v0.5.0

v0.5.0 release evidence

Scope, audit, harden, and retest web projects with AI coding agents and reproducible evidence.

Web App Security Skill v0.5.0 expands narrow automated source detection and makes every actionable
source result understandable before a user approves a change. It keeps the evidence discipline and
passive defaults from v0.4.0; it does not turn syntax matches into confirmed vulnerabilities or let
the CLI edit a project unattended.

Release identity

• Version/tag: v0.5.0
• Source identity: the commit peeled from the SSH-signed annotated tag; the exact 40-character SHA
  is also recorded in web-app-security-skill-0.5.0.release.json and the provenance attestation.
• Runtime matrix: Node.js 22 and 24 on Ubuntu and macOS; Bash 3.2 remains covered on macOS.
• External adapters: Gitleaks 8.30.1, Opengrep 1.27.0, OSV-Scanner 2.5.0 and Checkov 3.3.9,
  installed and version-pinned by the caller.

This Markdown file is part of the source commit it describes, so it does not embed a fabricated
self-referential commit SHA. Verify the exact published identity with the signed tag, release
manifest and provenance.

Stable rule boundary

The v0.5.0 stable source and deployment-policy corpus contains exactly 30 rules:

• 20 built-in risk rules: four shared project/configuration checks, eight bounded
  JavaScript/TypeScript checks and eight tokenizer-backed Python checks;
• two built-in evidence-integrity rules that expose unreadable/failed source observations as
  unknown rather than clean;
• eight opt-in external-adapter risk rules: two Gitleaks rules, two Opengrep rules, one
  OSV-Scanner rule and three Checkov rules.

The machine-readable source of truth is docs/stable-source-rules.json,
and docs/stable-rule-corpus.json links every stable rule to a positive
fixture, safe near-neighbour, expected state, evidence boundary and test entrypoint. Built-in rules
have 22 real observations and 22 planted missing-observation failures. External rules use pinned
real-tool CI fixtures. This demonstrates the documented observation paths, not population-level
precision, recall or exploitability.

Built-in depth is deliberately limited to direct lexical or tokenizer-backed constructs. It does
not prove whole-program input flow, runtime reachability, sanitizer correctness or deployment
exposure. Source patterns and external scanner rows remain suspected unless rule-specific
independent evidence confirms the conclusion.

Explanation and repair contract

Source findings and reports now use v3. Each actionable result retains the professional term and
standards mapping, then also records:

• a plain-language explanation and conditional consequence;
• the evidence that exists and what it cannot prove;
• one reviewable proposal, alternatives and likely product side effects;
• decisions that must remain with the owner;
• separate security and normal-function retests; and
• rollback criteria.

Persisted v2 source baselines remain readable through the compatibility layer and cannot
manufacture a fixed result. A fix is comparable only when subject, scope, rule identity and current
coverage agree. repair-plan and repair-validate create and validate private, non-overwriting
review records with explicit approval and dual-retest states. The CLI does not apply project edits,
deploy changes or migrations.

Adapter decisions

• Opengrep 1.27.0 is the stable bounded SAST adapter for two bundled, digest-pinned same-file
  request-to-command rules. It is opt-in, does not fetch rules and does not execute project code.
• Checkov 3.3.9 is the stable bounded deployment adapter for three fixed root Dockerfile/GitHub
  Actions rules. It uses --skip-download; it may query PyPI for version metadata but does not
  upload project source.
• Gitleaks and OSV-Scanner retain the v0.4.0 contracts. OSV data may change with the public advisory
  database. None of the adapters is downloaded automatically, and project dependencies are never
  installed or executed.

Exact selection evidence, rejected alternatives and failure behavior are in
docs/sast-adapter-benchmark.md,
docs/iac-adapter-benchmark.md and
docs/adapter-protocol.md.

Ordinary-project and demo evidence

The broader built-in v3 path ran against five existing ordinary Web projects at immutable commits,
without probing hosted services or executing project dependencies. All 43 observed findings were
uniquely reviewed: 11 useful leads, 27 expected benign matches, one unknown tokenizer observation
and four confirmed missing-lockfile facts. These are finding classifications, not 43 vulnerabilities
and not a precision/recall result. A zero-finding project is not evidence that the project is secure.

The local network-free demo uses one intentionally unsafe Node.js child-process call. It reports a
suspected CWE-78-shaped lead, states that input flow and reachability are unproven, proposes
execFile with separate arguments, names quoting and cross-platform behavior as side effects, then
records a compatible security retest and an independent functional retest. The demo proves this
bounded workflow, not automatic safe repair.

Release verification

The release workflow runs the full repository gate, builds every artifact twice and compares bytes,
verifies archive paths, the stable rule manifest, release manifest, SHA-256 list and SPDX 2.3 SBOM,
then exercises clean installation and an isolated v0.4.0-to-v0.5.0 lifecycle upgrade. GitHub build
provenance is requested only after these checks pass. External consumers separately exercise the
exact immutable Action source in backward-compatible crawl mode and v0.5.0 source mode before the
stable v1 alias moves.

Verify the published tag after release:

git -c gpg.ssh.allowedSignersFile=.github/release-signers verify-tag v0.5.0

Verify downloaded assets with SHA256SUMS, compare the manifest source commit with
git rev-parse 'v0.5.0^{}', and verify GitHub provenance. The built-in verified-installer trust
anchor is updated only after immutable public asset digests exist; until then, the documented
default installer remains the already trusted v0.4.0 release.

Unsupported and known risks

• This is not a general SAST/DAST scanner, authenticated pentest or proof that a project is secure.
• BOLA/IDOR, business logic, LLM/OAuth, database isolation and most framework-specific paths remain
  agent-guided and require project context.
• Twenty-seven expected benign matches in the bounded ordinary-project review show that lexical
  leads still need human review. No precision or recall percentage is claimed.
• Authenticated browser DAST, universal language coverage, automatic exploit generation, unattended
  patching, deployment and database migration are not provided.
• No authenticated third-party deployment, production cloud account or upstream live system was
  actively tested for this release.
• Native Windows, PowerShell and WSL2 remain unsupported because no maintained verification
  environment exists. Node 20 and earlier are not supported release targets.
• Signatures, checksums and attestations establish artifact identity and build origin; they do not
  prove that every security conclusion or proposed implementation is correct.