Description
At the Mendeley organisation internally we use an @mendeley-internal namespace for NPM packages which should not be released to the public (internal tooling, packages which use internal-only APIs, etc).
A couple of years ago we employed a pen-testing organisation called SynAck to pen-test our systems, and they identified that we had neglected to register @mendeley-internal as a public NPM namespace, which was a potential security vulnerability. To test if it was exploitable they registered the namespace and uploaded a test package called @mendeley-internal/api which did nothing but dial home to their server to confirm the existence of an exploitable vulnerability, to see if any of our systems would pick it up.
- One of our build systems was misconfigured and did pick up the external package (since patched), and NPM reacted commendably quickly itself, blocking access to the package and organisation. In the intervening time we have since acquired ownership of the public @mendeley-internal namespace (along with any other public namespaces corresponding to internal ones) and unpublished the relevant package, but now every time we run an npm audit for a tool which uses the (legitimate) @mendeley-internal/api package (even when the tool only ever retrieves the package from our internal artifactory and does not touch the public NPM repo), we get a spurious warning (GHSA-9cf5-3q4m-6qh3) that the package includes malware.
As this was never a genuinely compromised package (as the pen-testing team were working under our direction), never had a destructive payload and has since been prevented from being exploited by our acquired ownership of all relevant NPM @-organisations, is it possible to have this advisory expunged from the database, or must every tool which uses our internal API package falsely report a non-existent vulnerability for the rest of time?
Many thanks for your consideration,
James Palmer
Engineering Manager,
Mendeley Ltd.