Software visibility is the missing control in build trust

At a glance

What this is: This is an analysis of software visibility in the build pipeline, with SolarWinds used to show how hidden components can inherit trust downstream.

Why it matters: It matters to IAM practitioners because the same governance failure pattern appears when machine identities, secrets, and release trust are granted without clear evidence of what is actually present and approved.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read DigiCert's analysis of software visibility and build trust

Context

Software visibility means knowing what is actually inside a build, where it came from, and whether it should be trusted before release. In software supply chain security, the problem is not signing itself, but signing after trust has already been assumed.

For IAM and security teams, the same governance gap appears whenever downstream controls certify something they cannot fully inspect. That is why software release trust, CI/CD controls, and machine identity governance belong in the same conversation.

The article uses SolarWinds to show that the failure began upstream, long before final signing, which makes the starting point typical of modern supply chain risk rather than an unusual edge case.

Key questions

Q: How should security teams govern trust in software builds when visibility is incomplete?

A: Treat incomplete visibility as a release-risk condition, not a documentation gap. Teams should require provenance, component inventory, and approval evidence before signing or deployment. If the build cannot be explained at the component level, trust has already been extended too far and should be bounded until the release can be verified.

Q: Why does code signing not solve supply chain risk by itself?

A: Code signing confirms publisher identity and protects artifact integrity after signing, but it does not prove the build was clean before signing. If malicious code enters upstream, signing can preserve a compromised artifact with perfect authenticity. Practitioners need visibility and provenance controls earlier in the pipeline.

Q: What do teams get wrong about software visibility in CI/CD pipelines?

A: They often treat visibility as reporting instead of governance. Visibility only matters when it changes who can approve, sign, or release software, and when it creates evidence for every trust decision. Without that enforcement, teams can see more and still know too little to manage risk.

Q: What should organisations do when a release cannot be fully traced to its inputs?

A: Pause trust at the release boundary until the artifact can be tied back to source, dependencies, and build approvals. If traceability is missing, the safest assumption is that unknown content may already be embedded. That is especially important where signed releases move into critical or regulated environments.

Technical breakdown

Why build visibility fails before code signing

Code signing verifies who produced an artifact and whether it changed after signing. It does not prove the build was clean, complete, or free from embedded malicious code. In a modern pipeline, untrusted or compromised content can enter through source, dependencies, scripts, or build steps, then move forward as if it were legitimate. That is why visibility must exist before trust is attached to the output. Without component-level inspection, the signing event becomes a preservation step for something that may already be compromised.

Practical implication: inspect build inputs and dependency provenance before signing, not after release.

Software supply chain trust and upstream contamination

Upstream contamination is the point where malicious or unwanted code becomes part of the trusted software path. Once inside the build, it can inherit legitimacy from the pipeline itself, especially when release controls focus on the final artifact instead of the contents that produced it. This is a supply chain trust problem, not just a detection problem. The real architectural failure is that downstream consumers assume the build system validated more than it actually did.

Practical implication: treat provenance, dependency integrity, and build attestation as controls on trust inheritance.

CI/CD visibility as a governance control

CI/CD visibility is not just an engineering convenience. It is a governance mechanism that shows what entered the pipeline, who approved it, and whether the release decision is defensible. When visibility is centralised with policy enforcement, teams can separate acceptable risk from unknown risk and apply release gates based on evidence. That creates an auditable chain from source to artifact to deployment, which is the only way to make trust operational at scale.

Practical implication: tie release approval to traceable build evidence, not to process memory or informal review.

Threat narrative

Attacker objective: The objective was to distribute compromised software at scale while benefiting from the trust attached to a signed release.

1. Entry occurred when malicious code was introduced into the build process before the software was signed.
2. Escalation happened as the code moved through compilation, packaging, and release with the same trust as legitimate components.
3. Impact followed when thousands of customer environments received and ran the compromised software as a trusted update.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Software visibility is a trust control, not a reporting feature. When teams cannot see what enters the build, signing only preserves uncertainty at scale. The SolarWinds lesson is that downstream assurance collapses if the release pipeline certifies artifacts it never truly understood. Practitioners should treat visibility as a prerequisite for trust, not an optional layer after development.

