#DevSecOps #SecDevOps #OpsSe.. you get it.
InfoSec has a knack for transient buzzwords that imply the problem while teeing-up the solution. The prefix “NextGen” does this beautifully- ‘the legacy method is obsolete; this new thing is better.’
‘SecDevOps’ is a mouthful for a reason. It assumes the gap between Security and Development is well known, making the mashup a bit of a metaphor. To repair the relationship we need more than a bridge, a compromise, (or a comma), we need to blur the lines between each. We need shared goals and accountabilities. So does what we call it matter? Yes, but soon it won’t. Why? Well has the love of your life ever told you that labels don’t matter if you truly care about each other? Yea he was lying to you, but this is sort of like that. Once we get it right, we won’t need the name.
The status quo
97% of organizations plan to add more security initiatives into their development lifecycles this year, but 58% of Dev teams say Security slows them down. This might sound discouraging to you, but I don’t think it’s very surprising, and not entirely unwarranted. That’s because this isn’t a measure of willingness, it’s a measure of reality. Many Dev teams are staring down the barrel of the status quo, and at its worst it might look like this:
Development prioritizes rapid code release.
⬇️
Security periodically assesses and passes all identified vulnerabilities back to Dev for analysis and resolution.
⬇️
Dev assesses workload to resolve against other priorities, patches point in time issue.
⬇️
Security identifies similar vulnerability in different code base.
Now this relationship might seem perfectly fine- plenty of handover back and forth. But is that really the most efficient way to work? Think about a time you started in a new office, and began working with a business unit outside your own. Was it difficult to get on the same page? What would have helped you understand, and eventually anticipate their needs a little better? Organizations that follow the above flow lack a clear framework for integrating security best practices throughout the development lifecycle- it’s perpetually reactive, for both sides. Not only does this pattern result in persistently inflated work loads for each group, the risk of exploit as things sit in various queues increases by the second. In other words, once we can improve (or theoretically replace) the operational ‘handover’, we may solve this problem entirely. For now, the gap, and its impact on timelines persists.
The Problem: Misalignment
To build the solution we have to start at the bottom. What’s causing the chasm? Is it…
A) Dev doesn’t care about secure code
B) Dev doesn’t get along with the security team
C) Dev is on Android while Security is on iOS so they avoid chat for fear of the dreaded green text (Same).
Answer? C! (Metaphorically speaking)
Security and Development teams speak different languages: Builder and Breaker. At its simplest, they have different priorities and different ways of accomplishing them. As above, the problem is less about a willingness to collaborate as much as it is knowing how to do so without sacrificing the things each cares most about. If the goal is more secure products in market faster, you need more than a shared vision, you need a shared foundation.
Solution: Make secure things easier, and insecure things, obvious.
Communication- A common language
Dev must release products quickly, and Security must ensure they’re safe- two reasonable objectives with relatively little overlap. Structured check-ins do well to track status and facilitate mutual understanding of expectations, but to reduce friction in these initial sessions, we need a common language. Both severity of a vulnerability and criticality of a release can be communicated in terms of risk and impact to the organization. Working towards the same logic, Security should triage, validate, and contextualize all issues before presentation to Development. These measures will reduce time spent debating priorities, but more is needed to continue the downward trend of ‘handover’ duration and frequency. We need to operationalize insights rather than just exchange information.
Automation- Find and Fix Faster
Operations (the business unit or initiative) is focused on promoting reliability and consistency between and within the security and development lifecycles. Automating certain elements of code creation by identifying and repeating useful patterns, is common practice for reducing development timelines and improving operational efficiency. Similarly, automating the the hunt and resolution of issues that share structure across different code bases, reduces workload for both Security and Development. The introduction of continuous testing methods also helps smooth submission volumes over time to prevent request spikes that sporadically drown Dev and jeopardize other initiatives. Each of these methods reduce time to react; but what can be done to avoid issues altogether?
Education- Build Better
As I used to say when single, #DateYourself (I prefer to think it was more a mantra of choice than circumstance… I digress). It was a reminder that working on yourself first eases how you work in a relationship. SecDevOps isn’t too dissimilar. While effective communication and strategic automation reduce friction and push Security and Development closer- if you’re really looking to achieve a unified goal without compromising individuals priorities, you have to start at the bottom. Educate Development teams on writing more secure code the first time. Inform Engineers on how to design, build, and implement according to evolving security requirements. Arm Security teams with remediation advice for submitted vulnerabilities to ease time for Dev to resolve. Without continual education, Development will ultimately always be reactive to, and yes, slowed by, Security.
Common and clearly understood foundations help build shared goals, lessening the time and effort each side might stand to lose in any compromise. If both Security and Development understand and implement initiatives in their respective team that recognize the needs, constraints, and goals of the other, the two can fix faster and build better, together.
Good relationships compromise, great relationships don’t have to.
