Why We Build In The Open

Every so often we hear (or get told) that Openlane being open source is a "security concern". The code sits on GitHub for anyone to read, including the people trying to break in, so it's a natural conclusion to arrive at. It's also a fair thing to ask a security-focused company, but I've come to like the question because the honest answer is more useful than either side in the debate suggests. Whether or not we'd chosen to publish a single line of code, Openlane would still be built mostly out of open source software, and so is nearly every product you'd compare us against. What we decided was whether you'd get to see the rest, which I think speaks to our company values more than it speaks to the security of the software.

An Old Argument

The debate about this topic is older than software; in 1883 Auguste Kerckhoffs argued that a military cipher should stay secure even if the enemy captured the device and learned how it worked, which puts all of its safety in the key. Andy Manoske, who spent seven years leading Vault Enterprise at HashiCorp, writes about the principle as "there is no security in obscurity," and notes that most of Vault's core cryptographic libraries were open source for that reason. If the encryption held up with its internals visible to the world, it met a standard nobody could argue with. His summary is that "in many cases, being open source forces your product to be better."

The modern form of the question is whether public source code helps defenders find and fix flaws faster than it helps attackers build exploits, because both happen. Reading our code could help an attacker understand the system, but keeping it private wouldn't stop anyone from probing the running application. The whole debate also assumes there's a large body of private code worth protecting, and in modern software there usually isn't.

Black Duck audits commercial codebases every year, and its 2026 Open Source Security and Risk Analysis covers 947 of them. 98% contained open source components. The report suspects the remaining 2% are mostly specialized legacy systems rather than anything built recently. The average application carried 1,180 open source components, up from 911 a year earlier, and the prior edition found that 70% of the scanned code, on average, had open source origins. Black Duck's own conclusion is about as blunt as a vendor report gets: "if you're building software today, you're building with open source."

Openlane is no exception - our core server is written in Go, runs on Postgres, and we have ~407 modules as I write this (we maintain 14 of them). The rest are a long tail of packages that each solve one problem well enough that we believed it shouldn't be solved twice (with only a few minor exceptions). Manoske makes the same point about infrastructure: "The most successful databases today, outside of Oracle, are all open source." Developers want to inspect what sits underneath their systems, and so do we.

When a vendor keeps its repository private, what it hides is the layer it wrote on top of the same public components everyone else uses. An attacker can already read the Postgres source and every library in the dependency tree, along with the published advisories for all of it. The code an attacker can't read in a closed product is the code specific to that product, which is also the code nobody outside the company has ever reviewed, and that you can't see when you buy their software - which we think is more about principles than it is about meaningful security.

Attackers Don't Need Your Repo

The source for Openlane's core server and orchestration services is on GitHub under the Apache 2.0 license. Cloning the repository gets you the application's source code and an empty database. Our hosted environment and the highly available service we offer our customers is a separate composition of services and systems. Your data is no more part of the repository than your email is part of your mail server's source code or any other creative analogy I could come up with that still results in the same fact: the design has to hold up even when someone knows how the lock is built.

Closed source gives an attacker less direct visibility, but that changes nothing about whether you can still test whether the application enforces the permissions it claims. The U.S. Department of War's open source FAQ asks whether hiding source code automatically makes software more secure, and answers plainly: "No."

For a web application the attack is often embarrassingly simple. Change the document identifier in a request and see whether the server hands back another customer's data. Missing authorization gets found that way all the time, and finding it doesn't require reading a line of the authorization code. Good software should be designed on the assumption that someone will study how it works, and publishing the code at least makes that assumption honest in our eyes.

Secrecy Has a Track Record

Proprietary software has a long record of serious vulnerabilities found and exploited without anyone reading its source. Microsoft's analysis of the 2021 Exchange Server attacks documents attackers using previously unknown flaws to read mailboxes and establish persistent access in customer environments. A joint advisory from CISA, the FBI, the NSA, and their international partners listed the vulnerabilities most routinely exploited in 2023, and it reads like a proprietary product catalog: Citrix NetScaler, Cisco IOS XE, Fortinet FortiOS, MOVEit Transfer, Microsoft Outlook. None of this settles which development model is safer, but it does show that attackers find serious flaws without a public repository to help them.

