BSidesSF 2026 - Building an open source security... (Fletcher Heisler, Marcelo Elizeche Landó)

Welcome to B-Sides, day two, theater seven, presentation two at 12:00 noon. We're going to be talking today about building an open source security project with 1 million plus installations with Fletcher Heisler and Marcelo Elizondo. Cool. Thank you very much. This is working out. There we go. A little bit closer. Um so the ultimate title here uh would be the seven and a half-ish lessons that we learned scaling up an open source project. Uh we're going to be talking about our path in doing that and hopefully that will help some of you if you have open source projects or you're looking to spend more time supporting one or building one up. Uh it's not the only path, but some things that we've

we've learned along the way. Uh we're also going to in keeping with the theme this year, uh I will pre-commit so that I don't back out, uh end with a musical number uh to the tune of a modern major general, uh concluding, you know, us wrapping up what we've we've talked about here. Uh so who are we? I'm Fletcher Heisler, the CEO of Authentic Security. Um so we're going to be talking about Authentic Security which supports Authentic, the open source project, but really just in the context of how those two pieces work together. Um previously I founded Thunder Two for AppSec training for developers uh and Real Python which is a set of resources and community for uh

also developers, web developers. Uh and in my little free time, I have lots of silly side projects I build like taser chess. Uh so I have a a channel uh Everything Is Stacked where you can watch me get shocked a lot. Yep, I'm Marcelo Elizondo. Uh I'm a uh software engineer at Authentic. Also, I uh come from the open source world. I uh have been doing a lot of open source projects and civic tech projects. Uh so I came for to this talk from both sides as an open source users and now as a maintainer. So, this is just a quick shot from our GitHub page. We're going to be talking about Authentic, uh, the open source

project. Um, what is it? Uh, it is an identity provider. Um, so if you're familiar with similar, it's just offering single sign-on. You log in, you can access all your applications, uh, self-hosted. Um, and so we have a lot of home lab users who use this to, um, organize all of their infrastructure and applications and access everything. Um, but also for larger groups and companies and so forth. That is impressive. Um, so a little bit about the project history. So, uh, our founder, uh, and now CTO Jens Langhammer, is based in Germany. Um, he was a an infrastructure engineer at Yelp. Um, and so he, in his part-time, uh, you know, free evenings and weekends, uh,

started building out Authentic as sort of an experiment around identity and access. Um, he didn't really see anything that that worked the way he wanted it and was kind of just tinkering around in Python, uh, on his own and with a couple friends for the first couple years. Um, I don't recommend building an identity provider from scratch. Uh, you can imagine it's a lot of protocols, a lot of I see you got, uh, a lot of specs to maintain, um, just a wide-reaching project. So, a lot of open source projects are more of a a point tool and that's probably a much easier place to start. Um, but Jens being the the powerhouse that he is,

spent two, three years building out a lot of the core functionality, uh, of an IDP, um, and then actually shared it first on the self-hosted, uh, subreddit. Uh, this is back in 2022, um, and got a lot of community reactions to this. Uh, really positive folks wanting to get involved, wanting to run it, um, lots of comments. So, uh, in addition to that, he also had a couple folks from venture capital reach out. One firm that basically helps, you know, specializes in taking open source projects and helping form a company around them, an open core company. And so, our first lesson learned is your side project could become your full-time job. Caveat that funding does help for that. But

Jens decided to give away some equity in the company in, you know, return for help setting up that company and being able to go full-time, pay himself a salary. His first employee was a long-time Home Lab user and community power user member. And so, started building up a team around that as well to help focus on building out Authentic full-time once we saw that there was a lot of wide-ranging interest from the community. So, these were our sort of GitHub stars. You can see 2022 that things start ramping up and by 2024 more of us had joined. We had a a small but full-time team dedicated to it. And we kind of figured this was like slow but steady.

We're going to continue on this path for for a long time. Note the X axis here. Mid-2024 we were fortunate enough to be the number one trending GitHub project as the the open source GitHub page for a couple weeks before the algorithm kind of turned it out. And so, that was a big step function for us of we started from a core set of users and experts. We all kind of knew each other to very quickly scaling up to a a wide-ranging community in a lot of different places and figuring out quickly how to manage that as as a small team still. I'm going to hand it off to Marcelo to talk a little bit on the

community side. Yeah, I'm going to talk a little about the community. Like listen to as your community grows, meet them where they are. So, uh as most projects, it start the community started just in GitHub issues. But, as the community start growing, start showing some growing pains. And Yeah, you need to have different channels for different kind of users. Because you have users that only want to, I don't know, install and run the the project and some users that want to understand the internals and even contribute to that. Like both both users and use cases are totally valid and you need to meet them where they are. The community asked for a Discord channel, so we created one.

