Compliance mapping
Every audit rule is mapped to the compliance controls it produces evidence toward. A finding weakens the evidence for the controls it maps to; a clean run is evidence the control's practice is present. This page is the full control-by-control reference. For how the audit itself works, see the audit docs.
Evidence toward controls, not an attestation.A clean audit is not a certification, and pipeline activity evidences only part of any standard — the secure-development, change-management, vulnerability, testing, and capacity controls. Organisational, people, and physical controls are out of scope. Mappings marked partial are evidence toward a control without fully exercising it.
Standards and scope
Standards fall into two classes. Scope-universal standards apply to any software pipeline and are mapped on every repository. Scope-conditionalstandards apply only to a declared context — ISO 42001 to repositories that build AI systems, PCI-DSS to those in cardholder-data-environment scope — and surface on the audit page once a repository is declared in that scope. SOC 2 mapping is planned.
ISO/IEC 27001:2022
Live13 controls evidenced by 23 detectors.
| Control | Evidenced by |
|---|---|
| 5.3Segregation of duties |
|
| 5.17Authentication information |
|
| 5.21Managing information security in the ICT supply chain |
|
| 5.32Intellectual property rights |
|
| 8.2Privileged access rights |
|
| 8.4Access to source code |
|
| 8.6Capacity management |
|
| 8.8Management of technical vulnerabilities |
|
| 8.24Use of cryptography |
|
| 8.25Secure development life cycle |
|
| 8.28Secure coding |
|
| 8.29Security testing in development and acceptance |
|
| 8.32Change management |
|
NIST SSDF (SP 800-218 v1.1)
Live13 controls evidenced by 19 detectors.
| Control | Evidenced by |
|---|---|
| PO.4Define and use criteria for software security checks |
|
| PO.5Implement and maintain secure environments for software development |
|
| PS.1Protect all forms of code from unauthorized access and tampering |
|
| PS.2Provide a mechanism for verifying software release integrity |
|
| PS.3.2Maintain provenance data for each software release (SBOM) |
|
| PW.4Reuse existing, well-secured software |
|
| PW.5Create source code by adhering to secure coding practices |
|
| PW.6Configure the build process to improve executable security |
|
| PW.7Review and/or analyze human-readable code |
|
| PW.7.1Perform human code review |
|
| PW.7.2Use automated tools to analyze code |
|
| PW.8Test executable code to identify vulnerabilities |
|
| RV.1Identify and confirm vulnerabilities on an ongoing basis |
|
ISO/IEC 42001
Scope-conditional2 controls evidenced by 8 detectors. Surfaced on the audit page once this pipeline builds or deploys an AI system.
| Control | Evidenced by |
|---|---|
| A.6.2.4AI system verification and validation |
|
| A.6.2.5AI system deployment |
|
PCI-DSS v4.0
Scope-conditional7 controls evidenced by 17 detectors. Surfaced on the audit page once this pipeline is in PCI cardholder-data-environment scope.
| Control | Evidenced by |
|---|---|
| 6.2.3Bespoke and custom software reviewed prior to release |
|
| 6.2.3.1Code review by automated tools and/or manual review |
|
| 6.2.4Software engineering techniques prevent common attacks |
|
| 6.3.1Security vulnerabilities identified and managed |
|
| 6.3.2Inventory of bespoke and custom software components maintained |
|
| 6.5.1Changes managed via formal change-control procedures |
|
| 6.5.2PCI DSS requirements verified after a significant change |
|
SOC 2
SOC 2 (Trust Services Criteria) mapping is planned. Change management (CC8.1) and system operations / monitoring (CC7.x) are the expected anchors. Not yet available.
Using the mapping
On the audit page, each finding shows the controls it maps to. Filter findings by standard with the Standard filter, and on Business see a per-standard coverage roll-up. The same data is available via the public API (a standard filter plus a controls array on each finding) and the MCP server.