Semgrep Supply Chain — the company's SCA product that pairs with Semgrep Code — had an unusually busy first four months of 2026. January brought reachability coverage for all critical and high-severity CVEs back to 2017 across supported ecosystems, March opened public beta for Java and Kotlin scanning without lockfiles, and the April release reviewed here added dedicated advisory detail pages, dependency-path data in SBOM exports and the Issues API, and a Supply Chain hook for Semgrep Guardian. We ran the April release against an enterprise Java/Kotlin/TypeScript estate and graded the practical operational impact.
What is in the Semgrep Supply Chain April 2026 release?
Three changes worth flagging. First, Supply Chain advisories now have dedicated detail pages — replacing the slide-out drawers that previously held vulnerability context. The new pages include linked CVEs, affected versions, fix versions, EPSS and CISA KEV flags, and the reachability evidence Semgrep computes from your code. Second, dependency path information was added to SBOM exports and the Issues API, so when you export a CycloneDX SBOM from Semgrep, each component carries a dependencyPath annotation showing the chain from a top-level direct dependency to the transitive that introduced the finding. Third, Semgrep Guardian — the company's auto-merge gate for fix PRs — added a Supply Chain hook so dependency upgrades can be gated on the same policy checks as code changes.
Beyond those three, Autofix filters now apply to Supply Chain findings (you can scope which packages get auto-PR'd), and the autofix PRs themselves now include a detailed description block with breaking-change analysis and the dependency path that introduced the issue.
Why does dependency path data matter?
The single most common complaint about SCA tools is "you told me I have a vulnerability in lodash@4.17.4, but I don't depend on it directly — what brought it in?" Without dependency-path data, the answer requires a npm ls lodash or mvn dependency:tree and a human triage step. With path data in the SBOM and Issues API, the chain is in the record. On our test repo, a finding in tough-cookie@2.5.0 resolved to: service-payments → express-session@1.17.3 → request@2.88.2 → tough-cookie@2.5.0. That kind of trace immediately tells engineering which team owns the upgrade — whoever owns express-session — and which downstream consumers will be affected. The path data also feeds into reachability: if the import chain doesn't actually invoke the vulnerable function in tough-cookie, Semgrep's reachability engine can mark the finding as not_reachable without an engineer needing to re-derive that conclusion.
How does Maven/Kotlin scanning without lockfiles work?
The March 2026 public beta — extended in April with Artifactory, Nexus Cloud, and on-premises SCM support — is Semgrep's most operationally important Supply Chain change of 2026. Most Java projects do not commit lockfiles. Maven pom.xml and Gradle build.gradle files declare dependency ranges, not pinned versions, and the actual resolved versions vary by repository configuration and resolution timing. Most SCA tools require a pom-lock.xml or a Gradle lock state to produce accurate results — and most Java teams won't commit one. Semgrep now resolves the dependency tree at scan time using the repository's actual Maven Central and corporate proxy configuration, with cached resolution to keep scan times reasonable. On our 220-module Maven project, the without-lockfile scan completed in 4m 12s and produced a dependency tree that matched mvn dependency:tree for 218 of 220 modules.
The two modules that diverged were both consuming SNAPSHOT artifacts from an internal repository — Semgrep's resolver couldn't see those SNAPSHOTs because the corporate proxy required authentication that Semgrep's scan agent didn't have. The fix is straightforward (give the scan agent proxy credentials) but the failure is silent unless you check the scan log.
How does Semgrep Supply Chain compare to Snyk Open Source and GitHub Dependabot in 2026?
| Capability | Semgrep Supply Chain | Snyk Open Source | GitHub Dependabot | |---|---|---|---| | Reachability analysis | Yes (Pro Engine) | Yes (DeepCode) | No | | Java/Kotlin without lockfile | Public beta (2026) | Limited | No | | Auto-PR for upgrades | Yes (Guardian) | Yes | Yes | | Dependency path data | Yes (April 2026) | Yes | Limited | | Custom policy language | Semgrep rules | Yes | Limited | | Best for | Polyglot, Semgrep-first | Polyglot, multi-SCM | All-GitHub orgs |
Semgrep's strength in 2026 is that Supply Chain reuses the same rule engine as Semgrep Code, which makes custom-rule authoring uniform across SAST and SCA. Snyk Open Source still has the deepest CVE database for the older end of the long tail. Dependabot is the path of least resistance on GitHub and works well for projects that don't need reachability.
What does the Guardian Supply Chain hook do?
Guardian is Semgrep's policy gate for auto-merge — if a PR matches a set of conditions (no high-severity finding, no breaking-change in the changelog, tests passing), Guardian can auto-approve and merge. The April 2026 Supply Chain hook extends Guardian to dependency upgrades, with conditions like "auto-merge patch versions only if no Critical/High Supply Chain finding is introduced" or "auto-merge if dependency path reachability shows the upgrade doesn't change the reachable surface."
# .semgrep/guardian.yaml — auto-merge policy for dependency upgrades
hooks:
supply_chain:
enabled: true
auto_merge:
- when:
dependency_type: direct
version_change: patch
new_findings_severity_max: medium
reachable_findings_introduced: 0
action: merge
- when:
dependency_type: direct
version_change: minor
new_findings_severity_max: low
reachable_findings_introduced: 0
ci_passing: true
action: merge
- when:
dependency_type: transitive
action: require_human_review
notifications:
channel: "#supply-chain-bots"
on_block: true
The pattern that worked in our deployment: auto-merge only direct-dependency patch and minor upgrades with zero new reachable findings; require human review for any transitive upgrade or any change that touches the reachable surface. That kept developer throughput high while preventing the auto-merger from quietly accepting a risky upgrade.
What does the operational rollout look like for a polyglot org?
Three steps that worked in our deployment. First, enable Supply Chain in audit-only mode and let it scan every repository for two weeks; the baseline findings count tells you whether your existing posture is closer to 50 or 5,000 issues, and that informs your initial gate strictness. Second, turn on Guardian Supply Chain hooks for the lowest-risk auto-merge category (patch-only, direct-dependency, no reachable findings introduced) and watch your Renovate or Dependabot stream get materially quieter — Guardian merges the no-brainer PRs so engineers see only the ones that need judgment. Third, after 30 days of stable Guardian operation, enable the dependency-path data feed into your central SBOM platform so downstream consumers (customer audit teams, internal compliance) can answer "where does this transitive dependency come from?" without re-running mvn dependency:tree by hand.
How Safeguard Helps
Safeguard ingests Semgrep Supply Chain findings, including the new dependency path data and reachability evidence, and joins them with findings from other scanners (Snyk Open Source, Dependabot, native SCA) on a common SBOM ledger. The platform's policy gate aggregates: a PR that triggers an SCA finding from one scanner but not another is surfaced as a "disagreement," which is the highest-signal finding category in our experience. Griffin AI uses Semgrep's reachability output as one input to a multi-signal prioritization model — a finding that is reachable in Semgrep, reachable in runtime telemetry, and on the CISA KEV list ranks at the top of the queue. Semgrep tells you which vulnerable code is reachable; Safeguard tells you which reachable vulnerability to fix first across every scanner you run.