CCT 356: Supply Chain Attacks Are Exploding in 2026 — Here's What the NCSC Wants You to Do

Your software is only as trustworthy as the dependencies you quietly inherit and attackers know it. Today I break down the NCSC warning on software supply chain security and why open source package ecosystems have become a high-value target for real-world compromises that spread fast through CI/CD pipelines.

I walk through the attack patterns that keep showing up in incidents: maintainer account compromise, expired domain takeover, typosquatting, and credential chaining. We connect each technique to the CISSP mindset so you can spot it in scenario questions and, more importantly, recognise it in your own environment. Along the way, I explain why Node.js, Python, and Rust projects are especially exposed, how automation can turn “latest version” convenience into an enterprise incident, and why developer environments often become an overlooked attack surface.

Then we get practical with controls you can actually implement: pausing automatic dependency updates when compromise is suspected, adding human approval for critical packages, rotating credentials immediately, enforcing MFA on developer and registry accounts, and using private or trusted registries to mirror and vet dependencies. I also zoom out to show how to build supply chain security into the secure SDLC with software composition analysis (SCA), code signing, checksum verification, audit logging, continuous monitoring, and an SBOM so you can respond fast when a package turns toxic.

If this helps you tighten your dependency management and level up your CISSP prep, subscribe, share this with a teammate, and leave a quick review so more security pros can find the show.

Gain exclusive access to 360 FREE CISSP Practice Questions at FreeCISSPQuestions.com and have them delivered directly to your inbox!  Don’t miss this valuable opportunity to strengthen your CISSP exam preparation and boost your chances of certification success.

Join now and start your journey toward CISSP mastery today!

Transcript

Welcome And CISSP Mission

SPEAKER_00 0:00

Welcome to the CISSP Cybertraining Podcast, where we provide you the training and tools you need to pass the CISSP exam the first time. Hi, my name is Sean Gerber. I'm your host of this Action Act Informative Podcast. Join me each week as I provide the information you need to pass the CISSP exam and grow your cybersecurity knowledge. Alright, let's get started.

SPEAKER_01 0:26

Good morning everybody. It's Sean Gerber with CISSP Cyber Training and hope you all are having a wonderfully blessed day today. Today is Monday, and we are super excited to be able to talk to you about some great topics that are going to be happening with you as it relates to the CISSP.

NCSC Warning On Supply Chains

SPEAKER_01 0:43

Now, before we get started, obviously one of the big aspects I want to talk about is something I saw in the news that is kind of tied to what we're talking about today. Today is going to be supply chain security practices, and we're going to be getting into focus around supply chain and the different domains that are associated with that at the CISSP. But this article is related to the NCSC, urges organizations to share up supply chain security practices. So this is written by an Emma Wallacott. Okay, this was a couple days ago. And this is the if you're not familiar with NC NCSC, it's the National Cybersecurity Center that is part of the UK. And so they are recommending that you do some shoe share cybersecurity practices. The ultimate goal around this would be associated around domain eight with the CISSP. So how is this all kind of play together? Well, today we're going to be talking about something that should be keeping every security leader up at night. And I know you all deal with this on a daily basis, but we're trying to talk about how this can affect you. So the software supply chains are a big factor for any organization. And I'm not talking about stuff that might be theoretical. This is the stuff that is going on all the time. Now, the UK's National Cybersecurity Center, the NCSC, just dropped a fresh warning urging organizations to revisit how they manage their dependencies. Because we know the bad guys are not waiting around for this. And everything that comes into the uh when you're rolling into the supply chain, supply chain is such a huge factor with any organization. Any organization that has any size is dealing with supply chain challenges, and they also have very high ties to supply chain. So here's the thing your application that you have specifically isn't just your code, it's almost in every library out there, every package, every open source component you've ever pulled in, and each one of those is a potential door for an attacker to walk through. So, I mean, that's that's actually it. It's literally what it comes down to is if you are in a position where you have software development in your environment and you're dealing with supply chain, you definitely have a challenge with it there. So, what did the NCSC actually say? So they issued guidance warning organizations about a sharp rise in attacks, specifically targeting open source package ecosystems. And the attack techniques they called out, these are not new. No, they're not new at all. We deal with them all the time, but they are scaling fast, especially when you're starting to roll into the AI component and techniques that are happening there. So let me walk you through some of the key

