CCT 366: Software Supply Chain Security Explained — CISSP Domain 8 (ChainDrop Case Study)

A supply chain attack that leaves your Git history spotless should change how you think about “secure code.” We walk through ChainDrop, a worm discovered in the NPM ecosystem that poisoned 444 packages while evading the places defenders usually look. The unnerving twist is that it can trigger without a classic npm install and can hide in the space between your repository and the package archive your CI/CD pipeline actually pulls, which is exactly why code review alone can’t be your finish line.

From there, we tie the real-world scenario directly to CISSP Domain 8 Software Development Security and the secure SDLC. I lay out a clear, exam-friendly framework for assessing third-party and acquired software risk: Software Composition Analysis (SCA), Software Bill of Materials (SBOM), vendor and publisher risk assessment, and runtime plus pipeline controls. We talk about why SCA is necessary but incomplete, how a living SBOM enables fast exposure checks when a new campaign hits, and why Executive Order 14028 is pushing SBOM adoption into “expected” territory for many organisations.

We also get practical about CI/CD pipeline security: dependency pinning, trusted publishing workflows, signed commits, OIDC, and package signing and verification approaches like Sigstore and Cosign. Finally, we run through scenario-based practice questions that highlight common CISSP traps and the manager mindset the exam rewards. If you want more episodes like this, subscribe, share it with a developer or security lead, and leave a quick review so more CISSP candidates 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 Domain 8 Setup

SPEAKER_00 0:00

Welcome to the CISSP Cyber Training 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 Pack 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:25

Good morning everybody. It's Sean Gerber with CISSP Cyber Training and hope you all are having a beautifully blessed day today. Today's Monday, and we're going to be getting into domain eight of the CISSP exam related to software development and the software development lifecycle. So, yes, a lot of great things coming to you today, and I'm sure you're extremely excited to get involved with this. But it's a great, great segue into some areas that we're going to be dealing with, especially related to the CISSP exam. One of the primary things that people struggle with on the CISSP is software development. And this is a great factor and a great segue into that. Well, I hope you all had did have a great weekend this weekend. For us, it was a very busy one, and we uh stayed on the road with our Kona Ice franchise and Traveling Tom's Coffee, so it was very busy there. And then I did a little bit of consulting stuff. So life has been happening. It's a thousand degrees in Wichita, Kansas this week. So a lot of people are just staying inside because it's just too bloody hot. So wherever you are at, I hope that it is cool and it's wonderful. Uh it probably is kind of warm. I don't know because it's just it's getting bad. But that's all right. Fall is almost here. So we're pretty excited about that. But let's get into domain

ChainDrop Hits The NPM Ecosystem

SPEAKER_01 1:38

eight. This is talking about the chain drop worm crawls into NPM, November Papa Mic supply chain, and evades standard defenses. Okay, so some of the stuff you might be dealing with, you might go, well, I don't really know what this is. On August 4th, 2026, security researchers found something very ugly buried inside NPM. That's November Papa Mic. This is the package repository that basically every JavaScript application on the planet depends upon. So is this issue that came up is called ChainDrop. Now it's a variant of a worm named Shahal Huluhead. Yes. It's the sandworm that's on Dune. I don't know how to say it, but it's Shahalhuluheed. And by the time anyone actually caught what happened, it had already poisoned 444 packages. Packages such as Ki V, Flat Cash, and Cash Manager. Now, deep infrastructure dependencies, these all have within any organization, especially as you're dealing with this overall MPM aspect. So combined, these packages get downloaded about two billion times a month. So again, two billion. This is a lot every single month. Now here's the part that should bother every security professional watching this, especially if you have a software development key or software development team. ChainDrop doesn't spread the way that we are trained to look for it. It doesn't need you to run an NPM install. Once it is triggered, it drops startup hooks straight into your repository's configuration files. So simply opening an infected branch in VS Code or in AI coding tools like Claude Code can silently hand control of your repo to the attacker. So this is very, very challenging. I mean, I've been dealing with a bunch of software development folks. This is a big one. This is a pretty scary one. And when it self-replicates, it doesn't touch your source commits at all. It rebuilds the tarball. The package archive. This is what the tarball is, and it slips its payload in there. You can audit your Git history all day and find nothing wrong because the evidence isn't in the code you are reviewing. It's in the package you're downloading. That's not a story about one NPM worm. That's a story about a hole in how we think about software supply chain risk, which we've talked about numerous times here on CISSP Cyber Training. And that hole is exactly what CISSP Domain 8, Software Development Security, is built to help you close. So let's talk about how to deal with this.

