Verify downloaded code before execution using an integrity mechanism that detects tampering. Prefer signed packages, compare expected hashes from a trusted source, and reject content that fails validation. Protect the retrieval channel as well, but do not rely on transport alone. Review update and plugin paths to ensure verification happens automatically.
What the mitigation has to accomplish
Download of code without integrity check is risky because the system executes code that has not been validated against tampering, substitution, or corruption. The core mitigation is to make execution contingent on a trusted integrity decision, not just on a successful download. That means the code must be signed or hashed, and the check must happen before the code is allowed to run.
For software supply chain controls, the most important question is whether the package you received is the same package the publisher intended you to execute. A protected transport channel helps, but it does not prove the payload is authentic or unchanged after publication. Verification is the control that closes that gap.
Good implementations also treat update paths, package managers, browser extensions, plugins, and bootstrap installers as execution gates. If any of those paths can pull code automatically, they need the same validation rule as a manual download, because attackers often target the path that bypasses the most review.
Where a broader supply chain program is in place, Software Supply Chain Security Guide is the natural parent concept for provenance, signing, and verification controls that prevent untrusted code from entering production.
Integrity checks that actually reduce exposure
The most effective mitigations are the ones that create a deterministic allow or block decision before execution. Signed packages are stronger than “download over HTTPS and hope,” because they let you validate publisher intent. Hash checks are useful when the expected digest comes from a trusted source that is not the same channel used to fetch the file.
If your platform supports it, enforce verification automatically rather than relying on users to compare checksums manually. Manual checks are easy to skip, especially during emergency updates, and that is exactly when unsafe code is most likely to be accepted.
Policy controls can add a second layer by restricting what may execute at all. Application Allowlisting Guide is relevant when you want execution to depend on explicit trust decisions rather than on a file merely arriving on disk.
On Windows endpoints, Windows Endpoint Hardening Guide is the right companion when code integrity needs to be enforced with platform features such as application control and tamper-resistant settings.
What to do when verification is missing or delayed
If a system cannot validate the code immediately, the safest response is to treat that package or update as untrusted until verification is complete. Do not make transport security, reputation scoring, or source familiarity substitute for integrity evidence. Those are supporting signals, not proofs.
For high-value software, use a staged rollout so that new code is validated in a controlled environment before it reaches the widest audience. That reduces the blast radius if the download is malicious, compromised, or accidentally damaged. It also gives you a chance to compare expected behavior with actual behavior before broad deployment.
Where code is part of a formal build and release process, SLSA is the most direct external framework for build provenance and artifact integrity, while NIST SSDF (SP 800-218) supports secure development and release practices that make unsigned or unverified code less likely to reach users.
Risk and Threat Considerations
Without integrity checks, the risk is not limited to corrupted downloads. Attackers can replace legitimate code with trojanised content, tamper with update channels, or abuse plugin and dependency paths to introduce malicious functionality that looks ordinary until execution time.
Failure mechanism: The system trusts a retrieved file because it came from a familiar location, but no cryptographic or policy-based validation proves the file is authentic and intact. That allows malicious or altered code to reach execution, persistence, or auto-update paths.
Impact: The result can be remote code execution, malicious update installation, persistence through recurring update mechanisms, or downstream compromise of the host, application, or dependent users.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST SP 800-53 Rev 5, CIS Controls v8, OWASP ASVS and NIST CSF 2.0 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 trusted code downloads. |
| Recommendation — Adopt SLSA-aligned provenance checks before release and execution. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | This control directly addresses validating integrity before software is trusted or run. |
| Recommendation — Apply SI-7 to verify downloaded code before execution. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Application software integrity and trusted update paths are core to this mitigation. |
| Recommendation — Enforce trusted software acquisition and integrity validation for updates and plugins. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Secure architecture should require integrity checks for retrieved executable content. |
| Recommendation — Design release and update flows so unverified code cannot execute. | ||
| NIST CSF 2.0 | PR.DS-10 — Integrity Mechanisms | Integrity mechanisms are the primary defense against tampered downloads. |
| Recommendation — Implement integrity mechanisms that block altered code from running. | ||
Practitioner Guidance
What to verify: Verify both the package signature and the source of the expected hash. If either value comes from the same untrusted channel as the download, the check is weak and should not be treated as a real control.
Decision rule: If the software can execute automatically, the verification must also happen automatically. If validation is manual, make it a temporary exception and require compensating controls until the process is hardened.
What practitioners underestimate: The most dangerous cases are often update systems and plugins, because they feel operationally routine. Those paths deserve the same integrity standard as any initial installation, and any exception should be treated as a release risk, not just a convenience issue.
Practitioner takeaway: The safest posture is to make integrity verification a precondition for execution, not a post-download review step, because once unverified code runs the risk has already shifted from supply-chain exposure to active compromise.
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