Supply Chain Security is a crucial aspect of software security. This involves securing all the elements in the software development life cycle, ranging from source codes, third-party services, and hardware components, ensuring they are not tampered with or compromised from design to delivery stages.
A vulnerability in any part of the chain could pose a threat to the entire software system, hence the need for robust supply chain security.
A software supply chain refers to the process of creating, packaging, and distributing software and its components. This typically involves various steps, from design, code writing, code review, use of third-party components, container packaging, and eventual software delivery.
The goal of securing the software supply chain is to protect the software from malicious attacks at any point in the chain. This security includes ensuring the integrity of code repositories, verifying third-party components, managing software dependencies, and more.
The components of a software supply chain include:
Software supply chain attacks are malicious activities targeting software developers and suppliers. They can come in different forms: infecting trusted components with malware, hijacking a component, or even taking over the update mechanism of an application.
A supply chain attack can compromise any element in the chain, from the source code to the finished software product. In essence, it's an attack on the process rather than the finished product: it aims to infect the application before it reaches the end user. As a result, even applications with strict security controls can be vulnerable if any stage of their supply chain is compromised.
A classic example of a supply chain attack is the infamous "NotPetya" malware attack, which in 2017 spread to businesses worldwide, causing billions of dollars in damage. NotPetya exploited the automatic update mechanism of a widely-used Ukrainian accounting software, disguised as a routine software update.
// This is a hypotheical explanation, no real malware code included
// A simplified version of how a similar attack might be structured in JavaScript
// The attacker modifies the update function to include malicious code
function maliciousUpdate() {
// The original update code:
// updateSoftware();
// Additional malicious code:
infectSystem();
}
Consider further, some of the biggest categories of supply chain security vulnerabilities:
Malicious code inclusion refers to when attackers inject harmful code into open-source libraries. As a developer, you might unknowingly include this harmful library in your project, leading to undesired outcomes.
// For example, you might use a external library in your application
const notSoSafeLibrary = require('not-so-safe-library');
// Which might have hidden malicious code
notSoSafeLibrary.doHarmfulThingsWithoutYourPermission();
In this category, attackers create a clone of a popular software or package and publish it on registries such as npm. The unsuspected developers who inadvertently install this counterfeit software instead of the genuine one, expose their systems and data to cyber-attacks.
// Instead of installing the legitimate 'lodash' library
// you might install the maliciously cloned 'l0dash' by mistake
const _ = require('l0dash');
// The cloned library might have a function like this:
_.map = function(arr, callback) {
sendAllYourDataToSomeWhere(arr);
// the real implementation of map function
}
Developers usually use a lot of third-party components, plugins, or libraries. Some of these components could host unpatched vulnerabilities, and if incorporated into your project, it escalates the chance of a successful attack.
// Using a vulnerable version of 'marked' library
const marked = require('marked');
console.log(marked('_Markdown_')); // Converts markdown to HTML
The 'marked' library had a Regular Expression Denial of Service (ReDoS) vulnerability. If users inputted a specific malicious string, it could cause the application to experience excessive CPU usage, possibly leading to a denial of service attack.
Common Vulnerabilities and Exposures (CVEs) are a standardized method used to uniquely identify and track publicly known vulnerabilities and exposures in software and systems. CVEs provide a consistent naming scheme, ensuring that information about security vulnerabilities is easily shared across organizations, vendors, researchers, and the cybersecurity community at large.
CVEs are typically published by organizations responsible for coordinating vulnerability disclosures, such as the MITRE Corporation. The process involves collecting information about a vulnerability, assigning it a unique CVE ID, and creating a public entry that describes the vulnerability and provides relevant details. This information is then shared with relevant parties, including vendors, security researchers, and the general public, allowing them to take appropriate actions to remediate the vulnerability.
Several repositories serve as central authoritative sources for CVEs, making them easily accessible to anyone interested in tracking and understanding vulnerabilities:
National Vulnerability Database (NVD): Maintained by the National Institute of Standards and Technology (NIST) in the United States, the NVD is a comprehensive CVE repository that provides detailed information on vulnerabilities along with severity scores, impact ratings, and remediation guidance.
CVE Details: CVE Details is another popular repository that aggregates and provides information on CVEs. It includes additional details such as vulnerability types, affected products, and references to related security advisories and patches.
Exploit Database (Exploit-DB): Although mainly focusing on exploit code, the Exploit Database also maintains a vast collection of CVEs. It provides a platform for security researchers to share exploits and relevant information, including references to the associated CVEs.
Vendor-specific Security Advisories: Many software vendors and organizations maintain their own repositories or security advisory pages where they publish information about vulnerabilities and the corresponding CVEs. These resources contain detailed information specific to the vendor's products and often provide guidance on patches or updates.
By consulting these repositories and keeping track of published CVEs, security professionals, system administrators, and other stakeholders can stay informed about emerging threats and take necessary steps to protect their systems from known vulnerabilities.
Securing software supply chains involves deploying best practices throughout the product lifecycle. Some precautionary measures include:
Understanding and managing software supply chains can play a pivotal role in preventing significant damage to your operations or your users. Adhering to best practices and consistently updating your security measures aiming at continuous improvement will strengthen your defenses against potential software chain attacks.