Common Package Attacks Explained

SPEAKER_01 3:16

ones. So a maintainer account compromise. Attackers steal the credentials or tokens of a trusted package maintainer. So that's a key factor, right? They're stealing somebody that already has an organization, they already have accounts, they are a key factor in this. So once they're in, they push malicious updates into every organization, they're pulling that package automatically. It gets the payload, everything is done. So the package is still listed as legitimate, nobody flags it, the trust is already baked in because they got the credentials. So it's a big factor. Another one is the expired domain takeover. Package maintainers often tie their accounts to email domains. So when those domains expire, attackers swoop in, register them, and take ownership of the package. You never even know there was a handoff. So that's the expired domain takeover. Type squatting. Attackers register package names that look almost identical to the real ones, which we have seen this over and over again, maybe potentially one letter off or a common misspelling. The developer's fat fingers during this quick install and suddenly malicious code is running in your build pipeline. This I've seen this specifically happen in my red team days. We would do this a lot when it came to we'd put packages out there that were just close, but the spelling was off a little. You wouldn't catch it, but they were just small little minor changes in there. Now, credential chaining. This is where tokens are stolen from one attack that are used to compromise additional packages. So one breach becomes a force multiplier. Again, this we see this, if you've all dealt with any sort of credential stealing, it's out there all the time, everywhere. Because we if you go to Google, they'll tell you you have it. So here's the CISSP angle on this. Which domain does this fall under? And here's the CISSP angle on this. Which domain does this fall under? Domain eight, software development security, obviously, right? But don't sleep on domain one either when you're dealing with risk management. Because the NCSC's core point is that organizations are accepting risk they don't even know they're carrying. This this happens all the time. And if you an organization depends on who has the rights to declare or to maintain the risk and to understand the risk to the organization, is a little bit fuzzy. So why is this problem getting worse? Now let's talk about why this is accelerating. NCSC pointed to three specific languages that are especially exposed: node.js, Rust, and Python. Python's everywhere. Rust, I've dealt with that in various aspects when I was doing my red teaming, and then Node.js is also everywhere. So why those three? Because they have minimal standard libraries, which means a developers lean heavily on third-party packages to get even basic functionality done. So Node.js.js particularly can have a single application that touches hundreds of packages, many of them small, obscure, and maintained by one person in their spare time. So big factors there, guys. And here's where it gets really kind of confusing and also a bit scary. Most of those packages are pulled in automatically through CI CD pipelines. So you have continuous engine integration, integration, and continuous development pipelines. So there's no human standing there reviewing each one. The pipeline just grabs the latest version and runs it. The NCSC put it very bluntly, and I'm paraphrasing here, but it's a combination of automation, trust, and scale that lets malicious code spread rapidly across many organizations before anyone even knows it happens. So think about that from a CISSP risk management lens. You've got confidentiality, integrity, and availability all at risk the moment a malicious package executes in your build environment. And the developer environments. I mean, all of those, right? The NCSC specifically noted those trends to be less controlled than corporate endpoints. And I will tell you that is spot on. It's a gap, it's an attack surface. How often do your developers have their own environment and it is not really even managed well by IT as a whole? Something there to kind of really consider.

Why Automation Makes It Worse

SPEAKER_01 7:26

