Open source security exposes the trust gap in closed systems

At a glance

What this is: Wazuh argues that open source software creates verifiable trust by replacing black-box assurance with public code review, community scrutiny, and stronger accountability across the software supply chain.

Why it matters: This matters because security teams cannot govern what they cannot inspect, and open source shifts the control problem from blind trust to evidence-based verification across build, deployment, and runtime.

By the numbers:

• Open source software powers 90% of the world’s web servers, according to Wazuh.
• Adoption rates for open source software reach up to 85% across industry software stacks, according to Wazuh.

Context

Open source security is fundamentally about verifiability. When source code, build practices, and dependency choices are inspectable, security claims can be tested instead of accepted as assertions from a vendor-controlled black box. That changes the governance problem from trust-by-contract to trust-by-evidence, which is increasingly relevant across software supply chains and cloud-native environments.

The identity angle is indirect but real: modern software supply chains depend on service accounts, signing keys, tokens, and build permissions that can be misused whether code is open or closed. Open source does not remove NHI risk, but it makes hidden dependency abuse, backdoor insertion, and supply-chain compromise more visible to defenders than closed systems typically allow.

The article’s starting position is typical for an open source transparency argument, but it is useful because it ties transparency to operational assurance rather than ideology. The strongest lesson is that openness helps only when organisations also govern the identities and secrets that move through the pipeline.

Key questions

Q: What breaks when software supply chains rely on opaque vendor trust?

A: The failure is that defenders cannot independently verify what was built, signed, or shipped, so malicious changes can persist until exploitation exposes them. In practice, this weakens patch confidence, delays detection, and turns the release process into a single point of trust rather than a verifiable control.

Q: Why do SBOMs matter for product security and compliance?

A: SBOMs matter because they show which components are present when a vulnerability emerges. They only add real value when they are complete, current, and linked to trustworthy change control, otherwise they become static documentation that cannot support incident response or supplier accountability.

Q: How should security teams secure open-source software before it reaches production?

A: Security teams should treat open-source software as an external dependency that needs continuous verification, not blind trust. Start with source vetting, component inventories, update discipline, and least privilege. Then add code review, SBOM generation, and CI/CD protection so vulnerable or malicious components are identified earlier, tracked consistently, and removed before they can be promoted into production systems.

Q: What is the difference between open source transparency and secure software assurance?

A: Transparency means the code and process can be inspected. Secure assurance means the organisation has evidence that the software, its dependencies, and its release path are controlled well enough to trust in production. One enables verification, the other proves the control environment is actually working.

Technical breakdown

Why code visibility changes the trust model

Closed source software asks defenders to trust that the vendor’s internal review, build pipeline, and release process are sufficient. Open source shifts that model because anyone can inspect implementation details, compare versions, and look for malicious changes or accidental weaknesses. This does not guarantee safety, but it increases the probability that flaws will be noticed, challenged, and independently validated. In practical terms, transparency improves auditability across the software lifecycle, which is especially valuable when software is embedded in infrastructure, monitoring, or remote access workflows.

Practical implication: require code provenance and review evidence for software that controls privileged or high-trust operational paths.

How supply-chain compromise survives in proprietary software

A proprietary product can hide a compromised build process, malicious update, or embedded backdoor until exploitation is obvious. That is the central weakness of opaque release pipelines: external defenders cannot independently verify what changed, how it was built, or whether the artifact matches source intent. In open ecosystems, the attack surface still exists, but public scrutiny can expose suspicious changes sooner and help validate whether a fix truly removes the issue. The mechanism is not “open source is safe”, but “open source makes tampering harder to conceal”.

Practical implication: pair software inventory with build attestation, dependency review, and artifact verification before deployment.

What transparency does not solve on its own

Open source visibility does not eliminate compromised dependencies, exposed credentials, or malicious maintainers. Security still depends on who can sign releases, who can publish changes, and what identities are trusted in the delivery pipeline. This is where the NHI intersection matters: tokens, signing keys, CI credentials, and service accounts remain high-value targets even when the code is public. Transparency helps defenders see more, but governance still has to control the identities and secrets that turn code into running software.

Practical implication: govern CI/CD credentials and signing keys as production-grade NHIs, not as low-risk developer tooling.

Threat narrative

Attacker objective: The attacker aims to exploit trust in software distribution so malicious code or hidden functionality reaches many victims through legitimate-looking updates or dependencies.

