Supply chain security and compliance: Why software organizations should get out in front of requirements

Get out in front of software supply chain compliance requirements for a competitive advantage. Here's what your software organization needs to know.

Software development organizations face new compliance and legal obligations in 2023 stemming from the response by governments and regulatory bodies to growing attacks on the software supply chain, starting with SolarWinds in 2020, ending 2022 with a bang — and looking ominous for software security in 2023.

Since SolarWinds, the industry and the federal government have been on high alert. The agencies and companies that supply software to them are already feeling the pressure, and it's just a matter of time before private sector entities do so as well.

A lot of the focus on taking action on software supply chain security begins with a software bill of materials (SBOM), a sort of ingredient list for software packages. The research company Gartner believes that by 2025, 60% of organizations procuring mission-critical software solutions will mandate SBOM disclosure in their license and support agreements, up from less than 5% in 2022.

However, software security experts urge that SBOMs are just the beginning in your software supply chain security journey. Here's what your team needs to know about how to get out in front of compliance requirements and focus on end-to-end software security.

The software security compliance landscape

Many of the new obligations for software supply chain security come with a bevy of  guidelines and mandates from the federal government that require software firms, and organizations purchasing from them, to employ best practices for supply chain security and secure software development practices in general.

[ Related post: A timeline of federal guidance on software supply chain security ]

The National Institute of Standards and Technology (NIST) for instance has developed guidelines for secure software development and supply chain security that all providers of software applications and services to federal civilian agencies must follow. The guidelines (NIST Special Publication 800-218x) include requirements like the need for software developers to have separate build environments; regularly audit trust relationships and have tools for maintaining a trusted source code supply chain.

NIST is also calling on software developers to capture provenance data for all third-party and open-source components in their software and to provide an SBOM and other development artifacts to federal government customers on demand.

Starting late this year, organizations selling software to the federal government will need to attest to their conformance with these NIST requirements and be prepared to provide evidence of their compliance if a federal agency customer requires it.

Federal agencies purchasing software from commercial vendors and other third parties have their obligations as well. A separate document that NIST released last year provides guidance to agencies on how to ensure their software providers are conforming to these standards. The document instructs agencies on the security questions they need to ask and the attestations they need to obtain when procuring software from a commercial software provider or other third-party.

NIST developed these guidelines under the aegis of an Executive Order that President Biden issued in May 2021 on improving the nation's cybersecurity (Executive Order 14028), prompted at least in part by the SolarWinds breach. That attack, and subsequent attacks on Kaseya, CodeCov and numerous others in recent years sparked widespread concern about the vulnerability of US organizations — especially those in critical infrastructure sectors — to threats sneaked in via trusted third-parties and supply chain partners.

Pressure is building on private sector to bolster supply chain security

The Biden Administration's EO directed NIST to work in collaboration with private sector partners and government stakeholders to develop standards and guidelines for bolstering supply chain security and secure software development in general.

The EO and standards requirements apply primarily to federal civilian branch agencies and their software suppliers. But pressure is building on private sector organizations as well from a variety of other fronts.

The US Securities and Exchange Commission (SEC) for instance is working on new cybersecurity incident disclosure rules for publicly listed companies, triggered largely by the SolarWinds compromise. If adopted as proposed, the new rules, among other things, would require public companies to maintain reasonable cybersecurity practices—including those pertaining to supply chain security. Organizations will have to publish their security practices in public filings and disclose all "material" cyber incidents within four days of occurrence.

Similarly, last March the President signed into law the Cyber Incident Report for Critical Act of 2022 (CIRCIA) that requires the US Cybersecurity and Infrastructure Security Agency (CISA) to develop requirements for incident disclosure to be used by operators of critical infrastructure, many of whom are private companies.

When it goes into effect, CIRCIA will require organizations in critical infrastructure sectors such as healthcare, financial services, communications and energy to disclose "covered" cyber incidents within 72 hours. Critical infrastructure organizations that make a ransomware payment following a ransomware incident will have 24 hours to report that fact to CISA, which then must disclose that incident to federal agencies. A supply chain compromise is one trigger for the disclosure requirement.