So what the NCS says you should do. Okay, so all right, let's get practical because this isn't just an academic exercise, and these are real controls you need to evaluate for yourself, your team, and if you're a CISO or a fractional CISO or a contractor for your organizations that you serve. And I that's one difference between us and everybody else at CISP Cyber Training. We want to give you the tools you need as a security leader to be able to make these changes. So the NCSC outlined five core actions. One, pause automatic dependency updates if you suspect a compromise may be present. Stop, assess, and then proceed deliberately. This is a big deal, right? So, but you're gonna have to suspect that this is a problem. If you suspect it, then work through it. Two, review and approve the new updates manually. Do not let the pipeline decide. Build a review step into your SDLC environment, so your software development lifecycle. Make sure that you have a plan in that. We've talked about that numerous times. You just can't let how the robot take over and run it. You need to have the ability to update it and be able to have an ability to review it. Three, rotate exposed credentials. If there's any chance a token or credential was exposed, rotate it. Do not wait to confirm the breach. And this is an important part. If you don't have a good process in which you can rotate those credentials, you need to build one soon. Just kind of put that into perspective. And then four, enforce MFA on developer and package registry accounts. This is one that should be a non-negotiable. I they they don't like it. They don't, but you need to make sure that you enhance that and that you enforce it. So maintain your account compromise is one of the top attack vectors. MFA dramatically raises the cost that of that attack. It just dragly does. Five, use a private or trusted registries where possible. So if you talk about the interdependencies that are there, they may not have those trusted repositories. So you're gonna need to do some due diligence and you need to begin building your own. Don't pull from the public internet if you can mirror packages internally and vet them first. So again, your own environment. We talk about this with AI a lot as well. Have your own environment built and ready to go. So there's a couple more from the NCSC that I would want to highlight because they're strategic, not just tactical. And we talk about that at CISSP Cyber Training. Tactical is great, but there's a lot of people who can tell you how to do this tactically. We want to focus on the strategic aspects. So first, balancing your patching speed against your dependency update speed. So this is a nuance, but it's an important distinction. You want to patch as fast for vulnerabilities as you possibly can. But you need to slow down and scrutinize when it comes to new dependency versions. So that's just again, think about this. Sometimes you have to slow down to speed up. And it isn't always about how fast you can automate the packages being deployed. There might be times you need to slow that down. I'm not saying don't do the automation. What I'm saying is that just have a good plan on how to deal it, if deal with it if there are dependencies associated. Second, deployment should run through controlled CI CD pipelines, not developer devices. I laugh because I see this happen a lot. There's so many developers that are using their own devices to manage this. You need to make sure that you have a developed CI CD pipeline that will manage that for you. Keep sensitive credentials off developer workstations. That's a supply chain hygiene at the infrastructure level. Again, you can't allow this stuff to happen. It's easy to happen. Why is it easy? Because it's the easier way to do it. And people need to get the jobs done. So what do they do? They put it on their devices. Okay, so an exam tip. So if you're studying for the CISP, here's your takeaway from this episode, right? Supply chain security maps primarily to domain eight, software development security. But expect it to show up in scenario questions tied to domain one, risk management, and domain seven security operations as well. The exam loves to test whether you understand the lifecycle view of risk, that vulnerabilities introduced during development can persist way into production. The exam loves to test you whether you understand the lifecycle view of a risk. The key is that vulnerabilities introduced during development can and will persist all the way into production. You need to know key terms. I mentioned these, CICD pipeline, uh software composition analysis, code signing, and open source risk management. Know what a typosquatting attack is and why automated pipelines amplify supply chain risk. And if you see a question asking what you should do first when a trusted package is suspected of being compromised, the answer is almost certainly stop consuming it and isolate any systems that already have it. Contain first, investigate second. So here's the bottom line Modern software development is incredible. The speed, the collaboration, the open source ecosystem, but that same ecosystem is now a top-tier attack vector. The NCSC is not issuing this guidance because of their board, obviously not, right? Because that's not something they're gonna do. They're issuing it because real actors are actively exploiting the gaps now. And we see this, we talk about it all the time. The supply chain is one of your biggest Achilles heels, right? It's a big challenge you're gonna have to deal with. So if you're a practitioner, take those five action steps back to your team this week. If you're studying for the CISSP, make sure you can explain why CICD pipelines create supply chain risk and what controls belong in a secure SDLC. Okay, so if this part of the episode was helpful, go to head on over to CISSP Cyber Training, right? There's tons of free resources waiting for you there, including a free practice exam, all that stuff. I got gobs of questions. It's all there and available for you. It's pretty awesome. All right, so let's roll into what we're gonna talk about related to supply chains

Five Actions To Reduce Risk

SPEAKER_01 13:13

