Coinminer and npm: What you see is not always what you get

Russia's war on Ukraine has resulted in increased malicious activity in cyberspace. Even before the Russian aggression started, malicious actors connected to the Russian state were quite active on the supply chain attack field, with the biggest incident probably being the SolarWinds compromise. Security analysts presume that more of these supply chain compromises exist — they just haven’t been detected or disclosed (yet).

Still, the growing number of software supply chain incidents is forcing the security community to improve security procedures and standards, in order to enforce verifiable security and integrity of software products. The SLSA framework is an example of a security framework designed to provide an industry standard to confront potential risks related to the software supply chain. The SLSA framework divides security threats into three main groups: source threats, build threats, and dependency threats, based on where the potential threat is introduced.

To detect and mitigate security risks, every piece of software should go through some form of software auditing to detect the presence of previously described threat types. However, many software development organizations aren’t yet aware of some of these threat vectors. They focus only on source code-related threats, letting the rest pass undetected. For example, source code analysis (SCA) helps you detect threats very early in the development process, lowering the costs of fixing the issue. But it shouldn’t be the only tool in your security tool belt. SCA can't assess the integrity of the precompiled dependencies or the integrity of your final deliverables. However, such elements have to be verified if you want to have confidence that the product you ship hasn’t been tampered with and doesn’t contain unwanted functionalities.

I know what you're thinking: "Sure. But how likely are we to be the target of a supply chain attack?" The answer is: more likely than you want to believe. Here's how a simple crypto mining functionality can unknowingly be included into your software if you rely only on the source code review.

Public Package Repositories: A Growing Risk

When looking at supply chain security, public software package repositories are becoming a pain point in the whole ecosystem. Malicious actors like to target package repositories for many reasons. The first is their growing popularity. Developers like to use public packages because they provide an easy way to implement new functionality. Developers need only install the package and upgrade the entire dependency tree. The second reason public packages are a target of attack is the lack of security practices governing them. As it stands, there is no standardized security protocol for including public packages from such repositories into private and proprietary software products. Finally, there is the fact that security analysis of packed software components is significantly harder than typical code reviews. This results in a foggy security view of the overall application. Rather than wade into that fog, however, developers often maintain an uncritical and unjustified trust that third-party components they use are secure. Or, they are willing to trade security for expedience - a faster way to implement needed functionality. Needless to say: this security compromise often comes at the cost of unexpected security compromises.