Most frameworks ask engineering the same questions: what is in the software, how it was built, who reviewed it, how it was tested and how vulnerabilities are handled. Produce the answers once per release, bound to the artifact digest: an SBOM, signed build provenance, review records, scan results with triage, ASVS verification results and vulnerability-handling records. Index them, map each item to the requirements it supports in each framework, and check the index in CI. Reuse stops at scope: each framework still decides its own boundary, period and judgment.
- Bind every piece of evidence to the artifact digest it is about, so it can be reused across frameworks but never across releases.
- Prefer system-generated evidence for complete populations, such as every merged change in a period, over screenshots and hand-built lists.
- Say “supports”, not “satisfies”: in NIST IR 8477 terms one piece of evidence supports part of a requirement, and the assessor judges the rest.
- Release-based evidence (SBOM, provenance) and period-based evidence (SOC 2 Type 2, ISO surveillance) are different shapes: keep both views.
- OSCAL 1.2.3 (August 2026) can carry the same mapping for GRC tools: component definitions point implemented requirements at evidence, and NIST publishes SP 800-53 5.2.0, CSF 2.0 and SSDF catalogs in OSCAL.
- Run the crosswalk check for the latest release in CI and confirm it fails when any evidence names a different digest.
- Pick one requirement per framework from the CSV and open the evidence it cites; confirm it covers the requirement's scope, not just its topic.
- Confirm SBOM and provenance attestations verify against the release image digest with your signature policy.
- Validate the OSCAL component definition against the schema of the OSCAL release it declares.
- For a SOC 2 or ISO period, confirm every release in the period has an evidence index.
- Applies to
- NIST SP 800-218 (SSDF) 1.1
- PCI DSS v4.0.1
- ISO/IEC 27001 2022
- AICPA Trust Services Criteria 2017, revised points of focus 2022
- OSCAL 1.2.3 component definition schema; oscal-content v1.5.0 catalogs
Teams answering more than one framework, audit or regulation for the same product. Mappings are this site's analysis; each framework's assessor decides what evidence is sufficient.
- Part of
- Learning path: Build an evidence-driven security program (step 4 of 11). Workflow: Build an AppSec program
Learning goals and prerequisites
What you will learn
- Describe what makes engineering evidence reusable: bound to an artifact, system-generated, complete and retained.
- Map each piece of evidence to the requirements it supports in SSDF, PCI DSS, ISO/IEC 27001, SOC 2 and the CRA without claiming equivalence.
- Keep an evidence index that CI checks against the release, export it as CSV and publish it as OSCAL.
Before you start
Platform, AppSec and compliance engineers who answer several frameworks and audits for the same product
- Know which frameworks and audits your product answers to, and their scopes.
- Know where your pipeline stores SBOMs, attestations, scan results and review records.
Refresh first: Control mapping between frameworks: state the relationship without overstating equivalence
Go to the guided practiceOne evidence set, several assessors
- Produce once per releaseThe pipeline produces the SBOM, signed provenance, review export, scan results with triage and the ASVS record, each naming the release’s artifact digest.
- Index and checkThe evidence index lists each item, where it is stored and the requirements it supports; CI fails when an item is about another digest or names an unknown framework.
- Export the crosswalkThe check writes one CSV row per framework requirement with the relationship “supports”, the evidence and the digest; an OSCAL component definition carries the same mapping for GRC tools.
- Share the same factsThe PCI assessor, SOC 2 auditor, ISO certification body and the CRA technical documentation draw on the same records; for a period audit, export the population across every release in the period.
- Judge within each scopeEach assessor decides whether the evidence is sufficient for its own scope, period and requirement; the system description, Statement of Applicability, report on compliance and technical documentation are still separate.
A team that answers SSDF attestation questions, a PCI DSS assessment, an ISO/IEC 27001 surveillance audit, a SOC 2 Type 2 examination and EU Cyber Resilience Act documentation is asked the same things five ways. Collecting evidence separately for each multiplies work, and the copies drift: the SOC 2 sample shows one approval rule, the PCI assessor sees another. One set of evidence, produced by the pipeline for each release and indexed once, gives every assessor the same facts. /frameworks/secure-software-attestation-form/ shows the same approach for a US federal attestation request, statement by statement.
The mapping layer is where teams overclaim. A crosswalk row that says an SBOM “meets” PCI DSS 6.3.2 hides that the requirement is about an inventory of bespoke and custom software and its components, which the SBOM supports only for the applications it covers. Use the relationship vocabulary from /frameworks/control-mapping-and-evidence/: evidence supports a requirement, within a stated scope.
- Bound to an artifact: it names the digest of the image or package it is about, so a reviewer can tell which release it describes.
- System-generated: exported by the system that enforced the control, such as the repository, CI or identity provider, not assembled by hand.
- Complete: for population evidence, every item in the period or release, so an auditor can sample from it.
- Timestamped and retained for the longest period any framework needs, such as a SOC 2 period or a CRA support period.
- Immutable where possible: signed attestations stored with the artifact, so evidence can't be edited after the fact.
- Owned: one named owner per kind of evidence, who notices when it stops being produced.
The table maps six kinds of evidence to the requirements they support. Read each cell as “supports, within the scope the evidence covers”, never “satisfies on its own”: each requirement also has process, scope and frequency expectations the evidence doesn't show. A dash means no direct relationship worth claiming.
| Evidence | SSDF 1.1 | PCI DSS v4.0.1 | ISO/IEC 27001:2022 | SOC 2 | EU CRA | Others |
|---|---|---|---|---|---|---|
| SBOM per release | PS.3.2 | 6.3.2 | 8.8 | CC7.1 | Annex I Part II(1) | FDA 524B(b)(3); UK Code 1.2; ASVS v5.0.0-15.1.2 |
| Signed build provenance | PS.2.1, PS.3.1 | — | 8.32 | CC8.1 | Annex I Part II(7) | UK Code 3.1; SP 800-53 SR-4 |
| Review records: merged changes with independent approval | PW.7.2 | 6.2.3, 6.2.3.1, 6.5.1 | 8.28, 8.32 | CC8.1 | Annex I Part II(3) | NIS2 Implementing Regulation 2024/2690 annex 6.4 |
| Scan results with triage decisions (SAST, SCA, DAST) | PW.7.2, PW.8.2, RV.1.2 | 6.2.4, 6.3.1 | 8.8, 8.29 | CC7.1 | Annex I Part II(3) | 2024/2690 annex 6.5; FDA cybersecurity testing |
| ASVS verification record | PW.8.2 | 6.2.4 | 8.26, 8.29 | — | Annex I Part I(2) | — |
| Vulnerability handling: intake, triage, VEX, advisories, fixes | RV.1, RV.2, RV.3 | 6.3.1, 6.3.3 | 8.8 | CC7.1, CC7.3, CC7.4 | Annex I Part II(2), (4) to (8); Art. 14 | NIS2 Art. 21(2)(e); FDA 524B(b)(1), (b)(2); UK Code 3.2 to 3.5 |
Keep an index per release that names each piece of evidence, the digest it is about, where it is stored and the requirements it supports, as framework-prefixed identifiers. The SBOM and provenance live as signed attestations next to the image (/domains/supply-chain/sbom/generate-release-inventory/ and /domains/supply-chain/provenance/read-and-verify-slsa/ cover producing and checking them); review exports and scan results live in your evidence store under the release version. In the example the ASVS record is about the previous release's image, which the check below catches.
{
"release": {
"product": "payments-api",
"version": "4.12.0",
"digest": "sha256:9f2c4e7d1b8a6f3e5c0d2a4b7e9f1c3d5a7b9e1f3c5d7a9b1e3f5c7d9a1b3e5f"
},
"evidence": [
{
"id": "E-SBOM",
"kind": "CycloneDX 1.6 SBOM",
"subject": "sha256:9f2c4e7d1b8a6f3e5c0d2a4b7e9f1c3d5a7b9e1f3c5d7a9b1e3f5c7d9a1b3e5f",
"location": "attestations/4.12.0/sbom.cdx.json",
"claims": [
"SSDF:PS.3.2",
"PCI:6.3.2",
"CRA:AnnexI-II-1",
"ASVS:v5.0.0-15.1.2",
"UKCoP:1.2"
]
},
{
"id": "E-PROV",
"kind": "SLSA v1.2 build provenance, signed",
"subject": "sha256:9f2c4e7d1b8a6f3e5c0d2a4b7e9f1c3d5a7b9e1f3c5d7a9b1e3f5c7d9a1b3e5f",
"location": "attestations/4.12.0/provenance.intoto.jsonl",
"claims": [
"SSDF:PS.2.1",
"SSDF:PS.3.1",
"UKCoP:3.1",
"SP800-53:sr-4"
]
},
{
"id": "E-REVIEW",
"kind": "Change population: merged pull requests with independent approvals",
"subject": "sha256:9f2c4e7d1b8a6f3e5c0d2a4b7e9f1c3d5a7b9e1f3c5d7a9b1e3f5c7d9a1b3e5f",
"location": "evidence/4.12.0/changes.csv",
"claims": [
"SSDF:PW.7.2",
"PCI:6.2.3",
"ISO27001:8.32",
"SOC2:CC8.1"
]
},
{
"id": "E-SCAN",
"kind": "SAST, SCA and DAST results (SARIF 2.1.0) with triage decisions",
"subject": "sha256:9f2c4e7d1b8a6f3e5c0d2a4b7e9f1c3d5a7b9e1f3c5d7a9b1e3f5c7d9a1b3e5f",
"location": "evidence/4.12.0/scans/",
"claims": [
"SSDF:PW.8.2",
"PCI:6.2.4",
"ISO27001:8.29",
"SOC2:CC7.1",
"CRA:AnnexI-II-3"
]
},
{
"id": "E-ASVS",
"kind": "ASVS 5.0.0 level 2 verification record for the release",
"subject": "sha256:0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c",
"location": "evidence/4.11.0/asvs-l2.json",
"claims": [
"ASVS:v5.0.0-L2",
"ISO27001:8.26",
"PCI:6.2.4"
]
}
]
}The script rejects evidence about another artifact and claims with an unknown framework prefix, then writes the crosswalk as CSV: one row per framework requirement, with the relationship, the evidence and the digest. Give the CSV to assessors and import it into GRC tools; regenerate it for every release instead of editing it. For the index above it exits non-zero and reports E-ASVS: about another artifact, not 4.12.0: rerun the ASVS verification on 4.12.0, or record why the 4.11.0 result still holds and have the assessor accept it. The /labs/release-evidence/ lab practices the same selection rule.
"""Check an evidence index against its release and export the crosswalk as CSV.
Every evidence item must be about the release's own artifact digest, so evidence from another
build can't be reused by accident, and every claim must name a known framework.
Usage: python3 crosswalk.py evidence-index.json > crosswalk.csv
"""
import csv
import json
import sys
FRAMEWORKS = {
"SSDF": "NIST SP 800-218 SSDF 1.1",
"PCI": "PCI DSS v4.0.1",
"ISO27001": "ISO/IEC 27001:2022 Annex A",
"SOC2": "AICPA Trust Services Criteria (2017, rev. 2022)",
"CRA": "Regulation (EU) 2024/2847",
"ASVS": "OWASP ASVS 5.0.0",
"UKCoP": "UK Software Security Code of Practice (2025)",
"SP800-53": "NIST SP 800-53 Rev. 5, release 5.2.0",
}
with open(sys.argv[1], encoding="utf-8") as f:
index = json.load(f)
release = index["release"]
problems, rows = [], []
for item in index["evidence"]:
if item["subject"] != release["digest"]:
problems.append(f"{item['id']}: about another artifact, not {release['version']}")
continue
for claim in item["claims"]:
framework, _, requirement = claim.partition(":")
if framework not in FRAMEWORKS or not requirement:
problems.append(f"{item['id']}: unknown claim {claim!r}")
continue
# The evidence supports the requirement for this release; it never satisfies it alone.
rows.append([FRAMEWORKS[framework], requirement, "supports", item["id"], item["kind"],
release["version"], release["digest"], item["location"]])
out = csv.writer(sys.stdout)
out.writerow(["framework", "requirement", "relationship", "evidence", "kind", "release", "digest",
"location"])
out.writerows(sorted(rows))
print("\n".join(problems) or f"{len(rows)} mappings for {release['version']}", file=sys.stderr)
sys.exit(1 if problems else 0)OSCAL, NIST's machine-readable format for control information, was at release 1.2.3 (7 August 2026). A component definition describes what a component implements against a catalog, and each implemented requirement can link to its evidence. NIST's oscal-content repository publishes the catalogs for SP 800-53 Rev. 5 (release 5.2.0), CSF 2.0 and SSDF, so source can point at a pinned version. OSCAL 1.2.0 added a control mapping model for crosswalks between catalogs, with relationship types and matching rationales aligned with NIST IR 8477.
{
"component-definition": {
"uuid": "817751cc-b5a9-4f9d-9886-b6aba6fdf1a6",
"metadata": {
"title": "payments-api 4.12.0: secure development evidence",
"last-modified": "2026-10-10T09:00:00Z",
"version": "4.12.0",
"oscal-version": "1.2.3"
},
"components": [
{
"uuid": "48066ece-9670-4771-8355-e9b4859435a8",
"type": "software",
"title": "payments-api",
"description": "Payments API service, release 4.12.0, image digest sha256:9f2c4e7d...",
"control-implementations": [
{
"uuid": "e72f3396-cff3-491a-979e-112f47ccbd7b",
"source": "https://raw.githubusercontent.com/usnistgov/oscal-content/v1.5.0/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_catalog.json",
"description": "SP 800-53 Rev. 5 (release 5.2.0) developer controls this release has evidence for.",
"implemented-requirements": [
{
"uuid": "eff19ef4-7a08-4eea-beeb-11fedeac9e68",
"control-id": "sa-11",
"description": "Developer testing: SAST, SCA and DAST run on every build; results triaged before release.",
"links": [{"href": "evidence/4.12.0/scans/", "rel": "reference", "text": "E-SCAN"}]
}
]
},
{
"uuid": "c303dbd3-a19e-44c5-aa46-7844d1429ae0",
"source": "https://raw.githubusercontent.com/usnistgov/oscal-content/v1.5.0/nist.gov/SP800-218/ver1/json/NIST_SP800-218_ver1_catalog.json",
"description": "SSDF 1.1 tasks this release has evidence for.",
"implemented-requirements": [
{
"uuid": "0bc9ba51-d29d-42f3-b256-0a18fde071f3",
"control-id": "PW.8.2",
"description": "Tests scoped, designed, run and documented; findings recorded in the team's tracker.",
"links": [{"href": "evidence/4.12.0/scans/", "rel": "reference", "text": "E-SCAN"}]
}
]
}
]
}
]
}
}Validate against the JSON schema published with the same OSCAL release, oscal_component_schema.json from the v1.2.3 release assets. The schema checks structure, required fields and UUID formats; it doesn't check that a control ID exists in the referenced catalog, so check those against the catalog the way the CSF profile check in /frameworks/nist-csf-2-for-product-teams/ does.
// Validate an OSCAL document against the JSON schema published with the same OSCAL release.
// npm install ajv@8
// node validate-oscal.mjs oscal_component_schema.json component-definition.json
import {readFileSync} from 'node:fs';
import Ajv from 'ajv';
const [schemaFile, documentFile] = process.argv.slice(2);
const read = file => JSON.parse(readFileSync(file, 'utf8'));
// Formats such as date-time need the ajv-formats plugin; without it they are not checked.
const ajv = new Ajv({strict: false, allErrors: true, validateFormats: false});
const validate = ajv.compile(read(schemaFile));
if (!validate(read(documentFile))) {
console.error(validate.errors);
process.exit(1);
}
console.log('valid');Evidence is shared; scope and judgment are not. A SOC 2 Type 2 opinion covers a system for a period; an ISO/IEC 27001 certificate covers an ISMS scope; PCI DSS covers the cardholder data environment and what can affect it; the CRA covers a product's conformity; an FDA submission covers one device. Each still needs its own documents, such as the system description, the Statement of Applicability, the PCI report on compliance, the CRA technical documentation and the premarket submission, and each assessor decides whether your evidence is sufficient for their scope.
Release-based evidence also has to be turned into period-based evidence for audits that test a period. Keep the per-release indexes, and for a SOC 2 or ISO period export the population across all releases in it, so a sampled change can be traced to its release's evidence.
Guided practice
Your GRC lead drafted a crosswalk for checkout-web 7.3.0 to send to the PCI assessor, the SOC 2 auditor and the ISO certification body. Review the rows before it goes out.
Supplied scenario material
Draft crosswalk, checkout-web 7.3.0 (fictional), SOC 2 period 2026-01-01 to 2026-06-30
R1 SBOM (CycloneDX) for checkout-web 7.3.0 -> PCI 6.3.2 "satisfied"; the loyalty service, also bespoke and in the CDE, has none.
R2 Secure coding training slides (2025) -> ISO 27001 8.28 "satisfied"; SAST runs but is advisory.
R3 PR export from the checkout-web repository -> SOC 2 CC8.1 "satisfied"; production also changes through the
infrastructure repository and a database migration tool.
R4 ASVS 5.0.0 level 2 record for 7.3.0 -> PCI 6.2.4 "equivalent".
R5 SBOM listing top-level dependencies only -> CRA Annex I Part II(1) "supports".
R6 Scan results exist for releases shipped in January, February and June; none for March to May.1. Fix the PCI inventory row
Judge R1.
Expected result and reasoning
PCI DSS 6.3.2 asks for an inventory of all bespoke and custom software and its third-party components. One application's SBOM supports the requirement for that application only; the loyalty service leaves a gap. Change "satisfied" to "supports, checkout-web only" and generate an SBOM for the loyalty service before the assessment.
2. Replace the training evidence
Judge R2.
Expected result and reasoning
Training supports 8.28 and PCI 6.2.2, but it doesn't show secure coding is applied. Map the operating evidence instead: the review records and SAST results, and make SAST block merges so the result means something. Until then mark 8.28 as partly supported.
3. Complete the change population
Judge R3 for the SOC 2 period.
Expected result and reasoning
CC8.1 covers changes to infrastructure, data, software and procedures. A population from one repository misses infrastructure changes and database migrations, so the auditor can't rely on its completeness. Export all three sources for the whole period and reconcile them with deployment logs.
4. Correct the relationship words
Judge R4 and R5.
Expected result and reasoning
R4 overclaims: an ASVS record supports PCI 6.2.4 for the attack classes its requirements test, but the two aren't equivalent, since 6.2.4 also expects coding standards, training and enumeration controls. Say "supports" with the scope. R5 is fair: Annex I Part II(1) asks for an SBOM covering at least the top-level dependencies, so the SBOM supports it; note that CISA's minimum elements and FDA ask for more if those apply.
5. Close the evidence gap
Decide what R6 means for SOC 2 and what to change.
Expected result and reasoning
Three months without scan evidence means CC7.1 detection can't be shown to have operated for half the period, which is likely an exception whatever the reason. Fix the pipeline so every release stores its scan results with its evidence index, alert when a release has none, and tell the auditor about the gap rather than letting them find it.
The product and crosswalk are fictional. Mappings are this site's analysis; each assessor decides sufficiency for their framework.
Save a draft on this device to resume later. Automatic saving begins after you choose Save. Drafts are never sent by this application; use synthetic data.
No draft saved on this device yet.
Sources & further reading
The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.
- NIST IR 8477: Mapping Relationships Between Documentary Standards, Regulations, Frameworks, and Guidelines. February 2024.
- NIST SP 800-218: SSDF 1.1. Version 1.1 (February 2022).
- PCI SSC document library: PCI DSS v4.0.1. v4.0.1 (June 2024).
- AICPA: 2017 Trust Services Criteria (with revised points of focus, 2022)
- Regulation (EU) 2024/2847 (Cyber Resilience Act), Annex I
- OSCAL release v1.2.3 (7 August 2026), with JSON schemas
- OSCAL v1.2.3 control mapping model reference. v1.2.3.
- usnistgov/oscal-content v1.5.0: NIST catalogs in OSCAL
- OWASP ASVS 5.0.0, V15 Secure Coding and Architecture (requirement 15.1.2). Version 5.0.0.
Reference information
- SDLC phase
- ReleaseSecurity program