additionally. All right, so we're gonna start off with a question. As we talked recently about how NCSC manage some of the security, they're recommending that we do updates and that you are constantly watching your supply chain environment. One thing I want to kind of just dig a little bit deeper into this, and so you understand a little bit more around the software development aspects of it, because it isn't it's something that many of the students struggle with, and it's also an area that isn't always talked about because not every organization has a coding environment. So let's get into that just a little bit. So when you think about securing your organization's software, what do you think about? Patching your own code, code reviews, static analysis tools, or maybe even a penetration test once a year. I've done pen tests, they're awesome. But you both based on the compliance aspects, you're like, I gotta do these once a year. So all of those things are important. They all matter. But here's the uncomfortable truth. Most modern applications are not primarily your code. And we kind of talked about this in the article ahead of time. They're a thin layer of your code sitting on top of a massive stack of third-party libraries, open source packages, frameworks, and SDKs. Again, these are all key terms you're going to need to know for the CISSP. So I highly recommend that you kind of think about this from a software development lifecycle standpoint. Software you didn't write, software you probably didn't audit. Guaranteed that happens a lot. And then software you are trusting implicitly every single day. So these are big factors, right? So think about your typical Node.js application. If you write a few hundred lines of code, but you pull back the curtain, you might have had 500, 600, even a thousand packages in your dependency tree. All of those are a risk to your organization. Most of them are transitive, meaning that they didn't even choose them directly. They came as dependencies of the dependencies. So they're like a child of the child. They all come along in the ride of the package. And so you need to know this, and you're going, wait a minute, how is that the case? Because they all are tied into each other. And there's some aspects that you may not have even heard of them, right? You may not have heard of the person who even wrote them. And in some cases, maybe bad cases, the person may even be gone. They may not be around anymore. So again, here's how the CISSP, we put that lens on it. This is a trust problem. And a trust is a concept that runs through the entire CISSP common body of knowledge, right? In domain eight, software development security, we talk about the secure software development lifecycle, the importance of vetting third-party components, and the concepts of software composition analysis. But the real world applications of those concepts is being tested every single day in ways that textbooks haven't even fully caught up with yet. And again, teaching college, I can tell you, the textbooks are way behind. They really are. So the NCSC that they had in the previous uh news cycle advisory is a signal. Supply chain tax are not edge cases anymore, they're a primary attack surface. And if you're going to be a competent security professional, whether you're studying for the CISSP or you're already in the field, you need to understand this deeply. Okay, so you need to truly grasp this understanding. So let me give you some context on why this is accelerating. Modern software development has a fundamentally changed how code is created and shared. And it's changed so much because of the fact that now code can be so easily distributed and created. The open source ecosystem is incredible. It enables developers to build faster, leverage the work of thousands of contributors, and avoid reinventing the wheel, which brings the code to life much quicker than it ever did. But that same openness is exactly what attackers are exploiting. They're looking at that and they're able to know that, hey, all this is available, I can now do something with it. So open publishing models means that almost anyone can publish a package to a public registry like npm or piep I's PyPy or crates.io. Okay, so npm, PyPy, or crates.io, all that stuff can be published. You can publish it to a public registry, and there really isn't a whole lot of oversight into that. So the barrier to entry is essentially Zilch Zero. It doesn't, right? So security controls for maintaining your accounts are not consistently enforced across all registry providers. And because developers are under constant pressure, and because developers are under such pressure to ship fast, dependency hygiene tends to be an afterthought. So the NCSC in that previous article specifically called out three language ecosystems as primary high risk. We talk about Node.js, Python, and Rust. Okay, so let's dig into a little bit though. Not because those languages are inherently insecure. They're not. Nope, they're not. We don't want to start that one, but because they have minimal standard libraries by design. That means the community leans heavily, heavily on third-party packages for even basic functionality. So more packages equals more attack surface. More attack surface equals more opportunity for attackers. So again, they're all there for you. So the exam will, it's kind of a CISSP exam note around this, is that the exam will test your understanding of risk in the context of full software supply chain, not just your own code. Third-party components introduce risks that must be assessed, managed, and monitored as part of your organization's overall risk posture. They're expecting that. If you get certified in any sort of the ISOs or SOCs, they're going to expect that as well. So that's a domain one risk management applied directly to software development context. So how the attacks actually

How Supply Chain Attacks Work

SPEAKER_01 18:54

