The Benefits of a Dev-First Security – InApps 2022

Snyk sponsored this post.

“Digital Transformation” is a buzzword for many but, in truth, it’s been a force of nature that has radically changed how businesses operate. It’s encouraged innovation and brought with it successful results across the board.

Yet, as entire organizations seek to reshape themselves in line with the latest digital transformation trends — software, cloud, or DevOps — security practices remain largely unchanged from the ones used two decades ago.

The need for security in a digitally transformed business is as strong as before — if not stronger. But while the rest of the organization changes to ship continuously through autonomous teams, security teams typically remain siloed and are often not consulted when decisions are made — which results in insecure applications.

Such uninformed security teams, therefore, force manual reviews and security gates, slowing things down when the business is looking to accelerate. None of this is helped by the decade of severe talent shortage in the security field, resulting in understaffed security teams.

This is not the path forward.

We need a new approach to continuous and integrated security. One where security is anchored into new technologies and methodologies and built from within. It needs to champion self-sufficient teams and accelerate the business, instead of slowing it down. In other words, it needs to be developer-first.

Taking Control with DevSecOps

This approach, often referred to as DevSecOps, requires a more collaborative approach to security — which brings with it more efficiency and encourages digital transformation, without the added security risks.

But how does it work in practice?

Ultimately, it requires both developers and security teams to work together and in turn both be responsible for security.

For developers, this means being thoughtful about security first and feeling empowered to take ownership of it. Whereas for security teams, it’s more about no longer seeing themselves as a controller but as a supportive function, tasked with enabling developers to find and solve security problems.

Empowering Developers to Make the Switch 

Empowering developers to fully embrace security requires a reset on how security currently operates. Essentially, instead of thinking top-down, security teams need to think bottom-up — it’s not about dictating steps to development, but rather about helping them make secure decisions themselves.

To do this effectively requires security teams to invest in building in empathy; taking the time to really put yourself in the shoes of developers and attempt to better understand their view of the world, before you start to impose yours.

To get developers to embrace a security solution, it must look like a developer tool, not a security one.

A key step in this empathy journey is understanding the difference in what you see when you “zoom out.” For instance, say you’re looking at known vulnerabilities in open source dependencies of a given app. For security staff, zooming out means looking at known vulnerabilities across all applications to better understand the risk. For developers, it means looking at all the defects of the same application — including functionality, operability and more — to better understand the quality of the app. This distinction in the big picture view requires rethinking how to present security flaws, placing them within an application context, not a risk context.

Another big distinction between the teams is what other tools they use look like. For security teams, neighboring tools are central in nature (they focus on risk and governance) and their goal is on finding and managing flaws. Developers, however, surround themselves with tools that are self-serve (that help them build and create, more than break) and that focus on fixing problems more than logging them. To get developers to embrace a security solution, it must look like a developer tool, not a security one.

Beyond the user experience, we must also acknowledge that developers do not have — and will never have — the same level of security expertise as the security team. Developers have a different full-time job, and security is one of the multiple responsibilities they bear. And so, dev-oriented security solutions must have built-in security expertise and guide developers towards a secure decision. The easier it is to make the right decision, the more secure the application will be.

Rethinking Security Teams 

All that said, this transformation requires more than tools and having developers step up. Security teams need to adapt too.

Within the organization, you should consider aligning your security group — which traditionally tends to mirror central IT — to the development teams. For instance, you can assign an AppSec person to several dev teams, allowing them to be better embedded in the teams and giving developers a clear partner to reach out too. The more aligned the orgs, the easier it is to collaborate.

Another introspection you should take is the skills in your team; and consider hiring or training to close any gaps. For example, security folks looking to build tools and have better dev empathy would benefit from knowing how to code. More importantly, building a supportive security team requires members who are excited to do so, and you may need to deal with those still wishing for dictatorial control.

Digital transformation is happening, whether you like the buzzword or not. The change it brings is real, and security practices have not evolved anywhere nearly as fast as development and operations. We need to do something about this. We need to transform security to be dev first.

To learn more tips and tricks about how to implement a developer-first security approach, join me this week (June 23-25) at the virtual DevOps Enterprise Summit London.

Feature image via Pixabay.

At this time, InApps does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: [email protected].