Cloud Native Computing Foundation Cloud Native DevX Day North America 2021, 30 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Building Secure Open Source Communities From the Ground Up- Kiran 'Rin' Oliver, Camunda

Description

Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Building Secure Open Source Communities From the Ground Up- Kiran 'Rin' Oliver, Camunda

When bringing together open source projects and contributions into a GitHub Organization or a collection of projects, it can be challenging to implement security best practices, outline how to best handle dependency management and vulnerability scanning, and how to balance the load of your Developer Experience team with the day-to-day work undertaken by open source maintainers to ensure their projects are secure. Building and implementing security policies for an open-source, community led project, or community GitHub Organization comes with a learning curve, but it’s not unachievable. In this presentation, attendees will learn how to evaluate and implement existing open source technologies such as Renovate, Trivy, JFrog X-Ray, CodeCov, and Dependabot to better empower and enable their open source project maintainers. This presentation will also explore how to write clear, scalable, and impactful policies and documentation that lays the foundational groundwork for a more secure and stable open source community.

A

Hi everyone I'm rin oliver and I use the heat pronouns, I'm a non-binary, multiple neurodivergent technical community builder at camunda. You can find me on twitter at karen underscore oliver on github slant. I'm here to talk to you today about building secure, open source communities from the ground up.

A

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 you're building are secure.

A

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.

A

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.

A

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 will, I promise they eventually will just wait.

A

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.

A

At kamunda in our community hub, which is a centralized location for all of our community extensions, we operate on the basis of least permissions necessary.

A

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.

A

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.

A

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 maintainer 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.

A

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.

A

There are a variety of container scanning tools available to you, such as aqua securities, trivi and jfrog maven, x-ray, trivia 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.

A

It's also suitable for continuous integration in devsecops works with github actions, gitlab ci, jenkins and so forth.

A

Jfrog move in x-ray offers impact analysis scans all layers of a maven package integrates with common ci cd pipelines and also does continuous analysis at comundo. We're making use of aqua securities trivi to great success in our community hub.

A

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 commenda we originally had hoped to use trivia 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.

A

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 pair programming across our departments, with myself on the developer, experience team and the infrastructure team to come up with a way to get trivi into our automated release action without using github actions.

A

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.

A

But if your extension returned a low or medium security vulnerability, you were able to continue forward with your release.

A

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.

A

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 move and release tool. It's really great and it was a collaboration between our developer experience, team and our infrastructure team.

A

It was a wonderful project and I'm super happy that we managed to get trivia working for our community members.

A

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 alert spam they can generate.

A

But that's okay, because that's telling you a lot of things that you'll need to know: there's code, cov, white source, renovate and dependabot, which is the one that everybody knows because it was recently made part of github itself so code cov is source code coverage for over 20 languages can't list them all, but codecov covers a lot and it's also cic diagnostic, so whatever cicd, tooling you're using code, cov probably works with it. It's also usable with multiple cloud platforms that works with azure works with gcp, etc.

A

It also reduces manual testing via automation. Codecov 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.

A

Renovate is really awesome in that it's an alternative to dependable and renovate. Depending on what you're doing can be better or worse for you than the pandabot 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.

A

I right now prefer renovate, but that's just because of the amount of projects and the type of projects I'm working with renovate detects dependencies number projects in a repository and checks that newer versions are available. It also creates commits and 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.

A

Notes, dependable also creates pull 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 advisors 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.

A

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're doing in your actual organization.

A

Dependable 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 dependable? 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 dependable to reduce the number of those notifications and filter those out to make sure that people aren't getting notifications every time.

A

Something changes because nobody likes that so go into your settings, adjust them and make sure that dependable isn't sending needless messages. That don't necessarily need to be checked on at that exact moment.

A

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 kamunda, the community hub didn't even exist.

A

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 its 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 taken it took six months to get that second wave of project successfully migrated and that's a pretty long time.

A

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.

A

I don't want to do this anymore, and so we had to figure out a life cycle for these extensions to say this is deprecated people shouldn't use it introduce shields dot, io 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.

A

We were able to give people a quick visual into where those were in their life cycle so that they could make a decision as to if they wanted to use that tooling or not.

A

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?

A

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.

A

So this was um 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.

A

uh But the long story short is that keeping things realistic is key, because if you think it's going to take whatever time, you think it's going to take, probably double it.

A

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.

A

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 our.

A

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.

A

If you're, if it seems impossible, don't worry, just break it down compartmentalize 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.

A

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?

A

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.

A

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.

A

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 grow security, expertise in all business functions and alyssa is wonderful and is at global ratings and is a biso at s p in 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!

A

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.

A

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.

A

Thank you. So much I'm going to 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.