There has been a 430% year-on-year increase in attacks targeting open source components to infect software supply chains in the last year. As companies go through their digital transformation journeys, they become more reliant on cloud-native software that utilizes open source components. Malicious actors know this and see it as a huge opportunity. By moving ‘upstream’ to attack the source of the software and shifting ‘left’ to target the developers building software, the number of targets they can infect increases exponentially, without increasing the amount of work required.
Infiltrating open source libraries can also be a more covert approach than directly attacking organizations — if it’s already part of a trusted supply chain, its malicious activity will be detected. Attacking an organization directly is tricky and will typically be harder and yield slower and fewer results. Synopsys’ 2020 Open source Security and Risk Analysis report highlighted how effective this tactic could be. The report found that most commercial code today is primarily comprised of open-source software.
If malicious actors are successful, these attacks allow them to steal both machine identities and sensitive data. While the implications of this can be devastating, there is still a lack of security standards around open-source software. Each piece of software in an open-source library should be authenticated with a codesigning certificate (also known as a codesigning machine identity). Yet today, codesigning machine identities are not well managed, making it unfeasible to verify each one at developer speed.
In the end, the opportunity for successfully protecting software development is in the hands of developers. Making it easy and fast for engineers to protect inside the software pipelines and assure the security of developed products will be the future.
Covert operations
Software supply chain attacks are very difficult to detect, as there is no reason to suspect a previously trusted supply chain has been altered or may not be legitimate. As organizations today are focused on speed, developers accelerate their processes by using functionalities implemented in software libraries or modules written previously by someone else (that are already proven to work correctly). These projects rely on contributions from volunteer developers and typically incorporate elements from other open-source projects. This can make the code prone to abuse accidentally, as known vulnerabilities can be incorporated by mistake or purposefully by adding malicious code pieces. It is simply impossible for the end company to inspect every piece of code to discover a vulnerability or a threat. By targeting these repositories, the attackers significantly increase the attack surface. Since there is no review and approval process for the open sources package repositories, these slowly become free malware-hosting services.
One of the most common attack techniques is typosquatting, which involves mimicking similar names to commonly used packages. The hope is that developers and administrators will accidentally mistype the intended name and install the malicious package. For example, the python-dateutil and jeIlyfish, (with an upper case I instead of an L). These packages then behave the same as the originals, except they also attempt to steal machine identities and other sensitive information from the developer or the user of their software.
In another example of a recent threat, Aqua Security discovered an infrastructure of 23 container images stored in Docker Hub comprising potentially unwanted applications (PUA) hidden either within their image layers or downloaded into their instantiated containers during runtime. Docker Hub is a popular open-source repository for container images and is widely adopted in the development cycle. Developers often integrate their CI/CD pipeline with Docker Hub in order to trigger automatic image builds and publish new images directly to the repository as part of the CI/CD workflow. If attackers succeed in compromising an image, they could effectively compromise a large user base.
How can attacks be prevented?
Developers who want to move as fast as possible are not aware of the risk that these repositories pose. Yet, with more security rules and standardization around codesigning in open source, people can prevent these package issues. It is now critical that developers build a verification process into their workflow and scan for known vulnerabilities.
However, all of the burden must not fall onto already stretched software developers, as checking every piece of code is unreasonable and unrealistic. The managers of open source repositories must implement a review and approval process for any code submitted, otherwise, they risk becoming a reliable and scalable malware distribution channel.
In collaboration with engineers at Cloudbees, Veracode, and Sophos, Venafi is sharing an open-source blueprint for securing software. The blueprint is built by engineers for engineers to immediately have an impact on security. Use, feedback, and contributions are encouraged here.
If security procedures around codesigning are not addressed quickly, attacks utilizing open source software techniques will only increase in frequency and potency. Organizations need to ensure that developers are armed with the automation and clear processes required to incorporate security and vulnerability checks in new software; repositories also need to shoulder the burden and review the submitted code.