APP-012 Software Integrity Verification
Description
Mechanisms are in place to verify the integrity of software, firmware and configuration artefacts in the build and deployment pipeline. Build artefacts are signed and signatures are verified at deployment. Unexpected changes to deployed software are detected and alerted. A detected integrity violation triggers a response defined in advance for the affected component: halting it, restarting it from a verified artefact or applying another stated control, and the response taken is recorded with the alert. The software supply chain is auditable.
Rationale
A compromised build pipeline or a tampered dependency can put malicious code into production undetected, and integrity verification is the technical control that catches or prevents it. Detection alone leaves the compromised component serving traffic for as long as it takes a person to read the alert, which at night is the whole night. Binding a response in advance moves the judgement to a calm moment and keeps the choice between halting a component and letting it run from being made under pressure.
Applicability (9 profiles)
The deployer's own pipeline. Integrity of the product's releases is the provider's.
The deployer's own pipeline. Integrity of the product's releases is the provider's.
Framework Mappings (23)
| CCC-04 | Unauthorized Change Protection | full |
| MDS-02 | Model Artifact Scanning | informative |
| MDS-08 | Model Integrity Checks | partial |
| MDS-09 | Model Signing/Ownership Verification | partial |
| MDS-13 | Secure Model Format | informative |
| CCC-04 | Unauthorized Change Protection | full |
| HIPAA-164.312.c.2 | Mechanism to Authenticate Electronic Protected Health Information | informative |
| 8.29 | Security testing in development and acceptance | informative |
| AML.M0013 | Code Signing | partial |
| AML.M0014 | Verify AI Artifacts | partial |
| NIS2-CIR-6.6 | Security Patch Management | informative |
| CM-14 | Signed Components | full |
| SA-10 | Developer Configuration Management | partial |
| SI-7 | Software, Firmware, and Information Integrity | full |
| SI-7(1) | Software, Firmware, and Information Integrity | Integrity Checks | full |
| SI-7(2) | Software, Firmware, and Information Integrity | Automated Notifications of Integrity Violations | full |
| SI-7(5) | Software, Firmware, and Information Integrity | Automated Response to Integrity Violations | full |
| SI-7(7) | Software, Firmware, and Information Integrity | Integration of Detection and Response | partial |
| SR-9 | Tamper Resistance and Detection | partial |
| ASI04 | Agentic Supply Chain Vulnerabilities | partial |
| LLM04 | Supply Chain | informative |
| LLM05 | Data and Model Poisoning | informative |
| CC6.8 | Controls to Prevent or Detect and Act Upon the Introduction of Unauthorized or Malicious Software | partial |
Evidence (3)
Build pipeline and signing configuration showing that build artefacts are signed and that signature verification is enforced at deployment.
Example: CI/CD pipeline configuration (e.g. GitHub Actions workflow) showing a code-signing step using Sigstore/Cosign, Notary, or GPG, and a deployment step that verifies the signature before pushing to production. Container registry policy (e.g. AWS ECR image scanning + signing policy) showing unsigned images are rejected.
Test: Review the CI/CD pipeline signing configuration and deployment policy. Verify: (1) every production build artefact (container image, binary, or package) is signed using an approved mechanism, (2) the deployment pipeline verifies the signature before deployment and fails if verification fails, confirmed by reviewing the pipeline failure behaviour, (3) container registry or artefact repository is configured to reject unsigned artefacts.
File integrity monitoring or runtime integrity tool output confirming that deployed software has not been tampered with since the signed build.
Example: AWS Security Hub findings for CodeArtifact integrity checks, Falco runtime security alert log, Wiz or Lacework runtime report, or equivalent tool output showing no integrity violations detected in the deployed production environment over the last 30 days.
Test: Request the most recent integrity monitoring report or alert log for the production environment. Verify: (1) the monitoring tool is active on all production compute resources, (2) no unresolved integrity violation alerts are open, (3) alerts are configured to notify the security team within a defined response time, (4) the last 30 days show no unexplained integrity events.
Integrity violation response configuration showing the response bound to each violation class and the components it applies to.
Example: Runtime integrity policy export, production clusters, 2026-08-12
Test: Export the integrity violation response configuration. Verify: (1) each violation class the tooling can raise has a response bound to it rather than an alert alone, (2) the response for a production workload is one of halting, restarting from a verified artefact or another stated control, (3) a violation induced in a controlled test triggered the bound response within the stated time, (4) the response taken is written to the alert record, (5) any component excluded from automated response carries a recorded justification and a compensating detection path.
Questions (2)
Are build artefacts cryptographically signed?
Signing and verification must both be in place and automated. Signing without verification provides no meaningful protection. Unsigned artefacts should be rejected by the deployment pipeline.
Which software integrity controls are in place in your build and deployment pipeline?
Options run from the most commonly in place to the least. Signing plus verification at deployment is the baseline; signing without verification protects nothing. For the bound response, count only an action the tooling takes on its own, not a runbook step a responder follows after reading an alert.