2021 was a wild year for cybersecurity; memorable for a slew of data breaches, cloud provider outages, ransomware attacks, and software supply chain compromises.

The software supply chain has become a notable concern due to the explosive growth of open source software use, and the cascading impact of software supply chain incidents from open source and vendor proprietary software.

Two high-profile software supply chain incidents, The SolarWinds compromise and the Log4j panic, garnered the most headlines as organizations associated with these attacks scrambled to address their impact.

The attacks on the software supply chain keep coming. In its “2021 State of the Software Supply Chain” report, security provider Sonatype recorded 12,000 incidents this past year, a 650 percent increase over the previous year. Despite this surge, supply chain compromises are not new: the Cloud Native Computing Foundation has documented a repository of notable supply chain attacks dating back to 2003.

Supply chain attacks are not limited to the private sector. The public sector and federal agencies, including the Defense Department and its industry partners, are some of the biggest consumers of proprietary and open source software.

Countless organizations — including in the federal community — continue to adopt open source software for its myriad benefits, such as expediting timelines, providing readily available code, improving functionality, and offering transparency.

Sonatype noted a 73% year-over-year growth in development downloads of open source components. Unfortunately, open source developers may not be dedicating enough time to securing their code. According to the Linux Foundation’s “Report on the 2020 FOSS Contributor Survey,” the average amount of time an open source developer spends on securing code is less than 3%.

Software Supply Chain Examples

Open source software adoption come with risks. Nowhere is this more apparent than with the recent vulnerability incident with Log4j, an open source Apache logging framework. The incident left thousands of organizations worldwide, including many federal agencies in the United States, scrambling to determine if they were using the vulnerable version of Log4j directly, or through the vendor software they consume. The latter fear was accompanied by a barrage of vendor advisories and bulletins.

The SolarWinds cyberattack highlighted the potential for malicious actors to compromise a vendor’s build environment and insert malicious software that could then be distributed broadly across the customer ecosystem and associated environments.

In late 2020, as the fallout from the SolarWinds cyberattack escalated, the Cybersecurity and Infrastructure Security Agency (CISA) released a set of emergency directives documenting mitigations that federal agencies should take to avoid the exploitation of their systems using SolarWinds.

Building on this incident and others, the cybersecurity executive order highlighted the need for guidance around validating vendors’ secure software development environments and practices, as well as instruction for monitoring and reporting cybersecurity incidents.

The Cybersecurity and Infrastructure Security Agency also created a dedicated page in its emergency directives for Log4j vulnerability guidance. CISA’s guidance applied to both vendors using the component in their software and affected organizations using it internally or through vendor software consumption.

This event also highlighted an alarming reality: most organizations lack effective methods to identify the software and associated components they are using.

Palo Alto’s Cloud Threat Research Group also released research highlighting software supply chain concerns, noting that supply chain flaws are difficult to detect and that third-party costs pose hidden risk. It pointed out several relevant software supply chain attacks. The report laid out how attackers are poisoning continuous integration pipelines and causing cascading impacts on downstream software consumers.

The Palo Alto report also highlighted concerns associated with infrastructure-as-code and container templates, which are increasingly being used by organizations in support of pushes for cloud adoption and digital transformation initiatives.

Securing the Software Supply Chain

The software supply chain, from both proprietary and open source perspectives, is fragile and warrants more security rigor, yet most organizations aren’t quite sure where to begin.

Thankfully, public and private organizations are releasing guidelines and best practices that companies can leverage to improve their software supply chain security hygiene and mitigate risk to their organizations and customers.

The National Institute of Standards and Technology (NIST) released the Cybersecurity Supply Chain Risk Management Practices, or 800-161. This is a framework to evaluate supply chain security. It was updated in October in draft form, and is now undergoing comment reviews.

Appendix F of this document responds specifically to the cybersecurity executive order and strives to provide guidelines for enhancing software supply chain security.

NIST recommends that federal agencies and the private sector incorporate C-SCRM practices into key activities, such as enterprise-wide risk management and acquisition. NIST also defines what “critical software” is, and provides associated security measures. The document offers guidelines for software verification to help developers supply secure products and services to organizations within the federal government.

