Snyk

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me the security scanning I actually need instead of Snyk: dependencies, code and containers checked in CI, with the noise cut down.

Read this first: the free tools here are genuinely good — Trivy for dependencies and containers, Semgrep for code, the public advisory databases underneath both. What the fee buys is a curated database beyond the public advisories, reachability analysis to cut false positives, and fix pull requests that pick a version that works. The first is not reproducible; the second and third mostly are, and they are where the value is.

STACK
- Node 20+ with Fastify for the orchestration and the dashboard
- SQLite through better-sqlite3, WAL mode
- Trivy and Semgrep as the engines, in containers. Do not write a scanner
- Caddy in front, on a private network

THE DATA MODEL
- repos: id, name, remote_url, default_branch, config_json, is_active
- scans: id, repo_id, commit_sha, ref, kind, started_at, finished_at, status, engine_versions_json
- findings: id, scan_id, kind, package, ecosystem, installed_version, fixed_version, advisory_id, severity, cvss, path, line, rule_id, message, is_direct, is_reachable, reachability_evidence, fingerprint
- suppressions: id, fingerprint, scope, reason, expires_at, approved_by, at — a suppression always has a reason and an expiry, never a permanent silent ignore
- advisories: id, source, identifier, ecosystem, package, affected_range, fixed_in, severity, published_at, withdrawn_at — mirrored locally from the public databases
- baselines: repo_id, fingerprint, first_seen_scan_id — what was already there when you started
- Fingerprints are stable across scans so a finding is one thing over time, not a new one every night

WHAT TO SCAN
- Dependencies from lockfiles, in every ecosystem the repository uses. The lockfile is the truth; a manifest constraint is not a version
- Transitive dependencies as well as direct, marked differently, because they are fixed differently
- Container images layer by layer, including the base image, which is usually where most of the findings are
- Infrastructure files for the obvious misconfigurations
- Secrets committed to the repository, including in history
- Your own code with rules for the classic injection and deserialisation patterns

THE NOISE PROBLEM, WHICH IS THE ONLY REAL DIFFICULTY
- An unfiltered scan of a normal repository produces hundreds of findings and is therefore ignored. Every one of them
- So the work is ranking, not detecting:
  - Is the vulnerable function actually called? Full reachability analysis is hard, but a cheap approximation is not: check whether the vulnerable package is imported at all, and whether the named symbol appears anywhere in your code or in a dependency's entry path. That alone removes a large share
  - Is it a direct dependency you can upgrade, or transitive with no fixed version available? Different action, different urgency
  - Is it in production code or a build tool? A vulnerability in a test-only dependency is not the same thing
  - Is it exposed? A parser vulnerability matters when you parse untrusted input and much less when you do not
- Present findings ranked by that, and let the default view show only what is actionable today
- A finding that cannot be acted on is a finding that should be visible somewhere other than the main list

BASELINE AND NEW FINDINGS
- On the first scan of an existing repository, record everything as the baseline. Do not fail the build on day one, or the tool is disabled on day one
- Fail on new findings above a threshold, and report the baseline separately with a plan to reduce it
- This is the same idea as new-code quality gates, and it is the difference between a tool that gets adopted and one that gets bypassed

FIX PULL REQUESTS
- For a direct dependency, propose the lowest version that resolves the advisory and satisfies the other constraints. The lowest, not the latest, because the smallest change is the one that gets merged
- Run the repository's own tests before opening it, and say in the body that they passed
- Include what changed, the advisory, and the release notes between the two versions
- Group by ecosystem and by update kind, on a schedule. Forty pull requests a week is forty nobody reads
- Honour a closed pull request: do not reopen the same fix

IN CI
- One command that scans and exits non-zero on new findings above the threshold
- Output as human-readable text and as SARIF, so the forge shows the findings in the diff natively — which is where somebody will actually see them
- A comment on the pull request listing only what the change introduced

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, FORGE_TOKEN, SESSION_SECRET, ADVISORY_MIRROR_PATH
- Migrations on boot, each once
- Advisory database mirrored on a schedule and the version recorded on every scan, so a change in results is explicable
- Nightly backup, restore script
- Health endpoint reporting the age of the advisory mirror

WHAT MATTERS MOST
The baseline and the ranking. Build those two before anything else — a scanner that reports four hundred findings on the first run is a scanner that gets switched off in week two, and the whole skill in this category is deciding what not to show.

Give me the repository, the engine wrappers, migrations, .env.example, the CI workflow, and a README that names the free tools it stands on.