It is increasingly common to use open source components in enterprise software projects. Whatever the size of your organization, you are probably making use of open source. As companies move their infrastructure to the cloud - they also migrate open source applications and platforms.
If you are migrating open source components to Azure, or have already done so, you need to pay closer attention to open source security concerns. Luckily, Azure provides several tools and practices you can use to secure your open source components.
Open-source software helps facilitate rapid software development and updates. Since it is community-driven, no single authority is responsible for maintenance and quality. The good thing is that open source software provides you with a resource to innovate quickly. The drawback is that anyone can access the source code and turn it into a vulnerability.
Once you introduce an open source vulnerability into your code, an attacker can exploit it to hack into your system. Depending on the vulnerability and your level of security, the attacker can start performing malicious actions. For example, injecting malware into your systems or moving laterally across the network to exfiltrate data.
The consequences of open source vulnerabilities
Open-source software serves as the core of many critical systems and infrastructure, including medical equipment, utilities, cloud services, government systems, hardware, Internet of Things (IoT) devices, software products, and more. Open-source vulnerabilities in any of these technologies can result in severe consequences.
Since open source components are essentially unknown variants, they should be treated as part of the supply chain and properly secured. However, obtaining visibility into open source software integrated into other products is often a complex task. Versioning and dependencies also become complicated, as source code can be copied and cloned.
Open-source security in Azure
The Open Source Security Foundation (OpenSSF) is a cross-industry collaboration initiated in 2020 between Microsoft Azure and other industry leaders. The foundation aims to improve open source software security by creating a security-minded community, facilitating targeted initiatives, and contributing open source security best practices.
Here are a few of the most important risks facing open source applications.
In an open source environment, applications make their code available to the general public. When a security vulnerability is discovered, initially open source project managers flag the issue and allow time to fix it before revealing the information publicly, to avoid attackers from launching zero-day attacks.
However, at some point, the vulnerability is published as part of the National Vulnerability Database (NVD). Attackers can use NVD vulnerability information to attack organizations that are still using older versions of the open source application.
It is important to realize that using an open source application means that any vulnerability discovered in the code will make your organization vulnerable. You must have a good process for learning about vulnerabilities in your open source components and upgrading or replacing them to avoid targeted attacks.
Most open source projects include a tree of dependencies - additional open source libraries included in the main library. This allows the reuse of functionality, allowing developers to build complex systems without having to code all aspects themselves.
However, the downside of dependencies is that any open source library can contain multiple additional libraries - in some cases even hundreds of libraries - and these may include components that are out of date or contain security vulnerabilities.
It is also significant how dependencies are included. If the original developers forked a library and created their own version, which they included as a dependency, the risk is much greater because that forked version will no longer receive updates and security patches.
Open source components can use one of over 200 license types. Three of the most common are the Apache License, GPL, and MIT. Organizations using open source software must comply with the terms of individual licenses—non-compliance puts the organization at legal risk. In addition, some open source licenses prohibit the organization from commercializing the proprietary software it develops.
To mitigate these risks, you can adopt an open source management tool such as software composition analysis (SCA), which can provide an inventory of open source components in the organization, their licenses, and whether they are aligned with the organization’s policies.
Proper open source security starts with visibility. You need to know which components you are using to learn whether they contain a known vulnerability. You can do this by inventorying your open source components.
Manual vs. automated inventory management
Manually creating an inventory of these components in production environments or high-scale development can be time-consuming. Use automated tools when possible, and integrate them with your pipeline to ensure your code is continuously checked.
Popular open source inventory tools
Popular open source inventory tools include OWASP Dependency-Check and NPM Audit. You can also use commercial services such as WhiteSource Bolt. When setting this up, you should include metadata to help identify the source repository, application, and version or commit.
Integrating tools into your pipeline
Be sure to introduce these tools at an appropriate phase in your development pipeline. You can introduce open source inventory management during branch merging or pull-request validation. Make your inventory results centrally stored and accessible to all relevant personnel.
Once you have inventoried all open source components, you need to check them for security vulnerabilities and determine a level of fidelity. Here are several options to help you perform security analysis:
Open source inventory tools typically provide basic alerting features for public vulnerabilities, and commercial solutions offer additional security information.
In addition to checking your open source components, you should implement pipeline security practices to protect your code, particularly credentials and secrets. Note that some Azure security tools come at extra cost - learn more in this in-depth blog post about Azure pricing.
Here are key authentication and authorization to help protect secrets and credentials:
Here are key CI/CD release pipeline practices to help protect secrets and credentials:
In addition to the above practices, you should also set up permissions management for your pipeline. You can use role-based access control (RBAC) to maintain control of build edits and release definitions in production.
WhiteSource offers an extension that integrates with your CI/CD pipeline to help address open-source security issues and quality and license compliance concerns. Here are notable features of the WhiteSource extension:
You can find the extension on the Azure DevOps Marketplace.
You should align open source security practices, procedures, and tools with your overall security, particularly incident response. The Microsoft Security Response Center can help you coordinate response activities related to open source vulnerabilities.
In this article, I explained the basics of open source security and reviewed security processes and tools that can help you secure your open source components in the Azure cloud:
I hope this will be useful as you improve the security posture of your open source components in the Azure cloud.
ABOUT THE AUTHOR:
Gilad David Maayan is a technology writer who has worked with over 150 technology companies including SAP, Imperva, Samsung NEXT, NetApp and Ixia, producing technical and thought leadership content that elucidates technical solutions for developers and IT leadership. Today he heads Agile SEO, the leading marketing agency in the technology industry.
LinkedIn: https://www.linkedin.com/in/giladdavidmaayan/
Twitter: https://twitter.com/gilad_maayan