The install path breaks first. A package can look legitimate in source control while the registry tarball, mirror, or startup hook still executes attacker code on a workstation or CI runner. That is why supply-chain defence has to validate artifacts, helpers, and execution context together, not just the published source tree.
Why source-only trust breaks at the install boundary
Trusting only the source repository leaves a gap between what reviewers inspect and what actually runs. Modern package workflows often fetch a registry tarball, resolve transitive dependencies, execute install-time hooks, or pull helpers from mirrors and build tooling. The source tree can be clean while the install artifact or execution path is compromised.
The practical issue is that package integrity is not a single checkpoint. A maintainer branch, a release asset, a package index entry, and a workstation or CI runner each form part of the trust chain. If your validation stops at the repository, you are verifying intent in one place while execution happens somewhere else.
This is why supply-chain controls need to cover provenance, packaging, and runtime behavior together. For source integrity work, the OpenSSF guidance is useful because it treats open-source security as a lifecycle problem, not just a code-review problem.
Where attacker code still gets execution authority
Package compromise often happens at the artifact layer, not the source layer. A malicious tarball, altered mirror, poisoned dependency, or install script can turn a trusted name into an execution path for attacker code on developer laptops, build agents, or deployment hosts. The dangerous part is that the package may still appear legitimate in source control and even pass a shallow review.
Execution context matters because the package is not just data at install time. It may run preinstall or postinstall hooks, unpack binaries, alter startup files, or invoke other tools with the permissions of the user or CI job. That makes the install step a privilege boundary, not a mere file copy.
For practitioners, the key distinction is between reviewing the published source tree and validating the exact artifact and execution behavior that the runner consumes. If those are different, your trust model is incomplete.
What a complete trust check has to cover
Effective package trust checks need to verify the artifact, the provenance, and the execution path together. At minimum, that means comparing source to published package contents, checking signatures or checksums where available, and understanding whether install-time code can run outside the reviewed repository. It also means considering mirrors, caches, package managers, and any startup hooks that can alter behavior after installation.
In supply-chain terms, the issue is not only whether the code originated from the right repository. It is whether the delivered package, its dependencies, and its install context still preserve the same trust assumptions. When they do not, a source-only check can produce false confidence.
A concrete example is a package that is benign in GitHub but ships a registry artifact that contains an extra bootstrap file or a dependency chain that resolves differently in CI. The source review passes, yet the workstation or runner executes something else. That is the break.
Risk and Threat Considerations
Source-only checks create a classic supply-chain exposure, because attackers target the weakest link between reviewed code and executed code. The main risk is not just hidden malware, but trust collapse across mirrored registries, dependency resolution, and install hooks that can reach developer or CI environments with high privileges.
Failure mechanism: A trusted repository is used as the approval signal, while the installer fetches a different artifact or executes unreviewed startup logic from the package manager, mirror, or build step.
Impact: Attackers can gain code execution on workstations or CI runners, steal secrets, alter build outputs, or persist through package updates even when the source tree looked safe.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while SLSA, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply chain integrity | Package trust gaps are supply-chain integrity problems spanning source, artifact and provenance. |
| Recommendation — Require provenance and integrity checks for every build artifact before installation. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Package compromise on runners can expose secrets during install-time execution. |
| Recommendation — Prevent package install steps from accessing secrets unless strictly required. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | Trusted packages depend on third-party publishers, registries and mirrors. |
| Recommendation — Review third-party software sources and validate their delivery paths before trust is granted. | ||
| NIST SP 800-53 Rev 5 | SA-12 — Supply Chain Protection | The question is directly about supply-chain trust beyond the source repository. |
| SI-7 — Software, Firmware, and Information Integrity | Integrity checks must cover the artifact that executes, not only the source tree. | |
| Recommendation — Validate supplier and artifact provenance before accepting software into the environment. Verify software integrity at delivery and execution boundaries. | ||
Practitioner Guidance
What to verify: Confirm that the reviewed source, the published artifact, and the install behavior are all tied to the same release identity. If your package manager can execute hooks or resolve mutable dependencies, treat that as part of the control boundary, not an implementation detail.
Decision rule: If a package can execute code before or during installation, require artifact provenance checks and runtime inspection, not just repository review. If the package is allowed to touch CI or developer machines, assume the blast radius includes secrets, signing material, and build integrity.
Practitioner takeaway: The control objective is end-to-end trust, not source-only trust, because attackers usually win at the handoff between the reviewed repository and the code that actually runs.
Related resources from NHI Mgmt Group
- How should teams reduce risk from malicious npm package installs?
- What breaks when lifecycle tools do not cover support-channel identity checks?
- What breaks when supply-chain trust is based mainly on package popularity?
- What breaks when AI assistants are allowed to trust repository content by default?
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 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org