One scan. Every framework.

The Gap

DevSecOps teams operate in a world of scanners, pipelines, and findings. They run static application security testing against source code repositories, dynamic application security testing against running applications, software composition analysis against dependency manifests, container image scanning against registry artifacts, and STIG compliance checks against operating system and application configurations. These scans produce structured output: SARIF files with rule IDs and locations, JSON reports with severity scores and remediation guidance, proprietary formats with scanner-specific metadata. The DevSecOps team triages these findings, assigns them to developers, tracks remediation through ticketing systems, and measures progress through vulnerability density metrics. Their world is measured in findings per scan, mean time to remediation, and critical vulnerability counts. They care about whether the code is secure. They do not think in terms of controls, practices, or framework requirements.

Compliance teams operate in a parallel universe. They maintain spreadsheets or GRC platforms that list every control required by every framework the organization must satisfy. For each control, they need evidence: a document, a screenshot, a configuration export, or a narrative that describes how the organization satisfies the requirement. They schedule quarterly evidence collection cycles where engineers take screenshots of dashboards, export access control lists, and capture configuration snapshots. They write implementation narratives that describe the organization's approach to each control. They chase engineers for proof that specific security measures are operating. Their world is measured in controls satisfied, evidence freshness, and assessment readiness percentage. They care about whether compliance can be demonstrated. They do not think in terms of SARIF findings, scanner rule IDs, or vulnerability severity scores.

Both teams are working from the same underlying security reality. A SAST finding that identifies an input validation vulnerability (the kind catalogued by OWASP) is evidence relevant to NIST 800-53 SI-10 (Information Input Validation). A container scan that confirms no known vulnerabilities in a base image is evidence relevant to SI-2 (Flaw Remediation) and CM-2 (Baseline Configuration). A STIG check that verifies password complexity settings is evidence relevant to IA-5 (Authenticator Management). The scan results that DevSecOps teams produce every day contain compliance evidence that compliance teams spend weeks collecting manually. But the data sits in different formats, different systems, and different organizational silos. The DevSecOps team does not know which compliance controls their scan results satisfy. The compliance team does not know that the evidence they need already exists in the CI/CD pipeline output from last night's build. The bridge between these worlds does not exist in most organizations. Building it requires understanding how scan findings map to framework controls at a structural level.

The Problem

The core problem is format translation. Scan results are structured data optimized for developer consumption: rule IDs, file paths, line numbers, severity scores, CWE classifications, and remediation suggestions. Compliance evidence is structured around control satisfaction: which requirement is addressed, what defense satisfies it, what proof demonstrates that the defense is operating, and when that proof was collected. These are fundamentally different data models. A SARIF file contains everything an assessor needs to evaluate whether flaw remediation controls are operating, but no assessor reads SARIF files. A compliance spreadsheet contains every control the organization must satisfy, but no scanner outputs compliance spreadsheets. The translation between these formats happens manually, if it happens at all. An engineer runs a scan, reviews the results, identifies which findings are relevant to compliance, exports a summary, reformats it into the evidence template the compliance team requires, and uploads it to the evidence repository. This process takes hours per scan, assumes the engineer understands the compliance framework well enough to identify relevance, and produces a static artifact that begins decaying the moment it is created.

The manual translation problem compounds across assessment cycles. Most organizations operate on quarterly evidence collection cadences. During the collection window, engineers stop their normal work to produce compliance artifacts. They re-run scans specifically for evidence purposes, even though the same scans ran automatically in CI/CD pipelines throughout the quarter. They take screenshots of dashboards that display information already captured in structured scan output. They write narrative descriptions of findings that the scanner already described in machine-readable format. They copy data from one system into another, reformatting it to match the compliance team's template. For organizations managing multiple frameworks, the translation consumes days of engineering time per cycle. Multiply that across the team, then across four cycles a year, and manual scan-to-compliance translation becomes a standing labor cost that produces nothing new. It moves existing data from one format to another.

Evidence decay makes the translation problem worse. A scan result collected in January describes the security posture as it existed in January. By March, the codebase has changed, dependencies have been updated, configurations have been modified, and new services have been deployed. The January evidence is technically accurate for January, but an assessor arriving in April is evaluating the organization's current security posture, not its historical posture. Stale evidence forces re-collection, which means re-running the translation process, which means more engineering time diverted from security work. The fundamental problem is not that scan results cannot serve as compliance evidence. They can. The problem is that the translation from scan output to compliance artifact is manual, expensive, and produces static snapshots that decay immediately. The scan-to-compliance bridge needs to be structural and continuous, not manual and periodic.

Scan Normalization

