Software Supply Chain Security and the Rapidly Evolving Regulatory Landscape

There are times when an unexpected event fundamentally changes our perceptions around a topic or redefines the boundaries of what is possible. We’ve all experienced them in aspects of our lives before, and when they happen it can take many months or years to fully adapt to the new reality. 

In cybersecurity, the of events beginning with SolarWinds and continuing with Codecov, Kaseya, Log4Shell, and a parade of others vulnerabilities and attacks exposed multiple fundamental problems with software supply chains today: 

1. The build process is vulnerable, and it is hard to guarantee the integrity of the produced software.
2. Software applications are made of a complex web of 3rd party components, any of which might be vulnerable at any time, and there is little visibility or monitoring of those components as software is built, deployed, or exchanged.
3. Traditional code scanning today is insufficient. Instead, you need to you need to secure your development pipelines for gaps and leaks, the SDLC systems and infrastructure within those pipelines, and the security posture of the people and code as they operate within it.

This leads to the bitter truth that there is no trust mechanism that ensures a given application or software release is truly safe to use. If you are a software vendor, you must question if your software is safe to provide to customers. And as a software consumer, you must question if the software or services you rely on for so many things are truly safe to use. 

Fortunately, industry leaders, governments and the software security community have responded with haste to standardize and regulate the security of the software supply chain and ultimately software itself. This includes a rapidly evolving landscape of regulations, standards, and guidance in an attempt to keep the software development community thriving amid these new threats. 

This article lists the key initiatives in this regulatory landscape, and in the process also helps redefine the term “software supply chain security”, which now encompasses the domain of securing applications and the development lifecycle including the build process itself.

Important Regulatory Changes You Need to Know

Here is a review of the most important developments in the regulatory landscape, including who is most affected: 

1. 1. US Executive Order 14028 and the Secure Software Development Framework (SSDF)
   2. Software Bill of Materials and its standardization
   3. Information Security Compliance frameworks and specifically PCI/DSS new updates
   4. SLSA – a framework to ensure the integrity of software. 
   5. Guidance for Supply Chain security from Industry Leaders
      

Executive Order 14082

On May 2021, EO 14028, “Improving the Nations’ Cybersecurity” was signed. Within it, section 4 – “Enhancing Software Supply Chain Security” calls upon the National Institute of Standards and Technology (NIST) to draft comprehensive guidelines that would serve as requirements for any software the federal government uses or purchases. This led to the publication of NIST SP 800-218 called “Secure Software Development Framework” or SSDF for short – a comprehensive set of requirements that details how to produce secure software.

The EO also describes the procedure of “providing a purchaser a Software Bill of Materials (SBOM) for each product directly, or by publishing it on a public website;” This made the comeback of the old concept of SBOM – a software bill of materials.

Vendors selling to the US government and are required to be FedRamp-compliant, are seeing changes from the EO affecting revision 5 of the framework (NIST SP 800-53), which is in its final release stages – those changes include stricter requirements on software supply chain management.Additionally, the EO mandates that every software sold to the US government must make available a software bill of materials – a requirement that implies having knowledge of all software components of all the n-parties that are part of the software.

SSDF 

NIST special publications (SP) are security guidelines that are aimed at federal agencies but have a large influence on the industry, academia and government purchasing regulations. 

NIST SP 800-218, aka SSDF version 1.1, details the requirements for secure development practices.

There are 4 groups that define security practices within the document:

1. Prepare the organization (PO) – Practices on procedures and requirements for a secure process.
2. Protect Software (PS) – Practices on securing the build process and ensuring the integrity of the built software.
3. Produce Well-Secured Software (PW) – Practices on secure software development lifecycle, including secure design, code reviews, security scanning, etc.
4. Respond to Vulnerabilities (RV) – Practices on monitoring and responding to vulnerabilities in the software after it is released. 

Group 2, “protect software”, largely focuses on the newly required hardening practices of the build system and the need to eliminate the risk of tampering, for example, in the practice of “verifying software release integrity”. More practices and tasks include code signing and automated vulnerability scanning.

