 Hi everyone. I'm Cara. This is Pedro. We're both members of the Google open source security team so I'm a software engineer with the open source security upstream team, which is a sub team and So we actually spend 100% of our time contributing to critical open source projects and Offering help making security improvements via issues PRs, etc. And I work on documentation. I Write documentation for open source security tooling and I explain security concepts in blog posts so today we've joined forces to talk about open source projects and supply chain security and Some thanks first this talk has grown out of many people's efforts all of ghost our team has contributed to the tooling We're talking about today And those tools are supported by the open source security foundation, which is a cross industry collaboration We also want to call out especially our teammate Geoga Santana who contributed to crafting the story. We're talking about today So what is that story? We'll start with an explanation of what we mean by supply chain security just to get everyone on the same page We'll talk about a tool called scorecard. I think it's been mentioned a lot already at this conference, which is great It helps you improve your project security And we'll talk about how we used it first to purposefully make a project as insecure as possible so that then we could use it properly and Improve that project and we'll share a couple lessons from that experience and leave time for questions So first what is supply chain security? What are supply chain attacks? We're really hoping that some of you or maybe even all of you in this audience are new to the topic So there's an official definition of the top but for today's purpose for maintainers We can say that a supply chain attack involves injecting code into your project to harm those who depend on you And while this definition is about attacks not everything we'll talk about today starts from a malicious mindset Some things just start as innocent bugs that nobody noticed For example, one of the big name supply chain emergencies in recent years started as an innocent bug that had been overlooked But when it was discovered it set the internet on fire That was a headline everywhere It was a vulnerability and log 4j an open-source project relied upon by a huge portion of the Java ecosystem And it sent developers around the world scrambling to patch this accidental bug that opened a major security risk across the ecosystem Where there was left pad which wasn't an attack per se But just a few lines of code that when they disappeared they broke the internet and that was also the real headline Where any of these other headlines from banking? To business it seems like most hacks we hear about these days are related to supply chains An open source is a major target. There's been an enormous increase in attacks on open-source projects This headline is actually old. It's now 742 percent And there's a reason for this You may have seen this before If not, this is the classic xkcd comic for this topic Anytime people talk about supply chain security. They show this comic They usually show it to emphasize the point that open-source projects are foundational to the software world and they absolutely are That's what's made them a target But I think from the point of view of the maintainer that that little block that's holding everything up I think this comic also illustrates how software comes in all shapes and sizes with different resources and different needs The security solutions that work for those those big giant blocks the big companies Those might not work for Nebraska dev here Who's a solo maintainer likely working on the project to do the evenings and weekends as a volunteer? outside of their paying job and Their family and their life responsibilities So though this comic shows all of modern digital infrastructure today We're going to focus on the most important piece, which is your open-source project and how to protect it So to get us started here's a fictional this is fake example of what one of these supply train threats might look like What if you saw a commit like this in a project? What's wrong with this commit? Yeah, we're laughing There's obviously the funny business with install crypto miner and steal crypto wallet. That's not not great But arguably that's not the main problem with this commit That part's sort of working as intended since the intention was obviously malicious We'd argue that the main problem is that this commit actually entered the code base and it went directly to the main branch of the repository Meaning it's basically okay for the next release and it came from the maintainer That little block or did it These slides were fake. This next slide is real So this is from a real discussion in the immediate aftermath of a supply chain attack that was based on the exact same idea as the previous slide A malicious actor asked just asked for ownership of the project and the original maintainer gave it to him for the reasons explained here And why ask for ownership? The project was used by a crypto wallet. So the new maintainer after being given the project added some code Added some code that would steal bitcoin from the crypto app And one thing that I find really striking about this example is the simplicity of this compromise So we hear about well-known supply chain attacks big names like Codecov and solar winds that are super complex and have nation-state level of backing But others are really simple just social engineering to get access to a project So your project might not be directly involved with anything Sensitive or critical or so you think but it could still be at risk based on what is connected to I'm going to hand this over to Pedro now to talk about some of these risks So the question now basically becomes like how can your project be affected by such attacks? And the answer honestly is that it depends on let's call it your project's maturity So let's actually walk through like a project's lifecycle to see how these risks start to come up Every project starts with an idea right you think i'm going to create this new tool. It's going to do xyz. It's going to be awesome So you spin up a repository you push it onto Your hosting platform of choice to get hub get lab whatever and you start hacking Honestly at this point in time the greatest risk to your project is You right you're writing code which means you're writing buggy code because that's what everyone does But this is especially true if in your excitement you just focus on like the actual code That's going to go into production and it's going to be really cool without investing some time on things that can At least reduce the number of bugs in your code things such as automated unit tests or static analysis tests And also over time as your project starts becoming more popular or starts being used by other popular projects Another risk is that your code might Not actually be yours A hacker might determine that the easiest way to attack your project is to simply take over your account So it's really important that you think about taking steps to make sure that your account remains your own That being said one of the first things I do when creating a new project is that I actually add a dependency to another package And let's be honest. I don't add one dependency. I don't add two dependencies I add a whole bunch of dependencies and the reason is simple Dependencies are awesome They save you time and with just like one or two lines of code you gain access to like awesome features without having to code Them up yourself It's honestly it's like having some of the world's greatest developers on your team instantaneously and for free usually But dependencies obviously also have their downsides And that's because those world's greatest developers. They're human too. They probably write just as much buggy code as you do, man And this problem is aggravated by the fact that your dependencies often have their dependencies and they have their dependencies It goes like turtles all the way down Therefore the risk that your project will eventually become harmed by a dependency having a bug Kind of increases exponentially the more dependencies you have And also the more dependencies you have The more version updates with security patches you need to keep in mind and you need to keep track of But you're a busy person. We all are So it's really easy, especially if you have many dependencies. You just kind of like forget to update one at some point But also dependencies aren't the only type of what we're calling here other code in your project Because after all like people will eventually discover your project They'll use it and it's awesome, right? So they'll love it But eventually, you know, they'll notice there's a feature they want or a bug that needs fixing So they might send your they might send a prs implementing those changes And receiving prs can be like a massive scaling up factor for a project Right, it means that you no longer have to like implement everything yourself, right? External contributors can just come and implement those features and those bug fixes that you didn't have time or honestly patience to implement yourself And how they might even come up with some really cool ideas that you hadn't even considered But obviously accepting prs also has its downsides, right? You know your code base inside and out and you still write buggy code every single day. We all do And imagine how much harder it is for external contributors who don't have all of that context by nature So prs are just much more likely to have bugs accidental bugs well-intentioned accidental bugs So this means that as a maintainer you may have to spend a lot of time reviewing prs Making sure there aren't any bugs or any nuances that the contributors weren't aware of And this can like honestly stress out and in some cases even like burnout maintainers If they don't come up with like systems that can at least help them triage all of these contributions But you know, let's say that you've gone through all this and with your code and with the help of your the world's greatest dependencies and Your external contributors everything is everything is running smoothly And you realize that your project has reached a level of maturity that you are happy and satisfied to release it into the wild So at this point you package it all up and you release it to the world This is a huge milestone for any project up until now anyone who wanted to use your package had to Go to your repository clone. It's install locally. It's a pain to install. It's a pain to maintain. It's not really fun But once you actually release your package Users can now use it Just as easily as you've been using your own dependencies. It's really really powerful stuff But it does raise a new concern Right the code for your package is in your repository But for most languages Users are actually installing the artifact from an index How can users really know that the package in the index really corresponds with the code in the repository? After all like what if someone stole your credentials and published a malicious version? It therefore be a really good idea to come up with some way to closely tie the package to the repository So here i've just described a whole bunch of things we need to keep in mind while developing and honestly There's a whole bunch of other stuff. I haven't even mentioned Uh, so now i'll actually pass to the word back to cara. We'll actually talk about a tool that'll help you keep all of this in check Yeah, so pedra touched on some of these aspects, uh, but the overall risks to your project There's just a lot of them and they can depend on a lot of different actions that you take and that the people behind the projects You depend on take It's pretty much impossible to keep track of all of it manually So the open ssf the open source security foundation developed a tool to help you measure these risks scorecard So these are some sample scorecards. That's three different projects not three for the same project Um, scorecard is an automated tool that runs a little under 20 checks on open source projects So a check evaluates an aspect known to correlate with risk So for example, one of the biggest risk signals is whether a project is maintained If it's not maintained is no longer getting bug fixes. It's not getting security updates. You'd want to know that Another check is vulnerabilities. It looks at whether there's known unfixed vulnerabilities in your code in your dependencies and in some languages in your dependencies dependencies those indirector frames that are dependencies A question we get sometimes is why would I need scorecard? I'm already using security tooling for example sastre tooling If sastre is like the guard in front of the bank Then scorecard is like the security consultant who comes in and tells you hey you need a guard in front of your bank and Also points out a whole bunch of other risk factors and solutions that you hadn't even thought of And despite the name I swear despite the name scorecard isn't just scoring you It really is meant to help maintainers It also gives you advice on how to raise any scores that indicate areas for improvement So that makes scorecard super useful not just for evaluating a project To understand the potential risks of adding it say as a dependency But also as a checklist of things to do to improve your own project security So this slide is one of those pieces of remediation advice It explains how a secure security policy can help people safely report vulnerabilities in your project It suggests where you should place the file or it tells you what you might say in that file You can click through and find even more guidance And scorecard gives a lot of info and the info is available in lots of ways There's three main ways that I think are useful for maintainers as opposed to say big query data for researchers There is the web viewer. You can just find that link on the front of the repository Towards the start of the read me. So there's a web viewer where you can look up I think it indexes about one million projects Each week it runs a scan There's a cli tool for any projects that aren't in that one million projects on the web viewer And there's a github action which you can add to your github project And it'll run on every change to your repository and you'll find out immediately if anything you do causes a security regression And then at the macro level scorecard gives us a snapshot of an ecosystem security health So this slide shows scores for 10 000 critical projects on github And that's critical based on how essential they are for digital infrastructure So that's calculated with another open ssf project the criticality score project And there's there's quite the spread here There are some projects that are up there in the nines, which is amazing I think honestly anything above like a six into the sevens is really really impressive But there are also some projects down there in the ones Which made us a little concerned and also made us wonder What would it take to get a project all the way to the left? And then what would it take to get it all the way back to the right? So We did that We mentioned that you can use scorecard as a checklist of things to do to improve your project's security So we did the opposite Pedro created a project cronk. I might say we in this section, but really Pedro did all the coding work in this area And cronk cronk is a real project developed by Pedro, but it's actually Nebraska dev up here And what it does is an important It's written in python, but it's meant to be a stand-in for any project Almost anything we're going to talk about today is agnostic of code or language or purpose So when cronk started out Just setting up the project using github defaults gave it around a four out of 10 score So that was right around that big peak on that chart a couple slides ago pretty normal score But by using scorecards checklist as a reverse list of what not to do We were able to lower cronk score pretty far Down to a 1.9 out of 10 So for reference out of the roughly million projects monitored regularly by scorecard only 0.7 are in that range And of the 10,000 most critical projects, there's only 22 that have a score in that range So you can see all those red zeros as scorecard just freaks out Much of this low score came from an absence of proactive action didn't actually have to do anything So not setting up automated tests like Pedro mentioned not setting up branch protection But getting the project to rock bottom required some intentional sabotage Intentionally looking for dependencies that had vulnerabilities that we could add Creating an automated workflow that intentionally could be easily exploited to inject code into the repository Overall fun exercise of doing everything you normally try not to do So now that we've got cronk score down to like rock bottom It's time to start climbing backup And the good news is that we realize that you can do just a few small things And increase the security of your project by quite a bit Naturally everything we're going to talk about from here on out Hinges on you being the person in control of your project Like if someone else takes gains control all bets are off game over So, you know, here's the same advice you've probably heard a thousand times before Please have a good password and set up two factor authentication This is so important actually that github is starting to require 2fa for all maintainers And so will pi pi by the end of 2023 Most other platforms don't yet require it But do it anyway. It's really important And that's because maintainer accounts do get hacked and this will help keep you in the driver's seat For example the solar winds attack from a couple of years ago that affected multiple united states government institutions And cost tens of millions of dollars of financial damage Likely began due to a leaked password, which was solar winds 123 We also recommend that you cryptographically sign your commits This adds a comforting little green badge next to all of your signed commits and a spooky orange badge next to all of your unsigned ones And this is something that would have been really useful in that very first example commit that kara showed In that it would have given users at least a hint As to whether that commit came from the maintainer or just someone who'd stolen their credentials So Now that nebraska dev has protected her account and started signing all of her commits Cronk's users can be confident that whatever code she submits to the repository actually came from her Now she just needs to make sure her code is actually any good And it's already very common practice to work on a feature branch or a bug fix branch And then when you're done you merge that work back into your main branch Our suggestion here simply takes that one step further And that is that we suggest that you configure branch protection rules for your repository So that everyone yourself included as the maintainer must contribute code via prs And that's because contributing via prs has huge advantages Most importantly it makes sure you don't forget to run tests on your code My personal experience is amazing every single time I forget to run tests before I push something There's an obvious glaring bug that I it's impossible. How did I not see it before? And also it just gives other people an opportunity to take a look at your code, right? Humans may write buggy code, but they're also very good at finding bugs in other people's code And and therefore it kind of also just lets you explain your idea more clearly Since you can use the pull request description you can link to issues all that stuff It lets you have a conversation with other contributors But yeah, let's be real like this request can be kind of annoying for the maintainer like honestly It can really can be Because this suggestion is actually the only one that we have that actually requires you to change how you work How you change how you change your workflow? But the advantage you get from it can be so important. We still made it one of the primary things we suggest you do So once nebraska dev set up branch protection and configured some automated testing workflows Cronk's score rose significantly to a 3.3 And honestly it could have gone further like nebraska dev is Cronk's only maintainer If the project had another maintainer they could review each other's code And that added code review alone would increase the project score by almost an entire point to a 4.1 So now that nebraska dev is a bit more confident that her own code is bug-free or less buggy at least It's time to put to ensure that the project is also safe from other people's code And part of that is to ensure that pull requests from external contributors are also bug-free ish And here is where those automated tests that help you avoid bugs in your code become especially important, right? Because this not only speeds up how quickly a pr can be approved Since the author can submit the pr notice its failing tests and fix the bug before you as the maintainer even see it And therefore it increases the health of your code base But and you could even say this is actually more important It can even help with your own mental health as the maintainer since you don't need to spend as much time and energy And honestly like stress on every single pr making sure they don't have any bugs. Oops. Sorry. They don't have any bugs or like any other problems Because you have those automated tests as backup giving you some confidence in the quality of the pr And then there's your dependencies And here the first question really is how well do you know your dependencies? Like are you sure you actually want to rely on these packages? But really that just leads to another question, right? Which is like what do you need to know Before you can even make an educated decision on this So here's an idea First, you know check a dependency scorecard score You have an idea of the project security posture See if it's something you're comfortable with Or there's also depths dev which is a website that will have more information about your dependencies than you'll even know what to do with Finally and honestly just as importantly Take a look at the packages at the packages repository yourself Like is the project active our maintainers interacting with issues and prs and like how many stars does the project have? like basically You want to make sure that you're looking at node j s with a hundred thousand stars and not accidentally looking at node gs Once you're sure you're comfortable with your dependencies You still need to like remember to have their latest security patches. So it's really important like remember keep your dependencies updated or Follow our suggestion and don't remember Instead we suggest that you embrace the robot overlords and use a dependency management bot Just as you'll receive a notification on your phone or laptop letting you know about the new version of the operating system With all the security patches and new features These automated tools will send you prs updating your dependencies as soon as new versions come out And if you have automated unit tests set up, you'll even know whether there were any breaking changes in the new version So just for the record, uh on github, there's dependent bot There's also renovate bot that's available on basically all platforms including github And many languages actually have their own dedicated tools So after nebraska dev set up dependent bot on krunk And actually fixed its uh vulnerable dependencies with dependent bot prs The project score went up to a 4.3 So now that nebraska dev is confident that all the code affecting krunk is reasonably bug free and up to date She's ready to release it to the world But how can this be done safely? The common method here is the most common method is just doing it on your laptop, right? The code is already there all you need to do is just run a few commands to build the package and then release it And this works just works But it's opaque Your users can't really know what's going on during this process And there's no way to be sure whether the package that ends up in the index is exactly the same as the code in the repository Also, it's just annoying for the maintainer for the vast majority of projects creating a new release isn't like an artisanal process It's mechanical. You're running the same commands every single time And each of them usually takes a while especially for larger projects And you need to just sit there and wait for them to finish We therefore suggest that you instead adopt an automated release This is an automated workflow that follows your instructions step by step to build and release your package And automated releases fix most of the issues we just described The workflow is in the repository so users can know exactly how releases are being made And they might even have ideas for improvements or use that information to build locally And the process also just gets easier for the maintainer, right those commands as I said they take a while But once it's automated, you just trigger the release and take a nap So once Nebraska dev set up Cronk's automated release workflow the score went up to 4.6 That's nice, but not a huge increase compared to the 4.3. We had before But it is important to remember here that this is Cronk we're talking about The project still has that ridiculously dangerous workflow. We mentioned and it doesn't even have basic things like a license that we haven't touched If we were talking about shall we say an ordinary project with a single maintainer that hadn't been sabotaged as thoroughly as Cronk was The improvements we just talked about would get the score to somewhere around a six And notice that this would already make your project better than the half that most of the 10,000 critical projects we talked about before And if it's a project with multiple maintainers that can review each other's prs the score actually goes up to 6.8 So from now on to more closely track the average project I actually removed the awful workflow. I added a license I miraculously solved the great problem of open source development, which is finding additional maintainers and found a friend for Nebraska dev And so that got Cronk up to the 6.8 like an average project would have by now and Yeah, 6.8 is really really good. I think sometimes people think it's about 60 seconds. We've got about five minutes left Projects on your bell shaped curve What source did you use to generate that list? The list of projects or the list of scores? It's the open ssf criticality score. It's a another project that uses a bunch of heuristics to determine things Okay, so we left off at a 6.8, which I want to emphasize is like really really really good But what if you wanted to go higher and enter that truly verified security space? Everything up to this point were the main tips the main takeaway For this talk if you did only that much your project will be in good shape But if you want some bonus tips, here's how you can go further The easiest way to know where to go next Just run a scorecard on your project Whether you use the cli tool or the github based action You'll get scores for each individual check and then remediation tips for any of the weaker areas But there's a lot of checks. So how do you prioritize? We suggest focusing on these three for the next steps Number one is token permissions. That's workflow permissions because it's incredibly easy For about 90 of projects just changing the right permission to say read only Is going to stop compromised workflows from being used against you The vulnerabilities check is just super useful It'll immediately notify you of any known vulnerabilities that enter your dependencies And signed releases it takes a little bit more effort, but it's super powerful Since it will help you create a process that helps users verify that your releases actually came from you So cronk is getting up there these three additional bonus changes Token permissions volums and signed releases push cronk to a 7.9, which is really the upper echelons of scores Getting through the final checks Cronk cronk all the way to the right basically off the chart to a 9.6 This last stretch was harder. We are not going to lie about that Pedro put more effort into this final point in half than all the other All the others combined, right? Yeah The addition of fuzzing was the most labor intensive part because fuzzing was actually the only part of this process That required actual project specific code to be written Everything else was changing settings or just adding some simple boilerplate code And that's it that's as far as cronk can go Getting it to a 10 out of 10 would mean having enough maintainers to require multiple approvers for each pr Which we didn't think was representative of what's realistic of a project of this size And that's okay. This is amazing. No project out there has a 10 out of 10 Yet, so I'm hoping one of you will first get that 10 Okay, coming into the end just to summarize If you improve these three areas of your project security just as a start You're going to be far above average in terms of reducing risk And I kept bugging Pedro. I kept telling him we need to say something about timing. How long did this take you? I wanted to emphasize just how quick most of these recommendations are But he rightly pointed out it's not so simple Even though branch protection will take literally minutes to add Regardless of the size of your project and adding a dependency management tool is less than probably 10 minutes It's thinking about making the change. That's the real time commitment You need to think about and decide whether these changes are right for your project So that's our closing thought we hope our suggestions were useful for you But we want to emphasize at the end of the day, you know your project best You know what will and won't work for your work file for your contributors for yourself Not everything that scored card suggests will work for you And that's okay every little bit of improvement you can make will help So if you are a maintainer of an open source project Thank you, especially if you are a solo maintainer And if you aren't a maintainer go find a solo maintainer. They're everywhere Um help them out with some code review. All right. Thank you everyone. We have time for questions Um GitHub has actually worked a bit on this already. So uh one of the Try to say previously most quote-unquote problematic default that it has what that was that Workflow permissions were uh default write all But since I believe it's February of 2023 They've changed that so any repository created since then starts with Read-only tokens however projects created before February 2023 have been grandfathered in with uh write all permissions So if you have any projects, please go to your settings and change that That that setting it's literally takes like seconds to fix uh, yes a write all token uh on a A write all token Could be used to modify the contents including like the actual code base of the repository You can have like branch protection rules that require a pr And then it becomes much more challenging to make that exploit But if you have no branch protection rules and you have write write all tokens a The workflow could potentially be exploited to literally change the code in your code base That was the only critical. There's there's one critical check The checks used to be low Mile medium high. I forget moderates high. Um, and then when the dangerous workflow check came out created a new category critical Yeah, and uh, so yeah, I mean like that's like Because like dangerous workflow is basically when your workflow is structured in a way that you can actually have code injection in the workflow To then be used to maybe modify the contents of your repository But also it could also be of uh malicious dependency. Maybe you use I don't know a github action that's been exploited or just uh Build time or test time dependency that maybe was exploited and could be then be used to modify the contents of your repository Not that i'm aware of not going to say no, but not that i'm aware of either. Um, I mean like most uh containers like in in broad use are usually Are usually like Maintained shall we say in the repository so you can at least like ensure that the development of the maintainer is secure But those things really to like guarantee other than maybe signing the having like a signature for the container image Um, that's like the best that I can think of but i'm not going to say no. I don't know everything um, so I mean like all sorts of dependencies are problems at different stages Right, so runtime dependencies. It's kind of important to keep those like just naturally updated Um, because especially if you have like you have a especially if you have an application Because right log for j is a runtime dependency that burnt down the internet But then there's also like build time and release time dependencies could also be used to Actually modify the very artifact that's released So your code base looks 100 clean But your dependency could be used to modify the artifact and actually send a poisoned release even though your code base is perfectly fine So he's asking our build time dependencies included. Uh, yes, they are the Like I mean like the the our point is about like keeping your dependencies updated and then dependent bot renovate bot Those kind of things can be set up to make sure that all of your dependencies No matter if they're in the package json or requirements txt in the root or in some other folder or wherever they are They can be registered and they'll be updated. I'm not sure I'm answering your question though Uh It's uh, I mean like dependent bot requires like a tiny little bit of setup You need to create a very simple file. That's like 10 lines long Uh, that says my my requirements files or wherever are in this folder or in that folder Whatever and then once it knows where the files are it, uh updates them all renovate bot I believe actually does it automatically. I don't think you need to register anything for the bend about Renovate bot, but uh, don't quote me on that even though it's recorded now Not gonna lie Some of the scorecard checks can be fooled, shall we say Like the dependency update tool check Currently mainly looks at like do you have it installed? It's not looking at whether you're merging the prs though And so and like the security policy It actually does parse the security policy to like guess like is this actually like a reasonable security policy But you know, it's impossible to like really create a robust parser Uh, so it could also be somewhat easily fooled as well And like here basically the Like the question once again becomes the matter of like, do you want to trust these packages? And that's also why I said that just as important as look running a scorecard is actually looking at the repository yourself And uh, seeing if it's a project that you trust Um, and so yeah, I wouldn't say that it's Uh It's yeah, please um If I think I understand your correct question correctly, it really depends on the situation I would actually um go to depths.dev look up your project Look at the tab that says dependencies and dependence See how many projects rely on your project and judge is this, you know A little experimental thing that I play around with to try out new things or oh my god, there's a thousand projects relying on me Um in that second situation, maybe when you look at your dependencies, you're gonna have a higher bar And just judge where your risk tolerance is and if it's just a you know, little toy project Lower your bar. Um We're not giving you a hard and fast like don't use anything below this cutoff. That's that's up to you to decide Yeah So This was I heard this stat. I can't answer that exactly in terms of vulnerabilities versus score But a stat that was actually mentioned earlier today That I remember 2022 Sonotype state of the supply chain report it found that there were two factors that Best predicted whether there was a vulnerability in a project and the two factors were Meantime to update how long it takes you to update and whether the project used scorecard You can show that you use scorecard by adding batch. Yeah, and also um having Um And that stat for example actually scorecard is now working or exploring How to perhaps add uh meantime to update As an actual check and let me clarify I don't mean that you're more likely to have a vulnerability if you use scorecard It's inversely proportional I don't have that we don't have that stat here Can you repeat the question for everybody? Oh, sorry. Yeah, the the question was whether there are any stats on like whether projects in rust are more secure for example And uh, I don't have that stat here But it is something that can be easily accessed because there is a big query data set Um, and that data set does include I believe language information Uh, not entirely sure I admit, but I believe And so then you could do your own exploration on that on that topic Um, this uh, so scorecard currently runs on uh, oops, sorry currently runs on Both github and git lab repositories and both public and private repositories Yeah, be my guest Yeah, so, um, please be inspired But uh, that's it. Uh, any other questions? One last question Uh scorecard scorecard scorecard is uh, we have it. Yeah, if you go all the way back. Yeah, we have we actually have it here as one of the three Was where is it? I'm getting it No, no that was that's crank There it is 9.4. Um, that score is from That's of course from like 10 days ago or so so it might be a little bit different now, but it's thereabouts I believe that's it everyone. Thank you very much