Guest post originally published on SparkFabrik’s blog
The concept of the Software Supply Chain is growing in importance since the Cloud Native approach has become increasingly central to modern application development. As in traditional industry, an increasingly complex supply chain exposes a higher number of malicious attack points, and requires tracking and verification that could previously be ignored.
This is demonstrated by a number of significant events in recent years that have strongly influenced the way we understand security. In the current landscape, it is important to focus on new elements such as OCI artifacts and how they too can be affected by vulnerabilities within the supply chain as a whole. This is why it is becoming increasingly important to know about techniques and open-source tools that enable us to protect ourselves from such threats.
What is the Software Supply Chain?
Software Supply Chain Security (SSCS) has become an increasingly important topic in the field of computer security. SSCS concerns the entire software supply chain, which includes the process of developing, distributing, managing and maintaining the software components used in a system. Software supply chain security is crucial to ensure that the software used is free of vulnerabilities and malicious components. A threat in the software supply chain could allow an attacker to compromise the security and reliability of computer systems, with potentially devastating consequences.
According to Wikipedia, the supply chain is a network of individuals and companies that are involved in creating a product and then delivering it to consumers
This is an ultra-generic definition that can obviously be applied to any type of product, from a shoe to a Kubernetes cluster.
The infographic below shows how the traditional supply chain is very similar to that of software, starting from our sources, which are our raw materials, to the delivery of the finished product to our users.
Obviously, the software supply chain suffers from a number of specific vulnerabilities, which are well represented by this further infographic derived from SLSA (“salsa”), a security framework specifically designed to help secure every link in the chain, and also the points in between.
By framework, however, we do not mean a software framework, but rather a set of guidelines and practical, real-world implementations, such as SBOM generation or cryptographic signing, build attestations and more. We recommend that you delve deeper and start adopting it incrementally, since it is a layered project that can be adopted progressively.
Security is not a tool, but a culture, and above all it is always in a transitory state: what is secure today may not be secure tomorrow, so it is always good to adopt as many good practices as possible.
So often there is a tendency to think that supply chain vulnerabilities come mainly from the use of malicious dependencies, when in reality every block in the chain is subject to vulnerabilities, as are their interconnection points.
Recent attacks show that it is precisely the latter that are growing vectors of attack.
Let’s take point C in the picture as an example: it represents the moment when a vulnerability compromised the build servers.
Imagine this scenario and how complicated it would be to detect. We might have been infected by malware that only wakes up during the compilation process, producing a compromised binary with a backdoor inside, which is also potentially cryptographically signed.
This track will be fed to our users who will in fact receive something legitimate and signed by us.
This was precisely the vector for one of the most important and serious attacks in recent years. Threats to Software Supply Chain Security can come in different forms.
A well-known example is the attack on the software supplier SolarWinds in December 2020. The attackers infiltrated the software development process by compromising an updated version of the Orion software. This compromised version was then distributed to end-users, opening the door to a series of malicious activities. The attack on SolarWinds demonstrated how a threat to the software supply chain can affect wide-ranging organisations, including governments and high-profile companies.
Another recent example was the ransomware attack on Colonial Pipeline in the US in April 2021. The attack exploited a vulnerability in the pipeline management software and caused the suspension of operations, leading to severe disruptions in fuel supply in the region. This event highlighted the vulnerability of the software supply chain and the importance of securing critical infrastructure software components.
Figures from Sonatype’s annual report on the state of the supply chain show that the number of attacks has been growing exponentially since 2020. The question is why this is happening. There are several reasons.
The first is certainly the growth in demand for open-source software, which over the years has established itself as the reference model Today, there is no software in any sector that is not based on open-source components: it is estimated that more than 98% of the software on the market contains at least 1% of it – and the remaining 2% probably do not know they have it.
Moreover, today more than 80 per cent of the software that is produced is transitive dependencies, which are the most dangerous.
What are the main types of attacks in the supply chain?
Let’s try to list them.
DEPENDENCY CONFUSION OR NAMESPACE CONFUSION
Exploits the feature of almost all popular package managers, i.e. it checks for the presence of a package first in a public registry and only afterwards in the private one. In other words, all an attacker would need to do is learn of a private package name, load it into the public registry with a higher version to make it a priority, and then force the package manager to download it.
EXPLOITATION OF A POPULAR LIBRARY AS A VECTOR FOR MALICIOUS CODE
It can occur in several ways, either by compromise or by gaining trust in the project by pretending to be a contributor and when trust is gained, by inserting malicious code directly or via a dependency.
CREATING A COMPONENT WITH A NAME VERY SIMILAR TO AN EXISTING ONE,
or entering an error in the name (e.g. ‘electorn’ instead of ‘electron‘). Then all that remains is to wait for users to download. Interesting examples can be found here Bytesafe.
FALSIFICATION OF COMPONENTS
Attackers can falsify or replace legitimate software components with compromised or malicious versions. This can happen during the transport of components or through untrusted third-party suppliers.
INFILTRATION OF DEVELOPMENT PROCESSES
Attackers attempt to compromise software development processes by infiltrating source code management systems or software package distribution repositories. This allows them to introduce malicious code or vulnerabilities into software components.
COMPROMISE OF UPDATE SERVERS
Attackers can compromise the servers used to distribute legitimate software updates. In this way, they can disseminate compromised software versions to customers.
TARGETED ATTACKS ON CRITICAL INFRASTRUCTURES
Critical infrastructures, such as energy networks or financial systems, may be subject to targeted attacks on the software supply chain. Attackers seek to compromise critical software components for these infrastructures in order to cause significant damage or disrupt operations.
Among the attacks that have become popular in recent months in the supply chain sphere is one called ‘Protestware‘, an attack where the project maintainer deliberately sabotages the project to cause damage or malfunction, as a sign of Protest. There were important cases in 2022, but surely the most famous is the colours/fakers project that added DoS code to large corporations.
The recent increase in supply chain attacks has, among its consequences, a very heavy fallout on the economy of the entire industry, with implications concerning possible distrust in this development model and a negative impact in terms of reputation. It is estimated that the cost of supply chain attacks alone could exceed USD 46 billion this year, and reach well over 80 by 2026.
This scenario has led the world’s major governments to enact new laws with the aim of regulating the industry more carefully, also going into detail about the supply chain aspects and the production of software, its processes and responsibilities along the supply chain.
In the United States, the national strategy follows the executive order issued in 2022 and is already taking effect in the various states. The main objective is the regulation of relations between public and private, going down to the specifics of technologies, down to the level of SBOM (Software Bill of Material) and accountability.
In Europe, however, the issue is much more delicate. The CRA (Cyber Resiliency Act) has the task of regulating any product containing digital elements. Using a parallelism, it is like defining a CE mark to be applied to software, as is the case for electronic components.
These are obviously fundamental and important initiatives, and we think it is right that they should be brought to the table, but they pose a problem of sustainability of the Open Source development model: on the one hand there are the compulsory technical requirements that could increase considerably in order to be able to publish approved software, and on the other the concept of responsibility that could fall on those who produce code to make it available to the community, an eventuality that is obviously not compatible in a model that on a large scale is based on voluntary and independent work.
As was to be expected, responses came not only from governments, but also from the community, which responded in a strong and organised manner.
A new foundation, the OpenSSF, was created as a branch of the Linux Foundation, with the mission to support security in the open-source ecosystem. Work is being done on standards, such as CycloneDX and SPDX for generating SBOMs, new software is being developed to simplify the asymmetric key signing of software with Sigstore, and much more.
This is an excellent sign of awareness on the part of the community, which should help guide governments and organisations to make decisions for the best.
Recent Attack Stories in the Software Supply Chain
We mentioned this in the opening of the article, but to give substance to what has been said so far, let us take up and elaborate on one of the most important supply chain attacks since 2020.
Let’s talk about the SolarWinds case, the practical and large-scale demonstration of one of the most serious attacks in the history of this industry. SolarWinds is an American company that develops solutions for monitoring and managing Information Technology (IT).
Among their customers are the world’s largest enterprises and many government agencies, such as the
Pentagon, Homeland Security, the National Security Agency. One of its most famous and popular products is the Orion platform, and this is where the story starts.
In January 2021, Crowdstrike, a cybersecurity company among the first to be hit, discovered the existence of the Sunspot malware, designed to replace legitimate sources at build time with a malicious version containing the Sunburst backdoor. Sunspot had infected the Solarwinds build systems. As a result of this process, a new release of Orion, containing malware, was distributed to all customers as if it were a normal security patch.SolarWinds is yet more proof that no organisation today is safe from the risk of compromise.
In 1984, Ken Thompson in a famous paper called ‘Reflections on trusting trust’ wondered just how far we should trust that code contains trojan horses. The moral is simple: we can never trust code that we have not created, no extensive source verification can ever fully protect us.
But we can trust the people who write it, so let us see how we can do that.
How to reduce Software Supply Chain vulnerabilities?
To reduce vulnerability in the software supply chain, a number of preventive and mitigation measures are required. We try to provide as comprehensive an overview as possible, but as mentioned, this is a rapidly evolving area.
- Verification of vendor security: performing a rigorous security assessment of software vendors is essential. This involves analysing the security practices implemented during software development, evaluating the testing and code review processes, and verifying data protection measures.
- Validation of software components: It is important to verify the integrity and authenticity of the software components used. This can be done through the implementation of digital signature mechanisms, the use of trusted distribution repositories and the adoption of component verification practices.
- Constant monitoring: it is crucial to constantly monitor the software supply chain for anomalies or intrusions. Advanced threat detection systems can help identify suspicious activity and report potential breaches.
- Collaboration and information sharing: Sharing security information between organisations can help strengthen the resilience of the software supply chain. Organisations can benefit from collaboration to identify and address common threats.
Watch the video of the talk by Paolo Mainardi, CTO of SparkFabrik, and Andrea Panisson, Cloud Architect of SparkFabrik, at KCD Italy 2023.
How to reduce vulnerabilities using OCI artifacts?
In the previous section, we identified the most high-level actions to mitigate software supply chain vulnerabilities. Going even deeper, on platforms such as Kubernetes, which exploit container architecture to distribute applications, it is possible to protect the supply chain using OCI (Open Container Initiative) artifacts.
OCI artifacts are the starting point for creating the container images used in a Kubernetes environment. Their security is therefore crucial to avoid the injection of malicious code or vulnerabilities with cascading effects. What are the best practices? Here are a few:
- Use verified OCI artifacts: Ensure that you only use OCI artifacts from trusted and verified sources. Check their digital signatures to ensure that they have not been altered or compromised during transfer or storage.
- Regular artifact updates: Keep OCI artifacts up-to-date with the latest versions released by developers. New versions often include security patches to fix known vulnerabilities. Monitor security notifications and act promptly to apply the necessary updates.
- Evaluation of package dependencies: It is essential to evaluate and monitor package dependencies to detect obsolete or vulnerable versions. Use dependency analysis tools to identify and solve possible security problems.
- Verifying the Integrity of Artifacts: During the transfer and storage of OCI artifacts, it is important to ensure their integrity. Use secure connections to transfer the packets and implement integrity control mechanisms, such as digital signatures, to ensure that the artifacts have not been altered or corrupted.
- Implementation of security controls: It is useful to implement release pipelines that include static code analysis, vulnerability analysis, security testing and approval process reviews. In this way, you can detect and resolve vulnerabilities throughout the software development process.
- Threat monitoring: Use threat intelligence tools and keep abreast of the latest trends and attack techniques in order to take appropriate preventive measures.
Software supply chain security is a shared responsibility between developers, Kubernetes operators and OCI artifact providers. Collaboration and adoption of best practices are essential to ensure a secure and reliable Kubernetes environment.
Observability simply means using all three of these sources of information in aggregate to analyse and predict the operation of a complex system that would otherwise be impossible to manage safely.