They should do both, but provenance checks usually deserve the first control investment because they stop bad packages before they enter the pipeline. Malware scanning still matters, yet it is weaker when attackers hide in legitimate-looking tooling or agent execution paths. Provenance, allowlisting, and source pinning reduce the set of packages scanners ever need to assess.
Why provenance controls should come first
Registry provenance checks answer a different question from malware scanning: not “does this artifact contain known bad code?” but “where did this artifact come from, and do we trust that path?” That matters because the safest time to stop a package is before it is admitted into build, deploy, or agent execution paths. Provenance controls also pair well with source pinning and allowlisting, which shrink the number of artifacts that ever need deeper inspection.
For package supply chains, provenance is the stronger gate when teams are choosing their first control investment. It blocks a large class of poisoned dependencies, typo-squats, hijacked maintainer accounts, and tampered artifacts without waiting for a scanner to recognise a payload signature. SLSA is the clearest external model for this because it focuses on build provenance and integrity before release.
Provenance also changes the economics of defense. If you trust the source, the build path, and the expected digest, downstream tools can make narrower decisions about what deserves malware analysis, behavioural sandboxing, or manual review. That does not make scanning obsolete, but it does make scanning a second-line control instead of the main barrier.
Where malware scanning still adds value
Malware scanning is still useful because provenance alone does not guarantee benign behaviour. A package can be legitimately published and still contain malicious scripts, hidden exfiltration logic, or post-install actions that abuse developer trust. Scanning helps catch known signatures, suspicious file patterns, and some forms of repackaged malware that provenance controls may not reveal on their own.
The limitation is that scanners are strongest against known or recognisable indicators. They are weaker when malicious logic is obfuscated, embedded in a legitimate toolchain component, or triggered only during execution. In those cases, a clean scan result can create false confidence if teams have not already narrowed the intake set with provenance and allowlisting. The right mental model is layered defense, not a contest where one control replaces the other.
That is why registry controls and malware detection should be tuned together. If provenance is strict, scanners spend their effort on fewer and better-sourced artifacts. If provenance is weak, the scanner becomes a compensating control, but it will also be asked to inspect far more noise.
How to decide the control order in practice
Teams should generally place provenance checks at the admission boundary and keep malware scanning as a downstream filter. That sequence is especially important for package registries, container images, CI/CD dependencies, and other software artifacts that can be pulled automatically into trusted systems. CIS Controls v8 supports that layered approach by combining inventory, vulnerability management, malware defense, and access control rather than treating any single control as sufficient.
A practical decision rule is simple: if the artifact can be blocked on origin, signature, digest, maintainer trust, or release attestation, do that first. Then scan what remains. That order reduces blast radius and helps avoid wasting scanning capacity on packages that never should have entered the pipeline.
This is also where source pinning matters. Pinning makes provenance verifiable, reduces dependency drift, and stops “latest” updates from silently changing what code enters the build. Allowlisting adds a further check by constraining which package names, registries, and publishers are even eligible for use.
Risk and Threat Considerations
Registry provenance failures create a broader exposure than malware scanning failures because they let untrusted software enter the trusted software supply chain in the first place. Once that happens, the attacker can rely on normal developer workflows, automation, and deployment trust to spread the compromise.
Failure mechanism: A compromised registry account, poisoned dependency, or tampered artifact is accepted as legitimate because the control checks content after admission instead of trust before admission. Scanning may detect some known payloads, but it will miss clean-looking or newly crafted malware that arrives through a trusted path.
Impact: The result can be secret theft, build compromise, malicious runtime behaviour, and wider pipeline exposure across many downstream systems. The more automated the delivery chain, the faster that trust failure propagates.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA 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 | Provenance checks and artifact integrity are central to the question. |
| Recommendation — Adopt provenance attestation and verification before accepting packages into the pipeline. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | The question concerns prioritising supply-chain intake controls and malware defense. |
| Recommendation — Harden software intake with allowlisting, source pinning, and controlled software acquisition. | ||
Practitioner Guidance
What to prioritise: Put provenance, allowlisting, and source pinning at the top of the control stack for registries and dependency intake. Treat malware scanning as a necessary follow-on control, not as the primary gate.
What to verify: Confirm that packages are checked against trusted origin, expected digest, and approved publisher or repository before they can reach build or runtime. If a team cannot explain how an artifact earned trust, it should not be consuming that artifact automatically.
Common mistake: Teams often increase scanner coverage while leaving registry admission wide open. That improves visibility after the fact, but it does little to stop high-risk packages from entering the pipeline in the first place.
Practitioner takeaway: If you can stop untrusted software at admission, do that first, then use malware scanning to catch what provenance cannot prove.
Related resources from NHI Mgmt Group
- When should teams prioritise CI/CD hardening over broader secret scanning?
- When should teams prioritise rule precision over broader detection coverage in code scanning?
- When should teams prioritise JWT expiry policy over broader secret scanning?
- Should teams prioritize just-in-time secret injection over more dependency scanning?