No material or immediate-danger concern was identified in this review.
This advisory report describes what the named tools and contextual reviewer found at one exact commit. Unknown or unobserved behavior may still exist.
0 immediate danger0 material8 low
What this review found
No material or immediate-danger item was identified.
Minor cautions
zizmor reported unpinned-uses
Minor caution · high confidence
The workflow uses a version label for a build tool instead of locking it to an exact copy. If someone hijacked that label, they could run different code during automated testing. Locking to an exact version removes that risk.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The checkout action is referenced by major version tag rather than a full commit SHA. A tag can be rebound by the action maintainer, so a compromised tag would execute different code in CI. The workflow uses only contents: read permissions and exposes no user secrets, limiting the blast radius. Pinning to a SHA digest is the recommended hardening step.
Impact: low · Exploitability: plausible
Developer action: Pin actions to full commit SHA digests instead of version tags to prevent tag-rebinding supply-chain attacks.
The workflow uses a version label for the Bun setup tool instead of locking it to an exact copy. If that label were hijacked, different code could run during testing. Locking to an exact version removes that risk.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The setup-bun action is referenced by major version tag rather than a full commit SHA. Tag rebinding by the maintainer or a compromise of the action repository could alter executed code. The workflow scope is limited to contents: read with no user secrets, keeping impact low. SHA pinning is the standard mitigation.
Impact: low · Exploitability: plausible
Developer action: Pin actions to full commit SHA digests instead of version tags to prevent tag-rebinding supply-chain attacks.
The workflow uses a version label for the checkout tool instead of locking it to an exact copy. If that label were hijacked, different code could run during testing. Locking to an exact version removes that risk.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The checkout action in the first job is referenced by major version tag rather than a full commit SHA. A tag can be rebound, allowing altered code to run in CI if the action repository is compromised. Permissions are limited to contents: read and no user secrets are present. SHA pinning is the recommended hardening.
Impact: low · Exploitability: plausible
Developer action: Pin actions to full commit SHA digests instead of version tags to prevent tag-rebinding supply-chain attacks.
The workflow uses a version label for the Bun setup tool instead of locking it to an exact copy. If that label were hijacked, different code could run during testing. Locking to an exact version removes that risk.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The setup-bun action in the first job is referenced by major version tag rather than a full commit SHA. Tag rebinding or repository compromise could alter the code executed in CI. The workflow uses only contents: read permissions with no user secrets, limiting impact. SHA pinning is the standard mitigation.
Impact: low · Exploitability: plausible
Developer action: Pin actions to full commit SHA digests instead of version tags to prevent tag-rebinding supply-chain attacks.
The scanner worried that build credentials could leak through uploaded files, but this workflow never uploads any files, so there is nowhere for credentials to leak to.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The artipacked rule flags credential persistence via artifacts when checkout stores the GITHUB_TOKEN in .git/config and artifacts are later uploaded. This workflow has no upload-artifact steps and no steps that exfiltrate the git config. The workflow permissions are restricted to contents: read. There is no artifact-based exfiltration path.
This is a test file that loads the extension's own built code so it can be tested. The code being run is the project's own backend, read from a local build folder, not anything from the internet or from user input. Tests like this never run for people who install the extension.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: The matched construct is a test harness that reads the locally built backend module from the dist directory and executes it via the Function constructor, passing a mock spindle object. This is a standard pattern for loading a bundled module in a test environment without a module loader. The executed content is the project's own compiled backend, read from the local filesystem, not from any external or untrusted source. The file is a test file that is never shipped to or run by end users, as stated in the project purpose. No untrusted input reaches the Function constructor.
The scanner worried that build credentials could leak through uploaded files, but this workflow never uploads any files, so there is nowhere for credentials to leak to.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The artipacked rule flags credential persistence when checkout stores the GITHUB_TOKEN in .git/config and that file is later included in an uploaded artifact. This workflow contains no upload-artifact steps and no steps that read or transmit .git/config. Permissions are restricted to contents: read. There is no exfiltration path for persisted credentials.
This is a test-only helper that loads the extension's own backend code so the tests can exercise it. It only runs when a developer types the test command, is not part of what users install, and does not execute anything from outside the project.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: The flagged dynamic execution is a test harness that reads the built backend module from disk and instantiates it via the Function constructor, passing a mock spindle object. This is confined to the test file role and is not shipped to extension users. The executed code is the project's own compiled backend, not attacker-controlled input. No untrusted data reaches the Function constructor.