But, also we have other channels like especially I will say it like the subreddit that emerge on their own. It was something created by the community and now it's one of the most active places where people go and to talk or try to figure out and about authentic about the the IDP. So, in that case, I can just the thing we need to like you need to try to make your users where they are. Yeah, different channels help. Especially like in open source project, the communication is key. So, lesson three. Prioritize and respond to your community. In our case, we have weekly backlog issue meeting. So, we we have a a call and we try to triage

and prioritize prioritize issues and bugs that the community support. Because if, you know, if the people are, I don't know, complaining or are having issues understanding something and you don't take care of that, like that's not a community. So, you need to prioritize that. Um so, uh in that case, uh we also like not everything uh comes uh it's it's it's easy. Uh especially lately, we had some I will say uh low-quality AI reading uh bug reports that take times to uh trash and to uh take care of that. Uh also, um it's not something that happened a lot, but sometimes you I think in most uh open-source project, you have uh some users that doesn't understand uh exactly

how open source work, and they expect uh enterprise uh support level uh for free. But, I I can we can say that uh in our case, our community those cases are really rare, so we were fortunate enough. Uh but, yeah, the the important part is having the channels to communicate with your community in that case. Uh that helps. So, uh another good thing about uh having an open-source community is that sometimes the road map of the product uh comes uh comes from the community. It's uh like this is an example like this is a feature request from the community that was uh to add Telegram as a social uh login. And, you know, this is a uh um feature

that probably we will never prioritize because it's not something that uh we don't use Telegram for that, but we have a huge part of our community that use Telegram for that, and you can see in the reactions there, like it was a really uh a lot of people wanted this feature, so we put uh that in the road map. And, yeah I'm the community is happy with that, and so that's pretty cool. Uh so, uh I'm going to talk a little more about the the the tech stack and the fourth lesson that is the best stack is the one that you already know. Uh but be prepared to evolve. Uh um Authentic has started like a pure

Django project and in and at that time I we think that was the uh correct uh way to do it because uh James was really proficient uh in Django. So, that allows him to move quickly and to ship features. Uh but as the project start uh growing, we uh encountered some some performance issues, especially I will say in with with the LDAP synchronization. So, uh that was a kind of a little slow in Python. So, we had a partial rewrite of some part of the project in Go lang. Uh and yeah, then that helps a lot. Uh but the important part is that most of the project is still uh as a a Django project. And we

have some parts that are in Go. Um uh one funny part of that is that now we have um an open PR that uh we call it the coop that basically is a Rust rewrite of some part of the of the Go Go rewrite. Now, we are rewriting in Rust because that's something that you do now. But the thing the important part is that uh we think is the right tool because our early numbers show that uh it's slashed the memory consumption uh almost by half in some parts. So, that's something that we are doing. Another thing that uh changed uh during the time is that uh when the project start, uh we had uh we have been using Redis, but

uh as the project continue and we had different kind of users and organizations, uh Redis was were giving more problems than solutions. So, we had to get rid of that and in our case, that was a good thing, especially because Postgres filled most of our needs and also um especially if because we are big in the self-host host community, keeping the architecture simple um it make you know um easier product to maintain. Um also, I'm I want to talk a little more about the packaging. Like now you can officially install Authentic from Docker Compose and Kubernetes. That was a deliberate choice because in the self-host and infrastructure community, most of the users are it's that is the

way that they install things. We also have an AWS cloud uh platform for me a template. And another good thing from the community is that we have a Digital Ocean one-click app that was that is maintained by the community. So, that's another way to install Authentic. Uh and yeah, and in general like looking back, I think that um that could be one lesson is that the language choice uh um there's a little blog post about that that Um I think we think that Python was a really good choice because it's a popular language and that allows to more of the community to being involved in that. So, now I'm going to the fifth lesson. Uh

Secure and transparent is tricky uh tricky balance, but worth the effort. So, uh how we handle security because building a security product in the open, it's uh it puts you sometimes in a weird position uh where you have to, you know, uh all the code is there, like everybody can see it. So, uh not only the users, also people looking for vulnerabilities. But, we think that uh when we you have more eyes looking at the code and finding bugs, it's better than obscurity. One thing that we do uh is that uh we have um regular independent pen test and we publish the results. Like Like we don't have to, but we do that because uh if we are asking people to

uh trust us their uh identity uh infrastructure, I think the best thing that you can do is to be transparent about it. Uh we also have uh I will say a pretty uh it was a it's a pretty um standard uh uh um uh responsible disclosure policy. Um like if you have a security bug, you can uh fill a report, and we are going to uh assess that threat and fix that. And we communicate uh like the policy say 24 hours prior, so people have time to organize and to apply the the patch or the fix. But, usually it's more days, like 4 days uh before we announce that we are going to have uh security issue.

