SI-7: Software, Firmware, and Information Integrity

Quick-reference card

What this control requires

SI-07 requires organizations to deploy integrity verification tools that detect unauthorized changes to software, firmware, and information. This control sits within the system and information integrity family and applies to any environment where code, configurations, or data could be tampered with before, during, or after deployment.

In practice, meeting this requirement means you need mechanisms that continuously validate the integrity of critical assets against known-good baselines. These mechanisms include cryptographic hashes, parity checks, cyclical redundancy checks, and file integrity monitoring tools that can flag modifications automatically. The scope is broad. It covers operating system kernels, drivers, middleware, application binaries, firmware interfaces like Unified Extensible Firmware Interface (UEFI) and Basic Input/Output System (BIOS), personally identifiable information (PII), and metadata containing security or privacy attributes.

Detection alone isn’t enough. You also need predefined response actions for when unauthorized changes surface. That could mean quarantining a compromised binary, alerting your security operations team, triggering an automated rollback, or halting a deployment pipeline. Without both halves of this control, detection and response, you’re left with visibility into a problem you can’t contain. The NIST SP 800-53 framework treats SI-07 as a baseline requirement at MODERATE and HIGH impact levels because the consequences of undetected tampering reach far beyond a single system.

Why it matters

Software integrity failures are among the hardest attacks to detect because the malicious artifact looks identical to the legitimate one. When attackers compromise a build pipeline or distribution channel, every downstream consumer inherits the threat, and traditional perimeter defenses won’t catch it. The risk class here isn’t a vulnerability you can patch. It’s a trust assumption you haven’t verified.

CCleaner supply chain attack

On March 11, 2017, four months before Avast acquired Piriform, attackers gained initial access to a Piriform developer workstation via TeamViewer using previously stolen credentials. Over the following months, they moved laterally through the internal network, deploying a keylogger to harvest additional credentials until they reached the build server.

By August 15, 2017, they had injected a multi-stage backdoor into the legitimate CCleaner 5.33 installer. The malicious binary bore a valid Piriform digital signature, making it indistinguishable from an authentic release to both users and security tools.

Over the next month, 2.27 million users downloaded the backdoored installer through CCleaner’s own official distribution infrastructure. On September 13, 2017, Cisco Talos researchers discovered the malicious payload and immediately notified Avast.

The attack was not a broad-based intrusion. Of the 2.27 million downloads, the attackers pushed a second-stage payload to approximately 40 machines at targeted technology and telecommunications companies, including Cisco, Microsoft, Intel, VMware, Google, Samsung, Sony, HTC, and Akamai. Cisco Talos identified code overlap between the second-stage payload and tools previously associated with Group 72, a threat actor linked to Chinese state-sponsored activity also tracked as Axiom (APT17), though researchers noted this overlap was not definitive proof of attribution.

The SI-07 failure was in the build process. Piriform had no integrity verification mechanism capable of detecting that the binary it was signing had been modified before release. A valid code-signing certificate was treated as complete assurance of software integrity, but the signing process itself had been compromised. NIST SP 800-53 SI-07 requires integrity verification tools to check software and firmware for unauthorized modifications. A build pipeline that verified the hash of output artifacts against expected values, or that ran integrity checks independent of the signing step, would have detected the modification before 2.27 million users were exposed.

What attackers exploit

Integrity verification gaps give adversaries multiple avenues to tamper with software and firmware without triggering alerts. The most common vectors include:

• Compromised build pipelines where attackers inject malicious code before binaries are signed, so the signature itself becomes a false trust signal
• Firmware-level implants that persist below the operating system, surviving reinstalls and evading host-based security monitoring tools
• Tampered configuration metadata where security attributes or access control lists are modified to escalate privileges without altering the application binary itself
• Supply chain distribution hijacking where legitimate update channels deliver modified packages to downstream consumers who have no independent verification step
• Insider modification of production artifacts where authorized users alter software or information without a corresponding integrity check or audit trail

How to implement

The most common implementation failure isn’t a missing tool. It’s treating code signing as a substitute for integrity verification. Signing confirms who produced an artifact, but it doesn’t confirm whether that artifact was modified after it left the developer’s workstation and before it reached the signing step.

For your organization

Start by inventorying every category of software, firmware, and information that falls under your organization’s SI-07 scope. Operating system images, application binaries, firmware for network devices and endpoints, middleware packages, and any information repositories containing PII or security-relevant metadata all belong on this list.

Deploy file integrity monitoring (FIM) tools that generate cryptographic hashes of baseline artifacts and continuously compare production assets against those baselines. Your FIM solution should cover endpoints, servers, and network infrastructure. For firmware, implement verification at boot time using secure boot protocols or hardware-based integrity checks tied to a trusted platform module (TPM).

Build integrity verification into your CI/CD pipeline. Every compiled artifact should have its hash recorded at build time, and every deployment step should verify that hash before promotion. This verification must happen independently from code signing. Signing and integrity checking serve different purposes, and collapsing them into a single step creates exactly the gap that the CCleaner attack exploited.

Define and document your response actions before you need them. Your system and information integrity policy should specify what happens when an integrity violation is detected. Common responses include automated quarantine of the affected asset, alerting the security operations center, blocking deployment, and initiating an incident response workflow.

