Static Security Audit of the Refactor Diff — refactor-chain · secure

Bundle: refactor-chain (self-diagnosing, self-healing fix-it pipeline). Phase: secure · Prerequisite: do-the-work (a lane produced changes) · Next: review gate (findings feed the reviewer, then ship). Adaptivity / conditional: repo-agnostic and advisory-only — reads the diff, ranks findings, edits nothing.

Purpose

Read the code the refactor changed and answer one question in plain words: is it safe to ship? This is a static audit — it reads source, config, and dependency manifests and reasons about them. It does not run the app, send payloads, or pen-test anything live. It walks the OWASP Top 10 lens over the diff — injection, broken auth/session, secrets in code, weak crypto, exposed PII, unsafe deserialization, SSRF/CORS/CSP — and hands back a ranked list of what to fix, worded so a non-security engineer can act on it. It changes no code; the developer (or the review gate) decides what to do.

When to use

• A refactor lane just finished and you want a safety check before the review gate or ship. Triggers: "security review", "is this safe to ship", "audit this change".
• Someone worries a change introduced or exposed a vulnerability. Triggers: "check for vulnerabilities", "OWASP check", "did we open a hole".
• You suspect a secret or credential got committed. Triggers: "did we leak a secret", "is there an API key in here".
• Precondition: there is a diff to look at (git diff, a branch, or a set of changed files). With no diff, it audits the current working tree but says so.