Why Supply Chain Is Perimeter

SPEAKER_01 4:10

So why the supply chain is the new perimeter? We've talked about this over and over again. For 20 years, security programs poured resources into the perimeter firewalls, endpoints, detection, network segmentation, and it's still very, very important. But the most modern applications aren't built from scratch, they are assembled. A typical enterprise code base is 70 to 90% third-party and open source components, all glued together by a small percentage of code your own developers actually wrote. So again, it's tied together with bits and pieces. I used to say growing up in a small farm in Iowa with baling wire and duct tape. And that's kind of how it is, right? So that means your attack surface isn't your code. It's every dependency, every library, every CICD plugin, every publisher account with the right access to a package you rely on. So ChainDrop exploded exactly that. It went after developer credentials, npm tokens, cloud keys, GitHub secrets, sitting in shell configs, environmental variables, even live memory. Then it uses credentials to compromise a supply chain from inside by bypassing every repository controls that we specifically count on and need. So for the exam and for your job, remember this supply chain risk isn't a subset of application security. It is application security now. So domain eight asks you to evaluate the security of software throughout this entire life cycle. And increasingly, most of that life cycle happens outside your organization's walls in code you didn't write and can't fully see. And that is so true in today's coding world.

Four Pillars To Assess Risk

SPEAKER_01 5:52

So let's get into a framework for assessing third-party and acquired software. So how do you actually assess the risk in a way that holds up whether you're preparing for the exam or building a program at work? Well, there are four pillars. One, software composition analysis or SCA. You cannot secure what you cannot see. SCA tooling scans your code base and the dependency tree associated with it. It identifies every third-party component and flags known vulnerabilities against the database, like the National Vulnerability Database. This is a table stakes now. But Chain Drop is a reminder that SCA tools scan source, and this worm specifically avoided leaving evidence in source. Which brings us to pillar two. The software bill of materials. We've talked about this on CICP Cyber Training, S-BOMs, right? They're a big challenge with many different types of organizations and many different software. So an SBOM is a formal machine readable inventory of every component in your software. Direct and transitive dependencies, versions, publishers, and the licenses that are associated with it. So when a researcher published a list of every package chain drop compromised, organizations with an accurate SBOM, so that's if you had that and you were watching it, could check within minutes of where they're at. Organizations without one had to go hunting. For the exam, SBOM is increasingly tied to secure acquisition and supply chain risk management, the standards and federal guidance under Executive Order 1420 or 028. This is published that SBOM from nice to have towards expected, basically saying that you have to have your SBOMs no matter what. You need to be able to do that, especially if you're dealing with federal types of activities. So three, the vendor publisher risk assessment. This is an acquired software side of domain eight. Before you bring a third-party component or acquired software from outside vendor into your organization, you must assess it. Their security software development practices, their patch history, and their incident response track record. And then finally, how they protect their publishing credentials. A vendor with weak internal controls becomes your weak internal control the moment you depend upon it. So you need to make sure that you have those proverbial ducks in a row. And then fourth, runtime and pipeline controls, not just point-in-time reviews. So you need to understand your pipeline and then what goes into it. This is the lesson Chaindrop teaches the hardest. A one-time code review or a vendor questionnaire at onboarding isn't enough. Because the NPM was so deeply wired into your CI CD pipelines, that auto pull patch updates on every rebuild. So every time they rebuild it's pulling it back, that means the package can be clean on Monday and poisoned by Wednesday. And your pipeline will be happy because it got rebuilt. No problem. It says it's rebuilt into production without any human ever looking at it again because you did it at the beginning. Trusted publishing workflows, signed commits, and pin dependency versions all exist to put a control in the gap. So

