OpenSSF OpenSSF Day @ OSS Japan 2022, 17 Dec 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Open Source Security and the OpenSSF’s Best Practices WG - David Wheeler, Linux Foundation

Description

Open Source Security and the OpenSSF’s Best Practices WG - David Wheeler, Linux Foundation

Software security is critical today, and that includes open source software (OSS). This talk will discuss some general principles involving software security and OSS, including supply chain security, as well as the Open Source Security Foundation (OpenSSF)'s best practices working group and the steps it is specifically taking to address these challenges.

A

So, uh thank you Brian. So, as he mentioned, I'm David a Wheeler. It's a pleasure to be with you here today in Japan, it's my first time in Japan. So it's an honor to be here so I want to talk briefly about open source software security and specifically the work of the open, ssf best practices. Working group, as Brian mentioned, there's a lot going on within the open ssf and we thought we'd be helpful to talk about one working group so that you can get a better perspective of what the openness and stuff is doing.

A

So, as Brian mentioned, open ssf, it's established in 2020 uh we're collaborate, we're committed to collaborating and working with communities to advance open source security for all you'll see this Goose several times. I'm sure uh Brian already showed this diagram, and what I want to do is focus on this left part just one of the many working groups within the open ssf. So you can get an idea of what the open ssf is like by looking at one particular group within it.

A

So the open, ssf uh best practices working group is all about providing open source developers with best practice, recommendations and easy ways to learn and apply them. I'll also note. Frankly, a lot of the work also applies to developers of proprietary software. In many cases the issues are the same and when you're developing proprietary software or closer software you're, bringing in a large amount of Open, Source software and they're down there on the bottom left is its main site.

A

You can group the kinds of activities it does into identifying best practices, helping people learn about them, helping people adopt those best practices.

A

So today, I'll discuss a few different things of the best practices working group has done. uh One thing best practices group has done is develop. Some guides I'll talk about those a concise guide for developing a more secure software for evaluating open source software and npm best practices guide, focus on particular, widely used tool. Npm then we'll talk a little bit about measuring and applying best practices, talk about the best practices badge and this open, ssf, scorecards and then more about education and I'll have a little announcement there.

A

Some of you already know, but in that part, so, first of all concise guide. Many people have asked how do I develop more secure software. Sadly, in general, it's not taught in schools about how to develop secure software to software developers, so we need to make that information available. So the best practices working group created a very short what they call a concise guide with some high level points that then link off to more information.

A

So this gives you a place to start a place to start I'm not going to go through all of these, but I'll just mention a few here. The first thing we mentioned is ensuring that the privileged developers use multi-factor, authentication tokens, one of the attacks that unfortunately, attackers are starting to get aware of, is if they can find the password of a developer, they can suddenly do actions as if they were that developer.

A

You know why go through a lot of exercise exercise and try to learn how to do a lot of complicated things and just take over their account, so multi-factor authentication tokens make it much harder to take. Take over a developer's account. Learn about software, how to develop secure software I'll talk more about that. In a moment, we also have developed materials to help using a combination of tools and, what's called your CI pipeline, in other words, is a reality that when you are developing software as a human, you make mistakes.

A

It is a part of the human condition. That's unfortunate, but the good news is there are tools to help identify problems so that you can find those problems before you ship them. But that requires that you have tools in that check. Every time you propose a change.

A

Wait a minute is that okay look for problems and that helps you find problems as well as, of course, human review and other things um evaluate the software before you select it, and you know this and I'll talk more about evaluating in a moment, use package managers and, more broadly, the list right underneath underneath there is all about enabling rapid update today.

A

One of the major challenges for developing secure software systems is that people bring in a component I'm going to bring in hundreds of components, and then the vulnerability is found in one of those reuse components. That's unfortunate, but it happens. The challenge is what happens next? What should happen is that you should immediately notice. Oh one of the components I use has of known vulnerability now. I will quickly update it fix it, make sure it's okay and then immediately ship out the update, if you are prepared for that, it's quite easy.

A

Okay, basically, you need to automate and prepare for this using package managers which help you automate bringing in packages. You know having automated tests to make sure that when you update the software, it didn't break anything monitoring, known vulnerabilities and keeping them reasonably up to date, but that requires ahead of time, planning that I know this will happen, so I'll be ready for it. I can say. Another concise guide is a concise guide for div um for evaluating open source software. uh This is this is a basic list of nine criteria.

A

I would argue, frankly, these are things you should be looking for for any software, because you would want software, regardless of its open source or closed Source. You know two things to do things like hey, wait, I'm, not evaluating the correct version, and is it maintained uh the interesting thing about open source software that is I struggle for many people is how to get the information.

A

So we provide not just here's some important questions to ask, but here's how you can answer them, because the amount of information available in open source software is often much greater than for closed Source, but people are not used to looking for it. So, let's so we have a guide to helping people. Look for the information to help them make a good, wise decision. Again things like you know, maybe you don't need to add that software at all the most the most secure software is the software you don't have.

A

