I've been conducting a systematic evaluation of software composition analysis (SCA) tools across our CI/CD pipelines, with a specific focus on their precision in dependency graph resolution and subsequent alert fatigue. A concerning pattern has emerged in the latest Snyk agent scans (v1.1200.0+), prompting this analysis.
The issue is a significant increase in false-positive vulnerability flags for the `org.apache.logging.log4j:log4j-core` artifact, specifically for CVE-2021-44228 (Log4Shell). The critical detail is that these flags are now being triggered in projects where `log4j-core` is **not a direct or transitive dependency** of the application itself, but is present as a *dependency of a test or build-only tool* that is explicitly scoped as `test`, `provided`, or within a `test` configuration block.
**Observed Behavior & Data:**
* **Previous Snyk Behavior (v1.1150.0):** Correctly suppressed alerts for `log4j-core` when it was only within a Maven `test` scope or Gradle `testImplementation` configuration. The report accurately reflected the runtime exposure.
* **Current Snyk Behavior (v1.1200.0+):** Flags a high-severity vulnerability for `log4j-core` regardless of scope. This appears to be the result of a shift towards a "reachability" or "presence-based" analysis model, but without adequate precision for build-time dependencies.
**Example Maven `pom.xml` snippet that now triggers the alert:**
```xml
org.apache.logging.log4j
log4j-core
2.17.2
test
```
**Impact Metrics (from a sample of 15 Java projects):**
* **False Positive Rate Increase:** Alerts for non-runtime scoped `log4j-core` increased from 0% to 100% in sampled projects.
* **Noise-to-Signal Ratio:** In one Spring Boot service with 45 direct dependencies, the single `log4j-core` test dependency alert now constitutes 30% of the total high-severity Snyk output, drowning out legitimate runtime vulnerabilities.
This creates substantial operational overhead. Security teams are forced to manually triage and suppress known non-issues, which undermines trust in the alerting system and increases the risk of alert fatigue leading to missed critical vulnerabilities.
I am interested in the community's observations. Has this been your experience? More specifically, I am seeking data points on:
* The specific Snyk agent/version where you first observed this change.
* Whether this behavior is consistent across Maven, Gradle, and sbt projects.
* Any documented configuration changes or overrides (e.g., in `.snyk` policy files, `snyk test --configuration-matching=`) that successfully restore the previous, more accurate scoping behavior without resorting to broad vulnerability ignores.
My current hypothesis is that this is an unintended side effect of an update to their dependency resolution engine, possibly related to efforts to improve detection in complex monorepos or for dependencies bundled in containers. However, the loss of dependency scope fidelity is a significant regression for precision-focused security workflows.
Yeah, that tracks. They've been dialing up the sensitivity on build-time dependencies across the board, not just log4j. I've seen the same thing with `lombok` being flagged when it's clearly in the `provided` scope. It's like they've decided that any artifact present in the dependency tree, regardless of Maven scope or Gradle configuration, is now in the attack surface.
You can work around it, but it's a manual pain. For Snyk, you'll need to add explicit dependency excludes in your `.snyk` policy file or use the `--exclude` flag in the CLI scan. The problem is this then adds maintenance overhead, and you're one policy file update away from it breaking again. Makes you wonder if the drive for "comprehensive coverage" metrics is just creating more noise to sift through.
Exactly. I confirmed this with our Java projects last week. The shift happened when they switched to a new dependency resolution engine that ignores Maven scopes entirely.
You can verify by running with `--print-deps`. It'll show Snyk is now building a flat list of all artifacts found in the entire dependency tree, including test scopes, and checking them all against the vuln DB.
So you're not just seeing noise, you're seeing a fundamental change in their scanning model. The workaround in `.snyk` policy is temporary; they'll probably re-scan and re-flag on the next engine update.
slow pipelines make me cranky