Proof

What the assessor receives.

Reference-stack artifacts · client originals stay with the clients who paid for them

Why this page exists

Every shop in this market claims audit-readiness. The claim costs nothing to make, so it carries no information. What carries information is the artifact: the thing that lands in an assessor’s inbox, in the format they read it in.

Everything below is emitted by the reference stack — a demo organisation running the same pipeline, the same scanners and the same controls we field for clients. No client artifact appears on this page. What is on display is the shape — which is the part you are actually trying to evaluate.

Evidence pack

The export the pipeline produces on demand. Not assembled the week before the audit — emitted by the same build that ships the code.

evidence pipeline · drawn from the capture below

validate 5
- Source checkout
- Pipeline hardening checkCC7.1
- Infrastructure-as-code validationCC8.1
- Secrets scanCC6.2
- Test environment setup
static scan 6
- Dependency vulnerability scanCC7.1
- Infrastructure misconfiguration scanCC6.1
- Policy-as-code evaluationCC6.3
- Static code analysisCC7.1
- Software bill of materialsCC7.1CC8.1
- Vulnerability matchingCC7.1
live infrastructure 4
- Audit-trailed deployCC8.1
- Rollback and monitoring baselineA1.2
- Live configuration assessmentCC6.1CC6.6
- Deploy policy checkCC6.1CC6.7CC8.1
DoD compliance 1
- DoD host benchmarkCC7.1A1.2
emit evidence 1
- Package evidence
evidence-2026-05-13.zip

Pipeline run: 17 jobs across 5 stages — validate, static-scan,
live-infra-scan, dod-compliance-scan, emit-evidence — each job
line annotated with the control it satisfies, ending in
evidence-2026-05-13.zip built as a build artifact. — 17 jobs, 5 stages. Every green line names the control it satisfies — CC6.1 through A1.2 — and the last stage zips the lot into `evidence-2026-05-13.zip` as a build artifact.

Control-to-artifact inventory

The index an assessor opens first: a control, the artifact that proves it, when that artifact was last emitted, and by which job. Controls and infrastructure point at each other rather than describing each other.

control inventory · drawn from the capture below

10 / 10 traced

control	emitted by
CC6.1	misconfiguration scanlive configuration assessment
CC6.2	secrets scan
CC6.3	policy-as-code evaluation
CC6.6	live configuration assessment
CC6.7	audit-trailed deploy
CC7.1	dependency scanvulnerability matchingDoD host benchmark
CC7.2	rollback and monitoring baseline
CC8.1	audit-trailed deploy
CC9.2	monthly drift review
A1.2	DoD host benchmark

Evidence pack inventory table: ten controls from CC6.1 to A1.2,
each with its artifact filename, last-emitted date and a green
status pill, followed by the pipeline job each row is produced
by. — Ten controls, all green, each row traced back to the job that emits it. `Status` is green only while that build is green — nothing here is retrospective.

Monthly audit merge request

What the retainer produces every month: drift found by the scanners, the fix as a diff, and a merge that is itself the attestation. No memo, no console screenshot, no consultant assembling a binder in month eleven.

drift, fixed · drawn from the capture below

caughtHIGH · firewall rule in sg.tf open to 0.0.0.0/0
fixedSSH scoped to a trusted management CIDR
mergedreviewer approval, timestamped · control CC6.1
re-scanned0 high · 0 critical

Merge request titled chore(security): drift remediation 2026-05.
A findings table lists a HIGH misconfiguration finding and six
failed policy-as-code checks, followed by the Terraform diff that
scopes bastion SSH from 0.0.0.0/0 to a trusted management CIDR,
and a re-scan showing zero high or critical findings. — CC6.1 drift detected in `sg.tf`, remediated, and linked to the pack it was found in. The reviewer approving this merge makes a timestamped, cryptographically identified assertion — that record is the audit evidence.

Host baseline — DISA STIG

The DoD layer. A host benchmark evaluates the server against the DISA STIG and CIS profiles on every run, and the report ships inside the same pack as the cloud evidence.

server hardening · drawn from the capture below

Rule results DISA STIG · 71 evaluated

passed 63
failed 8

Failed, by severity of 8

high 2

medium 6

63 passed, 8 failed, severity broken out — published as it comes out of the scanner. A baseline with no failures on first evaluation is a baseline nobody ran.

One method, many bodies

The through line under the four artifacts above. A control is implemented once; a framework is a reader of it. The pack is not rebuilt per body — the same run answers to each in that body’s own numbering, which is why adding a framework costs a mapping and not a project.

one method, many audits · drawn from the capture below

register	SOC 2	NIST 800-53	FedRAMP	DoD IL2–5
control walk10 SCF controls	10 / 10mapped	10 / 10mapped	not read	not read
cloud scan1 run	17requirements	177requirements	45requirements	not read
host benchmark1 datastream	CC7.1 · A1.2controls	not read	not read	63 / 8STIG pass / fail
one checkS3 object versioning	4criteria	17controls	5controls	not read

From the crosswalk on the proof page · FedRAMP read at Moderate rev 4 · DoD read at the host layer

Compliance crosswalk in four registers. First the declared
mapping: ten Secure Controls Framework controls walked out to
NIST 800-53 and SOC 2, each naming the artifact that implements
it. Then one SCAP datastream evaluated under the DISA STIG and
CIS profiles with different totals. Then one cloud scan
evaluated against eight frameworks in the same run, with
requirements, pass, fail and manual counts per body. Then the
same 30 checks shown to be referenced by 44 frameworks, and a
single check followed across twelve bodies in each one’s
own requirement numbering. — Four registers: the declared SCF walk, one host benchmark read as DISA STIG and as CIS, one cloud scan evaluated against eight frameworks at once, and one check — S3 object versioning on the evidence bucket — followed across every body that claims it.

We map through the community Secure Controls Framework, then walk SCF → NIST 800-53 → SOC 2. NIST’s Online Informative References and the CSA Cloud Controls Matrix are the alternatives we evaluated against it. Only the first register is our assertion, and every row of it names an artifact the pipeline emits — the rest is scanner output. The eight-body evaluation is one scan read eight ways, not eight scans, which is the whole economic claim: a new framework costs a mapping, not a project.

What these artifacts cover

boundary	FedRAMP High · DoD IL2–IL5 · SOC 2 · NIST 800-53 / 800-171
portability	One codebase shipping commercial cloud and air-gapped on-premises by an identical process

Scope, not scoreboard. Throughput figures — build times, engineer-days recovered — belong to the engagements that produced them, and those are named with dates on the team page. This page is for artifacts.

What is not here

A client’s artifact, and we will not send one. A shop that shows you another client’s evidence pack is telling you exactly what it will do with yours. The pages above are the reference stack, which is ours to publish.

What we will do is walk you through it live. The first ten minutes of every fit check is a demonstration of this pipeline running — and under an NDA, we can go further.

Book a 30-minute fit check

Ten minutes of us showing you something real we built or fixed. Twenty minutes on your pipeline and your compliance deadline — and a straight answer on what you need, including when the answer is nothing from us.

Pick a time