Despite Patches, Continue to Monitor Open-Source Code and Software for Vulnerabilities

Is Open Source More Secure Than Proprietary?

Many people believe that open source is more secure than proprietary software. This is because open-source components can be reviewed by a vast number of independent users, and the philosophy of collaboration and transparency should inevitably lead to more secure code.

In reality, some very important code is barely reviewed at all. For example, the Apache Log4j open-source code that put hundreds of millions of devices at risk due to a remote code execution vulnerability was reviewed by only a handful of volunteers.

In fact, open-source code often has critical vulnerabilities, causing concern for the many agencies that build or rely on products using open source.

There are big differences between in-house code and open-source code. When your developers write code in-house, they follow your rules; logic is planned and changes and fixes are standardized.

Open source, in contrast, is distributed among community members who write and maintain the projects. It often follows a looser set of rules, making it harder to evaluate the security of the code.

With open source, it is up to you to stay on top of all reported vulnerabilities. That means being alerted to new vulnerabilities in source code you incorporate in your own applications, as well as in source code contained in commercial products you use, and taking swift action to patch or update.

LEARN MORE: Learn how to better guard against threats and reduce risk and technical debt.

How to Best Monitor Open Source

There are three steps to keeping open source safe: knowing where it is used, finding which components have vulnerabilities, and quickly patching or updating.

The first is challenging, because many organizations don’t have a complete list of what is running on their systems. Additionally, vendors often fail to disclose that their commercial products use open source — and many commercial off-the-shelf products have vulnerabilities within their open-source components. A recent study showed that 85 percent of the browser, email, file-sharing, online meeting and messaging products evaluated had at least one critical vulnerability.

Once you determine which commercial products are running on your system, employ either an application security scanning and testing product, or a software composition analysis (SCA) tool such as Snyk or Sonatype Nexus to identify open-source components. Once critical vulnerabilities are found, most can be fixed with a revision or a patch.

Developers are often under time pressure to deliver, so they may take open-source code from repositories without checking for any known vulnerabilities. Before downloading open-source software, check to see if there is evidence it has been developed securely and is maintained (recent commits and releases), and that it has a governance model and substantial number of users. Check to see if the open-source project has earned an OpenSSF Best Practices badge, which increases the likelihood that the software is developed and maintained securely.

Once integrated, document both direct dependencies (the libraries your code is calling) and transitive dependencies (the libraries to which your dependencies are linked). A component inventory and vulnerability checking tool can be an immense help here, so you will know where open source is used. 

Next, continuously monitor for vulnerabilities. This may mean reviewing changelogs and updates from the open-source projects, and/or making sure security administrators subscribe to critical projects’ security communications channels.

Here again, SCA can manage open-source components and track reported vulnerabilities. If you find a vulnerability in the dependency, be ready to update quickly with package managers and automated tests.

If hackers exploit a vulnerability, you will need to take remedial action. Get recommendations on version updating from your SCA product or use a vulnerability remediation management software solution to automate the entire process.

In some cases, you will need to remove files from running machines as well as your own source code files to prevent inclusion in future builds. In other cases, you will need to upgrade all relevant components, both in files and in running code.

Remember, the best defense is a good offense. Reduce the likelihood of compromise by keeping open-source components continuously patched. That way, you can fix vulnerabilities before hackers even know they exist.

EXPLORE: What is the difference between hashing and encryption for federal agencies?