chore: dependency-submission: skip test scope #1392
Conversation
|
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. |
raboof
force-pushed
the
dependency-submission-skip-test
branch
from
0d7d96f to
fbd6ea3
Compare
|
(rebased to fix merge conflict) |
raboof
force-pushed
the
dependency-submission-skip-test
branch
from
fbd6ea3 to
40cd9f0
Compare
raboof
force-pushed
the
dependency-submission-skip-test
branch
from
40cd9f0 to
3db6dee
Compare
(this has since been updated with #1551) |
|
Rebased again to fix conflicts |
raboof
force-pushed
the
dependency-submission-skip-test
branch
from
3db6dee to
ae5d5e6
Compare
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 (apache#1181, apache#1313 and apache#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.
raboof
force-pushed
the
dependency-submission-skip-test
branch
from
ae5d5e6 to
3dfba6b
Compare
|
@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. |
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