Security through transparency
authentik is an open source Identity Provider that unifies your identity needs into a single platform, replacing Okta, Active Directory, and Auth0. Authentik Security is a public benefit company building on top of the open source project.
The XZ backdoor incident spooked a lot of people. Not all PRs are innocent—even from long-standing contributors—and this one would have created a backdoor in a utility included in almost all Linux distributions, had it not been caught.
But “open source = more vulnerable to exploits” is the wrong takeaway—being open source can actually be an advantage for security-focused products.
The fact that this incident unfolded in the open meant that it was able to be caught by a community member and then fixed. Contrast this to what can happen with proprietary security products: you don’t get any visibility into the code, owners, or changes being made. Additionally, proprietary codebases often use the same open source libraries under the hood anyway - but you don’t get to know which ones, or even if they have been updated to recent versions.
The Okta and Auth0 codebases aren’t public and open to scrutiny, and yet they were both leaked on the dark web.
You don’t want to be in a situation where, as an end user, you have less information about the product you’re using than bad actors do. You would never put your trust in a cryptographic library that only would-be attackers have access to inspect—so why would you entrust your identity and access management to software whose source code you can’t examine yourself?
With open source you get transparency by default
Authentik Security is built on top of authentik, the open source project. The enterprise version is source available. When a product is built in the open, it’s clear to users and customers whether security is being prioritized (and if so, how). Transparency is the default and it is much more obvious when issues need to be addressed.
With walled-garden products, end users have to rely on the vendor to pay attention and be aware when things get breached (unlike when Okta had to be notified by thier own customers – more than once!)
You’re also reliant on the vendor to disclose responsibly and keep users up to date on remediation. Of course, an open source project’s community relies on the project’s leadership to do the same. And, there’s a valuable alignment: the philosophy that underpins building in the open also results in transparency in the event of security incidents.
We’ve seen too many examples of vendors not delivering on these responsibilities. You always have the option to take your business elsewhere, but if you’re doing so in response to a breach (or in response to a vendor’s response to a breach), you’re closing the stable door after the horse has bolted.
Whereas if somebody finds a vulnerability in authentik or discovers a breach, users can have more expectation of transparency around the vulnerability and the fix when the code is available. The resulting PR and technical reviews are there for all to see.
Building in the open
Operating transparently comes naturally when you build in the open. At Authentik Security, we assume everything is visible to everyone, all the time. That comes with responsibility: we have to define and uphold really clear standards around documentation and communication. Community contributors need clarity on what’s on our roadmap and why we may not implement something that seems at first glance reasonable.
We also have to be clear about how to interface with us, and be accountable when people do. Working on both an open source and enterprise version of the product means we get feedback from both open source users and customers, so we have to be efficient with processing it.
One of the perks of working in the open is we can also do things like publish the results of our pen tests. This is a big win from a security perspective for users and customers; we have to be upfront about any security issues found by us or the community, how we fixed them, and what they affected.
Building on community-maintained projects does come with risk
“… auditing source code is time intensive and often needs highly experienced domain and security experts … The XZ project was in that sense the perfect blind spot for how effort is typically allocated for security audits. Very deeply nested and important for every distribution due to non-obvious reasons, and in the state of only one maintainer and very few contributors or reviewers for years.” — Dirk Mueller, "What we need to take away from the XZ Backdoor"
The XZ example did expose a risk: the project had one volunteer maintainer, was not very active, and was therefore an easy target for a bad actor to exploit. Without dedicated, full-time staff on a project, it is possible for something like that to go unnoticed.
Additionally, take the recent example of Ladybird/SerenityOS: after more than five years, the maintainer of SerenityOS is forking the project and stepping down, to pursue the spinoff web browser, Ladybird. As forking stories go, this one is pragmatic and without drama:
“a small project became a big one, and started [to] cannibalize the bigger project. So the developer decided to take the growing project to its own space and let the other project thrive, too” — bayindirh on Hacker News
It does illustrate the risk of relying on a community-maintained project as part of an enterprise stack—not from a security perspective specifically, but the project may be forked, abandoned, or taken in a different direction. So, how do you get the benefits of open source security solutions without taking on so much risk?
Open core aligns company and community incentives
There is usually some healthy skepticism from the community when a business forms around an open source project. Everyone’s been burned before.
In the open core model, the underlying open source project is an important part of the business’ pipeline; the core of the project will always be open source, and the core is what supports the additional features and capabilities of the enterprise version. Therefore, we have a clear financial incentive to keep supporting the open source project. Instead of resigning ourselves to a state where either:
-
“Our entire open source infrastructure is held together by enthusiastic volunteers who don’t get the support they really should”
or
-
Everyone is beholden to vendors who may or may not have robust security posture (and may or may not tell you about it if they don’t and get breached)
The open core model is a middle ground between the safety of a business owning the project and prioritizing maintenance and security, and healthy, aligned incentives on the other.
The open source project’s flourishing is critical to the success of the company
The business model of open source was long-ago proven to work:
For Authentik Security, authentik’s open source edition is a marketing and sales asset: potential users can try out the open source version and inspect the code themselves without the friction of signing up for a demo/sales call/webinar.
We also don’t want individuals or those with small use cases to have to pay for the necessary core pieces for a full-fledged identity provider, which is why we support both enterprise organizations and homelab users with different versions of authentik. Requirements that generally come with scale (such as compliance and audit logging) are part of our enterprise edition.
We also became a public benefit company with intention and strategy, to avoid some of the gotchas that people fear when a business is built on open source. The charter of our business requires us to maintain the free, open source version, not place arbitrary performance-based constraints on the product, and not charge for previously free features. Users and customers get the benefit of a consistent vision for the project and a team of experts providing support, guidance, and maintenance.
It’s easier to place your trust in a company when its self-interest aligns with the community’s.
Another great benefit to authentik being open source and source available is the recruitment aspect; it's easier for us to get great people onboard when our code base is open source and source available. Developers get to show off their work publicly, even long after their tenure with our company as an employee, or in passing as an occasional community contributor. Compare this to most engineering jobs where after years of hard work, you often don't have anything to show for it, or sometimes can't even talk about the work you contributed.
We look forward to continuing to work with the community and our users on further developing authentik, with the benefits and inherent advantages of building in the open, building ever-stronger security through transparency.
We are interested to hear your thoughts on this topic, wherever you fall within the many user types of authentik. Leave some comments here, find us on Discord, or send us an email to [email protected].
Rebecca Dodd contributed to this post.