What is software composition analysis scanning?
SCA scanning is the automated analysis of application codebases to identify all open-source and third-party components. This process helps you understand exactly what external code is running within your software so you can manage the associated risks.
SCA tools create a software bill of materials (SBOM) by inventorying every dependency, version, and license used in your project. Modern SCA generates SBOMs in standardized formats—primarily SPDX (Software Package Data Exchange) and CycloneDX—enabling consistent sharing across tools and organizations. These machine-readable formats allow continuous monitoring: when a new CVE is published, SCA tools can instantly check all SBOMs to identify affected systems.
There are two main ways scanners perform this analysis. Some scan manifest files like package.json or requirements.txt to see declared dependencies, while others perform binary analysis on compiled artifacts to find components that might not be listed in a file.
Crucially, SCA identifies both direct dependencies that you explicitly declare and transitive dependencies that your libraries pull in automatically. It also evaluates license risks to ensure you remain compliant with open-source licensing requirements.
Secure Coding Best Practices [Cheat Sheet]
With curated insights and easy-to-follow code snippets, this 11-page cheat sheet simplifies complex security concepts, empowering every developer to build secure, reliable applications.
Why SCA scanning matters for modern application security
Modern applications typically contain more open-source than proprietary code. According to Sonatype's 2024 State of the Software Supply Chain report, commercial applications often include a majority of open-source components, with some codebases approaching 90% OSS composition. This shift means that a significant portion of your application's security posture depends on code you didn't write.
Supply chain attacks exploit vulnerabilities in these widely-used libraries, as seen in high-profile incidents like Log4j. As development velocity increases, teams add more dependencies, which rapidly expands the attack surface.
Another major challenge is "dependency drift," where components become outdated and vulnerable over time without anyone noticing. According to Synopsys's 2024 Open Source Security and Risk Analysis report, 91% of codebases included components that were 10 or more versions behind the current release, significantly increasing exposure to known vulnerabilities that have been patched in newer versions. Traditional security tools often miss these vulnerabilities because they focus on your custom code rather than the third-party libraries embedded within it.
Consequently, regulatory frameworks are increasingly requiring visibility into software composition through SBOM mandates. Executive Order 14028 requires SBOMs for federal software suppliers, while NIST's Secure Software Development Framework (SSDF) provides implementation guidance.
What is CVE scanning?
CVE scanning is the automated process of checking your software, systems, and networks against a database of known security flaws to identify vulnerabilities before attackers can exploit them.
En savoir plus
How SCA scanning works in practice
The process begins with a discovery phase where SCA tools identify all dependencies across your repositories, containers, and artifacts. The tool matches these component versions against vulnerability databases to flag any known issues associated with them.
Modern SCA tools go further by correlating findings with CVSS severity, exploit availability (such as CISA KEV), exploit prediction (EPSS), and patch status. Leading tools add graph-based context and runtime signals to elevate reachable vulnerabilities in internet-exposed workloads over theoretical issues buried in unused code paths. This helps you understand not just which vulnerabilities exist, but which ones pose an immediate threat in your specific environment.
Remediation guidance: The tool generates specific advice, such as which version to upgrade to or alternative packages to use.
Continuous monitoring: SCA alerts your team immediately when new vulnerabilities are discovered in dependencies you are already using.
Lifecycle scanning: You can run scans at multiple stages, including developer workstations, build pipelines, container registries, and runtime environments.
SCA scanning vs other application security testing methods
SCA differs from SAST (static application security testing), which analyzes your proprietary code for coding flaws like SQL injection. While SAST looks at the code you wrote, SCA focuses specifically on the third-party components you imported.
It also contrasts with DAST (dynamic application security testing), which tests running applications from the outside in. In containerized workloads, SCA targets application dependencies while image scanning also covers OS and base-image packages—together they provide complete coverage of container risk.
It is important to clarify that SCA is different from SBOM generation. SBOM generation documents your components, whereas SCA analyzes that inventory to find vulnerabilities. Comprehensive security requires combining SCA with other testing methods like SAST, DAST, and IaC scanning to cover all bases.
Essential capabilities of effective SCA scanning tools
An effective tool should support major languages and package managers (npm, Maven, PyPI, RubyGems, NuGet, Go modules) and ingest multiple sources including lockfiles (package-lock.json, requirements.txt), SBOMs (SPDX, CycloneDX), container image layers, and binary fingerprints. This multi-source approach ensures comprehensive dependency discovery. It must also feature strong transitive dependency analysis to catch indirect vulnerabilities that are buried deep in your dependency tree.
Prioritization: Features that reduce noise by focusing on exploitable or reachable vulnerabilities are critical for managing workload. Effective prioritization combines multiple signals:
CVSS severity scores – Base risk assessment (Critical, High, Medium, Low)
CISA KEV catalog – Known exploited vulnerabilities actively used in attacks
EPSS scores – Exploit prediction probability based on threat intelligence
Runtime reachability – Whether vulnerable code paths are actually executed
Network exposure – Internet-facing versus internal-only workloads
Data sensitivity – Access to PII, credentials, or business-critical data
Asset criticality – Production versus development environmentsThis multi-signal approach helps teams fix vulnerabilities that combine high severity with actual exploitability in their specific environment.
Developer integrations: Plugins for IDEs and pull request checks enable shift-left security, allowing devs to fix issues before code is merged.
Agentless integrations: Connections to version control systems (GitHub, GitLab, Bitbucket), CI/CD platforms (Jenkins, CircleCI, GitHub Actions), and container registries (ECR, ACR, GCR) that require no agent installation minimize friction and ensure broad coverage across repositories and images without impacting build performance.
Automated remediation: Suggestions for safe version upgrades accelerate the fixing process.
License compliance: Features that flag restrictive licenses help prevent legal issues with organizational policies. According to Synopsys's 2024 report, over 53% of codebases have open-source license conflicts—for example, using GPL-licensed components in proprietary software or mixing incompatible licenses like Apache 2.0 and GPL v2 in the same project.
Continuous monitoring is also essential. This ensures your teams are alerted the moment a new CVE affects an existing dependency.
Watch 5-minute demo
Watch the demo to learn how Wiz Code scans infrastructure as code, container images, and CI/CD pipelines to catch risks early—before they reach the cloud.
Watch now
Implementation challenges and best practices for SCA scanning
A common implementation challenge is "alert fatigue," where SCA tools generate thousands of findings that overwhelm security teams. This is often compounded by false positives, where flagged vulnerabilities aren't actually exploitable in your specific context.
Gaps and inconsistencies across vulnerability data sources—such as package naming conventions, versioning schemes, and metadata formats—can lead to missed or misidentified findings if not properly normalized. For example, the same package may be referenced differently in NVD versus GitHub Security Advisories. Furthermore, prioritizing fixes is difficult when nearly every dependency seems to have multiple vulnerabilities.
Establish policies: Define acceptable risk levels and vulnerability SLAs to guide remediation efforts.
Automate workflows: Route findings directly to the appropriate development teams to ensure accountability.
Integrate seamlessly: Embed SCA into existing developer workflows to avoid creating friction or slowing down development.
Update regularly: Make dependency updates a routine part of maintenance to prevent vulnerability accumulation.
Establish dependency hygiene practices:
Pin versions: Use exact version numbers in lockfiles (package-lock.json, Gemfile.lock) rather than version ranges to ensure reproducible builds
Automate updates: Deploy tools like Renovate or Dependabot to create pull requests for dependency updates automatically
Maintain allowlists: Define approved packages and versions that meet your security and licensing standards
Use minimal base images: Start with distroless or Alpine-based images to reduce inherited vulnerabilities
Regular dependency audits: Schedule quarterly reviews to remove unused dependencies and consolidate duplicate packages
Source code scanning best practices for cloud security
Source code scanning is automated analysis of your code, dependencies, and infrastructure definitions to find security issues before you deploy. This means a tool reads your code the way a careful reviewer would, but at high speed and at scale.
En savoir plus
SCA scanning in cloud-native and container environments
Containerized applications package dependencies together, making SCA critical for securing the container supply chain. Because workloads in Kubernetes are ephemeral, you need continuous SCA monitoring beyond just build-time scans.
Multi-stage builds can obscure where a vulnerable dependency was introduced during the build process. Effective SCA scans the final image (including all base layers) and traces lineage back to the specific build stage that added each component, enabling teams to fix the root cause. SCA tools must integrate with container registries to scan images before they are ever deployed.
Scanning serverless functions presents a unique challenge because dependencies are often bundled directly with application code. Cloud-native SCA should account for both application dependencies and OS/base image packages, since inherited vulnerabilities often originate in the base layer. For example, a Node.js application image built on Ubuntu may inherit dozens of OS-level CVEs before any application code is added. Ultimately, runtime context is key to prioritizing which container vulnerabilities pose an actual risk to your environment.
Code-to-cloud lineage clarifies ownership by mapping findings from source repository to container image to running workload. This traceability enables security teams to route fixes to the right development team quickly—for example, identifying that a vulnerable Python library in a production pod originated from a specific commit in the data-science team's repository three weeks ago.
What is SBOM scanning?
An SBOM contains an inventory of all software components, libraries, dependencies, versions, licenses, and relationships.
En savoir plus
Wiz Code: Context-driven SCA scanning for cloud environments
Wiz Code provides native SCA to identify vulnerabilities and license risks across dependencies in repositories, images, and running workloads. Findings are enriched with graph-based context—a unified view of how cloud resources, permissions, network paths, and data flows interconnect—and runtime signals to reflect actual exploitability in your specific environment rather than theoretical risk scores.
Runtime reachability analysis using the Wiz Sensor validates which vulnerable libraries are actually loaded and executing in production workloads. This distinguishes between vulnerabilities present in code versus those actively reachable through execution paths.
Code-to-cloud traceability: Maps SCA findings from source repositories to production workloads so you know exactly who owns the fix.
Attack path analysis: Connects dependency vulnerabilities with network exposure, permissions, and sensitive data access to show the full impact.
WizOS: Hardened, near-zero-CVE base images reduce inherited vulnerabilities at the foundation, cutting SCA noise by eliminating dozens of OS-level CVEs before any application code is added. This reduces remediation toil and lets teams focus on application-layer risks they can actually control.
Unified policy engine: Apply consistent security guardrails in IDEs, pull requests, CI/CD pipelines, container registries, and cloud runtime—preventing risky dependencies from shipping while maintaining the same policy definitions across all stages. For example, block any package with a KEV-listed CVE at commit time, build time, and deployment time using a single policy rule.
Wiz turns SCA findings into prioritized action with full code-to-cloud context—so teams fix exploitable issues faster without slowing delivery. Security teams get clear risk prioritization, while developers get actionable remediation guidance routed directly to their workflows.
See how context-driven SCA works in your environment—book a demo to connect a repository and container registry in minutes and get prioritized findings with full cloud context, no agents required.
Secure your cloud from code to production
Learn why CISOs at the fastest growing companies trust Wiz to accelerate secure cloud development.
