When it was announced on June 8 that OpenSSL was vulnerable to a dangerous new attack that could reveal security certificates to an attacker, the Internet spent a few days in panic mode. Thousands, if not millions, of sites used (and still use) OpenSSL, and the fix for the problem took a few days to arrive.
The OpenSSL team became subject to all manner of suggestions and offers for help, from sources such as the OpenBSD team and from security companies. In the end, the OpenSSL core team expanded, and at least two separate organizations began full-scale security audits of the project. The OpenBSD team even decided to fork and rebuild OpenSSL themselves.
While the entire Heartbleed affair was complex, dangerous, and required both admins and developers to put out a lot of fires, the incident does cast a harsh light on the current state of software development, and upon the fact that so many teams rely on the security and integrity of software they did not write.
There have been many solutions offered from experts and vendors alike, but the most common and traditional security practices in software just might not be enough anymore. Static analysis, for example, failed to detect the bug in OpenSSL, primarily due to the complexity of the code that caused the vulnerability. In many ways, technical debt is just another form of security risk.
Zack Samocha, senior director of product at Coverity, said that his company did not detect the Heartbleed bug because it was such a strange case, hidden in such complex code. But, he added, Coverity 7.5, which arrived in July, is now able to find such security issues when doing static analysis of code. He said that Heartbleed brought a lot of new customers to Coverity.
“We got a lot of questions from our customer base,” said Samocha. “We had a huge amount of growth in Coverity Scan. Heartbleed made many customers very concerned about the supply chain of open source, not just the functionality, but also the security. It doesn’t matter if the code you provide to your customer comes from open source: It’s your product out there. To be able to solve security issues, it’s not just enough to have a security team; you really have to make sure security is a part of every developer’s workflow. We can really help with that.”
Samocha said that security is about being proactive, not just defending the network and reacting to threats. “All of those things are after the fact. They have their issues and they’re not really scalable,” he said. “We believe if you really want to get the security working well, it has to be part of the development workflow. That means if I’m a developer coding my tool, I’m going to scan my code and find the issues even before it’s checked in.”
But adding security to the workflow isn’t the way most IT organizations work. Instead, IT organizations with security teams often rely on auditing to ensure their systems are secure. “If you look into the market, the majority of the market is still doing auditing,” said Samocha.