A mismatch between visible source code and the packaged binary or shipped extension. This matters because security teams often trust repository review, but the artifact users install is the system that actually runs. Divergence can preserve malicious behaviour even after the source looks cleaned up.
Expanded Definition
Source Compiled Artifact Divergence occurs when the code a team reviews is not identical to the binary, package, or extension that is actually deployed. In NHI and agentic systems, that gap can hide altered logic in build output, post-processing steps, or release packaging, even when the repository appears clean.
Definitions vary across vendors because the problem spans source integrity, build provenance, and release trust. The closest operational anchor is software supply chain assurance, where NIST SP 800-53 Rev 5 Security and Privacy Controls emphasizes configuration management, integrity verification, and controlled change paths. For NHI security, the issue matters most when code contains embedded secrets, service-account logic, or agent tool permissions that are removed in source but preserved in the shipped artifact.
This concept is often confused with simple code review failure, but divergence can happen after review through compromised CI pipelines, unsafe build scripts, dependency injection, or release repackaging. The most common misapplication is assuming repository approval equals runtime trust, which occurs when teams validate source while ignoring the signed artifact, build provenance, and deployment checksum.
Examples and Use Cases
Implementing artifact integrity rigorously often introduces release friction, requiring organisations to weigh faster delivery against stronger verification of what actually runs.
- A service account helper library is reviewed in Git, but the compiled package shipped to production still contains an extra network call added during build-time instrumentation.
- An agent plugin is approved after source inspection, yet the distributed extension bundles a different manifest that grants broader tool access than the repository version intended.
- A secrets-handling module is cleaned in source control, but the published container layer still includes the older binary that logs credentials to disk.
- Build attestation is added after a post-incident review, linking the published artifact to a specific commit and pipeline run so release artifacts can be traced back to reviewed source.
NHIMG research shows that 30.9% of organisations store long-term credentials directly in code, which makes source to artifact mismatch especially dangerous when the hidden runtime payload can preserve exposed secrets or privilege logic. The ASP.NET machine keys RCE attack illustrates how trusted application material can become an execution path when packaging or deployment controls fail. For standards context, NIST SP 800-53 Rev 5 Security and Privacy Controls supports the control discipline needed to compare reviewed code with approved builds.
Why It Matters in NHI Security
Source Compiled Artifact Divergence undermines trust in the exact object that executes service-account actions, signs requests, calls APIs, or brokers agent tools. In NHI environments, that can turn a supposedly remediated credential path into a living attack surface because the binary may still contain dormant secret access, hidden privilege escalation, or unauthorized outbound connections.
NHIMG reports that 91.6% of secrets remain valid five days after notification, which shows how slowly real remediation often progresses once a build or release compromise is discovered. The same lag affects artifact integrity: teams may think they have removed dangerous logic, but the deployed object continues to operate until provenance, hashes, and release chains are validated. This is where ASP.NET machine keys RCE attack remains a useful cautionary example, because execution can persist even after the source narrative changes.
Organisations typically encounter this consequence only after a compromised release, at which point source compiled artifact divergence becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Build and artifact integrity are central to preventing hidden NHI behavior changes. |
| NIST CSF 2.0 | PR.DS-6 | Integrity verification covers software artifacts and their trusted release state. |
| NIST CSF 2.0 | CM-3 | Controlled change management reduces divergence between source and shipped binaries. |
Compare hashes, signatures, and build provenance before allowing release deployment.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