Sometimes opening the code is what finally exposes the flaw (and fix) - Borland's InterBase database shipped with a hardcoded backdoor account, and CERT's advisory in January 2001 confirmed that the vendor's own developers had put it there and that affected versions had shipped since 1994. Borland released the source in July 2000, and the Firebird project found the backdoor that following December. It sat unreported for roughly six years while the code was closed, and took five months to find once it wasn't.

What Open Doesn't Promise

I'd be remiss if I didn't hold my own argument to the same standard... publishing a repository doesn't make software secure, and availability for review says nothing about whether review happened. The same Black Duck report I mentioned earlier that found open source in nearly every codebase also found at least one known vulnerability in 87% of them, and the average codebase carried 581, more than double the year before. Those vulnerabilities sit in open source components that anyone could have read, inside commercial products that shipped them anyway. The risk rides in with the components regardless of how the finished product is licensed, which I think surrounds the crux of my view on the matter.

What decides the meaningful outcome is the process that surrounds the code (and is largely what compliance audits are meant to confirm in practice). Public access to a repository doesn't grant permission to merge changes or deploy them. Anyone can read the code or propose a patch; accepting that patch and releasing it are separate, controlled actions. Who can approve a change, how it's tested, who can cut a release, how the build and deployment systems are protected, and how dependencies are tracked and updated are the questions that matter for a SaaS product. NIST's Secure Software Development Framework addresses those practices, and they apply whether the source is public or private - a vendor with a private repository has the same thousand-odd components to keep current, you just can't check whether they do or not.

Manoske also lists bad reasons to be open source, and they're worth naming because they're common. One is treating the people who follow or contribute to a repository as a lead list; in his words, following a project "is not consent to be marketed to by an organization." The other is treating outside contributors as free labor and leaning on unpaid maintainers to hit your timelines. We depend on hundreds of projects maintained by people who owe us nothing, so we try to be the kind of neighbor we'd want: sending fixes upstream when we have them, and not expecting anyone's weekend, and despite being a scrappy startup, sponsoring as many of our dependencies as we can afford.

Why We Do It Anyway

Openlane is software you're asked to trust with the evidence behind your security program, and we're firmly rooted in the idea that you should be able to examine it. Manoske's best argument for open source is the one that applies to us: prospects "can run the code themselves (locally or otherwise), poke around, and get a sense of whether this is something that might solve their problem." You can run the open-source project yourself before you ever talk to us, and also why from day 1 we've always allowed for a free trial sign up. If you've read any of my other content you'll have already come to the conclusion I'm unabashed in my opinions: I'm exhausted from solving the problem multiple times already, and also want to use the software in the future regardless of what happens with the company we've built around it. Come at me. (Imagine me making intimidating hand motions.)

The same goes for the parts of the product that are easiest to oversell. We've felt what happens when connected scanners empty thousands of findings into a queue nobody triages, and a logo wall of integrations tells you nothing about that. Ours live in the public repository, where you can read what a connector does, including the expressions that decide which findings enter your program. We built Openlane around problems we'd lived through operating infrastructure and answering for it to auditors, and my DevOps post is a fair record of how that felt from the inside. The code is how you judge whether we solved them.

Source access is also an option held in reserve - in 2003 MITRE catalogued 115 open source applications in use across the Department of Defense and concluded that banning them would damage defensive capability, from security tooling to the ability to patch quickly after a new attack. For a business the logic is smaller but similar. Roadmaps get reprioritized and companies get acquired, and access to the source keeps the option of maintaining the software yourself, provided you have the people to do it.

A repository still can't tell you which version is deployed or who can reach production, and being open source doesn't excuse us from answering those questions. Put them to us, and put them to every other vendor you evaluate, along with one more: how much of your product is open source, and can I see the rest? Ours is on GitHub.