work. All right, so let's get into the mechanics, just like we talked a little bit before. Because understanding how these attacks work is not just as useful for the exam, it's essential for building defenses that actually hold up. Okay, so we're not just talking about the exam here, but this is an important part of understanding what you need for the CISSP. The NCSC outlined four primary attack methods, driving home the current wave of supply chain compromises. We talked about them briefly in the overall news cycle, but I'm going to dig into them just a little bit deeper right now. So the first one is the maintainer account. So this works by every package in a public registry is maintained by one or more developers. These developers have accounts in registries. So we talked about NPM, Pi, we all those aspects, whoever they are, they have accounts in these registries. They use these accounts to publish new versions of their packages. And the attackers will go after those accounts. Just like they do in an enterprise. They will go after the elevated credentials. They fish those credentials, they exploit reuse passwords, they steal session tokens. All of those things they are doing trying to get access to those specific credentials. Once they're in, they publish a malicious update to the package. The update looks completely legitimate. It looks totally fine. No problems at all. It's coming from a trusted maintainer account, right? Bill, the trusted maintainer. It has the same package name. It follows the same version number. All of that is good. There's no obvious red flag. However, there's something embedded within that code. And then every organization that has automatic dependency updates enabled, which most of them do, pulls that malicious version the next time their CICD pipeline runs, pulls it right in. And then guess what? Ha ha, bada boom, bada bing. They are in play. So the code executes and the attacker is in. So they're going after the supply chain. So I'm trying to break all this down and understand that it's an important part of any development environment. So one of the other things that the NCSC pulled out specifically is that attackers are using credentials and tokens stolen from previous attacks, right? Or access modified additional packages. One compromise account can become the foothold for a cascade, a contoffity of compromises. So it can happen, right? And that's an important part. So now the CISSP connection to this is to be domain five, your IAM, which is your identity and access management. This is an identity and access management applied to the software supply chain. It's not about your corporate users, it's about the developer accounts on external platforms. So if you have developers of any kind and they are working with external platforms, this is the issue that they might be dealing with. The same IAM principles apply. MFA on package registry accounts is not optional. It's a fundamental control. This is a very subtle one and it is nasty, right? The package maintainers often register. Their accounts using email addresses tied to custom domains. So your company domain, maybe they have their own domain. Maybe it's their personal SeanGuerber.com domain. Whether it's their personal website or maybe it's a startup they worked at, they set that up. And I'll give you an interesting part on that is I still have my the credentials I had were tied to my domain when I was with my previous company. And those credentials have gone away. But are they still there? Maybe. I don't know. So over time, these domains expire. They move on, they forget about it, right? We forget about all kinds of things. I forgot about what I ate yesterday. So that attackers monitor are for looking for expired domains linked to active package maintainers. When the domain becomes available, they register it. They now control the email addresses associated with it. So the domain goes away. Now they control the emails. They use his account for recovery flows to take ownership of the maintainer's registry account. And now they own a legitimate, trusted package without ever compromising a password. Again, this happens too frequently for any of us to really see. It's just amazing. So this is insidious because there's no breach event to detect. The attacker has full legitimate control. Every downstream organization pulling that package is at risk, and there's no way of knowing it. None. You won't even know it till after the fact has occurred. So this is where you get into domain seven of SecOps for the CISSP. This maps to a third-party and supply chain risk management. Organizations cannot assume the packages they trusted six months ago are still trustworthy today. Developers I've been working with in previous jobs, they have that same challenge that they think, well, it's in GitHub, it's good. No, you can't go with that attitude. You really can't. So continuous monitoring of your dependency ecosystem is a security operations function, not a one-time assessment. So once it's done, no, it's not. Now the other attack type we talked about was typosquatting. This is one is a little bit more straightforward, and we it's widely effective. Widely or wildly effective, uh, especially at scale. Attackers will register package names. They're almost identical to the popular name of the package. So, like for example, you may have sean gerber.com. Well, they may go, or not.com, just Sean Gerber as the name of the package. And you may have instead of Sean S-H-O-N, they do Sean, S-H-O-M, Gerber, right? So that would be an easy miss, Shom versus Sean, because it happens all the time. I mistype my name sometimes and become Shom. It's really hard to confuse people when they go, it's Shawn here. And I know Shom, there's no Shom. So again, one later transpose, a common misspelling, a different separator character, all of those are the factors. So the target is a developer error. Somebody types fast in their terminal, they install the wrong package, it executes on installation. Because Node.js and Python both support install scripts that run automatically when a package is installed. No prompt, no warning, no human approval required, right? By the time anyone notices, the malicious code is already running and in your environment saying, thank you, may I have another. So the CISSP connection, right, we're dealing with domains one and domain eight. This is a social engineering attack. It exploits human error rather than technical vulnerabilities. But it defense is technical. Private registries, allow lists of approved packages, and automated scanning with SCA tools. An important part of any organization, you need to have these software composition analysis tools. So know the defensive controls. The exam tests your ability to identify the right countermeasure, not just name the attack. Attack type four, credential chaining. So this last tap talked about a force multiplier for everything, right? Attackers use tokens and credentials stolen from one compromise account to move laterally across other packages and registries. It's an important thing that they do. So think about it like this the developer might maintain five different packages. Their credentials for all five live in the same place. Maybe a CICD secret store, maybe their local environment, bad idea. Maybe that's the case, but they compromise one and you potentially have access to all five. So each of these packages has its own downstream user base. The blast radius expands exponentially. It goes extremely quick. It moves super fast, right? So you need to really understand how you're going to deal with this. So as a CISSP, what are some things that you can think about? Defense in depth is important. Credential isolation, secrets management, and the principle of least privilege. They are not just for not just corporate IT assets, but for everything. So they apply everywhere developers interact with external systems. If your developers are storing credentials in plain text on their workstations, that's a risk to your organization is carrying. So again, I tell you, don't let them store it on their credentials on their organizational devices. The next one is a CI CD pipeline where automation becomes a liability.

