Application Architecture Summit

Modern Application Development for Digital Business Success

REGISTER

Online Conference

Like it or not, there’s always been some animosity between the engineering and security teams. Not open hostilities, mind you, but more like a cold war where two groups with competing goals engage in subtle tactics and subterfuge against each other to accomplish their mission.

On one hand, the development team wants to build and iterate as fast as possible based on immediate feedback from users, customers and the market. Security is often left out of the loop, a forgotten check on pushing out code as fast as possible.

 

On the other hand, the security team’s mission is mitigating risks to the organization—and may use its power to slow development until the proper checks can be implemented. The perception is that security may have good intentions, but it can be a real roadblock to development agility and innovation.

The Covid-19 global pandemic has only exacerbated this disconnect.

Work-from-home mandates have pushed everyone away from the office where the separation of engineering and security has only widened. Employees are more distributed, remote and more mobile than ever before. The tools and processes they use are more siloed. And new workflows are causing disruptions—adding cost and complexity while slowing time to market. Additional roadblocks—such as a penetration test—can be perceived as making a bad situation worse.

It doesn’t have to be this way.

Disruptions caused by Covid-19 are an opportunity to change the dynamic. In our case, we built a DevSecOps culture that integrates security seamlessly throughout the software lifecycle at the speed developers, the market and users expect.

Building a DevSecOps Culture in the Time of Covid… and Beyond

At Code42, we created a new team within the security organization called Product and Application Lifecycle Security—PALS for short.

A brainchild of some of my most trusted security experts, members of PALS have expertise up and down the stack—from networking and application access to compliance and architecture. They are embedded directly with the engineering team, participate in standups and help with scrum planning and execution. We’ve also set up a dedicated Slack channel and email alias where developers can get immediate feedback and input from the security team as they code. The result is that developers feel comfortable and confident when asking the security team for guidance at any time in the development lifecycle.

Resource allocation is a good example of how PALS has been able to work within existing engineering workflows to streamline development while hardening our security posture. Spinning up a server or cloud instance takes a single line of code in most cases and is often done at the drop of a hat without any security consideration whatsoever. Often, this results in a resource being exposed publicly, putting the organization at risk.

In the past, the security team would catch this after the fact—most likely during penetration testing—requiring the developer to go back in and implement the correct security controls. It was an extra step that annoyed the engineer and slowed development.

Today, the development team has access to a library of images that are pre-loaded with the appropriate policies and can be applied in a matter of seconds. If there are any questions, issues or exceptions, the developer can jump on Slack and get an immediate response. This allows the engineering team to spin up any resource with the appropriate security controls in place without slowing development.

PALS has also greatly reduced penetration testing as a whole. Developers hate what they deem an unnecessary process that takes their “perfect” code, puts it through the security ringer where it’s torn apart and watered down. I get that. But if security isn’t addressed during every development stage, penetration testing is the only way the security team can identify and mitigate risks.

PALS has been so successful at implementing security throughout the entire lifecycle and has created a more intense, personal and immediate feedback loop that it’s rare that penetration testing catches anything at all – it’s already been addressed. We still run the tests, of course, but I’m hard pressed to remember a time when we found anything significant that forced a developer to go back and rewrite code because of an exposed resource. Issues are closed before they’ve been opened because engineering and security code side by side.

Security at the Speed of DevOps

Addressing these issues has made our engineering team more productive—despite the Covid-19 disruptions. Our sprints are more focused on customer value than on readdressing security issues. We’re pushing more code, and our velocity is up. Just as importantly, we’re creating better, more secure code that doesn’t put the organization at risk.

Covid-19 has disrupted everyone’s world, but it’s important to take the opportunity to correct legacy processes bogged down by roadblocks and animosity. Code42 has done that.

At Code42, our security and engineering teams work side by side (virtually of course), advising each other on building powerful products that customers want and need. Animosity has been replaced by mutual respect, and close collaboration is the norm. When this is all done and over, I wouldn’t be surprised to see a joint engineering and security softball team come out of this. One team, one mission.

It’s the DevSecOps way.

Rob Juncker is CTO of Code42, the leader in insider risk detection and response.