These recommendations encourage critical activities such as threat modeling, static and dynamic application scanning, and the identification of hard-coded secrets - all of which can locate vulnerabilities and risks that may impact software consumers.

Generally, the NIST guidelines recommend that federal agencies ensure these practices be performed by their software suppliers. That will include baking these requirements into acquisition language in the future.

The 800-161 recommendations include emerging software supply chain concepts, such as the concept of a “Software Bill of Materials” (SBOM). An SBOM acts as a method of increased transparency and starting point to help organizations identify what software they are consuming, where it exists, and the potential vulnerabilities associated with it. These recommendations have been championed by the National Telecommunications and Information Administration (NTIA) and CISA, each releasing best practices. Think back to the Log4j vulnerability. How would having an SBOM have helped companies with poor software asset inventory? For many organizations, this meant they were left scrambling to even identify if they were impacted.

The 800-161 includes sections dedicated to open source software controls, with an eye on varying levels of maturity such as “foundational, sustaining, and enhancing.” These cover a range of issues, from controls such as software composition analysis, to setting up a centralized repository of open source components that have been cataloged and approved for organizational use.

On the industry side, the Cloud Native Computing Foundation’s white paper, “Best Practices for Supply Chain Security” outlines four principles for supply chain security: trust, automation, clarity, and mutual authentication. Each of these categories is critical at every step of the supply chain ecosystem to ensure a resilient software supply chain, and mitigate many of the risks in incidents we’ve seen.

What makes the guidance unique is the distinctions it makes among assurance requirements. It notes that not all software and enterprises share the same security requirements and risk tolerances, and it identifies low-, moderate- and high-assurance products/environments. Like the NIST guidance, the white paper recognizes that best practices carry different decisions and activities depending on whether the users are software producers or consumers.

These practices helps software creators and maintainers ensure they provide a product that matches their customers’ requirements. Software consumers ensure vendors are offering them software aligned with their risk tolerance. While the Cloud Native Computing Foundation guidance provides specific actions at various stages of the software supply chain, it carries some overlap with NIST guidance, such as requiring a (SBOM) from third-party suppliers, utilizing trusted repositories, and performing security control assessment on ingested software.

What’s Next?

Software supply chain concerns are here to stay. Organizations are realizing just how brittle their software supply chain security practices are; and malicious actors take advantage of this reality.

With the additional attention on Software-as-a-Service (SaaS) and Software Bill of Materials (SBOM), Aquia has been working diligently with one of the largest Federal agencies in both of these areas.

On the SaaS front, there are some very scary numbers. Organizations are using upwards to 200~ SaaS providers with very limited insight, governance or security of their SaaS footprint. Studies show IT/Security only controls 25% of SaaS usage in large organizations. Further, Organizations are adding, on average, 8 new SaaS apps a month, but only ⅓ of organizations make use of any SaaS Security tooling. Aquia has helped stand up a SaaS Governance and Security program to tackle the challenge from multiple angles. This includes improving discovery of existing SaaS use, managing the intake and approval process of new SaaS application requests, and hardening and securing existing SaaS footprints.

On the SBOM front, organizations are increasingly looking to NTIA, CISA, and others for guidance on how to both implement and operationalize the use of SBOM’s. Aquia has begun developing an API to ingest SBOM’s from SaaS vendors, which looks to give agencies a better idea of what software they are consuming, and its associated dependencies. Aquia is also implementing CI/CD tooling to help curate SBOM’s from internally developed software and containers. This helps give agencies an understanding of their software asset inventory, puts them in a position to mitigate existing risk, and also respond quickly to the next Log4j zero day event.

Where To From Here?

The federal government and defense community have made clear statements highlighting how critical software is to national security and international competitiveness.

Software brings innovations and promise, but it comes with an exorbitant amount of relevant peril, particularly when fundamental security practices and processes are not implemented throughout the software supply chain.

This is a reality for both software producers and consumers in any industry and vertical. The implementation of secure software supply chain practices is no easy feat. However, the new guidance from NIST, the Cloud Native Computing Foundation, and other security watchers is a great step toward, what should be, a strategic imperative for our national security and for a well-functioning society in today’s digital world.

If you have any questions, or would like to discuss this topic in more detail, feel free to contact us and we would be happy to schedule some time to chat about how Aquia can help you and your organization.