Okay, you know. Are you evaluating the intended version? One of the most common kinds of attacks today is something called typo squatting, where they they provide an almost correct name. An attacker creates something that, with a name that looks like the package you intended. Okay, so double check the name, it's not hard, and once you double check the name, you eliminate a major source of attacks so anyway, there are others lists here, but I'll put a link on the bottom. You're. Certainly welcome to take a look at that.

A

Here's, a more specific uh guide that the best practices working group has developed. The npm best practices guide. Npm is a very, very popular package manager, widely used and- uh and so these are specific guidelines for when you are using this particular tool, the npm tool.

A

um So if you're using the npm package manager, you'll first of all make sure that you have least privilege in your CI Pro integration process, and then you know, do some checks again. You know evaluate before use looking for type of squatting and then one of the first things that document does is make sure you understand what kind of software you're developing you know. Is it a? Is it a library? Is it a standalone command line interface?

A

There's an application, because the answers of what you should do and how you should use npm differ depending on the kind of software you use. So first we make it clear. There are different kinds here: the major categories and then for each major category, here's what you should do and not do, and this helps you avoid many problems and makes your life much better.

A

All right! Next topic: um we want the software. Whatever software, it is um well, whatever open source software is developed to be secure. So how can we encourage that? We actually have two different projects to help in this. uh One is the best practice open, ssf, best practices, badge I, actually leave that particular project and the open, ssf scorecards, which I interact with and I'll talk about that in just a moment, and the openness is have best practices badge. What we've done is we've identified best practices. What should you do?

A

What should you not do with the goal of of increasing the likelihood of the better quality of the software in general, better security? Frankly, better sustainability? You know things like, for example, the project must have at least one automated test Suite. You know people make mistakes, but having automated tests to check for those problems before you, ship is really important uh at least apply at least one static analysis tool. These are tools that look at the code look for problems, so they can find some problems before they ship.

A

The project must publish the process for reporting vulnerabilities. This is one of the most common missing criteria. By the way in the badge is a lot of projects, don't say how to report vulnerabilities back so tell people you want to figure out that out before someone finds a vulnerability, so are ready for the report and so trying to figure out how to do that. After the fact, and if an open source software project meets certain criteria, they get a badge there's over 5000 projects and over 850 have received at least the passing batch.

A

This is a more interactive there's, it's mostly a fill in form, so we emphasize very much what humans can understand. There are some automated ones and the fact we override if we can tell the humans incorrect, uh we do support many languages that includes English, simplified, Chinese and Japanese. The this is absolutely available in Japanese, okay,.

A

Next, the scorecards approach, uh scorecards takes a different approach um and I think they're complementary in scorecards. It automatically scores an open source project based on what's called heuristics or checks. Okay, we're looking for potential suggestions of what's working well and what's not? Each of those checks is scored zero through ten and then there's a weighted average computed, um and then this and what's nice about this- is that you can evaluate your own or others projects they don't need to cooperate. Currently, this only works on Project hosted on GitHub.

A

We do intend to expand it, but that's that's! A current limitation I've been arrested. Many many projects are on GitHub, so it's still quite useful um and I'm not going to talk about all of these, but this is just a few of the checks that includes uh things like, for example, we check for things like binary artifacts on GitHub you're supposed to only have the source code, not the resulting built results. If you do have the built results checked in that suggests problems, uh and so we want to note for that Branch protection.

A

Does it enable something called Branch protection which forces separate branches? That can be reviewed before you bring them into the main branch. Does it have tests? Does it have the open, ssf best practices badge, so this links back to the other other item I just mentioned earlier. Okay, and of course you know, does it have code review and contributors? Okay uh and indeed um stereotype did an analysis and they found that scorecards is actually pretty effective to assess project security.

A

uh There's a very strong correlation between uh the scorecards results up and some metrics in particular, and whether or not vulnerabilities will be found were being found in those programs. So that suggests that uh we're at least we're at least on the right track.

A

uh Now we do more than all the open, ssf working group on best practices does more than what I've just talked about. uh There's a very significant education component, uh and so one of the one of the first things that the open ssf did was um release something called the secure software development fundamentals course or courses. Okay, it's a free course takes about 16 hours to go through um and it covers anything from requirements, design, reuse, implementation, verification and also some more specialized topics.

A

uh You know for a variety of areas, and then the challenges I mentioned earlier is that software developers in general are not told how to develop secure software, and so this is a way to address that unfortunate weakness um and in fact this, although it's certainly, we certainly encourage anyone who's developing open source software to take the courses. We've actually encourage everyone, uh because the the fundamentals are: don't just don't matter, it doesn't matter what license you're. Releasing the fundamentals are still fundamental.

A

um If you complete the course, there's also an opportunity for a free certificate of completion uh through LF training- and some of you already know this, but in case you don't I want to make an announcement. This is an announcement for today. uh The fundamentals course is now available and natively in Japanese, so it's lfd 121-jp. You can see the title up there, I suspect. All of you can read it and I cannot.

A

