OpenSSF OpenSSF Day Open Source Summit North America, 15 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: OpenSSF Day at OSS NA - Automated Techniques for Measuring Trustworthiness of OSS Code & Communities

Description

OpenSSF Day at Open Source Summit North America - Automated Techniques for Measuring Trustworthiness of Open Source Code and Communities - Jeff Mendoza, Google & Naveen Srinivasan, Endor Labs

A

uh Snacks and beverages and continue the conversation so our next speakers, I would like to welcome to the podium jeff, mendoza and steve in august. Oh.

B

A

Steven, the man of mystery was not able to join us, so we have naveen srinivasan here. Speaking on behalf of our friend, stephen jeff is an engineer at google's open source security team he's focused on supply, chain security and securing google's github repositories. I will let naveen introduce himself because steven didn't give us a bio either. So please, jeff and naveen take it away. We would love to hear more.

C

Test test all right, thank you! Everyone, everyone for joining um and thanks for the introductions group uh today we're going to talk about automated trust techniques, for measuring trustworthiness of open source code and communities and that's a mouthful, and so I'm going to start it off and then naveen's going to cover some bit and then we'll we'll switch back to me naveen. Why don't you go ahead and introduce yourself hi.

D

Obviously, like what crow and jeff mentioned, I'm not stephen, I'm taking over for stevens, because stephen couldn't make it uh because of flight delays, um I'm going to try my best to cover up for things, and this is next in these last r. I prepared for this talk.

D

That's that's a quick about update of what it is. uh I'm navinci newasan, I'm one of the maintainers of the scorecard security project um and I work for indoor labs, which is a supply chain. Security startup um thanks, yeah.

C

Yeah and one of the benefits of having your your conference in your hotel is, you can get here really really quickly in the morning, but you can also go to your room after lunch for a nap. So thank you, everyone for not doing that.

B

C

Here because I could use a nap right now um so before we talk about automated uh ways to judge security and and trustworthy and trustworthiness, uh we should talk about the previous techniques or before automation, and that is the open, ssf best practices badge.

C

So this was kind of a precursor to some of the automated tools that were developed to to judge trustworthiness, um and it was formerly known as cii best practices badge it. I think predates openssf, so it has. And since it's not an automated tool, it's not something. You run it's it's text, you go and you look and you see what what are the requirements to meet these best practices and it's a lot of text and it's really really great. It's a really great resource, for you know an authoritative place.

C

We can say these are the practices that we recommend. This is something that is secure and you can go and see what you need to do to to meet those requirements.

C

And then, if you attest to meet them, then you get the badge and one another thing about the badge is it has full coverage because it's not limited by things that can be automated and as you'll see with the automation techniques later, of course, there are limitations to what you can build inside of a inside of a tool um so getting onto the first tool, we're gonna talk about scorecard and naveen. As the uh is a maintainer of scorecard he's, gonna go over that.

D

Okay, thanks jeff um scorecard is an open-source project um and it's an automated tool to help analyze most of the security issues that that are uh that an open source project could have scorecard is developed by with an open ssf with cross-cut industry um organizations like github, google ibm and uh all these organizations um there are. There are multiple maintainers, I'm one of the maintainers, among that, what does kolkat do tries to do scorecard, tries to identify the good practices, as well as the bad practices scorecard attempts to detect if the good practices are followed.

D

Example, do projects do continuous testing fuzzing. um Why is this critical, because that reduces the number of bugs in the source code? um The next thing is, it looks for, does it do do projects update their dependencies?

D

um Is it imp it's important so that you patch your vulnerabilities?

D

Does it have safe configuration settings, something like code protection um which which we will? I will be doing another talk tomorrow, which we will demonstrate? How that can? How that, if you don't have that setting enable how malicious developers can push source code into that? It also looks at web configuration settings like? um Is it authenticated.

D

Like I mentioned, not just good practices, even bad practices, um things like do you have a bus factor of one button. Is it maintained by only one developer? If it is then there's a higher risk of? If that one developer, something happens to him, then who's going to maintain that project looks for.

D

Are your secrets accessible to pull requests I'll demonstrate as it goes on the talk of why it can be a problem? um It also looks at how the attacker can circumvent your permissions and bypass code reviews things like that.

D

Primarily, what are the use cases of using scorecard? You can do it for your own projects, as well as for your dependencies, improve improve the security practice of your own project as well as your dependencies. Can it can it can identify if your dependencies are being maintained. Are there any vulnerabilities in your project and your dependencies.

D

Okay, uh I'm going to skip that. I'm going to go to this specifically, because um how do you install scorecard? How do you run scorecard? um The easiest way to run scorecard is using docker run. That's the easiest way to run this one of the critical things that you need is a github token, because scorecard primarily utilizes github token to use the github apis. That's that's something! You need that and using this uh there's a there's, a docker container to run that and you point it to a repository.

D

It runs all the default, all the checks that needs to run when it runs. What does it come back with? It comes back with certain warnings, um the good and the bad like. Like I mentioned it's going to come back and say what are the things that it could it could identify as not not not working like. In this example, it's going to indicate a project exposes secret to pull requests.

D

The next one is have somebody how an attacker can change the permissions of the workflow, that's critical, especially on the supply chain security, because if somebody can change your permission, that means they can.

D

They can take over your take away your code and then this last one how how your dependencies are not being pinned pinned with hash, so that somebody so that what you depend on can be changed and that could cause problems and which I will be demonstrating in the I apologize not today, but in tomorrow's talk now coming back to how is scorecard being utilized if you're using any go project. The official package.dev.go.dev.

D

Now provides a link to every project as to how? What is the score of each one of these things, which is which is uh which is which provides a link.

D

