Generally speaking, malware translates less to passive flaws in the attack surface of an application, and instead references packages that actively exhibit undesirable behavior - overt behavior that is very likely to lead to an active compromise or inherently represents a great increase in liability.

This includes perpetrators of dependency confusion - a technique where packages are published to public repositories in a deliberate attempt to collide with the name of private, internally controlled packages in order to trick the package management software into installing the author’s package to gain execution. Similarly, malware includes reputable packages that suddenly take confidential information from a local system, like production credentials, signing keys and other sensitive data, and ship it off to a remote server.

In each of these cases, the intent of the author is irrelevant - there is a clear business risk to utilizing a package that exhibits this functionality, and it should absolutely be examined prior to consideration for continued use.

Not only have many major historical compromises come through maintainer accounts, such as the relatively recent ua-parser-js incident, but there are other concerns that are entirely out of an author’s control. For example, Github recently purged a large amount of Russian software developer profiles.

Actions like this leave packages orphaned, without active maintainers, leaving those packages at high risk for compromise.

To make matters worse, it is often the case that software developers who publish verifiably malicious packages are able to retain the other software packages that they maintain. This creates other potential avenues where they may be able to continue to influence portions of the open source ecosystem.

As a critical portion of the software supply chain, it is impossible to understand the provenance of a piece of software without understanding the history and intent of the maintainers and contributors responsible for its development.

At the early stages of development, when selecting a particular tool or library, it is crucial to understand how robust and well-maintained that particular product is, which can be a substantial challenge when also attempting to consider its upstream dependencies and the tools and infrastructure it depends on for releases.

Understanding the test posture (i.e. does it have tests at all? What does the coverage look like?), documentation level, and how responsive its maintainers are historically are all critical.

It is also important to understand what the readiness level of a new package version is before choosing to adopt it. Fundamentally, how much has the new release changed from the previous version? For other projects that utilize this package, how many have rolled back to a previous release? All of these are strong indicators that a migration to the new release may be premature.

Vulnerabilities represent fundamental flaws that have been introduced into a software project. Their introduction may be either accidental or intentional, but the result is the same: software projects that rely on them will be vulnerable to compromise.

From the Equifax breach, which resulted from an old, unpatched dependency in an application, to the much newer Log4J debacle, vulnerability management and mitigation continues to play a critical role in application security.

The number of libraries that modern applications leverage has grown absolutely massive, and the number of findings surfaced has grown along with it. Vulnerabilities must be looked at, in depth, using a three-dimensional approach.

From GPL violation lawsuits to M&A risk management, licenses make up an important portion of the risks reflected by open source components.

Much like vulnerabilities, the landscape of potential license pitfalls has evolved in recent years. Risks such as the misuse of viral licenses that may infect proprietary code and put intellectual property at risk continue to be problematic, but issues such as unlicensed or improperly licensed projects, or shifts in license provisions by the maintainer have also begun to emerge.