This year’s Security Awareness Month theme — “See Yourself in Cyber” — was selected by the Cybersecurity and Infrastructure Security Agency to reinforce cybersecurity as a people priority: anchored in partnership, education and individual accountability. This article is part of a series focused on the people considerations of four key pillars of infosec enablement, as noted by CISA’s 2022 Awareness campaign: enabling multi-factor authentication, using strong passwords, recognizing and reporting phishing, and updating your software.
The software supply chain, defined
The software supply chain is the process by which software code is developed, tested, stored and ultimately deployed for release to the benefit of users. The individual components, people and processes that make up the supply chain are all responsible for making a particular piece of software what it is, which means that interfering or manipulating any part of that process can carry major security repercussions.
While software development and distribution has grown significantly more efficient through the years, security of the software supply chain has frequently struggled to keep pace. Many organizations have witnessed a staggering increase in their third-party dependencies, splintering their visibility of the software supply chain while complicating user access and authentication.
Survey data from CRA Business Intelligence reveals very few organizations have adequate visibility over their software supply chain. Only 41% of survey respondents report having visibility over their most critical 3rd-party direct dependencies. Only 26% of respondents believe they have full visibility across all tiers of their supply chain.
NIST provides an excellent breakdown of visibility barriers in the software supply chain:
Attacks on the software supply chain
Not surprisingly, bad actors have seized the opportunity to exploit these supply chain ‘soft spots’. By manipulating code in development and production, attackers are able to embed vulnerabilities in the supply chain that, upon release, can infect millions of users and businesses who download that software.
Recent supply chain attacks underscore the severity and scale of these disruptions:
- JuiceLedger & PyPi (2022) Through a combination of typosquatting, phishing attacks, and account takeovers of prominent developers, the entity known as JuiceLedger disseminated credential-stealing malware in the Python Package Index repository (PyPi) used by millions of developers. The vulnerability roughly impacts one-third of software packages from PyPi, and allows an attacker to automatically execute code when downloaded on a computer.
- Codecov (2021) Attackers exploited a bug in software company Codecov’s Docker image creation process to gain access to a Bash Uploader script used in mapping out development environments. The attackers modified the script to request users to submit credentials, which would allow them to access and exfiltrate data from their users’ continuous integration environment.
- SolarWinds (2020) After attackers installed malware on SolarWinds’ Orion Network Management Products, the company unknowingly issued trojanized updates to its vast customer base (which included government agencies) — effectively giving attackers a backdoor into thousands of customers’ IT systems, as well as systems used by third parties. Even one year after discovery, Russian attackers were still using the SolarWinds backdoor to discreetly pursue access to systems and data relevant to Russian national security interests.
Software supply chain security standards
Within the last few years — and particularly in recent months — the federal government and other cybersecurity bodies have released new standards and guidance for securing the software supply chain. Here are the ones companies should have on their radar:
#1: SLSA
Supply chain levels for Software artifacts, or SLSA (pronounced ‘salsa), is a security framework developed by Google and other industry stakeholders that aims to prevent tampering of artifacts and uphold integrity of the supply chain at critical junctures. SLSA identifies three major areas involved in software artifact creation — build integrity, source integrity and dependencies — and scores these areas along four separate levels of security ‘strength’.
- Level 1 (Basic security) The supply chain is documented, there’s infrastructure to generate provenance, and systems are prepared for higher SLSA levels.
- Level 2 (After the build) There is more trustworthiness in the build, builders are source-aware, and signatures are used to prevent provenance being tampered with.
- Level 3 (Back to source) The system’s builds are fully trustworthy, build definitions come from the source and a system has more hardened continuous integration.
- Level 4 (Across the chain) The build environment is fully accounted for, dependencies are tracked in provenance and insider threats are ruled out.
See the SLSA framework below:
#2: SBOMs
A Software Bill of Materials, or SBOM, is another standard that is intended to increase transparency and insight into the software supply chain. To understand how it works, suppose your best friend baked you a delicious cake and you wanted to know how they made it (so you could bake it too). You’d ask them for the recipe, obviously, as well as which stores provided them the specific ingredients. The SBOM works the same way for software, presenting in listed form all the “ingredients” and other particulars that went into the making of the software. These ingredients include things like component name, supplier info, developers and authors, as well as metadata and the relationships between each of these entities. By knowing the ingredients of software on any system, an organization can save significant time when it comes to performing risk analysis and vulnerability remediation. The recent White House executive order (EO 14028) and presidential memorandum (M-22-18) have even required that software providers present a SBOM to government customers, depending on the criticality of the software in question.
#3: NIST C-SCRM
Cybersecurity Supply Chain Risk Management, or C-SCRM, is a systematic process devised by NIST to help enterprises manage cybersecurity risks throughout the supply chain, including software artifacts. NIST’s framework encourages organizations to tailor C-SCRM practices across three tiers of activity – Enterprise, Mission and Business Processes, and Operational — for the purpose of continuously improving risk-related duties and facilitating better communication across the enterprise. Foundation practices in C-SCRM include implementing a risk management hierarchy and risk management process, integrating C-SCRM in acquisition policies, establishing metrics for identifying criticality of suppliers and products, and empowering multidisciplinary team structures to coordinate risk monitoring and response.
#4: Open source software management
Open source software is code that permits users to use, modify, study or distribute code to anyone and for any purpose. Because open source software is pervasive, generally cheap (or free), and easy to obtain, developers may unwittingly work on projects having multiple dependencies to vulnerable open source libraries. The NSA’s recent playbook on securing the software supply chain recommends organizations address this by using dedicated systems that can download, scan and perform recurring checks of open source libraries for new versions, updates, and known or new vulnerabilities. NIST also recommends running source code-based reviews with software composition analyses to identify vulnerable components in supplied binaries or images as a way to verify the contents of the end product.
#5: Hardening the build environment
Organizations should also prioritize hardening the build environment, which includes both the individual developer build environment and the production build environment. Code repositories, developer workstations, build systems and servers are all potential areas of vulnerability. Good build security includes:
- Review build scripts and configuration files
- Use version control for pipeline configurations
- Enforce multi factor authentication
- Create access logs for building infrastructure
- Perform regular audits of service accounts
- Monitor for data leaks
- Incident response protocol
In summary
Organizations that understand and can adopt these standards faithfully will be far better equipped to fortify their supply chain and eliminate unnecessary risk. Each of these steps is designed to give teams greater control and insight into the “DNA instructions” that make up secure software. Whether it’s instituting risk management protocols across the organization, introducing automated checks of open source libraries, or enforcing verification of third party dependencies and source code integrity, a combination of these disciplines can help organizations proactively address threats to the supply chain.
