 Thanks everyone for joining today. My name is Christine Abernathy and I lead the open source program office at F5 and here to kind of just chat and talk about what we're trying to do around managing and securing our GitHub access. Looks like most of the room is on this side. But a quick question for those who are here. Which garden would you prefer that you had? Raise your hand if you prefer A. Raise your hand if you prefer B. The B's have it. The picture was taken from yesterday. I got a chance to visit Stanley Park. It's a beautiful place. Unfortunately A comes from our back garden when I was in Campbell and it's a bit of a sorry sight. But I was inspired by this. One of our open source ambassadors at F5 wants to write an article about community and gardens and it inspired me to think about GitHub and management and gardens and a plug for the next talk about open source ambassador that we're going to be giving as well. But when I think about like gardens and GitHub management you might want to have things just in this place but sprawl can happen and things can just happen all over the place. Or you want all of your vegetables to be here and somehow you planted mint and it just, that was a working mistake I made and it went all over the place. But just kind of getting a handle on when things are at is something that I think about when I am, think about GitHub management and how you want things to be done well. And so when we're thinking about GitHub management perhaps you are an Ospo maintainer or an Ospo lead or you're working with that. This talk could be useful for you either if you are new because you are trying to figure out how you should set things up or perhaps you are already been very seasoned Ospo veteran and you're just here to see some of the things that we've learning maybe pick up some new things along the way. Or you could be a maintainer and open source project maintainer and the interest here could be just to see how you can actually secure your own projects. For various reasons this is one of the things that we were doing. So as a young Ospo we're trying to figure out all of the GitHub also we have the members et cetera and how we supposed to be set up in a way. And this is something that is actually important to us. And Ospo may have many different responsibilities and one of them is related to how we manage our GitHub orgs and membership. It's a key part of our infrastructure and how we show up. So this is pretty important. A reason why we wanted to tackle it. And the reason why this is actually an important piece of infrastructure is your open source projects. Your GitHub is almost like your presence to the world and some of the benefits where you think about how you manage it properly is obviously the talk is about security. So when you're thinking about security what are the policies that you're applying that are common across all them. This is something that you want to think about consistently. In addition to that just like the garden it could be like all kinds of sprawl where you don't even know where did I plant my tomatoes because weeds are all over the place. It's a question of like somebody coming into your GitHub presence and not even knowing where to go to find the repos of the projects that are interesting to them. Perhaps you have a website but sometimes people just like to go directly to your GitHub presence for that. Another thing that is actually important is around efficiency. So if you want people to actually for example create or produce new open source projects and it's not really very clear how they can do this. This can actually slow them down. So when you're thinking about efficiency either from the point of view of people wanting to release code or efficiency from the point of view of you just wanted to better understand and manage. This is something that you want to think about. And when it comes to sustainability GitHub management can really help. If you are an Ospo and you're maintaining a whole bunch of projects you want your project maintainers to basically fall into the pit of success where they actually very clear to them to know how they can actually release a project and what are the best practices around working within a project. So for all these different reasons you do really want to pay attention to your infrastructure. And obviously there are many challenges that come from thinking about managing your GitHub assets. And I'll talk about what the GitHub assets are. But for example one of the challenges could be just the fact that you have so many repos and in your particular org thousands. I mean we've got companies that might have like hundreds of orgs or thousands of repos and the challenge here could be just like how do I actually set the settings just right because I did it for this org this way but how do I do it for that org and how do I make it consistent. And that could be like a challenge for you. And so sometimes it's just like some guesswork. I remember there was a time where I had to kind of like set up a new org and you have to figure out what is the checkbox. What did I do last time. And if it's not really consistent then you would be leaving yourself open to missing a particular checkbox or something and things not working the way you want to as well. Also another challenge is with like GitHub management especially as they are actually rolling out new features. Even just setting up some of the settings can be a bit confusing. For example there might not be like best practices that are available out there that show this is if you want to set this up securely this is what you should do. So the settings are not always very clear. They're not a lot of like best practices and examples that are out there right now. And you know if people don't know how to use how things should be set up or even just know how they should be like publishing a new project and you make it really difficult to do so they're probably going to go off and just like go rogue and probably just like do a personal project and that could lead to leaked IP. And also if you actually roll out a policy or guidelines and you make things more difficult then you're going to have people try to do things or get around it. So too much red tape without making things easier is a challenge as well. And you do not want those folks just like doing just doing things any which way. So those are the key challenges that are in general. When it comes to like F5 over time we actually acquired a few companies along the way. And just like you could have a community garden and everyone wants to do things their way. It makes sense. This company used to do their open source projects this way and this is how they used to set up their securities but then that company is doing things different. It's natural but when everyone comes in with their own way of doing things that can get tricky. Also before the open source program office was formed at F5 there was like different teams responsible for different parts of open source and there was one team responsible for like if somebody wanted to add a member to a particular org that team would do that. And so there was like an operation team that was basically managing that and they didn't really have that much open source experience. So they would just basically be answering those these IT requests but not really knowing if they were doing the right thing or how it affects security. So some of those things is just like historical reasons. They just needed to kind of like know how to actually apply things in a way that made sense in the open source world. And so and then also some of the challenges that we had also applied just the fact that a lot of people are doing things differently. So just to step back just a kind of like a quick question. How many people in this room are actually involved in Ospo or run an Ospo. Just like a quick. OK. And do you have like for those who run Ospo's do you have like say more than five orgs. OK. So pretty pretty small amount. OK. It's kind of good to know. But when you're thinking about like what are the security risks that the key thing is that you want to protect the source code. That's what you really want to do. And GitHub as an example for this talk. I'm actually focusing a lot on GitHub because that's what we use. But towards the end I'll also touch upon GitHub. But GitHub is like a social construct around code. So you've got things like organizations. So you could actually create a repo repository to host your code. It could be on your personal account or it could be on an organization. And there's reasons why you would do one or the other. But if you're in an Ospo you're typically going to have people contribute and have their repositories on an organization. The repositories or could you could have teams assigned to repositories and you could have organizations who create the teams. Organizations can have members. Members could have higher privileges. They could be members. They could be owners. And you know there's all of these different levels of controls. And these are what I think about as assets. But at the core what you're trying to do is protect the code. So code security is one of the consideration that is key. And when I think about code security the question is who has access to that code. What does the development work for look like. And who is actually involved in sort of like collaborating and managing that code. And I didn't like mention like collaborators in here but you could have like members who are part of the organization and you can also have collaborators. It's just kind of like just level setting a lot of the different things so we can speak in one way. So collaboration and communication is another key thing especially around developer workflows. And very important consideration as well is monitoring and analytics in terms of like who's doing what. Things being audited. So these are the things that you want to be mindful of. So as we think about protecting the source one visual that I like comes from the open source security foundation. It's from this supply chain and levels for a software artifact is called Salsa. It's a framework that thinks it's a good way to think about all kinds of threats that can happen. You've got the producer on one hand on one end and you've got the consumer at the other hand. And you've got like the source code and the source then gets built and then packaged and then the consumer basically typically gets it. Somewhere around that it buckets it into these different types of threats. You could have source threats. You could have built threats and you could have dependency threats. So source threats is where I'm thinking about like say I'll get off source code. But even as you create source code you typically also pull in dependencies as part of your project. So in terms of source threats the things that could go wrong could be like somebody may be submitting a change that you didn't expect it to or there's some compromise that happens at the repository level or another threat could be just like somebody actually modifies the source code during the build step. So these are the things that can go wrong and when you're thinking about integrity the key thing to see here is that you want to make sure that the source is what you intended to do. So what are some of like the so you want to think about making sure that that is that the integrity is actually being being like preserved. Examples of where that's sort of like these exploits can happen at the source level. There's an example where one particular malicious actor actually got into the a particular GitHub repository and made a commit and just made made up with like the estimate is about three million dollars worth of Ethereum. And this is because they actually were able to get into the source code and and do something that that that wasn't intended. So that is one example of a source code threat. And another one which is so called called protest where is there a particular maintainer had these two packages of libraries called colors and fakers which are used by lots of different projects. And what they did is they went in and created almost like an infinite loop. It's almost like a denial of service and and and projects stop working. And this is a case where the actual maintainer themselves is the one who went in and and did something that was not was not the best thing. These are an example of of things that could go wrong. So how do you mitigate some of these different ways and levels that you can do. I mean not a no brainer in general is just to make sure that if you are a contributor or a maintainer or if even if you are an all level maintainer make sure that two factor authentication is something that is being enforced. And the good news is that GitHub is actually going to make that mandatory by the end of the year. So don't have to worry about that if you're struggling with trying to get people to do that. Another thing is just to be aware on in terms of access control who has access to what the members able to say create public repositories private repositories. Can they do they have like basically the keys to the castle. And so these are the things that you want to think about in GitHub makes available. Code security is another key sort of like bucket of things to think about. So if you want to enforce code reviews. So if you go back to one of the exploits where the maintainer actually injected sort of malicious code potentially if there was a code review that was enforceable and there and and set up in a way that that can be not be bypassed and somebody else would potentially have caught that assuming they were not part of the whole thing. But that's kind of like the key thing you want more than one person looking at the code and reviewing it. So branch protection rule is one of the things ways to do that. And if you want to have people more people contribute then generally you also want to invite either collaborators to kind of be in on the on the action. GitHub also makes available a lot of code scanning tools once called code QL. But you can turn that on to make sure that people know that that the maintainer can quickly spot if something is is wrong and it can send you all kinds of like email alerts. Another thing that they actually also do as well. And this is just like whether GitHub does it or not. You should have a way for people to report security vulnerabilities and do it in a way that it doesn't like kind of like open you up to a zero day exploit. So a way for private reporting of security vulnerabilities is really important. And give up also allows you now I think last year they released a feature to make that very easy to do. But if you don't go to GitHub's way at least you can check it out. Dependency threats is another thing that's pretty important. So we saw the salsa levels and dependency could be like a compromise dependency. And even in the example that I showed somebody actually like inserted malicious code into dependency and then that affected anyone upstream who was using it. And when you think about dependency some examples of this event stream was one of the supply chain attacks that was about 2018. And what happened in there is almost like a social engineering attack. So this particular particular developer kind of got the trust of the person who was the key maintainer of this this library that's used in a lot of different places. And after they were actually given ownership of that actually library that then introduced malicious code that was there for a little bit. And it actually took like I think they say about two months before it was even noticed. But it did cause a lot of different things because it was actually taking away. It was taking like private keys related to blockchain and and was able to kind of get a lot of get into a do a lot of damage in that way. But the key thing here is that it was like a social engineering attack. The dependency then kind of like made its way downstream and it took a while to kind of get noticed. Another one called UA Passage. Yes. And this was an NPM that this is a package that was actually was go again similar thing was able to get in. And in this case I think what happened is that the attackers attack was able to compromise the credentials of the actual developer and then was able to attack the dependency build it. And that's the way that they kind of got in. So these are all these are all things that can happen. And when it comes to GitHub some of the security settings that you can do you can do it both at the organizational level and you can also do it at the repository level. What you can do is GitHub will make it available for you to see what your dependency graph is as well. And they also have something called the dependabot which is I think is usually disabled by default by dependabot can you can configure it enable it. And then whenever you have dependencies where there is like a known vulnerability you will be notified through email. A lot of maintainers may say that this is very noisy and a little annoying especially if it just keeps sending your email. But it's just something that is sometimes it's like a necessary and necessary evil in terms of like you want to make sure that you're alerted when something's wrong and then make a decision to address it. And you can do things like you can say I wanted to automatically create PRs or pull requests on GitHub. If there's a vulnerability or just send you a report. But that's something that you definitely want to turn on. So another thing that's actually pretty important kind of tangential but it is actually when you think about security you might want to think about the community. So why is security good. Why is a community good for security. So open sources is a lot of eyes are looking at it and a lot of people say that the reason why open source may be more secure than proprietary software is that because there are so many people looking at the source code you might have that many people be able to spot a vulnerability and potentially even patch it a lot faster because it's the code is open. The question is then obviously if the vulnerability has already been out there downstream of people actually applying those patches into their own system. But in general that's why having an engaged community is actually good. Additionally if you have an open source project and you want to especially becomes popular. You want to share the workload if you're a maintainer because that allows you to for example have a lot of other people either help you triage issues if they're coming in or even be that extra contributor that helps within the code review process. And if you do have a lot of these things good things going especially let's say you have an open source project and you make it so that somebody wants to come in and use that project. A lot of people are more attracted to a project if they know that the types of folks who are contributing to come from different backgrounds meaning like even different organizations. And that's why a lot of projects may end up going into foundations because people do like to kind of go into to use open source project or contribute to open source projects if they know that there is a diverse representation of people who are working on it. So community is good. So how do you what are some of the best practices to actually grow a community? You know your community might depend on what your project is doing and what your goals are for your project. So know your community is one of the key things that you want to do. And if you know who your community is what are some of the things that you're thinking about to be welcoming and friendly. As simple as having a code of conduct on your repository is going to help. Not just having a code of conduct but making sure you can enforce it. And then you know things like contributor guidelines if you're trying to grow your contributor community. Being responsive on your issues your pull requests. All of those things are really going to be important and being very transparent especially if it's a big project but you can start really early about what type of project you have. What is the ways that somebody can say move up and become like a contributor or triage. And also things like just being open with your roadmap allows the community to feel like they're part of the process. And again all of this just means that there are more people looking at that project as well. So when you think about that insights is one of the key things. Once you know who your community is and the goals of what you're trying to measure you want to look at insights. And the example I have here is GitHub recently are actually in the process of rolling out. If you're an Ospo lead lead you can look at GitHub or Insights and get a chance to look at some of the how some of the projects within are doing. What is the pull request average. How fast the people responding to issues. Do some of your repos have some of those files that you need such as the code of conduct the contributor guidelines security file. There's a lot of different things that it can actually tell you. And this is not the only insights there's a lot of different companies such as like chaos also has a dashboard that can have you look at different things like what is the what is the makeup of external versus internal contributors and all the different things you can look. So there's a lot of possibilities that you can see out there. So talked about like securing F things in general. So what what about us what would have been been working on. And here I wanted to start with like we started with a vision of what we wanted to see in terms of how we manage our GitHub organizations. We wanted to first of all make sure that we were in line with some of the best practices that were out there. And I wanted to make sure that in the future the new projects that were being launched as well as any of the key projects that we have we're going to be following some of these best practice. And I say new and strategic because sometimes you might have like really old projects which are just like sample projects or demo projects that are still going to be out there. But there's sometimes no need to kind of put them under some of those stringent compliance requests. But in general this is what we want in our vision. We also want to make sure that any policy or guidelines we do has complementary tooling. So some of the lessons learned is that if you actually want people to enforce certain things it's always good to have tooling that not only helps people again fall into the pit of success but also help you to monitor what's going on. So tools are really good. And also another thing that we had is a vision for the future in terms of standardization is make it really easy to streamline the process of how you launch an open source project but not only launch but also how do you support the community. So after we kind of like put together what the vision of what we wanted to this was kind of like the outline of the project. So we basically started to figure out what is the plan and we started by just basically drafting the guides and the policy document. And when we as I said before we wanted to look at industry best practices. So there's a lot of good resources that we actually looked at. And then as part of the plan we also recruited initial stakeholders. Some of these came from like the F5's open source ambassador program as well. And these are people who are really excited about GitHub or open source in general. And so the few who are excited about this topic they were able to kind of come help us with that initial plan. And then getting thereby in because they also represented some of the different open source entities that we had like some of those different companies. So that was actually pretty important. And then as part of the plan to sort of go into the next stage we also wanted a working group to just go in and help guide the work and the implementation. And again you want as many people and stakeholders as possible because those are the ones who are more likely to help you push things through. And so some of the resources that we found really helpful was that GitHub has some really good documentations and guides around secure security and also how you manage your repos and your organization. The open source security foundation the OpenSSF they think a lot about security. They have a particular group called The Best Practices Working Group and I'll talk a little bit more about that. But they also have some good information around there. Legitify is an open source project and what they do is they you can run it as a tool and it'll actually give you a security posture of how your orgs and members are doing. And Scorecard is a project that's under the OpenSSF and they're being used increasingly now. And it can actually check a whole bunch of different things and I'll show you the check in a minute but it can also help tell you how good you're doing in sort of like the security spectrum. So these were the resources that we used to set up our initial document. And as we were drafting it we also had the we also were able to kind of set aside a separate organization github.com slash F5 and we also had a new project that was coming up and we were able to test some of our initial thoughts around how we wanted to set up in this sort of playground which was different from trying to go with an existing org where there was already a lot of stakeholders and we did not really want to interrupt some of the work that was already going. So I've documented actually outlined the challenges, the vision that I already explained and then for each type of asset whether it was an organization or a member or a team we outlined how we wanted to secure each of this. For example, if you're an organization we said you must have to a multi-factor authentication on. You want to make sure that the members are like employees. Want to make sure that if somebody is an owner they need to be an owner. We want to make sure that owners are checked every so often and if somebody hasn't been active for a certain amount of time we remove their access. If somebody is no longer an employee we remove their access. If you're like a repository we want to make sure that branch protection is on and went down the line and all the things that we thought would be really good. So we did that for each asset. We also talked about from the operations point of view if you're running operations what does it look like to actually start create a new repo? What are some of the things that you need to be checking if you have a new organization? How should it be set up? We also tackle the issue about like having so many different orgs. How do we tell this org versus that org what needs to make it different? Some of our orgs were tied to like commercial and community support so they needed to stay separate. Some of our orgs are very much demo heavy and so they need to be separate. And the reason why you want to separate some of these out is because you might have you might treat some of the orgs differently from others. Demo's may not have such a heavyweight support requirement but if it's like all of the projects that are should be really key and strategic you want to make sure that those are doing really well whether like being responsive to issue requests. And if you separate them out there like that it makes it easy for you to apply tooling in a way that's that's really relevant to that org. So as I mentioned before OpenSSF was one of the resources that we use pretty heavily and the best practices working group attending that they have a particular guide for developing more secure software. There was a lot of information that we got from there. The scorecard project was also very useful. And in a way as we were actually working on this project a new document or a guide was spun up under the best practices working group called Source Control Management. So that was actually where I learned about Legitify and I was actually a pretty good timing because we've been involved in that and helping them draft some of the document that is in there. And you can take go take a look at it I look at it as well especially if you're coming from a GitLab background. It kind of goes through all of the different things that you would want to do from continuous integration and there's lots of different recommendations around policies and how you would want to apply that. So it's been a pretty good learning and working with them. So after we basically worked on the planning now we're working on the requirements and with this initial group of stakeholders we're able to draft the initial guidelines and work with them to at least say OK this looks good. And here it's what we wanted to get out of there is wanted to move into the next phase of implementation. I wanted to make sure that we at least had a good view of what the lay of the land look like and what are all of the different. What are some of like our different orgs doing? Where do they score in sort of like industry best practices. And so and we also wanted to make sure that as we went into the next phase we had the right people in the room the stakeholders to help us phase this out. So those are the key things that we're working on. So we've able to get the audit report and now we're basically looking at reviewing that and getting sign off. And for auditing what was useful again the GitHub has an API that allows you to get a whole bunch of information. And we use the graph QL graph QL query to do that. Chaos is an organization and they also think about insight insights quite a bit. So we we looked at them as well and see like for example what are the things that would be interesting to measure and say that obviously the number of members the number of owners the number of repos number of vulnerabilities and on and on and on issue request. And so there's like all of these different things. And then once we saw what things we wanted to measure then we try to look at tooling and find what was there and available and the jitify and scorecard as well. Those is what we use to audit. So I'm just going to quickly show you like some of the things that scorecard and all can do. So if we go to all right. So I'm first going to just kind of like show you what we did with the auditing. Actually I want to quickly before I do that. This is I just created a an organization called DG rule. Can anyone guess what DG stands for? I should have. It's called demo gods. So hopefully so demo gods is like an all that we created. And we have two people who are like rules here. And there's a particular owner in here. And we also created a personal access token because when you're actually running some of these reports you need a personal access token. And and then this actual org has one one repo call. It's fine. It's not really but that's basically a very simple org that we said and we're going to use that to kind of run some some reports. So when you look at let's go here. I'm just going to give you a quick so what I have in this terminal is I've got scorecard. There's different ways that you can run scorecard. You can run it as a GitHub action at the end of the day but you can also run it downloaded and run it as a standalone CLI tool. So I'm just going to run scorecard and I'm going to run it on this repo. It's fine. And what it's doing is it's running all these checks and I'll just go through quickly. So these checks these checks include making sure that you're you have a best practices badge. There's something called the best practices badge and you self attest a bunch of different things. And if you can actually go through the exercise of going doing those best practices you'll find that you'll do a lot of things that are really good for from a security point of view. It also checks things like what are the token permissions if you have any binaries like a part of the repo it checks and like do you have fuzzing enabled do you have dependency that's pinned pin dependency is like kind of like a touchy topic for some people they believe that it should be pinned some people believe it should not but there's a lot of different things in that do you have a license do you have any dangerous workflows and you get have a security policy and this is a security policies where you tell people how they could report vulnerable as a vulnerability so that's pretty important as a bunch of different things that it checks do you have you running a code review. So as you can see it's fine has a score of 4.4 does 4.4 mean they say that usually anything above 7 is good and it tells you also why why it's called that way binary artifacts there's none is just to read me branch protection is not even on CI checks not even on so these are different things that you can do and it gives you a lot of these things that are actionable that you can go in and change things for example if I were to now go back into here and let's say I'm going to go into settings and I probably just going to turn on branch protection so branch protection branch protection rule I can just add something may I just call it something like that and require pull requests and this is just something that says that before somebody does something that should be a pull request and then there's other things like do you want status of CI checks before passing or merging. You can go down this list so for our own configuration we actually said we specified what we wanted but for this very basic thing I'm just going to say okay I'll create this branch protection rule that's going to send me an SMS where is my SMS give me a second this is called 2MFA so I guess the demo gods do rule or don't yeah so what it's doing is it's actually just basically this is pretty serious alright so now we've got branch protection on and if I were to hopefully run this again hopefully my score creeps up a little bit maybe maybe not but that's kind of like how you would set up branch protection and how you could actually use core cards to basically so we kind of like creeped up from 4.4 to 4.6 the other one that I wanted to show you really quick is Legitify so Legitify again is is a way that you can actually go through all of your repositories and it'll give you like a really cool report here it can talk about things like it'll very quickly highlight the fact that I don't have 2MFA turned on at the org level there's a lot of data okay so it's things like the default branch yeah it spits out a lot of things because it's going through all of the different things and it's kind of giving you a sense of how things are set up and so for here it'll tell me and it gives you also like a severity of medium or high so you definitely want to go through and address all of the highs things like GitHub Action should be restricted so this is what Legitify did and so we took these two like kind of like tools and we put them into like a script and we ran them across all of our different organizations that we had and so here I'll just kind of give you a sense of what the tests look like for just this organization so for this organization it just runs through and it gives it runs the same Legitify things but it just gives me the insights and it saves it as a JSON file and also once it's run that then I can actually create a report so this report is just basically taking the JSON file and making it in a pretty way so it's basically saying thing like okay DG rule is fine scorecard was 4.6 and it just talks about for the particular org what these are the number of admins two factors enabled for the two people who are members there's one public repository is no full request there's no critical about but this is kind of like the audit report that we run initially for all of our organizations so that's basically kind of like a quick example of what we did in terms of like the audit and so as we go through the next step of what we're trying to do we want to make sure that for all of our strategic orgs we make sure that they're compliant going through the audit turn on the configuration rules that we want in our document want to make sure that we train the maintainers so that they know what are the best practices why did we even actually set this branch protection rule on what is it good for and then for the ops team give them a playbook that they can then use so that they don't have to like think too much now they actually have something to work with and then as we go through and get input from some of these stakeholders refine our document to make sure that we are handling as many of the use cases that they want for the future work we want to make sure that we expand compliance across all of our different orgs and build as many self-service and automation tools to make sure that people are know how to use this thing and keep compliant and for some of the self-service tools an example could be if you're a maintainer and you want to add a new collaborator to your repo we want to make sure that we allow you to do that because it's something that we don't want to be in the middle and stopping you in addition we want to develop a lot of dashboards that can help maintainers and stakeholders for example if you're a maintainer and you see that your score is 4.6 and then you see another maintainer and another project and their score is 8 you'll be like okay how do I get to 8 so these kind of things would be things that we want to do in the future some of the tools that we can help can help with some of that repo linty can actually help before you launch a project and let you know that you've got the right files in there security file all of those different things repo status is one that we can use to show status of an org if we find projects that need to be archived we can say this is active this is inactive this is archived we also want to look at more metrics from chaos want to look into Salsa because Salsa as a producer of an open source project you can go in there there's different levels from one to four increasingly more difficult to attest to but you want to go through that exercise to make sure that your project is hardened and also apply for the best practices badge so a lot of the concepts that I've talked about they are for GitHub but a lot of them will apply to the different source control management platforms multi-factor authentication for sure access permissions control you want to make sure that you enforce code reviews static code analysis monitoring your dependencies and making sure you act in a timely manner to that and also documenting how people will actually disclose vulnerabilities and what is the process and for some of the tools that we've used I know that for example scorecard might work for GitLab and GitHub but not for Bitbucket so if you're interested you can always join them and make things better if Bitbucket is your thing and Legitify also has GitLab and GitHub and just go ahead and check the platform support and see if that is yours is supported and what are some of the key takeaways a lot of this is upset over and over again it bears repeating but make sure you have access in code base is actually secure for an OSPO putting things under one enterprise account make things super easy audit your assets continuously and make sure that there's least privilege access is what you're using as a practice and maybe apply also these policies at an all level and you can go ahead after this and explore some of the talks and the resources check out scorecard, check out Legitify but also join the source control management guide especially if you use GitLab we need a lot more people with experience in there we meet every other Thursday at 10 a.m. Eastern and the next meeting is on May 18th and definitely this is what I want to see as far as when I'm thinking about our GitHub management workflow and I know that our shared learnings are something together we can do to kind of make our open source software all more secure so thank you so much and I hope you enjoy the talk I don't have time for questions I wasn't sure how long any questions yeah so the question I'll repeat it for those on live stream from being involved in the open access best practices group that number seven is this something that people are going to be looking at to make a decision to be involved or to use that project use the project I think it's almost like becoming almost like a de facto standard I know Rust Foundation some of the other folks like Alpha Omega is another project within OpenSSF and they're working with some of these ecosystems like Rust and Node.js and all and one of the things they do is they have them run through scorecards and it's almost like becoming like thing that people are looking at so I would say that it's probably gonna get there a lot of people are embedding scorecard and some of their tooling any other questions? All right, thank you so much