Strong Security Doesn’t Have to Equate to Slow Development – InApps 2022

The tug-of-war between security teams and developers has long been a cause of friction within organizations. Developers thrive on innovation — moving fast, experimenting and rebuilding — while security professionals are pragmatic, risk-averse and are often misrepresented as “policing” company activity. This scenario causes unique challenges for any organization, but particularly for a SaaS company that builds and deploys security solutions.

This challenge is not an insurmountable one. At Code42, we created an integrated security and developer culture that allows us to build software at the speed customers and developers expect while also integrating security at every step of the software development process. It’s made a big difference in how our DevOps and SecOps teams work together and would be a helpful structure for other technology companies to implement as well.

Why DevOps and SecOps Teams Are Often at Odds

For anyone who follows the security space, you know the industry moves at an accelerated pace. After all, the goal of any security company is to stay one step ahead of emerging threats so time and precision is paramount. As a result, development teams within security organizations are in a unique and challenging position. Customers who reach out with a problem may oftentimes be in crisis mode or are trying to move as quickly as possible to address a potential risk to the organization. The ability for the development team to quickly respond and address an issue is key to customer satisfaction.

Unfortunately, this pace of work contradicts most security teams’ best practices. Code42 is an insider risk management company; as a security organization, it’s not in the cards for us to overlook these best practices and fix security flaws later once a new application is deployed or customer issue is addressed. Unsurprisingly, this often causes frustration between the two parties with developers wanting to move quickly and security teams requiring adjustments to be made before a new source of code or application is deployed. The root of this frustration is often a lack of understanding between the two teams — developers aren’t fully versed in security protocols while security professionals rarely understand the pressures imposed on development teams.

Before the pandemic, in most cases, these frustrations were solved through cross-office collaboration. But as with most organizations, that luxury was eliminated once COVID-19 swept across the world in March of 2020. Transitioning to work-from-home settings has only exacerbated this issue. While development and security teams often work in silos, these gaps were only as big as the office itself. Now, these silos expand between each home office and daily work has become less transparent. In addition, new workflows and pandemic-related security risks are causing disruption and slowing deployment while demands for teams to move faster have only increased.

Creating Greater Cohesion Between DevOps and SecOps

To uncover the disconnect between security and development teams, you often have to analyze the work being done day-in and day-out. For example, 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. Given the speed at which this task can be completed, it often feels counterintuitive to then go through the security team for penetration testing. When conducting this audit ourselves, we found that this extra round of testing ultimately required the developer to go back and add in the appropriate security controls. This is a frustrating experience for anyone who has a demanding schedule and can’t afford to waste time on seemingly easy tasks.

So what if we could just avoid this step altogether by providing developers with the right education and resources to implement security precautions early on in the development cycle, without requiring post-development security tests?

What came out of this experiment is a program we call Product and Application Lifecycle Security (PALS). The idea is to add security expertise up and down the stack — from networking and application access to compliance and architecture. To do this, we had members of our security team learn to code — not to the level of expertise of our developers — but enough to have the knowledge to create useful resources and provide trusted guidance. As a result, the PALS team is able to provide developers with easy-to-reference best practices such as a library of images that are pre-loaded with the appropriate policies and can be applied to code in a matter of seconds. If there are any questions, issues or exceptions, the developer can easily contact a member of the PALS team. This creates a level of confidence that the person they’ll be reaching is someone who speaks their language.

The result has been incredible. Our developers feel comfortable and confident when asking the security team for guidance at any time in the development lifecycle and our security team better understands the pressures faced by developers — all of which has ultimately eliminated the frustrations often felt between these two groups within the company.

How Adding Security Has Only Accelerated DevOps

As a cybersecurity company, the ability to have our security and development teams work in lockstep has been invaluable. The animosity between the teams has been replaced with support and understanding and as a result, we’re solving problems and deploying applications faster than before and without compromising security.

In a remote work environment where colleagues may seem further apart than ever before, adopting a DevSecOps culture — where the two teams work in tandem — has been a massive benefit. It has brought our team closer together and our customers are reaping the benefits.

List of Keywords users find our article on Google: