🧩Software Composition Analysis (SCA)

Summary

Arnica can identify risks in internal and 3rd party packages. Arnica provides a recommendation on the directly embedded packages to minimize the mitigation effort, where possible.

Supported languages

Language	Files	Reachability
.Net	packages.lock.json, packages.config, .deps.json	Coming Soon
C, C++	conan.lock
L	mix.lock
Go	go.mod
Java	pom.xml, gradle.lockfile, build.gradle, build.gradle.kts, libs.versions.toml	Coming Soon
JavaScript (including JSX, TSX, TypeScript)	package-lock.json, yarn.lock, pnpm-lock.yaml, npm-shrinkwrap.json	Supported
PHP	composer.lock
Python	Pipfile.lock, poetry.lock, requirements.txt	Supported
Ruby	Gemfile.lock
Rust	Cargo.lock
Scala	Coming soon: build.sbt
Swift	Podfile.lock

Risk mitigation recommendation

Trenched mitigation

Arnica enables a trenched mitigation approach for developers, so that a subset of the risks will be mitigated with low operational risk. For example, Arnica can provide a recommendation to have a minor version change (according to semantic versioning) that will fix a certain percentage of vulnerabilities, and another recommendation to have a major version change with a higher percentage of vulnerabilities.

Calculated effective mitigation

A fix of a known vulnerability can potentially introduce another vulnerability. Arnica calculates the most effective recommendation based on a weighed count of vulnerabilities remediated vs introduced. For example, if the existing package version is 1.2.3 and all vulnerabilities were resolved in version 1.4.6, and 1.4.6 introduces new vulnerabilities, Arnica will try to find the next optimal mitigation version that introduces the lowest risk, if any.

In some cases, even the latest package version might have vulnerabilities. Arnica will present that a new vulnerability is introduced in this version, so that you can make more educated decision about the mitigation path.

Automated risk reduction

Development dependencies

Development dependencies are not meant to be executed at runtime. Therefore, when Arnica identifies development dependencies, it automatically changes the status to dismissed and reduce the risk severity to info.

Package depth

Packages located too deep in the dependency tree may not pose the same risk as a directly embedded package. Therefore, Arnica observes the depth of the package in the context of the code and automatically reduces the risk where applicable.

Exploit Prediction Scoring System (EPSS) score and trend

Arnica correlates each vulnerability with the EPSS database to identify the probability of exploitation in the wild in the next 30 days. Based on this feed, Arnica determined if certain vulnerability risks can be reduced further.

Reachability Analysis

Arnica currently supports function-level and method-level reachability analysis, allowing organizations to determine whether a reported vulnerability is actually exploitable within their codebase. Our approach prioritizes efficiency by focusing on high and critical Common Vulnerabilities and Exposures (CVEs) in widely used and commonly adopted open-source packages.

By narrowing our analysis to real, actionable risks, we help development and security teams reduce noise, minimize false positives, and focus their remediation efforts on vulnerabilities that pose a genuine threat to their applications.

Reachability Confidence	Meaning
High	This means the identified CVEs are not only present in the codebase but is actively reachable through execution. Both the finding (CVEs) and the invoked function or method exist within the same branch of the code, ensuring a direct execution path. As a result, the vulnerability has a high likelihood of being exploitable under normal runtime conditions, making it a critical priority for remediation.
Medium	This means the identified CVEs are present in the codebase and has a reachable execution path, but the finding (CVEs) and the invoked function or method exist in different branches. While the vulnerable code is accessible, its execution depends on specific conditions or branching logic. This reduces the immediate likelihood of exploitation but still presents a potential security risk that should be assessed and prioritized accordingly.
Partially Reachable	This means the identified CVEs are present in the codebase, but its reachability is only partially determined. Some vulnerabilities are confirmed to be unreachable, while others lack sufficient reachability evidence. This suggests that while certain code paths do not invoke the vulnerable function, there may still be execution scenarios where exploitation is possible but unverified. As a result, these findings should be reviewed further to assess their actual risk and prioritize remediation accordingly.
Unreachable	This means the identified CVEs are present in the codebase but are not reachable through any known execution paths. All instances of the vulnerable functions or methods are either unused, blocked by control flow logic, or not invoked in a way that would make exploitation possible. Since these vulnerabilities cannot be triggered under normal runtime conditions, they pose minimal immediate risk. However, it is still important to monitor dependencies and reassess reachability if the application code changes in the future.
Not Available	Language is not supported yet, or there are no reachability rules for a specific set of CVEs such as Medium or Low severity findings.

A detailed vulnerabilities breakdown with a high reachability confidence

An example of a critical CVE reachability analysis

Internal packages support

If your development organization leverages shared packages developed in-house and defines them in source code repositories, Arnica identifies these internal packages and recommends fixes within the shared packages.

An example of a recommendation for an internal package