Security scanners produce output in formats optimized for their specific function. SAST scanners output SARIF (Static Analysis Results Interchange Format) with rule IDs, file paths, line numbers, code snippets, and severity classifications. DAST scanners output JSON or XML reports with HTTP request/response pairs, vulnerability classifications, and exploitation evidence. SCA scanners output dependency trees and SBOMs in formats like CycloneDX, carrying CVE identifiers, affected package versions, fixed versions, and severity scores. Container image scanners output layer-by-layer vulnerability assessments with package manifests and base image provenance. STIG scanners output check results with V-numbers, CCIs, check status (open, not a finding, not applicable), and target system identifiers. Each format contains the information needed for its primary audience. None of them are structured for compliance consumption. The data that an assessor needs exists within these outputs, but it is encoded in scanner-specific schemas that compliance teams cannot parse without translation.

Different formats prevent correlation across scanner types. A SAST finding about insecure deserialization and a DAST finding about the same vulnerability exploited through an API endpoint are two observations of the same security issue, but they share no common identifier, no common format, and no common data model. Without normalization, these findings remain isolated in their respective scanner outputs. The compliance team cannot determine that two scan results address the same control from different perspectives. The DevSecOps team cannot correlate a code-level vulnerability with its runtime manifestation. Each finding exists in isolation, mapped to nothing, correlated with nothing, and contributing to compliance posture only if someone manually identifies the relationship and translates it into the evidence format.

The architecture answers with one fleet and one stream. Vanguard's design names eight scanner classes: code, infrastructure as code, secrets, SBOM, vulnerability, DAST, malware, and cloud posture. Every class is specified to emit findings in one shape rather than a format per tool. Results return to the platform as a single typed event carrying the run reference, the finding count, and the source scan reference, feeding two consumers at once: the trend projector behind Sentinel's scan history, and the finding intake on Rampart's side. That boundary has a name in the architecture: the seam where a scan finding becomes a compliance finding is a designed edge between capabilities, not an accident of export scripts. Imported results have a path of their own. The collection modes include an import lane for scanner output produced outside the platform, and every imported artifact enters marked as tainted: it informs posture computation and never authorizes a ruling by itself. Normalization is the foundation that makes everything downstream possible; without one finding shape, cross-scanner correlation and multi-framework mapping revert to manual work at every step.

Five Strategies

The raw material for high-confidence mapping already exists, published by the authorities themselves. DISA publishes the STIG library and the CCI list beside it: every STIG check resolves to a Control Correlation Identifier, and every CCI resolves to its NIST 800-53 control. Neither link involves interpretation; both are maintained by the organization that publishes the STIGs. MITRE maintains the CWE catalog that SAST findings cite, and published references connect weakness classes to the controls they offend. Framework publishers maintain official cross-walks to and from NIST 800-53: the CMMC Level 2 control set is the NIST 800-171 requirement set, where the published cross-walk is identity, and NIST's OLIR program catalogs cross-framework relationships in machine-readable form. This is the mapping problem's open secret. The hard reference data is public, versioned, and machine-readable. What organizations lack is not the mappings. It is a system that traverses them.

Manual mapping at scale is not merely difficult. The arithmetic is against it. An organization maintaining certifications across CMMC Level 2, FedRAMP Moderate, SOC 2, and ISO 27001 answers to hundreds of unique controls, and a serious scan program produces hundreds of findings per cycle. Every finding-to-control pair is a judgment: is it relevant, is it accurate, is it evidentially sufficient? Multiply the two columns and the judgment matrix runs to tens of thousands of cells. At even a few minutes per cell, the mapping exercise alone would consume more analyst-years than the compliance team has. No organization has that capacity, so no organization does the work. Teams map the obvious relationships, STIG checks to NIST controls, and leave the rest unmapped. Findings that could serve as evidence for dozens of controls across four frameworks are filed against one control or none.

The design gives Rampart's mapping engine five named strategies, and they are an enum in the architecture, not a slide: native, via NIST 800-53, via CSF, cross-walk, and AI-suggested. Native mapping reads a framework in its own structure. The via-800-53 strategy rides the derivation chains, 800-171 and CMMC through their published 800-53 lineage, FedRAMP through its baselines. The via-CSF strategy bridges framework families that share no 800-53 ancestor; the catalog names NIST CSF 2.0 as the mapping bridge by role. Cross-walk mapping consumes the published cross-walks directly. AI-suggested mapping is the last resort, not the headline: a suggested mapping counts toward posture only after a named human confirms it, and the rule is a field on the record, not a policy memo. Three more fields carry the honesty. Strategy records how a mapping was derived; fidelity grades how authoritative that derivation is, from authoritative through published and derived down to AI-suggested; coverage states whether the source satisfies the whole target requirement or part of it, with the uncovered remainder named in writing whenever the answer is partial. A partial mapping never carries full posture weight, and every mapping records its complete path from finding identifier through each intermediate reference to the target control. An assessor reads the result and the chain that produced it.

