One of the worst-kept secrets in software development is just how often teams knowingly release products with bad code. A recent paper from Osterman Research found that 81% of development teams at large organizations have released an application with insecure code — and half do it frequently.
"After the last decade of increased cyber vulnerabilities, you'd think that security and development teams would have the same line of thinking," said Michael Sampson, senior analyst at Osterman Research. "They need to have a better relationship."
Many factors contribute to this disconnect, and failing to bridge the gap has consequences that extend beyond bad code.
That said, Sampson and other security experts point to several approaches that can introduce security earlier in the software development lifecycle, reducing friction while improving overall software quality.
Faster isn't always better
The main motivation for releasing insecure code is a need for speed. When engineering teams face pressure from sales, marketing and product teams to hit a release date, testing code decreases in importance, according to Justin Dolly, chief security officer at software testing firm Sauce Labs.
"There are competing interests, and it's a balancing act," he said. "Engineering may be lagging, and then they find things that just don't work, and then you add to that a security analysis to hit the quality metric for the code. It's a new priority — and there may be no room for it."
The availability of open-source code libraries and frameworks helps developers hit their deadlines, as it reduces the amount of code that needs to be written. However, this adds two critical security vulnerabilities: The security of the code itself, and the security of the dependencies among the software a developer is writing and the third-party libraries they are using.
Insecure dependencies introduce a new level of threat to the development lifecycle and it's one that can go undetected if it's not spotted early, according to Brian Fox, co-founder and CTO of Sonatype.
One example is a dependency that triggers in the development environment and steals production credentials. A typical scan may identify and fix the problem in the code, he said, but by then the damage is done.
"The way traditional application security practices are done, you scan before you ship to defend against shipping vulnerabilities," Fox said. "But that's late in the process, and it doesn't catch vulnerabilities in the development infrastructure. You have to pay attention to the whole process, not just the product."
A 'shift left' brings security into development sooner
The clear solution is to address security sooner in the development lifecycle — to "shift left," as Sampson put it. This means building security into the process during requirements analysis or planning, as opposed to waiting until development and testing have begun.
This can be a tall order, as it requires a shift in how developers work as well as how development teams are managed. Still, there are a few steps organizations can take.
Nigel Kersten, field CTO for Puppet, recommends applying the "as a service" mindset to the software development process itself. Using this approach, an organization assembles a team to create application programming interfaces for tasks such as version library checks, vulnerability scans and network tests.
By hosting these APIs on an internal platform, developers can access them as needed, and the organization has made the secure thing to do the easy thing to do, Kersten said. "The security team has a common point to come in and express a policy, and the development teams aren't bypassing the internal systems."
Kersten also pointed to the growing acceptance of the DevSecOps mentality. As the operational environment has shifted from physical infrastructure to software, development and operations have come together.
Puppet's ongoing research into the state of DevOps has found a correlation between the maturity of DevOps practices and the likelihood that security is baked into the software development lifecycle, according to Kersten.
"Removing friction and enabling collaboration for development and operations is key for security as well," he said. "Development outnumbers security, and the way to scale security is to put it in the hands of the developer with secure infrastructure and secure policies."
The DevSecOps approach also helps to shift the conversation from one solely focused on security to one that considers security in the larger context of quality, according to Dolly.
Bugs in software are inevitable and often unintentional, he said. The sooner that development teams can identify low-quality code, the more likely they are to address the issue during production and avoid releasing a vulnerability.
"Poor security is just one of the outcomes of the lack of quality in software," Dolly said. "Quality is something we've always cared about, but there's more to be done there. Increasing the level of quality across the board makes software more secure but also more usable."
