By: Matthew Lyon, Dell Technologies; Elena Kravchenko, Imperva; Altaz Valani, Security Compass; Bogdan Ionita, Adobe; Steve Lipner, SAFECode; Ashwini Siddhi, Dell Technologies
In today’s connected world, software is everywhere. Millions of lines of code power this software, so the safety, security, and reliability of software code is vital. Code integrity is not focused on identifying and remediating security vulnerabilities. Instead, code integrity deals with protecting code from sabotage and compromise.
Attackers can gain leverage by violating code integrity with sophisticated attacks. These attacks involve willful tampering to introduce corruption or malicious code. The unauthorized changes are then exploited in security breaches and privacy violations. The impact of such a code integrity compromise can be significant.
Across the industry, working groups, including the Open Source Security Foundation, OWASP, and OASIS-OPEN, are forming to try to address this problem, and each has a different perspective on the problem. SAFECode believes the industry must develop a cohesive and unified approach.
A Broad Attack Surface
Software development includes third-party component sourcing, development, build, verification, and release. Organizations must protect code integrity throughout this end-to-end lifecycle. The scope includes people, processes, and technology.
Today the industry lacks efficient detection capabilities to discover code integrity compromises. Manual code reviews, malware scanning, and static code analysis are common detection techniques. However, malicious code is often designed to avoid such detection, making it difficult to assess the true magnitude of the code integrity threat.
There are multiple attack vectors that must be considered:
- Compromise of third-party software components
- Substitution of malicious code in software artifact repositories
- Compromise of an organization’s source code
- Compromise of build process to inject malicious code
- Manipulation of software delivery pipeline to violate chain of trust
- Code tampering during the software delivery process
Code integrity attacks often exploit a sequence of security gaps to form an attack chain. For example, in the 2019 ASUS hack, attackers hijacked the trusted LiveUpdate tool, and then used LiveUpate to deliver malicious code to unsuspecting customers.
In the case of the SolarWinds attack, attackers compromised the product build environment and inserted malicious code in SolarWinds Orion update packages. System administrators downloaded the compromised update packages from the SolarWinds website.
A more recent example is the discovery of malware in a Popular NPM Package, ua-parser-js, as well as in coa and rc. These NPM packages have millions of weekly downloads. The malware contained crypto mining and password-exfiltrating logic. In this case, attackers appear to have gained access to a maintainer’s account to embed the malware.
The Industry Response
The examples cited above reinforce the need for code integrity. The recent Executive Order (EO) in the United States addresses this need, and similar requirements are emerging across the world. Organizations must respond to these requirements and the escalating threat.
Many working groups are addressing the challenge. The OWASP community is defining a Software Bill-of-Materials (SBOM) standard. OASIS-OPEN is working on end-to-end traceability of threats to affected software components. The Open Source Software Foundation is also working to define code integrity requirements. Additionally, Google SLSA and Microsoft SCIM are two major frameworks demonstrating thought leadership in this space. SAFECode is engaging with many of these organizations to further extend and enhance the current set of best practices for code integrity.
The SAFECode Perspective
SAFECode has also formed a working group focused on code integrity and dedicated to developing a strategy that works for the entire industry. We cannot address the code integrity challenge by working in isolation. It demands a robust response born from diverse perspectives and common understanding.
We’ll be publishing practical guidance over the next few months, and will continue to track emerging requirements and relevant industry progress as well.
SAFECode working groups include representatives from our member organizations. Members can contact [email protected] to join the Code Integrity Working Group.
In our next blog, we will delve into recommended mitigations for the risks that have been discussed in this post. This will include an examination of the relationship between Secure Development Lifecycle (SDL) and code integrity. We will also discuss a layered, defense-in-depth approach to safeguard code integrity.
Further Reading
SAFECode has published many useful guidance documents that address the many challenges of secure software development. Links to resources provided by SAFECode and other industry sources follow.
From SAFECode:
- SAFECode Tactical Threat Modeling
- SAFECode Fundamental Practices for Secure Software Development
- SAFECode Managing Security Risks Inherent in the Use of Third-party Components
From other sources: