For those in software development, open source software(OSS) is not a new concept anymore. We use it in our day to day development activities whether we approve of it or not. In order to spin up a proof of concept swiftly or fix a high priority bug in a production software, we may end up relying on an external dependency. Instead of re inventing the wheel and wasting time and effort, everyone would agree that is the best choice. Time  and thus cost, are of major essence here.

But, are we doing enough assessments to make sure that the open source software package is safe to use in our software ? The vetting of software is considered less relevant compared to the value the use of open source software brings on the table. The result of omitting this step can have a devastating effect on the software. Eventually even causing the company to face litigation and fines.

The best example to site here is the Equifax data breach which occurred in 2017. In this attack, the personal information of millions of Americans were exposed. The origin of the breach was from a vulnerability in Apache Struts framework, that caused the cyber attack on the Equifax servers. In the aftermath of this data breach, the company faced numerous lawsuits. Hence, its of utmost importance that organizations adopt robust cybersecurity practices and promptly handle security vulnerabilities in their software.

This article aims to raise awareness about OSS dangers and investigate solutions for strengthening software security against them.

So, what is open source ?

An open source software is code that is readily available to use for the public. It can be modified and distributed for free. We are thus provided with the source code along with their binaries.

This is as opposed to the “proprietary software” where we are only provided with the binaries. Only the original authors legally and solely have the right to alter that software.

What is the open source dilemma ?

In most of the software that we build and use today, numerous dependency libraries are used under the hood. These are downloaded directly from the internet. Its easier to use them rather than building the same feature from the scratch which would be time consuming.

Now, so far so good… So what could go wrong here ? 

The library that you are using in your production software is downloaded directly from the internet. It is developed by some developer from another part of the world who may not be following similar coding guidelines as your team.  For instance, there may be code fragments that are insecure, in which case you are letting your software open to a web of malicious attackers. The impact of such libraries in your codebase can be catastrophic.

As pointed out by OWASP (Open Worldwide Application Security Project), the software industry still lacks a holistic approach to OSS risk management.

OWASP has therefore defined top 10 OSS security risks that development team needs to be aware of and mitigate, before using them in their software development process.

Below are the top 10 OSS security risks defined by OWASP:

• OSS-RISK-1 Known Vulnerabilities

Although, open source engineers are fantastic, they occasionally make mistakes that leave their code vulnerable to security flaws or external attacks.

• OSS-RISK-2 Compromise of Legitimate Package

Attackers can insert malicious code into legitimate packages, thereby compromising the entire software that is using it. E.g, this may be done through hijacking the accounts of legitimate project maintainers or exploiting vulnerabilities in package repositories.

• OSS-RISK-3 Name Confusion Attacks

As the name suggests, attackers create components whose names resemble names of legitimate open-source. This is called typo-squatting. They can suggest trustworthy authors which is termed as brand-jacking. They can even play with common naming patterns in different languages or ecosystems which is called combo-squatting. These packages may even work just like their legitimate counterparts but include backdoors that may go undetected

• OSS-RISK-4 Unmaintained Software

A developer may have created the open source software out of passion and during the free time. But this passion can wane out down the line, as the developer gets busy. The developer may then have limited time to spend on maintaining the software. This results in several outdated dependencies with serious security issues unresolved in the software.

• OSS-RISK-5 Outdated Software

Even though newer versions exists, we may still stick with an older version of package. This may be simply because we don’t want to put effort in fixing the breaking changes. But, the problem with this approach is that the maintainers may not be applying security patches and fixes on the older versions.

• OSS-RISK-6 Untracked Dependencies

There are many transitive dependencies that are used under the hood which the developers may not have knowledge about. These packages may have malicious code that can go undetected until we hit a snag in the production environment. It may be too late to rectify at that point.

• OSS-RISK-7 License Risk

One major issue that open source foundation is facing is that most of the open source repositories are unlicensed. In addition to this, these packages may not be adhering the open source licensing requirements. The absence of a license or non-compliant use can directly result in copyright or license infringements. This consequences of such a software may end in major financial and reputation losses.

• OSS-RISK-8 Immature Software

Not all open source software is a high quality software unfortunately. They may be lacking in security updates and adequate testing, documentation etc. Incorporating such code can also introduce security vulnerabilities in your code.

• OSS-RISK-9 Unapproved Change

