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.
This page describes the design. Today, only the GPU optimization build at adaptwithchameleon.com runs. File-based output is re-established during the first 30 days of funded milestone work, and the OS-hosted runtime, illumin8 and the other Aptivs return when the milestones are complete. Wantware is not about writing or generating code as applications.
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.