Here’s a fix for open source supply chain attacks

TechRepublic contributing writer Jack Wallen is correct that “Open source software has proved itself, time and time and time again, that it is business-grade for a very long time.” Sonatype is also correct that supply chain attacks against popular open source software repositories jumped 650% over the last year. In fact, it’s the very popularity of that open source software that makes it a prime target.

Even though President Biden has called for greater focus on the safety and integrity of open source software, we’re no closer to knowing how to achieve it. Some larger projects like Kubernetes have the corporate backing necessary to ensure significant investment in securing the software, while others may be heavily used but can be the labor of love of a handful of developers. No federal mandate will magically gift the necessary resources to constantly update these less-moneyed projects. 

And yet, there’s hope. Cloud vendors and others increasingly incorporate open source software to deliver comprehensive offerings. Customers may be able to look to them to ensure the security of the code they operationalize.

SEE: Security incident response policy (TechRepublic Premium)

Open source under attack

Open source keeps growing in popularity, to the tune of 2.2 trillion open source packages pulled from repositories like npmjs and Maven in 2021, according to Sonatype’s study. As software becomes central to how most organizations operate, developers must build with ever-increasing velocity. With over 100 million repositories available on GitHub alone, many of them high in quality, developers turn to open source to get great software fast. 

That’s the good thing. But not completely.

Sonatype scoured the top 10% of the most popular Java, JavaScript, Python and .NET projects, finding that 29% of them contain at least one known security vulnerability. As the report continues, the old way of exploiting vulnerabilities in open source projects would be to look for publicly accessible, unpatched security holes in open source code. But now, hackers “are taking the initiative and injecting new vulnerabilities into open source projects that feed the global supply chain, and then exploiting those vulnerabilities.” 

Thus far, Node.js (npm) and Python (PyPI) repositories have been the primary targets. How do attackers infiltrate the upstreams of popular projects? There are a few ways, though the most prominent of which is called dependency or namespace confusion. 

As the report authors noted: “The novel, highly targeted attack vector allows unwanted or malicious code to be introduced downstream automatically without relying on typosquatting or brandjacking techniques. The technique involves a bad actor determining the names of proprietary (inner source) packages utilized by a company’s production application. Equipped with this information, the bad actor then publishes a malicious package using the exact same name and a newer semantic version to a public repository, like npmjs, that does not regulate namespace identity.”

These and other novel attacks are starting to add up (Figure A).

Figure A 

There are at least two difficulties inherent in improving open source security. The first I’ve mentioned: Not every project maintainer has the resources or know-how to effectively secure her code. On the receiving end, many enterprises aren’t quick to patch even known security problems. But that’s not to say things are hopeless. Far from it.

I know the pieces fit

It’s too soon to call it a trend, but RedMonk analyst Stephen O’Grady has highlighted early indicators of an industry shift away from isolated infrastructure primitives (e.g., compute, storage, etc.) and toward abstracted, integrated workflows. As he stated, “[V]endors are evolving beyond their original areas of core competency, extending their functional base horizontally in order to deliver a more comprehensive, integrated developer experience. From version control to monitoring, databases to build systems, every part of an application development workflow needs to be better and more smoothly integrated.” 

All this in an effort to make developers’ lives easier. 

What has made their work harder? In a more recent post he noted, “Where a developer’s first–and at times, only–priority might once have been scale, today it’s much more likely to be velocity.” As noted above, that “need for speed” is pushing developers to embrace open source, just as it’s nudging them to embrace cloud. Anything and everything that removes friction so they can build and deploy software more quickly. Often, they’re getting that open source delivered to them as managed services, which strips away hardware and software friction, allowing developers to move at maximum speed with a minimum of constraint. 

SEE: Vendor management & selection policy (TechRepublic Premium)

But it’s not merely a matter of a cloud vendor making, say, Apache Kafka available as a service. No, what’s happening, said O’Grady, is the packaging of (in this example) Kafka as part of a larger cloud service: “Instead of providing a layer above base hardware, operating systems or other similar underlying primitives, they abstract away an entire infrastructure stack and provide a higher level, specialized managed function or service.”

This brings us back to those supply chain attacks.

If vendors increasingly ship “higher level, specialized managed function[s] or service[s],” they’ll also presumably be on the hook for the provenance and security of the component parts of that service. This should lead more cloud providers to invest in the ongoing development, maintenance and security of these component parts, not to mention contractually standing behind those components for customers. A cloud vendor doesn’t get to ship OpenSSL, as an example, and then point the finger of blame at some hapless open source maintainer if things go awry. The cloud vendor is on the hook for support. 

It’s still early, but hopefully this widespread adoption of open source software to deliver higher-order cloud services will, in turn, lead to widespread contributions to the open source projects upon which these services depend. Purely from a security standpoint, it’s in the self-interest of the cloud vendors.

Disclosure: I work for MongoDB, but the views expressed herein are mine.

Open Source Weekly Newsletter

You don’t want to miss our tips, tutorials, and commentary on the Linux OS and open source applications.
Delivered Tuesdays

Sign up today

Also see