 Hi everyone, I'm Rin Oliver and I use the he pronouns. I'm a non-binary multiply neurodivergent technical community builder at commando You can find me on Twitter at Karen underscore Oliver on github at Salant I'm here to talk to you today about building secure open-source communities from the ground up So let's get started Security best practices in open-source software mean different things to different people So let's figure out some tips and tricks that you can keep in mind to make sure that the open-source communities Your building are secure First things first is that security looks different to everyone when you say security depending on who you're talking to you'll get 20 different answers So what you need to do is define a baseline of what security means to your project or your organization and Improve it alongside your community Whatever security looks like that's unique to your community itself doesn't have to be the same as Everyone that's in your ecosystem. It's going to be unique and it has to be yours security can be Influenced by your peers But in the end it has to be tailored to you and your developer community itself Another thing to keep in mind is to ask how you'll handle when things go wrong Because they're going to if you don't think they well, I promise they eventually will just wait You should have strategies in place that will detail when and how community members should report vulnerabilities what constitutes what a vulnerability is and Evaluate dependency management for your community maintained extensions or public forks or whatever community contributions Those are are you going to require people to keep their dependencies up to date? Are you going to have a policy that says if something isn't updated within 30 60 90 days? You will face some sort of action Etc having those things defined beforehand helps make your security Policies and governance easier especially when your community is scaling at Kamunga in our community hub, which is a centralized location for all of our community extensions We operate on the basis of least permissions necessary Our community members are granted the lowest level of permissions needed to obtain the desired outcome Whatever that may be we're going to give them the least permissions possible So that they can still do what they need to do without impacting the security of the organization as a whole Having a very clear contributor guide with member roles Repository access levels and responsibilities outlined is key to making this successful That way people know if they are a maintainer on a repository. They will get the following Permissions and if they are a contributor they have the following permissions But they might not be able to do everything they typically would do if they're a retainer and if they're an admin They can do just about anything However, be sure that if you are granting admin permissions you understand very clearly what that actually means Read those permission levels and make sure that you're not granting permissions to people that don't necessarily need them So back to that dependency management and vulnerability scanning Here's some tools that you can introduce into your organization that can help make your lives easier Especially for maintainers of open source projects There are a variety of container scanning tools available to you Such as Aqua securities trivy and JFrog and even x-ray Trivy scans Docker files and it works with Kubernetes terraform a variety of operating system configurations and much more and looking for vulnerabilities It also scans for common configuration issues and will alert you if something is configured incorrectly It's also suitable for continuous integration in DevSecOps works with github actions, GitLab CI, Jenkins and so forth JFrog move and x-ray offers impact analysis scans all layers of a move and package Integrates with common CI CD pipelines and also does continuous analysis at Komunda. We're making use of Aqua securities trivy to great success in our community hub and To that extent When all else fails use bash Why because sometimes the solution you want to use might not be the one you actually can use in reality at Komunda we originally had hoped to use Trivy with github actions, but the way our action was written up until recently github actions Did not have the ability to write concurrent actions in that you could not use the uses and with keywords in the same GitHub action now you can do that as of August 25th or so they actually put patch that in but it's still in the works So we had to end up a pair programming across our departments with myself on the developer experience team and Infrastructure team to come up with a way to get trivy into our automated release action without using github actions So we wrote a one-liner bash script that did that and we ended up where the bash script said that if your extension had a vulnerability that was critical it would Return an error code and you would not be able to push your automated release, but if your Extension returned a low or medium security Vulnerability you were able to continue forward with your release if you have a critical release We also coded the fact that it would now update to the github security Advisories tab so that people could see that that vulnerability was there and make an educated decision as to whether or not they wanted to use that extension so Although we couldn't use github actions entirely with trivia at the time Bashed into the rescue and in the end we had to be flexible and we had to cooperate Across teams to get that done and it's working out really well You can take a look at it in the community community hub and check out how we did it and the community action may have a release tool It's really great And it was a collaboration between our developer experience team and our infrastructure team It was a wonderful project and I'm super happy that we managed to get trivia working for our community members There's also a lot of opportunities for dependency management and code quality tooling out there And you've seen these everyone's seen these and I'm pretty sure that everyone's marginally annoyed at some of them because of the amount of alerts ban they can generate But that's okay because that's telling you a lot of things that you'll need to know There's codecub white source renovate and dependabot which is the one that everybody knows because it was recently made part of github itself so codecub is Source code coverage for over 20 languages can't list them all but codecub covers a lot and It's also CICD agnostic. So Whatever CICD tooling you're using codecub probably works with it It's also usable with multiple cloud platforms that works with Azure. It works with GCP, etc It also reduces manual testing via automation codecub will show the amount of coverage test coverage for your code and it automates whenever you push a new release it will Throw out your coverage and shows people about the amount of your code that is covered by testing Renovate is really awesome in that it's an alternative to dependabot and Renovate depending on what you're doing can be better or worse for you than dependabot I'd highly recommend comparing and contrasting the two not necessarily apples to oranges more like apples to a different kind of apples Which is fine But in the end it really depends on what your use case and your scenario is I like both of these things because they do slightly different things and slightly are slightly better depending on the particular use case You're using I right now prefer renovate But that's just because of the amount of projects on the type of projects. I'm working with renovate detects dependencies in a repository and checks if newer versions are available It also creates commits and merge merges pull requests to apply those changes and it also includes release notes Which is really awesome. Love that because nobody likes to write release notes and Renovate will do it for you to an extent. It will at least give you the building blocks to write better release notes Dependable also creates poor requests to keep dependencies up to date And it will slowly open PRs over time unlike renovate which can open about 12 at a time and In contrast to renovate dependabot will tell you Release notes as well and it will also monitor security advisers for eight common languages. So as I said Apples to different kinds of apples renovate will also tell you the amount of Individuals that have actually installed that fix and whether or not they believe it is trustworthy to install it So that gives you an opportunity to say do I really want to apply this right now? And the answer could be yes or no depending on what you are doing in your actual organization Dependabot is great in that it's already integrated with github So that does that means that you don't have to necessarily bring on anything new You don't have to scratch your head and go what should we do? Dependabot is there in github waiting for you to use it and make use of it And if you are part of the alert fatigue You can actually customize renovate and dependabot to reduce the number of those notifications and filter those out to make sure that People aren't getting notifications every time something changes because nobody likes that So go into your settings adjust them and make sure that dependabot isn't sending needless messages that don't necessarily Need to be checked on at that exact moment Another important thing to keep in mind is that this needs to be realistic while you think it might take a week Chances are it's not going to when I first started at Komunda the community hub didn't even exist This was in January of 2021. And so I had to build it from scratch and In February we had started contacting the initial first wave of maintainers and it wasn't until March That projects began transferring into that organization itself. So that in itself of itself took two months in April the first wave of projects had successfully been migrated over and that was great But now it's time to begin the second wave of project transfer, which was May So it didn't take in it took six months to get that second wave of project successfully migrated And that's a pretty long time you think oh transferring things into a different repository. That'll be really quick It was not quick. There were I want to say about 75 80 repos to transfer 80 maintainers to contact that's a lot of people and some of them were no longer maintaining some of them said I don't want to do this anymore and so we had to figure out a Lifecycle for these extensions to say this is deprecated people shouldn't use it Introduced shields I owe badges that gave people a way to navigate directly to that repo and said okay This is deprecated. I should probably shouldn't put this into production probably shouldn't use it in my product And so by introducing those life cycle badges and that life cycle pathway We were able to give people a quick visual into where those were in their life cycles So that they can make a decision as to if they wanted to use that tooling or not So in July we actually started scoping our security management policy and vulnerability scanning tooling seeing what was out there What was available to us? What options did we have and? Security as we all know is not quick or at least it probably shouldn't be So we researched and pair programmed that vulnerability scanning solution that I just told you about into the community community hub back in August So that took a month to do a pair programming and it took two months after that to publish a full security and dependency management policy and that's as of September that was published so this was Nine months to get this from start to finish and it's still not done yet and In the future. It's got a long way to go, but for now it's been kicked off and it's successful But the long story short is that keeping things realistic is key because if you think it's gonna take Whatever time you think it's going to take probably double it. I would say at least double it because doing research and Making sure that you get in touch with all of your community maintainers is key because you've got to also understand that some people May have built something five years ago and they're not into it anymore But you still have to get make sure that people know that that's no longer Properly maintained so or if it's new you need to make sure that new contributors know where to put it Say hey, we have a community hub bring your extensions bring your contributions We'd love to have them this is art This is their home and making that home for those extensions and those community contributions is key because it lets people feel like They're a part of that community in a broader way. So giving them that centralized hub is Really important because it allows people a way to discover everything that your community is doing in that central location So they're not having to navigate through the woods of GitHub If you're if it seems impossible, don't worry. Just break it down Comfermentalize it's going to be okay If by breaking down a task you can make it seem a lot more manageable First things first is to evaluate that task is now the right time. Do we need to do this at this very moment? What will happen if we don't what happens then? So evaluating that task is critical So ask yourself is now the right time and next you should probably do some research Confirm that hypothesis is what I think actually correct or am I going to end up? Sitting there saying this actually wasn't correct and having to go back to step one So by doing research and making sure you have all of your proverbial ducks in a row you'll make sure that you're not going to sit there and go in circles and Once you've done your research and that hypothesis is confirmed you get to implement it do the thing you did it congratulations So by breaking things down you can actually make sure that you're not overwhelming yourself It doesn't all have to be done at once Taking it step by step means that it's going to be realistic and achievable for everyone on your team And it means that you're reducing burnout and that you're not driving people To a place where they can't meet their deadlines and they can't meet their obligations It's very important, especially in these times that we make sure that we're being realistic with our deadlines Flexible and supportive to our team members and that we're also supporting the people that we work with I've got a quote here by one of my friends Alyssa Miller and Alyssa has said As digital transformation trends continue security has to be a part of every phase of our business So why then don't leaders look to grim security expertise in all business functions and Alyssa is wonderful and is that global ratings and is a BISO S&P global ratings and That's a pretty accurate quote If we're not grooming security expertise across the business It can't just be the security team. It's everyone. It's developer relations. It's developer advocacy. It's developer experience It's infrastructure. It's even marketing security is for everyone It's not just for the security people. It has to be across the company and embraced at a fundamentally intrinsic level and Stronger security starts with improving the developer experience So that's super important and each of us here today as developer experience professionals Can bring that security to life and can make sure that we are bringing security to our communities as a whole Thank you so much. I'm gonna take some time for some questions here from the audience if there are any But if there aren't you can find me on Twitter or on GitHub. Thank you so much