Skip to content
Risk Framework Final

The Phylum Risk Framework

Phylum’s proactive approach to analyzing the risk inherent within the software supply chain is built from years of research and observation.

Instead of taking a retrospective approach by analyzing incidents after they occur, Phylum starts by consuming all available information about open-source packages and structuring the data in a consistent format for analysis. Layers of analytics, heuristics and ML models then comb through the data to find risk indicators. Deductive analysis is then applied to account for the entire context around each indicator, and identified risks are prioritized based on the risk tolerance criteria set by the organization.

This allows Phylum to effectively surface and prioritize meaningful issues before an incident occurs, in a manner that doesn't overwhelm security teams. These risks can then be addressed before leading to compromise, outages, service degradation at runtime or legal liability.

Provenance-Based Risk Approach

To truly mitigate the risk of using open-source software, organizations must continuously analyze all packages published into the numerous ecosystems, in real time and at scale. The open-source ecosystem continues to grow at an increasing rate, but, how do you know what code to trust and why?

At Phylum, we first apply our U.S. Intelligence roots to answer two main questions through an adversarial lens:

  1. How could I gain access to this package?
  2. What are the types of impact that could be applied?

Then, we leverage our practitioner experience to answer the following:

  1. Is this a reasonable component to use?
  2. What are the technical feasibility risks associated with utilizing it?

“Given the large volume of components involved in the development of modern software, surfacing meaningful findings becomes critically important - as does accurately prioritizing issues. Phylum defines the attack surface and conducts the deductive analysis, and users define risk tolerance based on project needs. This combination results in a significantly reduced attack surface, and categorized risk prioritized by business objective”

Brad
Brad Crawford

Vice President of Product at Phylum, co-author of the MITRE ATT&CK Framework

Phylum Overview

Phylum's Five Domains of Risk 

The Phylum Risk Framework covers the broadest range of software supply chain attack indicators in the industry, addressing the entire attack surface and categorizing risk based on specific business objectives. 

Malicious Code

Malicious Code

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.

Author Risk

Author Risk & Reputation

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.

 

 

Engineering

Engineering

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.

Software Vulnerabilities

Software Vulnerabilities

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.

 

 

License Misuse

License Misuse

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.