The Dangers of Open Source and Software Supply Chain Attacks
Securing your software development lifecycle
Digital innovation is key to the success of businesses across all sectors. Mounting competitive pressures and continuously evolving customer behaviour means that organisations are expected to adapt rapidly, more than they ever have before. This need for flexibility, change and faster innovation coupled with the complexity of today’s applications demand efficient reuse of code and, to this end, companies are utilising large volumes of open source libraries.
In order to keep up with the pace of transformation, dependence on both third party and OSS libraries is now an integral part of the development process when writing code. Why try and reinvent the wheel every time? Effective use of open source libraries can be an efficient tool in this age of ever evolving digital solutions in a competitive market place.
OSS components make up 90% of modern applications. When such a large proportion of the fundamental building blocks of code are being taken from open source libraries and then amalgamated inside complex system designs, it is easy to see that the chances of losing track of where each of those individual blocks came from is high. But what are the risks that come with this?
Visibility is paramount when defending an organisation against security and legal risks, and this visibility includes the origins of the components in our applications. Take one of the applications that your business uses on an everyday basis: do you know what OSS components are in use? Do you know in which part of the code they reside? Can you name the licenses associated with those components? I’m going to hedge my bets that the answer is probably “no” to at least one of those questions. This means that if a new vulnerability was announced and listed in the National Vulnerability database and applications that were using that package were now open to exploitation, you would have no idea if any of the thousands of applications in use in your business were running vulnerable versions.
Businesses need to have verifiable insight into their software and the third party software that is in use within their organisations.
Software Supply Chain Attacks
As organisations continuously improve their overall cyber security posture, hackers are circumventing traditional security defences and looking for the path of least resistance and of maximum reward. Software supply chains are rapidly becoming the hacker’s attack of choice. In Sonatype’s seventh annual “State of the Software Supply Chain” it concludes that in 2021 the world witnessed a 650% increase in software supply chain attacks. These attacks can be relatively simple: corrupting a vendor’s patch site to contain malware; or far more complex: the malicious actor infiltrating a software company’s codebase to insert malware before the code is compiled and released. In the media we have seen an ongoing series of attacks on the supply chain – Dependency Confusion, Kingslayer, ASUS and SolarWinds to name a few.
The current state of practice in the software supply chain security lacks systematic integrity. A comprehensive framework that covers the design, build and delivery process is very much needed and should be implemented by the software development community and the information technology ecosystem, to reduce the risk of compromise, exploitation, exfiltration, or sabotage from software supply chain attacks.
Software Bill of Materials
As someone who suffers from a severe nut allergy, it would be completely irresponsible of me to eat a cake without knowing every ingredient that went in to making it. The benefits of eating the cake without reading the ingredients, getting to enjoy all that sugary goodness immediately rather than having to waste time checking the ingredients, is outweighed by the risk that comes with taking that shortcut, i.e. anaphylaxis. Suddenly, not taking time to research the ingredients just doesn’t seem worth it, right? This is the exact same attitude that businesses need to take regarding the components they use in their applications. It is irresponsible to use multiple OSS components in multiple systems without knowing everything about each one, doing so leaves your organisation and your customers at risk.
So, what can we do to overcome this? The benefits of using OSS and third party software are tangible and numerous, but we must negate the risk that comes hand in hand with this.
No silver bullet ever exists, we know this, but a good first step in this instance is a standardised Software Bill of Materials (SBOM). This is effectively a nested inventory of software components that describes which components have known security vulnerabilities and architectural or license risks. It enables businesses to make quick decisions, identify exposure and to take appropriate steps in response to any new vulnerabilities that arise. Knowing what open source and third party components have been used in and are flowing through your software supply chains is the first crucial step in mitigating the potential risks.
In response to the increasing number of application breaches that are occurring, standards bodies and governments are beginning to place a greater importance on SBOMs. They are also introducing laws, bills, guides and requirements to assist and hold development organisations accountable for the quality and security of the code they assemble and build.
In April 2020, The National Institute of Standards and Technology (NIST) released new standards for improving software security and in April 2021 they released a paper “Defending Against Software Supply Chain Attacks” which looks to be formalisation of software supply chain standard starting to take shape. Similarly, in January 2019, new PCI secure development standards advised organisations to generate an SBOM to track and trace the location of every single component of their software. The UK’s National Cyber Security Centre has recognised that software development practices are becoming increasingly automated and reliant on open source and third party components and, in an effort to help development teams evaluate their OSS components and reduce security risk, provided eight useful questions that organisations should consider in their resent guidance Produce clean & maintainable code – NCSC.GOV.UK.
Furthermore, Gartner states that by 2024 the provision of a detailed, regularly updated software bill of materials by software vendors will be a non-negotiable requirement for at least half of enterprise software buyers. From a security perspective, it is vital to have an inventory of every component used in your software, so that as a business you can act quickly to identify if any of the applications are vulnerable to known hacks or come from dubious sources, in order to stay ahead of adversaries and competitors. Any time a vulnerability in OSS software components is announced, two questions need to be able to be answered rapidly: Did we ever use the vulnerable version(s) of the open source component? If so, in what applications do they reside?
OSS licences – what are the legal risks?
An OSS License allows the software to be freely used, modified and shared; it grants others permission to modify, use and distribute software under certain conditions. The OSS license is there to protect the software and allows the code to remain open sourced.
OSS components come with different licenses and a different set of terms, and if you are operating without a license or in breach of the terms of a license, you could be putting your organisation in jeopardy. You should always be aware of the terms of each individual licence. For example, some of the licences state that ‘If you use this open source and distribute it, you have to make the software publicly available’ or words to that effect. What does that mean for your company? Potentially, your company patents and trade secrets should now all be publicly available.
When we think about the sheer number of components in a software supply chain and, consequently, the number of accompanying licences, it is easy to see how issues can quickly arise if an organisation does not have insight into the types of licenses in use and the legal requirements associated with each of them.
Types of Licences
There are two main categories of licenses: Permissive or Liberal and Copyleft.
Permissive or Liberal licences essentially allow you to alter the code however you like, but you are using it at your own risk – there is no warranty – and you need to acknowledge the author(s). Examples of this type of license include MIT and Apache 2 licences.
On the other hand, Copyleft licenses have added requirements. These additional requirements include terms such as: if you distribute the binaries, you must make the source available; also, the source and derivative must be under the same copyleft terms. Examples of these types of licenses are Maozilla Public License (MPL), Affero GPL (AGPL), GPL and Lesser GPL (LGPL).
Learning from Past Experiences
Many well known organisations have fallen into the trap of licence misuse and have subsequently found themselves subject to legal action. Below are just a couple of examples of organisations that know all too well the consequences of violating open source licenses:
- Versata and XimpleWare – Versata Case: The Consequences of Violating Open Source Licenses
- Samsung and BusyBox – Best Buy, Samsung, other retails violated GNU General Public License version 2 (GPLv2)
Both of these used the GPL code mentioned above. Versata and Samsung all lost their court cases and were forced to release their code to the general public.
Handling an organisation’s open source security and dependencies can be a taxing and onerous job; staying compliant with OSS licenses, managing open source CVEs and keeping track of what dependency version is in use is time consuming. Often organisations leave security teams to manually manage the risk of vulnerable OSS code, or worse, sweep it under the rug with the classic ‘we don’t use open source so we don’t have a problem’…
Do not be one of those organisations!
Don’t risk eating the cake without checking the ingredients. Make sure that you are aware of every OSS component that has been used in your applications and where abouts they reside. Be informed and knowledgeable about the licenses and accompanying terms. It might take a little longer in the first instance, but then you can sit back, relax and enjoy your cake without risking putting you and your business into anaphylactic shock.
6 Steps to Securing your Software Development Lifecycle
I will leave you with 6 steps for securing your software development lifecycle which can be used as a checklist to perform due diligence on third party software development companies:
- Secure code development training – creating security champions in the development teams is an excellent investment.
- Give developers the tools they need to find and fix vulnerabilities earlier on in the software development lifecycle (SDLC). Security testing tools like SAST and SCA, when integrated into the SDLC, do not hinder creativity and speed but do allow vulnerabilities, both open source and from other sources, to be found and fixed quickly. This saves you time and money in the long run.
- Secure access for developers – choose a privileged access management solution that enables a frictionless experience. Organisations have more privileged users (e.g. engineers, DevOps or SREs) than ever before, many operating with elevated privileges over a remote connection.
- Have an open source software legal partner lined up that can advise you of your OSS legal obligations.
- Ensure that all applications have a SBOM.
- Implement penetration testing: enlist an experienced, qualified penetration testing company to perform an in depth assessment prior to release of any application, as well as at least once a year minimum and after any significant changes.
Sources list –