Download of Code Without Integrity Check is the acceptance of executable code without verifying that it has not been altered in transit or storage. Attackers can replace the download with malware or backdoored code. Defenders should require cryptographic integrity checks and fail closed when validation does not match.
What this vulnerability means in practice
Download of Code Without integrity check is dangerous because the code you receive may not be the code you intended to trust. Without cryptographic validation, a malicious intermediary, compromised mirror, or tampered storage location can substitute altered binaries, scripts, or packages that still look legitimate to the downloader.
This pattern is especially risky when software is fetched from multiple hops, mirrored repositories, update channels, or user-controlled storage. The security issue is not just that the code could be harmful, but that the normal trust signal, successful download, can mask silent tampering.
Why integrity validation matters
Integrity checks turn a passive download into a trust decision. Hash comparison, digital signatures, and package provenance mechanisms help confirm that the retrieved file matches a known-good release and has not been modified in transit or at rest.
When validation is missing or optional, attackers can target the weakest link in the delivery chain. That can mean a poisoned installer, a trojanized script, or a backdoored dependency that enters the environment before any runtime security control has a chance to stop it.
How organisations reduce exposure
Exposure review starts with knowing where executable content comes from and who is allowed to introduce it. Teams should trace software acquisition paths, review whether downloads are pinned to trusted sources, and confirm that integrity verification is enforced at every stage where code enters build, deployment, or endpoint workflows.
For software supply chain controls, SLSA is a useful reference point because it focuses on build provenance and integrity verification. Where endpoint trust is the concern, Application Allowlisting Guide helps limit what can execute even if a malicious download lands on the system.
Detection and recovery after a suspicious download
When a download is suspected to have bypassed integrity checks, the response should move quickly from containment to verification. That includes identifying every system that executed or stored the file, checking whether the expected signature or hash matched, and reviewing whether the file introduced persistence, new network connections, or unexpected child processes.
If validation failed after deployment, treat the artefact as potentially compromised rather than merely broken. Reacquire software from a trusted source, compare known-good hashes or signatures, and review related logs for signs that the altered code was executed before removal.
Risk and Threat Considerations
This weakness can create a direct software supply chain compromise path, because the attacker only needs to alter the download once for many downstream systems to inherit the same malicious file. It is particularly severe when organisations trust unsigned or unchecked code from mirrors, third-party repositories, or automated update mechanisms.
Failure mechanism: The defender assumes the download is trustworthy without proving integrity, so tampering is detected too late or not at all. That gives the attacker a straightforward injection point for malware, backdoors, or sabotage code.
Impact: Compromised code can lead to initial execution, credential theft, persistence, lateral movement, or corrupted build and deployment pipelines, depending on where the altered file is used.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Defines provenance and integrity expectations for downloaded build artefacts. |
| Recommendation — Require verified provenance before accepting downloaded code into build or deployment flows. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | Addresses preventing execution of malicious code delivered through downloads. |
| Recommendation — Use malware defenses to block and detect trojanized downloads before execution. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Directly covers integrity checking for software and code artifacts. |
| Recommendation — Apply SI-7 to verify code integrity and reject altered downloads. | ||
| OWASP ASVS | V11 — Cryptography | Supports cryptographic validation of software and related artefacts. |
| Recommendation — Use cryptographic verification to confirm downloaded code has not been altered. | ||
| ISO/IEC 27001:2022 | A.8.8 — Management of technical vulnerabilities | Supports control of known weaknesses in software acquisition and validation processes. |
| Recommendation — Review acquisition and validation gaps so untrusted code cannot enter the environment. | ||
Practitioner Guidance
Why practitioners should care: Integrity verification should be treated as a release gate, not a nice-to-have check. If a workflow accepts executable content without validating it, the organisation is inheriting the attacker’s version of the software trust chain.
What to watch for: Watch for unsigned packages, hash mismatches, missing provenance metadata, and download paths that allow manual overrides. Those are common places where insecure acceptance of code slips into otherwise mature environments.
Practitioner takeaway: Fail closed when integrity validation does not match, and require a documented trusted source before any executable code is allowed to run.
Related resources from NHI Mgmt Group
- What happens when production code or build controls can be changed without strong integrity checks?
- What is the difference between code integrity risk and identity exposure risk in CI/CD?
- How should security teams harden user authentication without building custom auth code?
- How should security teams add authorization to legacy applications without changing code?