If you were buying a toy for a child and you noticed on the label that it contained lead paint, you wouldn’t buy it, no matter how cool or pretty the toy looked. As a consumer, you probably don’t know exactly how the toy was manufactured and how it was delivered to your local store, but you have an innate and intuitive understanding that it matters if a product is made with safe materials.
This raises a troubling question: why is it easier to find out if a toy contains unsafe materials than it is to find out if a software application contains unsafe or risky code?
Answering that question thoroughly would require another book. Meantime, it’s safe to say that if you are worried about the code you are using, you are not paranoid. The simple truth is that most of us cannot say with any reasonable degree of accuracy what is or isn’t in the applications we use. We have scant visibility into the software supply chain. That’s a huge problem.
It’s not hard to imagine compiled software that unintentionally includes a logic bomb that might stop the software from running. It only takes a few lines of bad code to crash a system. A software glitch in an HR system would be inconvenient. A software glitch in an implanted medical device, however, might prove fatal.
Genuine Risk and Real Danger
As the pace of digital transformation accelerates, securing the software supply chain becomes absolutely critical. The risks aren’t merely economic. There are physical dangers, too. Software is now embedded in many of our machines and devices. Cars, trains, airplanes, elevators, air conditioners, street lights, medical devices, wind turbines, thermostats and children’s toys rely increasingly on software.
The SolarWinds attack [1] cast a harsh spotlight on the software supply chain and on the methods used to secure end-to-end processes. It’s fair to say the attackers were counting on the fact that no one had complete knowledge of what was in the software, which enabled them to insert malicious code that compromised the end environments at various customer sites.
In this chapter, we’ll take a look at some of the ways in which software security issues can lead to much larger problems affecting billions of people worldwide. In a very real sense, the internet let the genie out of the bottle. Code is now everywhere; it has become an integral part of our daily lives. We cannot live without software. For quite a while, however, the scope of software security has been limited to public key infrastructures (PKIs), code signing and certificates.
Clearly, we need to do more. Software security issues now threaten our economies and our safety. Sadly, there is no magic formula for securing software. Ensuring the security of software requires diligence, awareness and close scrutiny at every step of the software development process.
In our globally interconnected digital economy, security cannot be an afterthought or a last-minute addition. Security must be designed into every application, at every level. Remember, a chain is only as strong as its weakest link. Even the most elegantly written software can be compromised by a few lines of code.
Securing the software supply chain is not a once-and-done affair. Software integrity depends on the ongoing and continual efforts of many individuals, teams and organizations. It involves the orchestration of processes and technologies operating in multiple environments, often in various parts of the world.
Here’s a brief list of areas where software supply chain risks and opportunities present themselves:
- Open source code
- Commercial code
- Proprietary code
- Intellectual property (IP) and data
- Software bill of materials (SBOM)
- Build management
- Cloud, DevOps, and DevSecOps
- Third-party suppliers
- Manufacturing supply chain
- Installation, service, and maintenance
- Requirements, standards, laws and regulations
Open Source Code
According to a Synopsys Black Duck study, open source code comprises “more than 35 percent of the average commercial applications” and 75 percent of code developed for internal-use applications.[2]
The inherent risk of using open source code is widely recognized but difficult to manage. It requires time for assurance using code reviews, analysis tools, and continuous evaluation of the open source project updates. An open source project may have thousands of lines of code constructed from hundreds of authors. It would require very little skill to embed malicious defects, threats, command and control, or logic bombs into a package.
Open source also presents a challenge for those who are required to provide a software country of origin to their customers. Most code commits do not request a code developer’s location and thus any open source package can contain code from any country.
To manage open source code risk, an organization should have clear procedures for evaluating open source packages versus using proprietary code. When open source software is included, a thorough review of the package, code commits, CVEs (common vulnerabilities and exposures), and the code itself should be performed by senior developers and code analysis tools. These tools should be executed on the code along with a threat model specifically for the open source package.
Commercial Code
The use of commercial code may alleviate some risk while introducing new ones. Commercial software or libraries are classically trusted but are not perfect. The same techniques (code inspection, code analysis, CVE reviews, and threat modeling) to reduce risk in open source should also be used for commercial code if allowable. Unlike open source, there are fewer package updates or patches to continuously monitor, but that can increase risk if there are unmitigated but exploitable vulnerabilities.
To manage commercial code risk, negotiate strong conditions with the commercial supplier. This should include a complete software bill of materials, service level agreements for disclosure of incidents and vulnerabilities, threat models, secure testing reports, and licensing terms for near-lifetime security updates.
Proprietary Code
One would think that proprietary code would not be part of supply chain risk, but there is a small amount of risk to consider with internally developed code. In customer questionnaires, a common software supply chain question focuses on background checks and developer locations. With geopolitical tensions increasing, more questions will surface on these areas as well as the capability to monitor code check-ins and have stringent change management approvals.
To manage proprietary code risk, consider creating an “insider trust” program (rather than the negative term “insider threat”) and enhancing change management processes. Logging, monitoring, and alerting should not only be applied to development tools, but also for development staff and the protection of intellectual property.
Intellectual Property (IP) and Data
Threat actors are always searching for publicly exposed data and intellectual property in cloud storage infrastructure and cloud-based technologies. Unintentional sharing of Intellectual Property (IP) and data loss can ruin a company at whatever stage—from start-up to mature. Data loss and breaches can result in fines, legal costs, and reputational damage.
To reduce the risk of IP and data loss, begin by using several of the approaches mentioned earlier such as “insider trust” and monitoring. Create data classification policies, processes, and awareness campaigns for all company staff. This should include a process for classifying source code, architecture information, hardware design, internal company data, etc. and then implementing controls for securing the information.
Software Bill of Materials (SBOM)
A software bill of materials (SBOM) is effectively a nested inventory, a list of ingredients that make up software components such as operating systems and libraries.[3] An SBOM generally contains authorship and version details of proprietary, commercial, and open source elements. SBOMs enable administrators to quickly assess the risk of disclosed vulnerabilities and the software assets deployed within a company.
To reduce risk when building software, request SBOMs from any commercial suppliers and generate SBOMs for open source and proprietary projects. Use SBOMs during threat modeling and testing to expose risks and threats. Maintain an inventory of SBOMs for each release of software for quick risk analysis, appropriate mitigations, and timely remediations.
Build Management
The build management process is critical in secure software supply chains. Manual builds can introduce risk when important steps are bypassed such as code analysis, code signing, and creating bills of materials. Even automated builds present risk when change logs and alerts are not examined for errors, threats, and unauthorized access.
To reduce risk in the build management process, carefully review common tactics, techniques, and procedures (TTPs) using a robust framework such as the MITRE ATT&CK® frameworks.[4] Implement controls for role-based access, logging, monitoring, service accounts, code signing, generation of salted hashes (for integrity checks) and change management.
Cloud, DevOps, and DevSecOps
Similar to the risks identified in build management, both manual and automated activities bring supply chain risks to cloud operations. The limited access in cloud environments also limits the awareness of improper change management and threats. A significant risk for cloud environments is the lack of integrity checks before packages are deployed.
To reduce risk in cloud operations, implement controls and testing as required under SOC2, ISO, CSA (Cloud Security Alliance), or FEDRAMP. Pay special attention to the access and movement of software packages through the deployment process. Implement hardening procedures, configurations, technologies and monitoring made available from the cloud hosting provider to strengthen the entire operational workflow.
Third-Party Suppliers
Third-party suppliers can introduce risk to your software, firmware, and systems from the practices, code, and technologies that the supplier uses to build the product. A single open source library, for example, can introduce critical vulnerabilities into your application.
If you purchase any development services, software or firmware from a third-party supplier, you should conduct a full assessment on the supplier’s software development practices. This should include a review of cybersecurity training, awareness, threat modeling, secure development, code analysis, secure testing, vulnerability scanning, and penetration testing. In alignment with a third-party supplier, a cybersecurity agreement should be established which includes the previous topics as well as vulnerability disclosures and patching service level agreements. Upon receipt of any third-party software, a thorough inspection and analysis should be conducted using scanning tools and the supplier’s SBOM (software bill of materials).
Manufacturing Supply Chain
For software or firmware being distributed through manufacturing and supply chains, there is risk to its integrity when the chain of custody is not controlled and logged. True end-to-end supply chain security must incorporate all the steps between development and delivery to a customer. Manufacturing and supply chain personnel should also be trained on special topics related to cybersecurity including the dangers of USB keys (which can contain malware) and controlled access to private software keys for registration.
To reduce risk in the manufacturing supply chain, careful analysis of each step from the completion of development to customer delivery should be taken to implement controls, procedures, and tests. Special attention must be made for any third-party suppliers or manufacturers who can introduce additional risk and threats into the lifecycle.
Installation, Service and Maintenance
The software supply chain can be compromised when additional personnel and processes have access to software and firmware. The same concerns from the manufacturing supply chain also apply to installation, service, or maintenance in the normal course of duty. Additional risks arise from configuration tools (which often are not created using a secure development lifecycle) and testing frameworks.
To reduce risk with installations, services, and maintenance, perform a detailed review of the procedures to identify risks and threats throughout the activities. Service tools, testing frameworks, and spare parts should be inspected continuously for malware and malicious threats. Special cybersecurity awareness training should be developed for personnel who have direct access to customer products and systems.
Requirements, Standards, Laws and Regulations
Alongside application security and product security, there must be improvements to the security of the software supply chain. To speed the process, new requirements are presented from customers and governments through questionnaires, agreements, contracts, and more. Government and regulatory oversight from FEDRAMP, NERC, CMMC, and other programs were increasing prior to SolarWinds but now the speed has accelerated further.
To reduce risks associated with new requirements, proactive compliance toward new software supply chain standards, laws, and regulations will give companies an advantage in the marketplace. Use customers, industry associations, and peer networks to maintain awareness of new supply chain requirements, standards, laws, and regulations.
Learn From Other Industries
The European wine industry is highly regulated and strictly enforced; there are stern penalties for making wine with the wrong kind of grapes. Across the industry, provenance is taken seriously. Every step of the winemaking process – from gathering grapes to storing bottles – is regulated and watched over zealously. In the Northern Rhône region of France, for example, red wines must be made with Syrah grapes. In the Piedmont region of Italy, Barolo wines are made exclusively with Nebbiolo grapes.
If the global software industry was monitored as closely as the European wine industry, it’s safe to say there would be fewer hacks, exploits, breaches and service disruptions.
Until software supply chain risks are more widely understood and appreciated, it’s up to us as professional security experts to provide as much safety and resiliency as we possibly can.
Hopefully, the risks described in this chapter will inspire you to take positive steps that will improve your understanding of software supply chain security issues and help you create practical strategies for avoiding the negative consequences of a vulnerability, exploit, breach, data loss or service interruption resulting from faulty or malicious software code. Positive steps include enhancement of controls (e.g., access, logging, monitoring, and alerts) and examining each activity throughout the entire supply chain for risks and threats, which may include personnel, tools, change management, and lack of oversight. Last, but not least, make it a habit to utilize resources such as The Purple Book to learn how practitioners at various organizations are working to enhance their security postures.
.svg)
.svg)
