Before installation. If provenance checks happen only after the file has already executed, the attacker has already crossed the trust boundary. Verification needs to cover the signed package, the source channel, and the publishing identity so the system can reject tampered content before it runs.
Why provenance checks belong before execution
Update provenance only works as a control when it is applied at the point where trust is decided. If a package, patch, or artifact is allowed to install or execute first, the organisation has already accepted the risk of tampered code, substituted sources, or a forged publisher identity. The practical question is not whether to inspect provenance, but whether you can stop untrusted content before it touches a trusted runtime.
That matters because provenance is not a cosmetic label. It is the evidence chain that tells you where the update came from, whether the package you received is the one that was published, and whether the signer or publishing identity is the one you intended to trust. If the check comes after execution, the trust decision is too late to prevent initial compromise.
When update channels are well governed, the control point sits at acquisition, verification, and admission, not at post-install review. The system should verify the signature, compare the source channel against the expected origin, and validate the publishing identity before any file is permitted to change state on the target system.
What “before installation” means in practice
Before installation does not mean every update must be manually reviewed. It means the receiving system, updater, or deployment pipeline should have a deterministic allow-or-block decision ahead of execution. That decision should be tied to the signed artifact, the metadata that identifies the publisher, and the transport or repository path used to retrieve the update.
A useful way to think about the control is that provenance must survive the full journey from publisher to consumer. If the package is rehosted, mirrored, cached, or wrapped by another delivery process, the verification step still has to prove that the content is authentic and unchanged. This is why supply-chain controls such as SLSA matter: they push integrity and provenance checks into the build and release path so downstream consumers can rely on pre-execution assurance.
In higher-trust environments, the verification logic may also depend on the identity of the publisher or signing service, not just the cryptographic validity of a signature. A valid signature from the wrong signer is still a trust failure. The operational objective is to reject updates that are authentic in a cryptographic sense but unauthorised in a governance sense.
Where organisations most often get this wrong
The most common failure is treating provenance as a logging or audit activity. Teams install the update first, then record metadata afterwards for compliance evidence. That sequence creates a blind spot large enough for supply-chain compromise, malicious substitution, or accidental misdelivery to become an execution event before anyone has a chance to intervene.
Another common mistake is checking only the file hash after download while ignoring the channel that delivered it. A checksum by itself says nothing about whether the source repository was legitimate, whether the signature key was expected, or whether the update was fetched through an approved path. Good provenance verification evaluates the package, the distribution path, and the publisher together.
There is also a trust-boundary problem. Once an update is executed, the attacker may gain code execution, persistence, or access to local privileges long before the provenance check fails. That is why defensive architectures such as NIST SP 800-207 Zero Trust Architecture align well with this problem: trust is not assumed because content arrived through an expected route, it is verified before access is granted.
Risk and Threat Considerations
Update provenance is a high-value attack surface because it sits on the path between distribution and execution. If attackers can tamper with the artifact, substitute the source, or abuse a trusted signing relationship, they can turn routine maintenance into code delivery. The danger rises sharply in automated deployment environments where unverified content can move quickly across many systems.
Failure mechanism: The control fails when verification occurs after installation, when signing trust is inherited from the wrong channel, or when publisher identity is not checked against an expected allowlist before execution. In those cases, the system admits untrusted code first and learns about the problem only after the attack path is already active.
Impact: The result can be immediate compromise, malicious persistence, unsafe lateral movement, or a widespread supply-chain incident affecting every system that accepted the same update. Once executed, the update may already have modified binaries, services, credentials, or configuration state, making rollback slower and containment harder.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply Chain Levels for Software Artifacts | Update provenance is a software supply-chain integrity problem. |
| Recommendation — Verify artifact provenance before release and reject unsigned or untrusted builds. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The question is about refusing trust until verification completes before execution. |
| Recommendation — Require verification before granting execution trust to updates or packages. | ||
Practitioner Guidance
What to prioritise: Treat provenance validation as an admission control, not a post-install audit. If your updater, package manager, CI/CD pipeline, or endpoint agent cannot block untrusted content before execution, the control is not strong enough for production use.
What to verify: Confirm that the verification step covers the signed package, the expected source channel, and the publishing identity. If any of those checks are optional, manual, or deferred until after installation, the trust model is weaker than it appears.
Decision rule: If the update can execute code or alter privileged state, verify provenance first and fail closed on uncertainty. If the update is truly non-executable metadata, the risk is lower, but the source and identity checks still need to be explicit.
Practitioner takeaway: Provenance only protects you when it prevents untrusted code from crossing the trust boundary, not when it documents the compromise after the fact.