Getty Images/iStockphoto
Managing open source components in the software supply chain
Software supply chain attacks are becoming increasingly common. There is no single measure that can stop attacks, but implementing security precautions can reduce risk.
Open source components are an essential part of today's software applications, but they can come at a critical cost: security.
Modern software applications comprise components from many different sources, including open source software (OSS). This can add advantages to the software development life cycle, such as increased development speed, reduced development costs and increased scalability.
But using components from diverse sources also broadens an application's attack surface, increasing the number of entry points attackers can use to gain access to applications and sensitive data. DevOps teams must ensure the security of their software supply chain by enacting proactive measures to mitigate attacks.
What is the software supply chain?
A software supply chain comprises all people, processes, tools, code libraries and underlying IT infrastructures used to create a software application. It includes all aspects of the software development life cycle (SDLC), such as code building, testing, deployment and post-launch maintenance.
Many of the components that make up a project's software supply chain are open source. For instance, design automation company Synopsys published a report in February 2023 that inspected the results of more than 1,700 audits of commercial codebases. The report found that at least one open source component is present in 96% of applications. Almost all commercial applications incorporate an open source component.
A software supply chain attack happens when attackers infiltrate a vendor's software to plant malicious code that infects clients using that software. Infiltration can happen at any point during the SDLC, and many devastating cyberattacks use the software supply chain. Recent supply chain attacks include the SolarWinds attack and the Log4j vulnerability.
Basic software supply chain security requires checking on its vulnerable areas:
- Software code libraries. Libraries are prewritten source code bases that perform specific functions. They are either procured from a commercial third-party vendor, or they are open source. Attackers can plant backdoors in libraries to gain an entry point into the applications that use it.
- Software development tools. Software development tools include integrated development environments that developers use to write program code, such as Visual Studio and Eclipse, and test frameworks like JUnit and Selenium.
- System build tools. These tools automate different tasks such as compiling code, packaging and deploying applications. Security vulnerabilities in these tools could let attackers plant malicious code when using them.
- IT infrastructure. DevOps teams must secure the IT infrastructure where the application will run -- whether in the cloud, on premises or hybrid -- to protect against unauthorized access.
Why are open source components essential for developing software applications?
OSS components are increasingly popular for software development projects. IT providers utilize and support the creation of open source projects, such as the following:
- Amazon. AWS' most popular tools are open source projects, such as EKS Distro, Bottlerocket, OpenSearch and FreeRTOS.
- Google. Google is the original developer of Kubernetes, the open source automation tool for containerized applications. Google also created the Android OS, an open source mobile OS.
- Apache Software Foundation. This foundation is responsible for managing more than 350 open source projects -- among them, the Apache web server.
- Cloud Native Computing Foundation. This organization focuses on developing cloud-native apps and resources. It currently manages more than 150 open source projects.
- Docker. This popular tool for packaging and deploying containers is an open source project.
In addition to powering major applications, OSS components provide numerous benefits. They are free to use, even when developing commercial apps. OSS components are also customizable because the code is open -- developers can extend functionality to include more features.
OSS can reduce development time. The OSS library holds components for nearly any functionality users may want to incorporate into their application. This gives developers more time for other areas of development. Open source projects are also often developed following a specific standard, which results in different open source components interoperating without hassle.
Lastly, open source projects can have robust code quality and security. They are often developed by many contributors, which ensures ample testing of the software component. Any developer can also inspect OSS components for security vulnerabilities, making them more secure than proprietary code that developers can't inspect for security issues.
How can attackers exploit OSS to compromise software applications?
Despite the numerous OSS benefits, attackers can still infiltrate open source components. The most common method of attack is abusing OSS aspects of the software supply chain for malicious purposes, which can happen in different ways:
- Attackers can scan commercial applications to identify open source components and exploit associated security vulnerabilities.
- Attackers might launch direct attacks against team members by stealing their account credentials on build/test servers or code repositories, such as GitHub. Attackers can then steal source code or inject malicious code within project files.
- Attackers might publish malicious source code libraries carrying names similar to popular OSS projects. Unaware developers could incorporate these packages and compromise their projects. This attack is called typosquatting, like in the PyPI typosquatting campaign.
- Attackers may pretend to be legitimate developers and contribute code with malicious backdoors into famous codebases. Developers using these malicious packages will unintentionally introduce security vulnerabilities into their projects.
- OSS packages require configurations when merging into software projects. Configuration errors or default settings could lead to security vulnerabilities.
- OSS components could suffer from zero-day vulnerabilities, which are unpatched vulnerabilities that hackers could exploit to compromise an application.
Mitigate the risks of open source components
To manage security of the open source components in software supply chains, DevOps teams should consider these best practices:
Secure coding practices
Follow secure coding practices when developing applications and ask software vendors to as well. Such coding practices include the following:
- Validate project code files using checksums and digital certificates to verify their integrity before using them in an application.
- Generate a software bill of materials to identify all software components used to create an application.
- Use HTTPS/SSL to encrypt all traffic between developers' devices and the codebase or when exchanging software components with external suppliers.
- Avoid using weak encryption algorithms in code, and don't use OSS components that utilize such libraries.
- Avoid uploading hardcoded passwords or access keys into code repositories.
Secure environment practices
Teams also must ensure that the software supply chain environment is secure throughout development. Best practices include the following:
- Apply the principle of least privilege to protect all resources across the software supply chain (code repositories, development/testing servers and distribution environments).
- Utilize multifactor authentication to restrict access to the development environment.
- Ensure all OSS components and other software dependencies are up to date.
- Download OSS components from trusted sources only -- for example, Docker Hub for sharing container images.
- Use automated tools to deploy applications to reduce attackers' ability to inject malicious code.
- Perform regular security audits on first-tier vendors to ensure their software components don't introduce security risk.
- Isolate development environments. For example, use a separate environment located on a separate network segment for each SDLC phase.
- Use security tools such as security information and event management systems, intrusion detection systems, and intrusion prevention systems to detect suspicious activities.
- Prepare an incident response plan to respond promptly if a software supply chain attack occurs.