Turning Pillars Into Daily Practice

SPEAKER_01 8:55

putting this into practice, make let's make this kind of a concrete thought process that you're dealing with. If you're the security lead responsible for this risk, here is what working program actually does for you. You maintain a living SBOM, not a static one, one that is actually growing, and then when people with software gets taken off, it is removed, right? It's regenerated with every build, not once a year during the audit. You treat the repository supplied configurations as executable content, because that's exactly what it is now. You also extend that scrutiny to every branch, not just the main, because that's where the attackers plant the hooks, betting it nobody is actually watching. So you evaluate your trusted publishing and CICD tooling the same way you would evaluate a vendor. Because a compromised GitHub action or compromised MPM token is the same blast radius as a compromised vendor relationship. And you build detection for the gap between the scanned and the executed. The space between your SCA tool checked and what your pipeline actually ran, that's the gap ChainDrop lived in. And it's likely won't be the last campaign to find it. So as you're studying for the CISSP, here is your takeaway. Domain eight exam questions on this topic aren't testing whether you can name the tool. They're testing whether you understand that software security is a life cycle problem, spanning acquisition, development, integration, and ongoing operations. And that third party and open source risk has to be managed with the same rigor and risk as your code that your entire team wrote. Now, if you're doing this job on a day-to-day basis, your takeaway is much simpler. Your dependency tree is now part of your threat model. Your CICD pipeline is now part of your attack surface. And we scan the source code is no longer a complete answer. And the examiners are not going to be asking you a question of going, oh, okay, we're good. They're going to be asking you, what did you do? And are you aware of this risk? Chain drop won't be the last supply chain worrym we talk about. Because as long as software is assembled instead of written from scratch, this is where the pressure will keep landing. So that's an important part. If you are studying for your CISSP, domain eight is an important part. And I guarantee you, even though the valuation from a percentage standpoint isn't the same as the more the larger ones, such as domain one, it carries a lot of weight. So if you are interested and want a structured practice setup specifically for you, go check out my CISSP Sprint program. You'll see that you can go, we're going to go get into some different training related to the S bombs here in just a minute. But go check out CISSP Cyber Training. I've got a lot of great things for you. I've got my CISSP Sprint. It is filling up quick. And if you're looking to take your CISSP within the next eight weeks, you know what? My next class starts on September 8th. And we go for eight weeks. And at the end of that eight weeks, you are going to be in a great position to pass the CISSP the first time. I mean it, it's a cohort that's set up to teach you step by step on everything you need. And I will tell you completely there is stuff in there that is going to be blow your mind to tell you on how you should be prepared for the exam. There's a diagnostic assessment, and that diagnostic assessment is going to help you understand where are your weak points. It's also got I've got weekly and daily exam questions that you can ask on top of all the training that's available to you. You're going to have videos, you'll have all of that stuff will be already for you. So it's incredible. Go check it out. CISSP Cyber Training, my CISSP Sprint Cohort, and spots are filling up extremely quick. My early bird pricing ends August 29th. You got 13 days, and I guarantee you it will fill up before August 29th. No question about it, because it's our the first one went extremely fast. This one will go even faster. Okay, so let's roll into what we're gonna talk about today. Okay, so as you all know, that have been tied to CISSP cyber training, if you've been listening to the podcast for any period of time, the first part of the episode we talk about the security risk that was discovered. And the second part is a little bit more related to the training that you could expect to see to help you pass the CISSP. And today we're gonna be covering domain eight, software development security, through the lens of this attack that we saw related to the MPM ecosystem and chain drop. So we're going to use it as our opening case study, and then we're gonna build out the full framework you need for assessing third-party and acquired software risk. And this is an important part. So this is gonna help you one with your job, but it's also gonna help you with getting understanding the manager mindset for the CISSP exam. So that framework is what the exam is actually gonna be testing you, and that's what you'll be applying for on the job. Because again, the great part about CISP cyber training is the things you have here, if you listen to this information, it's gonna help you specifically with your job as well as passing the test. I also highly recommend that if you are a current CISSP, sign up for my CPE Insider. That's do you have to sign up for CPEs related to the CISSP. If you sign up for my CPE insider, you can get all of this information. So all you have to do is copy, paste, and submit your CPEs to ISC Squared just by listening to the podcast. Makes it much, much easier. And we can go into that at a later time, but go check it out. Okay,

