apache
chore: dependency-submission: skip test scope
Currently, dependency-submission would submit all dependencies to https://github.com/apache/pekko/security/dependabot , including test dependencies. We then added explicit dependencies to the build to squash warnings about outdated test dependencies (#1181, #1313 and #1344).
With version 3, sbt-dependency-submission now supports ignoring scopes. This PR proposes to ignore the test scope, and remove the explicit dependencies from the build.
Of course, we want our developers to be secure as much as our users. From that perspective you could say we'd want to remove 'insecure' dependencies even from the test scope. In practice, however, I think it's really unlikely that a vulnerability in a test scope dependency would lead to a realistic attack on a developer. For that reason, I think ignoring this scope for dependency-submission and keeping the old dependencies in the build removes some development friction, which balances out the risk of testing with outdated dependencies. If there'd be a 'malicious' dependency out there, I expect we'd learn about it through other channels.
(do we need to request sbt-dependency-submission@v3 to be whitelisted at Infra?)
Closes #1317
It's hard to tell if the action will be pre-approved. I think the Infrastructure team wildcard the version but we'll only find out when we merge this.
It's hard to tell if the action will be pre-approved. I think the Infrastructure team wildcard the version but we'll only find out when we merge this.
(this has since been updated with #1551)
@mdedetrich has previously argued that test and build only dependencies can still affect users who run tests or other builds on their own machines. I'm on the fence because nearly all CVEs reported for jars are about runtime issues as opposed to issues around build poisoning or harvesting machine data.
@mdedetrich has previously argued that test and build only dependencies can still affect users who run tests or other builds on their own machines. I'm on the fence because nearly all CVEs reported for jars are about runtime issues as opposed to issues around build poisoning or harvesting machine data.
Yeah, I agree we should be mindful of attacks on developer machines, but I'd expect those would get some publicity and could be checked for in a 'targeted' way rather than using CVE scanning for that.
It's a trade-off, but I think it's more helpful to have a good signal-to-noise ratio in the dependabot security alerts tab than it is to also track build-time dependencies there.
The security issues count went up after this was merged.
https://github.com/apache/pekko/actions/runs/12631453495
7 new issues in https://github.com/apache/pekko/security/dependabot (4 increased to 11)
The submission json has 'development' scope. This is a possible reason why we are submitting the old versions of the transitive dependencies to dependabot.
"com.github.docker-java:docker-java-core:3.4.1": {
"package_url": "pkg:maven/com.github.docker-java/[email protected]",
"metadata": {
"config": "TestJdk9"
},
"relationship": "direct",
"scope": "development",
"dependencies": [
"com.fasterxml.jackson.core:jackson-databind:2.18.2",
"com.google.guava:guava:32.1.1-jre",
"com.github.docker-java:docker-java-api:3.4.1",
"com.github.docker-java:docker-java-transport:3.4.1",
"org.slf4j:slf4j-api:1.7.36",
"commons-io:commons-io:2.13.0",
"org.apache.commons:commons-compress:1.21",
"org.apache.commons:commons-lang3:3.12.0",
"org.bouncycastle:bcpkix-jdk18on:1.76"
]
},
You're right, I seem to have missed some scopes/modules - https://github.com/apache/pekko/pull/1689 should help