OpenTelemetry started as a tracing standard for distributed systems and has grown into the default instrumentation API for almost every modern language and platform. Its natural home is application observability, where spans describe requests flowing through services. Less discussed is its fit for CI/CD and supply chain observability, where spans can describe builds flowing through pipelines, packages flowing through registries, and artifacts flowing from commit to deployment.
The mental shift is small but consequential. Once you accept that a pipeline run is a trace, that each stage is a span, and that packages, artifacts, and commits are resources with semantic attributes, the rest of the OpenTelemetry toolchain becomes available. You can query supply chain data with the same languages you use for application traces, correlate pipeline events with runtime events, and produce a single graph of how code becomes running software.
The tracing model for pipelines
A pipeline run starts with a commit and ends with a deployment. Between those two events, dozens of steps produce intermediate artifacts, consume dependencies, and make decisions based on policy. Modeled as a trace, the commit is the root span, each stage is a child span, and each substep is a grandchild span. Errors and decisions are recorded as span events. Inputs and outputs are recorded as span attributes.
That model maps cleanly onto the structure of modern CI/CD platforms. GitHub Actions jobs and steps become spans naturally. GitLab CI stages and jobs become spans naturally. Jenkins pipeline stages become spans with minor instrumentation effort. The OpenTelemetry SDKs make the spans easy to produce; what takes discipline is settling on a consistent semantic convention across tools.
Semantic conventions for supply chain spans
OpenTelemetry's strength is that attributes follow a standard semantic convention. For HTTP requests, that convention is mature; for pipelines, the conventions are still evolving, and most production teams adopt a pragmatic subset from the CI/CD Observability working group and extend it locally.
A workable attribute set for pipeline spans covers five categories.
Identity attributes — cicd.pipeline.name, cicd.pipeline.run_id, cicd.job.name, cicd.runner.type — describe what the span is and where it ran. These map directly to the underlying CI platform's concepts and should not require transformation.
Source attributes — vcs.repository.url, vcs.commit.sha, vcs.branch.name, vcs.author.email — describe what the pipeline is building. A supply chain trace is nearly useless without these because every downstream question eventually pivots back to the source commit.
Artifact attributes — artifact.name, artifact.version, artifact.digest, artifact.registry — describe what the pipeline produced and where it went. The digest attribute specifically deserves emphasis; it is the cryptographic anchor that ties a span to a verifiable artifact in downstream systems.
Dependency attributes — package.ecosystem, package.name, package.version — describe what the pipeline consumed. Teams that emit a span per dependency resolution event get the best supply chain visibility but also the most spans; most teams start with an aggregated span per dependency manifest and iterate from there.
Policy attributes — policy.name, policy.result, policy.severity — describe the decisions the pipeline made. When a policy gate blocks or allows a build, the span records it with enough context to reconstruct why.
Propagation across the pipeline
Tracing a single pipeline run is useful; tracing across pipelines, registries, and runtime closes the loop. OpenTelemetry's context propagation model supports this, but requires discipline at the boundaries where traces hand off.
The two critical boundaries are registry publish and deployment. When a pipeline publishes an artifact, the trace context should be embedded in the artifact metadata or in an attestation that accompanies the artifact. When a deployment system pulls the artifact and starts running it, the deployment trace should continue from the same context.
In practice, several teams embed the trace ID in the in-toto attestation that accompanies a signed artifact. Consumers of the artifact — deployment systems, runtime scanners, incident responders — read the attestation, extract the trace ID, and correlate back to the pipeline run that produced the artifact. This is the mechanism that turns a static SBOM into a living record of software provenance.
Querying supply chain traces
Once the traces are flowing, the same backends that serve application tracing — Grafana Tempo, Honeycomb, Jaeger, Lightstep, and commercial APM platforms — serve supply chain tracing. Queries that prove their worth repeatedly fall into three categories.
Composition queries answer "what did we build." Given a commit SHA, the query returns every artifact produced from it, every registry it was published to, and every deployment that runs it. Given an artifact digest, the query returns the pipeline that produced it, the source commit, and the dependency set that was resolved at build time.
Drift queries answer "what changed." Given two runs of the same pipeline, the query returns the delta in dependencies, durations, and outcomes. Drift queries are where performance and security concerns meet. A build that suddenly takes three times as long, resolves different versions, or produces artifacts with different sizes deserves attention for both reasons.
Attribution queries answer "what is running where." Given a production incident, the query returns the pipeline run, the source commit, the author, and the dependency set responsible for the running code. The ability to move from a runtime symptom to a source cause in minutes is the most concrete operational payoff of pipeline tracing.
Sampling and cost
Pipeline spans can outnumber application spans by an order of magnitude, and naively shipping every span to the trace backend is expensive. Two sampling strategies cover most needs.
Always sample at full fidelity for failed runs, runs that produced artifacts deployed to production, and runs that touched signing or release infrastructure. These are the spans you will need in an investigation, and paying for them is worthwhile.
Sample at a lower rate for successful development and feature-branch runs. A 10 percent sample preserves enough data for trend analysis and tuning without blowing up the budget.
Avoid head-based sampling decisions for supply chain traces. A tail-based sampler that looks at the full trace before deciding whether to keep it produces much better data because supply chain signals often hide in the last few spans of a run.
Combining traces with SBOM and attestation data
Traces tell you what happened; SBOMs and attestations tell you what is true. The combination is more powerful than either alone. A trace backend that can correlate a span by artifact digest to an SBOM and an attestation is the foundation of a supply chain observability platform.
The practical pattern is to store SBOMs and attestations in a dedicated service, then enrich trace backend queries with lookups against that service. When a trace pivots from "this build produced artifact sha256:…" to "here is the SBOM of that artifact and here is the attestation signed by the pipeline identity," the investigation workflow becomes radically faster.
Operating the system
Instrumentation decays without care. Treat the OpenTelemetry pipeline as code, version it, and review span emissions the same way you review application telemetry. New tools and new pipeline stages should come with instrumentation or they should not land. The payoff compounds.
How Safeguard Helps
Safeguard is the SBOM and attestation service that makes OpenTelemetry supply chain traces complete. Our API accepts span attributes, artifact digests, and pipeline identities and returns the full software composition, provenance, vulnerability, and policy context for the corresponding artifact. Trace backends enrich spans with Safeguard data so that a single query moves from pipeline events to the real supply chain graph. Teams using Safeguard with OpenTelemetry get a unified observability surface that spans source, build, artifact, and runtime without gaps.