scan-security — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited scan-security (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Conduct a Snyk security audit of the current repository: static analysis (SAST) of code, software composition analysis (SCA) of dependencies, remediation of findings the project's verification gates accept, and a prioritized evidence-backed findings report.
This skill carries the audit workflow. The project supplies the rest: build / lint / test / install commands, source file conventions, dependency-manager invocations, false-positive patterns, and any hard remediation prohibitions live in the project's context files (AGENTS.md, CLAUDE.md, CONTRIBUTING.md, README.md) and architecture documentation. This skill tells you how to scan, remediate, and report; the project tells you what counts as valid for fixes.
The user invokes this skill with an optional scope argument. Resolve the scope before any tool call.
| Scope | SAST target | SCA target |
|---|---|---|
all (default when unset) | Entire repository | Full dependency manifest set |
code | Entire repository | (skipped) |
deps | (skipped) | Full dependency manifest set |
changed | Source files modified vs. HEAD | Manifest / lock files modified vs. HEAD |
For changed, derive the file set from the union of git diff --name-only HEAD and git diff --cached --name-only, deduplicated. Within that set:
package.json + lock, go.mod + go.sum, pyproject.toml + lock, Gemfile + Gemfile.lock, composer.json + lock, Cargo.toml + Cargo.lock, etc.). Include only manifests that appear in the diff.Copy this checklist into your response and tick items as you complete them.
Run these checks in order. Abort if any fails. Scanning incomplete or broken code produces unreliable results.
1a. Snyk capability. Determine how Snyk is reachable in this session, in preference order:
snyk_auth_status, snyk_auth, snyk_code_scan, snyk_sca_scan, snyk_trust, snyk_iac_scan, snyk_container_scan. Hosts namespace them differently (Claude Code exposes them as mcp__<server>__snyk_code_scan; other clients use other prefixes). Match by suffix and by tool description, not by exact name.command -v snyk. The CLI subcommands are snyk code test (SAST), snyk test (SCA), snyk auth, and snyk config get api (auth status).npm install -g snyk as remediation. Do not proceed.Record which path is in use; reuse it throughout the workflow.
1b. Authentication. Call the auth-status tool (snyk_auth_status via MCP) or run snyk config get api. If the result is empty or reports unauthenticated, halt. Tell the user to authenticate (snyk auth or the snyk_auth MCP tool) and re-invoke this skill.
1c. Build gate. Read the project's context files (AGENTS.md, CLAUDE.md, CONTRIBUTING.md, README.md) and identify the canonical command that compiles or type-checks the codebase. Run it. The project must build cleanly before a scan is meaningful. If the gate fails, halt and surface the errors.
If the project context does not document a build command, infer the default from the project manifest (e.g., tsc --noEmit for TypeScript, go build ./... for Go, cargo check for Rust) and note the inference in the report's Next Steps.
1d. Baseline SHA. Capture git rev-parse HEAD. This SHA anchors the report.
Skip when scope is deps.
Call the SAST tool (snyk_code_scan via MCP, or snyk code test --json via CLI) against the SAST target from Inputs.
For every finding, record:
| Field | Content |
|---|---|
| ID | SAST-{seq} starting at SAST-01 |
| Severity | critical / high / medium / low |
| CWE | Identifier and category (e.g., CWE-89 SQL Injection) |
| Location | path:start-end |
| Summary | One sentence describing the vulnerability |
| Snyk suggestion | Snyk's fix recommendation, if any |
| Confidence | high / medium / low |
Capture every finding Snyk reports. Do not filter or suppress at this stage. Triage happens in Step 4.
Skip when scope is code.
Call the SCA tool (snyk_sca_scan via MCP, or snyk test --json via CLI) against the SCA target from Inputs.
For every vulnerability, record:
| Field | Content |
|---|---|
| ID | SCA-{seq} starting at SCA-01 |
| Severity | critical / high / medium / low |
| CVE | CVE identifier(s) |
| Package | Name plus installed version (e.g., [email protected]) |
| Fixed version | Earliest version resolving the issue |
| Dep type | direct or transitive |
| Upgrade path | What to change to reach the fixed version |
Classify every finding from Steps 2-3 before touching any file.
| Verdict | Criteria | Next action |
|---|---|---|
| Fix Now | Safe fix exists; surgical change; no public API break; no major version bump | Remediate in Step 5 |
| Manual Review | Correct but risky: major version bump, API shape change, or expected test failures | Document; do not touch |
| False Positive | Matches a project-documented safe pattern | Suppress with inline justification |
| Track | Low severity with no safe upgrade path at this time | Document for backlog |
Project-approved safe patterns. Snyk's generic rules can fire on patterns that are intentionally safe in the host project. Search the project's context files and architecture documentation for documented safe patterns (search terms like "intentional", "false positive", "approved", "by design" alongside any term that appears in a finding). When a finding matches a documented pattern, classify as False Positive and cite the project documentation in the report. Never classify as False Positive without a citation; an undocumented suspicion is Manual Review.
Project prohibitions. The project context may document hard prohibitions: "never modify the database schema", "never downgrade dependency X below version Y", "never touch directory Z", "never modify lint / format config". Read these alongside the rest of project context at Step 1. Any Fix-Now candidate that would violate a documented prohibition becomes Manual Review with the prohibition cited as the reason.
Process Fix-Now findings ordered by severity, most severe first. After each individual fix, run the verification gate.
Verification gate. The set of commands the project considers proof that a change is acceptable. Read the project's context files at Step 1 (refresh now if needed) and run only the subset relevant to what you changed.
npm ci, yarn install --frozen-lockfile, pnpm install --frozen-lockfile, bundle install, poetry install, go mod tidy, cargo check) and the full test suite.Follow the project's declared commands verbatim. Do not substitute equivalents (e.g., do not invoke a binary directly when conventions specify a task runner). If the project context is silent on a category you touched, infer the default from the manifest and note the inference under the affected finding in the report.
On verification failure: revert the change with git checkout -- <files> and reclassify the finding as Manual Review. Move on.
SAST fix procedure.
SCA fix procedure.
git checkout and reclassify as Manual Review.Suppressions and inline disables. Never add a tool-specific disable comment (// snyk:disable, /* eslint-disable */, # noqa, #nosec, etc.) without an inline justification in the same comment that names the False Positive pattern the project context documents.
Staging. Never git add -A, git add ., or any equivalent blanket-staging command. Stage only files this skill intentionally modified, if asked to stage at all (the default is to leave changes unstaged for the user to review).
After all Step 5 work is complete:
For each previously remediated finding, confirm it no longer appears in the new output. If it still appears, append to the Manual Review section and update the report counts.
If a finding appears that was absent in Steps 2-3, treat it as a regression introduced by remediation: revert the responsible change, reclassify the finding as Manual Review, and document the regression in the report.
Write the report to .audit/security-{YYYYMMDD}-{short-sha}.md, where {short-sha} is the first 8 characters of the baseline SHA from Step 1d. Create .audit/ if absent. If a file with this name already exists, append -2, -3, etc. before the .md extension.
Use assets/report-template.md as the structural template. Fill every section; write "None" when a section is empty.
After writing the file, print to chat: the report's absolute path, the Summary table, and the verdict. Do not paste the full report into chat.
create-pr skill), recommend it in Next Steps; do not invoke it from this skill.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.