← ClaudeAtlas

security-regression-testslisted

Lock every confirmed security fix with a deterministic regression test so CI re-verifies it on every build (no live probing) — Applies to: when a security finding has been confirmed and fixed; when generating or changing security-sensitive code (authz, input handling, secrets); when wiring a security gate into CI/CD
ShieldNet-360/secure-vibe · ★ 3 · Testing & QA · score 76
Install: claude install-skill ShieldNet-360/secure-vibe
<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. --> <!-- Do not edit by hand; the source of truth is skills/security-regression-tests/SKILL.md. --> # Security Regression Tests Lock every confirmed security fix with a deterministic regression test so CI re-verifies it on every build (no live probing) ## ALWAYS - For every **confirmed and fixed** security finding, add a regression test that pins the secure behaviour, and commit it. The test is the durable, CI-side verification — it re-checks the fix on every build, unlike a one-off live probe. - Structure each test as **attack + control**: the attack input now yields the secure outcome (`403`/`404`, rejected, escaped, not evaluated, no exec), AND a legitimate input still succeeds. Both assertions matter — the attack half guards the vulnerability; the control half catches an over-correction that breaks the feature. - Map the test to the finding's class: - IDOR/BOLA → authenticate as A, request B's resource id → `403`/`404`. - Broken auth → forged / expired / `none`-alg token → `401`. - Mass assignment → POST an extra privileged field → it is ignored, never persisted. - SQLi / XSS / SSTI → the payload is parameterized / escaped / not evaluated. - Secret → the secret is absent from the built artifact and loaded from the env. - Prefer the **smallest tier that proves it**: a unit test on the handler/guard covers most authz/validation; use an integration test only when