Open Source Leaders Seek to Close Gaps in Software Supply Chain Security
Special attention has been paid to the security of the software supply chain over the past year. Two major cybersecurity attacks – SolarWinds and Kaseya – were sharp reminders to reexamine every component of software development and deployment, including what they are and where they came from.
The first signs of a major vulnerability in the supply chain actually emerged more than four years ago when the NotPetya wiper was launched against Ukraine in 2017. The NotPetya attackers, seen as threatening actors in the russian military, allegedly injected malicious code into accounting software owned by a Ukrainian company. The result was estimated $ 10 billion in damages which has impacted organizations across Asia, Europe and the Americas.
From a cost perspective, NotPetya was just a drop in the bucket. The incident response costs to repair damage caused by the SolarWinds violation are estimated to be exceed $ 100 billion, while the additional costs for recovery from the Kaseya attack earlier this year are still being calculated. Conclusion: The cost of software supply chain vulnerability has increased exponentially and open source is proving to be a prime target.
“We are starting to see an increase in attacks,” said Luke Hinds, Head of Security Engineering, CTO Office, at Red Hat Inc., in a recent interview with theCUBE, SiliconANGLE Media’s live streaming studio. âA recent statistic has come outâ¦ a 620% increase since last year in supply chain attacks involving the open source ecosystem. So things are certainly accelerating.
A multifaceted problem
The recent incidents prompted the White House to publish a decree in June designed to protect government systems from software supply chain attacks. More importantly, concerns about software security have driven some of the world’s largest IT companies to find technology solutions that reduce the potential for future exploits.
Part of the problem is that not all of the software in the world is behind locked doors. In fact, 90% of IT managers say they use enterprise open source tools, according to Red Hat State of the Open Source Business Report, and 79% expect the use of open source software to increase over the next two years.
The challenge of protecting open source software, which is built by many contributors, is akin to securing a bank safe where everyone is free to come and go as they please. What’s inside is extremely valuable, but there are no guards or locks on the safe door.
“This is a multi-faceted problem,” said Sandy Carielli, senior analyst at Forrester Research, in an interview with SiliconANGLE for this article. âCompanies want to put in place additional controls and analytics for software supply chain security to reduce risk. One of the problems is that open source is so ubiquitous.
Open source initiatives
Red Hat Inc. has come up with some ideas on how to tackle this challenge, and it starts with a project called Sigstore, which automates the digital signature and verification of software elements. The goal is to provide a free tool that will verify the provenance of software, allowing developers to use open source solutions safely. The bank safe is still wide open, but only verified and reliable sources are allowed to touch what’s inside.
Sigstore is an initially prototyped project at Red Hat, and the company has positioned it as a “Open response” to the trust and security of the software supply chain. Red Hat is actively seeking to galvanize industry support around the digital signature solution.
âWe have big plans with Sigstore, and that’s where the partnership comes in,â said Chris Wright, senior vice president and chief technology officer at Red Hat, in Remarks at the Linux Foundation Open Source Summit this fall. âTo date, the community has over 675 commits, over 465 members and 20 organizations. To provide all of these features and become a widely used free service, we need to build trust. “
This search for partnerships and trust has led Red Hat and IBM to join a multitude of other large companies in the support the Open Source Security Foundation. The collaboration, led by the Linux Foundation, has already raised $ 10 million from the two companies and other notables including Amazon, Cisco Systems, Dell Technologies, Microsoft, Google, Oracle and VMware.
The initiative brings together several projects under one umbrella with the charter to find and fix security vulnerabilities in open source software. Open source visionary Brian Behlendorf, who was a co-creator of the Apache web server, is the general manager of OpenSSF.
âThese groups know that their stacks are made up largely of open source software, so they are looking to pay it up front for these indirect dependencies,â Behlendorf said in a recent maintenance. “By improving the base of open source, they will get better quality code in the end.”
Cloud tools and ClusterFuzz
Container security is also part of the software supply chain discussion. In addition to supporting OpenSSF, IBM announced in July that it extend Sigstore with the ability to verify the origin and integrity of a Kubernetes manifesto with a cryptographic signature. The goal is to ensure that a resource has not been maliciously modified before being applied to a Kubernetes cluster.
IBM also has Automatique the practice of browsing Common Vulnerabilities and Exposures databases to reduce the risk of using compromised packages and binaries in applications. Of the society Anaconda deposit for IBM Cloud Pak automates this work for IT administrators.
Amazon Web Services Inc. two separate tools that can help monitor supply chain security. One is AWS CloudTrail, which provides a log of all the actions that have occurred in a user’s AWS environment. The other is Amazon CloudWatch, a monitoring and observability service for developers and IT managers. Logs, metrics, and events are collected to provide a unified view of AWS resource usage.
Google recently made an improvement to its open source ClusterFuzz Tool, with a focus on improving the security of the software supply chain. In early November, the search giant announced the exit of “ClusterFuzzLite”, which sends random data to computer programs to identify bugs that could be exploited by threat actors.
The latest improvement is an outgrowth of Google’s OSS-Fuzz project started five years ago to inject quality assurance into open source initiatives. An interesting sidebar in Google’s most recent announcement concerned the data it released. The company noted that OSS-Fuzz had identified 6,500 open source vulnerabilities and fixed 21,000 functional bugs to date.
Creating a verified signature system and implementing tools to detect unsafe behavior or fix vulnerabilities are steps in the right direction, but U.S. government officials say more transparency will be needed. The executive decree issued this year by the White House requested a software nomenclature, or SBOM.
This approach is similar to what is often found in the manufacture of goods. Just as manufacturers provide an inventory of all the items contained in a specific product, a software nomenclature would provide a list of all open source and third party elements contained in a code base.
The basic information for an SBOM has been developed by the National Telecommunications and Information Administration. At a minimum, the government seeks to make SBOM a requirement to provide software to federal agencies. Its adoption as a universal standard within the tech industry remains an open question.
âI’m a big fan of the ongoing software nomenclature initiatives,â said Carielli of Forrester. âWe need controls to track and manage software. Making new versions of open source software less vulnerable is an important initiative, but we cannot confuse this with some sort of silver bullet for the security of the entire software supply chain.
How the tech industry ultimately responds to vulnerabilities in the software security supply chain is a work in progress. Initiatives like Sigstore to address concerns about open source security have been a good place to start, but trust can be a tricky proposition in a software ecosystem based on the global sharing and use of common tools. Yet it will likely take trust in the open source ethics framework to answer today’s security conundrum.
âWe pull each other’s code all the time, which demonstrates this high level of implicit trust,â Red Hat’s Wright said in a recent blog post. âTransparency, partnership, trust. This is how we have done it in the past, and this is how we will continue to do it in the future.