One Scan, Many Frameworks

The derivation chains between compliance frameworks mean that scan-to-compliance mapping is not a linear relationship. It fans out. Consider the shape of one STIG evaluation against a Linux server. A single check verifies an account-management setting and returns not-a-finding. That check carries its CCI, published by DISA, and the CCI resolves to NIST 800-53 AC-2 (Account Management), a relationship also published by DISA. From AC-2 the published relationships keep resolving: the corresponding NIST 800-171 requirement, the CMMC Level 2 access-control practice built on it, AC-2's place in the FedRAMP Moderate baseline, the SOC 2 logical-access criterion the cross-walks reach, the ISO 27001 Annex A access control. One STIG check. One evidence artifact. Five frameworks advanced, and every link in the chain is published by the authority that owns it rather than asserted by the organization being assessed.

Without structural mapping automation, one scan equals one framework. The DevSecOps team runs a STIG scan and files the results in the CMMC evidence package. The same findings are relevant to FedRAMP, SOC 2, ISO 27001, and NIST 800-53, but no one maps them there because the mapping exercise is manual and the team's current assessment priority is CMMC. The SOC 2 compliance team collects separate evidence for the same controls three months later, re-running scans that already produced the relevant data, re-formatting results into the SOC 2 evidence template, and uploading them to a different evidence repository. The organization pays for the same evidence twice: once in the DevSecOps pipeline and once in the compliance collection cycle. Multiply this redundancy across every framework the organization maintains, and the waste compounds from inefficiency into a material cost center.

Rampart's charter is exactly this projection: multi-strategy mapping with coverage recompute across frameworks, so a finding filed once resolves against each active framework's controls with its own strategy, fidelity, and coverage recorded per relationship. The framework catalogs behind the projection enter as signed reference data on named cadences; NIST 800-53 rev5 arrives as OSCAL JSON, pulled and digest-compared daily, and the STIG library ingests generally, so any STIG DISA publishes is supported through content and CCI mapping with zero engine change. Adding a framework to the portfolio is designed to be an activation, not a project: the evidence already exists, the derivation chains already resolve, and the coverage recompute extends to the new framework's controls. Regulatory change rides the same machinery. The architecture specifies framework-version diffs computed and propagated at ingest, with affected controls, evidence, and customer deltas known on release day. An organization that has carried CMMC Level 2 for two years and now needs SOC 2 is not starting from scratch. It is activating a projection of posture it already holds.

The Pipeline

Point-in-time evidence collection is the root cause of the assessment scramble that every compliance team dreads. The quarterly cycle produces a burst of evidence that is maximally fresh on collection day and progressively stale every day after. By the time an assessor reviews the evidence, weeks or months have passed. The organization cannot prove that the security posture described by the evidence still reflects the running environment. The assessor must either accept stale evidence with reduced confidence or request fresh collection, which delays the assessment. Continuous evidence collection eliminates this problem by treating scan results as a stream rather than a snapshot. Every scan that runs, whether triggered by a CI/CD pipeline, a scheduled job, or a manual execution, produces evidence that enters the compliance mapping pipeline immediately. The evidence is timestamped, integrity-hashed, and filed against every applicable control.

Periodic scans leave evidentiary gaps that are invisible until assessment time. An organization that runs quarterly STIG scans has evidence for four days of the year; every other day is a gap in the evidentiary record. An assessor reviewing that evidence must either accept the implicit assumption that the control operated continuously between scans or flag the control as insufficiently evidenced. For frameworks that require continuous monitoring (NIST 800-53 CA-7, CMMC SI.L2-3.14.6), quarterly scans are structurally insufficient. The framework requires continuous evidence. The organization provides intermittent snapshots. The gap between what the framework demands and what the evidence demonstrates is not a documentation problem. It is an architectural problem with the evidence collection cadence itself.

The architecture makes the cadence itself a designed object. Sentinel owns the trigger surface, and schedules are derived rather than typed in: the schedule record carries its derivation basis field by field, the freshness horizon, the observed change frequency, the connector's quota posture, and the posture weight of what the observation supports. The boundary between capabilities is stated in the design's own terms: Sentinel is designed to schedule and trigger, Vanguard to run the scan, and results return as trends. The scan surfaces meet teams where they already work; the design names three: a local CLI scan, a GitHub Action or GitLab CI step, and Sentinel-scheduled execution. Freshness is law in this architecture rather than aspiration. Every belief carries a freshness horizon, and past that horizon it demotes to contested instead of quietly staying true; a satisfied control whose load-bearing evidence expires moves to other-than-satisfied and emits a re-observation demand, because stale evidence never silently satisfies. Any consumer that would act on a stale belief fails closed. The quarterly scramble is not improved by this design. It is made structurally unnecessary: re-collection is what the system demands of itself, one horizon at a time.

