Auditing and Compliance for Open Source Security

Nearly 35 years ago, Richard Stallman changed the developer world forever when he developed the GNU Project, an open source coding project. Stallman and other developers radically altered the future of coding forever. However, some lingering questions about open source coding have gone unanswered for the past three decades.

Security remains one of the biggest ongoing concerns about open source coding. Some experts believe open source coding creates grave security threats, while others feel the concerns are overblown.

Regardless of the scope of the threat, security risks can destabilize an open source project if they aren’t addressed. Failing to address security vulnerabilities in your open source code can lead to lawsuits and regulatory compliance issues if you fail to take adequate measures to address them.

Compliance is particularly important for companies in the financial sector since regulatory penalties for those violations can be severe. Daniel Wesley, a financial services expert with nearly 15 years of experience, reports that identity theft is particularly common if customers use unencrypted sites, particularly those that rely on open source code.

The project coordinator needs to understand the risks and conduct regular audits to address them.

Lowdown on Open Source Security Threats

Since its inception, critics of open source development have stated that open source software is inherently less secure for a variety of reasons. One of the biggest concerns is that hackers can peek at the source code to identify vulnerabilities.

Dr. Ian Levy, an expert on cybersecurity for open source projects, has debunked this claim.

"Again that's nonsense. If I look at how people break software, they don't use the source code. If you look at all the bugs in closed source products, the people that find the bugs don't have the source, they have IDA Pro, it's out there and it's going to work on open and closed source binaries — get over it."

Nevertheless, Levy points out that there are some fundamental security concerns that can’t be overlooked. The biggest concern is the overreliance on patches to address open source security issues.

"Open source patches have to put out the source. They inherently disclose the underlying issue. So if I've got a security vulnerability in a product and I put a binary patch out, it's a chunk of work to reverse engineer it and work out what the underlying thing is. If it's open source, then I'm putting out a source patch and so I'm telling my attacker exactly what the problem is.”

Levy states that this isn’t necessarily an issue if the patches are structured to keep hackers from reverse-engineering the code. Unfortunately, many development projects neglect to take such precautions.

Leaders of open source projects must also consider the risk that their developers may introduce insecure or harmful code into the project. Whether this is done unwittingly or maliciously, it creates serious security risks that threaten the integrity of the project.

A third risk is that many open source projects contain vulnerable components. According to one study, 50% of Global 500 use these components, which can threaten the security of the project.

Project organizers must carefully audit the project to address any security risks with their open source code.

Auditing Tips for Open Source Projects

Open source project coordinators must follow these tips to maintain the security of their projects.

Use Appropriate Tools to Identify Open Source Dependencies

Most open source security flaws are embedded in the components that are integrated into the project. Many of these components are never screened, so the security flaws can go undetected for years.

Fortunately, there are a variety of tools that you can use to identify security risks. These include:

• Source Clear
• Node Security Project (NSP)
• Bundler-audit
• Snyk

These tools should be used to evaluate any components used in an open source project.

Monitor the National Vulnerability Database

The Department of Homeland Security developed the National Vulnerability Database (NVP) in 2005. This database contains tens of thousands of known security vulnerabilities. It’s important to compare code against entries in the NVP to identify known security risks.

Take Immediate Action if Vulnerabilities Are Discovered

The longer security vulnerabilities linger, the greater the threat to your project. Mahshad Koohgoli, CEO of Protecode, warns that they must be promptly addressed.

“Security vulnerabilities are bound to occur, in both open source and propriety software. With the use of open source code on the rise, it is imperative to have a process in place to manage any potential vulnerabilities. An open source security vulnerability audit gives an organization full visibility into its codebase and allows them to take action immediately should a vulnerability be discovered.”