And we assign CVs for that. Um one thing that I think it's uh I will say we are pretty fortunate to is that uh our community understand that, you know, having CVEs it's not necessarily a bad thing. It's meant that you have a uh a responsible uh process of how to handle this kind of stuff. Um this is a screenshot from the subreddit. So, you know the I think it's something you got memes that are well-intentioned and it's it's fun to have that in the community. Nope. That's right. Um yeah, I want to talk about uh some of the the business aspects of supporting an open source project as well. Um so starting with number six, carefully

consider licensing trade-offs early on. Um we started out GPL licensed as a side project because Yance happened to be somewhat familiar with that. Uh when we formed a company around that, we did a lot more research and debate uh decided to license to re-license MIT. Um that comes with trade-offs, they all do. Um you know, we almost expect that other people will take our code and figure out ways to make money off of it. Uh but we felt that MIT being kind of the the gold standard of as open uh open source as possible uh was the right way to go. Um now we're an open core company. What does that mean? We have uh major open

source components. You know, 99% of of the code that we work on and release is entirely open source. Uh we have an enterprise folder in that same repo that is uh copywritten content that's licensed and what we sell subscriptions to as a company. Um but that also means there's, you know, this ongoing trade-off of what parts do you open source and so forth. Um another thing that I think trips people up too late in the process is dependency management, dependency license management specifically. So you have to think about as you are pulling in code or you're vibe coding and pulling in packages, uh what might be proprietary and then your users or end customers are also relying on, you know,

potentially some really complex licensing uh down the line. So we have to keep a very uh careful eye on what we pull into our our project regardless of how it's licensed itself. Um when we formed Odenic Security, we formed it as a PBC. Um you might have seen from OpenAI that a public benefit corp can be whatever you like it to be. In case In our case, it means our charter, you know, in our company charter is maintaining open source for the benefit of our open source project for the benefit of the public. I've got a QR code to the full legal ease if you want to borrow that wholesale or parts of it. But essentially it says, you know, we

take a stance early on. We're standing our full company behind the fact that we're not going to start taking things out of open source and charging for it or putting arbitrary usage limits or user limits or things like that in place. And that we're going to as a company continue building and contributing to primarily the open source project. Um Again, from a company perspective, that's a little bit of a poison pill that we've, you know, taken away a lot of potential, you know, lucrative options of say a competitor comes in and decides to give you a big handful of money to shut down. That doesn't matter and they won't because Authentic is still open source

and it's still out there and we're we're bound to maintain that. But I think given the number of sort of open source rug pulls we've seen, we wanted to be as careful as possible from day one to be really clear about what we're supporting and how we are taking a stance to to continue to support the open source side of things. Now that's not from a company perspective just from the goodness of your heart. Open core is a really useful business model as well. So there are commercial benefits to supporting this open source. One of them is we get expert eyes every day on our code. Certainly from a security perspective, that helps a lot that everything's in

the open and you're getting constant community feedback on what you're doing right or wrong or could be doing better and sometimes even direct contributions to improve that. A lot of our commercial adoption is also long-time home lab users. And so they are already familiar with Authentik. They've run it at home, and it's a much easier conversation to have once they've joined a large company and are looking to scale that up from there. Um, so things that might not feel like they make business sense early on in terms of spending a lot of time helping the community, we think there's also value on the company side to to continuing to do that. Um, it's also very helpful

recruiting-wise. Uh, I I I know lots of folks who have spent years of their life working on really cool stuff that they can't even talk about what they did. Um, this is very much the flip side where uh everyone who contributes, and especially our own employees, for whatever journey they go on next, have a public record of here are my actual pull requests, here's what I've contributed. Um, so it's a really nice incentive uh all the way around to say uh here's here's what you have contributed to the project very publicly. Um, keeping the lights on, you know, we mentioned uh in our case we went down the the venture-funded side of a business, but you don't have to and you

don't have to right away. Uh we also give back to a number of open source projects that support us in really critical technical ways. Uh some of whom are individual solo founders who just have GitHub sponsorships set up. Uh so you can set up subscriptions like that, reach out to companies who might be using or interested in your project. There are other, you know, donations and grants and so forth opportunities there to kind of slowly scale things up uh without having to set up a corporation. Um, and I'd alluded a bit to this, but our sort of seven and a half lesson, um, choosing what to open source I think is is always going to be a an ongoing

challenge and conversation uh for any open core company. Um, in our case it's a little easier, not always perfectly black and white, but we think, you know, if this is something that's uh uh, a home lab user wants and needs or helps secure them, we should just give that to them. Uh, if this is auditing and compliance or certain integrations that probably apply a lot more to a big business, that sounds a little bit more on the the enterprise side. Um, and sometimes there updates there. So, this was a case where we had a a full set of features around remote access, but we had a lot of home lab users asking for that so that they could remotely access