Another classic example is depth.dev, depths are dev people who don't know. Debsa dev essentially takes all your dependencies and showcases what uh on any project, what are the dependencies and what others depend on you based on that, and also along with that, the depth of depth also utilize, shows scorecard scores for each one of your each one of those projects and how they how they stand where they stand on each one of these checks, and what you see on the right side is all the checks of scorecards checks.

D

You can utilize scorecard for your own projects.

D

I show uh just now I showed prior to this, how to utilize scorecard using cly scorecard also has an action, a github action that you can install and it'll run for your project, your getup project and figure out. What are the? What are the best practices? What what are the things that are failing on the action runs on two two two different settings: one is a cron job that keeps running every uh on a crown.

D

Another one is whenever there's a push to your repository and all the results are stored within your get up code scanning so essentially you'd be able to go. Look at what the state of each one of these things.

D

Here's an example of how these results would be shown. It's not it's not shown to every every one of the content. It's only shown to the contributors and the administrators. What are things that are going wrong? The example these are the these are the ways it shows critical, high low vulnerabilities in any one of these things.

D

um That's about it thanks.

C

All right so um we've learned the automated techniques to judge the security posture of other projects, um and so I hope you you know would want to use those for your dependencies that you're using or dependencies that you may be evaluating to to bring into your project and depend on them, and then we've learned how to run scorecard on your own projects, because if you want other people to use your project, you want to have a good score. But now you might be thinking now.

C

How do I take these best practices and high security posture and apply it to my projects at scale and across and with enforcement or with with continuous checking? So that's where we bring into all-star. So if scorecard gives you a good score, uh you can use all-star to make your make yourself an all-star of of your scorecard score.

C

So we'll go over what is all-star, so it is a github app that continuously checks for your those security, best practices on all of your repositories as many as you install it on it can raise alerts like github issues, or it can actually just fix those settings that are if they are settings on your github repositories.

C

uh It based on what you decide so again, you decide what policies to enable- and it also extends a little bit past scorecard where, where scorecard, is a tool that is objective, the best practices come down from the our best best practices. Working group of the open, ssf all-star is a little bit more tweakable where you can decide for yourself. What do I want to enforce on my own github repositories and set those settings up uh with your own configuration.

C

So again, here you know it's in github app, you go. How do I use it? You go. You click install and you install it on your your organizations. um It has access to read the contents and settings of all your. Your repositories creates issues again set settings. uh If there's anything needs to be configured and it can actually, you can use it not just on public but on private github repositories as well.

C

So here's the configuration is all yaml files that go in a special github repo in your organization and you can turn on and off again all of those best practices. These are all really analogous to the scorecard checks that we saw that naveen covered. You can turn all those on and off and decide what you want, the enforcement action to be, and then you know which repos you want to be uh be enforced as well.

C

So um just to give you an example: um ann earlier today covered you know your security md, how you should have a security policy. uh um Also our scorecard can check for that. But you may only want to do that on your public repositories, because your private repositories don't need that. So you can. You can configure the all-star settings to only alert on um for each policy like which type of repository you want it to check.

C

And again, here are some of those example policies.

C

A big one right now is branch protection, so github has quite good settings for letting you enforce that on certain branches only commits go in through pull requests with certain reviews, and it's we want to apply that at scale on all of our repositories.

C

So allstar can put that on for whatever settings you pick and then make sure that it stays on.

C

When you for the for the policies that don't have a setting, that we can just go and set and fix for you, these are the alerts that it raises currently. So, if you have again a thousand github repositories and you have owners of each one, you can give each each repository owner an alert via a github issue that they need to go and fix something like remove a binary, artifact or set up a security md.

C

And that's just a real quick overview of all-star.

C

Just to wrap up both projects here in the open, ssf pr is welcome, but if actually that's kind of a joke, you know just join the join. The community uh join us on github, create us, create issues, we're on slack, open, ssf, slack and mailing lists, and we have our bi-weekly meeting any questions.

C

Yes, yeah so scorecard, uh oh yeah, I'll, repeat the question. So the question was: um what about places that you host your repositories that are not github uh scorecard works on git repositories.

C

It checks, it checks all of its settings there, but the a few of the settings that scorecard checks are github, specific and then all-star. Right now is a github app.

C

So all of the code is is connected to github, but the um the project is the the intention of the project is to be policy based and for all these settings. So if that could be applied to gitlab or any anywhere else that has like branch, protection settings or other settings that need to be um need to be checked. That would make sense for the project as well.

C

uh It's it's not for me, but it's a again part of the project. So if anybody wants to work with me, I want to work with them.

C

Duet, how does anybody.

B

Contact you or brian.

C

Yeah yeah talk to me afterwards and um brian.

D

Adding to that specifically um scorecard has a setting that you can run on local git repositories, but it's not going to cover all the checks, but it's cover certain checks scorecard has a you: can utilize to run on local repositories that, like what jeff mentioned.

C

All right: well, thanks.

D

Everybody, no no there's a question.

C

uh So, like you're talking about the the alerts- and you want to stop the alerts yeah, so the config is set up where either the organization owner can be the gatekeeper and allow things to be turned on or off or or accepted, or the organization owner can allow the individual the repo itself to opt itself out by setting a file in its own repo. So it's uh it's flexible, based on how the person installing all-star on the org can decides what they want to allow or disallow.

C

A

Yeah so when you're running it against the local repository.

D

No, it does not need more, it does not even obviously right that's a whole idea, so you don't need to you. Can you can earn it on you? Don't you don't need that yep? You don't need to you, don't even need yeah, you don't it does not go. It does all the checks locally. So it does not need any get about token.

C

D

We, the scorecard, um has contacted gitlab and we are working on efforts to not be specific to get up did I did I say that correctly. Okay, I just want to make sure that any of the questions- commons, okay,.

C

D

C