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 excessive-permissions
Minor caution · high confidence
The automated code-checking workflow doesn't explicitly limit what permissions it has. Since it only runs formatting and linting tools and doesn't upload anything or use secrets, the risk is very low, but adding a permissions restriction is good practice.
Technical evidence
Scanner reason: zizmor matched workflow-security rule excessive-permissions in this repository.
Contextual assessment: The lint workflow does not declare an explicit permissions block. Without it, the job inherits the repository default token permissions, which may be broader than needed for a lint-only job. However, this workflow performs no writes, deployments, artifact uploads, or secret access, so the practical exposure is minimal.
Impact: low · Exploitability: unlikely
Developer action: Add a top-level or job-level permissions block with contents: read to explicitly scope the workflow token.
The workflow uses a version label for a GitHub-provided tool instead of locking it to a specific code snapshot. This is common practice but could be made more secure by pinning to an exact version hash.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The workflow references actions/setup-node@v4 by major version tag rather than pinning to a commit SHA. A compromised tag could theoretically redirect to malicious code. This is a widespread community convention and the action is a first-party GitHub-maintained action, reducing practical risk.
Impact: low · Exploitability: unlikely
Developer action: Consider pinning actions/setup-node to a full commit SHA for reproducibility and supply-chain hardening.
The workflow uses a version label for the code-checkout tool instead of locking it to a specific code snapshot. This is common practice but could be made more secure by pinning to an exact version hash.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The workflow references actions/checkout@v4 by major version tag rather than pinning to a commit SHA. Same supply-chain consideration as the setup-node reference. The action is first-party and GitHub-maintained.
Impact: low · Exploitability: unlikely
Developer action: Consider pinning actions/checkout to a full commit SHA for reproducibility and supply-chain hardening.
The code-checkout tool keeps a temporary authentication token in its local configuration by default. Since this workflow doesn't save or share any build artifacts, there is no realistic way for that token to leak.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The artipacked finding relates to actions/checkout persisting the GITHUB_TOKEN in the local git config by default. This workflow does not upload artifacts or expose the git config to untrusted code, so credential leakage via artifacts is not possible here. The residual concern is negligible for a lint-only pipeline.
Impact: low · Exploitability: unlikely
Developer action: Optionally set persist-credentials: false on the checkout step to avoid leaving the token in the local git config.
This code sends a text prompt to a local AI model service (Ollama) so the test harness can generate or verify expected test outputs. No passwords, API keys, or private data are included in the request. This is normal behavior for a testing tool that needs to talk to a local AI.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.credential-exfiltration.javascript-secret-to-network in this repository.
Contextual assessment: The flagged fetch call posts to a local Ollama chat API endpoint. The request body contains only a model identifier, a user-role prompt message, a stream flag, and generation options such as token limits and stop sequences. No credentials, API keys, secrets, or user data are read from disk, environment, or SillyTavern state and then transmitted. The function is part of a test harness that calls a local LLM directly to produce or compare golden-file test fixtures, which matches the file's stated purpose.
Credential access and network transmission in one file
Expected behavior · high confidence
The scanner noticed that this file both reads files and makes a network request, which can sometimes indicate secret theft. In this case, the files being read are test fixture data, and the network request only sends a prompt to a local AI service. No sensitive information is sent over the network.
Technical evidence
Scanner reason: A credential source and an outbound network operation were detected in the same file.
Contextual assessment: The scanner flagged co-occurrence of credential access and network transmission in the same file. However, the only network sink in the supplied context is the Ollama chat API fetch, and the request body contains no credential material. The file imports filesystem utilities for reading and writing golden test files, not for reading secrets. No credential source is connected to the network call in the observable data flow.