Provenance should come first when the environment is AI-assisted, because scanning can only inspect what is already present. Provenance answers the harder question of whether an artefact, dependency, or build step was introduced through authorised paths. Scanning remains necessary, but it cannot compensate for unknown origin.
Why provenance should usually be the first control decision
Provenance sets the trust boundary. If you cannot tell where an artefact, dependency, or build step came from, dependency scanning is limited to assessing an object whose origin is already uncertain. In AI-assisted delivery pipelines, that distinction matters because untrusted generation and automated chaining can introduce code paths faster than reviewers can manually reconstruct.
Provenance is also the control that distinguishes authorised introduction from merely observed presence. A scan may show a vulnerable package, but provenance tells you whether that package arrived through an approved repository, a controlled build, or an unexpected path. That is why provenance is the better first question when the goal is to stop unknown-origin software from entering the system.
Dependency scanning still matters because known vulnerable components remain a direct exposure even when origin is known. The practical sequence is to establish whether the artefact belongs in the environment, then assess whether it contains known-risk components that require removal, upgrade, or compensating controls.
What dependency scanning can and cannot tell you
Dependency scanning is strongest at identification. It helps you find known CVEs, outdated libraries, transitive exposure, and packages that violate policy. It is weaker at trust establishment because it usually inspects what is already present, not whether the thing should have been accepted in the first place.
That limitation becomes sharper in AI-assisted workflows, where code, manifests, and even dependency suggestions may be produced or modified quickly by tools and then merged with minimal human review. A scanner can catch a bad version, but it cannot prove that the dependency came from the intended maintainer, the intended pipeline, or the intended build artefact.
For practitioners, the right mental model is that scanning answers “what problems are inside this thing?” while provenance answers “why should we trust this thing at all?” Both are necessary, but they answer different control questions.
How to decide the order in a real programme
The order depends on the trust objective. If your immediate concern is supply-chain trust, build integrity, or AI-assisted artefact creation, start with provenance controls such as signed builds, source-to-binary traceability, repository trust, and attestations. If your immediate concern is reducing known exposure inside a stable software estate, scanning can be introduced in parallel, but it should not be treated as the primary trust gate.
For teams handling modern software supply chains, a provenance-first approach is usually the safer default. Open source supply-chain guidance such as SLSA exists because build integrity and origin verification change the answer to whether a component should be accepted at all. Open source ecosystem guidance from OpenSSF reinforces the same practical point: trust the path first, then inspect the contents.
That ordering is especially important where dependencies are generated, recommended, or assembled by AI-assisted tooling. In that setting, artefact provenance is not a niche supply-chain concern, it is the control that prevents the organisation from scaling unknown origin faster than it can scan it.
Risk and Threat Considerations
When provenance is weak, the organisation may be scanning malicious, tampered, or simply unauthorised artefacts after they have already entered the environment. That creates a false sense of coverage because the scanner can only report on the object in hand, not on the legitimacy of the path that produced it.
Failure mechanism: An attacker, compromised dependency, or unsafe AI-assisted workflow introduces code through an approved-looking channel, then uses the resulting trust gap to bypass or outrun content-based scanning.
Impact: Teams may accept a dependency or build output that appears clean enough on inspection but was never produced through a controlled, attestable path, increasing the chance of hidden compromise, policy violation, or later-stage blast radius.
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 Levels for Software Artifacts | Build provenance is central to the question of what to prioritise first. |
| Recommendation — Adopt SLSA-aligned provenance controls before relying on content scanning. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | AI-assisted delivery can introduce untrusted artefacts and secret exposure in supply chains. |
| NHI-03 — Vulnerable Third-Party NHI | Third-party dependencies are a key source of untrusted software origin. | |
| Recommendation — Check provenance before scanning for leaked secrets in non-human delivery paths. Validate third-party dependency provenance before accepting scan results. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Dependency scanning and software provenance both sit inside secure application delivery. |
| Recommendation — Prioritise secure software assurance controls that verify source and dependencies. | ||
| NIST SP 800-53 Rev 5 | SA-12 — Supply Chain Protection | Supply chain protection directly addresses origin assurance for components and build inputs. |
| RA-5 — Vulnerability Monitoring and Scanning | Dependency scanning is the follow-on control for known vulnerabilities. | |
| Recommendation — Implement supply chain protection before depending on vulnerability scanning alone. Use vulnerability scanning after provenance checks to find known weaknesses. | ||
Practitioner Guidance
What to prioritise: Make provenance the admission control for anything that can influence production, especially artefacts produced or assembled in AI-assisted workflows. Scanning should be treated as a second line of defence, not the mechanism that decides whether origin is acceptable.
What to verify: Before trusting a component, verify that you can trace its source repository, build process, signing or attestation state, and release path. If that chain is missing, treat the object as untrusted even if no scanner has flagged it.
Decision rule: If you are choosing between investing first in provenance or dependency scanning, choose provenance first when unauthorised introduction would be harder to recover from than a known vulnerable package. Choose scanning in parallel when you already have a trustworthy intake path and need better visibility into exposure.
Practitioner takeaway: The safest programme sequence is to prove where software came from, then measure what is inside it; reversing that order leaves you with better visibility but weaker trust.
Related resources from NHI Mgmt Group
- Should organisations prioritise secret scanning or privilege reduction first?
- Should organisations prioritise secret scanning or pipeline policy enforcement first?
- Should organisations prioritise rotation automation or dependency mapping first?
- Should organisations prioritise lockfiles or provenance checks first?