I've been evaluating Semgrep's new Supply Chain (SSC) feature for the past few weeks, specifically against Snyk and GitHub's Dependabot for dependency vulnerability scanning. The core premise is interesting: using the same Semgrep engine for both SAST and SCA by analyzing lockfiles (`package-lock.json`, `Pipfile.lock`, etc.) and applying rules to the dependency graph.
My initial benchmark focused on a mid-sized Node.js and Python monorepo. Here's a comparison of the out-of-the-box findings:
* **Precision:** Semgrep SSC had significantly fewer false positives on transitive dependencies compared to Dependabot's default rules. It correctly ignored several development dependencies flagged by others.
* **Performance:** The scan time was negligible when run locally, but the CI integration added ~45 seconds to our pipeline, which is comparable to Snyk but heavier than Dependabot's native GitHub Actions integration.
* **Rule Customization:** This is SSC's standout feature. The ability to write custom supply chain rules in YAML is powerful. For example, we created a rule to block any indirect dependency that hasn't seen an update in over three years, regardless of CVEs.
```yaml
rules:
- id: stale-transitive-dependency
message: Transitive dependency has had no releases in over 3 years
languages: [javascript, python]
severity: WARNING
pattern: |
dependencies:
...
metadata:
category: "maintainability"
```
The main drawback I've observed is ecosystem coverage. While it handles npm and PyPI well, its support for other registries (like Maven Central) feels less mature compared to established SCA tools. The dependency reachability analysis also isn't as advanced as some commercial offerings—it tells you a vulnerable function is present, but not if your application's data flow can actually trigger it.
Has anyone else integrated SSC into their CI/CD pipeline? I'm particularly interested in how you're managing the custom rule sets across multiple projects and whether you've found the reachability filtering to be practical in reducing noise.
benchmark or bust
benchmark or bust
Ah, that rule customization part is the killer feature, isn't it? Writing a custom rule for stale dependencies regardless of CVEs is a fantastic use case. We did something similar to block any package from a specific maintainer after a messy left-pad style incident years back. Having that logic live right next to our SAST rules instead of in some separate SCA dashboard is a huge win for the team's mental overhead.
I'm curious about that ~45 second CI hit, though. Was that with caching enabled? I found the first run a bit slow, but subsequent runs were much snappier if the lockfiles hadn't changed. Still, it's a trade-off for the extra control.
The precision on transitive dependencies is a big deal. I got so tired of nagging alerts for dev tools in CI pipelines. If it's catching real issues without the noise, that alone might justify the switch from Dependabot's more shotgun approach.
it worked on my machine