No material or immediate-danger concern was identified in this review.
This advisory report describes what the named tools and review process found at one exact commit. Unknown or unobserved behavior may still exist.
0 immediate danger0 material6 low
What this review found
No material or immediate-danger item was identified.
Minor cautions
zizmor reported archived-uses
Minor caution · high confidence
The release automation references an old, no-longer-maintained GitHub Action. It only runs when a maintainer merges a pull request and uses the project's own release token, so it does not affect people who install or use the extension. It is a housekeeping issue worth fixing but not a security danger.
Technical evidence
Scanner reason: zizmor matched workflow-security rule archived-uses. The match applies to this repository.
Contextual assessment: The workflow uses actions/create-release@v1, which is an archived and unmaintained GitHub Action. The workflow runs only in CI on merged pull requests to the release branch and uses the repository's default GITHUB_TOKEN with contents write permission to create a release. No attacker-controlled input reaches the action inputs beyond PR labels and metadata that the maintainer controls, and no concrete harm to extension users is demonstrated. This is a maintenance and reliability concern rather than a demonstrated security vulnerability.
Impact: low · Exploitability: unlikely
Developer action: Replace actions/create-release@v1 with a maintained alternative such as softprops/action-gh-release or the GitHub CLI release command, and consider pinning actions by commit SHA.
Outdated actions/checkout@v2 used in release workflow
low risk · high confidence
The checkout step also uses an older version of a standard GitHub Action. This is a maintenance best-practice issue, not a demonstrated security problem.
Technical assessment
The workflow also uses actions/checkout@v2, which is an older major version. While not the scanner candidate, it is the same class of unmaintained-action maintenance issue and contributes no demonstrated security exposure because the workflow is maintainer-triggered CI with the default token.
Impact: low · Exploitability: unlikely
Developer action: Update actions/checkout to a current major version and pin by commit SHA for reproducibility.
The workflow briefly saves the project's release token to a temporary file on the build machine. This is unnecessary and slightly messy, but the file is discarded after the run and does not affect extension users.
Technical assessment
The step writes the GITHUB_TOKEN to a file named gh_token on the runner. The token is the default repository token, the file is ephemeral on a self-destroying CI runner, and subsequent steps pass the token via the GH_TOKEN environment variable instead. This is unnecessary and a mild hygiene issue, but it does not demonstrate exposure to extension users or external attackers.
Impact: low · Exploitability: unlikely
Developer action: Remove the file-writing step and rely solely on the GH_TOKEN environment variable already set in later steps.