Is Software Supply Chain Security More Than Just Open-Source and SBOMs?
If software supply chain security is not just about open-source and SBOMs, what else is there to consider? In fact, a lot more
For many, the concept of software supply chain security has become synonymous to open-source software (OSS) security and the use of Software Bill of Materials (SBOM).
Security vendors offering software composition analysis (SCA) tools are helping to identify vulnerable OSS within our software products by highlighting CVEs. Additionally, many new security start-ups are emerging, offering capabilities to generate and analyse SBOM.
However, there is an important question to ask —
Is securing Open-Source Software (OSS) and generating Software Bill of Materials (SBOMs) sufficient to genuinely address ALL software supply chain security concerns, or if there is more to it?
While there is a heightened awareness of software supply chain security concerns, the definition may vary significantly. If posed with the question, you might get differing answers from everyone asked. While seeking insights from security vendors, their response may align closely with the services they offer.
I firmly believe that software supply chain security is much more than merely performing software composition analysis on open-source software to highlight CVEs and producing Software Bill of Materials **(**SBOM).
So, let’s explore to find out what software supply chain security means in reality and what it entails?
Understanding Software Supply Chains
At a high-level, the software supply chains can be defined as follows —
As per Wikipedia —
“A software supply chain is composed of the components, libraries, tools, and processes used to develop, build, and publish a software artifact.”
RedHat defines software supply chains as follows —
“The software supply chain is made up of everything and everyone that touches your code in the software development lifecycle (SDLC), from application development to the CI/CD pipeline and deployment.
The supply chain includes networks of information about the software, like the components (e.g. infrastructure, hardware, operating systems (OS), cloud services, etc.), the people who wrote them, and the sources they come from, like registries, GitHub repositories, codebases, or other open source projects.”
Getting the definition out of the way, now let’s draw an analogy to a manufacturing process, such as car manufacturing, to better understand software supply chains.
As a manufacturing process involves raw materials, components, equipment, manufacturing processes, people, and distribution channels to create and deliver the final product to end-users, the software supply chains follow a similar pattern involving components, libraries, tools, people, and processes used to develop, build, and publish software artifacts.
The Cloud Native Computing Foundation (CNCF) illustrates how software supply chains closely mirror the manufacturing process as per the diagram below:
Source: CNCF Software Supply Chain Best Practices
Understanding what constitutes a software supply chain is crucial to effectively securing it. If the definition is overly narrow, focusing only on OSS dependencies and generating Software Bill of Materials (SBOMs) to improve transparency and to identify OSS vulnerabilities, it can be challenging to implement a comprehensive security strategy to safeguard the entire supply chain from potential threats.
Considerations for a Comprehensive Software Supply Chain Security Strategy?
While securing OSS could be a significant step forward, it only offers a partial solution to a much bigger and complex problem. So, let’s find out what else do we need to consider as part of an overall strategy to secure software supply chains.
What about the security of third-party vendor products?
Along with OSS security, have you considered the security of third-party vendor products? Yes, I hear you say that these are covered via your vendor assurance programs, but do you have any visibility into what OSS dependencies (both direct and transitive) do they have in the end-product? These products may contain vulnerable or even unsupported OSS dependencies in some cases.
A recent study suggests that software codebases may contain up to 76% of open-source software making it really important for you to understand what OSS components a vendor product has and the security implications.
What about securing developer systems?
Have you considered securing developer accounts, hardening development workstations, or VPN access for remote working? Consider a scenario where threat actors have compromised a developer account through a phishing attack or have exploited a 0-day vulnerability to compromise developer’s machine, allowing them to manipulate the source code in the source code repository to introduce a backdoor in the final product. These are all real threats that demand attention in securing complete software supply chains.
What about securing CI/CD pipelines and development environment?
Have you considered securing your source code manager (SCM), build platform, artifact repositories, secrets management, release and deployment processes? What if a threat actor was able exploit a vulnerability or a weakness in any one of these components or processes to gain direct access to your software development environment and injects malicious code or a backdoor within the final product that gets deployed in production?
The SolarWinds hack involved threat actors being able to compromise the build process introducing a backdoor in one of its products, ultimately providing them access to consumer organizations where the backdoored software was deployed.
What about malicious dependencies and next-generation attacks?
The dangers extend to malicious OSS dependencies. A malicious software is one where threat actors intentionally introduce malicious code or backdoors with the intent of causing harm, whereas a vulnerable software may result from unintentional programming errors introduced by genuine OSS developers.
Threat actors may create packages that seem legitimate but include malicious code or backdoors. They could gain ownership of an open-source package, pose as a contributor, and add harmful code with the hope that it will get approved by package maintainer or an admin.
What about next-generation attacks such as typo-squatting, dependency confusion, repo-jacking, or AI hallucination. These sophisticated tactics could pose serious threats to systems and consuming organizations.
Moreover, these kinds of attacks are not tracked via CVEs, and if not considered may leave a massive gap in your overall software supply chain security strategy.
What about the security of the final product?
Have you considered the security of the end-product itself to ensure that it does not contain security vulnerabilities or has not been altered maliciously?
How about ensuring that your DevSecOps practices include secure coding practices, threat modeling, and security scanning (SAST, DAST, and others) to identify vulnerabilities within the source code as well as the finished product? What about signing artifacts and generating provenance and attestation records and validating these at every stage of the development process and before deployment to production?
An attacker having direct access to your artifact repositories or deployment processes or even the production environment may be able to tamper with software artifacts to inject malicious code or backdoors.
What about the security of runtime and production environment?
Have you considered the security of your runtime or the production environment? What about continuous scanning, monitoring, and improving the transparency of software running in your production environment? A vulnerability in Log4J is a good reminder of having improved transparency of what’s running in your production environment, being able to identify where the vulnerable components are deployed and how much risk do these pose to help you with mitigation efforts.
A question arises, if production even forms part of your software supply chain? If we look at the formal definitions above, the software supply chain goes only up to publishing or deploying a software artifact in production and excludes the production environment itself.
What I believe is since most of the risks are realised in production, it makes sense to extend your software supply chains to production. Even if you have taken all the steps to secure your software supply chains to ensure the security of a released product, it may not remain that way while running in production. New vulnerabilities are identified all the time and may put your application under threat of being compromised.
Every organization operates uniquely, and if certain production processes align with other strategies, such as application security or vulnerability management interlocking security controls, these factors should be considered while determining the components of your software supply chain strategy.
Final Thoughts
To comprehensively secure software supply chains, it is essential to broaden the understanding of security threats and potential attack vectors at every stage within your software supply chains.
Even though Software Bill of Materials (SBOM) is integral to enhancing transparency and security of open-source software within your software ecosystem, it is crucial to understand how it fits in with the overarching software supply chain security strategy.
It’s essential to recognize that supply chain security represents a broader challenge that demands a comprehensive security strategy that goes well beyond open-source software and SBOMs.