Software Supply Chain Risks and Controls - 2025

1. Introduction: Hello. Hello, everybody. Welcome to my new course, which is the supply chain security and Master Class. My name is Pamurg Law, and I'm going to be an instructor for the duration of this course, which is, of course, about software supply chain security. Now, the purpose of this course is very, very simple. I want to explain to you the fundamentals of software supply chain security, firm the fundamentals to the advanced level, and you're going to get a very comprehensive understanding of the software supply chain. What are its components, what are the stakeholders and the various types of risks and security issues that can compromise your software integrity and security. So you're going to understand all the risks that are there, and I'll give you the knowledge that you require to implement a proper supply chain security program. And very, very important. I said a security program. I didn't mean I did not say a security product because that is unfortunately a lot of times where people get confused. They think that software supply chain security is about implementing a software or getting certification, and that cannot be further from the truth. A software supply chain security is a complete like you can say, a niche within cybersecurity, which you need to understand it's different risks and how to mitigate them. We're going to look at a few case studies also within the industry, how they happened, and how you can use understand them to further protect yourself from becoming falling prey to the same issues that are there. Now, who am I? My name is Kamchal and I'm a multi award winning cybersecurity professional leader, I've written, Okay, I'll call myself a leader. I've been in an industry for around 21 plus years within cybersecurity. I've been a speaker, instructor. I'm also a career coach. I help people get into cybersecurity. I have a YouTube channel called the Cloud Security guy on which I talk about Cloud security and AI. I'm also a bestselling author and a course creator, like I've mentioned. So just to give you that assurance that I do know a little bit about what I'm talking about, these are a few of my books which are written on AI governance and cybersecurity. I have many courses on this platform. On that topic. I also have written books on Zero Trust and Comtea, cybersecurity certifications, a lot of other topics, also. I'm there on Substack. I have a free newsletter there. I'm also there on LinkedIn. Cloud like my YouTube channel is called the Cloud Security guy, and I'm there on Twitter, so feel free to reach out to me there. Always happy to hear from people who've taken my courses. Now, let's take a step forward, backward, sorry. Let's talk about the supply chain when we talk about the supply chain. Now you might not be aware, but supply chain are critical to our lives. And what is a supply chain? It is a network of individuals and companies who are involved in creating a product and delivering it to the customer, right? And when you purchase something, you know, like from the Internet or a product, and most people are not aware. Usually, it's a very long journey from the original idea to the moment of delivery. And there are a lot of, like, people involved from the warehouse to the company, to the transport until you get it, right? And there are many many what do you call stakeholders involved there. And what you don't realize is there are many, many opportunities, also for something to happen as the product moved along this path, the goods which are moving along, right? All of these are issues. Security issues are present at any point of the supply chain. And most people are not aware, but supply chain security has been part of our existence. For thousands and thousands of years, such as when spices were carried from east to west or when ships were moving goods between continents, right? Or when military troops are transporting food and weapons during wars, all of the situations, people are prepared for attacks and they defend their supplies. So the item could make it to the intended destination. And the same is same same applies for software also. So imagine building a car. Right? You wouldn't manufacture the parts from scratch, right? Instead, you'd get the various components, the tires, the engine, the electronics from various different suppliers in a factory, and then assemble it. And this is the same way. The same principle applies to software also. And this is where the software supply chain comes in. It refers to the sequence of processes involved in the development deployment and maintenance of software applications, basically everything that is needed to create a software from source code deployment to production, right? In today's environments, it is very, very rare for companies to create software completely from scratch. Instead, what they do is they rely on the range of building blocks, such as open source libraries, developer tools, cloud based deployments, you know. And each of these components is part of a long supply chain from IT infrastructure, source code, right? And the software supply chain, it refers to the sequence of processes that are involved in getting you this software. So this can be the source code, the third party libraries which are involved, the build and packaging systems, the distribution channels, the deployment infrastructures, all of them, they come about here. And so this is how it looks like from the various levels, right? Like, developers will rely on when they write the they will rely on numerous external components when developing software. This can be an open source library, a third party, API, or a cloud service. They use it within their environment, and then send it to a bit system, which creates like a software artifact and goes to a repository, and then it gets deployed. Don't worry if you're not familiar with these terms. We're going to dive deep into each of this, software, I'm just trying to make you understand that software usually is developed by multiple individuals that might be part of multiple different organizations. And over time, thousands of people may have contributed to a particular software. So you need to make sure that you understand. Where the security issues might come in, right? And this is where software supply chain security comes in. This is making sure the integrity, security, and reliability of the components and the processes that are involved in the development, distribution, and maintenance of software. You want to make sure that your software is not being tampered with compromise at any point of the life cycle. And the supply chain, it does not just we're not talking about just the code, but also the third party libraries, tools and services. It depends on the infrastructure. So software supply chain security encompasses everything. Software supply chain security is not a certification you get. It is not a product you buy. It encompasses all these processes. Okay? And why is it so important? Well, simply put, this can be a massive blind spot. Right? Most companies, what they do is they focus on securing their own environments, their own code, they do trainings, and they make sure that everything is secure. And they completely forgot about the third party libraries, the third party components that are there. And attackers are not stupid. They are also aware of this. Why would they want to attack head on when they know that the company is securing itself, when they can just sneak in through a third party component, through a third party library, through some other sort of like backdoor which the company is not aware of. And unfortunately, like I there is a lack of awareness and controls around this. Most companies think they'll buy a product and their supply chain is secure, or they'll make a checklist, check their vendor, and now we are secure or they'll invoice MFA. All of these things are important. By the way, I'm not saying those things are not important, but software supply chain security is much, much more than that. And there is a general lack of awareness, which is why I made this course here. And why should you should care? I mean, I cannot stress this enough when like a few years back, solar wins was compromised, right? It raised awareness about software supply chain security. And I'm going to talk in detail about solar wins but in summary, it began in October 2019 and remain undetected until December 2020. And by then, 18,000 customers had been placed at risk, okay? Microsoft confirming so many companies had been waged, including even US governments, right? And solar wins, they had to settle for, I believe, a $26,000,000 lawsuit with its investors due to all the financial losses that came about. And this did not include the millions spent by solar winds and its customers or incident response, threat investigations, downtime, remediations, the loss of revenue. So you can understand just how powerful this attack was and similarly, Log for J, if you're familiar, if you were anywhere in December 2021 in cybersecurity, I'm sure you know how many people's holidays got compromised because of this popular labrary, it got compromised, and it was present in millions and millions of environments, and all of them had to do a risk assessment to make sure they were not vulnerable. So the software supply chain security is no joke. It can lead to devastating cyber attacks if you're not securing it properly. So who is this course for? This is for, of course, cybersecurity professions who want to get a proper understanding I've used all my knowledge that I have on software supply chain security and put it in this course. It's also for developers who want to understand the wider context of the code, the security of it. This professionals, if you want to refine your risk knowledge and include Suffa supply chain risks also. And of course, security leaders like CIOs, CTOs, chief information security officers, anybody who is interested in understanding about software supply chain security, happy to have you on this course. And how to use this course, please, you have to understand and implement the strategies that I'm going to be outlining and gap your software supply chain against these practices. Do not just take this course and then forget about it. Please apply the knowledge which I'm talking about. Knowledge that you're not applied, you're going to forget about it, and then create a proper software supply chain security program. That's going to be your project for this course. I want you to lead, use the concepts that I teach you and apply it within your company and do a gap. That is what we're covering about. Now, software, we're about to start now. Remember, software is everywhere. Trillions of lines of source code are present everywhere, and a single software vulnerability can stop entire companies from doing business and cause billions of dollars of damage right. No more than ever, you need to understand software supply chain, security. So I hope this gives you a good understanding and it motivated you to really learn about this topic. Let's start. I hope you are as excited as I am, and I'll see you in the next lesson. Thank you very much. 2. Understanding Supply Chain: Hello, everybody. Welcome to this lesson in which we're going to understand the software supply chain. Before we get into securing it, you need to get an understanding of how the software supply chain works in today's world, and then we're going to jump into the risks part. Okay? So this is what you're be talking about in this lesson, which is the software supply chain, the key concepts that you need to keep in mind and the different types of environments that are there. And this is like a foundational course that is going to set the baseline for the whole course. So if you're not aware of what the software supply chain is, please make sure to take this lesson, and you won't believe the amount of security professionals I've seen that make this mistake. What they do is they jump into immediately the risk without first getting an understanding or an appreciation for what the software supply chain is, what are the different environments, and how they work. So we've talked about this definition before, very quick review. Software supply chain, like we talked about, the sequence of processes involved in the deployment, development, maintenance of software applications. Basically, everything that you need to build a software artifact from source code development to production deployment, that comes within the software supply chain. We talked earlier about how companies, it's very rare for them to create ein from scratch wide. They rely on building blocks such as open source libraries, developer tools, SAS services. All of them come together to make this software package, right? And in all of them, there's a potential of security risks happening. So how does a typical software development environment look like nowadays? A software environment, sorry. So this is how it looks like. We're going to go step by step how it takes. And before you jump onto me and start shouting that this is not how my environment is, I know each environment is different, but this is the most common like, these are the attributes that will be present in virtually every environment that is there. So first of all, let's start with the development environment. This is where the magic happens, right? Developers use this environment to write and test code. They create new features and experiment with ideas. It's like their workspace, right? Allowing them to write code and bring their visions to life. And the development environment usually is equipped with various tools and frameworks, which are not present on other business machines. So this is like a special environment. They usually have more privileges. So what do they do? They use their integrated development environment, their workstations, which has their coding software. To write code, which gets pushed to a code repo. A code repo can be it's like a shared server which contains the code. From there, the build platform, it takes its code and it builds into it into an artifact. Now, developers might be using dependencies in their code, or when it's being built, it might pull dependencies. Dependencies are, like I said, these building blocks, right? You're not going to write everything from scratch, right? If you're writing Python code, you'll be using various libraries. So all of these dependencies, the build platform will use to build its software, and this is how the development environment works. So I write code. It goes into a code repo, where the build environment, it it generates it compiles this code. It pulls any dependencies that are required. It might be within the environment, it might be a public report, which is stored on the Internet. But this is how typically development environment looks like. So after that, what comes, it comes the testing environment. So once the code is written, time to assess its robustness and functionality, right? The testing environment, it's like a controlled place where you perform various types of testing like unit testing, integration testing, system testing, quality assurance. You are meticulously evaluating this code, right? Against predefined test cases to find out if any issues are there. Now, this can be completely automated with a lot of environments. They have DevOps and DFsycovs. So you might have completely automated testings. Or you might have a person sitting there who's doing the testing, and you won't believe we still happen. You have lots of QA and testing teams who are running they are running those automated tests, but there's a person looking at it. So there are various ways of doing it. But usually you have a testing and a UAT environment where the code is tested to make sure it is free of bots. Okay? What happens after this? So after this, you have something called a pre prod or a staging environment. So this is like a gap between the testing and the production phases. This is usually a replica of the production environment. It allows teams to validate whether the software is behavior. It is working properly under real world conditions, right? Like I said, it's very close to the production environment. So it enables them to stress test it, and enables them to look at various how the software will actually work, you know? Because the UAT testing environment, it's like a test environment. It does not represent the actual world. So the preprod and the staging environment, this is this is very, very close to how the production environment will work like. And a lot of people they use preprod and staging interchangeably. There are subtle differences. But usually, across the board, they use pretty interchangeably, honestly speaking within what I have seen. And what are the benefits of using these environments? Like I said, load testing, performance testing, stress testing, which you cannot do in UAT environments, right? And they give you several advantages because they will tell you how the actual customer will look at the software, and he bugs errors with the performance, and you slow down before the software reaches the end customer. It allows you to fine tune the performance by identifying any bottle necks that might be there, and it gives you a good way to judge whether the user performance, the user satisfaction, how it'll be there because now you're getting a very good idea of how the customer will be looking at this software, and that is the benefit of adding the pre prod and the staging. And like I said, this is very, very close to the production environment, so you might have actual data here, actual production data being stored here. And lastly, is the production environment. So this is the ultimate destination for your software, it is a live environment where end users will interact with your application or system. The software is deployed here, and it must be meticulously tested and refined in the previous environments to make sure that the customers have a seamless experience. Now, I have never heard of any software which does not have bug in that production environment no matter how much testing you do. But following the steps, it gives you a very good idea, and it gives you a chance to remove any bugs that might be there. So this is how a typical software environment will look like. Like I said, before you go all crazy and accuse me of missing out critical areas. Like I said, I know every environment is different, but this is the closest that environments. Usually, these are the most common ways software development environments are structured. So I hope you got a good idea. Now we're going to go what we're going to do is we're going to take a look at a few concepts that are there, which are Dev SecOps, CICD pipelines, artifacts, artifact repos, package repositories and infrastructure as COD. You might be familiar with this, but I've deliberately put it here just to put as a refresher, because all of these areas they will come into play when we talked about the software supply chain security risks that are there. So I've put it this as a quid revision. If you feel that you are very good in all of these concepts, feel free to skip this lesson. But I would recommend taking it as a quick revision, so I'll see you in the next lesson. Thank you. 3. Supply Chain Risks - 1: Hello, everybody. Welcome. Welcome to the next lesson. And this is where we really start going into the meat of the course, which is now we're going to talk about the security risk, right? The software supply chain, security risk. So in the previous lesson, I talk to you about how software development environments are usually configured, right? A very I try to cover the most common software development environment and how it works, and what are the different concepts and how software moves through them. Now, what we're going to do in this lesson, we're going to talk about the security risks, which is the security risks in the sofa supply chain, how they happen, and we're going to do an analysis of actual incidents. Some of the most popular ones like solar events, Cord Cov. By the time I finished this course, probably some other supply chain attack might have happened. But I'm going to cover the ones which cover different scenarios. And which can show you the actual impact. So it's not just theoretical where I'm just telling you these things can happen. I'm going to show you actually how it happened and what were the impact and what you can do to actually protect yourself, right, prevent these things from happening. So if you remember, this is the diagram we looked at before, right? We had the developer environment with the ID, pushing code to the repo, the bull platform will kick in, pull in any dependencies and white, and it's going to push it to the testing environment, and then the prep to the production. This can be completely manual or this can be a CICD pipeline, white, pushing your code. From the different environments until it gets pushed to the production environment, and this is what we talked about. So let's now think about the risks at a high level. Now, let's start from the developer. Now, developers in most environments and what do you call developers, they usually have quite powerful privileges. They have the capability to maintain their own developer environments because they need that flexibility for creating new applications and products from my experience, they sometimes can spin up virtual machines like, you know, dual boat operating systems, Linux and Windows. And these environments, often they sometimes invisible to IT organizations. That's why they call them shadow IT, right? And developers believe they require this flexibility, right? They need the ability to spin up a virtual machine, install applications, manage their environments. They do not want their laptops or their desktops to be locked down, and they want administrative or power user access to their systems because if you stop this ability, they won't have the ability to troubleshoot to create environments, or they'll have to go through dozens of approvals for modifying environments. If you've ever worked in cybersecurity, I'm sure you must have seen this, right? So we start that's the first thing you need to think about the very powerful privileges that developers have and what that will lead to we'll see. Then of course, comes in secure code. And we're going to see what if the code they're writing is insecure? They will push it to a code repo and then it's going to get propagated throughout the environments, and that code has serious security flaws. And if you are a service provider, like solar winds, that insecure code will get propagated everywhere, right? Thousands and thousands of people because you did not check it yourself, right? And the code gets pushed to like what do you call a code repo, right? Now, the code repo, you can have multiple compromises here also, right? The source repository, the code repository, maybe the admin interface is not secure. And the attacker can use the admin interface or compromise the underlying server to directly attack the source code and get access to it, and they start modifying the code. Or they might put something malware there, which gets propagated everywhere. So think about the code repo which is there. Of course, you have the built platform, and they are tightly integrated with your artifact repos and your package repositories. And often what they do is they start building stuff and propagating it throughout your environments, right? So attacker can attack that build platform inputs, like what version to use and they can redirect it to some malicious code, which the build platform with the propagate. And we'll see this in the solar winds attack. So they can attack any part of the built platform, including its services or the underlying infrastructure, and they can alter how it's getting billed, right? And this can lead on. They can compromise the artifact repository like the package we talked about, and they can upload or publish altered artifacts because you didn't secure the admin interface. And lastly, the dependencies, if you look at the very top and this is one of the most common things. And unfortunately, people think this is just the only thing about software supply chain, but your dependencies, because you're using a variety of third party commercial and open source library is there, and that's how most environments are configured, right? And so what will happen is you'll have multiple What if an attacker compromises this library. They try to introduce malicious behavior by compromising this library, and this dependency is going to get propagated throughout your code. Your code, we have an insecure component, like we talked about Log for J, right? It'll get propagated to your environment, and later on, when a vulnerability is discovered, attacker can use this to piggyback into your environment. So this is just the developer environment, right? And then moving on to the other environments like the UAT testing environment, when you're doing the testing, sometimes companies don't even bother to do security testing. They have no idea whether the code is secure. Whether the COO is introducing any vulnerabilities or not, something independent. They just rely on the developer. You will not believe how common this still is, unfortunately. So that security testing is not there. A lot of companies I've seen, they do security testing, but nothing happens after that. So they do a security test, and they okay, they just published a report. These are the security vulnerabilities. Nobody's looking at those vulnerabilities, right? So the security test you don't do security testing just for the sake of security testing, right? You do security testing so that vulnerabilities are fixed. So this is another issue. The security testing is not there. Then, of course, you move on to the pre proud and the staging environments. And we talked about this is a replica of production. This is not as secure as production. It's a replica. So somebody might be able to compromise it and gain access to the data because you have customer data. Maybe you haven't masked it or anonymize it, so people will be able to get access to this data and compromise it. And lastly, of course, the production environment. The production environment, I've kept it out of scope of this course because, of course, that's traditional cybersecurity. You will have patching and all those other things. But that can also get compromised, right? Because I want you to think of it from the big picture perspective. These are all the attacks that can happen, right? And lastly, of course, if you look at the arrows which are connecting those environments, this one, the CICD pipeline if you're using, if you're using a CSED pipeline, we talked about how the continuous integration will quickly testing it push the code and do the testing, and then the continuous deployment or it'll push the code throughout the other environments, right? What if somebody is able to compromise the CICD pipeline? This pipeline has access to all the environments, right? So they can actually control what code is getting pushed, what sort of testings are happening. This is another thing you have to keep in mind. Is another very, very dangerous thing that can happen. So this is the big picture. These are the sort of attacks I want you to think about when you're thinking about the supply chain security, right? And is this my opinion? So you might be thinking, and this is just your subjective opinion. So no, I have based it on an industry benchmark. So this is Salsa. It's say they pronounce it salsa, which I like, but supply chain levels for software artifacts. This is an industry benchmark. I'll put the link in this course. So it's a security framework. It's like a checklist of best practices to prevent like your software supply chain security from being compromised, right? And it's usually used across the industry. It's a very, very good independent, it's technology agnostic, it's vendor agnostic. And it's like a set of guidelines. You can slowly slowly adopt them and they are established by industry consensus. And they are set up. So anybody who's building software, use them, right? Anybody who's producing, consuming or providing software such as build platforms or anything, this can be used to, like, get more trust within your software supply chain security. It's like industry cross collaboration. We're going to talk about this more later on. But it's like a completely vendor neutral, what do you call framework for securing your software a plan. It gives you a common vocabulary to talk about software supply chain security. And so this is what I built this diagram upon. So this is what we want to show. And this is an industry benchmark. So I'll put the link there. You can see, so it's not just me, you're thinking I'm just talking out of my own opinion. This is based on an industry benchmark which I talked about, and I definitely would recommend later on when we build a software supply chain security program to take a look at it, okay? So now we're going to talk about the key security risk. I'm not going to talk about it in this lesson, because I've already given you a few things to talk about. We'll continue on in the next lesson. But we're going to talk about the key security risk. All the risk we talked about in the diagram, we're going to actually dive deep into each of them and think about how this works and what are the implications of these attacks happening. Understanding these, it's quite critical because otherwise you can't secure something if you don't understand how it happens, right? So now we're going to dive deep into each of these risks, and I'm going to show you the impact of these things happening. Okay, thank you very much. I'll see you in the next lesson. 4. Supply Chain Risks - 2: Hello, everybody. Welcome to this lesson. And now we're going to talk about the key security risks which we talked about in the diagram. And we're going to walk one by one, so you get a better idea of these security risks. And later on, when we start securing them, you're going to have a much better idea. And we're going to see some case studies also about solar winds and Kokov how these risks can actually happen and really compromise. I'm going to go step by step to give you a better appreciation of these attacks. So let's start with the number one which is insecure code. Now, insecure code is not I mean, honestly speaking, this is something which has been in the industry for decades now, and there's a lot of good awareness now. I mean, compared to the other attacks, I would say insecure code is not that serious. Most companies, I know they have started putting in measures, but this is the starting point. Of all software supply chain security risk Honestly, like I said, the root of all evil, whether it's first party or third party, you have to make sure that your code is secure. And the mistake I see a lot of companies making, they secure their first party code, which is their own code, but they don't look at third parties, and you have to treat all code equal. You have to make sure that you have that assurance that that code has been secured. And you might ask, how can I secure third party code? I don't have access to it? Well, there are ways of going about it. You can ask the vendor. You can assess the vendor risk management processes, right? So there are ways of checking it, and we're going to look at it in more detail. Where we talk about creating the vendors security risk management program. But insecure code is pretty much if you're not securing your code, all the other controls will not matter because this is where most of your security risks will lie. So these are just examples. I used to look at them, and if you know a little bit of coding, it's something like an injection attack where you're not sanitizing the code, you're just accepting code into your environment, and pretty much anybody can just bypass this code to access your underlying databases, your underlying operating system. It's called an injection attack. And you won't believe even in 2024, I see people still making this mistake. So it's incredible. I was looking at programming in 2002. So it's almost 22 years now, and still this issue is still there, which I found very funny that still this mistake is there despite all the advances that we've made. This is something else. This is like a ZIP bomb attack in case you're unfamiliar with this, this is like an archive which you're not validating a ZIP file or an archive file, you're just extracting it without doing any validation. So you can actually cause a denial of service the attacker. You can exhaust the dispace or memory of the target system when you try to extract it, right? And honestly, the ZIP format is the most commonly used, but you can pretty much use it. It's like compressing a large file consisting of a single character, right? And you can create a one MB file that will decompress to one GV. And it will actually it'll mess up the operating system because you're not doing any validation. So these are another attack, which is because of your insecure code. And this is, I mean, anybody knows this. This is the oldest and the most common thing, which is hard coded secrets. Like people are lazy. They don't want to do secure validation and nobody is looking at the code. So they actually put in the hard coded secrets, and this gets pushed to a public code repository. Like assuming you're using a public code reaper, somebody accesses it and boom, he has access to your environment because you put in the user ID and password within a code reaper. So many companies I know, are they have very strict password policies, but they do not look at the code. Which is there, and so they are not even scanning their code. So this can actually lead to hard coded user IDs, passwords, hard coded access keys being put in a code and being pushed to the code report. Anybody who has access to that code can actually now bypass and compromise your environment. So this is just to show you just how dangerous these attacks are. So this was like insecure code. Let's move on to the next one, which is insecure third party components. And this is where the most focus comes on when people talk about supply chain security, basically vulnerable or malicious third party dependencies. You know, we talked about this earlier that modern software they rely on third party libraries or adios. And if these dependencies they are containing vulnerabilities or maybe malicious code, they can introduce risk into your entire environment, right? And third party software, think of third party software is just first party software which is written by someone else. So just like the Cloud is just server that is run by somebody else. Third party software dependencies, you can think of it. These are your dependencies, but written by somebody else. All the risks that we talked about encoding, they get carried over here also. And these vulnerabilities can come into your environment. If the attacker is able to compromise it. That dependency, this dependency will now be used to compromise your environment, right? And these can be known vulnerabilities. So it's not like it's hidden because this vulnerability has been known for quite a long time, but you're not able to fix it because it'll break your application or because the vendor has not released a fix. So you have to think about it. Okay, what do I do now? Or, this can be zero days, like the initial Lock for J. You remember Log for J, right? This can be zero days. Nobody knew about it. Suddenly, it comes in, and there is no fix for it. And quickly, attackers can start manipulating it, start trying to compromise environments with it. And th this is like immediate vulnerabilities can be there that lie dormant in a code base for months, years, even decades. And when they're finally uncovered and announced people around the world, they are scrambling. Like to find if they're using this software or not, right, to figure out if they use this dependency and how to protect themselves from being exploited. Attackers are also scrambling. By the way, they're trying to determine who's using this vulnerable software, and they're trying to craft exploits to take advantage and compromise environment. So it's like it's like a mad dash for people to find out, right? And this is how it usually looks like. So you have an attacker, they compromise this environment. They compromise a third party labrary and this third party labrarys getting across the board. It's being propagated to thousands and thousands of companies, right, like Lock for and take the example of solar wins. Somebody compromised the solar winds environment, and that code we then used to push across the environment. So this is another example of how that happened. And this is usually how insecure third party components work, right? You have to think about it from this perspective. So these were the first level coding and the third party dependencies. I'm going to break this lesson down into multiple parts because I want you to absorb what we've talked about before I jump into the next one. In the next one, I'm going to talk about compromising the code repose where you're storing the code. Remember when the developer used to push code, it would go to a code repo. So let's talk about the code repo and what can happen. Thank you, and I'll see you in the next lesson. 5. Supply Chain Risks - 3: Hello, everybody. Welcome. Welcome to this lesson. And now we're going to talk about the code repo compromise. So as you can see, if you remember the diagram, we are slowly slowly moving across the software supply chain. And we've talked about code repos before. Basic, think of it as a centralized library or a centralized repository where your developers can collaborate on code, right? So I write some code and I push it to a code report. Another developer is also writing code. They are pushing to the same report. And the code, you've heard of Github wide. So it makes sure that all the code is synchronized. And what can happen, attackers can gain access to this repo, right? Maybe the software is not secured, or maybe they compromise the user they sent him a malicious link, and he was like he put in his user ID and password, and they were able to get it. Now they can manipulate the source code at the foundation. Or even a lot of people are not aware. The repo itself can be used to serve attacks to customers. And sometimes people are not aware of this. So there is the security of the repo itself, making sure that the repo is not compromised, and the repo itself can be used as an attack vector. And let's take an example. So just in case you're not aware of this, I think this happened in in 2020, the octopus scanner malware. So they actually attackers. What they did was they had like a set of Github hosted repositories, and they were unintentionally, the keyword here. Unintentionally, they were being used to serve malware. And actually, the Github security team, they researched it, and they found out that what had happened was these repos had not been secured and they were being used to serve malware across the board, right? And the owners of the repos, they were completely unaware. They were committing like malicious code into the repositories. When they're doing that pulling the code, they were actually pulling malware, and they provide a high level, what do you call? What it does well, basically, it compromised the repo itself. And you can imagine how dangerous this is, right? Because why? Because the malware is being pulled into the developer workstation. And from there, it's getting pulled into the build, and now you're giving that malware an ability to move across your environment. And since the primary people who are getting compromised are developers, and if you remember what we talked about, developers, traditionally have more access than normal people, right? They have elevated privileges, power user. So this will allow them potentially to gain access to production environments. You could potentially get access to database, passwords, other critical assets, right? There is a huge potential for escalation of access for the attacker doing a privilege escalation, which is a core objective of most data compromise. When the attacker gets into an environment, the first thing he wants to do is become the administrator, right? And this is just to show you what can happen. People think that, Oh, the code depot might become public. That's the worst thing that can happen. No, if you've not secured your code repo, the code report itself can get compromised and being used to serve malware. And we're going to talk about all the security controls later on. First, I want you to understand the risks. And this is very much linked to the developer environment. We talked about this before, right? That a developer they need access because they want the ability to be able to they want sandboxes. They want the ability to spin a virtual machines, install applications, at least elevated access. They don't want that corporate PC on which they cannot do anything because they need the ability to run code. So they have power tools, they have IDs with plugins. Those plugins can be compromised, right? So all of those things you have to think about. And, of course, preprodEenvironments. The pre prod environment, it will have customer data. So if a malware is there, it compromises the developer machine, and slowly it gets pushed towards the environment, the attacker will be able to reach until he reaches an environment the malware is able to tell him, Look, I have access to customer data now. You will be able to exfiltrate that data. So this is how you can see how multiple things come together, the developer PC not being secure, the source sweep are being compromised, your preproduct environment containing completely open production data. All of these come together to really compromise your environment. So this was more from the developer perspective. Now let's talk about attacks during the build phase. We talked about a build server before, right? It's a critical part of CICD because basically they automate the process of compiling code, running tests, preparing applications for deployment. It's like the build server is doing everything, right? And attacks during the build phase are quite dangerous because if attacker is able to gain unauthorized access or control over the build server, and they can really cause havoc within your environment. Why? Because built platforms are typically integrated with your artifact repos, where your code is, or your package repos why? And they can modify your build. So they can actually attack these bill platforms. They have lots of parameters, right? So they can actually change it. They can use it to direct to somewhere that is compromised. Or they can actually use the bill platform itself to push their own malicious code, like the one which happened with solar winds, which we talk about shortly. Or they can actually use it to compromise the artifacts, right? So the built platform is a very, very critical part of your environment. And one of the best examples of what happens is solar wins. After this lesson, we're going to look at a few lessons later, we're going to do the case study of what happens when a built platform is compromised. The sheer impact of the best example of that is solar wins. The other one very much linked to this is the compromise of the CICD pipeline. We talked about the CICD pipeline. Why? That automatically pushes code, deploys it, tests it. And these pipelines are very, very attractive targets for attackers. Why? Because they offer a direct path to the software production environment and user system and data. So I mean, how can it be compromised? There are multiple ways. You might have insecure credentials. Maybe you have not configured the access controls properly. You might have vulnerable tools that get compromised, right? And remember, CSCDPipeline is the automated processes which are using for integrating, testing, and deploying code. And these can lead to severe security breaches. And this can lead to actually other customers also getting compromise, which we're going to talk about in a case study called Cod COV. I'm going to show you what happens. Actually, if the CICD pipeline gets compromised, the impact of that. So these are the two ones. So one is the build server, we're going to do a case study and this one. We're going to do a Kas study. I'm going to show you shortly what happens when either the build server or the CICD pipeline gets compromised. But right now, I want you to think about the impact of that which can happen. So this covers this particular section. Now we're going to talk about the package depot, but like I said, I don't want or, like, overwhelm you with too much information. In the next lesson, we're going to talk about the package wept and specific attacks that can target it and some unique attacks like dependency, confusion attacks. How they happen, and what are the impact of those attacks. So thank you very much, and I'll see you in the next. 6. Supply Chain Risks - 4: Hello, everybody. Welcome. Welcome to this lesson. And now we're going to be focusing on the package repose. If you remember your software that's bundled into a package, right? All the code and everything it gets dependencies, it gets bundled into a package, which you can deploy to the customer environments, to your production environments. Now, package repo is where these packages being kept, and the package report itself can get compromised. So maybe you've not secured the package repo, right? We've given it open access. So you've misconfigured it. Maybe you've connected to the Internet, maybe you've allowed anonymous access. You're using default passwords and granting upload privileges to users that can be abuse. And what can happen is an attacker can gain access to this package repo and poison it. So the package repo is breached or manipulated by malicious actors like widen. So this can affect the integrity and security of the entire supply chain, right, the software supply chain, because they can push malicious packages, right? Remember, this is a centralized place where software packages are being stored. So what can happen? People can push malware. So malware injection, malicious code can be added to packages in the repository. So when people are downloading it and integrating these compromised packages, the malware becomes part of the application or uh the credential theft, right? Maybe attackers can steal credentials from packages and then use it to push other unauthorized code within the pipeline. You can even have replace legitimate packages. So you have a package name. You can replace that with your own malicious package, and downstream, it will get pushed to thousands and thousands of people. And lastly, dependency confusion attacks. This is a special type of attack where what attackers do is they publish packages, which names which are similar to internal private packages used by company. And if the public package, it has a higher version number, the package managers might fetch this instead of the internal one, and I'll show you how that happens. It's a very unique attack, but an extremely, extremely dangerous one. But this is just what I wanted to show you. And this is not a joke. I mean, the package repo, just to give you an example. This was a packages repo that got compromised last year. Attacker was able to gain access, I think to four inactive accounts, and they hijacked over a dozen packages with over 500 million installs, right? And basically they replaced I think the package description with their own message, and that was allowed to compromise, basically, modify the packages, and it got pushed more and more. So developers downloading the packages, they would get the malicious package. And just to show you how dangerous this is, people if you're not using something like multifactor authentication, if you're just opening up your using shared passwords, and this is how that happened. And, you know, this just goes to show you how dangerous it is that pers, which are completely open, which do not have access control, you could actually get malware. People think about Malware. They think about something coming into the Internet or through email, right? They do not realize that your software supply chain, which is your package pers, your built platforms that can also be used to push malicious code into your environment and into your customer's environment, which can cause a massive reputational issue to your company. So remember all these things, please. And now, so what I wanted to talked about earlier, dependency confusion, if you remember. So these are like a special type of attack. These exploit how package managers are downloading and installing packages. So what an attacker does is it publishes a malicious package to a public package repo with the same name as a popular package, which is being used internally. And what happens is when you request this package, if you're not configured your package repo, what it's going to do is going to go to the Internet first and check if a higher version number is there. So assuming you're using Version one in your private repo, the attacker is going to put the same name and it's going to put version two. So the package repo, if you've not configured it properly, it's going to download this malicious package. So that's why it's called the dependency confusion, right? We are exploiting the way these things work. Remember, we have public repos and private repos, right? Sorry. So private repos are one which are hosted internally, but you might have public like node packet manager and all that, right? So the public ones, attackers can push they can quickly find out what are the common and most popular packages, and they can quickly push lots and lots of packages, malicious packages with the same name. And this is very, very dangerous because if you've not configured it properly, attackers can create a malicious package with the same name as a legitimate package and upload it to these popular package repos. So when a developer is asking for a legitimate dependency, the package manager is going to go is going to fetch this malicious package. And this is a great way to push Malware. So this is how it's going to look like, right? You have a public package repo. The attacker goes there. He says, Okay, these are the most common packages. I'm going to push my own one with the same name, but I'm going to put a higher version number than the current one. Version three, version four, version five, right? And what happens? So the developer goes there. He says, I want XYZ package to the private registry. They've not configured this private registry to only use the private ones. So by default, the behavior is going to go to the public repo first. It's going to say and it's going to fetch the wrong package. It's not going to fetch the internal one. It's going to say, Hey, I have version one on the Internet, there's version two. So it's going to give what do you call the latest one. But this one was malicious. This was one pushed by the attacker. So if it's successful, a dependency confusion and attack can have seriously messed up consequences. It can infect all the customers that install the malicious package, and they can then be targeted because they've been compromised by malware or ransomware, and they can be mitigated by making sure that developers review and verify their packages and keep their dependencies up to date but with private ones, right? So it's a very unique type of attack which a lot of people are not familiar with. And this is quite dangerous in the way it works. So that wraps up this particular what do you call area of supply chain security risk. In the next lesson, I'm going to talk about a case study. Remember we talked about the build platform being compromised and the CICD pipeline. We're going to talk about the solar veins and the code CV ones. So but in this lesson, which was quite long, we talked about the types of software, supply chain risks, the different entry points of attacks, and the impact that can happen. So with the impact, I'm going to give you more context by actually looking at actual attacks that have happened and the like the very dangerous consequences that happened because of these attacks. So thank you very much. Take time to, like, go through this lesson again if you need to. So that you have a good foundation, and I'll see you in the next lesson. Thank you. 7. SolarWinds: Hello, everybody. Welcome. Welcome to this lesson, which is about understanding the solo winds attack. I'm sure you must have heard about the solar winds supply chain attack. It is one of the most devastating attacks that have ever happened, at least within 21 years of myself working in cybersecurity, the impact and the amount of companies that got compromised. Solar wins is easily one of the biggest cyber attacks that has ever happened. It's very possible that you are taking this course of mine, mainly because of the solar wind cyber attack, I'll be honest, yeah. So that's the reason I wanted to talk about solar winds. You cannot talk about supply chain security without talking about the solar wind cyber attack and case studies, and, you know, really taking a step back and looking at a few of these issues will really help to contextualize the supply chain security risks I was talking about, because then you can take a look at it from the perspective of an actual incident which has happened and just to get a better idea of how dangerous these things are, right? So let's move ahead. So when we talk about solar wins, it is, like I said, one of the most devastating supply chain attacks of all time. It's like recognized, you know, all the big cybersecurity incidents, and it really shows the vulnerabilities that are there within the sofa supply chain and the consequences like the impact. Solar wins had a global impact. It's spread across governments, organizations worldwide, simply because of how common the solar wind software is, right? And it really so many CSOs, thousands and thousands of companies, they re evaluated their supply chain security and their trust in third party vendors across industries. And solar wins, if you're not familiar, it's a widely used network management software company, and that was targeted in the highly sophisticated supply chain attack. Basically, attackers were able to infiltrate the solar wind software development and the distribution process, and they were able to insert malicious code into its software updates. So it was not just a direct attack on solar wins, but an indirect attack on the thousands and thousands of companies. Which they trust. So the malicious update, it was disguised as a legitimate software update to solar wins, and it was distributed to thousands of solar wins customers, and it sneakily gained their way into the networks of so many solar win customers, right? And it's really a reminder of how important it is to secure the software supply chain and how you really need to keep evaluating, keep doing this risk assessments. So this is what it looked right. Like I told you, solar wins offers like ID performance management and monitoring system called Orion, and it's used by customers worldwide. And Orion usually has access to customers system performance logs and data. And that's why probably why the attackers targeted it because that's why it became the victim of the supply chain attack. So what they did was they used custom malware designed for the solar winds build cycle. And they were able to replace the files. Some people say like milliseconds, and they were basically able to replace the files with their own malicious updates. And there was a very, very sophisticated attack, the way they did it, right? It was called the malway was called Sunspot, and it enabled the hackers to basically monitor. The solar winds development environment. And whenever they would be pushing their bills, they would replace them with their own malicious update. So basically, it was a backdoor. And this backdoor, when the updates were pushed the malicious update, now they had access to thousands and thousands of customers because they were able to sneak into other customers because they had put their own malicious update within the solar wins update. So solar wins helped them distribute this malware, right? And you can understand why Slewns was such a promising target for this type of supply chain attack, right? Why would they possibly be like this? Well, because honestly, like I said, many multinational companies and government agencies use the Oon software. All the hackers needed was to install this malicious update, and Solewns would be distributing it, right? And because companies are trusting them, they would be installing them. So it was, like, really beautiful in the way not beautiful because of the damage that happened, but really beautiful in the way it was designed. You could see just how intelligent these guys were, right? And what happened after that? A security company, I believe it was Frey. They detected this malware that was spreading to the customers, and they were able to identify the sunburst update package. They identified in K this solvins package has been compromised, right? And once detected, they immediately issued this update, and several customers could detect the same behavior happening in their enami. And so they realized just how bad the spread was, right? It had infected thousands and thousands of customers by them. And Solns did release quick hot fixes to eliminate this backdoor. But, you know, I mean, around I think 18,000 customers of solar vines and applied the Sunburst update, which then allowed the attackers to remotely access their customers' data. And, you know, we had, I think the US Department of Health, Treasury and state, all of them were infected, big big names, you know, like big tech companies, all of them were affected by the malware. And the whole point of this is because the way they were able to spread it, it showed the blind spot of trusting software updates, and it really led to not just solar vines but other companies taking a look at the rebuild process. If you are a company that is distributing software to other companies, right? And you're automatically issuing updates. You need to really think about what if there is a malware inside this? How do I make sure that it doesn't happen to me? And that's the whole point of looking at this case study. And that's what happened after this. So we had so many companies taking a look at their software bills, like, how do I make sure I don't have somebody sneaking in. And this is where the concept of reproducible builds started coming out, which we'll discuss shortly. But I just wanted to show you the impact. We had, like, a the Biden government, they issued an executive order and improving the nation's cybersecurity. You can see the date May 12, 2021, and they had a specific requirement on software supply chain security. They said that they mentioned the fact that these sort of software, they don't have transparency. We don't know what if Malware is coming in, and we really need to put in controls to make sure that the software supply chain security is secured, right? And the most, like, the shock thing was in the Landmark move, the Securities and Exchange Commission, SEC, it actually charged the CSO of solar wins with fraud and internal control failures related to the company's cyber security practices. They said that they bought charges that you had misstated how secure solar wins was. So they actually they bought these. They said that he had misled investors about the company's cybersecurity practices. He had not disclosed the risks and inadequate control. So basically, he had overstated how secured they were, and he had not disclosed all the risks. And that is that was quite like a a significant shift in how people view cybersecurity. Now CSOs realize that they are actually liable, you know, not just with fines but actually jail time. And will evaluate CSOs really had to take a step back. And this is why software supply chain security has become so, so prominent nowadays. And I hope I'm able to make you understand just how big a deal solar wins was. Now, how to protect? That's $1,000,000 question, right? How do you make sure that your company does not become the next, say, solar wins? Now, unfortunately, a lot of conventional good practices of security cannot counter this sort of attack. Like, what do people say that only installed signed versions, you know, digitally signed software updates that are coming from solar wins? It won't help because the software is sign. It is coming from the legitimate company. It's not like an attacker is sneaking it in. It's coming from the trusted company, right? Update your software to the latest version, like people will say, right? Because the updated software was the one that was malicious. And it was part of the valid build process. So that is where the starting the problem started to come in. You can't even say, review the source code because they were compromising the build process, right? And so a few of the key things you can do is, along with your good security practices like monitoring and hardening, right, making sure that you have controls that monitor behavior, organizations really need to harden their build process against these sort of attacks, right? And they need to make sure that the build environment cannot be compromised. They have made sure that we'll talk about this more when we talk about securing the software supply chain. But the build environment needs to be secured. You need to make sure that people cannot just compromise the environment and insert their own malicious updates, and you have to be monitoring. And the two most important things you can do is verified reproducible builds and software bills of material. I'm going to go into detail on their software bills of material, but the most strong countermeasure you can have is called a reproducible build, which is a build that always produces the same outputs so that the build results can be verified. So basically, verified reproducible build is where somebody independent can produce a build from the source code and verify that the build results come from the same source code you are claiming. Almost, I would say 99% of software today is not like that. But in the case of solar winds, what would have happened? Like, how would verified reproducible build? Just from the name you can see, you can verify it and you can reproduce it. So if you have access to both the source code and the build. What do verified reproducible bills do? They basically give you a very, very strong countermeasure against attacks like solar ins where binaries are not matching the source code. Why? Because an attacker has inserted malicious code into a binary, right? Because in the case of solar veins, they attack the binary, not the source code. So one of the advantages of reproducible builds are when those two builds happen, you can build them independently, and both of them will produce the same artifact bit by bit. And it'll give you that confidence that no malware was injected into this. And this is the whole motivation behind this concept. And what would have happened in solar ins if solar wins had implemented reproducible bills, it would have required them to generate a good binary from the source and compare it to the distributed binary. And it would not match, right? So this discrepancy would have introduced would have been introduced by the insertion of the malicious code, and it would have been detected because when they're distributing the binary, it would not have matched the verified reproducible build. And this could have alerted the developers to the presence of unauthorized changes that, hey, the build process has been compromised. There's something extra added to the binary, which was not there before. Is it like foolproof, 100%? Absolutely not. Because remember, the attackers were already within the environment, right? So you need other security controls also. But this sort of verified, reproducible build, this gives you a very, very strong sort of control against it. I'm going to put the link also to the whole website which purports this sort of control. But remember that if you are distributing updates to thousands of customers and you need this sort of verification, the verified reproducible belt is a very, very strong control against this. So I hope this was useful to you. We took a step back and we took a strong look at the solar winds attack. Now, are we going to take a look at another attack and see how that happened and it was a different type of attack from solar winds. But just to give you more context into how these attacks happen, thank you, and I'll see you in the next lesson. 8. Codecov: It's more Hello, everybody. Welcome to this lesson. And now continuing on from the previous one where we took a look at solar winds. Now we're going to another one recent one, which is dov attack. Now, solar winds, if you remember, it compromise the build process, right? The attackers were able to compromise the build process and inject malware. With this one, it is more about the CICD pipeline. If you're not familiar with Codkov and I hope I'm pronouncing the name if they don't get mad at me. But yeah, it is a code coverage tool. What does that mean? Basically, the check how much of your application is being tested, you know? Like when you're building modern applications when we're using CICE we use automated tests, right? We talked about this before. And we want to make sure that every line of code has been tested, right, and every FOG and this requires quite a lot of mature testing framework. This is where Cod Cov comes in, and it it can help let you know what lines of code are not being covered in your CI environment. And this is how they compromise they compromise this one which allowed them to compromise other environments also. Now, if you remember solar wind, solar wins was more targeted and towards espionage against government agencies and large corporations, right? Had a clear geopolitical motive, like a nation state attack. This one is more like a broad security breach that affected a wide range of companies indiscriminately. They didn't care who was being compromised. And they were focused on stealing information from Soffe development environments. Oh, this is what we're talking about now. The Code Cv attack, it was discovered in April 2021, if I remember. Yeah, it was like a massive security beach. And like I said, this is a very popular code coverage tool used by software developers to assess how effective their tests are. And it integrates with various virgin control systems. It generates reports to let you know how well the software tests are covering your code base, right? So basically, the attackers, they gained unauthorized access to Code COf systems. How they exploited our vulnerability. I think in their Docker image creation, we don't need to know the specifics of Docker and everything. But basically, they modified the Bash uploader script. I'm going to see details of that. What allowed them to do it allowed them to secretly export sensitive information from the customers of Cod C, right? From there, specifically from the CI environments, continuous integration environments. And what this information, credentials, user ID, passwords, token keys, and other data that they could use to grant further and unauthorized access. It went undetected for several months, I think, from January 31, 2021 until April 2021. And anybody who downloaded the compromised Bash uploader script, basically, they unknowingly exposed their information. I think it affected about 29,000 customers, big names in the industry, you know? And again, as usual, everybody woke up to supply chain attacks. Sorry, and everybody woke up to supply chain attacks, and they suddenly realized just how critical these things are. And Kotov did notify the affected users and they revoked and issued the keys and everything, and they agreed to have their environment audited. But if you take a look, this is how it basically looked like, right? So let's focus on if you remember the CI environment, a continuous integration environment. We can do a lot of powerful automation here to test our application, right? And you rely on a lot of external things also, right? Databases, payment systems, cloud infrastructure. When you're doing the testing, and all of these components need to be accessed from the pipeline so they can build and test the application. So basically your CI pipeline, it needs to have access to what secrets and credentials so they can gain access. And typically, hopefully, if you're building a CI environment, you should use staging infrastructure, not production byte, but based on my own experience, it is very common for production credentials to be used because people want to make sure they're doing the testing properly, and the testing is covering as much as possible. So unfortunately, a lot of times that information can happen. So it is very likely that the CI environment will have access to very sensitive information. So by attacking Kotkov and this is what they did, right? They infected the malware, they compromised the testing tool. They have access to all the credentials. Within the CI environment for all the Cdf customers. And basically, if you remember, they compromised a Bash script, which is just a set of instructions to what you would write if you've ever done terminal or Bash, but written out in a programmative way. They added a single line of code, which was to send all their environment variables from the CI to the attacker's remote server. You understand they're basically silently exfiltating this data out. And now you can understand if they have around 23,000 customers, anybody that was using the compromised version of Cod Cov between January 31 and April 1 would have been affected. And large corporations were affected, and they actually released basically documents on for their customers to how to recover from this attack. And what they do, what did they do after they had compromised it. So they did not attack them directly. They could have conducted multiple attacks from there, right? But what they did was they actually compromised the source code repos because they got the credentials, right? The source. And they were able to access then their source code repos. And they were able to find because those repos might have actually production credentials. So you can see how this attack is cascading, right? First, they compromised Kotkov. They got the credentials to the source code repos of customers. They compromised those repos. They got production access. And they had get up even noticed they had noted the suspicious activity from other private repos. They were being cloned to some unauthorized users, and it just shows how simple it was, right? Compromised KotkvUuse stolen Git credentials, access private repos, using those stolen credentials, and then you can start scanning them for sensitive information. Just to show you how beautifully simple this attack was and how they were able to compromise so many uh, customers using this. Again, like I mentioned, it had a global impact. Massive amount of customers, they were rotating their secrets, their source code depots and attackers were able to gain access to unauthorized depos, and they containteral source code, internal credentials, unfortunately. Again, now you have a better idea what can be done. Of course, it's different from solar winds, where the build environment was compromised. But here, again, you have to do security heartening of the environment. I cannot stressless enough, you have to make sure your environment is secure. Keep your source code repos clean. Do not put credentials there in your repose. If somebody is able to compromise them, he can use it as a jumping point into your environment, right? Put in data filtration and leakage controls. How do you know if somebody is silently leaking out data wide? You can even harden your source code repos via multifactor authentication and IP whitelisting. So if you know that requests are only coming from a particular area, you can actually put IP restrictions, right? So even if they have the credentials, they will not be able to access it. Security hardening of the CICD pipelines, making sure they only have that access which is needed. You don't want to give them admin credentials into the whole environment, right? And of course, avoiding hard coded credentials. So this was, again, another key study, another environment that had been compromised due to a supply chain attack, and I hope you've seen a different picture now. I deliberately chose this one because it is different from how solar ones was compromised. So now you have a good idea, and I hope now you've set the stage for understanding how we can go about securing it. You have a good idea of the risks, and within the context of actual attacks, you see how those risks materialize. So now we can move on to the next lesson, which is about actually securing the software supply chain. Now we can move on to the good part, which is actually securing and mitigating these risks. So thank you very much, and I'll see you in the next lesson. 9. Crowdstrike: Hello, everybody. Welcome. Welcome to this new lesson which I've just uploaded regarding the CrowdStrike outage. So unless I mean, if you're not using IT or not using any system at all, you would have heard about the CrowdStrike outage, which happened this year in 2024. Cloud Strike is a very, very popular like a security solutions company. I mean, they give their products exclusively to businesses and large organizations. They're very, very famous in the world of cybersecurity. Unfortunately, they become like a household name. Now everybody knows them because of this incident. And basically, put even though this is not like a cybersecurity incident in the sense, nobody compromised it, but it did have a massive massive impact on the supply chain. And it is very important. I could not talk about software supply chain or the supply chain security risks without discussing about Cloud Strike. Now, if you're not familiar CoudStrike, they basically have a component called the CrowdStrike falcon. It's like a sensor. It uses AI to protect, customer environments, you know, by identifying and protecting against the latest threats. And in a nutshell, basically in like 2024, they introduced a new update, right, which basically the new sensor was not able to handle and it crashed. And given how close the CrowdStrike sensor sits to the Windows operating system, it resulted in all the systems crashing and a massive massive global outage happening which impacted nearly every industry across the globe. Millions and millions of endpoints were impacted, right? And this has been dubbed the biggest ID disruption of all time or one of the I think it is the biggest because simply because of the nature and how it happened. I already talked to you about rodseg, it is a very, very popular security solutions company. Millions of companies have used it, and it is a good company. Unfortunately, the name has gotten kind of, like, dragged through the mud because of this incident. But no doubt it is a very good company, a very, very, like, mature security company. But unfortunately, the faulty software update. I led to that blue screen of death. It's like a loop on Windows machines causing them to repeatedly crash. And despite like crowds deploying the fix, the impact across the globe was massive. And like I said, literally, airports, ports, let's take an example, what sort of things happen. Airports were impacted. If you were traveling you at time, you have my sympathies. You will see images of, like, you know, across the board, airports being jammed, thousands of flights getting delayed, shipping ports being impacted, supermarkets, hospitals, I live in the UK, and the NHS sent out like a statement saying that they are not able to service customers right now patients because of the impact ID companies, government offices, and so on. I mean, across the globe, major closures, delays were happening, thousands of flights like a sideway. And basically, it shows the interconnected nature of the software supply chain. And even though the stunning part, this is not like an attack. It was just a mistake, but it showed the impact which can happen, and this is just an example. I mean, I'm sure you would have seen it, right? But it just shows how dangerous the dependencies are across the globe regarding this sort of software, right? So the global like I said, hospitals, Australian businesses, they said they had a damage bill of around 1 billion, right? And banks, media, NHS. So the impact across the globe was incredible. But it is very, very important to separate the fact from the hyperbole. And I do not like this the way a lot of times it was phrased. And how people started saying it was a cyber attack. It did have a cyber impact on availability, of course, and it was not like an attack by a criminal. And they did issue a root cause report, which you can see. And they did mention how it happened. Basically, the censor. It was like expecting, I think, around 20 input fields, but it had the latest update at 21 input fields, and the count mismatch is what caused a global crash. And because the interpreter was expecting 20 values, and when it started accessing 21st, it produced an out of bounds memory ad. You know, those things. And because it's so tightly integrated with Windows code, when it crashed, it brought down the entire operating system, and the blue screen was flashing across the globe, across supermarkets, airports, everywhere you can think of, it was basically flashing w it boils down to, there was a lack of proper testing for sensor updates. It bypassed their novel processes. The testing was not a detigors. And a lot of people started saying that this could now be exploited. And I would recommend reading the blog posts from CrowdStrike in which they addressed, and they refuted the claims about the Falcons security sensor even though it was an out of bounds memory crash, it was determined not to be exploitable for previous escalation or remote code execution as of today. And they gave a detailed root cause analysis that even this bug does not allow any program execution, and they mentioned the other controls they had like certificate pinning, checksum validation, access control is anti tampering detection, right? And they showed that I will link the report here, the blog here, and I will definitely recommend you read it, because if you're going to be analyzing these situations, make sure that you're analyzing it correctly and you are not putting in things which did not exist at that time. And CoudStak they have affirmed the commitment to security, and they mentioned that their bug bounty program, they have enhanced also. But the lessons to be learned from this incident are very, very important. So just to be very, very clear, attacker, even though this was not an attack, but attackers will learn from this incident. They have seen just how damaging this attack was the impact. So you can no doubt imagine attackers have taken interest in this attack, and they will think about how they can even make a bigger impact next time and make some money off it. If you are a solution provider. That is like CrowdStrike, you provide some agent, some software to the company. It is a good thing to look at your testing processes. Think about this sort of resiliency. What happens if your endpoint is sitting very close to the Windows kernel and something happens, right? Do a phase deployment. Don't do a big bang approach. I can't believe I'm having to say this, but this just shows right. No need to do a big bang deployment, do it in phases, and have independent audits done of your entire process. CrowdStrike, I think they engage with two separate companies to do a complete assessment of their software development practices, the testing just to make sure that they have not any blindspots. And from the customer perspective, if you are somebody who's using a software like RoudStrik First of all, I would recommend removing excessive dependency on one vendor. If you have one vendor that is doing everything and something happens to that vendor, you're going to be in big trouble, right? Think about this scenario and add it to your disaster recovery playbook. But I have to be very clear. This sort of scenario very few people can predict. It was like a Black Swan incident, right? Like something which happens once every two, three decades. But I would recommend think about things like Cloud backups or having like a virtual desktop, which is a completely separate image from your normal desktops, right? So if something happens, if there is a major, major case, you will be able to recover to the Cloud desktop. And this is something completely so it's air gapped from your regular network. It does not have the same agents. It has different agents. It might cost more, but then in such an incident, you will be able to completely have a separate image created on which your staff will be able to resume at limited at least activities because a lot of companies, they were completely cut off. The servers were down, but even the regular desktops are down because Cloud Stoke was running everywhere, right? So think about this having another image on which you can deploy and which you can get up and running, which is separate from your normal images and which will not be impacted by the same issues. So these were the things I wanted to talk about everybody, just to show you because CrowdStk was like a massive incident. It's still unfolding. A lot of news are coming out. But think about these incidents, especially when you're thinking about securing your software to apply chain. Thank you very much. I'll see you the next lesson. 10. Securing Supply Chain - 1: Hello, everybody. Welcome. Welcome to this lesson, which is part of a multi part lesson, which is going to be about securing the software supply chain. Now, by now, I hope you have a good idea of what the software supply chain is. You have a good idea of the risks that can happen. You have seen actual attacks and how they got compromised, right? So now we're going to be looking at implementing controls within the software supply chain. We're going to be looking at security controls and practices, some of the common mistakes that people make when they're starting out on their software supply chain, security journey. And then we're going to look at some standards and frameworks also, which you can leverage to get the best benefit for when you're building up a of a supply chain security program, you don't need to build from scratch w. You can leverage what you already have. So if you take a look, this is what we discussed earlier. Remember? This was the environment with the risks that you have a developer environment, which can got compromised. You have insecure code, the build platform get compromised, the source code repo, the dependencies, you could not be doing security testing of the code. You got a data breach of the preprod environment, and even your production environment can get compromised. So this is where software supply chain security comes in to basically secure all these risks, right? And if you remember way back when we started the course, we talked about software supply chain security, right? It is basically ensuring the integrity, security, availability, reliability of all the components and processes that are involved. In your development, distribution, and maintenance of software. You want to make sure nobody messes around with your software, nobody tampers with it. And very, very important when we talk about a supply chain, we are not just talking about the direct source code, right? We're also talking about third party libraries, tools and services and the infrastructure because I can see a lot of times sometimes it's not your infrastructure that is cutting compromise. It is the vendors or the providers. So how to make sure that your supply chain security program covers everything? So this is what you need to keep in mind. And what are unfortunately some of the common mistakes that people make which always like it gives me a headache when I'm talking to customers, supply chain security. What it is not? It is not a tool or product. Please. Anybody that tells you that any vendor that comes to you and says, Buy my product, and you will have software supply chain security, that is complete bogus. It will help you. Undoubtedly, it will help you, but it is not. It is a part of software supply chain security, not the end goal. Okay? You cannot automatically just become your software supply chain does not become secure because you've bought a solution for millions of dollars and implemented it. It is not a certification. Anybody says that use this checklist or use this thing, and now your supply chain is secured. Again, that's not how it works. It is not a vendor checklist, also. Some people, what they do is they do a vendor risk assessment, and they think now their software supply chain is secure. And it's also not a one time activity. It is something you have to continually keep risk assessing. And it is Last one is myF enabling MFA. Again, nothing wrong with enabling MFA. It is a very important part of software supply security. But people think because we've enabled MFA now our environment is secure. I have no idea how that comes about, but please do not make this mistake, right? So, like I said, think of the definition which I talked to you earlier, this one, keep that in mind and do not get confused with these misconceptions. And when we talk about securing the software supply chain, we're talking about multiple controls, right? And this is what I'm going to be focusing on in these lessons. We're going to talk about secure coding practices, what you can do, third party components, hardening your environment, CICD pipeline security, actual security testing and scanning, the software builds of material, L BOM, if you're not familiar, and, of course, vendor West management. All of these things come together for an effective software supply chain security, and then we're going to look at how to create an actual program also. So all of these items I'm going to be covering. I'm not going to bombard you with information. We're going to go step by build up your environment, right? So at the end, your environment is going to look like this. You're going to have controls at multiple levels, and then you're going to have a proper program running, which makes sure all of these things are being looked after and risk assessed. So like I said, we're going to do it in paces. I'll see you in the next lesson, we will start deep diving into these controls. Thank you very much, and I'll see you in the next lesson. 11. Securing Supply Chain - 2: Hello, everybody. Welcome. Welcome back to the lesson. And we are continuing our previous lesson where we're talking about securing the supply chain and the security controls, we can implement it. So if you recall, I showed you these basic controls which are there secure coding practices, third party components, hoarding environments, CICD pipelines, security testing. All of them, we're going to go one by one and take a look at it. So let's move ahead. And if you remember, I showed you the diagram also like this is if we earlier had the risks showing up in this diagram, but if you put in the controls, these controls which you're seeing in the diagram, those risks get mitigated. So let's start with the very first one, which is secure coding. If you recall, we talked about the risks, right? And I said that the insecure code, that is the root of all evil. So secure coding, that's why we need to discuss it first. Secure coding in the context of supply chain security it refers to the developers developing software in a way that you make sure that no vulnerabilities are present in the code at any point in time. Okay? And that requires controls, both awareness and technical controls, right? Because remember there are multiple ways in which vulnerabilities can get introduced. So we're going to talk about secure code training, and how to integrate security feedback into the ID itself, which is a critical part which gets missed out by a lot of people. We're going to talk about the ways in secure code reviews can happen. And, of course, the security testing of the code that is submitted the SAST and the dust. If you have been working in cybersecurity, I'm sure you're familiar with this. So first, let's start with the secure code training. Security Awareness of insecure code is a very, very, very start. You have to inform your developers about insecure code and, like, the dangers of it, right? There are many, many good trainings available. OS top ten is the industry benchmark. I'm sure if you're in cybersecurity, you must have heard of it already. So do educate them, tell them about trainings like this, show them, talk to them about the insecurities, can be, but very, very important. Please do not make it death by PowerPoint, which is I refer to it as when you give them like a 200 page PowerPoint document. Believe me, nobody's going to remember that. Show them, actually show them insecure pieces of code and show them what are the vulnerabilities. Show them that if you fix it within the code itself, how much time and effort is saved as opposed to somebody finding it out later and then fixing it and the amount of time that gets wasted, right? So there are many, many, very good trainings available on insecure code, on OVA, things like SQL injection, cross site scripting, all of those things. So make them awareness. But on a very, very important point, and this is where people miss out you start with the awareness but make sure that you do this, which is this point which is integrating security feedback into the ID. The ID is the integrated development environment. And by that, I mean, the coding that they're doing, they should be able to get feedback there and then. Okay? You can give as many trainings as you want. Developers need a way to get real time feedback. Okay? When they're developing the code, how to let them know that the code is not secure, right? What issues are present? And this is the most painless and a frictionless way to secure code. Believe me, you don't need to do security testing later on if the developer knows right away, if it does a quick scan and see, look these are the insecure. Maybe my code I've written is not secure, I need to fix it. This is the easiest way, and if you do this properly, you will see a massive boost in your security code. Okay? So if you take an example, if you remember I showed you this example early on, like this is a code which does not sanitize, the input is taken, and of course, it can lead to things like SQL injection where people can actually access your backend databases, your operating systems, your files, if you don't sanitize it. Now, this is an example of an IDE, like Visual Studio code where people type right. And this is a tool, what do you call code whisperer, which is A. You can use any tool. I don't like mentioning specific tools, by the way. But if you look at the screenshot, so this was the code, the same code I've shown you, if I put it here and I run a security scan, right away, it'll tell me, look that there is a SeQL injection, and it'll tell me the line also. You see how powerful this is if you do it properly. So you can say right away, the developer will know, look, I'm introducing a security vulnerability to the code. I need to fix this before I submit it to the repo. And this will lead to a massive boost in your security code quality. Again, if you remember, I showed you this one, the zip bomb attack where people are sending a file which can potentially be unzipped to GBs of massive amount of data and being down the server cause a denial of service. So if you do this, again, you will see immediately, it'll give you feedback, unrestricted upload of dangerous file tap you can see at the bottom and resource link. So this is a very, very powerful way. I showed you the example of code with spur but you can use many tools which integrate into the IDE itself and give the developer real time feedback. About what sort of code they are submitting and why it is insecure. So please do look at that. Do not make the mistake which 90% of people do, which is they give the developers security code training and then they expect them to find everything. No, it's not going to work like that, give them tools which give them real time feedback. So after that, we talk about testing. Now, if you remember, we talked about testing, it goes through the CSED pipeline, it goes to the quality testing. This is where you can introduce your different types of security testing for the code. The first one is static application securities testing or SAS. This is a testing methodology that looks at your source code. It doesn't execute the program, and it's usually executed at an early stage during the coding phase itself. It will let you know, so it looks at the source code and it'll find out, hey, are you introducing any security vulnerabilities? You can integrate the tools into the CICD pipeline and it does a very thorough analysis of your code base. It examines the code because it goes right down to the code level. The second one is the DAST, which it is a black box testing methodology, meaning the code has no access. It's not looking at the source code, but it actually executes. So during its execution, then the program is running. I actually simulates external attacks like SQL injection, and it's performed later on in the CICD pipeline. Usually when your software is in preprod or the staging environment, right? So it looks like the web pages, and the APIs, and it tries to exploit them. So booster both of them are used together. There is no people try to say I SASPTO is DAS B SAS and DAS both complement each other. DAST identifies vailabilities from a different perspective, and SAS looks at the source code. So they complement each other. Ideally, you should be looking at both of them. And how does it come together? So if you look at the left, you have the ID where you give the developers training, and you are putting feedback into the ID. So they're writing secure code. Once they submit the code, it goes into the CI pipeline. It does testing, reporting, building, and SAST comes in. So it looks like the source code. If the code is insecure, it goes back to the developer. Please fix this. If it passes, so if it passes the ID, it passes the SAS, it goes to the CD pipeline where you have the review staging prod. Within the staging, you have the das happening. This is a very simplistic example of looking at it, but it's a very, very powerful tool. So if you put distribute security throughout your life cycle, you will definitely lead to a higher quality of code within your application. So that was the SAST and dust. I want to come to the other example, which is, again, one of the most crucial examples. I think this is the thing which people think about the most when they talk about software supply chain security, which is third party components or dependency. We talked about the libraries, right? The libraries because nobody builds applications from scratch. You're going to be relying on libraries, Libraries like Log FoJ but got compromised, right? So all of these libraries can introduce vulnerabilities, third party components, and they are a huge blind spot. So what do you do here? You use something called software composition analysis. So what it does is it looks at your dependencies. What are the dependencies? What are the software libraries, and it actually identifies any security risks which are there. Just like SAST looks like the source code. This one looks like your third party libraries, and it tells developers, Hey, your component is vulnerable and it can actually use it on an ongoing basis to find out if any vulnerability is because it's not static, right? It might be possible that a component is secure and tomorrow it becomes insecure. So SCS software composition analysis, it completely monitors and it looks like what is happening. So this is an example from CISA, they're a government website, and they have a very good publication, I'll link it about securing the software supply chain for developers. And they give this recommendation. So within the pipeline, the developer maybe he selects a component for download, right? I don't know, the Log four j library. So the component gets put into an intermediate secure repository where you have the software composition analysis. So it'll scan it and it'll let you know that, okay, this is secure. No issues are there, and it'll move it to the secure repository. And from there, the developer can now sign in, check it in and start using it within the code. Or unless it finds an issue, then it goes back. So this is a very good way of looking at it, how software composition and analysis works. And if you look at it again within the pipeline, so within the ID, you have secure code and feedback, and you can put software composition and RSS there also. So when the developer is checking in a library, the software composition Ss will kick in and let him know this is insecure or within the CI pipeline also. So when SAST happens, SAS can integrate with software composition analysis and let you know, look, the code is secure, but you're using an insecure library. And lastly, DAST. So DAS when you're doing DAS, you can also do monitoring of the libraries which are present, and it can let you know in the running software, what issues are there. So this was just a high level view of the very first part, which was the insecure code and how to secure it. So by now, by now, I hope you have a much better idea of the controls you can put in place to secure your source code. Okay, now the next one, we're going to look at the environment hardening, how we harden the source code reports, the bill servers, the packet servers, and we're going to look at it in a higher level and see how it complements software source code security. Thank you very much, and I'll ask you in the next lesson. 12. Securing Supply Chain - 3: Hello. Hello, everybody. Welcome, welcome. We're continuing on our lesson now. We've covered coding, white secure coding and why that is important and how to secure it. And we talked about third party dependencies, also, right? So we're going to be continuing on in that case, and now we're going to be talking about the environments. If you remember we talked about the developer environment, the pre prod environment. And we're going to talk about the components that are there in this lesson. So first of all, you know, giving practical tooling, practically, making sure that developers are able to do what they want. That is one of the most biggest challenges, you know, in cybersecurity, because if you don't give them developers what they need to do their jobs, developers are very technically savvy. They will find insecure ways of doing their work. So this is where cybersecurity has always been a bit of a challenge, right? Let's take an example. Companies and cybersecurity teams, they typically do not want staff to be executing code on their workstations or laptops, right for obvious reasons. Yet developers need that. They need the ability to install essential tools and test their software effectively. That's where you need to be flexible, in the developer environment. And like I said, developers are very tech savvy. If you don't give them what they want, they are likely to find ways to bypass obstacles that are stopping them from working, and that will create an insecure environment. So this is why you need to think about giving developers the ability to do what they need to do. So there are many ways to do it. You can actually segment of the developer network. So you can put it on a separate network, right? I know people who put their developer environments completely on the cloud and segregated it from the production network. The only thing that is combining them is a repo. But they are full rights because they know that even if there's something issue happening there, it's on the cloud, it's completely segregated off from their production network. So this is where you need to think about. If an attacker compromises it, what's going to happen? So because once an attacker compromises it, they can potentially inject malicious core, exploit compromised devices. So there are many varied ways of doing it. You can separate, like I said, your business environment and your development environment, isolate your developers, from the core business. So make sure they do not have access to any critical business functions and think about ways of securing your developer environment. You're putting in multifactor authentication give them things like VDI, which gives them a sandbox. So it gives them the ability to do what they want to do, but they are restricted. They are put into a particular sandbox. So these are the things you really need to think about when you're hardening your environments, right? How to isolate your developers from your production environments. And, of course, you have preprod environments, also. They have data. Make sure you're anonymizing it. You're sanitizing it to the best extent possible. Contrary to popular belief, you don't need all the data there. You just need enough to simulate production wide, but you might not need all, for example, like a cow data or PII data, you can potentially sanitize it. So think about those things. You have to have security monitoring. I've talked about data anonymization. So these are the ways in which you can harden your development environment and your P production environment. And we talked about hardening. One of the key things to think about is the security of your source code repos, your build server, your packet server. All of these things come into mind, whether you have a CICD pipeline or DevOps or just manual. So let's go step by step. First of all, is your code repo. If you remember this is where you put all your code yeah. This is where your developers are putting the code and hardened access to the reaper. You can think putting things like multifactor authentication. Are you reviewing who has access to the repo and secure the underlying infrastructure. If it's on prem and somebody can hack into the server itself, then you can't really trust the code, which is going to be on top of it, right? And always enforce that principle of lease privilege. You won't believe how many companies I know they check the access of their applications, but the IPOs they completely forget. They completely miss about it. So user access to repos, think about how you authenticated. Is there a good password policy? Are you enforcing things like multifactor authentication? Are you restricting it to IP addresses? Like we talked about the Cod Cv issue, right? That could have been so if the IPs had been destructed because even if they had compromised your repo, they would not have been able to access it. And, of course, one of the most dangerous things, please keep scanning it. Always keep your credentials and your source code separate. Do you know if your developers have hardcoded any credentials into your EPO, logically separating your credentials from source code. And making sure that they are being scanned. This is one of the most basic stuff. To this date, I can guarantee you so many companies have hard coded credentials within their repos and they are not aware of it. So do you have that plan? Do you have some sort of an incident response plan if you find out, right? These are all the things you need to think about when you're talking about your code repo. If the code Depot was secured, attacks like Cod COV could have been blocked. Okay, the next one is the build pipeline, right? We talked about this once the developer, he commits something to the code, the repo. That's where your build pipeline comes in. This can be part of the CSCD pipeline. You have to secure this most crucially, because this is one of the biggest targets. We've already seen this happening in solar wins, right? What does an attacker do? He infiltrates a development network. He scans to find out where the source code repos is, where the built systems and where the vulnerabilities. He compromises it. Now he's able to like compromise the code which is being committed, and you can compromise the binaries, right? If you want to secure the integrity of your code and the build artifacts, you should make sure that your build serves hardened. And remember this at all times, that the build threads are one of the most dangerous threats that can be there, as evidenced by the solar winds environment. So what can we do? So first of all, following the hardening guidelines. Most of the build tools that are there, all of them have hardening best practices which you can follow. Segregate your development, your engineering network from the coopit network. We already talked about it. Are you monitoring your build environment? Do you have things like, a multi factor authentication there. Why? Are you auditing what accounts they have access to? Because remember, the build server, if it's automatically deploying code to different environments, it will need access. How do you know that those accounts have not been compromised, right? Making sure that you're logging all access. And we talked about the verified reproducible builds, also, right? So builds which you can build on separate environments, and they will always be the same. That gives you the assurance that nobody has tampered with a built like solar. And making sure basically your secrets and your credentials they are secure. So these are complete checklist which you can use to start securing your built environments. So those are the build servers. What else is the package server? If you remember, so you put things onto the source code, they go to the build server, and from there, they go to the package. Now, the package server is where your software gets deployed, right? You software packages. And package repository compromise. That can be a significant threat in your software supply chain. We talked about this earlier. If attackers are able to compromise it, they can potentially push malicious code there, right? So again, hardening MFA, using cryptographic signatures. What is this? You want to make sure that the integrity of your software packages. So this way, if this package is tampered or altered, your cryptographic signature will come into play. Because the package will have a unique digital footprint, right? And we can verify that nobody has tampered with. So again, then you can make sure that you're using secure channels, making sure that HDDPS, SFTP or even VPNs are being used to make sure that the packages are encrypted in transet verifying the integrity of the software packages before distribution. So you want to compare your packages current crypto signature against the original signature to make sure that nobody has tampered with that, right? And against signing it. These are some of the very, very important controls. And right now, I want to take you back one of the key risks we talked about. You remember this the dependency confusion attack. This was a major, very, like a major supply chain whisk, which is where attacker publishes a malicious package to a public package repository with the same name as a popular package. So your developer, they might ask for a package, and what happens is the package re first, what it does, it checks the public report. And there the attacker has put the same name, but with a higher version number. So you might have version three, he'll put version five. And the package repo the way it's configured, it'll first go to the Internet to check, and it'll download the malicious package. And in this way, the package will get copied onto your developers network and Bingo. The attacker has access to your software development environment and he's able to compromise it. So it's just a way it's a type of attack that exploits the way software development environments and package managers work, you know, things like node package manager, Python package index. This is just the way it works. So, again, what can you do securing this? You can use private repositories for critical dependencies, you can just use private repositories with strict access controls to reduce the risk of you accidentally consuming compromised packages. You can use dependency locking, making sure that your dependency the package which the developer is isting is locked down to a specific version which you have verified. It prevents those automatic updates from potentially compromised newer versions. In this diagram, you can see the attacker has compromised a public package repo, right? And the developer he asked for a package. The package will not go to the Internet to check it. Why? Because you've locked down the dependency. You've said that this is the only version I want, which you've already verified, which is on prem. So it will not go to the Internet and you will be able to completely bypass this attack. The attacker will not be able to compromise your environment. So these are the things I want you to keep in mind, which is protecting against dependency confusion attacks, right? These are the things you need to think package name verification that the names of all the packages being used in your project are known and trusted. And you can do this by verifying the source and maintainer of each package before you add it to your dependencies. Package signing of already talked about. Same thing like you have a digital signature, right? Signing the package and using private package repositories, so consider using private package repositories where you host your internal dependencies. This can help to reduce the attacker, like I showed in the previous diagram. Even if he introduces a malicious package, which has the same name as your internal dependency, your package manager will not go there because it is going to stay on prem and only use the internal one. And of course, monitoring and scanning your packages, right? You want to make sure that no vulnerabilities have been introduced in the meantime. So this can help to catch any malicious packages and monitoring the package downloads. So by monitoring the downloads of your package, you can help to detect any malicious activity. So these are all the things you can do to make sure that you are secured against dependency confusion attacks. So we've covered now the environments. Now I want to talk about a very important topic which is crucial when it comes to software supply chain security, and this is the software builds of material, SBOM. Thank you. And I won't cover this because I think you already have enough things to understand in this lesson. I'll see you in the next lesson, we will start this topic. Thank you very much, and I'll see you in the next lesson. 13. SBOM: Hello, everybody. Welcome. Welcome to this lesson, which covers a very, very important topic in software supply chain security, which is a software builds of material, SBOYM. So what is an SBM? It's very simple. It's basically a nested inventory. It's a list of ingredients. Of all the software components that are present within your software. And if you think about the software supply chain, right, every tool framework or build used to write, build and run applications, and this is where all the vulnerabilities come in, right? And you're constantly reusing code, software packages, and third party vendors also sell commercial packages. So the complexity of building all these software apps, it makes it very, very crucial to have an inventory of all the components that are used to create such application, a catalog, right? And this catalog helps organizations to quickly identify and detect if they have any security vulnerabilities within the environment. So this is where the SBM comes in. It has become very like a standard in software supply chain security. And this is where you can actually ask from vendors and get this. And we're going to look into this into more detail. So you can actually do this yourself. You can even do it with Excel sheet. I would not recommend it at all, or you can generate it automatically. Many, many softwares are there which scan your environment, and then they actually generate or software builds of materials. That is what I recommend using a machine generated one. And it's very, very beneficial, why? Because it helps you to identify vulnerable components and it gives you a full knowledge of what you have, right? What if there's an incident of a particular library which is being compromised? How would you know if your critical applications have this or not? You can actually quickly query your SBM, if it's there in machine format to find out if this particular version of this particular library is being used, right? And it helps you to select vendors also who are writing, like if your vendor is transparent and he says, Hey, here's my SBM with the application. You know that this is a mature vendor, right? They have all these things necessary. And even after I believe it was solar wins, the software supply chain vendors and the security from the executive order that came about, they also started mandating that you need to have an SPOM. So like I said, you can do it manually, use an Excel sheet. I would absolutely not recommend it because you can have hundreds to thousands of dependencies. Usually, you can do it using machine generated tools, right, which are completely do it automatically for you. So like I said, what does it do? It's like a completely exhaustive inventory, right? It details every piece of third party open source, libraries, code packages that are utilized in the development of a software application, and it gives you a good idea of the software composition, right? This way you know what is there, what is not there, what version you're using, what libraries and code packages are using? What third party components are like, what's the PAT status? What's the dependencies between them? And you can understand now, if I wanted to know what the PAT status is because I don't know if the particular software is vulnerable or not to a particular attack, the SBOM can immediately help you identify it. And this is like a machine generated one. This is how it looks like. I mean, I don't want you to read it, but it just shows you can see that it shows you what's the package. Right? What's the status? What's the version? What's the hashcode? Who's the supplier? So all these things come into play. And how does it help? So I've already talked about this, but, you know, first of all, you have transparency. So it gives you a complete list of what you have, right? This level of transparency allows companies to know exactly what is there in the software and making it easier to manage and secure. Vulnerability management with SBM, you can quickly identify if any software components are there that are vulnerable of security issues. So you can proactively identify issues. Compliance, many industries have regulatory requirements that mandate security standards for software. So if you do not even if you do not have the software in the house, maybe you're using a vendor based software. You can use an SBOM. You can ask the vendor for the SBM, right? And of course, supply chain security. The whole point of this is to improve your supply chain security, and it helps an incident response also. Let's say, in the event of an incident response, SBM allows you for quicker and more efficient incident response. You can quickly easily determine which components might be affected by an attack. And again, dependency tracking. So like I said, it becomes so complicated to track what you have and what you don't have. So an SVM helps you track these dependencies over time. And nowadays in the age of GNAI and everything, you can actually put an AI on top of these files and query it and get completely human life responses, right? So all these things you can think about. So if I look at it from this perspective. So supposing like you have a cybersecurity team, right, and your company is purchasing a product from a vendor. And now the cybersecurity team they wants to know what sort of software is there? Is it open source? How is it built, right? So you ask the vendor, can you please give me a SBM? So this is what the vendor responds right. They give you an SBOM and the person is now able to read it and get that assurance. Okay, what is there? What is not there? Now, no software is immune to security vulnerabilities, right? Every There's no software which is completely 100% secure. So you can actually even do that with an SBOM. So you can ask the vendor, are there any vulnerabilities in your software lab redes? They can give you OSB plus something called vulnerability exploitability exchange. Now what is that? This is a framework that is designed to communicate the security vulnerabilities in the software, particularly whether software is vulnerable or not. So VX statements, they provide vendors a way to communicate. Whether there is a vulnerability or not, you can tell them exactly. So if I'm a vendor and a customer asks me, I can give them the SBM plus a VX. And I say that this vulnerability is not a concern for our product, and you can detail the conditions under which it might be an issue, but you have mitigated it, right? So it's a part of the SBOM and it gives you a transparency. So this is, again, a standard which is becoming more and more popular in the software supply chain. Why because you do not have access to outsource source code, right? But if you're buying an application, you can actually use the SPM. You can use the VX to get that assurance. And in the next lesson, what we're going to do is we're going to do an actual case study, like, how would that happen if a customer was buying a software and what we can do? So I think this covers pretty much all the things we talked about, right? So we've looked at it from the developer environment, secure coding, hardening, component scanning, testing, hardening the environment and now looking at it from the SBM perspective. So I hope this was useful to you to understand just how vast this world is, right? Now, you have a good idea of what the software supply chain security and the controls at each stage and the misconceptions which people have like this is a product that you buy or this is a certification you get. So now that you are in a good state, we can now you might be thinking, Okay, there are so many controls. How do I actually implement? Where do I start do I start with the SBM? Do I start with Secure code? Do I start with dependencies? What do I have to do? So this is we're going to talk about in the next lesson where we're going to talk about building a software supply chain, security and risk program. Like if you start making this within your company, where to start and where all these different components are going to come in. Okay? So I hope this was useful to you. I'll see you in the next lesson. Thank you. 14. Conclusion: Hello, hello, everybody. Welcome. Welcome to the final lesson. And this is just wrapping up. Thank you. Thank you for listening to me, talking for God knows how long. But I hope you've gotten a good understanding of software supply chain security. I hope you have a holistic view now, and you're not just thinking about like buying a product or just turning on MFA or something like that. I hope I've increased your knowledge about new types of attacks. So remember, it's an ongoing journey. Follow industry best practices and trends which are there and start. I cannot, please do not be one of those people who just take this lesson, and then you forget about it the next week. Okay, start, take some of the lessons which I've told you about and start implementing it within your company. Take a look at the built repos, the package repos and start implementing it incrementally. But that's pretty much we've ended the course. I hope you enjoyed listening to me Babylon for so many hours. Thank you very much for putting up with me. Remember I gave you a project at the start. You can take this and gap your own software supply chain against the risk we talked about and share it. And take a look at like do a simple assessment of where you stand, your supply chain, what are the risks and how you can mitigate it, document it so you can get a better idea. Because if you don't apply this knowledge, I can guarantee you will forget about it. You will have wasted your time and money if you do not apply the knowledge which I've talked about. So that's pretty much it. Please do feel free to reach out to me. I'm there on Substack, LinkedIn and I have a small YouTube channel also. I link everything within the comments. So sorry, within the lesson, you can click on it, and reach out to me if you thought this was a good lesson, please do leave a if you thought this was the worst course you've ever taken, let me know, please, also. No worries at all. I'm happy to get feedback. So thank you very much. This wraps up this course. I hope you had a good time, and I'll see you in the next course which I teach. Thank you very much and goodbye.