SCA scanning: how it works, challenges, and how AI can help

What is SCA (software composition analysis) scanning?

Software Composition Analysis (SCA) scanning is an automated process that identifies and analyzes open-source and third-party components used in an application. It helps development and security teams detect known vulnerabilities, track software dependencies, and identify license compliance risks.

Modern applications rely on external libraries, frameworks, and packages to reduce development time. However, these components can introduce security vulnerabilities, outdated dependencies, and licensing issues. SCA scanning provides visibility into these risks without requiring developers to manually inspect every dependency.

How does SCA scanning work?

• Discovering third-party components: Examines project files, package metadata, dependencies, and build artifacts to inventory external software.
• Resolving exact package versions: Uses lockfiles and build data to identify resolved versions rather than relying only on declared version ranges.
• Mapping dependency relationships: Traces direct and transitive dependencies to show how vulnerable packages enter the application.
• Detecting known vulnerabilities: Matches component names and versions against vulnerability databases and advisories, without assuming every match is exploitable.
• Generating an SBOM: Creates a structured component inventory for supply chain visibility, vulnerability monitoring, and compliance.
• Assessing exploitability and prioritizing findings: Evaluates application-specific exploit conditions, then considers threat intelligence and business impact to prioritize remediation.
• Remediating and continuously monitoring: Recommends fixes or mitigations, supports developer-reviewed changes, and monitors for new vulnerabilities and patches.

Which security issues can SCA scanning detect?

• Known vulnerabilities (CVEs) in open-source dependencies: Matches identified package versions against published vulnerability records and security advisories.
• Outdated, unmaintained, and potentially malicious packages: Identifies aging or abandoned dependencies and, where supported, packages associated with known malicious activity or supply chain compromise.
• Open-source license and compliance risks: Detects package licenses that may conflict with organizational policies or introduce licensing obligations.
• Vulnerabilities in container images and embedded libraries: Identifies affected software components included in supported build artifacts, container images, and packaged applications.

Detection alone does not establish the likelihood or impact of exploitation. For a broader overview of the risks covered by software composition analysis, see Software Composition Analysis: How It Works and Best Practices.

What does an SCA scan analyze?

SCA scanners examine different sources of information to establish which third-party components an application depends on. The accuracy and completeness of the results depend partly on whether the scanner analyzes declared dependencies, resolved versions, or the components actually included in the deployed application.

Dependency manifests and package definitions

Dependency manifests declare the external packages an application requires. Examples include package.json for JavaScript, requirements.txt and pyproject.toml for Python, pom.xml for Maven, and go.mod for Go. Scanners parse these files to identify packages, dependency constraints, and the package ecosystems involved.

However, manifests do not always establish the exact versions used in a build. A dependency declaration may permit multiple compatible versions, and the application may pull in transitive dependencies that the manifest never lists. Manifest analysis therefore provides an important starting point, but it may not represent the complete software delivered to production.

Lockfiles and resolved dependency versions

Lockfiles record the specific dependency versions selected during package resolution, often including transitive dependencies. Examples include package-lock.json, yarn.lock, poetry.lock, and Cargo.lock. These files allow scanners to determine the resolved versions more precisely than manifests containing version ranges.

This distinction directly affects vulnerability detection, because a manifest might allow versions 2.0 through 2.9 of a library while the lockfile identifies version 2.4 as the actual resolved dependency. If a security advisory affects versions below 2.6, the scanner needs that exact version information to determine whether the application includes an affected release.

Lockfile accuracy also depends on the build using the recorded dependency resolution. When lockfiles are missing, outdated, or bypassed during installation, scanners may need to inspect installed packages or build outputs to establish which components were actually used.

Built artifacts, binaries, and container images

Artifact scanning examines the software produced by the build process rather than relying exclusively on source repository files. Depending on the scanner and ecosystem, this can include Java archives, compiled packages, vendored libraries, operating system packages, and container images.

