Security teams detect a software integrity attack by comparing running code, packages and configuration against trusted baselines, then watching for unauthorised changes. Alert on unexpected hashes, unsigned updates, altered binaries, abnormal admin activity and new persistence. Verify build and deployment provenance, and inspect hosts after patching if integrity checks fail or behaviour changes.
How integrity attacks reveal themselves in practice
A software integrity attack usually shows up as a mismatch between what the environment should be running and what is actually present. The signal is strongest when multiple checks disagree at once: the package or binary hash changes, a signed artifact becomes unsigned, a deployment no longer matches provenance records, or configuration drifts without an approved change.
Teams should treat these as evidence of tampering only after they have compared the running state to a trusted baseline. The baseline needs to include code, packages, configuration, build metadata and release provenance so that detection is based on integrity, not just on file presence or version numbers.
What to watch for across code, builds and runtime state
The most useful detections are the ones that correlate technical change with an unauthorised path. That includes unexpected hashes on executables or libraries, altered startup scripts, new services or scheduled tasks, abnormal administrative activity, and persistence mechanisms that appear after a patch or deployment window.
Build and deployment provenance matters because integrity attacks often begin before the code reaches production. If build output, signing records, artifact storage or release notes do not line up, the problem may be in the supply path rather than on the host itself. For broader guidance on software supply chain integrity, the Software Supply Chain Security Guide is the best internal starting point, and SLSA is the clearest external reference for build provenance and artifact integrity.
Alerting should also include control-plane signs, not just file changes. If an administrator account appears where it should not, if a deployment pipeline changes without approval, or if a trusted update channel begins serving unexpected content, the integrity issue may be active even before the workload behaves oddly.
How to confirm compromise and separate noise from tampering
Not every integrity alert means a confirmed compromise, but every credible alert deserves verification. The right next step is to compare the suspect host or package against known-good hashes, trusted package repositories, signed release metadata and deployment records, then inspect whether the change is isolated or appears across multiple systems.
If patching or recovery has already occurred, do not assume the issue is closed. When integrity checks fail, or when system behaviour changes after a patch, teams should inspect for pre-existing compromise, hidden persistence and any evidence that the attacker used the update path or build process itself. That is where malicious modification is most likely to survive routine remediation.
For teams that want a control-oriented lens, NIST SP 800-53 Guide helps map integrity monitoring to assessment and baseline control thinking, while NIST SP 800-53 Rev 5 Security and Privacy Controls provides the underlying control catalogue. For operational detection work, MITRE ATT&CK Enterprise Matrix is useful for mapping persistence, privilege escalation and credential access patterns that often accompany integrity compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while SLSA, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Build provenance and artifact integrity are central to detecting software integrity attacks. |
| Recommendation — Verify artifact provenance and signed build metadata before trusting deployed software. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | This subject is about detecting unauthorized software and configuration changes. |
| CM-5 — Access Restrictions for Change | Unauthorized changes often come from unapproved administrative or pipeline actions. | |
| Recommendation — Monitor integrity of software, firmware and configuration, then investigate unauthorized deviations. Restrict change paths to approved roles and log all privileged modification activity. | ||
| MITRE ATT&CK | Enterprise Matrix | Integrity attacks commonly involve persistence, privilege escalation and malicious modification techniques. |
| Recommendation — Map suspicious integrity-change patterns to ATT&CK techniques and hunt for related persistence. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Baseline comparison and unauthorized drift detection are core to this question. |
| Recommendation — Compare assets to hardened baselines and alert on unauthorized configuration or software drift. | ||
Practitioner Guidance
What to prioritise: Start with the assets whose integrity would change business or security outcomes, such as production binaries, packages, build artifacts, signing keys and deployment pipelines. A single unexplained change in those layers is more important than many benign deviations in low-risk systems.
What to verify: Confirm that your baseline is actually trusted, current and complete. If the baseline omits provenance records, signing status or deployment metadata, your detection program may only find drift, not tampering.
Decision rule: If the change affects a release artifact, signature, build pipeline or privileged administrative action, treat it as a possible compromise until provenance and host inspection prove otherwise. If the change is limited to a non-production asset with no execution path, it may be a lower-severity configuration issue.
Practitioner takeaway: Integrity detection works best when teams correlate runtime state with release provenance and control-plane activity, because the attacker’s strongest advantage is usually the gap between a trusted pipeline and an untrusted result.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org