No material or high-risk 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 high0 material5 low
What this review found
No material or high-risk item was identified.
Minor cautions
zizmor reported artipacked
Minor caution · high confidence
The workflow checks out code using a setting that temporarily stores a short-lived access token on the build machine. Because the machine is destroyed after the job finishes and the token expires quickly, there is very little real risk.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The checkout action at line 22 uses default persist-credentials behavior, which writes the short-lived GITHUB_TOKEN into .git/config on the runner. Since this job runs on an ephemeral GitHub-hosted runner and the token expires when the job ends, the practical risk of credential persistence is minimal. No artifacts are uploaded that could capture the .git directory.
Impact: low · Exploitability: unlikely
Developer action: Consider setting persist-credentials: false on the checkout step if no subsequent git operations require authenticated access, as a defense-in-depth measure.
The release workflow uses a version label instead of a fixed code snapshot for one of its build tools. If someone changed what that label points to, the workflow could run different code. Pinning to a specific snapshot would prevent that.
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. If the tag were ever moved or compromised, a different version could execute in the release pipeline. This is a CI supply-chain hardening gap, not a runtime extension vulnerability.
Impact: low · Exploitability: plausible
Developer action: Pin the action to a full commit SHA for reproducible and tamper-resistant builds.
The checkout step uses a version label instead of a fixed code snapshot. Pinning to a specific snapshot would prevent unexpected changes if the label were ever moved.
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. This is a common practice but introduces a supply-chain risk where a retagged or compromised version could execute in the pipeline. This is a CI hardening gap, not a runtime extension issue.
Impact: low · Exploitability: plausible
Developer action: Pin the action to a full commit SHA for reproducible and tamper-resistant builds.
One of the build tools used in the release workflow is no longer maintained by its creators. It still works, but it will not receive fixes or updates going forward.
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 repository that no longer receives maintenance or security updates. While the action still functions, relying on archived tooling in a release pipeline is a maintenance and supply-chain concern. This does not affect the extension's runtime behavior.
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 commands already used elsewhere in the workflow.
GitHub token written to filesystem as plaintext file
low risk · medium confidence
The workflow saves a short-lived access token to a plain file on the build machine. This appears unnecessary since the token is also available through an environment variable. The risk is low because the machine is temporary, but it is better to avoid writing secrets to files.
Technical assessment
At line 27 the workflow writes the GITHUB_TOKEN to a file named gh_token on the runner. The token is also provided via the GH_TOKEN environment variable on subsequent steps, making the file write appear redundant. The file is created on an ephemeral runner and the token is short-lived, limiting practical risk, but writing secrets to plaintext files is an unnecessary exposure surface.
Impact: low · Exploitability: unlikely
Developer action: Remove the file-writing step and rely solely on the GH_TOKEN environment variable for GitHub CLI authentication.