This helps identify differences between declared dependencies and deployed software. A development dependency might appear in a repository but never reach production, while a container base image might introduce vulnerable libraries that are not mentioned in the application’s dependency manifests.

Artifact analysis can therefore improve the accuracy of component inventories and help establish whether a vulnerable package is included in the delivered application. However, determining whether that package actually runs or exposes a vulnerable function may require additional code and runtime analysis.

Direct and transitive dependencies

SCA scans examine both direct dependencies, which developers explicitly include in their projects, and transitive dependencies, which are brought in automatically by other packages.

For example, an application might depend directly on a web framework that imports several utilities, each with additional dependencies. A vulnerability several layers down this dependency chain can still affect the application, even though developers never intentionally installed the vulnerable package.

Dependency relationship analysis identifies which package introduced the vulnerable component and where it sits in the dependency tree. This information is especially useful for remediation because developers may need to upgrade a parent dependency rather than modify the vulnerable package directly.

When should SCA scans run?

SCA scans should run throughout development and deployment, with ongoing monitoring after release. Each stage serves a different purpose, from providing early developer feedback to detecting newly disclosed vulnerabilities in software already in production.

• During development in the IDE: Scan dependencies as developers add or update them to catch potential vulnerabilities early. Treat findings as preliminary until resolved versions, build details, and deployment context are available.
• On every pull request: Scan dependency changes before merging to identify newly introduced risks, including vulnerable transitive dependencies. Focus blocking policies on verified new risks rather than unrelated existing vulnerabilities.
• During CI/CD builds and before deployment: Scan resolved dependencies and release artifacts, generate SBOMs, and check container packages and base images. Apply gates based on severity, exploitability, and newly introduced risk.
• Across the entire repository and existing codebase: Regularly scan active and inactive projects to maintain a dependency-risk baseline. Use findings to identify affected applications, assign owners, and coordinate remediation across teams.
• When new vulnerabilities affect shipped dependencies: Continuously compare dependency inventories against new advisories. Investigate whether affected packages were shipped, vulnerable code is used, and exploitation conditions exist in production.

Related content: Read our article about SAST vs SCA

How does SCA scanning work?

1. Discovering and inventorying third-party components

The scanner first examines available project files, package metadata, installed dependencies, and supported build artifacts to identify external components. It creates an inventory of the libraries, frameworks, packages, and other third-party software included in the application.

Depending on the available inputs, this inventory may include package names, ecosystems, dependency sources, and references to the files or artifacts where components were identified. The objective is to establish which third-party components need further analysis.

2. Resolving exact package versions from lockfiles and build data

Next, the scanner identifies the actual versions selected for each dependency. It examines lockfiles and other available resolution data rather than relying exclusively on version ranges declared in package manifests.

This step is essential because vulnerability advisories typically specify affected package versions or version ranges. Without accurate resolution information, a scanner may incorrectly flag a package version that is not installed or overlook a vulnerable version introduced during the build.

When possible, scanners can compare dependency resolution data with installed packages and build artifacts to confirm that the identified versions correspond to the software being analyzed.

3. Mapping direct and transitive dependency relationships

After resolving package versions, the scanner maps how dependencies relate to one another. It identifies which packages are explicitly required by the application and which are indirectly introduced through other dependencies.

This produces a dependency tree or graph that helps security teams understand where vulnerable packages originate. If a vulnerability appears in a deeply nested library, the scanner can identify the upstream dependency responsible for introducing it.

These relationships also inform remediation because updating the vulnerable package directly may not be possible when its version is controlled by a parent dependency, so developers may need to update or replace another package in the dependency chain.

4. Vulnerability detection using CVE databases and security advisories

The scanner compares the identified package names and versions against vulnerability databases and security advisories. These may include CVE records, the National Vulnerability Database (NVD), GitHub Security Advisories, OSV, and ecosystem-specific advisories.

Traditional vulnerability matching is primarily based on affected version ranges. If an application contains a package version listed as vulnerable, the scanner reports the corresponding finding.

