Six Considerations for Securing Your Supply Chain

On a fundamental level, securing the supply chain must include considerations of how to secure applications from upstream risk, and how to prevent your organization from generating downstream risk.

• First consideration

Is the open source you use secure?

Understanding open source risk Addressing security at every single point in your supply chain is imperative, but a significant level of risk comes with the open source you use. As you certainly know, open source in today’s development landscape is ubiquitous. It is therefore very safe to assume that the majority of your applications are composed to some degree of open source. The prevalence of open source marks a fundamental concern when addressing supply chain security. While open source is no more or less risky than proprietary code, failure to adequately secure it introduces great risk to your organization’s overall security. Since your developers very likely use open source in nearly everything they create, this translates to large portions of your applications being composed of code that you did not write. Successfully securing your supply chain means maintaining visibility into everything that your applications are composed of, especially when it comes from outside your organization.

• Second Consideration

Is the code you write secure?

Since open source represents the majority of application code, it’s no surprise that it also represents the majority of the attack surface. However, it’s still crucial to ensure that the code your developers write protects sensitive data and systems from cyberattacks. Security defects and weaknesses that are inadvertently coded into applications open the door to attacks such as buffer overflows, SQL injection, and cross-site scripting. Should a system breach occur, these security defects leave sensitive data vulnerable to exposure. A threat actor could exploit these weaknesses to inject malicious code, and then have an avenue to infiltrate the operating system and additional systems maintained by the organization operating the software. Attempting to avoid these issues usually leads to the implementation of code reviews in hopes that a few more sets of eyes on source code will help identify issues. However, most software developers are not trained in secure coding, and many security flaws are far too complex to spot and trace during manual code review. Therefore, static analysis solutions that can automatically review code execution and data paths as well as identify security weaknesses such as CWEs are essential tools in ensuring that you can trust that you’re not introducing any downstream risk.

• Third Consideration

Are you protecting yourself against deliberately inserted malicious code?

Whether it is a disgruntled developer creating a back door or a hacker who has breached a system and is mounting a larger attack, carefully placed malicious code poses significant risk to the software you build and operate. Since most malicious code is planted by someone with intimate knowledge of the software system, the vulnerable system can appear to be completely normal, making it a challenge to identify these risks using traditional tooling. Malicious code detection (MCD) is a process carried out by a team of professionals with the goal of finding suspicious constructs in production binaries, configurations, and data. It also identifies malicious code that typical security tools can’t find, along with the insider threat actors. In addition to code planted from the inside, MCD can also evaluate open source and third- party dependencies for any intentionally malicious packages that have been pulled into codebases.

• Fourth Consideration

Is your development and delivery infrastructure secure?

Containers make it easy to rapidly deploy, patch, and scale an application or microservice. They also ensure consistent performance across multiple different operating systems and hardware platforms. This makes containerization an ideal solution for a cloud-native approach—but it also introduces additional avenues for threats to enter the supply chain. The most common approach developers take when containerizing applications is to start with a base image, often open source, and build on top of it. Layers consisting of additional third-party and custom code are added on top of this base image, and then combined into a single file system, represented as a binary file, when the final image is being executed. Basic SCA tools will assume that files in a layer are added via a package manager such as YUM, which is what it will use to determine composition.

• Fifth Consideration

Are the APIs and protocols your applications use to communicate with other systems secure?

APIs and protocols enable the quick transfer of data and services between applications and users. Despite the growing use of these methods, most organizations struggle to maintain an inventory of the APIs they operate. As a result, they have limited control over which applications and which users can access which service. Lack of visibility and control over APIs threatens the security of critical systems and sensitive user information. Given the opportunity, a hacker can leverage built-in flaws to carry out tasks such as crashing a critical system or perpetrating man-in-the- middle attacks—essentially eavesdropping with the end goal of stealing information like keys, passwords, login credentials, and account details that can be used to mount more significant attacks elsewhere within the supply chain. Protecting the supply chain from these types of attacks requires not only visibility into the APIs that an application is exposed to, but also the ability to prod for flaws and proactively patch security gaps. Modern testing solutions like IAST and fuzz testing can automatically test for known and unknown vulnerabilities, failures, and anomalies.

• Sixth consideration

Is your software supply chain transparent to your customers and other stakeholders?

Aside from regulatory obligations, maintaining an SBOM is a best practice and the cornerstone of a successful supply chain security program. Without a complete, dynamic view of what’s in your applications, neither you, your vendors, nor your consumers can confidently determine what risk you’re exposed to. For an SBOM to be effective, it needs to be continuously populated with the dependencies buried in code, regardless of language, dependency type, or version. And it can’t stop at open source; custom and commercial code needs to be included and tracked as well. The only solution that can provide this type of visibility at scale is a comprehensive SCA tool.