The security of the software supply chain has become increasingly important in the past year. Two major cybersecurity attacks – SolarWinds and Kaseya – have emerged as urgent reminders to scrutinize every component of software development and deployment, including where they come from and where they come from.
The first signs of a major security gap in the supply chain appeared over four years ago when the malware wiper NotPetya was launched against Ukraine in 2017, a Ukrainian company. The result was an estimated $ 10 billion damage affecting businesses in Asia, Europe, and the Americas.
From a cost perspective, NotPetya was just a drop in the ocean. The cost of responding to incidents to repair damage from the SolarWinds attack is estimated at over $ 100 billion, while additional costs for recovery from the Kaseya attack are still being calculated earlier this year. Bottom line: The cost of security breaches in the software supply chain has grown exponentially, and open source is proving to be the primary target.
“We’re seeing an increase in attacks,” said Luke Hinds, Head of Security Technology, Office of the CTO, Red Hat Inc., in a recent interview with theCUBE, SiliconANGLE Media’s live streaming studio. “There’s a recent statistic that has come out … a 620% increase since last year in supply chain attacks involving the open source ecosystem. So things are definitely looking up. “
A complex problem
The recent incidents prompted the White House to issue an executive order in June aimed at protecting government systems from attacks on the software supply chain. More importantly, concerns about software security have led some of the largest computer companies in the world 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 closed gates. According to Red Hat’s The State of Enterprise Open Source report, 90% of IT executives say they will use open source tools for businesses and 79% expect to use open source software in the next two years will increase.
The challenge of protecting open source software, developed by many contributors, is akin to securing a bank vault where anyone can come and go as they please. What’s inside is extremely valuable, but there are no guards or locks on the vault door.
“This is a complex problem,” said Sandy Carielli, principal analyst at Forrester Research, in an interview with SiliconANGLE for the story. “Companies want to perform additional controls and analysis on the security of the software supply chain in order 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 to address this challenge and is starting a project called Sigstore, which will automate the digital signature and verification of software elements. The aim is to provide a free tool that verifies the origin of software and enables developers to use open source solutions safely. The bank vault is still wide open, but only verified, trustworthy sources are allowed to touch the inside.
Sigstore is a project originally prototyped at Red Hat, and the company positioned it as an “open response” to the trust and security of the software supply chain. Red Hat has actively sought support for the industry 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 a speech at the Linux Foundation’s Open Source Summit this fall. “So far, the community has more than 675 commits, more than 465 members and 20 organizations. In order to offer all of these features and become a widely available free service, we need to build trust. “
This pursuit of partnership and trust has led Red Hat and IBM to partner with a variety of other large companies to support the Open Source Security Foundation. The Linux Foundation-led collaboration has already raised $ 10 million from the two companies and other celebrities including Amazon, Cisco Systems, Dell Technologies, Microsoft, Google, Oracle, and VMware.
The initiative unites several projects under a single roof with the charter to find and fix security gaps 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 largely made up of open source software, so they try to pass on these indirect dependencies,” Behlendorf said in a recent interview. “By improving the basis of open source, you end up getting higher quality code.”
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 would expand Sigstore to include the ability to verify the origin and integrity of a Kubernetes manifest with a cryptographic signature. This is to ensure that a resource has not been maliciously modified before it is applied to a Kubernetes cluster.
IBM has also automated the query of Common Vulnerabilities and Exposures databases to reduce the risk of compromised packages and binaries being used in applications. The company’s Anaconda repository for IBM Cloud Pak automates this work for IT administrators.
Amazon Web Services Inc. offers two separate tools that can help monitor supply chain security. One of them is AWS CloudTrail, which provides a log of all 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 upgraded its open source tool, ClusterFuzz, with an emphasis on improving the security of the software supply chain. In early November, the search giant announced the release of ClusterFuzzLite, which throws random data at computer programs to identify bugs that could be exploited by threat actors.
The latest improvement is a result of Google’s OSS Fuzz project, which started five years ago to incorporate quality assurance into open source initiatives. An interesting sidebar from Google’s recent announcement was about the published data. The company found that OSS-Fuzz has identified 6,500 open source vulnerabilities and fixed 21,000 functional bugs to date.
Establishing a verified signature system and implementing tools to detect dangerous behavior or remediate vulnerabilities are steps in the right direction, but there are indications from US government officials that more transparency is needed. The Executive Order issued by the White House earlier that year called for a software bill of materials, or SBOM.
This approach is similar to the one commonly used in the manufacture of goods. Just as manufacturers keep an inventory of all of the items in a given product, a software bill of materials would contain a list of all of the open source and third-party items contained in a code base.
Basic information for an SBOM was developed by the National Telecommunications and Information Administration. The government is at least trying to make SBOM a requirement for software to be made available to federal agencies. It remains to be seen whether it will be accepted as a universal standard in the tech industry.
“I’m a huge fan of the ongoing software BOM 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 mistake this for some kind of magic bullet for the security of the entire software supply chain. “
How the tech industry will ultimately respond to vulnerabilities in the software security supply chain is still a work in progress. Initiatives like Sigstore to address open source security concerns were a good place to start, but trust can be a difficult endeavor in a software ecosystem based on the sharing and global use of common tools. However, it will likely take trust as part of the open source ethos to provide an answer to today’s security problem.
“We’re constantly pulling each other’s code, which demonstrates this high level of implicit trust,” Red Hat’s Wright said in a recent blog post. “Transparency, partnership, trust. That’s how we’ve done it in the past and that’s how we will do it in the future. “