However, a version match does not establish that an application can be exploited. The vulnerable function may never be called, the affected feature may be disabled, or the application may not meet the exploit’s technical prerequisites. This is a major source of alert noise in traditional SCA scanning and explains why additional investigation is necessary.

5. Software bill of materials (SBOM) generation

SCA scanners can generate a software bill of materials (SBOM) containing an inventory of identified software components and their relationships. Common SBOM formats include SPDX and CycloneDX.

An SBOM provides a structured record that organizations can use for software supply chain visibility, vulnerability monitoring, and compliance processes. It can also help identify which applications may be affected when new vulnerabilities are disclosed.

However, an SBOM is an inventory rather than an exploitability assessment. The presence of a vulnerable component in an SBOM does not establish whether attackers can reach or exploit the affected functionality.

6. Exploitability assessment and vulnerability prioritization

Once vulnerabilities have been detected, the next question is whether they are technically exploitable in the application’s actual environment. This requires examining factors such as the affected function, application configuration, attacker-controlled inputs, deployment conditions, and security controls.

Exploitability differs from exploit availability, which only tells you whether attackers have the means to exploit a vulnerability in general. A vulnerability may have a published proof of concept or appear in CISA’s Known Exploited Vulnerabilities (KEV) catalog, yet remain impossible to exploit in a particular environment because a necessary condition is absent. Conversely, a vulnerability may be exploitable even when no public exploit is known. EPSS and KEV contribute threat intelligence, but they do not independently determine environment-specific exploitability.

After establishing which findings are exploitable, security teams can prioritize them according to the likelihood of attack and potential business impact. Relevant factors include network exposure, access requirements, sensitive data access, available controls, and the importance of the affected service.

7. Remediation recommendations, developer-reviewed fixes, and continuous monitoring

SCA scanning results should guide developers toward practical remediation. Recommendations may include upgrading to a fixed dependency version, replacing an unsupported library, or modifying application code to avoid vulnerable functionality.

The preferred fix is often the smallest compatible upgrade that resolves the vulnerability without introducing unnecessary breaking changes. Where automated code changes or pull requests are available, developers should review and validate them through the organization’s normal testing and approval process rather than applying changes without oversight.

When no compatible fix exists, security teams may recommend temporary mitigations, such as disabling the affected feature, restricting access, or changing configurations. Continuous monitoring should then identify new patches, newly disclosed vulnerabilities, and changes in the environment that affect the original risk assessment.

How to interpret and act on SCA scan results

An SCA scan can produce hundreds or thousands of findings, particularly in applications with large dependency trees. The goal is to work out which of those findings represent real risk and point developers to the right fix, rather than to close every reported package match one by one.

Distinguishing detected vulnerabilities from exploitable risks

A detected vulnerability indicates that a component matches an affected package version described in a security advisory. It does not necessarily mean the vulnerable functionality can be reached or exploited in the application.

Security teams should distinguish among package-level detection, vulnerable code reachability, and actual exploitability. A package may be vulnerable according to its version, but the application may not use the affected functionality. Even when that functionality is reachable, exploitation may require specific conditions that do not exist.

This distinction helps teams avoid treating every CVE match as an equally urgent remediation task. Findings supported by evidence of technical exploitability should receive greater attention than those whose exploit prerequisites are demonstrably absent.

Validating findings against the application and deployment environment

Security teams should investigate findings using the application’s actual code, build outputs, and deployment context. Important questions include whether the vulnerable package is included in the production build, which functions invoke it, and whether an attacker can reach the affected behavior.

Deployment details also matter because a library running in an internet-facing service may have a different exposure profile from the same library in an isolated internal environment. Configuration settings, authentication requirements, network controls, and runtime permissions may determine whether an attack is technically possible.

Validation should produce evidence explaining the assessment rather than simply assigning a severity label. Where critical information is missing, the finding should remain unresolved or require further investigation rather than being automatically classified as safe.

