A good DevSecOps strategy goes beyond having the right tools and processes in place: it requires consistent and crucially, bi-directional feedback and learning. Both security and engineering teams have such different priorities and strengths, but that doesn’t mean they don’t have anything to learn from each other. This year, make it a resolution to create a culture of bi-directional learning between these two teams and reap the benefit of improved collaboration. Here are the top things one can learn from the other to break down silos in the name of DevSecOps.
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.
Want to learn more about shift-left security? Read our DevSecGuide to Infrastructure as Code (IaC) Security and discover how you can leverage IaC and DevSecOps to secure your cloud.
This post originally appeared on DZone.