The key to DevSecOps success: Cross-team knowledge sharing

What Security Teams Can Learn From Developers

Part of embracing DevSecOps requires relinquishing some amount of control. Security isn’t going anywhere anytime soon, but to fully embrace DevSecOps, they have to relinquish some amount of control. They have to rely on training and automation and trust that developers are capable of securing their own code.

A lot of the current DevSecOps narrative is focused on how developers need to take more security ownership or learn how to be better at security. While we do know we can always be improving, we also think security teams can make strides to be more collaborative and proactive. So let’s look at some tactical things security teams can take out of developers’ books to improve their own workflows.

1. Always Be Testing

Developers are always testing, going so far as doing test-driven development, where tests—such as unit and integration tests—are built-in before the first line of code is even typed. This is something security teams should get in the habit of doing to some extent to ensure application architecture is secure by design. At the design phase, security teams can ideate on new attack surfaces and incorporate the necessary testing to identify misconfigurations and vulnerabilities from the start.

2. If It’s Repeatable, It’s Automatable

The advantage of DevOps is increased speed and agility, meant to accelerate time to market. This is only accomplished by automating away the toil of manual operations tasks. The same goes for DevSecOps. Automating security testing at every stage of the development lifecycle is the only way to automate the manual task of finding common misconfigurations or known vulnerabilities. Automate the security testing from the previous learning into developer tools.

3. Leverage Open Source

Developers know there is no reason to reinvent the wheel: good code only needs to be written once. That’s why developers often look to incorporate open source components into their apps and services to fulfill basic requirements, so they can focus on building the new capabilities and functionality that differentiate their offerings. Security teams can do the same, implementing open source tools that have been vetted by the community and customizing it to their team’s specific needs.

If security teams can incorporate some of these developer traits and tap into the developer mindset, it will help them work more efficiently and better with their developer counterparts. Plus, security teams may be able to repay the favor and impart a few things that will help developers improve their workflows and outcomes.

What Developers Can Learn From Security Teams

This is not a post about how making developers into “security champions” is the only way to have secure code. It’s about recognizing the different working styles of engineering and security teams and identifying security engineers’ practices that could be useful to developers.

Here are a few security-centric skills and mantras that can help reduce friction between teams and benefit each mutually.

1. Ignorance Is Not Bliss

If you spend any time with security teams, you’ll know that visibility is the number one priority. Knowing your attack surface is more important than trying to fix everything. That way, teams can make a conscious decision about which risks they are willing to accept as necessary to enable the business. Like security, developers would be better served by getting visibility into all of the risks—including stability, cost, and security—as early and consistently as possible. That way, engineering can weigh the cost-benefit of ignoring or fixing these issues.

2. Prioritize the Low Hanging Fruit

Like developers, security teams enjoy hunting down and finding that advanced threat. However, they know that although it’s fun (and oftentimes terrifying) to find that super intense zero-day, the likelihood of being popped by a bot trying all the known misconfigurations and vulnerabilities is much higher than a nation-state with a targeted attack. Developers can follow a similar model, knocking out the low-hanging fruit bugs that are well documented, such as publicly available S3 buckets, and then worrying about the multi-dependency, undiscovered zero-day.

3. Defense in Depth

Going back to recommendation number one, Security teams are aware that not all bugs are patchable. Many times a new vulnerability, like Log4Shell, is easy to exploit but hard to patch everywhere. That’s when it pays to have a compensating control in place. Developers with known vulnerabilities can add additional protections like a WAF to their infrastructure as code templates that can block attempted exploits. This isn’t as good as patching the source, but it does buy time to do the patching right.

Conclusion

If developers and security teams work together and cross-pollinate, both organizations benefit. Security teams can help themselves by learning from developers to automate and scale their practices to maintain even better posture. And developers benefit from fewer blockers leading to higher velocity—without compromising security.