Ilkka Turunen, Field CTO at Sonatype shares his thoughts on how to master open source security risks.
Open source software is essential to innovation in the modern economy and powers nearly all of our digital infrastructure.
In fact, the impact of OSS is so high that if it were measured by economic value it would rank as the world’s 3rd largest economy on the planet.
Due to its ubiquitous adoption, software companies and developers must understand the risks associated with using OSS.
As we see the increasing number of social engineering takeovers and other risks affecting it, creating awareness on how this beneficial resource is best used helps you maximise what you get out of it.
Research has found that 96% of known-vulnerable open source downloads are avoidable, with poor consumption behaviours being the primary source of risk facing the organisation.
This has caused industry groups such as the Linux Foundation’s OpenSSF to call upon companies to have better practices to avoid known risk when using open source.
Unfortunately, managing open source based on just avoiding Common Vulnerabilities and Exposures (CVEs) is not enough.
To address these challenges, companies developing software need a more comprehensive approach to open source risk management.
This involves identifying, assessing and mitigating potential security, compliance and operational risks.
The following are the most vital risk areas to consider when designing an effective approach.
While many open source projects remain secure and active, over time surprisingly many fall out of maintenance, which leaves them vulnerable to exploitation.
It may come as no surprise that actively maintained projects have fewer known vulnerabilities, but according to research in any given year, nearly 20% of projects become abandoned.
Abandoned projects won’t address new vulnerabilities, which will increase the likelihood of any software leveraging these components being at risk.
Over time, unmaintained projects tend to accumulate more known risks.
Industry groups have been advocating for organisations to develop strategies to contribute back to the maintenance of the projects they leverage as an effective strategy to mitigate this risk as well as migrating to more maintained projects over time.
This is just half of the story though – Most vulnerability exploitation is done leveraging known vulnerabilities, such as Log4shell, which still has a patch adoption rate of just 66%. This is why it still ranks as one of the most routinely exploited vulnerabilities according to US authorities.
Open source comes with a range of licensing options, each with its own unique requirements and restrictions.
Unravelling the terms of the licences can be complex and time-consuming, but it can’t be overlooked.
The fine print matters as the usage terms can be permissive or restrictive by design.
For example, some may require you to simply by the author of the software a beer if met, whilst others require complete source code disclosure.
Failure to comply with these licences can lead to costly and lengthy legal troubles.
Malicious code With great popularity come new types of attacks.
The past decade has seen an explosive emergence of new types of malware, growing at an alarming annual rate of 742%, disguised as legitimate open source packages published in canonical repositories.
Their aim is to trick organisations into accidentally downloading them, backdooring their infrastructure in the process.
Robust risk mitigation is all about prioritising remediation.
It’s important to recognise that not all vulnerabilities pose an equal threat.
Having the means to address them based on their impact ensures effective safeguarding of your applications.
It should not cover software you build either – requiring similar practices from vendors of software you buy is a best practice.
Regularly assessing and updating open source within your applications results in a more secure software environment in two ways – by keeping your technology clean from decay – and by training your teams to apply fixes quickly when needed.
Having a Software Bill of Materials (SBOM) helps to understand how widely fixes need to be applied.
Generating these is the initial port of call.
Actively managing open source components is not solely about risk mitigation, it’s also about enhancing the quality of your software.
With the right tools and strategies in place, staying vigilant in your approach to open source risk management is proven to increase your software’s performance and resilience.
The entire open source community – from the maintainers that sustain projects to the developers that actively use and contribute to them – play a key role in effective risk management.
At its best, the open source community provides swift and coordinated responses to vulnerabilities if and when they are found.
Take the recent XZ compression library backdoor which was discovered within a week of attempted delivery.
A thousand eyes make all bugs shallow.
This collaborative spirit reduces the window of opportunity for any potential bad actors.
By investing in the maintenance of the projects you use, you increase your security and quality all at the same time.
The open source community stands as a massive repository of knowledge and expertise, use it.
With the support of the open source community, risk management ensures a safer and more resilient software environment for all who consume it.