Software visibility is the missing control in build trust

At a glance

What this is: This is a blog post arguing that build-time software visibility is the missing control for trust, because signed output can still contain unverified or malicious upstream components.

Why it matters: For IAM, PAM, and NHI practitioners, the lesson is that trust decisions are only as defensible as the evidence behind them, and opaque build inputs create governance gaps that signing alone cannot close.

Context

Software visibility means being able to see and trace what enters a build at component level, not just knowing the final artifact name or publisher. The article argues that when that visibility fades, trust shifts from something verified to something assumed, which creates a governance problem before release rather than after.

The identity security connection is governance, not just code hygiene. If teams cannot explain where components came from, how they were approved, and what risk they carry, then software release decisions lose the traceability that IAM, IGA, and control assurance depend on.

Key questions

Q: How should teams govern trust when build contents cannot be fully seen?

A: Teams should treat incomplete build visibility as a release-governance failure, not a documentation gap. If they cannot identify what entered the build, they cannot justify why the artefact was trusted. The right response is to require provenance, approval evidence, and component traceability before trust is extended downstream.

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 breaks when software teams cannot trace build provenance?

A: The release record loses its evidentiary value. Teams can no longer explain which components were included, how they were approved, or why specific risk decisions were made. That breaks accountability, weakens auditability, and leaves security teams responding after the software has already been trusted and deployed.

Q: What should security teams do when a trusted build might contain unverified code?

A: They should halt reliance on the trust label and inspect the build record itself. The priority is to identify where unverified code entered, whether it was approved, and whether the release decision was made on evidence or assumption. Containment starts by re-establishing the facts behind the artefact.

Technical breakdown

Why signed software can still hide upstream risk

Code signing proves publisher identity and protects integrity after release, but it does not inspect every component that entered the build before signing. If malicious or vulnerable code is already embedded upstream, the signature can faithfully preserve a compromised artifact. That is why visibility must precede trust application, not follow it. The technical failure is not the signing step itself, but the blind spot before signing where untrusted inputs become part of a trusted output.

Practical implication: treat signing as preservation of trust, not proof that the build was clean.

How build invisibility turns into release-time trust debt

When build inputs are not traceable, every downstream decision inherits uncertainty. Components, dependencies, and contributed code become difficult to attribute, which means teams cannot reliably tell whether a risk is new, accepted, or already mitigated. That erodes the decision record behind release approvals. In practice, the organisation accumulates trust debt, because each shipped artefact depends on assumptions that were never validated at the point of entry.

Practical implication: enforce component traceability before release decisions are allowed to rely on trust.

Why build visibility supports governance, not just detection

Visibility changes the unit of control from the final binary to the contents and provenance of the build itself. That gives teams evidence to connect risk to specific components, approval paths, and sign-off decisions. It also supports defensible accountability when customers, auditors, or regulators ask what was shipped and why it was allowed to ship. The governance value is that trust becomes auditable rather than implied.

Practical implication: make build provenance part of release governance so decisions are backed by evidence.

Threat narrative

Attacker objective: The objective was to embed malicious code into a signed, trusted software release so it could propagate downstream without immediate detection.

1. Entry occurred upstream when malicious code was introduced into the build process before signing, rather than at the point of final distribution.
2. The compromised component blended with legitimate build material and survived compilation, packaging, and signing without obvious artifact-level anomalies.
3. Impact followed when the trusted release was distributed into customer environments at scale, including critical infrastructure and government settings.

Breaches seen in the wild

• GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Build visibility is the control that determines whether trust is earned or merely inherited: signing confirms identity and integrity, but it cannot compensate for unseen build inputs. When organisations cannot trace what entered the release, trust becomes a downstream assumption rather than an upstream control. That is a governance failure, not just a tooling gap, and practitioners should treat visibility as a prerequisite for defensible release authority.

Software trust debt accumulates whenever approval happens before inspection: once hidden components are allowed into the build, every later control has to work around uncertainty. Vulnerability scanning, sign-off, and release policy all become weaker when they operate on artefacts whose contents were never fully understood. The practical conclusion is that build provenance must be treated as part of identity and access governance for software supply chains.

Software visibility is the missing control because it connects provenance, risk, and accountability in one evidence chain: teams can only answer customer, partner, and regulator questions when they can show what was included, where it came from, and who accepted the risk. That makes visibility a governance primitive, not a reporting convenience. Practitioners should expect trust programmes to move upstream toward evidence-based release decisions.

Build trust becomes defensible only when the release process can explain itself: opaque builds force security teams into after-the-fact response, while visible builds allow them to govern before distribution. The strongest programmes will stop treating signing as the control boundary and start treating build composition as the decision boundary. For practitioners, that is where software trust becomes measurable.

Traceability is the named concept this article sharpens: without a traceability layer across build inputs, approval paths, and signing, software teams cannot demonstrate why a release was trusted. That is why visibility should be measured as an assurance property, not just a developer convenience. The operational question is whether the release record can survive scrutiny without relying on assumptions.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• By 2029, 40% of enterprises that successfully implement zero trust within cloud service provider environments will rely on the advanced visibility and control capabilities offered by CNAPP solutions.

What this signals

Build provenance is becoming an assurance boundary: teams that can trace components, approvals, and signing decisions can defend their releases under scrutiny. Teams that cannot do that will keep inheriting trust they have not actually verified.

When visibility is missing, software governance shifts from preventative control to post-release explanation. That is the same pattern identity teams see whenever an access decision is made without enough evidence to prove why it was safe.

Traceability across build inputs, approval paths, and signing is the operational concept to watch: it turns software release from an act of faith into an auditable governance process. For practitioners, that is the difference between trusting a release and being able to defend it.

For practitioners

• Map build inputs to release trust decisions Document which components, dependencies, and contributed code enter each build, then require the release record to show how those inputs were reviewed before signing.
• Separate signing from trust approval Use signing to preserve integrity, but gate trust decisions on prior validation of build contents so a valid signature does not mask an unverified payload.
• Record component provenance at build time Capture source, approval, and usage context when code enters the pipeline so investigators can trace exactly where risk was introduced.
• Make visibility part of CI/CD governance Embed build inspection and approval evidence into pipeline controls so trust is applied from the build record rather than from post-release assumptions.

Key takeaways

• The article argues that software risk starts earlier than many teams assume, at the point where unseen build inputs are allowed to become trusted artefacts.
• SolarWinds is used as evidence that malicious code can survive the build process, pass through signing, and inherit downstream trust at scale.
• Practitioners need build provenance and component traceability before signing, otherwise release governance remains based on assumption rather than proof.

Key terms

• Build provenance: Build provenance is the evidence chain showing where a software artefact came from, how it was assembled, and which identities and keys were used. It is essential when teams need to prove that an embedded release was produced from trusted source and controlled inputs.
• 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.
• Code signing: Code signing is the process of attaching cryptographic proof to software so recipients can verify origin and integrity. In CI/CD, it turns release trust into an enforceable control instead of a human promise, and it only works when the signing step is mandatory and protected.
• Trust debt: Accumulated security risk created when access assumptions are not revalidated quickly enough for the pace of modern automation. In identity programmes, trust debt appears when roles, secrets, or agent permissions persist longer than the environment that justified them.

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.