When it comes to securing open source, ‘visibility and transparency are vital’ writes Vivian Dufour, CEO of Meterian, and when a vulnerability is discovered, the ability to respond fast saves time, resource and reputations.
Recent high profile cyber security incidents have reinforced the importance of cleaning up the open source software supply chain. From Heartbleed to the Apache Software Foundation’s Log4j vulnerability, these highly publicised incidents have exposed the threats associated with the software supply chain.
Open source security vulnerabilities are nothing new. Heartbleed was a security bug in the OpenSSL cryptography library that affected many systems. Similarly, Log4Shell is a severe vulnerability, however in the case of Log4j the number of affected systems could well run into potentially billions. Many cybersecurity experts have characterised Log4Shell as the single biggest, most critical vulnerability of the last decade.
How do we ensure source code, build, and distribution integrity to achieve effective open source security management?
Open source under the microscope
Technology companies have been using open source for years as it speeds up innovation and time to market. Indeed, most major software developments include open source software – including software used by the national security community.
Open source software brings unique value, but it also has unique security challenges. It is used extensively, however, the responsibility of ongoing security maintenance is carried out by a community of dedicated volunteers. These security incidents have demonstrated that the use of open source is so ubiquitous that no company can blindly continue in the mode of business as usual. Recent research showed that 73% of applications scanned have at least one vulnerability.
The known unknown
The concept of known knowns, known unknowns and unknown unknowns has been widely used as a risk assessment methodology. When it comes to cybersecurity and the voracity of threat actors to exploit vulnerabilities, it is a useful analogy.
Let’s take Apache Log4J as an example. Companies often create products by assembling open source and commercial software components. Almost all software will have some form of ability to journal activity and Log4j is a very common component used for this.
Java logger Log4j 2 – A zero-day vulnerability
On 9 December 2021, the zero-day vulnerability in the Java logger Log4j 2, known as Log4Shell, sent shockwaves across organisations as security teams scrambled to patch the flaw. If left unfixed, attackers can break into systems, steal passwords and logins, extract data, and infect networks with malicious software causing untold damage, not least to brand reputations.
However, herein lies the problem. How do you quickly patch what you don’t know you have?
Often in the race to innovate, the first thing sacrificed is documentation. Without it how does a company know if Log4J is integrated within its application estate, let alone know if it has been previously patched.
Improving safety and trust when speed is of the essence
If we are to increase safety and trust in software, we must improve transparency and visibility across the entire software supply chain. Companies should have the ability to automatically identify open source components in order to monitor and manage security risks from publicly disclosed vulnerabilities. A software bill of materials (SBOM) should be a minimum for any project or development. Without such visibility of all component parts, security teams cannot manage risk and will be unaware, and potentially exposed, to dangers lurking in their software.
Innovating securely
As organisations continue to innovate at pace in order to reduce time to market, the reliance on open source software continues to increase. However, when the security of a widely-used open source component or application is compromised, every company, every country, and every community is impacted.
Organisations can and should take advantage of the many benefits that open source software can deliver, but they must not do so blindly. Ensuring you know the exact make-up of your technology stack including all the component parts is an important first step. Choosing discovery tools that have the widest comprehensive coverage is important, and so too is the flexibility to grade alerts so that only the most pressing threats are highlighted. This avoids ‘alert fatigue’ and enables security teams to focus resources where it matters most, putting organisations in a good position to act fast when vulnerabilities are discovered.
Hackers faced with stronger security defences will continue to turn their attention to the weaker underbelly of the software supply chain. Now is the time for organisations to implement integrated and automated tooling to gain comprehensive risk control of components in their open-source software supply chain. Only by increasing visibility, coverage of known unknowns and transparency can companies stay one step ahead.
