Security

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

Although Log4j has been fixed, the original flaw could have allowed malware inside a system.

Tanya Candia is an international management expert, specializing for more than 25 years in information security strategy and communication for public- and private-sector organizations.

Open-source code is everywhere. It is the underpinning of hundreds of commercial products used in government, the private sector and by individual citizens.

Over the years, from the early days of Unix to today, the term has taken on a deeper meaning. It’s more than its legal definition as “commercial software for which the human-readable source code is available for use, study, reuse, modification, enhancement and redistribution by the users of that code.”

It’s become a philosophy that embraces the open exchange of code, collaboration and transparency, with a large community of users available to test and vet the code.

Gartner reports that the actual proprietary code a developer writes is generally less than 10 percent of the final application, with the rest made up of open-source components freely available from public sources and repositories such as GitHub.

Developers depend on open-source components, libraries, containers and frameworks to provide them with useful features that they would otherwise have to write on their own.

Click the banner below to get access to customized cybersecurity content by becoming an Insider.

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.

4,500

The number of vendors and products that employ Log4j

Source: github.com, “CISA Log4j (CVE-2021-44228) Affected Vendor & Software List,” March 29, 2022

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?

CISA Best Security Vulnerability Practices

If your agency has not taken measures to fix the Log4j vulnerability, the Cybersecurity and Infrastructure Security Agency recommends the following:

Identify all internet-facing assets that use Log4j Java library anywhere in the stack.
Locate all assets that use the Log4j library.
Update or isolate affected assets.
Monitor for odd traffic patterns.

SDI Productions/Getty Images