CodeSecDays 2024 - Join GitGuardian for a full-day exploration of cutting-edge DevSecOps solutions!

Save my spot!

CodeSecDays 2024 - Join GitGuardian for a full-day exploration of cutting-edge DevSecOps solutions!

Save my spot!

The iceberg: Your attack surface just got bigger, mitigating risk in your OSS projects) -CodeSecDays

Recent high-profile software supply chain attacks like SolarWinds, CodeCov, and Kaseya have increased in volume, frequency, and sophistication. Maintainers must take steps to secure their projects and ensure the integrity of their CI/CD pipeline. Sonya Moisset, Senior Security Advocate at Snyk, will explain how to set up guardrails and harden OSS projects.

Video Transcript

cool so uh well hi everyone welcome to my session the iceberg your Tech surface just got bigger so what are we going to talk today so there are a few things that we're going to talk about uh so first of all we're going to have a look at the cyber security uh challenges then we're gonna have a look at the iceberg and you might be like this little Emoji sing with yourself what is she talking about that I'll explain what's the the iceberg is then I'll explain how you could leverage the tools on the GitHub Marketplace to secure your pipeline and then I'll give some uh tips and best practices to harden your open source software products so first of all it's like a step back and let's define what is open source software so the term open source software was actually coined by Christine Patterson in 1998 and this was just Endeavor to make it more understandable to newcomers and to uh businesses and we know that open source software is source code that can that anyone can inspect modify and enhance and also we know that many people love using uh open source software for several reasons because we do love alsys the ecosystem but one thing to consider even if it's more secure than preparative software it does come with its own sets of security challenges are we going to have a look at a couple of open series software it's actually just to understand a little bit more what is going on so the first one is typos cutting attack so this one is when Bad actors push malicious packages to registry with the hope of tricking user into installing them this is the same as website phishing attacks that will exploit typos made by individuals who may accidentally typing a wrong address so here we have an example with the react package you can see in that case I will not install react this will install instead a malicious package that has a completely different end goal another attack is malicious packages this is to inject malicious code into a software product in order to compromise dependent systems further down the chain so here we have an example with fellow guys it might be filler with this game but usually the malicious actor will try to surf on Trends in that case a game that hasn't quite popular during the the pandemic so users might think that by downloading this package they will get an advantage in the game and personally this is a malicious package and it will attempt to read local sensitive files and accessorate information through a Discord web hook so that was the the entry points so this is known as supply chain attack and unfortunately it affects all ecosystems not only the npm ecosystem uh it's also called third-party attack and this occurs when someone infiltrates your system through an outside partner or provider with access to your systems and data so actually supply chain attacks are quite attractive to hackers because when commonly used software packages are compromised the attackers could potentially gain access to all the Enterprises they use the software so here we have an example of a classic workflow from coding to the consumer and you can see there's actually a lot of entry points that potentially attacks on here so at the coding phase there's the typos cutting that I've mentioned there's also another one called dependency confusion so this this kind of typically a typical attacks from that entry points but also we can see that the build the storage on consumers there's a few events that you might have probably heard of for example kodkov so kotkov happen in 2021 could curve is a software company that provides a code coverage and what happened is actually they had their bash upload of scripts temporary so the the attacker was able to upload um their their their bash their Scripts now this allowed them to steal credentials access sensitive data carry out Theory attacks so it's always the same pattern I'd say um because this temporary weight supply chain attack it makes it a simple entry and actually the the impact is quite it's quite big for example uh solo wins in terms of um of organizations actually it targeted 18 000 organizations that were using the solarwind and more specifically the Orion platform this is uh the one that happens uh tempered width so let's try to understand how this is possible and let's say hi to the iceberg let's all say hi I don't see like wavy hands and the Emojis on the chats uh if you're still confused by that statement uh let me explain it to you so the iceberg is usually used for uh as a good analogy or myth for to understand the different layers of our code base so if we start with our codes where we potentially can have security vulnerabilities that's our Preparatory code the code that we write within the organization so that's the uh the first layer and that's actually one layer that could also produce security vulnerabilities the second one below is the open source code because if we think about how many lines of code we write ourselves versus the number of packages we import to cut down the time we spend coding we don't want to prevent the wheel and that's only understandable because we know that the future already exists uh in the ecosystem as a package that we were using but unfortunately it's bringing new vulnerabilities and expanding the attack surface because of the complexity as well let's go down one more uh there the containers we know that the application needs to be deployed somewhere we can use containers static websites to deploy our projects we can use different ways to do so Docker reversal netlify all the cloud providers um if we're using Docker we're adding a Docker file now in the equation which has metadata about your your projects and again it's adding adding additional layer and increasing the attack surface and the complexity of your project and the last layer is infrastructure as codes so infrastructure as code is used to make your code as your single source of Truth where you specify explicitly through code all the infrastructure specifications that you have in your config file you can have Version Control you can test you can monitor IC is amazing but again it might also bring security vulnerabilities so now we have a better understanding of the different layers that we have within our applications so fun fact the application kits only represent 10 to 20 of our code base and the rest open source libraries containers in the ISC actually represents 80 to 90 of our code base and all of these layers can bring potentially security vulnerabilities at different layers and since important you have guardrails at each stages of your pipeline to support vulnerabilities as your attack surface is getting bigger and you can start from the cutting stage up to the production and depending on your workflow you can actually add those guardrails at each stages so depending on if you're on coding you can add the plugin within your ID to flag those vulnerabilities in your repo you can actually erase automated pull requests on GitHub there's there's a few ways to to do so and talking about GitHub I would like to talk a little bit more about the GitHub Marketplace so who here knows about the GitHub Marketplace a little bit of emojis just um me to check cool there's a few great so for those of you who don't know the GitHub Marketplace was first introduced in 2016 at the GitHub universe and it's a place where developers can find Integrations and Implement them into their workflow which is great and you can see it covers actually all of the stages uh CI CD could review security compliance dependency management it's amazing so first of all let's take another step back and what do we need to consider before adding those applications and actions so at first when you're a team of maintainers contributors um on the the open source ecosystem you need to look at if you want to implement an application or an action within your your projects you can have a look at different information on the on the page and we'll go through uh through this uh in a second also if GitHub has verified this this action or this application and also what is important for your project is to know what is the programming languages that you're using uh also what is your workflow and how many tools do you want to implement at each of these of these steps so if you're having some sort of devops pipeline you can have one tool for a good review for good quality for the advances and you can have also tools for uh screen to cover those but most importantly experiments and get the right tools for your projects also the thing with this this tools for open source projects and for public repos there are free usually which is good so that's why experiments so let's see and uh create this Baseline pipeline for um if you're a contributor a maintainer of an open source project you can actually leverage security tools from GitHub the GitHub Marketplace to create a basic Pipeline and Implement those guardrails so we're going to have a look at the basic pipeline which will include three things so software composition analysis and that will Define each of these terms so without uh the obvious career authors uh we'll see a tool to prevent Secrets sprawling and we'll see a tool to cover static code analysis so first of all the software composition analysis so definition that focuses on identifying the open source and the code base to so teams can manage their exposure to security and license compliance issues and considers a few vendors uh that actually um I mean in that space to cover that needs and usually when you go on the the get the marketplace you can actually navigate through the uh the page you have a little bit more info but the most important is actually on the left side you can see the supported languages and just to make sure that actually covers the the ecosystem and the languages they're using within your uh your projects so here you can see with uh with renovate they usually have the same kind of pattern they will um those tools will usually raise pull requests to let you know which version you can uh update to they'll also give you information if there's any breaking changes so at the end of the day it's yourself you actually uh will make the decision to merge that that change or not depending on the the workflow and the test Suites that you might have within your open source projects another tool is a sneak again have a look at the supported languages and make sure that it's actually covering the languages and packages that you're using within your your code base and again the tool will raise a pull request to let you know a little bit more to give you that that context also um you can get actually uh email and digest so you can have a weekly daily monthly so depending on the settings uh just to let you know if there's any new vulnerabilities within your uh the packages and libraries that you're using within your your code base so that was for the software composition analysis so we have this cover let's move on to Secrets prolink actually that's that's very well we have a definition from git Garden so what is secret sprawling so Secrets Pro is the invented distribution of Secrets like API Keys credentials through multiple system so uh and actually with this was uh it's a good thing if you attended uh McKenzie presentation before because he actually did a great a great demo uh live but I will have a look at kindergarten you might be also using different other tools uh operand Source tools but this is great um so again you can have a look at the the page just to make sure that uh this tool will fit your needs and your code base and then when you install it I would recommend for uh get Garden also specifically if you're having a lot of uh a lot of different uh repos to make sure that you actually scan all of these repos because we're talking about credentials uh API keys are really sensitive info we don't want to have them compromise so it's good to have that visibility so make sure to actually scan it all of your repos to have that historical uh data so once you've done that so for this uh this presentation I've been using the OSG shop um so um for this one it's it's actually vulnerable and you can see there's a few keys that have been flanked so this is giving you that visibility which is great and then you can act on on those because remediation is actually what we want from these tools as well also a good thing to keep in mind is that is usually these tools have a lot of Integrations um so depending where you're actually hosting your code should it be GitHub or gitlab um the different steps that you have within your CI CD pipeline so also if you're using Circle CI Jenkins and others most importantly for git Garden what you want is to actually flag those credits as soon as possible so within your CLI so I would strongly recommend you to to use a pre-commits pre-push to actually make sure that you capture those Secrets before being pushed to your repo so we've seen Secrets Pro let's see the last one study code analysis first of all definition what is it so it's a method of debugging by examining source code before a program is run it's done by analyzing a set of code against a set of coding rules few examples uh you might know Sono Cloud so you can use it through the website you can use it also through the GitHub actions if you actually have those set up within your workflow and your projects so once you've uploaded your project this will give you again the historical scan to let you know if there's any security vulnerabilities also this tool will give you if there's any could smell duplication but we're more interested in the security bits and this is usually what you have from these tools it's giving you it's plugging you the snippet of code which is vulnerable it's giving you example a steeple of code to actually fix and roommate and there's also a little bit of Education piece for for some tools just to give you a little bit more context on that security vulnerability and if you're a fan of metrics and insights they usually have a heat map on those you can see if there's metrics if your code is actually completely covered if there's any gaps another good tool is codeql from GitHub this one is natively implemented through GitHub actions and if you don't know where to start you can actually install it through GitHub action so if you're on the repo you click on GitHub actions you can set up this workflow by clicking this little button and it will actually populate your yaml file which is great the only thing that you need to check if it's um actually capturing the correct programming language so in my case again I'm using the OSG shop demo when it's using both JavaScript and python I know it's quite small but actually at the bottom is um the um the language is covering JavaScript python I'm good with this I'm committing that one and it will actually trigger the the workflow and let me know give me that visibility and apparently there's a lot of vulnerabilities which is expected from this vulnerable project cool so I've given you a few steps from uh the the pipeline so you might be asking this is great Sonia you're actually adding a lot of tools in the pipeline but how do we have visibility that's actually a really good question so how does it work on GitHub so actually when a contributor a maintenance will raise a pull request it will trigger all the application and actions that you have implemented within your pipeline so if you scroll down your uh your PR you will actually start seeing all of these little widgets are popping up and letting you know about the status of your uh of your Delta the the code that if you've pushed and if you go to the bottom of your of your PR you actually see all of the checks so that's an ideal State because everything is green usually you will see one or two Reds um but this is actually giving you that visibility and making sure that um your your code is vulnerability before pushing to to production also one thing to each uh to implement I would recommend for uh open source maintainers and contributors is to get um value from chat Ops so for those of you who are not familiar with chat helps so chat Ops is a collaboration model that connects people tools and processes and automation into your transparent workflow so for example if you're using a free slack account where you can have the team of contributors And maintenors discussing you'll have dedicated channels for specific tools that will give you that visibility and what is going on in your project so having said monitoring and setting alerts is a vital piece and we do this where developers can help where when they get the right type of information so if you're asking yourself what it does look like it looks like this so with a free uh like account you won't have the categories but you can still actually create dedicated uh channels to them just to um Circle back on the the feedback so from the your cicd pipeline from security tools from all the web hooks that it can actually set up and this is one example with GitHub you can see actually when you push the pull request you'll erase it'll actually send the web hook to your slack channels and let you know in real time you can see the different colors and you'll see if there's any issues that can actually fix any documentation on GitHub yes you don't need to actually use if you don't have the the budgets ticketing systems you can actually use the GitHub platform with their boards and you can also mimic uh the if you're used to a jira and there's a source of platforms so when working on analysis project you can Leverage The GitHub projects to um to list all of the tests that you have to work on for a specific feature so you can create labels so you can see on the left side and epics it's actually called Milestone on GitHub just to track projects or for raising issues and you can create a security label for example to track vulnerabilities into your project so for example we have the home page uh epic or Milestone so you can see there's like different tasks within it the only thing that you need to do is to be disciplined when you raise the pr you can see on the right side you need to apply the labels you need to apply the project and you need to link it to the Milestones well the project just to make sure that it actually fits back to that progression bar that you have at the top you can see a 61 complete just to make sure that everything is linked properly and also the cool thing is you can use automated projects or boards because the cars would actually move accordingly to the status of the pull request so if you merged the car that would actually um well merge the pr the car will automatically move onto the board which is amazing you don't need actually to touch anything you'll see cars flying over on the the board cool so we've seen a basic pipeline um and now I wanted to give you a few options for software best practices because adding security guardrails at each stages of your pipeline is great but you can also Harden your open source project by applying the following best practices the first one is apply the least privileged principle so this is to set the base permissions to new permissions on the member privilege section so they can only clone and pull the public repo and to give more um to give more addition to give additional access sorry the material will need to add them to teams or make them collabores on individual repositories so create teams add users to this team and allocate them to specific repos with specific permissions and then you have that granularity actually and you have that least privileged principle and you avoid cases where you get a compromised GitHub maintainers where there's an interesting case actually with the event stream uh example where one of the um the malicious actor went through all of the issues I was looking if he could actually push potential potentially a feature he actually builds up the trust with the material he was pushing some cosmetic changes so CSS changes readme changes and then when he got more permissions well be trust a little bit more he actually managed to push it was targeting a Bitcoin while it's um in that case so make sure to have the granularity and apply the less privileged principle when you're working on um on open source projects make sure you Fame mandatory for all maintainers and contributors if you don't do so actually by the end of 2023 GitHub will require all users who contribute code to enable one or more forms of two-factor authentication so this will be by default they will actually uh set it up protect your main branch so just to make sure to protect your main branch to avoid any accidental deletion by maintainer buying contributor by a malicious actor so that's one thing the other thing is if you click on the little edit button you'll actually have a few options and one of them is to have all of these little tools that you've actually spent time adding to your workflow to make them required and you can see on the right side the little required label so when you actually raise the pr those required tools have to be um green actually before merging the um the the pull request so they will depend this will depend on the threshold that you've set so you need to sit down with your team and have those discussions uh if you want to if you actually have the maturity live only the in the team and you want to apply those thresholds uh to your um and I have a specific production level enable notification errors this is to make sure that um you actually you're being alerted if there's anything that goes wrong and make sure to update the email address to make sure that you're receiving notification for your for your projects so also one settings that you might also forget about one thing is to review also the web hooks so if you're on those uh that security hygiene exercise because I've mentioned that these tools are free for open source and public repos so it's important to have that that exercise where you review your web Hooks and if you don't use them delete them because you never know if one of them get compromised that could potentially compromise your your projects and this goes back to the supply chain attacks so just to make sure that you have that that exercise and to review all of the web Hooks and applications that you've added to your to your projects check and add licenses um well an open source software license protect contributors and users so make sure that you have the correct license to use this is a good starting point here so if you're not sure about the license the GitHub is giving you a link to um more information on the the license and also if you if you don't want to start from scratch actually you can add the license to your project here so on this screen you can see MIT license which is already populated it's giving you the permissions limitation and condition at the top so you can review it with your team if this is something applicable for your project the only thing that you need to do and this is great is just to add the year and the full name in that case for that specific license you review it your submitted and here you go you have a license in your on your projects finally um you can use automated projects uh well you can use sorry you can showcase your uh your open source project status so this one is interesting um so because you're let's say let's assume that you're a maintainer or contributor and you want to showcase actually how your open source product is doing all of these little tools allow you to have those tags um and usually people forget to add those tags at the at the top of your project and this is not to actually just brag about your project it's more about um attracting new maintainers and new contributors because you want to actually showcase that your officers project is healthy uh it's also covered and it's using different tools should it be in your devops pipeline on the security sites so just to make sure that you have those it's always a good a good idea to implement through your readme file so it's usually markdown that you can add annual links so you can find it for those tools on the setting page um usually they'll have an options to to copy paste and edit on the yeah your readme file so yeah I would strongly recommend to have that at the top of your readme file just to give that visibility for other maintainers so if you takeaways uh before I close this talk so open source can be a factor for large-scale cyber attacks unfortunately and we've seen it a couple of years ago with the the vulnerability in Apache log4j the open source Java package used to support the activity logging in many Java applications so this was greatly um in December 2021 it was like big impact on the on the industry uh it was quite a nightmare but yeah the open source uh software can also be a vector for large-scale and cyber attacks so make sure if you're using OSS to leverage the application which are available on GitHub Marketplace and free for open source projects and your public repos and also if you don't work uh for an open source product but you're working on a pet projects or if you're prepping for an interview you can actually showcase this uh these tools just to um show that you know how to set up a devops pipeline and to secure your pipe language is good also to Showcase so having visibility through your pipeline using different tools and guardrails is critical to reduce your attack surface and you've seen it with the iceberg so it could be quite quite big and we've seen that leveraging the application in actions from the GitHub Marketplace could help and as maintenance contributors do not hesitate to create a small pipeline to Start experiment with the tools if they don't suit your project you you can still remove them make sure to remove and have that cleaning exercise for your web Hooks and applications and don't forget to harden your GitHub projects for everyone that are contributing to to it so experiments but most importantly I would say do not push your keys on GitHub please so um before I close I've actually wrote a handbook on this topic uh I'll I can actually share it on the uh on the chat link just shirts so I don't know if you can actually scan okay so uh yeah this covers and more in depth because I only have 25 30 minutes on this one because more in depth on the on the topic and there's a little bit more tips around uh OSS Security and how to make also an impact as a contributor if you want to upscale on that sense um yeah just whoops and going back here it is here so I am Sony master I'm passionate about death Cyclops uh open sourcing Cloud security I'm a senior security Advocate uh at sneak I'm also a writer for a free crit Camp a GitHub star and doing other things that I'm not going to bother you with uh today but if you want to link um yeah you can link it up with me on LinkedIn at Sonia mosa and yeah I just wanted to say thank you and don't forget to stay safe in your journey to open source software contributions thank you