Choosing between dependency upgrades, replacement, and temporary mitigations

When a vulnerability requires remediation, developers should first identify whether a fixed and compatible package version is available. A targeted version upgrade is often preferable to a major dependency update because it minimizes the likelihood of breaking existing functionality.

However, fixes may require upgrading a parent dependency, replacing an abandoned library, or making application code changes. Developers should examine compatibility constraints, API changes, transitive dependency effects, and regression test results before approving the change.

If no patch is available, temporary mitigations may reduce risk. For example, teams might disable a vulnerable feature, restrict access to an affected endpoint, or change application configuration to remove a prerequisite for exploitation. These mitigations should be documented and reassessed when a permanent fix becomes available.

Assigning findings to developers and reviewing remediation PRs

Remediation is more effective when findings are assigned to developers who own the affected application or dependency. Scan results should identify the relevant package, vulnerable version, affected repository, dependency path, and recommended corrective action.

Where supported, remediation workflows can generate pull requests containing targeted dependency updates or code changes. The responsible developer can then review the proposed fix, run tests, and confirm that the change does not introduce regressions.

This approach reduces the burden of manually investigating every finding while preserving developer control over application changes. Security teams can focus on validating risk and tracking remediation, rather than repeatedly routing generic vulnerability reports between teams.

Setting PR blocking policies based on newly introduced, verified risk

Pull request security gates should distinguish between vulnerabilities introduced by the proposed change and existing vulnerabilities already present in the codebase. A developer modifying an unrelated feature should not automatically be blocked by an issue introduced in another component months earlier.

A more effective policy blocks changes that introduce new, verified security risks, while handling previously identified vulnerabilities through a separate remediation workflow. Where exploitability analysis is available, it can help determine whether a newly introduced dependency vulnerability warrants blocking the merge.

Blocking policies should also account for available fixes, risk acceptance, and exceptional cases. Excessively strict gates that fail builds for every version-based finding can slow development and encourage developers to bypass scanning tools, undermining the controls they were intended to enforce.

Benefits of SCA scanners

SCA scanners help development and security teams identify and manage risks introduced by open-source and third-party software components. By automating dependency analysis, vulnerability detection, and license checks, these tools improve software supply chain visibility and reduce the manual effort required to maintain application security.

Key benefits of SCA scanners include:

• Early vulnerability detection: Identify known security vulnerabilities in open-source dependencies before applications reach production.
• Full dependency visibility: Discover direct and transitive dependencies, including components developers may not explicitly manage.
• Faster vulnerability remediation: Identify affected package versions, available security patches, and recommended dependency upgrades.
• Reduced manual security work: Automate dependency inventories, vulnerability checks, and security reporting across multiple projects.
• Improved vulnerability prioritization: Use severity scores, exploit intelligence, and, where supported, reachability analysis to focus remediation on higher-risk findings.
• Open-source license compliance: Detect component licenses and flag potential conflicts with organizational policies or software distribution requirements.
• Software supply chain transparency: Generate software bills of materials (SBOMs) to document third-party components and support security audits.
• Continuous security monitoring: Detect newly disclosed vulnerabilities in existing dependencies without requiring changes to application code.
• CI/CD pipeline integration: Automatically scan dependencies during development and enforce security policies before deployment.
• Reduced exposure to known threats: Help teams replace or update vulnerable components, reducing the risk of attacks that exploit known dependency weaknesses.

Related content: Read our guide to SCA security

Common challenges and limitations of traditional SCA scanning

Traditional SCA scanners are effective at identifying dependencies associated with known vulnerabilities. However, detecting a potentially vulnerable package is easier than establishing whether it creates a real security risk in a specific application.

High volumes of vulnerability alerts and false positives

Traditional SCA scanning relies heavily on matching package versions against vulnerability databases. This approach is useful for identifying potentially affected software, but it can generate large numbers of findings without establishing whether attackers can exploit them.