their own infrastructure. Uh, so, you know, at the cost of maybe some short-term dollars, we had a lot of good uh, community goodwill by being able to say, "Yes, that is now part of the the open source as well." So, uh, basically this, uh, the lesson the lesson that we learned, uh, some of them like if you want to take a picture of that. I did. And to, uh, to wrap up as promised, I can't get this open. Uh, Marcel has been hard at work the past, uh, 2 minutes before this, uh, learning how to play his his uh, harmonica. I even forgot what it was called. Yeah. So, in conclusion, I get a Probably stand a little from the mic

though. Yeah. It started with a side project to build a better IDP. Our founder Yensen and then his friends were iterating constantly. A Reddit post had spread the word, we're picking up velocity. 10,000 stars, next thing you know, we're building a community. >> community to But wait, there's more. I'll let you go to lunch in just a minute. To keep the most permissive rights, we chose to license an MIT. To show commitment to our open source, we formed a VPC. Investment dollars helped us hire a team to work consistently. From day one, despite the fun, prioritize security. Like like publishing your pen test as a matter of transparency and setting up a clear and standard bug reporting policy

that documents the protocol for every vulnerability then handling when a horde of folks submit another CVE. So, choose your test tech stack carefully, communicate consistently, prioritize stability, be good to your community, and do it all sustainably. This is one way to build a brand on open source security. Thank you very much. Thank you. Uh this is a link to our community Discord. Uh feel free to email us or find us in person later on today. We'd be love to talk, but I think we have a few minutes for questions if anyone has uh thoughts they want to share or go deeper on. Yes, feel free to enter your questions in Slido or raise your hand if you like.

Either way we can take questions. We got a couple minutes.

Was that clear? Yeah.

Yes. Um there are a lot of specific cases there. Uh but yes, we do have that that conversation and that struggle and sort of trade-off there. Um one is just around support and being on a contract. So, for a lot of companies they they say, you know, we can keep using the open source project, but this is something so fundamental to our infrastructure or this is all our our employees are relying on this in a really critical way. We want someone to call um to, you know, be able to get answers and make sure that our feedback is heard timely and so forth. And we try to support that still on the open source side for anyone including a

company. Um but I think that is kind of a a default for any sufficiently large company to say, "Yes, we should probably be on a contract as well. Um you know, a lot of our enterprise roadmap also comes out of those conversations where if a company says, this is all great, we love this thing that, you know, doesn't quite fit into our current roadmap and I don't think home lab users would care too much, but we keep building out, you know, enterprise value on that side as well. Uh where even if that's something that might uh occur to them in the future of this would be nice to have. It might be a year or two before they

transition over and say, yes, we're ready for a a commercial relationship. Um but again, it's also kind of there for the long term as as a a partner and as a company as a project. So. Um sometimes no easy answers, but it's it's a little bit of all of those pieces.

Yeah. Um one actually other piece to the the previous question that I just thought of as well. Yeah, sometimes if it's not even a commercial relationship, there might be a case study or some PR to be had uh around, you know, we're not taking dollars from this company, but they're using our stuff and we can talk about it in really interesting ways that also gain visibility. So. There's also that possibility. Um I think there maybe a couple questions there of sort of like how to keep up with a very broad landscape and maybe a secondary question of like what sets us apart and I'm not here to pitch us as a vendor. Like if you want to individually

talk about why Authentic is much better than all the ones you named and more, I'm happy to do that afterward. Um I think it's a very broad landscape uh without getting too in the weeds of IDPs specifically, um you know, Jens started the project because he was was to use Keycloak and very frustrated and couldn't get done what he wanted to and so it's always been very mission-driven for us that we want it to be programmable, you know, automatable API for everything which again was a good reason for Django. It's just a Django API under every single action within Authentic. Um and you can embed expression policies, so a little bit of Python in there if

you need really complicated custom logic. Um so it's kind of a fundamentally different approach rather than like here's your plug-and-play UI wizard uh that maybe like a legacy approach might lend to. It's a little more developer forward and modern DevSecOps uh for for an IDP. Um but that's also really fun for us again on the the community side to be able to say it's much easier to build in integrations. So a lot of our community contributions are specifically, hey, I have Home Assistant or whatever happens to be and I've written up an integration guide of how to set up Authentic with this. And then that just becomes, you know, a massive catalog of here is what else you can do

and connect to and and use data from automatically. All right, thank you for your thoughtful questions and thank you too for our presenters for a It's a great musical experience. Um that wraps it up. We have lunch happening right now from 12:00 to 1:30 and we'll be back in here at 1:30 for You're going to be popular. Why they're getting a callback and you're not.