Why Transparency Is Your Best Security Control

The Old Argument Against Transparency Was Already Incomplete​

There is a version of the security world that treats open source as a liability rather than an asset on the theory that publishing your code is equivalent to publishing a blueprint of your own vulnerabilities. It is an old argument and has never aged particularly well. One technology CEO recently told a reporter for ZDNet that “open-source code is basically like handing out the blueprint to a bank vault,” with every additional reader assumed to be a potential thief rather than a potential ally. I understand the intuition behind it, though I think it gets the underlying dynamic backward.​

Closed source does not eliminate the existence of vulnerabilities; it only narrows the population of people capable of finding them before an attacker does. Of course, serious vendors run internal audits, penetration testing and bug bounty programs, and some do this exceptionally well. The trouble is that a customer has no way to confirm any of it directly and is left evaluating a vendor’s account of its own security rather than the security itself. ​

AI Is What Turns Inspectability Into Verification at Scale​

Open source has always made software inspectable. In practice, that principle ran into a limit: Skilled reviewers are scarce, and most open source projects went years without a thorough independent audit simply because nobody had the hours.

AI is what removes that limit, and its effect runs in both directions. As the Open Secure AI Alliance has noted, AI can audit a codebase and surface critical vulnerabilities in minutes, a task that used to take skilled researchers weeks. Attackers can scan open repositories faster than ever, which is the backbone of the “transparency is liability” argument. But defenders and independent researchers can do exactly the same thing at the same speed against the same code, narrowing the asymmetry that used to favor patient, well-resourced attackers over stretched open source maintainers.​

Closed source software does not get this benefit in anything close to the same measure since its code is reviewed only by people the vendor chooses to let see it, on the vendor’s own timeline. Open source projects, by contrast, are increasingly supported by initiatives explicitly built around this new reality. GitHub’s Secure Open Source Fund reported that participating projects resolved over 4,000 CodeQL security alerts and blocked more than 100 exposed secrets in a single six-month period. This is what inspection looks like once it can scale, but it is only possible because the code was open to begin with.

Why Visibility Alone Is Not the Whole Model​

A customer can read every line of a public repository and still have no guarantee the binary running on their server was actually built from that code. Closing that gap requires provenance: Signed releases confirm who published a build, software bills of materials document every dependency inside it, reproducible builds let anyone regenerate the same binary from the same source and check that it matches. Cryptographic attestations tie a running system back to a verified origin, and transparency tells you what the code is supposed to do. Provenance confirms that what is running corresponds to it. Paired with continuous verification, rather than a one-time audit, those pieces together form a far more complete security model.​

The Black Duck 2026 Open Source Security and Risk Analysis Report, based on audits of nearly 1,000 commercial codebases, found that the average number of open source vulnerabilities embedded in an application rose 107% year over year, driven substantially by the sheer volume of code AI tools now allow developers to produce. That figure describes open source specifically, because open source is what the report was able to measure. However, it would be a mistake to read it as evidence that proprietary code is exempt from the same pressure. Closed codebases are almost certainly experiencing a comparable increase in volume and complexity. The difference is simply that one side can be measured and the other cannot.​

This is the pattern the TechRadar audit captured. The danger was never that OpenVPN’s source code was visible to the world but rather that certain vendors were running years-old forks of it without disclosure. A customer running a current, actively maintained open source implementation, with the provenance to prove it, could verify that fact independently. A customer running an outdated fork inside a closed application had no comparable way to know.​

Verifiability Is Becoming The Real Dividing Line​

It would be easy to mistake this for an ideological preference for open source rather than an operational point about how security gets verified in practice. To be clear: Openness is what makes verification possible in the first place, though it does not complete the job on its own. A closed system asks customers to trust a vendor’s account of what the code does. An open system lets customers, auditors and independent researchers confirm it directly on their own schedule rather than depending entirely on the vendor’s word.​​

I expect the next era of cybersecurity to divide along this line. Software whose security claims can be independently checked will sit on one side. Software that still asks customers to take those claims on trust will sit on the other. Vendors will increasingly be judged not by what they say about their own security but by how much of it they let someone else confirm.

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?