The US Federal Trade Commission (FTC) stepped into the fray last January with a warning to software vendors related to the vulnerability in the Apache Log4j logging framework. Many consider the flaw as a classic example of a risk to organizations from insecure components in the open-source supply chain. The FTC provided organizations with a list of recommended remedial measures they could take to mitigate the Log4j threat. It warned of action under the FTC Act against those that failed to take reasonable measures to mitigate the vulnerability.

There are other preexisting requirements as well. The Federal Financial Institutions Examination Council (FFIEC) of banking regulators for instance has a mandate that requires financial institutions to perform automated testing and reviews of third-party updates and conduct regular assessments of the reliability and integrity of their third party software. And standards such as ISO-27036-3 require organizations to frequently scan for and identify suspicious code and software tampering.

A new standard of care for software security

The new requirements and scrutiny of cyber practices from government and regulatory bodies means the time is now for software producers and consumers to start implementing secure practices, especially those related to supply chain security.

Davis McCarthy, principal security researcher at cloud security service provider Valtix, said supply chain security has become front and center for software teams.

"Governmental and regulatory acknowledgement that supply chain compromise is a risk underscores its severity and just how complex it is to manage. Once perceived security threats within the software supply chain are now materializing at an accelerated rate."
—Davis McCarthy

It's a legal matter, baby

Importantly, the new requirements and guidelines reflect the higher expectations around the standard of care and due diligence organizations must pay to address software security issues, a panel of legal counsel from Microsoft, Raytheon and NetApp said at a panel discussion at the RSA Conference last year. The lawyers expect that government organizations will soon include many of the new standards in their contract clauses and it is only a matter of time before private sector organizations start incorporating those same requirements in their software contracts as well.

Also significant is the fact that Biden's 2021 Executive Order required the CISA to develop incident response and vulnerability response playbooks for federal agencies. The availability of those playbooks means organizations—both private and public—now have even less legal cover for failing to apply security standards, the panel experts concluded.

Over the near term, the lawyers expect the new standards and requirements for cyber and supply chain security could create new challenges, in addition to those related to compliance. For instance, CIRCIA's early disclosure requirements could be problematic for organizations if they are only still trying to figure out for themselves how an incident might have happened. In such a situation, early disclosure might only aggravate a security incident, they noted.

Similarly, organizations gathering attestations about software security from their software vendors need to ensure they are ready to act on the information a vendor provides. Otherwise, they might be in a position where they are sitting on information that could make them legally liable later if an incident were to occur, the panel said.

Open source and the software supply chain

The increased attention from government and regulatory bodies puts organizations on notice that they can’t avoid addressing software supply chain issues, says Bud Broomhead, CEO at IoT security provider Viakoo.

"Follow CISA and government agencies where mandates are being put in place on vulnerability mitigation and remediation for infected software, as they mandate use of SBOMs. Cyber insurance providers are another source of direction for where organizations need to put their focus."
—Bud Broomhead

Open-source component use is one area where organizations need to pay special attention. And software repositories are of particular concern, given the surge in attacks on npm and PyPi repositories, as noted in the special report NVD Analysis 2022: A Call to Action on Software Supply Chain Security.

Mike Lambert, VP of product at ArmorCode, said SBOMs can be especially useful for identifying components of software packages.

"As the software supply chain gets more complicated, it is critical to know what open source you are indirectly utilizing as part of third-party libraries, services (APIs) or tools. By requiring disclosure of all embedded technologies from your vendors, you can perform analysis of those libraries to further assess your risk and react appropriately."
—Mike Lambert

Events like the Log4Shell vulnerability highlighted the need and value of SBOMs at the enterprise level, but for many this has not yet translated to how development teams will be able to leverage them without slowing down software delivery with manual tasks, Lamber says.

"Organizations are going to need ways to automate generating, publishing and ingesting SBOMs. They will need ways to bring the remediation of the associated vulnerabilities into their current application security programs without having to adopt whole new workflows."