Open-source software has become an integral part of many organizations’ software development processes due to its cost-effectiveness and flexibility. However, a reliance on open-source can lead to security risks. In this blog post, we will explore the dangers of using outdated open-source software and ways to mitigate these risks.

One of the biggest benefits of open-source software is the ability to leverage the work of others for your own projects. This can save time and money, while also providing the flexibility to customize the software to meet your specific needs. However, the use of open-source software also brings with it the potential risk of using software components that may contain vulnerabilities. For instance, a vulnerability in the commonly used Java logging library, Log4j, forced thousands of developers to patch affected code after it was found that hackers had been actively exploiting it.

Repeat Offenders

Component exploits help attackers gain access to sensitive data and systems, which can have devastating consequences. For instance, the 2017 Equifax data breach was caused by an unpatched vulnerability in the open-source Apache Struts framework, which allowed attackers to gain access to the personal information of over 143 million people.  In 2020, Solarwinds suffered a near-fatal setback when it was discovered that attackers had inserted the so-called Sunburst malware into the software build, giving attackers broad access to thousands of customers’ entire networks.

It is not uncommon for malicious actors to subtly manipulate code packages. One effective attack is to change the stated version in the header while leaving known prior vulnerabilities in the package.  Unfortunately, the use of a simple Software Bill of Materials (SBOM) would not be sufficient to catch this technique.

What is needed is a ‘suspicious’ SBOM solution that scans the actual packages and categorizes them according to their true contents.

A ‘suspicious’ SBOM solution needs advanced scanning tools and machine learning algorithms that can detect anomalies in the software’s components. This way, it can identify components that have been modified, substituted or tampered with, providing a more accurate representation of the software’s reality. Also, this process can help in identifying any hidden dependencies that might not be listed in the software manifest or any potential vulnerabilities that might have been introduced through the use of outdated components. By doing so, we can ensure that software developers and users alike can trust the integrity of the SBOM, making it a valuable tool in promoting trustworthy software applications.

A ‘suspicious’ SBOM also needs a strong and trustworthy PKI to sign and validate its outputs. If you’re developing solutions for IoT devices for critical infrastructure, talk to us at SecureG about how you can have your own hosted PKI for certificates.