Lucas Gonze – Securing InnerSource #InnerSourceSummit2025  All right, we're going to talk about securing inner source. And the question we're going to ask is, is it too open to be secure or too closed, too proprietary, or just right? And how can you make it just right? And really, that question of how can you make it just right is the one we're going to be talking about. This is an active talk. It's about providing you with tools. So, my name is Lucas Gans. You can find me on GitHub. It's probably the best place to look me up. Um, I um have been an open source contributor since the beginning of my career, and that's how I make a living. Like, I've just been involved in so many projects, kind of seen everything. Uh, and I am a uh fractional uh open-source program office. I work for a variety of corporate clients um doing uh you know supply chain security compliance work, ESPO work um and uh community development and sometimes marketing for their open source projects. We're going to talk about threats. We're going to talk about tooling for open-source uh security. We're going to talk about the applicability of that tooling to inner source projects. We're going to talk about how to adapt things that are slightly maladapted to specifics about an inner source. And then we're going to do a Q&A. But the Q&A is going to be a little different because I'm going to ask you the questions. >> That's right. Um so first of all let's talk about threats because um when it comes to um security you want to avoid handwaving. You want to be as precise as you can be because there are a lot of vague threats that may be impossible. Um and and there may be threats that seem tiny that are very real. Um, so, uh, to give an example of a threat that is specific to o to to inner source security and actually I'm going to backtrack a little bit here. When I started working on this slide, I went out and I looked for prior art on inner source security threats and I hardly found anything. I mean, I found one thing and it was very, you know, loosey goosey. Um, and so I've been working on this list for about a month now and it's probably just the beginning. So here we go. First of all, there's no external community scrutiny of um inner source code and the inner source community is smaller than the open- source community, right? You think about something like heartbleleed like it took you vast numbers of people you tens hundreds of millions of people using that code to eventually get the eyeballs to identify the source of that code and in the in an inner source context that is not the case. Number two, in a in any enterprise context, in any business context, you assume that everybody else involved is being um they're vetted by the organization, right? If they do something that's that's kind of wrong, they're going to lose their job. Um but uh that leads to the presumption that upstream components things that um you're using that are coming from other parts of your organization are safe and that is not necessarily true. This is where we get back to that 8020 rule. There can be malicious insiders number one. Uh, and number two, there can be infected components inside your firewall um that are looking to ride on something they can get into to get into something downstream from there. Number three, um, write and commit access controls may be too broad. So you think about or even read access. Think about something like uh um Google's famous mono repo. Like the the scale of access there is really remarkable and in an open-source context uh uh um privileges are very fine grained. We're super aware of what anybody out there in the world can do to your repository and we're very precise about what we allow. That is often not the case inside the firewall. I don't want to encourage locking things down, although that's kind of what security people do a lot, but more I want you to think about the precise things that you do have to give away. There may be a way for somebody to leverage something you think should be open into the privilege to look at environment settings in your CI and then use those environment settings to you escalate into something like writing to your main AWS account, right? So little leaks can uh can cause can come much bear. Um there's the issue of security culture. Um cautiousness around security. Um is something that has to be absorbed organizationally. So the classic one is the CEO calls you up and says I want you to email me the SSH key. And it's really hard to say no to that. There's there's really no good answer to that. Um, and that's much harder inside uh an inner source project than it is in an open source project. Um, number six, this list goes on and on. I could stop at any time because you you know like this the list of possible threats is so long, but it is worth being as precise as possible. And that is the single biggest message I want you to take away. Be precise about uh threats to your inner source projects and exhaustive as much as you can. Um, next maintainers may have left the company in an open-source project. People stay on projects for years. Uh, they may stay on them their whole lives. There's a thing I built in 2020 that I still get emails about and I'll I'll just do it as long as I can. um and the expertise in a project that it takes to vet PRs that may potentially lead to um security problems uh can leave the company. So, watch out for projects that seem to have nobody with the expertise to vet PRs. Uh and the last one that I'm going to mention, but not the last one by any means, is a tooling gap. And that's what I'm going to focus on here because I don't have that much time and I want to get as deep as I can to to help you have the tools to use in the future. Okay, we're going to talk about some specific tools that are um oriented towards opensource security. One specific tool that's really critical is Salsa. SLSA, security levels. Somebody want to finish this for me? Okay. Salsa is used to um to to um secure the build and distribution process. For example, um you might um only accept libraries, binaries into your build that have been signed in a cryptographically secure way. And um that protects you from doing a build with an infected library. Um which is a great way to get an exploit into your into your application. Um Salsa is is a is a terrific tool that is very useful. There are things about it that are kind of p, you know, particular to open source, but it goes to the question of your build and distribution pipeline. Um, next, um, as an example, um, actually I'm going to jump through here because I think I talked for a little too long about the earlier things and I'm going to need more time, but I want to bring up openc.org, which is the master repository of uh, publicly reported vulnerabilities. And it's really important that that is wide open to the to the world and um and anybody can read it and check and check for themselves whether there is a vulnerability in something they're using. Um and it is essential but it's also not quite right in an inner source context because obviously your internal vulnerabilities can't be there. So it it does certain essential jobs and in an inner source context you have to find a way to stand in for it. Um open SSF is the main organization that um that hosts um tools for the health uh the security of the open source ecosystem as a whole. So if you think about a typical node.js JS project, you do a single uh npm ad that can lead to 50 or 500 uh dependencies getting pulled into your project. You can't possibly vet all of those. Open SSF exists to you know create a context where we can hope to have reasonable security across such an enormous web of dependencies. This is uh these are just a a few examples of the things there. Uh I'm not going to go too deep into this, but be aware that when you're looking for um tools that address the open-source side of your world, go here, study it, get to know the options. Um even if their project isn't fully mature, it's addressing an important problem that um you probably should have somebody on your team who is aware of. I'm going to talk about a particular project now. Um, and I'm choosing this one just because uh I want to go into detail, but be aware that the same issues will affect almost anything you use. Scorecard is a project I'm going to talk about. This is a open SSF project. It was originally called Scorecards. And what scorecard does is, well, let's take a look at the website. Um it is uh okay let's let's just look at this tagline quickly assess open-source projects for risky practices. Number one quickly the speed of assessment is part of its value. Number two assess these are metrics for security quality. I mean keep in mind they're quick metrics right and a real security audit takes real time. Um but quick metrics have their own value. Um and for risky practices, right? So with in a broad brush kind of way, we can identify risky practices. And the truth is broad brushes do actually matter. There are a lot of kind of you know e there's a lot of lowhanging uh fruit in this space. And notice uh in this list here the numbers that there's, you know, these are numbers zero out of 10, eight out of 10. Um and if you actually look in they're even finer grained. All right. Yeah. Yeah. Okay. Here we go. So, what does scorecard measure? Um, it has, um, you know, it checks whether you're using dependabot to look for known CVEes in any of your upstream dependencies. Here you are. you have 500 npm dependencies in your project from the one little thing that you pulled in deliberately and you need to keep track of every reported CVE and every available patch and then whether it's applicable to your software. So um there's a there's a lot of detail to track there. Um and dependabot does that well. The problem with dependabot it is for opensource software and and publicly reported cdees. So take this lesson away. You want to do something like that for your inner source software. You want to be checking for known vulnerabilities. And you know, with internal development, your apps team, they're going to have a list of these things they're going to know, but they can't shut down everything as soon as something is found. And making a fix can take a long time. It can be hard. You're going to have a count of open vulnerabilities, and you need to know what it is. So for each one of these there's a comparable kind of lesson to learn that um it's a thing that matters and it may be harder or easier in an inner source context. So I looked at each one of these and I asked um how well the uh open-source oriented version would be would adapt to an inner source context. What I found is there's one that you just want to drop. It doesn't make any difference. Um, and about half of them you can leave intact. So like this one, binary artifacts. Don't check binaries of libraries into your into your repo, right? Because that's where, you know, that's where the exploits live. It's a perfect place to poison your build. Um, and and no change like that. the open source, you know, logic is directly applicable, but some of these need uh uh cultural translation and I'm going to talk about that now for the ones that need cultural translation. What does that mean and how do you go about the process of doing it? Oops. Um so the one I'm going to talk about is the vulnerability count. Um, so and just as an example of one that has a really clear porting kind of process. Um, so the way that you get the vulnerability count in an open source project is you check for CVEEs in all your known upstream dependencies. Just it's a straight count from opencve.org. Um, and those aren't all known for a proprietary project. a lot of them are in your your corporate your enterprise level security infrastructure. Um so a cultural translation of this metric would have to include connecting to whatever enterprise level software you're using for tracking vulnerabilities. So be aware that the original thing is useful and there's very likely open source software on almost anything that anybody builds. Um but internally uh in an inner source context very importantly the more reuse you have the more impact a vulnerability has. Um so there is a downside to all this great superhealthy reuse which is greater impact of vulnerabilities in reused components. Um what does it mean to implement one of these projects? Um, first of all, um, think about your threats. Number two, um, like be precise with your threats. Um, be specific, avoid needless fear, but be concrete. Number two, look for tools that can address those. Number three, look for the gaps, the things that can happen in your context, in an inner source context that wouldn't happen in an open source context. And fortunately almost every tool for open source um security is open source and you can adapt it. Pretty much everything from open SSF is very clean and maintainable. I've touched those things. It's super easy. Um so the key thing for you to remember is um well okay so I'm going to talk about porting uh security scorecard itself right now. And here is my advice to you. Don't touch the code. Keep the algorithm. keep the concept um but do it this way. Um I have uh uh applied open source uh sorry security scorecard at a variety of clients probably five different clients um and I find it extremely useful. Um and what I use it for is I get a score a scorecard manually. I run it in the CLI. I make a list of the issues uh and then I get them into the road map and I walk them through the road map. And that's a process that doesn't require redoing once a day. I can do it manually. I can come in as an expert and spend a week figuring it out and then I do eventually get them all touched and you can do the same thing. So my recommendation to you for scorecard is be aware of the metrics and do it manually. Here's what that would look like. Uh I made up a scale that is amendable to doing it manually. Okay. Me and this needs fixing. Um and you know for you as an expert you especially for an engineering manager a senior manager a senior engineer client who would be here like you can make that sort of assessment pretty well. Um and then I extended the metrics that we saw before to cover the inner source uh issues the issues that are specific to inner source security. And you notice how flexible this framework is. It was really easy to do this. I took each of the tests we talked about, each of the threats we talked about, and I added a category for it, and I'm going to track it. I'm going to evaluate it and track it and get it fixed. So, it's a low tech way. Automation is great, but you know what? Getting it done is what matters, and it's not that hard to do it by hand here and there., Lucas Gonze – Securing InnerSource #InnerSourceSummit2025, YouTube, 01kchh0pqspaatxs2v4bdwae8a.