github
Private NPM appearing as malware in public repo
Greetings, I see a large influx of similar issues like this so sorry for only on to the pile.
It looks like a private, and only internally used npm package we have called @ibm-pipeline/logging is not only published in the public registry, but it is also being flagged as malware.
As far as I can tell, our team had nothing to do with this and it very well could be a bad actor that published the public package of the same name.
However, our local .npmrc and package-lock.json files are configured to pull absolutely everything from our private npm registry, so I'm perplexed as to why running npm audit pulls up the alert for the public package as that isn't what we're installing and not how I understood audit to work.
Links: https://github.com/advisories/GHSA-g4xx-7vwp-pq9p https://www.npmjs.com/package/@ibm-pipeline/logging
Output:
harlow$ npm audit
# npm audit report
@ibm-pipeline/logging >0
Severity: critical
Malware in @ibm-pipeline/logging - https://github.com/advisories/GHSA-g4xx-7vwp-pq9p
No fix available
harlow$ npm view @ibm-pipeline/logging
@ibm-pipeline/[email protected] | UNLICENSED | deps: 3 | versions: 16
logging framework
dist
.tarball: <NOT THE PUBLIC REGISTRY>/@ibm-pipeline/logging-1.0.14.tgz
.shasum: <SHASUM>
.integrity: <SHA>
dependencies:
joi: 17.5.0 nconf: 0.12.0 winston: 3.3.3
dist-tags:
latest: 1.0.14
Is this a false positive, or something we should be concerned about?
I'm especially curious about npm audit pointing to the public package despite the local configurations.
Thanks in advance for your time.
I believe I understand because I saw a similar situation.
They're alerting because they see a reference to a package name in which they found malware. In this case, the @ibm-pipeline/logging package. They don't know your using a local package with that name. They do know there is an npm package with that name which had malware (in this case, npm replaced the package with a no-op package 2 months ago). The recommended solution to avoid the alert (and risk) is to scope internal packages to scopes you own.
You got the alert now because they kicked off an effort to publish advisories for malware packages yesterday. https://github.blog/2022-06-15-github-now-publishes-malware-advisories-in-the-github-advisory-database/
We are NOT using a local package, we ARE using our own internal scope. Please do not copy&paste replies for people without reading their write ups.
What is occurring is we are getting alerts for a public NPM of the same name, despite the fact our configuration and .npmrc is pointing only to our own internal registry.
Registering our own internal scopes and package names on the public registry to prevent bad actors from using them is not feasible.
So the question is: why is npm audit alerting us of the public package if we're not actually using it?
Thank you for your time.
@HarlowIBM you should not be using an internal scope that you do not ALSO own on the public registry, for reasons like this, as well as supply chain attacks.
I do agree that npm audit shouldn't be warning about a non-public-registry package, but you shouldn't be in this situation in the first place.
@HarlowIBM @Straubulous thank you for proactively sharing your experience and concern.
On June 15th, we announced GitHub added malware advisories to the GitHub Advisory Database, though we do not send Dependabot alerts on them.
We found that the majority of those alerts in question (like the one you raised) were for substitution attacks. During these types of incidents, an attacker would publish a package to the public registry with the same name as a dependency users rely on from a third party or private registry, with the hope a malicious version would be consumed. As Dependabot doesn’t look at project configuration to determine if the packages are coming from a third-party registry, it has been triggering a notification for packages with the same name from the public npm registry. To resolve this issue in the short term, we we paused all Dependabot notifications on malware advisories and will work to determine how to best notify customers of being the target of a substitution attack going forward.
If you are the owner of this package, it seems your package was the target of a substitution attack. However, it does not mean that there is an immediate action to be taken on your part as the malware has already been removed from the npm registry.
If you think that this advisory has been created in error, you can reach out to NPM support to clarify!
I'm going to close this Issue as there is no further action that we can take, but please reopen a new one if you have another ask!
