You can’t secure what you can’t see
Even in the age of LLMs, the most fundamental problem in software composition analysis (SCA) has been elusive to solve at scale: producing an accurate inventory of dependencies with their versions and tree structure across an entire codebase.
Scale and velocity of modern applications mean constantly shifting dependency versions. Codebases sprawl across multiple languages and ecosystems. Transitive dependencies are notoriously difficult to inventory correctly, especially when imported via private packages. Because of these challenges, the inventory of dependencies in an organization’s codebase is often incorrect in frustrating and subtle ways that reveal themselves over time.
This meant many customers have had to get by with only a partial picture of the packages they use. But in a world where malicious dependencies downloaded from trusted package managers can compromise your entire org, having a comprehensive and up-to-date dependency inventory can be the difference between being impacted by a zero day attack and being unaffected. Besides, an accurate inventory is the foundational basis of finding vulnerabilities, handling compliance, and answering customer questions.
At Semgrep, we've long recommended developers adopt lockfiles, where possible, for the security benefits of pinned versions. But our customers are accountable for securing vast codebases built on package managers that don't rely on lockfiles — and the majority of enterprise Semgrep customers have critical code in exactly those ecosystems.
Resolve dependencies at scan time
Today, we’re covering that gap. With Dynamic Dependency Resolution, Semgrep Supply Chain can now accurately inventory dependencies without lockfiles—resolving full dependency trees using a combination of manifest parsing and repository integration with package managers and private registries.
Wherever Semgrep detects a project with missing or incomplete lockfiles, it invokes the appropriate package manager commands to resolve dependencies at scan time. This includes transitives that aren't declared in the manifest. For example, for Maven projects, Semgrep reads your pom.xml and resolves the dependency tree with Maven's own resolution logic.
Any dependencies that exist but aren’t stated in a lockfile or manifest file are still counted in the inventory, giving you the complete picture — direct dependencies, transitive dependencies, and full tree structure — without changing build processes, maintaining extra CI steps, or limping by with partial coverage.
Here's what's supported in the beta program today:
In your CI infrastructure: public beta for Java (Maven), Kotlin (Gradle), C# (NuGet), and Python (setup.py); private beta for Scala (SBT)
In Semgrep’s managed infrastructure: public beta for Java and Kotlin (Maven and Gradle).
Private package manager integration: public beta for Artifactory and Nexus Cloud; private beta for on-prem registries
Complete visibility with private registry integration
Complete dependency resolution also requires access to a private package registry. For any internal packages hosted in Artifactory or Nexus, resolving those packages and their transitive dependencies requires connecting to that registry.
It’s not always obvious to an AppSec team that hasn’t connected a registry that they only have partial coverage without this kind of integration. In such cases, dependency resolution is silently incomplete, or can even fail in the case of gradle, leading to blind spots in the SBOM that are not obvious, and can be very painful in the event of a malware incident.
Dynamic Dependency Resolution allows private registry integration directly from the Semgrep App Platform. Simply connect and authenticate to any supported registries, and Semgrep Supply Chain will resolve the full dependency tree, including any transitive dependencies of private packages which cannot be covered any other way.
.jpg)