A package may be flagged because its version falls within a vulnerable range, even though the application does not use the affected function. The same vulnerability may also be reported across multiple services, repositories, and container images, creating repetitive remediation work.

As a result, security teams must investigate substantial backlogs of findings, many of which may not represent exploitable risks in their environments. Severity scores alone do little to solve the problem because they describe vulnerability characteristics without considering the application’s actual configuration and deployment.

Difficulty tracing vulnerable code through dynamic calls and frameworks

Traditional reachability analysis represented an important improvement over version-based vulnerability matching. Instead of flagging every vulnerable dependency equally, it attempts to determine whether application code contains a path to the affected function, often using static call graphs.

However, constructing complete call graphs is difficult in modern applications. Dynamic function calls, reflection, dependency injection, and framework routing can obscure relationships between functions. A web framework, for example, may resolve request handlers dynamically, preventing a static analyzer from identifying the full execution path.

When analysis reaches one of these boundaries, the trace may stop before establishing whether the vulnerable function is reachable. This can produce inconclusive results, forcing developers to investigate manually or leaving security teams without enough evidence to distinguish relevant findings from noise.

Reachable vulnerabilities are not always exploitable

Even when a scanner identifies a valid path to vulnerable code, that does not prove an attacker can exploit it. Reachability establishes that an execution path exists, and it’s one part of checking exploitability, which also requires the additional conditions necessary to exploit the vulnerability and achieve its security impact.

For example, consider an application that uses a vulnerable decompression function in an HTTP library. Static analysis might confirm that requests from the application can invoke the affected function, establishing reachability. However, exploiting the flaw may require an attacker to control the server response being decompressed. If the application only communicates with fixed, trusted endpoints that attackers cannot influence, that prerequisite may be absent.

In this situation, the vulnerable function is reachable, but the specific attack cannot succeed under the current conditions. Exploitability analysis must examine attacker control, configuration settings, runtime behavior, and other vulnerability-specific prerequisites, rather than assuming that the existence of a call path creates a practical attack.

Limited visibility into runtime and cloud environments

Repository-based scanning examines application code and dependency information, but it may lack visibility into where the software is deployed and how it behaves in production. This creates a gap between detecting vulnerabilities in source code and understanding their actual operational significance.

Consider the same vulnerable dependency in two services. One runs in an internet-facing payment application that processes customer transactions, while the other runs in an isolated staging environment without real customer data or external access. Although the package vulnerability is identical, the exposure, likelihood of attack, and potential business impact are very different.

A scanner that only examines repository contents cannot reliably account for these differences. Accurate risk assessment may require information about running workloads, container images, network exposure, identity permissions, application configurations, and access to sensitive resources.

How AI improves SCA scanning and vulnerability management

Think about how a security engineer would handle a dependency vulnerability with unlimited time. They would find what pulled the package in, check which version the build used and whether it ships, read the vulnerable function, and work out whether an attacker could reach it in the environment where the code runs. Rules can’t run that investigation on every finding, because every vulnerability needs its own set of checks and context, and that’s the job AI was built to take on.

AI improves software composition analysis by moving beyond dependency discovery and vulnerability matching to investigate whether identified issues can actually be exploited. Instead of requiring security teams to manually examine every CVE, AI-powered tools can analyze application code, dependency relationships, deployment configurations, and runtime conditions to identify vulnerabilities that represent real security risks.

The best AI-based SCA tools can also trace complex execution paths, prioritize exploitable vulnerabilities, and generate remediation recommendations tailored to the affected application. This reduces unnecessary security alerts and allows developers to focus on fixing vulnerabilities that matter.

AI-powered investigation of open-source vulnerabilities

Traditional SCA scanners identify vulnerable packages by comparing dependency versions against known vulnerability databases. AI-powered investigation extends this process by examining the vulnerability itself, including the affected functionality, conditions required for exploitation, and changes introduced by security patches. This helps determine whether a detected vulnerability poses a meaningful risk to the application.