Thank you. Thank you. So uh you'll be grateful. I did not do the translation, so uh my actually I do want to thank just briefly here the translators who did uh the the work of that translation. So thank you so so very much uh security knowledge framework. This is actually a collaboration with oasp uh there's something a security knowledge framework implements a number of lab exercises um that of course, I just mentioned earlier.

A

The main focus is we want to make sure that developers can quickly learn what they need to learn, but when you emphasize quick the disadvantages, if you don't do it in a lab course, you may not remember as much so the advantage of a lab, the disadvention of lab courses that they take longer the advantages that you learn more thoroughly. So that's fine. We have both. We have the course I just mentioned earlier and SKF incorporates a large number of lab exercises and they've actually integrated the fundamentals course I just mentioned ago.

A

So again collaboration working together and it also supports some other functionality.

A

um There is a general acknowledgment that education is important, um so I'm, you know Brian just earlier mentioned the mobilization plan, one of the 10 points. In fact, the first point in the mobilization plan emphasized education on developing secure software. Now, obviously, we've made some progress there. We already have.

A

You know a you know two courses basically, um but that said, um there's a there's, an acknowledgment that there's also need for more uh and so, for example, we want to make sure that we encourage people to you know, take these courses so that, for example, if you go on GitHub or get lab or you show up in an employment site like LinkedIn or right, indeed, you can see which developers have learned how to develop secure software.

A

We want to encourage that to be a value, something valuable for uh developers um and so the edu and, in addition, there's a question of what else needs to be developed. We believe that in many cases we need more in-depth material. Well, what exactly is that and for what? And so the education, Sig or education special interest group uh is created to basically these three categories uh collect and curate. What's already out, there uh expand and figure out what needs to be expanded.

A

What other training is needed and then finally work out how to reward and incentivize, because we want to encourage all developers of software to know how to develop secure software I mean I, like our courses, I, think our courses are great.

A

um This may seem strange, but if you don't, like our courses, take another course, okay, we're what we're much more of concern to us is. We want to make sure that the one people who are developing the software that we all around the world depend on know how to write it so that it is secure.

A

um I'll make a couple miscellaneous notes: Here one of the other projects that the best practices uh working group worked on and I wouldn't be surprised. If we work on it again. uh Last year um you could say it's kind of a Christmas time kind of thing, we're trying to send out some gifts, so we were engaged something called the Great MFA distribution project. I mentioned earlier that a lot of attackers.

A

What they want to do is take over the accounts of developers so having Little Hardware tokens to log into those accounts counters very, very well, most attackers efforts to break into developer accounts, and so we actually spent some time to identify the top 100, most critical, open source projects, and then we went out and individually contacted each one and offered them free, MFA tokens and if they said Yes, we made we arranged for them to get for their developers to get the MFA tokens. Why?

A

Because this makes it harder for attackers to subvert these most import, important, open source software projects and I think it was a. It was a big success. We had lots of people say thank you, uh you know, and um you know and I just we distributed many hundreds I would have the number in front of me but I'm sure we'll do it again. uh We also have some incubating projects.

A

I won't talk very much about them, but just primarily to note that the best practices working group- the point- is to collaborate together to develop these guidelines and criteria and courses and anything else to help develop better software that we all depend on now. I've focused only on the open ssf but, uh of course, I only own the openstack best practices working group, but, of course the open ssf does a lot more. This is only one working group.

A

um I'll quickly note some others uh Brian did did. Warn you I would do that. So um you know one of the other ones is something called Salsa. The idea is there is they're supposed to have a checklist of standards and controls to prevent tampering, they're, focusing very much on build level, um they're uh they're right now, working on focusing on uh defining levels, one through three.

A

If you look on their on their main site, they have an early draft of one through four right now, they're, really focusing on being very, very uh precise and clear about levels, one through three and just trying to make sure that they're as clear as and as possible, um something else called the s2c2f Sig. That's just started out the secure soft supply chain consumption framework.

A

um It is focused on how to ensure that the software coming in is, as you know, you're securing it not not just that it's secure, but your process of bringing it in is not easily tampered with. Alpha Omega is another really interesting project. uh It funds, critical, open source, offer projects and identifies and reports vulnerabilities in the top set. You know right now we're focusing on the top ten thousand uh open source software projects. I'm gonna go go, do some analysis, find vulnerabilities report them and get them fixed before the attackers do all right.

A

So this is my uh my key slide here. I. Would please encourage all of you to get involved. um You know. Software security is not really just an open source thing. It's not just a closed Source thing. It's a software thing and it is a worldwide issue. We all around the world depend on software and sadly there are those who wish to exploit that and wish to do. Others harm that's unfortunate.

A

We can't change that fact, but we can make it very, very difficult for them to exploit that software, and so, if you're interested in getting involved in this process, to really make the world a better place, please please get involved. uh We have zoom calls. We have mail lists, we have slack, we have GitHub projects. We have many many different ways to collaborate. Work together.

A

If you have nothing else, there's the URL of open, ssf., open, ssf organization, openssf.org you're, certainly welcome to email, Brian or myself um would be delighted to help so with that Arigato. Thank you very much.