A chain-of-custody model for software artifacts: proving — not just claiming — that what shipped is what was scanned.
Security scanning is often treated as a one-time checkbox: scan once, move on. But that leaves real questions unanswered. Was the artifact that got deployed actually the one that was scanned? Can you prove that, months later, if asked? Most pipelines have no structural answer.
SEVEN treats security compliance as an unbroken, directed graph of metadata — every artifact carries a verifiable record of where it came from and what verdict it received, rather than relying on a scan log that could apply to anything.
- PR Stage (Advisory Gate) — Runs lightweight scans on pull requests. Findings are surfaced directly in the PR for visibility; this stage informs developers early but doesn't block on its own.
- QA Stage (Authoritative Gate) — On merge to a trusted branch, a full Software Bill of Materials (SBOM) is generated, enriched with custom metadata, and run through an authoritative vulnerability scan. The enriched SBOM and an audit sidecar are published as immutable artifacts.
- Release Stage (Compliance Gate) — At release time, no new SBOM is generated. Instead, the system pulls the already-validated SBOM from the QA stage and re-verifies it against current compliance requirements, proving structural identity between what was tested and what's shipping.
- No raw output leakage — all execution output is filtered through structured logging rather than passed through as raw text.
- Decoupled authentication — credential injection for different ecosystems (npm, Maven, NuGet, etc.) is handled through an interface rather than hardcoded per-script logic, so adding a new ecosystem doesn't require touching core execution code.
- Shell-less execution — binaries are invoked directly rather than through a shell, removing an entire class of injection risk.
The output of this model isn't just "pass/fail" — it's a forensic-grade record linking a specific build, to a specific scan, to a specific verdict, that can't be quietly substituted later. That's the difference between claiming compliance and being able to prove it on demand.
This is a conceptual architecture writeup describing a security governance pattern, generalized from real design work. It is not tied to any specific organization's tooling or pipeline implementation.