Software and applications are essential to the functioning of our modern economy. Yet the vast majority of applications are riddled with security flaws that can be exploited by malicious actors, with potentially disastrous consequences. An economy built on vulnerable software is like a house of cards. An attack on one weakness could topple the whole thing.
Consider the cyberattacks on the 2016 U.S. election that targeted vulnerabilities in voter information databases; or the global ransomware known as WannaCry, which exploited a vulnerability in unpatched systems to cripple thousands of businesses and institutions, including hospitals, banks, retailers and governments.
Both of these extreme cases could have been worse. The alleged nation-state attackers who hacked voter databases in the U.S., likely via a basic and preventable web application vulnerability known as SQL injection, could have deleted voter records and disrupted voting. And we dodged a bullet when it turned out that WannaCry had a built in kill-switch that prevented it from spreading even further. The next time, we might not be so lucky.
Sources of Software Insecurity
The root of this exposure lies in the way software applications are created, or more accurately, stitched together. To speed up the development process, developers mix together their own code with components borrowed from open source projects and third-party components purchased from vendors. Even if a developer is careful to use the most recent version of a component with no known vulnerabilities, new security defects are disclosed all the time, requiring regular updates. Complicating matters even further, organizations typically use hundreds of components across many applications, making it impossible to manually track which components are used and where.
Moreover, there’s a void in the security education and training of developers, whether they are learning to code in college or in specialized coding boot camps. According to a recent survey, just 24 percent of developers were required to complete cybersecurity courses as part of their university education. Generally, these institutions pass the security buck to students’ future employers, who haven’t done much better at educating developers in secure coding. As developers increasingly take on the responsibility of creating secure code, they will need better education and security tools.
“The expectation is that the fundamentals of security will be taught as part of a developer’s on-the-job training,” says Brian Wrozek, executive director at cybersecurity solutions provider Optiv. “The reality is that security training isn’t happening all that much on the job.”
The result of these factors is that flaws are inevitably introduced during development. And if they are not caught by code reviews or security testing, security flaws make it into production. According to a recent study, 83 percent of organizations have released code before testing or resolving security issues. What’s more, 77 percent of applications have at least one security vulnerability, according to application security company CA Veracode.
Issues with open source vulnerabilities are especially pervasive, as seen with the OpenSSL Heartbleed bug. More recently, a critical vulnerability in a popular Java library exposed enterprises to injection attacks on web servers. That bug was connected to several breaches in the aftermath of the vulnerability disclosure, including one of the largest breaches in history.
So how can we reduce risk? Several security experts say it is going to take significant changes to the way businesses create software. That means everyone, from developers and security teams, on up to executives and the board, needs to buy into more secure development practices.
Security as a Core Requirement
Under pressure to get to market first, development teams long ago began to adopt methodologies, such as Agile, that formalize processes for more frequent releases. More recently, the culture of DevOps (development and operations) has shifted more of the requirements for operational quality and performance “left” into development. However, these methodologies do not typically prioritize security.
That needs to change, says Chris Eng, VP of research at CA Veracode. Security should be treated as another requirement, like functionality, performance and cost.
“We need to think about the security we want and then clearly articulate the requirements,” Eng says. For example, formal policies could require applications to pass without SQL injection weaknesses, a common flaw that has been exploited to devastating effect in countless breaches, Eng says.
With built-in standards, security teams can create a gate that prevents applications from going into production unless they meet the policy, Eng says. These standards can also be used to measure the overall security posture of the organization – so everyone from developers to security teams, and up the ladder to the executive team, can be held accountable.
“Until every executive has at least one security metric in their quarterly performance review, there won’t be any incentive to make the right security decisions,” says Zulfikar Ramzan, chief technology officer at RSA.
The Promise of DevSecOps
Development teams won’t buy into security processes if they slow down releases. Security needs to become a seamless part of the lifespan of the DevOps process, rather than a last-minute test in pre-production that could halt the works. This is the idea behind DevSecOps.
“Striking the balance between securing your applications, and not slowing down the speed of your business more than you have to, is the role of DevSecOps,” says Optiv’s Wrozek.
This means developers and security professionals need to think about application security differently, Wrozek says. DevSecOps empowers developers to fully own security, and treat securing code as part of their functional requirements, freeing up the security team to focus on assurance and governance.
In a DevSecOps approach, development teams bring security into the earliest phases of development, where software flaws are the least expensive to fix, and continuously test throughout the development lifecycle.
“In order to make DevSecOps a reality, we need to automate as much security as we possibly can, so that it is fully integrated with the rest of the DevOps process,” says Chris Wysopal, chief technology officer at CA Veracode.
Developers must also embrace the idea of security as part of their job. Engineers who know how to write secure software are in high demand, but these so-called full spectrum engineers are incredibly difficult to find. Instead of looking for an all-in-one hire, Wysopal says development managers would do well to offer training programs and eLearning courses, teaching the talented developers they already employ how to code securely.
Wysopal suggests development managers designate security champions – developers with security interest and aptitude – on each team. Security champions elevate the skills of the whole team, coaching developers through code reviews, and ensuring security requirements are set early in the development process. These champions can also help smash the stigma that attention to security in the DevOps process will slow things down.
Organizations also need to enable developers with security tools that integrate into the IDE and build environments they are already using. There’s evidence that training and early testing produces results. According to CA Veracode research, developers who use eLearning have an average 19 percent better flaw fix rate; and applications scanned early in the development process have a 48 percent better fix rate.
DevSecOps isn’t yet widely adopted, but many organizations are recognizing the promise of DevSecOps to secure applications. One-third of IT and business leaders surveyed recently said their IT organization is very effective at integrating security early in the software development lifecycle. This is a hopeful sign of progress towards a more secure digital economy.
Yet, with so much on the line, more organizations need to get on board with the DevSecOps paradigm. Until security is embedded into the very DNA of software development, the risk is too great that the next code release will contain the vulnerability that brings the house of cards crashing down.