CI/CD Pipeline As Attack Multiplier

SPEAKER_01 27:04

So we talk about this all the time at CIC Cyber Training is that CI CD pipelines are awesome. They're incredible, but they also can be a challenge, right? So the NCIC gave this particular attention and it deserves it. CI CD pipelines are one of the great innovations of modern software development. They work awesome. They create this great environment for you. They automate, they build, they test, and they deploy code without you having to go through all the steps. So I've worked with teams that have not used a CI CD pipeline, and it's very clunky and cluey and very painful. I've worked with teams that are very good at it, and man, they push to code super fast, and everything works like a champ. So they let their team ship code faster and more reliable, and they have fewer manual errors. But here's a security problem, right? The CICD pipeline runs with elevated privileges. They have to access production environments, secrets and signing keys, and deployment infrastructure. All of that has to be done. So, and by design, they operate automatically, or I like to say automagically. They do, often without human review at each and every step. So the NCSC warnings that attackers are actively exploiting because they implicit trust. They're baked into these pipelines. Trust is there automatically. So when a pipeline is configured to automatically pull the latest version of every dependency and execute it, the automation becomes a liability the moment one of those dependencies is compromised. So here's a grill scenario to make this a little bit more concrete. Your pipeline runs at 2 a.m. It pulls the latest version of a popular utility package down, right? At 2 a.m. Everybody's sleeping. That version was pushed four hours ago by an attacker who compromised the maintainer's account. So now they have something in your system that was automatically pulled into your environment. The install scripts execute, right? Because it's Python. They exfiltrate your CICD environment variables, which happen to include your AWS access keys. Oh no. By morning, your production environment is compromised. Your pipeline logs show nothing unusual. A legitimate package was installed, everything looks fine, but this is not hypothetical. Variants of this attack have happened to real organizations all over the globe. And you want to have wake up and have a problem. That is when your head starts spinning and you're going, oh my gosh, what are we going to do? Right. So, domain eight, know your CICD security concepts. Security management is built into your environments. Separation of build and deployment environments, very important. Code signing and artifact integrity verification is extremely important for you if you have a development team. Also know this developer environments are weak, the weak point. Developer workstations typically have fewer security controls because they need to run as admin, they need to run all these different kinds of things than the managed corporate endpoints and because they're special. I mean, I'm not bagging developers by any means, but they are. They're special. They have to make this stuff work. So a lot of times because they're in the process of making it, their specialness becomes a problem. That's your risk security program needs to account for. You need to play for this. Now, we talk about the recommended controls of the NCSC. Let's just kind of get into those. We spent a lot of time understanding the problem. Now let's get into what you can actually do about it. So NCSC, this article laid out a clear set of recommended actions. And I'm going to walk you through each one and give you the practitioner perspective and the CISSP angle on this. So, pause automatic dependency updates. When a compromise is suspected, this sounds obvious, but is not always operationally easy. Most development teams have automatic updates enabled because they manually depend management is tedious. But the NCSC is saying when you have a reason to suspect a package may be compromised, you stop the automation and go manual. So you need to document and process this before you need it. I cannot stress this enough. Documentation is everything. You need it before you need the problem. This is a run book item. Write it down, right? You need to have a plan for it. Domain seven, incident response. Pausing the automatic updates when a compromise is suspected is a containment action, not a remediation action. The goal is to stop the spread while you investigate. Okay, again, you want to contain this as best you can. Control review and approve new updates manually. So the NCSC is advocating for human in the loop approach, a dependency management, or at least for critical packages. This doesn't mean you review every minor package. That's not operational or realistic, but it means establishing the process where someone with security awareness is making a conscious decision about what enters your dependency tree. Practically, it looks like this: a list of approved packages, a private registry to mirror and vet packages before they reach your build environment. A change management process for adding new dependencies. So again, domain seven, domain eight, this is kind of a CISSP exam note around this. Change management applies to your dependencies, not just your own code. The exam will test this understanding. Control three, rotate exposed credentials immediately. When you have any indication that a credential may have been exposed, or even suspicion, you need to rotate it. Do not wait for confirmation. The cost of rotating a credential is low. The cost of a confirmed breach, yeah, that's huge. It's catastrophic. It's monstrous. This applies to API tokens, registry credentials, CICD secrets, cloud access keys, any credential living in your development environment. So here's a CISSP exam note. Domain three and five. Know the principle when doubt, when in doubt, rotate. The exam loves scenario questions where the right answer is the conservative security first choice. Control four, enforce MFA on developer and registry accounts. So I said this earlier and I'll say it again. This is non-negotiable. Maintain your account compromise is one of the top attack vectors in all supply chain attacks. So multi-factor authentication dramatically raises the cost of that attack. Fish passwords become useless. Session token theft becomes harder to leverage. The challenge: not all registry providers enforce MFA. That means you cannot rely on the platform to require it. Your organization needs to require it as a policy. You need to verify compliance. So when you're dealing with domain, domain five and the IEM, no MFA is a compensating control for credential theft. We talk about this all the time at CISSP Cyber Training. It is. It's a compensating control related to that. Know that policy enforcement is a management control, not a technical one. Policies, management, right? That distinction matters on the exam. Control five, use private or trusted registries. So rather than pulling directly from a public registry like NPM or P or PiPy, that then you want to have a mirror that approves your packages in a private registry that you control. This gives you the ability to vet packages before they reach your build environment. So lock to specific approved versions. Prevent typosquatting by limiting what packages can be resolved. So this kind of falls into domain eight of the CISSP. This is a technical control supporting least privilege. This is applied to your software supply chain. Your build environment should have only access to packages you have approved, and you have a process in place to approve those packages. So everything outside that perimeter should be blocked by default. Now, is this stuff that's going to happen overnight? No, it's going to take time to do it. But these are key steps that you're going to need to be aware of. That defense in depth is applied to the dependency ecosystem altogether. Okay, so two more controls to deal with. Balance patch speed against dependency update speed. These are not the same thing. Security vulnerabilities in packages you use patch fast. New non-security version released, slow down. Okay, review it first. So vulnerabilities, go for it. Non-security versions, hey, you just need to update this. Don't do that right away. Review it first before you do it. Deployment should happen through controlled CICD pipelines, not from developer workstations directly. Again, take yourself out of it as a developer. If the developers can push to production from their laptops, you have an uncontrolled channel that bypasses your pipeline security controls. Lock that down, right? Get rid of that. Building supply chain security into your SDLC.