SSDF is new and challenging to implement.  Particularly around the lack of available commercial tools for signing and validation of software and especially for legacy technology stacks. It also requires a complete inventory of all development assets, including build tools, servers, plugins, and 3rd party software, which large organizations find extremely challenging to discover and inventory in real-time. Although this document is still not mandatory, it is being regarded as a key document when organizations assess the security of their 3rd party suppliers, and its influence over the private sector is growing rapidly.

Software Bill of Materials

The concept of SBOM is in the fast lane for being standardized. On July 2021, NTIA published the minimum requirements for SBOM, which defines the acceptable SBOM the US government requires from its software vendors. There are 3 formats approved for SBOM, which are SPDX, Cyclone DX and SWID tags and the requirement as it stands today is to provide a file in one of the above formats of all software dependencies, including their relations with each other.  While SBOM is merely a file containing a list of components, it is much more than that. The OSSF has named one of its key security initiatives, “SBOM Everywhere”. The hope is that an industry-agreed standard for specifying software content will be mandatory for every exchange of software.

Many vendors selling software, mainly to enterprises, are being requested to provide an SBOM in a standard format as part of the deal.  SBOM requests are growing and will continue to grow for the following reason:

1. US Regulations and Contributing Parties – A vendor selling software to the US government that is required to present an SBOM, will also require SBOMs from its 3rd party software providers, and so forth. The more detailed and wider the SBOM requirements are, the more requirements trickle down to supporting and contributing parties.
   For example – a new discussed addition to SBOM is to include “build plugins” used to compile the software. This will require 3rd party vendors that produce build plugins to provide the SBOM for their components, and so forth.
   
2. Double down on 3rd-party inventory requirements – information security compliances have always requested manufacturers to list their 3rd party dependencies, however, this requirement was usually completed with a “check the box” sort of mentality. Essentially any list, however impartial would be accepted. Today, more scrutiny is placed on identifying third parties in various stages of the software development process, and SBOM is a good way to store and trace them for compliance purpose.
3. Insufficiency of SCA tools – Software Composition Analysis (SCA) tools can analyze software and find some of its dependencies, but they are not sufficient. For example, once native applications on C/C++ are compiled and shipped, it is hard to do binary analysis and pinpoint the exact source code dependencies. Purchaser of such software in need of 3rd party lists must turn to SBOMs provided by the creator to reveal the accurate list of dependencies. 

The concept of SBOM is still new although it is evolving rapidly. Problems remain, but  government/industry entities are actively working on solving them including:

• How to verify the completeness and integrity of an SBOM? 
• Should SaaS vendors make SBOM available for their service?
• How to address the lack of tooling to consume, verify and manage SBOMs. For example, tooling to continuously monitor SBOMs of 3rd parties used by an organization and match them against known vulnerability databases.

There is still a long way to go on standardization, adoption, and tooling around SBOMs. However, the US government now requires the minimal version of SBOM for any purchased software and intend to add more requirements. The US EO, and the increased focus on 3rd party inventory has led the private sector to also begin demanding SBOMs as part of regular vendor assessments – a practice that will also grow to become the norm of software exchange and purchases.

Information Security Standards

Many private information security compliances exist and are being exchanged between vendors during security assessments. You might be familiar with SOC 2 or ISO 27001 – two popular compliance frameworks used across the software industry. Both SOC 2 and ISO 27001 have not made significant revisions yet, although their broadness and focus on secure development practices make them excellent candidates to validate that an organization carries out procedures to tackle software supply chain security challenges. Already, organizations are reporting more focus from these auditors around areas of build system security and 3rd party management.

PCI/DSS

The Payment Card Industry (PCI) Data Security Standard (DSS) is mandatory compliance by a wide range of financial institutions. Failing to comply can lead to fines, loss of brand reputation and closure of business. Parts of the PCI/DSS requirements focus on the security of the software provided by the financial institution. For example, requirement 6, “Develop and maintain secure systems and applications”, requires incorporating information security throughout the “software development life cycle”.