Upstream contamination is the failure mode that matters most. The important question is not whether a final artifact was signed, but whether the build content was already compromised before trust was applied. That is the governance assumption that fails here: release controls presume the thing being released has been sufficiently examined. Practitioners need governance over provenance, dependency intake, and build attestation.

Software trust and identity governance now intersect at the pipeline boundary. Release processes increasingly rely on machine identities, service accounts, and CI/CD permissions, which means the same over-privilege problems seen in NHI programmes can undermine software assurance. The issue is not just code quality. It is whether the identities driving the build have bounded, auditable authority. Practitioners should review build trust as an identity problem as much as an engineering one.

Defensible trust requires evidence, not assumption. Organisations now face pressure from customers, regulators, and internal risk teams to explain what entered a release and why it was allowed through. That shifts the programme from reactive response to governance maturity. Practitioners should be able to trace any shipped artifact back to its components, approvers, and policy checks.

Build trust debt: When organisations keep shipping while visibility degrades, they accumulate unresolved uncertainty in every release. The debt is not only technical. It is governance debt that grows each time a build is trusted without proving what was inside it. Practitioners should treat hidden build content as a compounding exposure, not a one-off exception.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• For a broader governance lens, see NHI Lifecycle Management Guide for lifecycle visibility, rotation, and offboarding controls.

What this signals

Software visibility is converging with machine identity governance. When build systems rely on service accounts, tokens, and signing permissions, the same control gaps that hide NHI sprawl can hide release risk. With only 5.7% of organisations reporting full visibility into service accounts, according to the Ultimate Guide to NHIs, the operational problem is no longer just software transparency. It is identity traceability across the pipeline.

Build trust debt: Organisations that keep shipping with incomplete provenance create a hidden backlog of releases they cannot fully explain later. That matters for audit, incident response, and executive assurance because the organisation loses the ability to prove what was trusted and why. The next maturity step is not more scanning alone, but traceable release governance tied to policy and evidence.

For practitioners

• Map the build trust boundary Identify the exact point where source code becomes a trusted release artifact, then require evidence at that boundary for dependencies, scripts, and generated components.
• Audit pipeline identities and approvals Review which service accounts, tokens, and release permissions can move code through CI/CD without independent evidence checks, and remove broad standing authority.
• Require provenance before signing Block signing until the build has traceable component provenance, dependency integrity checks, and an approver record tied to the release artifact.
• Create release traceability records Keep an auditable chain from source commit to packaged artifact to deployment so investigators can reconstruct what was trusted and when.

Key takeaways

• Software supply chain risk often begins before signing, when unknown code is allowed into the build and then inherits trust downstream.
• Visibility is a governance control because it turns release trust into an evidence-based decision rather than an assumption.
• Teams should bind signing, provenance, and pipeline identity controls together so no artifact is trusted without a traceable build history.

Key terms

• Software Visibility: Software visibility is the ability to see what components, dependencies, scripts, and identities are involved in producing a release. It matters because trust decisions depend on evidence, not assumptions. In practice, visibility must exist before signing or deployment if teams want defensible assurance.
• Upstream Contamination: Upstream contamination occurs when malicious or unwanted code enters the build path before final release controls are applied. The artifact may still look valid after signing, which is why the weakness is structural. The risk is that downstream trust preserves an already compromised input.
• Build Trust Boundary: The build trust boundary is the point at which software stops being a changeable input and becomes a trusted output. That boundary should be enforced with provenance, policy, and approval evidence. If it is unclear where the boundary sits, release trust is already too loose.
• Release Traceability: Release traceability is the ability to connect a shipped artifact back to its source, dependencies, build steps, and approvers. It turns software governance into an auditable chain of custody. Without traceability, security teams cannot reliably prove what was trusted or why.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: Software visibility is the missing control in build trust. Read the original.