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 artipacked
Minor caution · low confidence
The workflow checks out code in a way that leaves a temporary login token on the build machine. Since nothing is saved or uploaded from the build machine, that token cannot escape. It is a minor hygiene issue, not a live danger.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The checkout action at line 60 uses default persist-credentials behavior, which stores the scoped GITHUB_TOKEN in .git/config. However, this workflow never uploads artifacts, so there is no path for the persisted credential to leave the runner. The workflow permissions are limited to contents: read, further reducing impact.
Impact: low · Exploitability: unlikely
Developer action: Set persist-credentials: false on checkout steps if no subsequent git operations require the token.
The workflow uses a version label instead of an exact code fingerprint for a build tool. If that tool were ever tampered with, the build could be affected. Pinning to an exact fingerprint would remove that small risk.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The checkout action is pinned to a major version tag rather than a full commit SHA. This is a supply-chain hardening concern: a compromise of the action repository could affect CI runs. The workflow has minimal permissions (contents: read) and handles no user secrets, so the blast radius is limited to CI integrity.
Impact: low · Exploitability: unlikely
Developer action: Pin actions to full commit SHAs with version comments for reproducibility and supply-chain hardening.
The workflow uses a version label instead of an exact code fingerprint for the Bun setup tool. Pinning to an exact fingerprint would harden the build against supply-chain tampering.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The setup-bun action is pinned to a major version tag rather than a full commit SHA. Same supply-chain hardening concern as other unpinned actions. The workflow scope is limited to running tests and a build parity check with no secret material beyond the auto-generated token.
Impact: low · Exploitability: unlikely
Developer action: Pin actions to full commit SHAs with version comments for reproducibility and supply-chain hardening.
The workflow uses a version label instead of an exact code fingerprint for the checkout tool. Pinning to an exact fingerprint would harden the build against supply-chain tampering.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The checkout action in the check job is pinned to a major version tag rather than a full commit SHA. The workflow permissions are contents: read only, and no artifacts are uploaded, limiting the blast radius to CI integrity.
Impact: low · Exploitability: unlikely
Developer action: Pin actions to full commit SHAs with version comments for reproducibility and supply-chain hardening.
The workflow uses a version label instead of an exact code fingerprint for the Bun setup tool. Pinning to an exact fingerprint would harden the build against supply-chain tampering.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The setup-bun action in the check job is pinned to a major version tag rather than a full commit SHA. Same supply-chain hardening concern. The job only runs type checks, tests, and a dist parity check with no sensitive secrets.
Impact: low · Exploitability: unlikely
Developer action: Pin actions to full commit SHAs with version comments for reproducibility and supply-chain hardening.
The workflow checks out code in a way that leaves a temporary login token on the build machine. Since nothing is saved or uploaded from the build machine, that token cannot escape. It is a minor hygiene issue, not a live danger.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The checkout action at line 33 uses default persist-credentials behavior, storing the scoped GITHUB_TOKEN in .git/config. No artifacts are uploaded in this workflow, so there is no exfiltration path. The workflow is limited to contents: read permissions.
Impact: low · Exploitability: unlikely
Developer action: Set persist-credentials: false on checkout steps if no subsequent git operations require the token.
This is a test file that loads the extension's built backend code into a fake environment so the tests can check how it behaves. The dynamic execution is just the test harness running the project's own code locally during development. It is not part of what users install and never runs for anyone using the extension.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: The matched `new Function` call is in a test harness that reads the project's own built backend module from disk and executes it with a mock spindle object. This is a standard pattern for testing a bundled module without a real host environment. The file role is test, the README states tests are not shipped or run for end users, and the executed code is the project's own backend, not attacker-controlled input. No user-facing runtime path is involved.
This is a test file that loads the extension's own built code into a fake environment to run automated checks. It only runs the project's own code, not anything from users or the internet, and it is not included in the version people install.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: The flagged dynamic execution is inside a test harness that loads the project's own built backend module into an in-memory mock environment. The code being executed is read from the project's own dist output, not from user input, network data, or untrusted content. This pattern is used to exercise the word-swap engine through the real backend during automated tests. The file role is test, and the project documentation states tests are not shipped to users and only run during development checks.