-
Notifications
You must be signed in to change notification settings - Fork 151
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: dependency-submission: skip test scope #1392
base: main
Are you sure you want to change the base?
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. |
0d7d96f
to
fbd6ea3
Compare
(rebased to fix merge conflict) |
fbd6ea3
to
40cd9f0
Compare
40cd9f0
to
3db6dee
Compare
(this has since been updated with #1551) |
Rebased again to fix conflicts |
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.
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