Phylum’s primary focus is around emerging open-source software supply chain threats, particularly those spaces uncovered by existing SCA solutions. Vulnerability management has historically been the primary focus for most application security programs, with malicious code being viewed as more of an endpoint problem. On the contrary, the volume of new overtly malicious activities in the open-source ecosystem has grown to such a degree that it absolutely dominates the new emerging application security issues.
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.
The S2C2F addresses popular gaps in today’s appsec programs by adding additional maturity levels around OSS consumption and management that go well beyond vulnerability management, triage, and remediation.
Two of the three major goals outlined in the framework seek to address:
The framework includes four levels of maturity:
This level is essentially achieved through the use of an SCA product, and the manual application of software updates as issues are identified.
This level goes a bit beyond just incorporating an SCA solution, and requires some additional controls, processes, & policy - including the use of a private registry or mechanism to ensure that the package leveraged is inline with organizational requirements.
This level falls firmly within Phylum’s wheelhouse - providing protection against emerging threats and issues, and enabling defense and validation before packages are downloaded.
While the positioning in the framework is more aspirational, Phylum provides the advanced SBOM validation and management needed to set a foundation for how SBOMs will evolve.While other tools mostly cover L1 and parts of L2, we built Phylum to focus primarily on the malware defense and aspirational categories of the framework.
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.
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.