ChainDrop Steps And How It Spreads

SPEAKER_01 14:00

so let's start with the numbers. On August 4th, 2026, a variant called the Shahud Halahood. Yeah, that thing, off of Dune, their worm, right? Nicknamed Chaindrop was found to have poisoned 444 NPM packages. Those packages are collectively downloaded about two billion times a month. We know that is a lot. And here's the number that should really get your attention. There was no evidence left, right, in these source commits. So the standard code review found nothing wrong because the attack didn't live where the code review looks. So how does this actually work? Well, there's a four steps. Step one, it harvests the credentials, it scans the shells, the environment variables, and even the live memory for any NPM, November Papa Mic tokens, cloud keys, and GitHub secrets. So step two, it then rebuilds the tarball, downloading every package that stolen token can access. So the creds that are there, it tries to download all of those and then injects its payload and then republishes it. The source repo still looks completely clean, and then therefore, step three, it commits the malicious configuration directly into GitHub. Files like .vscode slash task dot JSON are all pushed into every reachable branch. And then step four, it triggers on the open. So when they open it, the next developer that opens that branch in an IDE or in the AI coding tool, the hook fires and the whole cycle starts all over again. This is a closed loop. Every new developer who opens the branch reharvests credentials for the next round. So this is a pretty big deal, guys. It's a huge deal. So the question is if you you need to go talk to your software development teams and make sure that they understand this risk. And if it isn't in your CITD pipeline, you need to make sure you have security tools, and which we'll get into that will help you with this situation.

SolarWinds And Log4Shell Parallels

SPEAKER_01 15:50

So the pattern isn't new. To be clear, this is not a one-off. In 2020, attackers compromised SolarWinds, owned build system, and slipped a backdoor into signed software updates, reaching about 18,000 organizations, including multiple federal agencies. In 2021, Log4 Shell, a critical flaw, and Log4J, which we all dealt with, logging library became one of the most widespread vulnerabilities ever disclosed. Because that library was buried inside millions of applications, no one even realized we're using it. Different mechanism every time, but the same lesson. The dependency you trust is an attack surface. And the longer you think of this, is that, you know, I got I got all these third parties that I rely on outside of just coding. They're all an attack surface. So you really need to be prepared for this situation. So, like we talked about earlier, and we've talked about many times on this podcast, the supply chain is the new perimeter. So why does this matter so much for domain eight? Because a typical enterprise code base is about 70 to 90% third-party or open source code. Dealt with this all the time, especially my last consulting in gig, that they dealt a lot with open source code. Now, they also did a lot of stuff they developed on their own, but because of the interdependencies, they're all embedded. So that flips the script on the old security model on its head. The old model was secure your perimeter, firewalls, endpoints, all these things. Network segmentation is the important part. The current reality is that most breaches now enter through a trusted dependency, a publisher credential, or a pipeline plugin. Yeah, they're all there, right? That's exactly why domain eight scope is so broad. It spans acquisition, development, integration, and the ongoing operation. And most of all of that happens now outside of your organization's walls because of all the development work that is occurring. So here is the four-pillared

Exam Focus On Lifecycle Thinking

SPEAKER_01 17:43