AI can collect and correlate information from vulnerability advisories, source code, dependency manifests, build artifacts, and application configurations. For example, when investigating a vulnerable library, AI might examine the specific function affected by a CVE, determine whether the application uses that function, and identify whether the conditions required to exploit the vulnerability exist.

These investigations can produce evidence-backed assessments explaining why a vulnerability is exploitable, not exploitable, or requires further investigation. Security teams can review the supporting code paths, configurations, and technical reasoning instead of relying exclusively on vulnerability severity scores or automated classifications.

AI tracing for dependency reachability

Traditional reachability analysis often relies on static call graphs to identify whether application code can invoke vulnerable functions inside third-party dependencies. However, these techniques can struggle with dynamic function calls, reflection, dependency injection, and framework-specific routing. As a result, traditional scanners may be unable to determine whether a vulnerable function can be reached through complex application logic.

AI tracing can analyze application code and dependency implementations to reconstruct execution paths that conventional call graphs cannot fully resolve. It can follow function calls across multiple dependency layers, interpret framework behavior, and identify connections between application entry points and vulnerable functions. This is particularly useful when vulnerabilities exist deep within transitive dependencies.

For example, an AI-based scanner might trace an HTTP request through application routing logic, middleware, a third-party framework, and several nested libraries before reaching a vulnerable function. By identifying the complete execution path and the evidence supporting it, the scanner helps developers understand how the vulnerability relates to their application. However, reachability alone does not establish exploitability.

Context-aware exploitability analysis across code and cloud

AI-powered SCA can combine application-level findings with deployment and cloud infrastructure context to determine whether vulnerabilities can actually be exploited. This requires examining more than the presence of vulnerable code or an execution path. The analysis must also establish whether the technical prerequisites for exploitation exist in the application’s operating environment.

Relevant factors include network exposure, attacker-controlled inputs, application configuration, identity permissions, runtime behavior, and existing security controls. For example, a vulnerable function might be reachable in application code but require a specific configuration that is disabled in production. Similarly, a vulnerable package might exist in a container image without being loaded or executed by the running application.

By correlating code, build, and cloud evidence, AI systems can identify these differences and explain whether the vulnerability creates a viable attack path. This helps distinguish exploitable vulnerabilities from findings whose exploitation conditions are demonstrably absent. When evidence is incomplete or deployment conditions change, the assessment should be revisited rather than permanently treating the vulnerability as harmless.

Risk-based prioritization of verified exploitable vulnerabilities

Traditional vulnerability prioritization often relies on CVSS severity scores, which describe the general characteristics of a vulnerability but do not establish its risk in a specific environment. AI-powered prioritization can first investigate technical exploitability and then evaluate the likelihood and potential impact of exploitation using application and infrastructure context.

Relevant factors include whether attackers can reach the affected service, what privileges exploitation requires, whether the vulnerability is being exploited in the wild, and what sensitive systems or data could be compromised. AI can combine these factors with information about asset criticality and business importance to prioritize vulnerabilities that create the greatest organizational risk.

For example, a medium-severity vulnerability affecting an internet-facing payment service may deserve more immediate attention than a critical vulnerability in an isolated development environment. This approach helps security teams allocate remediation resources based on verified exposure and potential business impact rather than severity scores alone. Priorities can also be updated as new exploits emerge or deployment conditions change.

AI-generated, code-specific remediation recommendations and developer-reviewed fixes

AI-powered SCA solutions can generate remediation recommendations based on the application’s actual dependency structure, source code, and build requirements. Instead of suggesting a generic upgrade to the latest package version, AI can identify a compatible version that addresses the vulnerability while minimizing unnecessary dependency changes.

When a vulnerability originates from a transitive dependency, AI can trace it to the parent package responsible for introducing the affected component and recommend an appropriate upgrade path. More advanced systems can generate code changes, dependency updates, or pull requests tailored to the repository. If no suitable patch exists, they can recommend mitigations such as disabling vulnerable functionality, restricting access, or modifying configurations.

