Amp up OSS security with these steps

Custom code often comprises less than 20% of an application, and the rest is open source. Antony Edwards, CTO of test automation vendor Eggplant, formerly called Testplant, sees little open source software security focus in enterprise software development practices. Instead, many businesses do code inspection and review of only their original code, and leave at least 80% of their products' code unsecured.

Most companies that use unsecured open source code in products have not suffered data breaches -- yet. Credit goes to the OSS project teams, which do a good job protecting code, Edwards said. He noted that secure code should be the first line of defense in OSS security. Enterprises that fail to take further steps might see their luck run out.

Edwards shares advice and insights on open source code security, in this Q&A with SearchSoftwareQuality.

Why do enterprises fail to respond to OSS patch notifications, the Equifax mistake that caused its data breach?

Antony Edwards: Every report I've ever seen says that the majority of data breaches could have been prevented by having a quick, reliable patching process. It's nothing fancy, just following the OWASP security vulnerabilities lists.

Unfortunately, this [patch management process] doesn't fit with the way a lot of companies run. They all like to be super agile, ad hoc and fast. So, having a boring, repeatable patching process isn't in most companies' DNA anymore.

One workaround for this problem is using managed servers. Amazon [Web Services], [Microsoft] Azure and other cloud-based managed servers are great at automated patching.

Which old-school OSS security practices and tools remain useful today?

Antony Edwards

Edwards: The number one best practice is using components that are widely used. The more used, the more hardened it'll be. The most secure OSS codebases are Linux and Apache. It's been a long time since someone found a real major exploit in the core of those projects. Steer clear of using really new OSS in critical components. It will have holes.

What two new OSS security hardening and test practices and tools are being used effectively?

Edwards: Machine learning is becoming a real force in security. With machine learning, the technology can be used to look at millions of lines of source code, learn from previous security issues and find the patterns in your source code that may be security holes. It's just not feasible for a human to work with that amount of data and find patterns.

With machine learning, the technology can be used to look at millions of lines of source code ... and find the patterns in your source code that may be security holes.

Continuous security testing is critical. The big problem is security testing is treated as a one-off. People create a new application or website, and they do a one-off penetration test or security scan. Then they let a hundred developers -- some of them just out of college -- make source code changes, but they don't recheck. I think that continuous testing is getting a lot more attention now.

Is inadequate OSS security documentation common in enterprises?

Edwards: It will be getting better because of the cost of breaches. OSS projects often give credit and status to people who contribute code. Maybe they need to put more emphasis on people who provide other value, such as security audits and documentation.

Do you find that DevOps teams have accurate inventories of software dependencies used by different applications? If not, what risks are they running?

Edwards: Good software is organized in layers of security. So, you have a trusted computing base, in which all the code is trusted. You then have an admin layer that can do a bit more.

When you don't manage your dependencies, you can find that code that is supposed to be 'untrusted' can indirectly or even directly cause highly secure code to do something. This is called rights amplification in the security world and is a key problem. It's amazing how quickly bad software design can allow what seems like harmless code to get superuser access.

To reduce the risk, you need to have very well-defined interfaces between security levels. You need to constantly review these with static analysis tools. Also, do not let quick hacks from bad developers into secure code.