| 6 min read
Holistic or comprehensive approaches are what the cybersecurity industry is increasingly aiming at with its products, solutions and services. Indeed, we should ask ourselves, why do we focus on limited-scope examination of our software products when even the remotest of its parts, when compromised, can end up damaging the whole? It's precisely in recent years that one such approach has been gaining more and more momentum and acceptance for software development and deployment. We're talking about "software supply chain security" (SSCS), possibly a dominant standard in the near future.
Before going on to explain this concept, let's answer a couple of questions.
What is a software supply chain?
As we know, a chain is a series of interconnected objects. When we talk about a software supply chain, we refer to a network of components, tools and processes (also involving people and organizations) engaged in the software development lifecycle (SDLC). All these chain elements provide some structure, function or other valuable input to give shape, functionality and quality to the software product in question.
Nowadays, software development doesn't usually happen from scratch. On the contrary, it depends to a large extent on the work of others (on which a certain amount of trust is placed): packages, libraries and other software components, whether open-source or commercial. In a previous post, we pointed out that, in fact, open-source components constitute more than 70% of the total code of the average application. The benefits of this way of working for a company are mainly higher development speed, lower production cost and shorter time to market.
All those third-party software components are integrated, analyzed and monitored with the help of tools and people and have specific relationships with each other, which are called dependencies, giving rise to the supply chains. Both components and dependencies may have licensing issues, configuration problems and vulnerabilities that can affect the final product's security. While these individual difficulties can be easily solved, when it comes to very complex chains, many of their elements may go unnoticed or be completely unknown to those who have resorted to them. But how does this happen?
Let's say you chose an open-source component to fulfill a particular functionality in your software product. That component, in turn, may be dependent on other pieces of code, which in turn may be connected to others, and so on. Hence, the so-called dependency trees. Being aware of that first relationship of your software with the component and not recognizing all the other elements of the tree can generate a false sense of security. The broader and more complex the dependency trees are, the more entry points there may be for attackers to access them and compromise the supply chain.
What are the supply chain attacks?
If an attacker identifies and exploits a vulnerability in a component that is not directly related to or is two or more levels away from your application —let's say by analogy that the issue is in a branch that sprouted distant from the main trunk of the tree— it can still affect your application. Moreover, all those organizations also using that component as part of their products can be compromised. Once the vulnerability is exploited, whether or not with the use of malware, the threat actor can gain access to systems, steal sensitive information, alter or disrupt operations or take control of all or almost all of the systems involved. In other words, an attack on a single point can affect a whole series of elements within the chain. These are supply chain attacks.
Attackers have traditionally focused on exploiting known vulnerabilities that many organizations ignore and, therefore, have not patched or remediated. Once a vulnerability in an open-source component is publicly reported, criminals desperately seek to attack those systems that have not yet been patched. More recently, without waiting for vulnerability disclosure, threat actors have been increasingly aiming to inject malware into widely used third-party components and their updates so that they affect vast numbers of organizations and individuals when distributed.
Related to the above, these criminals have sought to compromise software development tools. They have even ventured to hack into developers' accounts —including trusted contributors to open-source projects— on code-sharing platforms such as GitLab and GitHub and then going on to infect or otherwise corrupt the projects they work on and ultimately affect everyone who makes use of those software products.
Situations like the aforementioned took place in the widely publicized supply chain attacks of SolarWinds and Log4j. The SolarWinds attack occurred in 2020, specifically through malware injection into an update of its Orion platform. This ended up affecting thousands of companies and U.S. government agencies that installed the infected update. In the case of Log4j —an Apache library that appeared to be used in millions of apps worldwide— a vulnerability was identified in 2021 that had apparently existed for more than seven years. By exploiting this security flaw, attackers could make applications perform actions that allowed, for example, data leakage or the installation of malicious code.
Based on cases such as the above, initiatives have been created and strengthened to motivate the implementation of security measures related to software supply chains. The Biden Administration, for instance, issued an Executive Order in May 2021 to improve the nation's cybersecurity, including areas such as supply chain security. In February 2022, NIST released the first version of the "Secure Software Development Framework" (SSDF), and in August, CISA published the "Securing the Software Supply Chain: Recommended Practices Guide For Developers." While, in terms of requirements, these regulations only apply to those organizations doing business with the federal government, what is required there will surely come to be seen as a responsibility and even a necessity in the private sector as well.
What is software supply chain security?
The more we use supply chains, the more attack attempts will increase, and the more we will have to worry about their security. So far, talk of software supply chain security (SSCS) invites many to think only of processes such as software composition analysis (SCA), sometimes including software bill of materials (SBOM), procedures currently growing in adoption among security-minded companies. However, a security approach with only these two elements for an entire supply chain would be insufficient. SSCS is not just SCA with SBOM.
The SCA focuses on recognizing and evaluating open-source components and their dependencies. In the recognition part, the SBOM, a detailed inventory or listing of all such components and dependencies, can come into play. In the evaluation part, license conflicts are reviewed, and known vulnerabilities are identified by matching with a database. However, the SBOM can also provide information beyond those open-source components. And it becomes even more helpful when it updates its reports whenever changes occur during the SDLC.
Although both processes significantly contribute to a software product's security, they only address part of what we initially noted as the software supply chain. SSCS, as a comprehensive approach, should include all the necessary measures to ensure that all operations, tools and components involved in software development and deployment are secure. So, it is not only about verifying and analyzing third-party components, but also the proprietary code, infrastructure, tools and people involved in the development, and even more.
As a quick checklist, these are some of the aspects to be taken into account in SSCS during the different phases of the SDLC:
- Keep source code's version control and history of changes.
- Have adequate processes for verifying the identity of the developers.
- Do peer review of code quality and include secure code review by an external agent to identify security vulnerabilities.
- Introduce static (SAST) and dynamic (DAST) code assessment methods.
- Carry out SCA and SBOMs that allow clear visualization of the entire dependency tree and its possible flaws.
- Keep a dynamic SBOM throughout the SDLC.
- Always verify the provenance of components (automate this as much as possible).
- Perform binary analysis of the code and its dependencies to detect potential vulnerabilities.
- Evaluate the behavior of dependencies to discover if there are compromised interactions.
- Configure rules for dependencies and prevent using those not complying with them.
- Verify supplier policies and procedures to ensure they align with best practices and standards.
- Apply audit logs and tool access controls for both internal and external parties.
- Evaluate partners and other external individuals on factors such as credibility, track record, and reputation in the marketplace.
- Keep isolated and secure build environments.
- Review infrastructure configurations (now usually in the cloud) and verify the provenance of container images.
- Validate that deployments to production meet strict security requirements.
- Perform high-level assessment procedures such as manual penetration testing and red teaming.
- Beyond vulnerability detection and remediation, act in favor of malware identification and removal.
- Implement measures for intrusion prevention and detection (perform continuous analysis of suspicious behavior).
- Define a sufficiently robust incident management and response plan that clarifies what everyone must do and in what order when an attack occurs.
- Maintain continuous visibility into compliance with security standards requirements, ranging from initial implementation of controls, scanning at different stages, and verification of policies before going into production.
- As part of the DevSecOps culture, in addition to technical controls, there must be a governance framework from which all parties are educated on best security practices.
If you'd like to know how we at Fluid Attacks can help your company follow many of the above procedures for the security of your software supply chains from our comprehensive Continuous Hacking service, please do not hesitate to contact us.
Recommended blog posts
You might be interested in the following related posts.
