Notifications
Clear all
Topic starter
24/06/2026 11:22 pm
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
25/06/2026 8:12 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Software visibility is the missing control in build trust