On March 2022, PCI announced version 4.0 of the standard, which will take effect in 2025.

In this new version , new requirements focus on the security of the software supply chain. Requirement 6.3.2 demands maintaining an inventory of all software, including 3rd party components, and their respective vulnerabilities. 

Special security requirements demand that the integrity and security of all client-side (browser) code provided by the financial service must be guaranteed. Effectively, it requires vendors to track all 3rd parties, validate them and include security guardrails to prevent tampering at any stage of the development lifecycle. 

The new updates in PCI/DSS are adaptations to the new threats and can be summed up to provide better visibility into software supply chains and automated mechanisms to detect vulnerabilities and maintain software integrity. As they are currently in a transition period, GRC teams are learning about these new changes and planning for additional controls to support upcoming audits.

SLSA

The SolarWinds case, and other software tampering incidents that followed (Codecov, Kaseya), made it clear that integrity is a problem in dire need of solving. Supply Chain Levels for Software Artifacts, SLSA (pronounced salsa), is a security framework that attributes a level of security between 1 and 4 to software artifacts, and can be verified by consumers.  This model was invented and made public by Google in a blog post on June 2021, and since then, is growing in recognition. It is now being actively maintained by the OSSF.

SLSA requirements are mostly about hardening and verifying the build process, such as having a verified history or doing a 2-person code review. SLSA levels measure the integrity of software, and they attest to the security of the build process, but it does not guarantee that the software will be vulnerability-free, nor does replace an SBOM. The main concept in SLSA is a Provenance File. This is a file that describes the entire build chain of a specific piece of software (“artifact”) and serves as a “certificate” that the artifact is trustworthy.

It is important to note that SLSA is not yet a regulated or mandatory framework, but it will not be a surprise to see some vendors starting to attest that the software they create is SLSA level 3 or level 4, or that consumers begin asking for evidence of SLSA from software providers. 

In an ideal world, every SLSA level 4 artifact would require recursively that all the software dependencies it uses will also be SLSA level 4. This will require the entire open-source community to implement SLSA and provide provenance files as evidence of integrity, which won’t happen quickly. We believe the first to adopt SLSA will be organizations that are more conscious of the integrity of their software and are more sensitive to the business risks of a software supply chain attack on their applications and pipelines.

Other Frameworks

In the recent months following the President’s Executive Order, industry leaders have drafted many guidelines and frameworks that give organizations guidelines to improve their software supply chain security risk posture, and better assess the third-party risk coming from software dependencies. These emerging frameworks are already starting to influence third-party risk assessments. Here are two notable examples:

1. CNCF Software Supply Chain Best Practices – Published by the Cloud Native Computing Foundation, various community leaders describe security practices aimed mostly at cloud-native products and services. This is also accompanied by the Secure Software Factory, which is a practical reference guide for implementing a secure build process.
   
2. Securing software supply chains for developers – New guidelines (August 2022) from 3 security agencies – NSA, CISA, and ODNI. This paper focuses on implementing a secure pipeline for ensuring software integrity. It references SLSA, SSDF and SBOM and aimed to be more practical.
   

Where Do We Go From Here?

The regulatory landscape is rapidly evolving by necessity to create better trust and security in our software in light of increasing software supply chain attacks and well-publicized exploits. These main themes are evident across all regulations:

1. Ensure the integrity of software and harden the software supply chain and build process through means of validation and certification/signing. This imposes a set of new requirements organizations will need to implement and provide an attestation of their integrity to their customers.
2. Gain visibility, control and protected usage of 3rd party software dependencies through SBOMs and additional requirements. All organizations will be expected to provide greater visibility into the software build process and all components that are part of their software.

In addition to a range of new US federal government requirements, we see examples of industry-leading frameworks that are designed for adaption by any vendor.  This is just the beginning. Daily software supply chain security incidents make the need for increasing trust in the software development process and applications an absolute necessity. It is inevitable that we will see more and more standards being adopted by organizations and demanded by software consumers.

By Liav Caspi, CTO and Co-Founder of Legit Security