Security Validation Lanes

Atlas separates supply-chain, threat-model, and data-protection validation so their findings remain attributable. The lanes overlap in governance evidence but protect different boundaries and have different trigger coverage.

Lane Map

Lane	Trigger	Primary evidence
supply chain	every pull request and pushes to main	governance artifacts, security validation, dependency audit, and command contract test
threat model	manual dispatch and selected model, implementation, CLI, workflow, or public security documentation paths	threat-registry verification plus positive and negative command contracts
data protection	every pull request and pushes to main	runtime data-protection contracts, governance evidence, and security control validation

flowchart TD
    Candidate[Candidate revision] --> Supply[Dependency and supply-chain lane]
    Candidate --> Threat[Threat-model lane]
    Candidate --> Data[Data-protection lane]
    Supply --> Findings[Scoped findings and evidence]
    Threat --> Findings
    Data --> Findings
    Findings --> Decision{Required security claims satisfied?}
    Decision -->|no| Block[Block or narrow release]
    Decision -->|yes| Bind[Bind evidence to release candidate]

Evidence Boundaries

Supply-chain validation covers repository governance artifacts, dependency security commands, and their command contract. It does not by itself prove image provenance, registry integrity, or deployment admission.

Threat-model validation checks governed threat linkage and command behavior. Its path filter covers ops/security/threat-model/**, the command implementation and routing, the public security and maintainer guides, and the workflow itself. It intentionally remains a pull-request and manual-dispatch lane; a direct push does not create threat-lane evidence unless another invocation runs it.

Data-protection validation exercises runtime protection contracts and broader governance/security commands. It does not prove live secret delivery, encryption infrastructure, external identity, or production data handling.

The runtime contract covers certificate-bundle parsing, TLS policy decisions, rotation state, checksums, manifest integrity, and an internal keyed digest. It does not establish live TLS termination, asymmetric producer signatures, storage-layer encryption, or target key custody. The data-protection guide defines the additional operator evidence for those claims.

Change-to-Lane Coverage

Changed surface	Expected threat-lane action	Review requirement
threat assets, taxonomy, registry, threats, or mitigations	trigger and run registry verification plus both command contracts	inspect coverage report status, errors, and changed residual risk
security contract schema	no threat-lane trigger is guaranteed	run the schema's owning validation and determine whether threat verification also needs that schema
threat command implementation or CLI route	trigger and exercise the focused command contracts	retain test count and command output
public threat, identity, supply-chain, workload, or admin-exposure claim	trigger the lane	reconcile the claim with governed model and implementation evidence
runtime authorization or server route outside watched paths	no threat-lane trigger is guaranteed	run route-level security evidence and evaluate whether the workflow path set must expand
chart, RBAC, NetworkPolicy, or deployment profile outside watched paths	no threat-lane trigger is guaranteed	render and validate the exact deployment profile; the threat lane is insufficient

Path coverage is a change detector, not control coverage. If an implementation surface can invalidate a documented mitigation but is not watched, record that gap and run the owning evidence explicitly.

Administrative Route Coverage Gap

None of the three workflows compares the complete server route-registration set with route_is_admin_endpoint. The server currently registers 26 routes when administrative endpoints are enabled, but the classifier recognizes only 18. Replica, recovery, failure-injection, and chaos routes fall through to the ordinary dataset-read authorization class.

The supply-chain lane checks dependency and governance surfaces. The threat lane verifies the threat-model control-plane command and its positive and negative command contracts. The data-protection lane runs runtime foundation contracts. Those are valuable checks, but none establishes route-level parity in the server adapter. A green conclusion from all three lanes must not be reported as proof that enabled administrative routes are operator-only.

Tolerated Commands and Artifacts

The supply-chain and data-protection workflows run several governance evidence commands with || true, then verify that expected files exist. File presence does not establish an internally passing result. Review the generated statuses and findings before accepting security evidence, and require downstream gates to fail closed on invalid or failed content.

Carry Findings to Closure

Every non-passing security observation needs a durable disposition. Workflow completion and artifact upload are transport events, not dispositions.

Finding state	Acceptance rule
open.	The protected claim remains blocked or explicitly narrowed.
accepted exception.	Scope, authority, expiry, compensating control, and removal path are recorded.
false positive.	The detector, affected evidence, and reproducible disproof are retained.
remediated.	The fix revision and a fresh execution of the owning check both pass.
superseded.	A named policy or control replaces the finding and preserves historical lineage.

Do not infer remediation because a later run omitted the finding. Confirm that the same detector, policy revision, and target surface executed. A changed path filter, tolerated command, or missing artifact can make a finding disappear without changing the risk.

Trigger, Execution, and Acceptance

flowchart LR
    Change[Candidate change] --> Trigger{Workflow triggered?}
    Trigger -- no --> Gap[Record coverage gap]
    Trigger -- yes --> Execute{Required commands executed?}
    Execute -- no --> Incomplete[Record incomplete lane]
    Execute -- yes --> Internal{Reports internally pass?}
    Internal -- no --> Reject[Reject or govern exception]
    Internal -- yes --> Bind{Bound to candidate artifacts?}
    Bind -- no --> Unbound[Retain as unbound observation]
    Bind -- yes --> Accept[Accept lane-owned claim]

A green workflow conclusion answers only the outermost automation question. Security acceptance also requires expected trigger coverage, command execution, internally passing reports, and binding to the exact candidate. Artifact upload with if: always() preserves diagnostics; it does not convert failed content into passing evidence.

Coverage by Claim

Release claim	Repository lane	Additional evidence outside the lane
dependency and source policy	supply chain	released SBOM, artifact provenance, and consumer verification
threat controls match implementation	threat model	rendered exposure, live route tests, and incident detection
protected runtime data paths	data protection	live secret delivery, storage encryption, access audit, and retention
administrative routes are operator-only	no current lane provides complete coverage	registration-to-classifier parity plus authenticated positive and unauthorized negative tests for every enabled route
image admitted as intended	supply chain plus deployment policy	image digest, signature or ledger verification, and admission result
production exposure is safe	all applicable lanes	edge identity, network reachability, authorization, and workload evidence

No repository lane observes the entire production trust boundary. Use lane results as inputs to deployment security review, not as a replacement for it.

Release Use

Bind each accepted report to the source revision, dependency lock state, security policy, tool versions, and released artifact identities. Record lane trigger, skipped coverage, exceptions, and unresolved findings. A combined “security passed” claim is valid only when every security boundary required by the release has direct evidence; absence of a triggered lane is not a pass.