Build Artifact

Origin & evolution

Build-once-deploy-many became doctrine as continuous delivery matured. Jez Humble and David Farley's Continuous Delivery (2010) argued that the same binary should flow through every stage of the pipeline, because rebuilding per environment reintroduces the very risk🎲RiskComplianceA risk to the product or businessView reference → the pipeline exists to remove. Artifact registries, from Maven Central through container registries, gave these outputs a versioned, addressable home.

The recent shift is from identity to provenance. A 2021 supply-chain attack wave, including the SolarWinds compromise where malicious code was injected into the build, made a hard question urgent: was this artifact actually built from the source we approved? The answer is SLSA, Supply-chain Levels for Software Artifacts, which attaches signed provenance to each artifact describing how, where, and from what source it was built. Provenance is expressed as a signed attestation, and once published for an artifact it is immutable and cannot be overwritten (Kusari). The artifact stopped being a passive output and became a verifiable claim about its own origin.

How it works in practice

A team's CI pipeline🚇CI PipelineDevOps & PlatformA CI/CD pipelineView reference → builds a container image once, tags it with the commit hash, and pushes it to a registry. That same image, byte-for-byte, is pulled into the test environment⚗️Test EnvironmentQuality AssuranceA testing environmentView reference →, then staging, then production. No environment rebuilds. When the image is built, the pipeline also generates SLSA provenance: a signed statement naming the source commit, the build steps, and the builder identity. Three months later a vulnerability🔓VulnerabilitySecurityA known vulnerabilityView reference → surfaces in a dependency⛓️DependencyTeam & OrganisationA cross-team or system dependencyView reference →. The team queries the registry for every artifact whose provenance lists that dependency, finds the affected images in minutes, and proves which production deployment📤DeploymentEngineeringA deployment eventView reference → shipped which build. Without the immutable artifact and its attestation, that audit would be guesswork against environments that may each have rebuilt differently.

Build artifact vs. its neighbours

• CI pipeline is the process that produces the artifact; the artifact is its frozen output. The pipeline runs and changes; the artifact, once built, never does. One pipeline run, one immutable artifact.
• Deployment is the act of running an artifact in an environment. The same artifact feeds many deployments across stages. The artifact is the noun; the deployment is the verb that places it somewhere.
• Library dependency📚Library DependencyEngineeringA third-party library dependencyView reference → is an input consumed during the build and baked into the artifact. The dependency is source the artifact incorporates; the artifact is the sealed result. Provenance is what links a finished artifact back to the dependencies inside it.

In the graph

In the Unified Product Graph, a build artifact sits in the engineering region as the immutable output of building. Two edges define its origin: service_produces_build_artifactServiceproducesBuild Artifacthierarchy ties an artifact to the service it embodies, and ci_pipeline_produces_build_artifactCI PipelineproducesBuild Artifacthierarchy ties it to the pipeline run that made it. Modelling the artifact as its own node, distinct from both the service and the pipeline, is what makes provenance queryable: you can walk from a running deployment back to the exact artifact, then back to the pipeline and source that produced it, which is the chain a supply-chain audit has to follow.