Scan everything. Prove everything.

The Engineer's Door

DevSecOps puts security testing where engineering happens: in the editor, in the commit, in the pipeline. Vanguard is that ground inside the platform: the workbench that holds scan results, pipeline status, and CI/CD integration together. The design holds two doors into one spine. An assessor starts at a requirement and drills down to evidence. An engineer starts at a scan, on day one, with no framework in sight, because nobody should need a framework to get value from finding a live credential in a repository. Vanguard is the engineer's door. Among the capability mnemonics it carries the shortest one: Garrison is what you have, Sentinel is what is happening, Rampart is what you are proving. Vanguard is what you do.

The boundary is written into the architecture as a non-goal: Vanguard is not a code host and not a CI product. It integrates repositories and pipelines; it never replaces them. Code stays on its host. Builds stay in their runners. What crosses into the platform is findings. A security platform that tries to absorb the toolchain converts adoption into migration, and migration is where security programs stall. The design refuses that trade: the pipeline keeps its shape, and the scan step inside it gains a memory.

One Fleet, One Finding Stream

Security scanning fragments by default. A SAST product, a dependency scanner, a DAST service, a container scanner, a secrets tool: each arrives with its own severity scale, its own export format, and its own dashboard. Two of them will disagree about which finding matters more, and the reconciliation lands on whoever owns the spreadsheet. The findings that matter drown in the findings that repeat. Most teams do not lack scanners. They lack one account of what the scanners found.

The architecture specifies a single fleet of signed FIPS scanner images spanning code, infrastructure as code, secrets, SBOM, vulnerability, DAST, malware, and cloud posture. The code class covers static analysis with custom rule support. The IaC class reads Terraform, CloudFormation, Kubernetes manifests, and Dockerfiles before they deploy. Secret detection goes past pattern matching to live-credential validation, so a dead key in a test fixture and an active production secret are different findings. Container scanning covers operating system and application CVEs alongside misconfiguration. Dynamic testing exercises the running surface: cross-site scripting, SQL injection, CSRF, exposed endpoints. A malware class exists because FedRAMP SI-3 demands malicious code protection. Every class emits into one finding stream with one severity model, which is what makes the later compliance projection possible at all.

Signed in Both Directions

Supply chain proof has hard requirements now. An SBOM is expected in two forms for two consumers: SPDX where federal artifacts are filed, CycloneDX where operations teams correlate vulnerabilities against what is running. A VEX record captures the determination that a CVE present in a dependency is not exploitable in context, with the justification attached rather than implied. Build provenance in the SLSA model ties an artifact to the source and pipeline that produced it. The design carries all of these as outputs of the same dependency walk: SBOMs in both formats, VEX-aware vulnerability scanning that suppresses only what a recorded determination says to suppress, and provenance attestation on build artifacts.

The same rigor points in both directions. The fleet is specified to verify customers' artifact attestations, and the scanner images are held to the standard they check: each one signed, carrying its own SBOM and SLSA provenance, built on FIPS-validated base images. The container supply chain is FIPS end to end in the design, which matters in FedRAMP and CMMC environments where an assessor's first question about a tool is its own pedigree.

Scanning the AI Estate

An AI system's security posture does not live only in its code. It lives in model files, system prompts, agent definitions, tool manifests, and the retrieval corpora an agent reads at runtime. None of those are artifacts a classic scanner understands, and most ship with less review than an ordinary pull request. An over-permissive tool manifest grants an agent capabilities nobody audited. A poisoned retrieval corpus changes behavior without changing a line of code. Governance regimes are arriving faster than review practices: NIST AI RMF sets expectations for managing these systems, and NIST AI 600-1 profiles generative AI specifically, while most scanning stacks still end at the container boundary.

The architecture extends the scanner fleet to the AI estate by name: models, prompts, agent definitions, tool manifests, and RAG corpora are scan surfaces beside code and containers, and their findings enter the same stream with the same severity model. An AI company meeting its first governance regime is exactly the buyer this design has in view, and the order holds there as everywhere: the security work comes first, and the framework projection follows from it.

Compliance Scanning

Hardening baselines are where compliance scanning gets concrete. DISA STIGs prescribe exact settings per operating system and application. SRGs state the requirements generally where no STIG exists. CIS Benchmarks cover similar ground for commercial baselines. The difficulty is not running the checks; it is knowing which profile legitimately applies to which target. A STIG result scored against the wrong OS release is noise wearing a severity label, and manual profile selection produces exactly that.

The mechanism asks no profile expertise of the operator. A target arrives as a container image, an Outpost target, or an entry in the Garrison estate. The scanner mounts the filesystem read-only, identifies the base OS from its release record, and selects the best available profile automatically, falling back through the hierarchy when no exact match exists. Results return per V-number with CAT I, II, or III severity and remediation guidance. What Vanguard returns is raw hardening truth. What it means for a framework is Rampart's judgment, made where interpretation belongs.

Three Scan Surfaces

The design names three scan surfaces, and each answers a different trust constraint. The local CLI surface is the developer's terminal: the scanner image runs where the code lives, nothing leaves the machine, and pushing results to the platform is optional and authenticated. The pipeline surface is a GitHub Action or GitLab CI step: the scan executes in your runner, and only results travel upward. No image layers, no filesystem, no source. Posture thresholds enforced at the pipeline ride Sentinel's gate design, so a degrading branch fails its build on policy rather than on someone noticing.

The third surface is Sentinel-scheduled, and the seam is specified precisely: Sentinel derives the cadence and emits the scan trigger; execution belongs to Vanguard's fleet, in ephemeral, tenant-isolated containers with short-lived credentials, destroyed when the run completes. Targets do not have to be systems yet: Outpost holds saved scan targets with trend history, and its graduation pipeline runs Outpost to Garrison estate to Sentinel monitoring when a target becomes real infrastructure. Whatever the surface, results carry in the formats their consumers expect: SARIF toward code review, JUnit toward the pipeline, CycloneDX and SPDX toward supply chain tooling, OSCAL toward assessment automation, JSON and CSV for everything custom.

From Finding to Posture

The composition edges in the architecture are short sentences. Scan results become trends: Vanguard's stream is what Sentinel projects trend lines from. Citadel aggregates scan status beside posture, alerts, and inventory. And findings born from scans drive posture: the intake seam is written into Rampart's locked design. Vanguard owns scan execution, never interpretation. Mapping a finding to a control, scoring it, projecting it across frameworks: that is Rampart's mapping engine, and keeping the boundary clean is what keeps both sides honest.

That engine holds five named mapping strategies: native, via NIST 800-53, via CSF, cross-walk, and AI-suggested. Every mapping records its derivation path, requirement to CCI to NIST 800-53 rev5 control to target practice, and carries a fidelity grade beside it. Partial coverage never carries full posture weight. An AI-suggested mapping counts toward posture only after a human confirms it, and mappings expire on freshness horizons rather than living forever. That is how one scan finding reaches CMMC, SOC 2, and ISO 27001 at once without a mapping anyone has to take on faith: every framework is a projection of one defended implementation, and the derivation is replayable link by link.