Security / Contributed

Get a Handle on Your Software Supply Chain

8 Mar 2022 10:00am, by
Jack Aboutboul
Jack Aboutboul is a long-time member of the Linux, open source, and free software community. He brings over 20 years of technology, community, and developer outreach expertise. His previous roles include Community Architect at Red Hat for Fedora and its associated projects, Developer Program Manager at open source eCommerce platform Magento, an early member of the Developer Evangelism team at cloud communications powerhouse Twilio, and CTO of Energizer’s Connect IoT platform. He is currently Community Manager for the popular CentOS replacement AlmaLinux. Jack is passionate about education, technology, open source, IoT and enabling developers to build the best, most secure software possible through great developer experiences.

The software deployed in your organization is probably the most critical piece of infrastructure powering operations and contributing to productivity. If a truck breaks down, logistics arrangements can be made. But if a critical piece of software becomes vulnerable, or even worse, is actively compromised, not only can the organization face devastating legal consequences, but operations may come to a total halt too. Welcome to 2022, where this is no longer fiction, but a reality that’s already been observed multiple times this year.

Let’s talk about two software consumption models, proprietary and open source. Traditionally, in the proprietary software consumption world, you know your vendor and place a great deal of trust in them (and rightfully so for the price) to ensure that your software is always functional, reliable and actively being maintained and patched for security vulnerabilities. The onus is always on them. 

In reality, that was only half true though. What runs on your infrastructure is ultimately your responsibility and no one else’s. The SolarWinds Hack drove that point home. Without a comprehensive information security plan in place throughout your organization and without constantly monitoring files, folders, infrastructure and applications — basically having eyes and ears detecting even the most seemingly benign activity — it turns out that you can only really trust your vendor as much as much as you trust yourself … and you shouldn’t be trusting yourself.

Fast forward to 2022, the world runs on Open Source software — that’s a fact. Gartner says that 95% of the IT enterprises across the globe use open source software for their mission-critical IT workloads and that number is growing everywhere, not just in IT enterprises. Linux and open source software also power a majority of the cloud. There is good reason for that too, mainly, the speed at which open source software innovates, due to the collaborative nature of its development.

One of open source software’s greatest strengths is postulated as Linus’ law — given enough eyeballs, all bugs are shallow. Someone is always looking, right? Wrong. Even with someone looking, it’s still possible to introduce extremely severe vulnerabilities, like Heartbleed and now Log4j/Log4Shell, that sneak in undetected. Those, however, were introduced by mistake and their root cause lay in the global characteristic of the open source development model where often a certain critical piece of code (or what ends up being one after a vulnerability is discovered) might have been contributed by a student or may be maintained by someone whose primary professional focus lays elsewhere. See xkcd #2347.

XKCD 2347

Organizations now have to address a more subtle and potentially more dangerous threat vector, the software supply chain attack. While the SolarWinds hack was done from without, there is also the prospect of such a compromise being done willfully, from within, by its own developer. Recently the developer of the widely-popular npm packages colors.js and faker.js, which are downloaded a collective 25 million times a week (yes, per week) decided to go on an activism bender, and purposely introduced changes breaking his software to get his point across.

His justification? “I am no longer going to support Fortune 500s (and other smaller sized companies) with my free work.”

Even more, it is often comical how enterprises will reach out to random open source maintainers, with whom they have no relationship, demanding answers. Here is an example recently reported by Daniel Stenberg, maintainer of the popular cURL and libcurl open source packages.

What to Do About It All…

I propose that organizations shift their thinking to adjust to a new landscape. Stop thinking about software as a product you consume and start thinking about it as a process you are a part of. There is a chain here, and whether you like it or not, you are a link on that chain. You need to play your part to preserve the continuity of that chain.

That’s accomplished by recognizing and accepting your place in the chain. Is your organization purely a consumer of software or a producer of software? Are you relying on proprietary software or open source? It’s probably a mix of both.  Make sure you’re interacting with your proprietary software vendors, you’re paying them good money. They owe it to you. Use their established guidance on ensuring that their software is set up securely and then take further measures to harden your infrastructure. It is, after all, yours.

On the open source front, don’t just be a consumer. Your participation in strengthening the broader open source ecosystem is more vital now than ever before. Identify which open source projects and components are important to your organization and then engage with the community. There are several ways to engage, the easiest being to send any bugs you find upstream. Developers appreciate this immensely, more than you would know. It keeps the feedback loop open and helps them improve, what for many is a project of passion. 

Many open source projects also accept sponsors or some sort of donation. It’s not often much but it helps developers feel appreciated and maybe allows a bit of extra freedom. Speaking of appreciation, reach out to developers and let them know you are using their software and simply acknowledge their work. Many open source developers spend countless hours pouring their hearts and minds into their projects and receive no esteem, no notability and no regard. Often a simple “thank you” goes a long way.

Combine this new mindset with the classical approaches of infrastructure monitoring, vulnerability scanners, monitoring, logging and audit trails. Establish new policies, mirroring the president’s recent Executive Order making sure you’re either generating or being provided with a Software Bill of Materials (SBOM). Start implementing the cybersecurity principles in the recent memo on Moving Towards Zero Trust Cybersecurity.

This new mindset, coupled with classical approaches to cybersecurity, and keeping up with the latest guidance will ensure that your organization has a comprehensive strategy to shore up your digital defenses against the software supply chain for a long time to come.

Feature image via Pixabay.