If we use an unversioned package in our software, we are at a risk of unapproved changes done by an actor who has gained access to the code. The actor may have installed a backdoor in which case the person has unauthorised access and control into the system.

• OSS-RISK-10 Under/over-sized Dependency

Sometimes we need only a few lines of code and for that we do not require an entire open source code package. At other times, there are other packages and features that are added into the OSS package that we are forced to keep track. Uncontrolled feature creep increases the surface area of attack.

How can we mitigate the risks ?

Below are some of the ways we can mitigate the security risks when we use an open sources software in our application:

1. Use of SAST/DAST tools

It may not be possible for a human to review and test all the scenarios and isolate the vulnerability in the code. This is where SAST and DAST tools come to our rescue.

• SAST (Static Application Security Testing) searches for potential security vulnerability in the code itself without running it. 

• DAST (Dynamic Application Security Testing) analyses application by simulating automated attacks mimicking a malicious attacker.

By monitoring applications through the integration of these tools in the CI/CD pipeline, we can detect vulnerabilities earlier in the process.

These tools provide you with extensive reports with scores and metrics. An example would be CVSS (Common Vulnerability Scoring System) and EPSS(Exploit Prediction Scoring System).

CVSS is a numerical value of severity which are translated to various levels like CRITICAL, HIGH,MEDIUM, and LOW. EPSS tells you an estimate of the likelihood of an attack if the software goes into production. This helps mitigating any attack that may happen in production software.

Examples of such platforms that perform both SAST and DAST are Fortify, Checkmarx etc.

A typical Checkmarx report looks like below:

This image is sourced from Checkmarx documentation here

2. Use of SCA tools

As a developer, we may not be aware of all the OSS packages being used in the software. We may as well not be aware of its corresponding licensing regulations. SCA(Software composition analysis) tools helps us exactly with this aspect.

Most of the mainstream programming languages support package manager these days. The SCA tool inspects the package managers, source code, binaries etc and creates an SBOM(Software Bill of Materials). An SBOM lists all the dependencies used in the software along with its licenses, security patch status and so on. It then compares the list against the National Vulnerability Database(NVD) and produces a report identifying the critical vulnerabilities. With this report, we can then prioritise to fix before the software goes into production.

Examples of SCA tools are Blackduck, Sonatype’s Nexus Lifecycle etc.

A typical Blackduck SCA report looks like below:

This image is sourced from Blackduck documentation here

3. Promote DevSecOps

Integrate security earlier into the DevOps pipeline. Doing this ensures that security considerations are taken into account throughout the software development life cycle. These tasks needs to be run on a scheduled basis. Because imagine running this tool on your software once before production release .We will be swamped up with a lot of malicious packages identified just before the release. This can result in postponement of release which no stakeholders will be happy about.

Incorporating these kind of automated updates and scans of dependencies earlier in the process guarantees that we are keeping the software up to date and free from vulnerabilities.

4. Prioritize the security fixes

It is not only important to identify the security risks through scanning process, but at the same time, it is crucial to prioritize the security fixes to remove any malicious code present in the software.

5. Audit the release process

Auditing of release process done by the external person is one way to guarantee that the team has followed the all the security practices before allowing the release of the software into production

6. Use Trusted Sources

Use open source software from trusted repositories and make certain of the integrity of downloaded packages. Make sure that the code is very well maintained and supported by the open source community. This can be understood from their security patching schedules, well defined API documentations, standard testing practices etc. These are some of the ways you can check the package in advance prior to using it. 

7. Dependency Pinning

Pin dependencies to specific versions to prevent unexpected changes or vulnerabilities from being introduced through automatic updates.

8. Code Reviews

Performing thorough manual code reviews and test practices especially while using a new OSS package can greatly reduce the risk of using a vulnerable package

9. Team Training and Awareness

Educate and train developers on security best practices, including the risks and benefits of using OSS. 

Conclusion

From the recent SolarWinds and Log4Shell incidents, it is apparent that both malicious software updates (SolarWinds) and vulnerabilities in widely used libraries (Log4Shell) can significantly compromise application security and user privacy. 

Its extremely crucial that companies realize this aspect and make this a step in their software delivery life cycle. This way organizations can proactively identify and address security vulnerabilities, minimize risks, and ensure compliance with licensing requirements.

Building software is important, but even more crucial is keeping it secure.

Resources