Repository: dependabot/dependabot-core

Issue #5741: npm erroneously reports no longer vulnerable with multiple versions of dependency.
Created: 2022-09-17T20:00:39Z
An npm project is allowed to have multiple versions of the same dependency in the tree. When parsing the dependency we consolidate the different versions using the DependencySet. This retains the lowest version of the dependency seen with the expectation that the lowest version is the oldest and most likely to be vulnerable (or at least most noteworthy to call out in the update PR).
However, we've seen this can lead to confusing states when there is a vulnerability that affects some versions of the dependency but not the lowest version. In this case Dependabot incorrectly reports that no security update is needed.
Fixing this will be a bit of a lift because dependabot-core code has a number of places that assumes there will only be one version of a dependency in the tree.
Related:

#4701 👈 Primary root cause
#4222
#2389
#1693 👈 aliased packages can also result in multiple versions of a single dependency to be installed at the top level

Duplicate issue #4222: Dependabot shows an alert which it says is no longer vulnerable. 
Created: 2021-09-14T05:42:47Z
There are couple of alerts eg: No security update is needed as browserslist is no longer vulnerable where the patched version is 4.16.5 however the app updated the dependency to 4.17.0 , so technically the issue should go away.
So what we are observing is that,  alert is still present , however on details page it says a message "alert is no longer vulnerable" .

Looking into vulnerability itself, it says nothing about versions greater than 4.16.5 , so maybe thats why alert persist(this is my guess) . I believe this is a bug as the alert should be removed .
package manager-> npm
package -> browserlist
CVE --> CVE-2021-23364
language- > JavaScript
package lock file -> ui/yarn.lock
dependabot.yml :
version: 2
updates:

package-ecosystem: npm
directory: "/"
target-branch: "dependabot-updates"
schedule:
interval: monthly
package-ecosystem: npm
directory: "/ui"
target-branch: "dependabot-updates"
schedule:
interval: monthly

Closing comment (2022-09-17T20:47:38Z): So I learned a little more from teammates about npm (an ecosystem that I've never worked with directly myself).  Here's my current understanding:

The alerts are triggered by manifest parsing code that is a separate code path from dependabot-core's parsing code. So if the alert manifest parsing code thinks the repo is still vulnerable, the alert will persist.
npm allows multiple versions of a dependency in the dep tree... and these are used in the code at runtime... the newest is not superseding the old one. So if those exist, you're still vulnerable.
dependabot-core has a known bug where it only updates the lowest version of a dependency... so Dependabot may try to create a PR, then report that npm is no longer vulnerable, when in fact a later version of the dependency is vulnerable and is still in the tree. That's tracked in #5741
The alerts are generated based on information in the GitHub advisory database. So if that database lists all versions > 0.16.5 are vulnerable, but the maintaner just pushed v0.17.0 which fixes the issue, then the alert will not disappear until the advisory database is updated. Thankfully, you can submit a PR to the advisory DB to fix an incorrect version specifier.

So I suspect that the majority of these cases are symptoms of #5741.
As far as reporting additional cases, first take a look at your manifests to see if it matches the behavior of #5741. If it's something different, then file a new issue.
If at all possible, please include a link to a public repo that can reproduce the problem. That should generally be possible, but if for some reason it's not you can file a support ticket instead with a link to your private repo.
And to be clear, we don't mind more issues, as long as you've done your homework to ensure they're valid.
In the meantime, I'm going to close this issue as the original browserlist issue is resolved and if we leave it open it'll continue to be a "catch-all" ticket... Unfortunately catch-call issues aren't really helpful because while the symptoms may be similar, the root cause may be entirely different.