A malicious package downloaded approximately 50,000 times from a node package manager (npm) is providing an object lesson for adopting more DevSecOps best practices.
Security researchers from Tenable discovered a “ambar-src” package that was first published Feb. 13 and then updated again before being discovered. It is aimed at developers building JavaScript applications on Windows, Linux and macOS hosts.
More troubling still, in addition to making use of a naming convention that is similar to a legitimate “ember-source” package, the malicious package was also crafted to evade detection. Specifically, the malware abuses npm’s preinstall script hook, a script that executes during the package-installation process. That preinstall script is a file that is part of the npm package itself that also contains code that launches an operating system-specific single line of code to initiate the full infection chain.
The malware that winds up being embedded then uses well-known web services to set up a command-and-control relay through which data is exfiltrated. That technique makes the traffic look legitimate so it is less likely to be blocked by network security platforms.
Ari Eitan, director of cloud research at Tenable, said the one-liner is hex-encoded to make detection and analysis of the malicious code harder. As such, software engineering teams that discover this malicious package in their software supply chain should rebuild their IT environment on the assumption the existing code bases and underlying platforms have been compromised, he added.
Additionally, software engineering teams should also take this opportunity to ensure they have full visibility across their software supply chains to ensure that only trusted packages are being used to build applications, noted Eitan.
In the wake of a series of attacks against software supply chains that, for the most part, have involved some type of malicious npm package, more software engineering teams are hopefully revisiting DevSecOps workflows. A recent Futurum Group survey finds 39% plan to increase spending on software security testing, followed by additional investments in securing application programming interfaces (APIs).
Of course, some software engineering teams may decide that JavaScript packages downloaded from repositories are just too risky. The better part of valor may be to move to another programming model altogether.
Hopefully, there will come a day soon when AI agents are able to identify and remediate vulnerabilities created by AI coding tools, but in the meantime many DevSecOps teams are simply being overwhelmed by the amount of code that needs to be scanned and remediated, especially as AI coding tools download code from repositories without much regard for quality.
Unfortunately, not nearly enough application developers are cognizant of how they might inadvertently add vulnerabilities to a code base. If a vulnerability is discovered just prior, or worse yet after, an application is deployed the cost of resolving those issues is considerably higher. In fact, all the investments made in DevOps tools and platforms to accelerate deployment can easily become all for naught if the code being created only serves to increase the amount of rework that needs to be done.

