What do the Log4J zero-day vulnerability, the SolarWinds attack, and Alex Birsan’s hacking of Apple and Microsoft have in common? The answer is simple: software supply chain security. But while the answer may be simple, each example highlights a different aspect of software supply chain security.
Definitions of software supply chain vary depending on who you’re talking to, and in what context, but simply put, securing the software supply chain means analyzing software from external sources. This can include open source code, commercial off-the-shelf (COTS) software, firmware, container images, APIs, and any other resource that was not developed in-house. At first glance, this may seem like a concern only for software consumers, who stand to be the most impacted by a compromised supply chain. But that’s not the case. It’s also the responsibility of software producers to take necessary steps to protect their applications from downstream risk, and provide their consumers with transparency of their security efforts.
Analysis of external software should include proactive and reactive efforts to reduce risk. This means writing secure code, keeping vulnerable dependencies out of the application life cycle, continuously monitoring for new vulnerabilities, avoiding dependencies with poor health, and securing the entire development life cycle against injection of malicious code or malware, just to name a few. All this should be done with the expectation that the consumer of the software will inquire about the practices in place, and the contents of an application that could introduce risk.
In the Critical Capabilities for Application Security Testing report, Gartner lists software supply chain security use cases, and shares what every organization should be considering to secure their software supply chain. Let’s break down those critical capabilities.
Software supply chain security
Gartner identifies software supply chain security as the most critical capability of securing the supply chain. This may seem confusing or redundant, but there is a distinction between software supply chain security as a use case or initiative, and software supply chain security as a grouping of features and functionality. We are talking about using the latter to achieve the former.
The features and functionality associated with this capability can be classified as those that enable teams to be proactive in mitigating the risk introduced by external software. Teams can be proactive by evaluating software for problematic indicators, like poorly maintained projects, inadequate security controls, a history of vulnerabilities or malicious code, poor maintainer reputation, and many more. This also involves producing and managing artifacts that consumers can use to perform their own evaluation of the security of software built by a provider. This can come in the form of a Software Bill of Materials (SBOM), or an attestation to security practices that can be used to better understand the amount of risk that software introduces into an organization.
Software composition analysis
Identifying all external dependencies used to build an application can be a challenge. More than 75% of the code in an average application is from an open source project. Asking development teams to manually track which dependencies they use demonstrates a disconnect from the reality of modern development practices and how package managers and dependency trees work. But without complete visibility of these dependencies, you can’t track which supply chain threats impact an application. This is why software composition analysis (SCA) plays such a crucial role in software supply chain security.
SCA tools can be built directly into a development pipeline with DevOps integrations to automatically detect open source (and sometimes commercial and custom components). They also associate them with areas of security, their licenses, and any health risks, to help you enforce your policies and ensure that issues get addressed as needed.
Not only do SCA tools identify dependencies and help teams act on risk, they also generate SBOMs that teams can ship with applications to provide supply chain transparency to the consumers of the software.
Container security scanning
Building applications and packaging them into containers has become a popular method of deployment. This helps teams easily scale their deployments to meet demand, overcome issues associated with varying deployment environments, and enable a microservices approach to application development. However, modern AppSec practices don’t always suffice when securing containers.
Base images tend to be the easiest aspect of a container to scan for vulnerabilities. In fact, many container registries do some flavor of it themselves. However, there can be hidden issues in what’s added by the countless layers on top of the base image. To get a true picture of risk, container images need to be scanned after they’re built. As such, security teams should prioritize a solution that can analyze the file structures that make up a container image to identify dependencies and associated risk. Otherwise, containers can represent a weak link in the software supply chain.
Static application security testing
Development and security teams can spend countless hours and dollars on securing their applications from external threats, but it will all be for nothing if they’re not writing their own code securely. Traditionally, this is what code review is for, but manual efforts like that can be ineffective and time-consuming.
Static application security testing (SAST) tools automatically scan source code and evaluate it for potential security weaknesses, which can lead to issues such as buffer overflows, SQL injections, and cross-site scripting. These types of flaws can be difficult for the human eye to detect, but SAST can do so with precision, speed, and on a regular cadence. When countless high-severity vulnerabilities can be attributed to simple flaws like insufficient data sanitization, using a SAST tool can make all the difference in keeping a development team from being the upstream risk.
Application security posture management
Securing the software supply chain means managing risks across the entire application life cycle. Doing so requires a variety of tooling and processes, which will inevitably yield a bevy of results. Application security posture management (ASPM) tools help automate all the different tests across the life cycle, while ingesting the results from each one.
The benefits of ASPM are twofold. First, before any scan occurs, teams can use ASPM to define policy across all their testing types, and configure when each test occurs and which findings should trigger which workflows. Second, as results are produced, ASPM tools can correlate and analyze findings, giving teams a single dashboard for triaging and remediating issues. Simply put, ASPM provides one single picture of risk across the entire software supply chain of any application in development.
Developer enablement
Developers are the first line of defense against supply chain threats. Not only are they the ones deciding which third-party dependencies to leverage to build an application, they’re also tasked with fixing the issues identified by the tools mentioned in this blog.
As such, it’s important to meet developers where they already are. Before a single line of code is written, security teams should be defining policy aligned with the amount of risk the organization can tolerate. Scans should work directly with development tools, like IDEs and SCMs, to automatically trigger and enforce policy. Additionally, any issues identified and sent back to development teams should include as much information as possible to assist in resolution efforts, like code location, issue type, remediation guidance, and education/training options associated with the particular issue. The earlier in the supply chain that issues are caught, the quicker they can be remediated. This reduces risk and puts less strain on the resources needed to make the fix.
Software supply chain security solutions
In an analysis of 12 vendors performed by Gartner, Black Duck received the highest score for our ability to satisfy the Software Supply Chain Security use case. Our application security testing (AST) portfolio can provide a software supply chain security solution that meets a variety of customer needs and requirements.
Black Duck SCA provides the foundation of a software supply chain security approach. Since almost every modern application uses some form of open source or external components, which are developed completely outside of the control of the organization utilizing them, they naturally represent the largest surface area for risk. Our SCA tools integrate directly within the application development pipeline to automatically scan for open source and third-party components in source code, container images, and firmware. The result is an accurate and complete SBOM that can be configured and exported to meet a wide variety of requirements. Each component identified and added to the SBOM will also be evaluated for security vulnerabilities, malicious packages, health and viability, and license conflicts.
Our SAST solutions fill in the gaps between third-party code, and work to harden code written in-house. Much like SCA, SAST can also be built into development and build tools to use standard events as triggers to run scans in the background. Our SAST customers enjoy fast, accurate results that provide developers with all the information needed to make the fix before the issue makes it to production.
We realize that the last thing teams need is yet another tool to onboard, configure, and consume results from. With Software Risk Manager, our ASPM solution, customers get a full software supply chain security solution—SCA, SAST, container scanning, developer enablement—in a single dashboard. This means that security and compliance teams define all their AST policy and consume and triage the correlated results in the same place. Any policy defined will be automatically enforced via SDLC integrations so that development teams can focus on innovating while protecting applications from upstream risk.
For more details on how you can establish visibility of your software supply chain and protect you and your customers from risk, visit us here.
Report
Gartner® Critical Capabilities for Application Security Testing
Continue Reading
.jpg)
What is the Xz Utils Backdoor : Everything you need to know about the supply chain attack
Apr 08, 2024 / 5 min read