With each report, include whether or not the affected dependency is a dev dependency

[ehuelsmann]

Almost all issues reported on our repository (ledgersmb/LedgerSMB) are filed against dev dependencies. The vulnerabilities are being reported with an attack vector Network, but in our case the attack vector becomes Local (because the development setups aren't publicly accessible) or they require social engineering skills where an attacker convinces a developer to merge code which triggers this vulnerability. Both of these situations warrent much lower ratings than the standard CSSv3 ratings.

Please:

1. Indicate that the affected components are dev dependencies to allow prioritization as such
2. Allow us to dismiss vulnerabilities, indicating that the risk for our repository is much lower than the standard CSSv3 rating

Thanks in advance!

[mattt]

Thanks so much for sharing your idea, @ehuelsmann. I agree that distinguishing dev dependencies would be useful for a lot of folks, for exactly that reason — the threat model for things running locally seems quite different from things running in production. That high-severity ReDoS vulnerability, for example, may not be too concerning if it only affects a build tool.

We're definitely interested in solving this alert fatigue / "boy who cried wolf" situation, and think this could be a good first step.

See also #4146

[michaelmworthington]

Is this the implementation? - https://github.blog/changelog/2022-06-23-dependabot-alerts-filter-alerts-by-the-scope-of-the-dependency-runtime-and-development/

[jeffwidman]

Yeah, I think this is resolved by https://github.blog/changelog/2022-06-23-dependabot-alerts-filter-alerts-by-the-scope-of-the-dependency-runtime-and-development/.

Also, to clarify, this issue is about the alerts, whereas this repo is for the code that creates version-bump PR's (which may be triggered to rectify alerts)... so going forward, issues about security alerts themselves rather than PR's from security alerts shouldn't be filed against this repo.