Since the compromise of the SolarWinds Orion update mechanism two years ago this month, governments and the IT industry have made strides in trying to reduce the attack surface of applications.
However, Google believes software supply chain security is still one of the most critical security risks facing the world. “There is an urgent need to come together as an industry to address it,” Royal Hansen, the company’s vice-president of engineering for privacy, safety, and security, said in a blog.
So Google has released a research paper on securing software supply chains, the first in a series of reports on addressing security issues.
“Overall progress” by the IT industry “has been slow,” the report complains.
It makes two main recommendations:
— “First, we must work together as a community to develop and deploy a common Supply-chain Levels for Software Artifacts (SLSA) framework that mitigates threats across the entire software supply chain ecosystem.” This has been a requirement at Google for almost a decade. “We believe the SLSA framework, if implemented properly, would substantially reduce every organization’s attack surface,” the report says;
Application developers should implement the open source SLSA framework to harden software supply chain security; cryptographically sign and verify the authenticity of software using sigstore.dev; automate vulnerability discovery at scale with OSS-Fuzz; automate vulnerability tracking, and triaging with OSV.dev; and automatically evaluate security risk with Security Scorecards, says the report.
— “Second, the lessons we’ve learned from various security events call for a more holistic approach to strengthen defenses against software supply chain attacks. This includes a common strategy across various stakeholders that centers on three core pillars: 1) adopt best practices and standards for cyber hygiene; 2) build a more resilient software ecosystem; and 3) make investments in the future.”
IT departments need to understand their software supply chain and related infrastructure; develop software supply chain risk mitigation plans; identify potential software supply chain
risks; consider security requirements for software procurement; and ensure coordinated vulnerability disclosure plans are in place.
Google Cloud customers should equip developers, DevOps, and security teams with the
tools they need to build secure cloud applications with Software Delivery Shield, says the report. They should also enable access to open source software packages that have been curated and vetted by Google with Assured OSS; explore centralized information about vulnerabilities and possible risks using Google Cloud services like Security Command Center; and leverage best practices like the Google Cloud security foundation guide to set up more secure authentication and authorization, resource hierarchy, logging, and detective controls.
Software supply chain attacks aren’t new, but they were highlighted with the discovery that Solarwind’s Orion network management platform had been compromised — allegedly by Russia –with malicious code that was delivered to customers as part of routine updates. Over 18,000 SolarWinds customers worldwide received those updates — including nine U.S. federal departments — although SolarWinds says fewer than 100 ended up being hacked.
Over the course of the next several years, the frequency of similar attacks will likely continue to grow and increasingly focus on open-source software, the report says. The
emergence of open-source software has made software supply chains deeper, wider and more complex, it adds, because modern-day software tends to include elements published by a large number of diverse open-source projects, and often dependencies are several levels deep.
“This creates a massive attack surface ripe for exploitation by nation-states and cyber criminals.” it says.
There is a number of tools application developers can take advantage of, says the report. One is called Minimum Viable Secure Product, a checklist of controls that must, at a minimum, be implemented in software to ensure a reasonable security posture.
Another is including a Software Bill of Materials (SBOM), a nested list of packages and components included in an application. One problem: There’s no well-established ecosystem to easily distribute and verify SBOM documents;
A third tool is the SLSA framework. If an SBOM is like an ingredient list on a food product in the grocery store, says Google, then SLSA can be thought of as all the food
safety handling guidelines that ensure the final product is safe for consumption.
Related content: SLSA + SBOM
Developers should also note that the U.S. National Institute of Standards and Technology (NIST) has issued guidelines on the recommended minimum standards for vendors’ testing of their software source code and guidance outlining security measures for critical software use.
The Log4j2 vulnerability, revealed in December, 2021, illustrates a related problem in software supply chain risks, says the report — a vulnerable open-source component embedded in software widely around the world, with few IT departments aware of it. Log4j is an open-source Java logging library developed by the Apache Foundation. Experts say we may be hunting for applications with this bug for years.
Threat actors developed exploits quickly. Worse, says the report, is that second, Log4j revealed weaknesses in how large organizations track their own software deployments and
map associated dependencies. Without this information, defenders can’t find and fix software bugs quickly, the report says, which meant that in many organizations, it was unclear where to even start their remediation efforts or how large the effort would be. Again, this is why Google believes SLSA will be effective for securely building and verifying the integrity of software.
