An analysis of 203 million files spanning three million software packages conducted by Phylum, a provider of tools that prevent suspicious code from running, finds a 47% increase in the discovery of malicious packages (974) targeting the software supply chains of specific organizations.

In total, in the third quarter of 2023, Phylum discovered 10,201 packages referencing known malicious URLs, with 13,708 packages executing suspicious code during installation. In addition, 5,502 packages attempted to obfuscate underlying code, while 3,662 packages imported dependencies in a non-standard way.

Phylum CTO Louis Lang said the report makes it clear that attacks against software supply chains are not only becoming more targeted but are also increasing in sophistication. For example, 85,805 packages contained pre-compiled binaries, with 1,481 packages surreptitiously downloaded and executed code from a remote source.

The challenge is the pace at which software is being updated is beyond the ability of application development teams to effectively track. Overall, 208,904 packages received at least one update, approximately 7.5% of all packages published in the quarter. On average, there were 5.5 updates per package, averaging 21 days between each update.

Npm, the JavaScript package registry widely used by developers to download packages, served approximately 24 billion downloads in one week alone, with no developers checking to see if any of those packages contained malicious components.

In theory, responsibility for ensuring the security of packages being used to construct applications should fall to application developers. In practice, it’s apparent that DevSecOps best practices that call for the scanning of software components for malicious code and known vulnerabilities are not being widely implemented. As a result, cybersecurity teams continue to be overwhelmed by cyberattacks aimed at applications that are relatively simple to exploit.

As application security continues to become a national security issue, it’s only a matter of time before DevSecOps best practices are more widely implemented, noted Lang. The challenge is often determining who within an organization is responsible for ensuring applications are as secure as possible before they are deployed and then who will be be accountable for making sure any patch required to address a newly discovered vulnerability is applied. That latter issue is especially problematic because most developers spend less than 10% of their time building and applying patches for software that has already been deployed.

No one knows for certain how many vulnerabilities there might be in existing production environments, but it’s more than most organizations can effectively address. The best most organizations will be able to do is identify and prioritize their remediation effects based on not just the severity ranking assigned to a vulnerability but also the actual level of risk it represents to the business.

Of course, some organizations may simply decide to replace an application altogether with one designed with cybersecurity best practices in the first place. Regardless of approach, it’s clear cybersecurity teams have a vested interest in making sure applications are as secure as possible long before they ever find their way into a production environment that is already under siege.