How DevSecOps done right makes application security easier

by Taylor Armerding on August 5, 2020

How do you integrate application security into DevOps? By enabling your developers to address security issues with automation, integration, and training.

Software security is hard. If it were easy, everybody would be doing it, and doing it well. But as we see daily, that is not the case. Cyber intrusions and data breaches, many enabled by insecure software, are a regular part of online life.

The 2020 Verizon Data Breach Investigations Report (DBIR), out May 19, tracked 3,950 data breaches in 2019, an average of about 11 per day. But that data came from just 74 participating companies. The total is certainly twice that or more.

So if anything could make software security easier—even incrementally easier—you might think everybody in the business of building software would jump on it. But that’s not the case either.

Sponsorships Available

Even though DevOps can indeed make it easier to build in application security. Even though it has been around as a concept for many years, its value preached at keynotes and in workshops at security conferences.

Even though it was described as a “new wave of engineering culture” in the 10^th annual Building Security In Maturity Model report last October.

Why security is still missing from DevOps

With all that, many organizations still have trouble integrating application security into the DevOps process. Why else would the most recent RSA Conference have devoted half a day to helping security professionals figure out how to do it better?

Largely because it can be tricky. There is still a disconnect between development and security teams that ranges from misunderstanding to outright resentment.

As multiple RSA speakers noted, developers hate having to stop what they’re doing, open something they were doing a week ago, and fix a bunch of bugs or defects the security team just found and sent them. They see it as a hurdle, blocking them from getting their job done. They, understandably, resent it. It makes them resent the entire security team.

So one of the key messages at the conference was to “simplify” security and for security teams to work on “developer empathy.”

Christopher J. Romeo, CEO of Security Journey, said one of the main things he wished security people knew about developers is that process complexity is their enemy, and simplicity is a friend that is likely to help them view security teams as friends, or at least collaborators.

Or as we’ve been hearing for years now, “make the secure way the easier way.”

How to make security easier and faster with DevOps

Organizations clearly need to make the secure way both easier and faster. But how to do it? That’s where better use of technology can demonstrate empathy. According to Gartner in its December 2019 research, 12 Things to Get Right for Successful DevSecOps, one of the top “things” to get right is to “adapt your security testing tools to the developers, not the other way around.”

One fundamental goal of software development is speed. And one of the ways to help developers maintain their speed is to “build security in” during the entire software development life cycle (SDLC). As the Gartner report points out, “Less well-understood, but crucial to DevOps and application security, is the principle of providing feedback to developers at an equal pace, and as early in the process as possible.”

Rely on automation and integration

One change recommended by the report: “Never making developers leave their native toolchain environment. This means integrating testing—ideally on a near-real-time basis—with integrated development environment (IDE) and CI/CD toolchain tools.”

You can help your developers by relying on integrated, automated testing (key to DevOps) to help them find and fix application security defects while they are coding, almost like a spellcheck. Doing this is both faster and easier than the alternative: forcing them to fix a long list of issues that the security team dumps on them later.

But remember that “automation” is not equivalent to “autonomous.” Producing secure software still requires multiple kinds of testing throughout the SDLC, including static and dynamic analysis and software composition analysis. It also requires manual efforts to review, triage, and remediate. Even in DevOps, automation doesn’t eliminate responsibility for application security. Instead, it helps developers assume that responsibility.

Redefine the ‘Sec’ in DevSecOps

Empowering developers to take responsibility for security is not a new message. In fact, for DevOps to succeed, application security testing shouldn’t require the involvement of the security team.

At RSA, Romeo called for simplifying “methodology, language and framework choices and provide adequate security guidance.” He even went so far as to declare that the “Sec” in DevSecOps should be “silent.” That, he said, would also simplify the development process.

“You cannot have true DevOps without security being integrated, which is where it needs to be. It’s all about building security in,” he said. “Don’t make it a separate thing.”

The Gartner report notes that this change is required: “Designing security scanning so information security professionals are not needed to scan applications. The need for information security assistance should be a rare exception. Where possible, everything should be automated and transparent to the developer.”

Boost developers’ security knowledge

Giving developers responsibility for application security within DevOps does, of course, require a measure of skill, which leads to another of Gartner’s 12 Things: “Train all developers on the basics of secure coding, but don’t expect them to become security experts.”

Not all training needs to be as rigorous, said the Gartner report: “Developers get the most, testers get nearly the same and product owners will get less.”

“However,” the report continued, “you can train all developers in the basics of secure coding, and the ways applications can be attacked.” The report recommends these topics, among others:

How to build and maintain simple threat-modeling scenarios (i.e., thinking like a bad guy)
Input whitelisting, filtering and sanitization for user input and files
Injection
Broken authentication and session management
Security misconfiguration of applications, OSs and container environments
Foundational security hygiene

As noted, this training won’t make developers into security experts. But it will give them enough expertise to allow the security team members to function more as SMEs and consultants, available to do things like interpret automated tool results, without upending the workflow with a pile of changes at the end of the SDLC.

It also gives the development and security teams a much better chance to, as one RSA panel said, “work together rather than hating each other.”

Indeed, the development and security teams are on the same team. In football, there are offensive, defensive, and special teams units, but they all share a common goal—win the game.

If done well, that is what you can accomplish by integrating application security into DevOps: Everybody wins the game.