Findings as Evidence

The distinction between a scan finding and a compliance evidence artifact is the metadata that establishes provenance, integrity, and control relevance. A raw scan finding is a data point: this scanner observed this condition on this target at this time. A compliance evidence artifact is that same data point wrapped in provenance metadata that answers the questions an assessor will ask. Who collected it? What scanner configuration was used? What target was scanned? When was the scan executed? Can the result be independently verified? Has the artifact been modified since collection? Which controls does this finding address? What is the mapping provenance for each control relationship? Without this metadata, the finding is security data. With it, the finding is compliance evidence. The transformation from one to the other is the difference between a scan result that sits in a pipeline log and a scan result that satisfies a control requirement during an assessment.

Findings without mapping are wasted data from a compliance perspective. An organization that runs comprehensive security scans but does not map findings to controls possesses the raw material for compliance evidence without possessing the evidence itself. The DevSecOps team knows the codebase has no critical vulnerabilities. The compliance team needs evidence that RA-5 (Vulnerability Monitoring and Scanning) and SI-2 (Flaw Remediation) are operating effectively. Both statements describe the same reality, but the first is expressed in DevSecOps terms and the second in compliance terms. Without the mapping bridge, the compliance team must independently collect evidence for RA-5 and SI-2, even though the DevSecOps team already possesses it in a different format. The finding is not wasted from a security perspective. It is wasted from a compliance perspective because it cannot be consumed by the compliance process without manual translation.

The design attaches that pedigree at the substrate, not in an export step. Findings and the evidence they become ride the platform's event spine, where every organization's events form a SHA-256 hash chain sealed under Merkle checkpoints with a signed root; no unsigned attestation exists in the design, and a modified record is a detected record rather than a quiet one. Collection carries a taint law beside the integrity law: every byte collected from the outside enters marked as tainted, and tainted observation informs posture computation but never authorizes a ruling on its own. On the interpretation side, Rampart's posture record is never a bare verdict; the record carries its basis, the satisfying mapping references and their derivation, as a required field. Documents obey the same rule, computed rather than written: the architecture specifies the SSP and managed documents regenerated from living data, with control narratives a named document kind, so an implementation description cites the mappings and evidence behind it instead of paraphrasing them from memory. And nothing a model infers becomes evidence by itself; an AI-suggested mapping counts toward posture only after a named human confirms it. The assessor's questions about provenance are answered by fields that must exist for the record to exist at all.

The Bridge

The gap between DevSecOps and compliance is not a people problem. Both teams are competent, motivated, and doing their jobs. The gap is a data model problem. DevSecOps teams produce structured security data in scanner-native formats. Compliance teams consume evidence in control-mapped formats. The translation between these formats has historically been manual, expensive, and lossy. Information is lost at every translation step: the SARIF file contains line-level detail that the compliance screenshot does not capture. The scanner configuration metadata is discarded during the manual export. The temporal precision of a continuous scan pipeline is reduced to a quarterly snapshot. Each translation step degrades the evidence from machine-verifiable structured data into a static document that proves less than the original data contained.

The bridge is not a tool that sits between two workflows. It is the elimination of the second workflow entirely. When scan findings are normalized, mapped to controls through deterministic derivation chains, packaged with provenance metadata, and filed against every applicable framework automatically, the compliance team does not need a separate evidence collection process. The evidence arrives through the scan pipeline. The mapping is structural and continuous. The provenance is cryptographic and verifiable. The compliance team's role shifts from evidence collection (a labor-intensive, low-value activity) to evidence validation and posture management (a high-value activity that requires compliance expertise). The DevSecOps team's role does not change at all. They continue running scans, triaging findings, and remediating vulnerabilities. The compliance evidence is a byproduct of their existing workflow, not an additional burden.

The composition is drawn in the architecture as named edges, not marketing arrows. Vanguard's scan results feed Sentinel as trends; Sentinel's collection and change events feed Rampart's posture recompute; and Citadel aggregates what the others produce, posture, alerts, estate, and scan status, four inbound edges to one command surface that displays and never acts. The charter calls the consequence two doors, one spine: an engineer scans on day one with no framework in sight, an assessor starts at the requirement and drills to the evidence, and both stand on the same computed posture. DevSecOps reads a finding with its compliance projection attached. Compliance reads a control with the scan evidence and derivation chain behind it. Neither view is a translation of the other; both are projections of one data model, which is this article's argument arrived at from the far side. The two-team gap was never going to be closed by a better exporter. It closes when there is nothing left to export.