Security Validation Flow
A practical path to govern exported artifacts and enforce declared purpose at runtime — without breaking existing CI/CD and compliance workflows. Four steps, each earning its place workload by workload.
Native — plugs into existing tooling. Standard — operates on exported artifacts like any other build output. Optional — earns its place when the workload benefits.
Step 1 · Scan
Native
Run your existing SAST / DAST, dependency scanning, SBOM generation, and license checks against exported artifacts — like any normal build output. Nothing in scanner configuration needs to change.
- SAST / DAST: AppScan, Veracode, SonarQube, and similar tools
- Dependencies: Snyk, Mend, Dependency-Check
- SBOM: Syft, CycloneDX, SPDX
Step 2 · Sign
Standard
Sign exported artifacts and their attestations — SBOM, scan reports, provenance. This creates a verifiable compliance bundle that downstream systems can check before deploy.
- Signing: cosign, Sigstore
- Provenance: in-toto, SLSA-style attestations
- Artifacts: Nexus, Artifactory, container registries
Step 3 · Verify
Standard
Before deploy or execution, verify the signed bundle — policy gates, provenance checks, integrity validation. Scan-ready builds remain available when required.
- Policy gates: OPA, Gatekeeper, custom CI checks
- Integrity: verify signatures and hashes
- Controls: choose fixed (scan-ready) vs adaptive outputs
Step 4 · Runtime Enforce
Optional
If you adopt deeper integration, enforcement continues at runtime: declared purpose, trust posture, and who / what / when / why audit trails — not just build-time checks. Trust becomes continuous rather than a one-shot gate.
- Declared-purpose enforcement: allow only verified intents
- Continuous verification: trust and validation while running
- Audit trails: who executed what, where, when
How the four steps compose
Build-Time Alone
Steps 1–3 alone give you a compliance workflow that looks identical to any regulated enterprise deployment today. No runtime changes required; no new assurance model to explain to auditors.
Build-Time Plus Runtime
Adding Step 4 extends the assurance model into execution. The artifact that was scanned, signed, and verified continues to be checked while it runs — against the policies it was authorized under. Drift, unauthorized behavior, or purpose violations trigger policy-defined action.
Per-Workload Choice
Some workloads justify all four steps; others only need Steps 1–3. The flow is incremental — you invest in runtime enforcement where it earns its place, not as a platform-wide mandate.
You can keep your existing compliance workflow intact while selectively adding verification and runtime enforcement where it delivers measurable assurance. The four-step flow composes: each step earns its place without requiring the next.