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 material5 low
What this review found
No material or immediate-danger item was identified.
Minor cautions
zizmor reported artipacked
Minor caution · medium confidence
The release workflow handles the GitHub token carelessly by leaving it stored in the build environment and writing it to a file. However, the token is temporary and automatically scoped to just this repository, and nothing in the workflow publishes the build files anywhere, so the risk is low. This does not affect people who install the extension.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The checkout step uses the default persist-credentials behavior, which stores the ephemeral GITHUB_TOKEN in the runner's git config. Additionally, a later step writes the token to a plaintext file in the workspace. However, no artifact upload step exists in this workflow, so the persisted credential cannot leak through artifacts. The token is the scoped, ephemeral default GITHUB_TOKEN, not a long-lived secret. This is CI hygiene weakness with no path to end-user harm.
Impact: low · Exploitability: unlikely
Developer action: Avoid writing the token to a plaintext file; rely on the GH_TOKEN environment variable already set in subsequent steps. Consider setting persist-credentials: false on the checkout step if full git history is not needed for push operations.
The release workflow uses a version label for a GitHub Action instead of locking it to a specific snapshot. If someone compromised that action's repository and moved the label, the workflow could run altered code. This only affects the project's release process, not people who install the extension.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The workflow references actions/create-release@v1 using a floating major-version tag rather than a commit SHA pin. If the tag were moved to a malicious commit, the release job could execute untrusted code with write access to repository contents and releases. This is a standard supply-chain hardening gap common in hobbyist workflows and does not affect extension end users.
Impact: low · Exploitability: plausible
Developer action: Pin third-party actions to a full commit SHA rather than a floating tag.
The checkout step in the release workflow uses a version label instead of a locked snapshot. If that label were moved to malicious code, the release process could be affected. This does not impact people who install the extension.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The workflow references actions/checkout@v2 using a floating major-version tag rather than a commit SHA pin. The same supply-chain tag-swap concern applies. This is a common hardening gap in CI tooling and has no impact on extension end users.
Impact: low · Exploitability: plausible
Developer action: Pin actions/checkout to a full commit SHA and update to a current major version.
The release workflow uses a GitHub Action whose source repository is no longer maintained. It still works, but it will not receive fixes or improvements. This only affects the project's release process, not extension users.
Technical evidence
Scanner reason: zizmor matched workflow-security rule archived-uses in this repository.
Contextual assessment: The actions/create-release@v1 action originates from an archived GitHub repository and will no longer receive maintenance or security updates. It still functions for creating releases but represents a long-term reliability and supply-chain concern. This is a CI tooling issue with no effect on extension end users.
Impact: low · Exploitability: unlikely
Developer action: Replace the archived create-release action with a maintained alternative such as softprops/action-gh-release or the GitHub CLI release command.
The release workflow writes a temporary GitHub access token into a plain file on the build machine. The token is short-lived and nothing publishes the file, so the practical risk is low, but it is an unnecessary and sloppy practice.
Technical assessment
A workflow step writes the GITHUB_TOKEN to a file named gh_token in the runner workspace. Although the token is ephemeral and scoped, and no artifact upload step exposes the file, writing secrets to plaintext files is unnecessary and poor hygiene. Subsequent steps already receive the token via the GH_TOKEN environment variable.
Impact: low · Exploitability: unlikely
Developer action: Remove the step that writes the token to a file; the environment variable already provides it to later steps.