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 unpinned-uses
Minor caution · high confidence
The CI workflow uses a version label for a standard GitHub action instead of locking it to an exact code snapshot. This is a common practice and low risk, but pinning to an exact snapshot is the stricter best practice.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The workflow references actions/checkout using a major-version tag rather than a full commit SHA. Major-version tags are mutable and could be retargeted by a compromised maintainer account, but this is the prevailing convention across the ecosystem and the workflow performs only read-only checkout and test execution with no secrets beyond the default token.
Impact: low · Exploitability: unlikely
Developer action: Consider pinning third-party actions to full commit SHAs for stricter supply-chain integrity, though this is optional for first-party actions used at major-version tags.
Same as the checkout finding: the workflow uses a version label instead of an exact code snapshot for a standard GitHub action. Low risk and common practice.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The workflow references actions/setup-node using a major-version tag rather than a full commit SHA. As with the checkout action, this is the dominant convention and the action is first-party. The risk is that a mutable tag could be retargeted, but the workflow has no privileged operations or secret usage that would amplify such an event.
Impact: low · Exploitability: unlikely
Developer action: Consider pinning to full commit SHAs for stricter supply-chain integrity, though optional for first-party actions at major-version tags.
The workflow does not explicitly limit what its built-in token is allowed to do. Since the workflow only runs tests and does not need write access, adding an explicit minimal-permissions line would be a good hardening step but is not an active vulnerability.
Technical evidence
Scanner reason: zizmor matched workflow-security rule excessive-permissions in this repository.
Contextual assessment: The workflow does not declare an explicit permissions block, so the GITHUB_TOKEN scope defaults to the repository or organization setting. The workflow performs only checkout, dependency install, and a check run, none of which require write or elevated permissions. Adding an explicit minimal permissions block would harden the workflow against accidental broad defaults.
Impact: low · Exploitability: unlikely
Developer action: Add an explicit permissions block with read-only contents to the workflow job to ensure least-privilege defaults regardless of repository settings.
The scanner saw a string that looks like it could be a key and flagged it. It is actually just a label the extension uses to remember where it stores its crash-recovery data in the browser. It is not a password or secret of any kind.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key in this repository.
Contextual assessment: The flagged value is a string constant used as a localStorage key for the extension's crash-recovery journal. It is a descriptive identifier, not a credential, API key, or secret. No authentication material is present, and the value is used solely to namespace persisted state in the browser.
The scanner flagged a risk about saving credentials into downloadable files, but this workflow never creates or uploads any files. The concern does not apply here.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The artipacked rule flags potential credential persistence in artifacts, but this workflow contains no upload-artifact step and produces no artifacts. It only checks out source, installs dependencies, and runs a lint or test command. The default GITHUB_TOKEN used by checkout is not persisted anywhere. The scanner confidence is low and the finding does not apply to the actual data flow.