Artifact Provenance in Intelligence Pipelines: Who Built This Binary and Why Does That Matter?

Supply chain attacks don't announce themselves. A compromised build dependency, a tampered container layer, an unsigned tool pulled from a mirror that looked legitimate three months ago — these are the vectors that end operations, not dramatic zero-day exploits against your perimeter.

Photo by Ray Bran on Pexels.

For intelligence teams running custom tooling, the problem is worse than it is for your average enterprise shop. You can't always rely on vendor SLAs, public CVE disclosures, or community-maintained patch cadences. You're building bespoke collection tools, custom enrichment scripts, proprietary parsers. The question of who built this artifact, when, from what source, and whether it's been touched since isn't an audit checkbox. It's an operational question.

Why Provenance Fails in Practice

Most teams treat artifact provenance as something that happens at the end of a pipeline — a hash check, maybe a GPG signature verification if someone remembered to set it up. That's not provenance. That's a receipt without a chain of custody.

Real provenance means you can answer: What source code commit produced this binary? Which build environment ran the compilation? Who authorized the promotion from staging to production? Has any byte of this artifact changed since it left the build system?

Without that chain, you're trusting. And in intelligence operations, trust without verification is just hope with better branding.

SBOM generation — Software Bill of Materials — has become the nominal answer to this. The U.S. government's push toward SBOM adoption post-SolarWinds is real, and the tooling (Syft, Grype, Trivy, CycloneDX) has matured considerably. But an SBOM only tells you what's in an artifact. It doesn't tell you whether the build process that produced it was clean.

The Build Environment Is the Attack Surface

Here's what gets overlooked: the binary you're signing is only as trustworthy as the environment that compiled it. A poisoned base image in your build container, a malicious GitHub Action pulled from a third-party repository, a compromised dependency cached in your artifact registry — any of these can produce a perfectly signed binary that will still do something you didn't intend.

This is the distinction between signing and attestation. Signing proves the artifact hasn't changed since it was signed. Attestation proves something about the conditions under which it was produced.

SLSA (Supply-chain Levels for Software Artifacts) gives you a vocabulary for this. Reaching SLSA Level 3 means your build runs in an isolated, ephemeral environment; the build definition is version-controlled and can't be modified during execution; and the provenance metadata is generated by the build system itself, not by a script someone wrote and forgot about.

For classified or sensitive tooling, SLSA Level 3 should be your floor, not your aspiration.

graph TD
    A[Source Commit] --> B(Hermetic Build Environment)
    B --> C[Artifact + Provenance Attestation]
    C --> D{Signature Verification}
    D --> E[Artifact Registry]
    E --> F(Deployment Gate)
    F --> G[Operational Environment]
    C --> D

Practical Steps That Actually Move the Needle

Ephemeral build environments. Every build spins up a fresh container or VM from a known-good base image, runs, and dies. Nothing persists between builds. This eliminates entire categories of persistent compromise in your build infrastructure.

Hermetic builds are harder — they require all dependencies to be declared and fetched from controlled sources, with no network access during compilation. Bazel does this well. If your team isn't ready for Bazel, at minimum pin every dependency to a specific digest, not a tag. Tags are mutable. Digests are not.

For the artifact registry itself: enforce immutability. Once an artifact is pushed with a given tag or digest, it cannot be overwritten. Nexus, Artifactory, and AWS ECR all support this. If your current setup allows tag overwrites, someone could silently replace a production binary and your deployment logs would show nothing unusual.

Promotion gates between environments — dev, staging, production — should require explicit re-attestation, not just re-tagging. An artifact that passes security scanning in a dev registry shouldn't automatically be trusted in a production context. The promotion decision should generate its own signed record: who approved it, when, and what checks passed.

The Operational Reality

None of this is frictionless to implement. Hermetic builds break things that weren't properly declared as dependencies. SLSA compliance requires buy-in from whoever manages your build infrastructure. SBOMs generate noise before they generate signal.

But consider the alternative framing: if an adversary wanted to compromise your collection tooling, your build pipeline is a far softer target than your runtime environment. You've hardened the endpoint. You've locked down the network. Meanwhile, your CI system is pulling packages from public registries with no attestation verification, running in a persistent VM that hasn't been rotated in eight months.

Provenance isn't bureaucratic overhead. It's the documentation that lets you answer — quickly, under pressure, when something has already gone wrong — whether the tool you've been running for the past six months is the tool you think it is.