Verify the authenticity and integrity of downloaded code before it runs. Use signed packages or other trusted verification, compare hashes from a trusted source, and fetch over protected channels. Reject downloads that fail verification, and make sure updates, dependencies, and scripts are checked before execution so a man-in-the-middle or compromised mirror cannot alter them undetected.
What “integrity check” means before code is allowed to run
The practical goal is to make sure the artifact you downloaded is the one the publisher intended, not just a file that arrived successfully. That means validating provenance and content before execution, so tampering during transit, mirror compromise, or package substitution is detected before it reaches your build or runtime path.
integrity check can be simple, such as comparing a published hash from a trusted source, or stronger, such as verifying a signed package, release manifest, or attestable provenance chain. The important point is that the trust decision happens before the code is executed, imported, installed, or piped into another tool.
For software supply chain security guidance, the right framing is that integrity is not a separate final step, it is part of the acceptance criteria for the download itself. NHIMG’s Software Supply Chain Security Guide is the most direct internal starting point for the broader controls around provenance, signing, and dependency trust.
Which verification methods actually stop tampered downloads
Developers should prefer verification methods that bind the file to a trusted publisher or release process. Signed packages are stronger than ad hoc checksums because they let you verify origin as well as content, while trusted hash publication is useful when the hash itself is delivered over a channel you already trust.
Protected transport still matters, but transport security alone is not enough. HTTPS reduces interception risk in transit, yet a compromised mirror, a poisoned release pipeline, or a malicious dependency can still present a file that is perfectly delivered and still untrusted. Verification must therefore sit on top of transport, not replace it.
One practical control is to enforce code integrity in the endpoint or build environment so unverified executables and scripts cannot run by default. The Application Allowlisting Guide is useful here because it covers policy mechanisms that block unauthorized code paths after download and before execution.
For implementation detail, the most useful external references are the SLSA framework for provenance and the OpenSSF ecosystem for software supply chain practices and tooling.
How to keep integrity verification from becoming a one-time checkbox
The mistake to avoid is verifying only the first download and then assuming everything downstream is safe. Updates, dependency fetches, generated artifacts, bootstrap scripts, and CI jobs all need the same trust discipline, because an attacker often targets the easiest step in the chain rather than the original release itself.
That means developers should treat package managers, build scripts, and install hooks as execution points, not as passive file transfers. If a dependency manager auto-installs code, or a script fetches and runs something in one step, the verification control needs to happen before that action is allowed to complete.
When teams want a practical secure-development baseline, OWASP Cheat Sheet Series provides implementation guidance that complements release verification, while NIST SSDF (SP 800-218) anchors the broader practice of building integrity checks into the development lifecycle.
Risk and Threat Considerations
The main risk is silent trust failure: code appears to download normally, but the content has been altered by an attacker, a compromised repository, or a malicious intermediate. That creates a direct path from a routine developer action to supply-chain compromise, because the unverified file can run with the same privileges as the developer or pipeline that fetched it.
Failure mechanism: A man-in-the-middle, poisoned mirror, or compromised package source substitutes altered code, and the absence of a verification gate lets the file execute before anyone detects the change.
Impact: The result can be malware execution, credential theft, backdoored builds, dependency poisoning, or persistence in downstream systems that trust the downloaded artifact.
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 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain integrity | This question is about verifying software provenance before execution. |
| Recommendation — Adopt provenance controls that bind builds and releases to verifiable artifact integrity. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Integrity checks on downloaded code directly align with ensuring software is not altered or tampered with. |
| Recommendation — Apply SI-7 to verify code integrity before installation or execution. | ||
| OWASP ASVS | V13 — Configuration | Trusted installation and update paths require verification controls around software configuration and deployment. |
| V15 — Secure Coding and Architecture | Secure software delivery needs integrity validation embedded in the development and release flow. | |
| Recommendation — Require verified deployment inputs before allowing code to run. Build integrity checks into the release and dependency workflow. | ||
Practitioner Guidance
What to verify: Check both provenance and integrity, not just transport. If the artifact has a signature, verify it; if the process relies on hashes, confirm the hash came from a trusted, separate source and matches the exact file you received.
Decision rule: If the download cannot be tied to a trusted publisher or release process, do not run it, even if the file “looks right” or the repository is familiar. For build automation, fail closed and surface the mismatch as an operational defect, not a warning to ignore.
What practitioners underestimate: Dependency installers and bootstrap scripts are often the real execution path, so verification has to cover the entire acquisition chain, including updates and transitive pulls.
Practitioner takeaway: The control is effective only when integrity checking is mandatory before execution, consistently enforced across updates and dependencies, and backed by a reject-on-fail rule.