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.
Editorial analysis by NHI Mgmt Group, based on content published by DigiCert: “Software Visibility: You Can’t Secure What You Can’t See”.
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.
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 breaks when software teams cannot trace build provenance?
A: The release record loses its evidentiary value.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 8:12 am
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.
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.
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Software visibility is the missing control in build trust