A real, publicly-verifiable proof pack from samples/vulnerable-web.

The verifier fetches the JWS, fetches the JWK, imports the Ed25519 key using the browser's Web Crypto API, checks the signature over the JWS signing input, and then re-hashes every component file to confirm it matches the SHA-256 recorded in the signed payload.

• Violated
  No critical findings

  no-critical-findings · 1 critical findings.
• Violated
  No known CVEs in direct dependencies

  no-known-cve-in-direct-deps · Direct dependencies checked against OSV.
• Violated
  No `eval` on untrusted input

  no-eval-on-untrusted-input · SEC-EVAL-001 gate.
• Violated
  High-severity findings ≤ 2

  high-severity-cap · 3 high-severity findings (cap 2).
• Violated
  No architectural fan-out violations

  architecture-fanout · ARCH-FANOUT-001 gate.

• criticalsecuritySEC-EVAL-001

  Direct call to `eval()` on user-controlled input

  src/handlers/dangerous.ts:4 · dangerousHandler

  confidence 99%
  return eval(input);

  Why: The parameter `input: string` reaches a call to the global `eval` builtin with no sanitisation. Any caller controls arbitrary code execution.

  Detector: svp-parser + svp-verification (data-flow to sink)

  Reachable from

  • → src/index.ts:main → dangerousHandler("2+2")
  Recommendation: Replace `eval` with a scoped expression evaluator, or reject the endpoint entirely.
• lowsecuritySEC-SECRET-NAME-001

  Symbol name matches secret-material heuristic

  src/auth/secrets.ts:5 · getSecretKey

  confidence 42%
  export function getSecretKey(): string { ... }

  Why: Function name matches the pattern `get*Secret*` — a name-based signal that this may return sensitive material. Body currently returns an env value with a plaintext fallback; validate that no real secret is inlined in future.

  Detector: svp-verification (name heuristic)

  Reachable from

  • → src/index.ts:main → getSecretKey()
  Recommendation: Confirm the fallback is never taken in production; assert `SVP_DEMO_SECRET` presence at startup.
• mediumqualityQUAL-LONG-001

  Function body exceeds physical length threshold (≥200 lines)

  src/handlers/long.ts:3 · longHandler

  confidence 100%
  export function longHandler(): number { ... 220+ lines ... }

  Why: Physical LoC ≥ 200 within a single function body.

  Detector: svp-parser (structural metric)

  Recommendation: Extract logical sub-steps into helper functions.
• mediumqualityQUAL-PARAMS-001

  Function accepts more than 7 parameters

  src/handlers/manyparams.ts:3 · manyParamsHandler

  confidence 100%
  export function manyParamsHandler(a, b, c, d, e, f, g, h, i)

  Why: 9 formal parameters — over the configured threshold of 7.

  Detector: svp-parser (structural metric)

  Recommendation: Group related parameters into an options object.
• higharchitectureARCH-FANOUT-001

  Excessive fan-out ("god function") — 42 outgoing call edges

  src/handlers/god.ts:45 · godHandler

  confidence 100%
  godHandler calls a() b() c() ... ap() — 42 distinct targets

  Why: Symbol fan-out is 42; architectural policy caps intra-module fan-out at 20. This handler concentrates orchestration that should live in a coordinator.

  Detector: svp-knowledge-graph (call-edge count)

  Reachable from

  • → src/index.ts:main → godHandler()
  Recommendation: Split into per-responsibility coordinators; consider a command bus pattern.
• highsupply-chainSC-CVE-LODASH-001

  Direct dependency `lodash@4.17.20` has known CVEs (OSV)

  package.json:8

  confidence 100%
  "lodash": "4.17.20"

  Why: Version 4.17.20 predates fixes for CVE-2020-8203 (prototype pollution) and CVE-2021-23337 (command injection via `template`). Fixed in 4.17.21+.

  Detector: svp-dependency + OSV feed

  Recommendation: Bump to `lodash ^4.17.21` (patch-only upgrade, no API break).
• mediumsupply-chainSC-CVE-EXPRESS-001

  Direct dependency `express@4.17.1` is behind current stable

  package.json:9

  confidence 90%
  "express": "4.17.1"

  Why: Version 4.17.1 predates several 4.x security patches; current 4.x stable resolves multiple ReDoS and prototype-pollution issues.

  Detector: svp-dependency + OSV feed

  Recommendation: Bump to latest 4.x (`^4.19.2` at time of writing).
• highsupply-chainSC-CVE-JWT-001

  Direct dependency `jsonwebtoken@8.5.1` has known CVEs

  package.json:10

  confidence 98%
  "jsonwebtoken": "8.5.1"

  Why: Version 8.5.1 is affected by CVE-2022-23539 (weak signature verification when `algorithms` is not passed) and CVE-2022-23540/23541 (algorithm confusion). Fixed in 9.0.0.

  Detector: svp-dependency + OSV feed

  Recommendation: Bump to `jsonwebtoken ^9.0.2` and pass an explicit `algorithms` allowlist to `jwt.verify`.

If you prefer a JOSE library: any Ed25519-capable JWS verifier will work (Python joserfc, Node jose, Go github.com/go-jose/go-jose). The key id to look up in the JWKS is softinel-evidence-2026-07.

• → Canonical. One model — files, symbols, edges, dependencies, findings, verdict — in one structure with one identifier per node.
• → Connected. Every finding is grounded in a specific file, symbol, and reachability chain. Verdict conditions cite the rule ids that produced them.
• → Queryable. The verdict is a query (policy over model + evidence). Same substrate answers the security, quality, architecture, and supply-chain questions.
• → Evidence-bearing. Every claim ships with its source extract, its confidence, and the detector that produced it. Nothing is asserted without provenance.
• → Signed. The entire pack is committed to by a single Ed25519 signature over the SHA-256 of every component file. Tamper with anything and the signature breaks.