You should avoid these common mistakes:

• Relying solely on antivirus or endpoint detection and response (EDR) as your integrity verification mechanism
• Verifying integrity at deployment but not monitoring for changes post-deployment
• Excluding firmware and information from your integrity monitoring scope
• Treating code signing certificates as a complete integrity assurance without an independent hash verification step
• Failing to define and test automated response actions for integrity violations

For your vendors

When assessing a vendor’s SI-07 posture, your security questionnaire should go beyond asking whether they “have integrity controls in place.” Generic attestations don’t reveal whether the controls function as described.

Ask your vendors these targeted questions:

• What integrity verification tools do you use to detect unauthorized changes to your software, firmware, and hosted information?
• How do you verify the integrity of artifacts in your build pipeline independently from code signing?
• What automated actions are triggered when your integrity monitoring tools detect an unauthorized modification?
• How frequently do you re-baseline your integrity verification hashes, and what change management process governs re-baselining?
• Do your integrity checks extend to firmware interfaces and metadata containing security attributes?

Request specific evidence rather than accepting a blanket statement of compliance. Useful artifacts include FIM tool configuration documentation, sample integrity violation alerts with timestamps, build pipeline verification logs, and documented response procedures for detected modifications.

Watch for these red flags during your assessment:

• The vendor cannot name the specific integrity verification tools they use
• Code signing is described as their sole integrity mechanism
• Firmware and information are excluded from the integrity monitoring scope
• No documented or tested response actions exist for integrity violations
• Integrity verification runs only at deployment with no ongoing monitoring

To verify beyond self-attestation, request a live demonstration or recent audit evidence showing that FIM alerts are generated and acted upon. Review their incident response records for integrity-related events. If the vendor’s build pipeline produces software your organization consumes, request hash verification documentation for recent releases.

Evidence examples

Cross-framework mapping

No cross-framework mappings are currently configured for this control.

Related controls

• AC-04 — Information Flow Enforcement: restricts data movement between systems, complementing SI-07 by preventing unauthorized transfers of software or information that could bypass integrity checks
• CM-03 — Configuration Change Control: governs change management processes so that modifications to software and firmware go through approved channels where integrity can be verified
• CM-07 — Least Functionality: reduces the attack surface by limiting installed software to what’s operationally necessary, shrinking the scope of assets that require integrity monitoring
• CM-08 — System Component Inventory: provides the authoritative list of components against which integrity baselines are established and maintained
• MA-03 — Maintenance Tools: controls which tools can modify system software and firmware during maintenance, reducing the risk of unauthorized changes
• MA-04 — Nonlocal Maintenance: secures remote maintenance sessions that could introduce unauthorized modifications to software or firmware
• RA-05 — Vulnerability Monitoring and Scanning: identifies known vulnerabilities in software and firmware, complementing integrity verification with threat-aware prioritization
• SA-08 — Security and Privacy Engineering Principles: embeds integrity verification requirements into system architecture from the design phase
• SA-09 — External System Services: extends integrity expectations to software and services provided by external parties
• SA-10 — Developer Configuration Management: requires developers to track and control changes during the software development lifecycle, feeding verified artifacts into production integrity baselines

Frequently asked questions

What is NIST SP 800-53 SI-07?

SI-07 is the NIST SP 800-53 control that requires organizations to use integrity verification tools to detect unauthorized changes to software, firmware, and information. It also mandates predefined response actions when those tools identify a modification, such as quarantine, alerting, or rollback. The control specifically covers operating system components, middleware, application binaries, firmware interfaces like UEFI and BIOS, PII, and security-related metadata. It applies at MODERATE and HIGH baselines within the NIST SP 800-53 framework.

What happens if SI-07 is not implemented?

Without integrity verification tools in place, your organization has no reliable way to detect when software, firmware, or information has been tampered with. Attackers can modify production binaries, inject backdoors into build pipelines, or alter security metadata without triggering any alert. The CCleaner supply chain attack demonstrated this risk at scale, where 2.27 million users downloaded a backdoored installer because no integrity check existed between the build step and the signing step. Regulatory auditors will flag the absence of integrity verification mechanisms as a control gap that undermines your entire system and information integrity posture.

How do you audit SI-07?

Auditing SI-07 starts with verifying that integrity verification tools are deployed and actively monitoring all in-scope software, firmware, and information assets. Reviewers should examine file integrity monitoring configurations, cryptographic hash baselines, and build pipeline verification steps to confirm they function independently from code signing. Auditors then check that documented response actions exist for unauthorized modifications and review system audit records showing those actions have been executed when violations were detected. Evidence of regular re-baselining tied to approved change management processes demonstrates that the integrity program keeps pace with legitimate updates.

What tools are used for software integrity verification?

File integrity monitoring (FIM) tools are the primary category used to satisfy SI-07, generating cryptographic hashes of baseline artifacts and alerting on deviations. Organizations also use secure boot mechanisms tied to trusted platform modules (TPMs) for firmware verification, and CI/CD pipeline tools that perform independent hash checks on build artifacts before deployment. Parity checks and cyclical redundancy checks serve as additional verification methods for data and information integrity. The key requirement is that these tools operate independently from the code-signing process, so a compromised signing certificate doesn’t nullify the entire verification chain.