Software visibility and build trust: what IAM teams need to know

TL;DR: Software teams often cannot explain what is inside a build at component level, and SolarWinds showed how malicious code can enter upstream, survive signing, and inherit trust downstream according to DigiCert. When visibility fades, trust becomes assumed rather than verified, and that breaks the basis for defensible software governance.

NHIMG editorial — based on content published by DigiCert: Software visibility is the missing control in build trust

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.

Questions worth separating out

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.

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.

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

A: They often treat visibility as reporting instead of governance.

Practitioner guidance

• 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.

What's in the full article

DigiCert's full blog covers the operational detail this post intentionally leaves for the source:

• How DigiCert Software Trust Manager ties visibility, vulnerability scanning, and signing into one governed workflow.
• What the article says about centralising trust decisions inside CI/CD pipelines rather than relying on downstream documentation.
• How the source frames traceability, approval, and release governance as a practical operating model for software teams.

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

Software visibility and build trust: what IAM teams need to know?

Explore further

View Full Forum →  |  NHI Foundation Course →