1. Entry occurs through opaque software supply chains where hidden build steps, compromised dependencies, or malicious updates can enter production without external detection.
2. Credential or update trust is then abused because defenders must accept vendor-controlled artifacts, signatures, and release processes without independent code verification.
3. Impact follows when the compromised software is deployed at scale, allowing persistence, surveillance, backdoors, or data exposure across many downstream organisations.

Breaches seen in the wild

• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
• SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.

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

NHI Mgmt Group analysis

Open source does not make trust disappear, it relocates it into evidence. The decisive advantage is not ideology but inspectability: defenders can validate code, review changes, and assess build integrity with far less dependence on vendor assurance. That improves the quality of governance conversations around provenance and assurance, especially where software sits inside critical infrastructure or identity-adjacent workflows. Practitioners should treat transparency as a control input, not a substitute for controls.

The real trust gap in closed systems is operational, not philosophical. When organisations cannot inspect source code or release mechanics, they cannot independently test whether a patch truly remediates the issue or whether a compromise has been fully removed. That weakness becomes acute in monitoring tools, VPNs, and other high-trust infrastructure because those systems often sit closest to privileged access paths. Practitioners should evaluate whether opaque software is creating an unreviewable control plane in their environment.

Software supply chain assurance now depends on identity governance as much as code review. Open source visibility helps, but the compromise still happens through credentials, signing keys, and pipeline permissions that act as NHIs. This is the named concept worth tracking: verification trust gap, the space between what software claims and what defenders can independently prove. Practitioners should close that gap by governing the identities that publish, sign, and deploy software.

Community scrutiny is useful only when it is operationally connected to response. The article is right to connect openness with faster detection and remediation, but that benefit depends on whether organisations can act on findings across their own environments. Many teams still struggle with dependency inventory, patch validation, and runtime monitoring after disclosure. Practitioners should align transparency with response discipline, not assume it is enough on its own.

Open source transparency is becoming a procurement and assurance issue, not just a developer preference. Regulators and buyers increasingly expect component visibility, SBOMs, and evidence that third-party software can be governed after release. That trend favors organisations that can actually verify what they run, but it also raises the bar for supply-chain assurance across every deployment path. Practitioners should make verifiability a buying criterion for software that touches high-trust operations.

From our research library:

• Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
• Software supply chain attacks were projected to cost organisations $60 billion in 2025.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Verification trust gap: Open source closes part of the assurance problem, but the real programme risk is still who can sign, publish, and deploy software. Teams should treat those publishing identities as production assets and measure whether their controls are actually reducing release-path trust.

Transparency does not replace supply-chain discipline. The practical test is whether your team can trace a package from source to runtime, prove who approved it, and detect drift after deployment.

For identity and security leaders, the lesson is straightforward: software governance now includes secrets governance, because the identities behind build, signing, and deployment are what turn inspectable code into trusted software.

For practitioners

• Review source visibility for high-trust software Prioritise code-available software for monitoring, remote access, build, and security tooling so teams can verify what the software does before it reaches production.
• Govern build and signing identities Treat CI credentials, signing keys, and package-publishing tokens as high-value NHIs and enforce least privilege, rotation, and offboarding for each one.
• Require artifact verification before deployment Verify hashes, signatures, and provenance evidence for packages and images before promotion into production or privileged environments.
• Maintain dependency inventories and SBOM review Track third-party components, map them to deployed services, and use SBOMs to identify where a compromised dependency would create the largest blast radius.
• Instrument runtime monitoring for opaque components Monitor endpoint, server, cloud workload, and container behaviour so security teams can detect changes that code review alone will not catch.

Key takeaways

• Open source reduces blind trust by making software behaviour and build assumptions more inspectable, but transparency alone does not make deployments secure.
• The strongest risk remains the software supply chain, where compromised build paths, opaque updates, and hidden dependencies can still reach production at scale.
• Practitioners should pair source visibility with provenance checks, SBOM review, runtime monitoring, and strict governance of CI/CD identities and signing keys.

Key terms

• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
• Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
• Code provenance: Code provenance is the verifiable history of where code came from and who or what created it. In security practice, it combines authorship, timestamps, signatures, and build lineage so teams can prove a change was trusted before it reached production.
• Activation Trust Gap: The activation trust gap is the difference between trusting data because it is protected and governing it because it is being reused. It appears when organisations move data from backup or archival systems into AI pipelines without reapplying access, sensitivity, and consumer controls.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners connect code transparency to the identities and credentials that move software into production.