framework. Four pillars for assessing third-party and acquired software risk. One, software composition analysis, two, software bill of materials, or we commonly refer to as the SBOM. Three, vendors and publisher risk assessments, and then the fourth one is runtime and pipeline controls. So let's go through each one because the exam loves to test gaps between them. Pillar one, SCA. So this scans your code base and your dependency tree. It matches components against known vulnerability sources such as the National Vulnerability Database and flags anything already disclosed. Tools such as Sneak, OWASP's dependency checker, mend all live in this space. It's necessary, it's required, you need to have it. But this is the exam's favorite trap. SCA alone is not a complete supply chain answer. SCA only catches what has already been reported to a vulnerability database. If it hasn't been reported, there's nothing there. It has no visibility into something that hasn't been flagged. Chain drops payload spread through tarball rebuilds, and IDE triggered config hooks. Mechanisms known for CVE scans simply doesn't look at this, and this brand new campaign, a signature-based tool hasn't yet seen, will not be flagged to the MVD. So this is exactly why three the next three pillars exist not as backups for SCA, but as coverage for what SEA actually cannot see. Pillar two is SBOM. If you can't inventory it, you can't defend it. An SBOM is a machine readable record of every component, version, and publisher in your environment. Here's why it mattered in Chain Drop. Once researchers publish the full list of all four hundred and forty-four compromised packages with their version numbers, then organizations can accurately check their SBOM to ensure they have it to see what kind of exposure they may have. Organizations without one had to go hunting branch by branch by branch. And this isn't just the best practice anymore. The U.S. Executive Order 14028 has published S bombs from optional towards expected. Common tooling here requires such as SIFT, Cyclone DX, and SPDX. Pillar three is vendor and acquired software risk. The core idea of this is a vendor's weak internal controls become your weak internal controls the moment you depend on their code. And we talk about this all the time, and we see it all the time. Four things to evaluate: their secure development practices, their patch and disclosure history, and their incident response track record, and then finally how they protect their own publishing credentials. Basically, to operationalize this, you need to look at a standard information gathering questionnaire. What do you have specifically to gather this information? Now you need to, I know it's a challenge because there's so it's so hard to get with people on this information to get it for you, but you need to make sure you have a questionnaire that is set up specifically for you and your organization and do your best to get that taken care of before you publish stuff to your production environment. Pillar four is runtime and pipeline controls, and this is the lesson ChainDrop teaches the hardest. A point-in-time review isn't enough when CICD auto-pulls patch updates on every rebuild. Picture the timeline. Monday, a dependency scans clean. Wednesday, that same dependency is compromised upstream. By the time the next rebuild, the pipeline pulls it automatically. No human review anywhere is in that loop. The control that closes this gap, a trusted publishing workflow such as GitHub Actions, OIDC, signed commits, and package signing through tools such as Sigstore or Cosign as an important part of this whole process. Using something like Dependbot or Renovate required or configured correctly will also help you in this situation. So it's an important part that you need to think about when you're doing this from your CI CD environment. So what does this look like day to day? Let's make this concrete. A working program does five things. It maintains a living SBOM, regenerated with every single build, not once a year. It treats repository supply configuration as executable content, not passive formatting. It reviews every branch for unfamiliar hooks or configs, not just the main branch. That's a big one. That gets a lot of people. They don't look at every branch, they just look at the main branch and say, oh, we're done, we're good. It evaluates the CI CD tooling and publishing workflows the same way it would evaluate a vendor. And it Monitors continuously for the gap between what is scanned and what is actually ran. That's rigor applied continuously, not something applied only once. So, what is domain eight actually testing you? It's not whether you can name a scanning tool. We talked about this earlier. It's whether you understand the software security as a lifecycle problem. And this NPM chain drop situation just highlights that even more. Acquisition, development, integration, and ongoing operations all carry risk. And most of that life cycle now happens outside your organization. And third-party and open source components have to be managed with the same rigor of code that your own team specifically wrote. So we scan the source code, it's no longer a complete answer. It truly isn't. I hear it a lot. We scanned it. It's okay. It's all good. Yeah, no, it's not good. It's just not. So let's roll into some practice questions.

Practice Questions And Common Traps

SPEAKER_01 22:50