These recommendations can be routed to the developers responsible for the affected code, along with evidence explaining the vulnerability and proposed fix. Developers should review AI-generated changes, validate dependency compatibility, and run automated tests before merging. This preserves engineering oversight while reducing the manual effort required to investigate vulnerabilities and prepare remediation.

Reducing false positives, unnecessary PR blocks, and developer alert fatigue

Traditional SCA tools can overwhelm developers with vulnerability alerts based on package-version matches, even when the affected functionality is unused or the conditions required for exploitation are absent. AI-powered investigation reduces this noise by evaluating each finding against application code, dependency behavior, and deployment context before determining whether it requires developer attention.

Findings confirmed as not exploitable under current conditions can be filtered from active remediation queues while retaining the supporting evidence for future review. AI can also correlate duplicate findings reported by different scanners, repositories, or cloud environments, helping security teams avoid creating multiple tickets for the same underlying issue. Findings with insufficient evidence should remain open for investigation rather than being automatically dismissed.

AI-based exploitability assessments can also improve pull request security gates. Instead of blocking every change associated with a vulnerable dependency, organizations can configure policies to block newly introduced, verified exploitable risks while managing existing vulnerabilities through separate remediation workflows. This prevents developers from being repeatedly blocked by unrelated findings, reduces alert fatigue, and maintains security controls focused on meaningful risk.

How Maze approaches SCA scanning

While working with security teams, Maze’s founders kept running into the same gap, which was that dependency scanners could list every vulnerable package but couldn’t gather the context to say which ones mattered, so teams spent their time chasing findings that were never a real risk. They built Maze so that every vulnerability gets the investigation those teams never had time to run. Maze uses AI to find the vulnerabilities in your code and dependencies, investigate every finding, and tell you which ones an attacker could actually exploit in your environment, with the evidence behind every answer. AI-SCA covers your open-source dependencies, and AI-SAST runs on every pull request and across your entire codebase.

Instead of applying static rules about what matters, Maze’s AI works out what context each vulnerability needs and gathers it from your code, your build, and your cloud, the way your best security engineer would. Because Maze looks at your code, build, and cloud together, it can tell you whether a vulnerable dependency is exploitable given where and how that code runs. Maze then fixes where your developers work, writing a fix that matches your code and opening a pull request for the developer who owns it.

Key capabilities of Maze Code:

• AI-SCA for dependencies: Uses AI to find vulnerable dependencies, direct and transitive, and investigates every one, including the backlog you already have, with code and cloud context to decide whether it is exploitable. If you already run something like Dependabot and want to keep it, Maze will investigate, triage, and deduplicate those findings too.
• Multi-hop reachability analysis: Goes beyond checking whether code directly calls a vulnerable function. Maze uses AI to trace the path from an entry point to the vulnerable function, however many hops deep, then checks whether an attacker can control what reaches that code and whether the code is even running.
• Context-aware review across code and cloud: Traces each vulnerability through the codebase and the cloud environment. A vulnerable library is treated as more urgent when it runs in a public-facing production container.
• Exploitability-based prioritization: Ranks exploitable findings by risk to your environment, so developers spend less time on noise. On average, Maze finds that over 70% of vulnerabilities are not exploitable, and those are closed with the full reasoning behind the decision.
• Code-matched fixes routed to owners: Writes fixes that match your existing code and sends them as pull requests to the developer who owns the code. When no fix exists, Maze recommends a mitigation.
• CI/CD and pull request integration: Runs in your CI/CD pipeline and shows findings at the pull request, and fixes can go to the coding agent your team already uses, such as Claude Code or Cursor.
• Unified code and cloud findings: Maze Code and Maze Cloud gather context and share it across every investigation, producing one unified ticket per issue.

Want to see which of your dependency vulnerabilities are actually exploitable? Learn more about Maze Code