Software Integrity Blog

 

Tanya Janca at RSA on better AppSec: Play nice with DevOps

The DevOps / security relationship is often tense—but does it have to be? At RSA 2019, Tanya Janca explained how teams can play nice, and why they ought to.

Tanya Janca on the DevOps / security relationship at RSA 2019

Play nice. Communicate. Cooperate.

If you really want to make the “Sec” part of DevSecOps work effectively, those “soft” interpersonal skills are just as important as tech skills, Tanya Janca told an audience at RSA Conference on Wednesday.

Janca, senior cloud developer advocate for Microsoft, has a resume that includes application security evangelist, trainer, public speaker, ethical hacker, OWASP (Open Web Application Security Project) Ottawa leader, OWASP DevSlop project leader, software developer, and mentor.

She has also been a guest on the Silver Bullet Security Podcast and featured in the past on this blog.

And in her presentation, titled Security Learns to Sprint: DevSecOps, she said a major reason that security isn’t part of the software development life cycle (SDLC) from start to finish is that development and security teams tend to view each other not just with suspicion, but sometimes with outright hostility.

Get the eBook How to Navigate the Intersection of DevOps and Security

The tension between DevOps and security

One of her first slides, illustrating how “some security people see DevOps,” showed a scowling member of a security team shoveling away the, uh, excrement of a DevOps unicorn.

Her vision, by contrast, was filled with puffy clouds and rainbows, with a smiling security team member giving the DevOps unicorn an apple and putting new horseshoes on it.

That, she said, symbolized a necessary component of reaching what ought to be a shared goal: “Change the way we make software so that the easiest way to do something is also the most secure way.”

Change the way we make software so that the easiest way to do something is also the most secure way.

Which is an obvious and desperate need. Janca cited, as have others, past Verizon Data Breach Investigations Reports (DBIR) that poor AppSec enables 29%–40% of breaches. And she noted, as have others, an obvious reason: Security teams are vastly outnumbered. She said the current average is 100 developers and 10 ops team members for every 1 team member in security.

How to improve the DevOps and security relationship

But even with those obstacles, she said, it is important to remember that if DevOps loses, that doesn’t mean security wins. “Security doesn’t win if the business doesn’t also win,” she said.

And given that the pace of DevOps is frequently a sprint, “we have to sprint along with them. We can’t be a bottleneck,” she said. “They can’t wait for us. And we have to make processes that actually work.”

Security doesn’t win if the business doesn’t also win.

Break security into smaller pieces

One way to do that, she said, is to break security into smaller pieces. “If you test for just one bug class, it will tear through that code so much faster, and you can eliminate a bug class.”

She also recommended tuning static analysis (SAST) and dynamic analysis (DAST) tools and reusing code that is known to be good.

And she said she has created a parallel security pipeline for more in-depth testing. While it’s more time-consuming, it doesn’t interrupt developers. “Then you have annoyed no one,” she said.

Build security in throughout the SDLC

And, as the Synopsys Software Integrity Group has been saying for a long time, the way to make applications secure is to “build security in” during the entire SDLC—to “make it possible for Dev and Ops to perform security as part of their daily work,” she said.

Not only does it make security testing faster—it makes it vastly cheaper. She cited estimates from Ponemon Institute research that found the cost of fixing a quality or security defect during coding costs about $80. It rises to $240 during the build, $960 during the QA and security phase, and a staggering $7,600 during production.

So, for the security team, that means “pushing left,” or providing feedback earlier and more often.

Invite Dev and Ops to participate in security

Never forget that your focus is to enable Dev and Ops to get their jobs done, securely.
That doesn’t mean relaxing standards to keep things moving. Janca said, multiple times, that security teams should “insist that the build breaks if a large security vulnerability is found. Security is part of quality,” she said.

But, she added, issues like that will be less likely if Dev and Ops are invited to participate in security activities—activities like threat modeling, incident simulations, and security sprints. She even recommended that the security side offer security training to Dev and Ops—and pay for it.

“We want to make sure they know what to do for things like that,” she said. “We need them. We can’t work in isolation.”

Which is where those relationship skills come into play. Janca called for “blameless” postmortems, lunch-and-learns, white papers, formal training, job shadowing, celebrating “security wins,” and creating Security Champions.

“Never forget that your focus is to enable Dev and Ops to get their jobs done, securely,” she said.

Get the eBook How to Navigate the Intersection of DevOps and Security

 

More by this author