All right, so there are four scenario questions that are all built around what we just covered: SBOM versus SCA, vendor risk, configure because code, and pipeline controls. So we're going to go through each of these questions and then the trap that's built into each one of them. All right, so question one. A CISO wants to know within minutes whether an application in the portfolio uses one of the 440 per packages compromised in the chain drop campaign. Before the vulnerability database that scanning tools rely on has been updated, which capability makes this possible? A software composition analysis. B a web application firewall rule update. C an accurate, up-to-date software build of materials, or a a quarterly risk risk, a vendor risk questionnaire. Okay, so let's kind of think through what are they asking for here? And again, we've kind of talked about this. You guys are going to probably know the answer just by listening to it. But the big factor in all of this is the fact that you want to make sure that you have these aspects in place. So the answer is, of course, C. Right. We're looking at an accurate, up-to-date software bill of materials. So we talked about the SBOM and how important the SBOM is to your organization. You need to make sure that you have that in place. So again, the trap in this is that SCA sounds right because it deals with composition. But SCA checks code against known vulnerability databases at scan time. A brand new worm often isn't catalog yet. So SCA alone will and can miss it. So the SBOM SBOM is what lets you search instantly when you get word that something actually has occurred. Okay, so why is SCA alone? We talked about how that one doesn't really work. The WAF update rule, firewall network filters have no visibility into what packages are embedded into your code base. So that one's just throw that out the window. And then your vendor questionnaire. It is a point-in-time paperwork exercise. Again, this is something that's important you have to do, but it's not something that's going to find out your code issues that you have. All right, so next question An organization approved a SAS vendor after one-time due diligence review at procurement. Yay! A security questionnaire and SOC to report. That's what they want, right? It's important. Eight months later, a dependency that a vendor relies on is compromised and auto-deployed through the vendor's own pipeline. Oh no. What control gap does this best illustrate? A an absence of continuous monitoring beyond one-time point in point-in-time vendor assessments. B a failure to enforce lease privilege on vendor accounts. C, lack of non-disclosure agreement with the vendor, or D. Insufficient encryption of data at rest. Okay, so an organization approves SaaS vendor after a one-time due diligence review at procurement. Security question is questionnaire and the SOC 2 report are been done, right? So they got that. Eight months later, again, fast forward from the point in time ex point in time exercise with SOC 2, and now we have a control gap. Which one is it? And the answer is A. Of course, absence of control monitoring beyond the one time, point-in-time vendor assessment. There's a lot of times there. But it is, right? So we talk about a vendor assessment, which are great. They are awesome and they have to be done, but they are a point-in-time situation, and they are not going to be relying upon you for that. So the least privilege is a real supply chain control, which makes it tempting. So as we get into the different kinds of scenarios, that's one you might bite off on. But it treats the specific system, the symptom, the blast radius specifically, rather than the root cause that nobody is watching, or basically after that at all. So least privilege, again, we talked about that. Missing NDAs. NDAs protect confidential information. It does nothing to detect or prevent a technical supply chain compromise. D, an encryption at rest. This protects stored data from unauthorized reading, obviously, but it's irrelevant to a pipeline pushing a compromised update. So those are the reasons that those answers are wrong. Next question A developer opens a Git branch in VS Code. No NPM install is ever run, and the full code review of every commit finds nothing suspicious. Oh, I wonder why. Credentials are harvested anyway, which principle explains why standard code review missed this. K. A. Code Review doesn't tools don't check licensing compliance. B a developer failed to use multi-factor authentication. C, the vulnerability lived in compiled binary which reviewed tool which writ which review tools can't parse. Or D repository supply configuration files must be treated as executable content, not passive metadata. Okay, so a developer opens a git branch in VS Code. No NPM install is ever run, so they're not running the NPM install. Be just because the put the commits and the pulls, the full code review of every commit finds nothing suspicious. Because we know we just read with chain drop or dealt with chain drop, that is why. So which one is it? And the answer is D. Repository supplied configuration files must be treated as executable content, not passive metadata. So why is this correct? ChainDrop Planet is triggered inside the config files like VS Code, Task.json, and Claude. All of these as well, right? So they're these files execute automatically when open. So that's why they're treated as an executable. Now, the when you're the trap that's in play is a compiled binary sounds technically sophisticated and plausible, but why is that not right? Yeah, the attack lived in plain text, not in the actual binary. So that's the reason why you don't see that. So why are the others wrong? Well, licensing compliance, a real code review function, but not is really is not is unrelated to the credential harvesting malware hidden in the configuration files. Minacing MFA, this protects login events, but it doesn't stop the hook from firing. So it's not going to help you there. And then a compile binary, we already talked about. This is again, you're dealing with a uh a plain text in this situation, not an actual binary. Okay, so let's go to the fourth question. A CICD pipeline auto pulls the latest patch version of a dependency on every nightly rebuild. The dependency is clean Monday, but compromised on Wednesday. And by Thursday's rebuild, the malicious version has entered the production with no human review. Which control most directly closes this specific gap? A. Pinning dependency versions instead of allowing floating updates combined with signed commits package verification. B an annual third-party penetration testing. C. Requiring vendors to sign updated NDAs, or D. Increasing password complexity requirements for developer accounts. Okay, so again, this is something that occurs it's on Monday, but then a compromise stream up or upstream situation on Wednesday, and then Thursday, the rebuild malicious version is entered the production. Again, no human review. If you're looking at the question, no human review. Which control most directly closes this specific gap? Okay, so you know it's not being reviewed. And the answer is A. Correct. Pinning dependency versions instead of allowing floating updates combined with sign commit package verification. So instead of having it automatically run, you now have some sort of aspect control of that. So pinning stops the pipeline from silently pulling newer compromised versions, and signature verification confirms what you do pull hasn't been tampered with. Both act at the same moment of the Wednesday to Thursday gap. Now, the trap that's in play is an annual penetration testing is legitimate control, which can be tempting, right? Depends. But since we've gone through all these questions, you're gonna go, well, of course it's not right. But again, it could be tempting. It is periodic, though, very similar to any sort of assessment or SOC 2 type of activities. It is a periodic or it is set up a point in time. It is not continuous. So it can't catch compromises that happen between Monday and Thursday of the same week. And the pen test may not be focused on that specific environment, and therefore it wouldn't be tested. So there's lots of different areas that are associated with