Building Secure SDLC And SBOM

SPEAKER_01 35:29

Look, let's zoom out and talk about how this is all fits into the SDLC environment. Because supply chain security isn't a bolt-on, it needs to be embedded in how your organization develops software from the very beginning. So the design phase, before you write a line of code, ask what dependencies does this application need? Can we use well-maintained, widely adopted packages? Are there packages we can eliminate entirely? That is usually one of the things that happens. People are hoarders, they keep stuff forever. How do you eliminate it? Are there low risk alternatives out there? This is a threat modeling applied to your dependency choices, not just your application architecture. So in the development phase, as code is written and dependencies are added, you need tooling. Software composition analysis tools, SCA, your dependency tree, and flag. Packages with known vulnerabilities, license issues, suspicious characteristics, tools like SNEC and OWASP dependency check can integrate directly into your IDE or your pipeline and catch problems before they reach production. In the build phase in your CICD pipeline, you need to our artifact integrity verification. Code signing ensures what comes out of your build is exactly that went in. Checksum verification ensures packages downloaded during the build match what you expected. Checksums are an important part of any development environment. These are technical controls that catch tampering. They truly do. Deployment phase, ensure that production deployments only happen through your controlled pipeline. With full audit logging, what is deployed, when is it deployed, by what processes, and from what source is it deployed as well. Monitoring phase, post-deployment, you need continuous visibility into what packages are running in your production environment. The threat landscape changes. A package that was clean last week may be a compromised one today. Your software asset inventory needs to include your dependencies and it needs to be kept current completely. So here's a CISSP exam takeaway. CISSP tests your ability to select the right control for a specific right phase of the SDLC. So you need to know where the lifecycle supply chain risks are introduced and where they most effectively are mitigated. The earlier you catch a problem, the cheaper it is to fix. That's a core CISSP principle, guys. That you catch the problem early, it saves you time, energy, and money. So what should you do now? So this means basically there's three things you need to focus on at this moment. Inventory. You cannot manage what you do not know about. Do you have a complete software build of materials, SBOM, for every application in production? The SBOM is a machine readable inventory of all components in a piece of software. The U.S. government now requires SBOMs for software sold to federal agencies. If you're trying to get certified in CMMC, SBOM's an important part. If your organization doesn't have SBOMs for critical applications, that's a gap worth closing. Assessment, how are you evaluating the security posture of the open source components you depend upon? Do maintainers follow secure development practices? Do they have vulnerability disclosure programs? Is the project actively maintained? These are vendor risk assessment questions apply to open source software. They belong in your risk and management program. Monitoring. Risk isn't static. A package that was safe when you added it may become risky over time because a maintainer left, because a project's abandoned, because a vulnerability was discovered. Continuous monitoring of your dependency ecosystem is a security operations function that needs to be resourced and owned. And then response. When a supply chain incident occurs, and it will, I guarantee you, what is your response plan? Can you quickly identify all applications using compromised packages? Can you push an emergency update through your pipeline and verify its success within hours? These are incident response capabilities that supply chain attacks specifically require. So for the CISOs in the room, for the folks that are in strategic positions within your organization, this is a conversation you need to be having with your boards and your executive teams. Supply chain risk is an enterprise risk. The SolarWinds attacks of 2020 compromise thousands of organizations, including U.S. government agencies, not because if any of them had bad security programs, but because they trusted a vendor update process. The next SolarWinds is out there. Your job is to make sure your organization is resilient as possible when it happens.

