Infamous software supply chain attacks, like SolarWinds, and federal regulations regarding software supply chain security have brought the topic to the forefront. According to Gartner, 45% of organizations globally will face this type of attack by 2025, which would be a 300% increase since 2021. Because most developers aren’t writing their code from scratch anymore, understanding the enterprise’s software supply chain and the intricacies of securing it are critical.
Modern Software Development Uses Open-Source Code
Today’s software development uses a combination of artifacts. These include open-source code, estimated to be included in 97-99% of all enterprise software, and that open source comprises 78% of all software code. However, software supply chain security is about more than open-source code use.
What Makes Up Your Software supply Chain?
A software supply chain encompasses every aspect of the code used – the who, what, when, where, why, and how much.
- Who created the code – internally or third parties?
- What components make up the software? What code, components, binaries, or scripts? What are the supported versions and known vulnerabilities?
- When was the code created, and how long has it been since components were licensed, updated, or patched?
- Where did the software components originate? Was it a registry, repository, open-source collaborative, or codebase?
- Why were these components chosen?
- How much of the production software contains open-source code?
Beyond the code itself, the software supply chain encompasses the infrastructure, hardware, cloud services, and operating systems that support the application. DevSecOps policies and procedures, and the teams who follow them, are also key to the end-to-end production and security of software development.
Understanding Software Supply Chain Risks
The ability to leverage open-source and third-party codes enables SDLC speed, focusing developers on innovative or bespoke aspects of their work. These sources also introduce a host of risks from an unpatched vulnerability, a developer’s innocent error, or a cybersecurity attack using a dependency in the supply chain to distribute malicious code to an intended target.
The most common risks include the following:
- Flaws in software code with unpatched software as the leading cause
- Third-party dependencies come from code developed by those outside your organization
- Attack vectors like compromising source control systems, leaking credentials, malware, patch site attacks
- DevSecOps processes and policies don’t exist, aren’t regularly updated, or haven’t kept up with supply chain complexities
- Lack of awareness into the individual or end-to-end software supply chain
- Inability to monitor or score the risks of existing or new vulnerabilities
The complexity of an organization’s software supply chain will only increase. Taking a proactive approach that includes a commitment to DevSecOps principles provides a mature, robust strategy for software supply chain security.
Software Supply Chain Security
The push for greater software supply chain security is due to the dwindling time between when new vulnerabilities are found and disclosed and when they are exploited. Nefarious actors capitalize on these windows, leveraging vulnerabilities to deliver code into the software supply chain or use access for other purposes. And, because these types of attacks avoid standard defenses, the targets are varied — file systems, networks, executable files, and software packages.
Software Supply Chain Security best practices
Most striking, a risk to one component in the software supply chain creates a risk for each reliant artifact. The following best practices provide a vigorous foundation that addresses individual software components but also the more expansive, end-to-end software supply chain across the enterprise.
Software Bill of Materials
The software bill of materials (SBOMs) is a critical first step. It provides visibility into the full scope of components that comprise an application. Gartner states, “By 2025, 60% of organizations building or procuring critical infrastructure software will mandate and standardize SBOMs in their software engineering practices.”
Automatically generating SBOMs throughout development, testing, and deployment supports a DevSecOps-first approach to software supply chain security.
Tools chosen should leverage the latest standards for signing and verifying software using sigstore keyless, as well as symmetric and asymmetric code signing.
Continuously scan, detect, and prioritize software supply chain security risks
Developers need reliable and straightforward tools to detect and prioritize risks associated with their software supply chains, including exploits in open-source software (OSS). Building on the SBOM tools mentioned, they should also provide runtime verification of SBOMs and correlate them with known vulnerabilities.
The following SBOM components are essential to scan:
- Vulnerabilities
- Software component name
- Software author name
- Supplier name
- Licenses
- Dependencies
- Version string
- Open source components
Once detected, exploits should be blocked during the runtime verification and mitigated.
Deploy static application security testing
Static application security testing (SAST) fetters out security vulnerabilities during software code development.
Automate software composition analysis
Software composition analysis (SCA) identifies the open-source software in a codebase via automated processes and helps find and remediate vulnerabilities from third-party code.
Assess and managed software supply chain dependencies
Assessing the security risks inherent in your software supply chain reveals dependencies that carry risk. Use tools to detect and score high-risk vulnerabilities and deploy compensating controls. Ensuring compliance teams can offset the dangers of high-risk vulnerabilities, particularly when issuing a zero-day patch is not an option.
Software Supply Chain security as a DevSecOps Collaboration
Providing strong and streamlined security for your software supply chain is the ideal use case for a DevSecOps approach. It is a collective responsibility throughout the SDLC.
Software Supply Chain Security Starts with Panoptica
Cisco’s Emerging Technologies and Incubation (ET&I) team is paving the way with “DevOps-friendly” cloud-native security solutions that fundamentally simplify conventional offerings. Built from the ground up to meet the needs of mission-critical modern applications, our Panoptica solution simplifies cloud-native application security making it easy to embed into the software development lifecycle. Panoptica protects the full application stack from code to runtime by scanning for security vulnerabilities in the cloud infrastructure, microservices (Containers or Serverless), the software bill of materials (SBOM), and the interconnecting APIs. And best of all, it integrates with the tools that your application development and SecOps teams are already using.