CISSP Sprint Cohort Invitation

SPEAKER_01 30:35

this. All right, so that is all I have for you today. Head on over to CISSP Cyber Training. If you want to get your CISSP in the next basically two months, working on getting that the training done for it, sign up for my CISSP Sprint cohort. I'm gonna be honest with you. I have your charger right now at the early bird pricing of $497. I mean, it's it's inexpensive. Let's get real here. $500 to get the training that you need. You're gonna get one-on-one training, you're getting a diagnostics exam, you're getting questions every day, you're getting another butt batch of questions beyond that. You will be prepared for your CISSP exam, and we get you done in a structured way in the next eight weeks. And the best part about all of this is the fact is that it is going to give you accountability so that you can get this done. So often people are studying for their CISSP and they just don't have the accountability to ensure they do the training and the studying. You will have accountability partners with you when you're going through this process. You can work out and work with me directly. We're going to be also talking to each other every single week, uh, going over the different content for each domain. It is the best money spent. Period. If you're self-studying, it is the best way you can do this without having to spend five to ten to fifteen thousand dollars on a CISSP boot camp. Again, again, if you're the self-study person, this is it. If you're the boot camp person, this is not it. If you but if you want to self-study and you don't have time and you're a busy professional that needs to be able to carve some time out of your day, this is the way to do it. And the accountability is there to ensure you get this thing done. All right, so sign up for my CISSP cohort number two. It's get it's out there, it's ready to go. And uh slots are going very, very quickly. All right, we'll talk to you all later. Have a great day, and we will catch you on the flip side. See ya.

Reviews YouTube And Free Questions

SPEAKER_01 32:25

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.