Here is a potential test exam question for your review. Let me lay out the scenario:
The Cybersecurity Maturity Model Certification (CMMC) Level 2 is a U.S. Department of Defense (DoD) framework that provides security benchmarks for handling Controlled Unclassified Information (CUI). In our scenario, a defense contractor handling CUI must achieve CMMC Level 2 certification within six months.
An internal security audit shows that the software supply chain for a core CUI-processing application has not been inventoried in three years, and two critical CVEs were recently disclosed in an embedded logging library. The program manager proposes a one-time component audit to minimize engineering overhead while meeting the deadline. The CISO must advocate for a continuous, automated software composition management approach.
So the core question is this:
You are the CISO at a defense contractor subject to CMMC Level 2 requirements. Your team discovers that several open-source components in a CUI-handling data management system have not been tracked since deployment three years ago. Your security architect recommends implementing Software Composition Analysis (SCA). The program manager argues that a one-time manual inventory is sufficient. What is the MOST important reason to implement SCA rather than a one-time manual inventory?
Your options:
A) Generates a Software Bill of Materials (SBOM) to comply with federal supply chain mandates.
B) Integrates into the CI/CD pipeline to prevent the deployment of new vulnerable components.
C) Identifies and inventories open-source license obligations to reduce potential legal risks.
D) Provides continuous visibility into component vulnerabilities as new threats are disclosed.
We’ll come back to this question later. To better understand SCA’s core strengths and where it’s effective, let’s dive into how it works, how it’s used, what it catches, and what it may miss.
We’ll start with how an SCA scan actually works.
Coding libraries, dependencies, and tools
Let’s define a few concepts before we start. Developers rarely write applications from scratch. Instead, they usually import open-source libraries or packages to handle common tasks such as managing HTTP requests or database connections.
While open-source libraries reduce a developer’s up-front work, they add dependencies. A direct dependency is a library explicitly imported by a developer because the application relies on its functions and code. While using pre-built libraries saves engineering time, it introduces a critical security tradeoff: every direct dependency brings its own web of transitive dependencies, trading writing code from scratch for managing third-party operational and vulnerability risk.
So a direct dependency means that a library was explicitly requested or imported into the codebase by the developer. Transitive dependencies are the libraries that the direct dependencies rely on to work (and the libraries that those libraries rely on).
So, for example, if your code imports library A, and Library A relies on Library B and Library C, your application now contains and is dependent on all three. A project with 10 direct dependencies can easily pull in 300 or more transitive dependencies, significantly expanding the attack surface beyond what developers explicitly wrote or reviewed.
To manage hundreds of dependencies, developers use several tools, including a Package Manager and a manifest file. A Package Manager (for example, npm for JavaScript, pip for Python, Maven for Java, NuGet for .NET, etc.) reads a manifest file (e.g., package.json, pom.xml), which is a type of dependency list that declares what direct libraries the project needs. Manifest files often use flexible version ranges (for instance, “^2.1.0” meaning “version 2.1.0 or any compatible minor update”) to represent these associated dependencies.
A lockfile (e.g., package-lock.json, yarn.lock, cargo.lock) is generated automatically when dependencies are installed and records the exact versions and cryptographic hashes of every direct and transitive package resolved during build time. In a security context, the lockfile provides the definitive inventory of what code will actually run in production.
How an SCA Scan Works
Understanding package managers and lockfiles makes it easier to see how a Software Composition Analysis tool can leverage raw project files to find actionable security intelligence. At its core, an SCA scan automates the process of reading those dependency records, mapping out every open-source component in the application, and evaluating those components against known security, legal, and even operational risks.
The scan begins by constructing a complete inventory known as a Software Bill of Materials, or SBOM. To do this, the tool parses the project’s manifest files and lockfiles to extract every package name and exact version number across the entire dependency tree, capturing both direct imports and deep transitive libraries.
Once the complete component inventory is established, the SCA engine evaluates the SBOM across three main areas: security risks, exploitability context, and licensing obligations.
The tool matches every identified component against vulnerability intelligence feeds, such as the National Vulnerability Database (NVD) and private vendor research, to flag any known Common Vulnerabilities and Exposures (CVEs). However, simply listing CVEs often creates hundreds of alerts that can overwhelm security teams. To help prioritize what actually needs fixing, modern SCA tools incorporate the Exploit Prediction Scoring System (EPSS) to calculate the probability that a given vulnerability will be actively exploited in the wild over the next 30 days.
Beyond statistical likelihood, advanced scanners do reachability analysis by constructing a call graph of the application. A call graph checks whether your application’s code actually executes the specific, vulnerable function inside a compromised library, allowing security teams to distinguish between a critical flaw that is actively exposed and an uncalled or benign piece of code.
Finally, the scan checks the open-source software license associated with every package in the inventory, ranging from permissive licenses like MIT and Apache 2.0 to restrictive copyleft licenses like the GNU General Public License (GPL). By flagging copyleft requirements that could legally obligate an organization to open-source its proprietary codebase, the SCA tool protects the organization from intellectual property exposure, not just technical vulnerabilities.
What Happens When There Are No Manifest Files?
Parsing manifest files works well when you have direct access to source code. However, security teams often have to audit vendor software, legacy applications, or pre-built container images where no package manifest or lockfile exists, meaning that code essentially “arrives without paperwork”. In these scenarios, SCA tools perform binary analysis and cryptographic fingerprinting to look inside the compiled application.
To inspect a compiled artifact, the SCA tool first unpacks the binary, unzipping container layers, parsing file headers, and identifying raw functions and symbols embedded directly in the machine code. Next, the scanner generates unique cryptographic hashes (such as SHA-256) for the extracted files, function blocks, or binary signatures. It then compares these digital fingerprints against a vendor database containing millions of known open-source builds. If developers manually copy-pasted or modified open-source code, advanced tools use fuzzy hashing algorithms (like SSDEEP or TLSH) to recognize the original snippet.
Once the tool identifies the components from these fingerprints, it constructs an accurate SBOM and maps the discovered packages to known CVEs, EPSS exploitability scores, and open-source license obligations.
Additional benefits of SCA
Beyond standard software development, SCA provides additional benefits across broader areas of enterprise risk. In Third-Party Risk Management, when a commercial vendor provides compiled applications without underlying source code, binary SCA paired with cryptographic hashing allows security teams to audit the software for hidden vulnerabilities before deploying it to internal networks. SCA also helps detect "shadow" open source.
Developers occasionally copy and paste open-source code snippets directly into proprietary files or bypass package managers entirely. While traditional manifest parsing misses these instances, hashing and binary analysis expose this hidden code. In addition, cryptographic hashing ensures supply-chain integrity by verifying that libraries downloaded during automated CI/CD builds match original vendor signatures, protecting pipelines against tampering, dependency confusion, or typosquatting attacks.
How SCA Compares to Other Application Security Tools
Software Composition Analysis is only one piece of an application security program. To understand how SCA complements other testing tools, it helps to picture a residential construction project. Building a house requires different inspections and safety checks at various stages: verifying building materials before installation, reviewing architectural blueprints, inspecting the completed structure, monitoring internal utility systems under load, and managing overall project risk.
Software Composition Analysis is similar to inspecting construction building materials. Before each construction phase, the builder or an inspector verifies the prefabricated materials delivered to the job site. Examples might include lumber, pre-made roof trusses, electrical panels, and plumbing fixtures, all of which need review to ensure parts haven’t been damaged, recalled, or restricted by building codes. Similarly, SCA scans open-source libraries and package lockfiles to catch vulnerabilities and license issues in the code your team didn’t write.
Static Application Security Testing (SAST) is like reviewing the blueprints. An architect examines structural blueprints, electrical schematics, and plumbing diagrams on paper before or during construction. SAST performs “inside-out” static analysis, parsing raw source code without executing the application, catching design flaws or coding mistakes early, similar to our house construction example of looking for an outlet wired too close to a water line or omitting a load-bearing beam. Similarly, SAST searches for patterns like SQL injection, hardcoded credentials, or improper input validation.
Dynamic Application Security Testing (DAST) works similarly to an inspector reviewing the exterior of a fully built house. The inspector checks the roof, doors, and foundation for structural weaknesses or leaks under physical pressure. DAST conducts outside-in dynamic testing by inspecting a running application over HTTP/HTTPS, probing live endpoints for vulnerabilities such as cross-site scripting or misconfigured authentication headers.
Interactive Application Security Testing (IAST) is comparable to placing smart sensors inside a house's walls, such as vibration or current detectors that monitor structural stress or electrical flow in real time. IAST is a hybrid approach that installs an agent inside the application’s runtime environment. As QA teams or DAST scanners interact with the live application, the IAST agent observes internal code execution and data flow, combining the real-world validation of DAST with the line-level code accuracy of SAST.
Finally, Application Security Posture Management (ASPM) serves as the general contractor’s dashboard, synthesizing reports from the material supplier (SCA), the architect (SAST), the exterior inspector (DAST), and internal wall sensors (IAST). Instead of flooding workers with disorganized issue lists, ASPM prioritizes risks by severity and business impact, recognizing that a minor leak in a garden shed is low priority, while a foundation crack next to a gas line demands immediate action. ASPM orchestrates alerts across tools and cloud environments, deduplicates findings, and routes prioritized tickets to the appropriate engineering teams.
Where Each Tool Fits in the Process
To understand where and why these security tools run in your CI/CD pipeline, it helps to follow the standard journey code takes from a developer’s laptop to serving real customers in production.
Starting in an editor on a developer’s local machine, new code is submitted for peer review, typically through the process of opening a pull request. Once approved, the code is merged into the main codebase, compiled, and packaged into a finished build artifact. That artifact is stored in a repository, often called an artifact registry, which functions like a warehouse of built software waiting for deployment. After passing final testing, the software is deployed into production, where live users interact with it.
Each application security tool requires different information from the application, which determines exactly where it operates along this delivery pipeline. SAST requires access to raw source code, meaning it can run as early as an editing session on a developer’s laptop, during pull request reviews, or during automated build processes. Once the code is compiled into a binary, SAST is no longer effective. DAST requires a fully deployed, running application, so it typically runs in staging or pre-production environments that mirror live setups. IAST also requires a running application, but it needs an embedded agent alongside active user traffic or automated QA tests to observe code execution in real time.
SCA is unique because it can operate at every single stage of the pipeline. It does not need to analyze proprietary source code logic or watch application execution; it only needs to know which open-source components are present. This information is available everywhere along the journey: in manifest files on a developer’s machine, in lockfiles at build time, in compiled layers within a container registry, and in active production deployments.
A team running SCA at every stage gains distinct security advantages at each step. An editor plugin can flag an unsafe dependency while a developer is actively typing, long before code is committed. During a pull request, an automated scan can compare the branch against the main codebase to block vulnerable or improperly licensed libraries. At build time, the scanner reviews the entire dependency tree, inspects compiled output, and generates an accurate SBOM. Within the artifact registry, SCA can monitor stored software in the background. And in production, an SCA tool continually checks newly published vulnerability disclosures against the live inventory.
Tailoring Deployment Across Industries
While organizations across sectors use the same fundamental security tools, they adapt them to their environment, regulatory standards, and stakeholder expectations. Software and cloud providers rely on SCA to satisfy strict procurement demands, leveraging continuous scanning, automated SBOM generation, and rapid patching to demonstrate compliance with frameworks like SOC 2 and ISO 27001. Banks and financial institutions use SCA to protect critical payment processing systems and maintain license compliance, often routing dependencies through a single managed repository to satisfy PCI DSS or NIST SSDF requirements. Healthcare organizations and medical device manufacturers integrate SCA into release validation builds to ensure patient safety and satisfy HIPAA and FDA oversight. Defense contractors deploy SCA across their software supply chains to meet rigorous federal requirements such as FedRAMP, FISMA, Executive Order 14028, and CMMC Level 2.
Software Composition Analysis earns its place at the center of modern application security because it is fast, highly adaptable, and operates seamlessly across the entire development lifecycle. While traditional tools focus on the code the team writes, SCA protects the massive foundation of open-source components that modern applications rely on.
Returning to the Question
Now that we’ve covered how SCA operates and how it compares to other tools and monitors software across the entire development pipeline, let’s return to the scenario we introduced at the beginning. With these concepts in mind, the correct answer should now be clear.
As a reminder, the scenario presented a defense contractor subject to CMMC Level 2 requirements whose team discovered untracked open-source components in a CUI-handling application. While the program manager proposed a one-time manual inventory to save engineering overhead, the security architect recommended implementing SCA. The question asked for the MOST important reason to choose SCA over a one-time manual inventory:
A) Generates a Software Bill of Materials (SBOM) to comply with federal supply chain mandates.
B) Integrates into the CI/CD pipeline to prevent the deployment of new vulnerable components.
C) Identifies and inventories open-source license obligations to reduce potential legal risks.
D) Provides continuous visibility into component vulnerabilities as new threats are disclosed.
The correct answer is D.
While options A, B, and C describe real SCA capabilities and benefits, option D captures the core strength that a one-time audit can never replicate. Vulnerability disclosure is dynamic and continuous. An open-source library that is considered completely secure during a manual audit today may have a critical CVE disclosed against it tomorrow. A one-time inventory provides only a temporary snapshot in time, whereas automated SCA continuously monitors the component inventory against newly published threat intelligence, ensuring the organization remains aware of emerging risks throughout the application’s operational lifecycle.
Take Your CISSP Preparation Further
If you are currently preparing for the CISSP exam, mastering judgment-based scenarios like the one above is critical. Technical recall alone is not enough; you need to reinforce your ability to evaluate trade-offs like a security leader.
I wrote a comprehensive CISSP book focused on this exact mindset, and rather than publishing a static PDF, I built it into an interactive platform called the BalancedSec Academy. We are currently offering 30 days of free access to founding beta members in exchange for your feedback. Access includes the full digital book, a personalized study plan tuned to your exam date, a spaced-repetition study queue, and a CAT-style exam engine designed to mimic the ambiguity of the real test. One recent founding member noted after passing their exam that these scenario-driven practice questions made the test feel much more manageable.
If you would like to join the founding cohort, you can claim your access at academy.balancedsec.com.