Final Tips And Resources

SPEAKER_01 40:04

Okay, so that's all I've got for you today. I hope you guys get a lot out of this. Again, talked about supply chain, software development, the importance of it. All of those are aspects that you need to be aware of. I want to quick give you a side note just real quickly at CISSP Cyber Training. We will not be doing, I'm not going to be putting out two podcasts a week. I'm basically making some changes. We'll be still putting out one on Monday, but they're not going to be putting out podcasts on Thursday. I'm trying to consolidate the training to make it a little bit more effective in that regard. When it comes to CISSP questions, going through the questions are important. However, the content itself will help you with the question. If you focus on the overall content and what you need to do and what changes you need to do, that will help with the question specifically. Studying and memorizing a question isn't going to cut it. You gonna have to know the content to be able to stay and study for the exam. Okay, so that's all I've got for you today. I hope you all have a blessed day and we will catch you all on the flip side. See ya. Thanks so much for joining me today on my podcast. If you like what you heard, please leave a review on iTunes as I would greatly appreciate your feedback. Also, check out my videos that are on YouTube and just head to my channel at CISSP Cyber Training, and you will find a plethora or a conocopia of content to help you pass the CISSP exam the first time. Lastly, head to CISSP Cyber Training and sign up for 360 free CISSP questions to help you in your CISSP journey. Thanks again for listening.