A lifecycle-evidenced technique is an attack or compromise that happens before the system is running, such as training-time poisoning or supply-chain compromise. The runtime programme cannot see it directly, so assurance must come from build, training, and provenance controls.
What Lifecycle-Evidenced Technique Means
A lifecycle-evidenced technique is an attack or compromise that occurs before runtime, such as training-time poisoning or supply-chain compromise, so the runtime system cannot reliably observe it directly.
The defining feature is not just that the technique happened “earlier,” but that the evidence of compromise lives in lifecycle stages such as build, training, packaging, signing, release, and provenance. That shifts assurance away from runtime telemetry and toward control of the creation path.
In practice, this term spans both software and AI delivery chains when the integrity problem is introduced before the system is operational. For AI systems, poisoned data, tampered artifacts, or compromised model inputs can shape later behaviour without leaving an obvious runtime signal. For software systems, the same pattern appears in compromised dependencies, build steps, or release artifacts.
This is why lifecycle-evidenced techniques are often harder to detect than in-session attacks: the compromise may look legitimate by the time the system starts, and downstream monitoring may only see the consequence, not the origin.
How Lifecycle-Evidenced Techniques Work
These techniques typically exploit trust in upstream stages that are assumed to be safe. An attacker may alter source, training data, dependencies, build tooling, signing material, or distribution paths so the compromise is effectively “baked in” before operation begins.
That means the key security question is often provenance, not simply runtime behaviour. If the pipeline cannot prove what was built, trained, or signed, then later trust decisions can be built on a compromised foundation.
Lifecycle evidence can come from source control history, build logs, artifact attestations, training lineage, dependency inventories, signing records, and controlled release approvals. The stronger and more complete the chain of custody, the easier it is to establish whether an artifact or model was tainted before deployment.
For that reason, lifecycle-evidenced techniques are a control-plane problem as much as a detection problem. Once the compromise has propagated into a released system, remediation is usually much more expensive than preventing or proving integrity earlier.
Security Implications of Pre-Runtime Compromise
The main security consequence is that runtime-only monitoring can miss the root cause. A system may appear healthy while actually behaving exactly as the attacker intended because the compromise was introduced upstream.
That creates integrity risk, persistence risk, and trust risk. The attacker does not need to repeatedly trigger an exploit at runtime if the artifact, model, or dependency already contains the malicious change.
Lifecycle-evidenced techniques also raise supply-chain and provenance concerns. When build systems, dependency sources, or training pipelines are weakly controlled, an attacker can turn a single upstream foothold into many downstream compromises. NHI lifecycle security challenges illustrate the same pattern in identity systems, where unmanaged credentials and poor visibility create durable exposure.
In AI environments, a poisoned training or tuning process can create model behaviour that is hard to distinguish from intended output. In software environments, a tampered dependency or signed artifact can preserve attacker control even after the original intrusion point is closed.
Where Assurance Has to Happen
Assurance for lifecycle-evidenced techniques has to happen before and during creation, not only after deployment. That is where provenance, change control, signing, dependency integrity, build isolation, and training-data governance do the most work.
The practical issue is traceability: if you cannot explain where an artifact came from, what influenced it, and who approved it, you cannot confidently say the runtime result is trustworthy. IAM and IGA Basics is useful here because the same governance logic, ownership, and review discipline applies to non-runtime trust chains.
Strong provenance does not eliminate all risk, but it narrows the window in which compromise can hide. That is why lifecycle-evidenced techniques are closely associated with secure build pipelines, artifact attestations, and controlled promotion between environments.
For readers, the key mental model is simple: if the compromise happened before the system ran, then the evidence of compromise must also be sought before the system ran.
Risk and Threat Considerations
Lifecycle-evidenced techniques are especially dangerous because they can survive normal runtime defenses and leave little obvious telemetry at the point of use. A compromised artifact, model, or dependency can remain trusted until a downstream review finally exposes the origin problem.
Failure mechanism: The attacker corrupts a pre-runtime stage such as training, build, signing, or packaging, then relies on the system’s trust in that stage to carry the compromise forward.
Impact: The result can be persistent integrity loss, broad downstream exposure, and delayed detection, often affecting every environment that consumes the tainted output.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while SLSA 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 | Defines provenance and build integrity controls for pre-runtime artifact trust |
| Recommendation — Apply SLSA concepts to verify build provenance and protect artifact integrity before release. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Covers integrity verification for code, firmware, and content that can be altered pre-runtime |
| CM-3 — Configuration Change Control | Supports controlled changes to build, training, and release paths that can introduce hidden compromise | |
| AU-10 — Non-repudiation | Supports trustworthy evidence for who produced or approved lifecycle artifacts | |
| Recommendation — Use SI-7 to verify integrity of artifacts and detect tampering before deployment. Use CM-3 to control and approve changes across the lifecycle that affect trusted outputs. Use AU-10 to preserve evidence that links artifacts to approved lifecycle actions. | ||
| MITRE ATT&CK | Enterprise attack techniques | Covers supply-chain and pre-compromise techniques that occur before runtime |
| Recommendation — Map observed pre-runtime compromise paths to ATT&CK techniques and hunt for upstream intrusion. | ||
Practitioner Guidance
Why practitioners should care: The control point is the lifecycle, not the runtime. If assurance only starts after deployment, the highest-risk compromise path may already be outside visibility.
Practitioner takeaway: Treat provenance, approvals, and chain-of-custody evidence as first-class security signals for any system where pre-runtime compromise would invalidate later runtime trust.
Related resources from NHI Mgmt Group
- How does NHI lifecycle management differ from human identity lifecycle management?
- What is the difference between runtime protection and NHI lifecycle management?
- How should organisations prove EU AI Act compliance across the AI lifecycle?
- What is the difference between secrets rotation and lifecycle governance?