Picture this.
You are a developer rock star on a team of similarly skilled, butt-kicking, zero-defect-writing coding ninjas. Your team has spent the past few months cranking out code, closing stories and epics, building next generation, awe-inspiring, industry-disruptive functionality for your business clients. You are days away from release and you hand your baby over to the security team for testing.
And BAM.
You get hit with a security assessment report 20, 30 pages long. Your app is riddled with security flaws. Your once beautiful, pure and perfect application lovechild has morphed into a screaming, fist-pounding, public-tantrum-throwing toddler in desperate need of a nap.
Commence the Kübler-Ross model’s Five Stages of Grief: Denial. Anger. Bargaining. Depression. Acceptance.
You now find yourself stuck between a rock and a hard place. Do you release your application on schedule with known security defects and risk your company’s security posture and reputation? Or do you patch, re-test, and release a hardened application, but past your initial promise date, increasing project costs and risk losing dollars for the business?
It’s not difficult to see why developers view InfoSec as a barrier to their objectives and project goals. It’s “us” versus “them,” the good guys against the bad guys. Indeed, InfoSec is regularly viewed as a stumbling block on the path to the promised land of project completion.
It should not be this way. It shouldn’t be “us versus them,” but “us, together.”
Let’s take a look at how this situation could have been avoided by examining the six things that developers want from their information security teams:
1. Empowerment
No, I don’t mean power as in direct access to the production database server—I mean that DevOps teams want to have the power to be great at security on their own. Security teams still need to be great at security, but developers don’t want the handholding and nagging that sometimes comes from well-meaning security folks.
To address this, security professionals can empower their DevOps teams in the following ways:
- Provide security training and give them opportunities to learn.
- Build a strong, welcoming security culture within your company that encourages forming relationships, asking questions and measuring with positive metrics.
- Give them ownership so that they want to reduce the number of security vulnerabilities and support the necessary remediations or mitigation strategies.
- Get out of their way—don’t micromanage them! Give them the tools they need to succeed and trust that they will do the right thing.
2. Tools & Integrations
Developers love tools and integrations, particularly if they are easy to use and work with their existing tech stack. Bonus points if the tool is open source or free! Developers, like anyone else, want as little hassle as possible when doing their job.
When DevOps teams need a new security tool, it presents the perfect opportunity for security teams to take their relationship with them to the next level by following these steps:
- Research tools and integrations available in the market, comparing total cost of ownership, major features, and other pros and cons for each.
- Put usability above all else—make sure your recommendations are easy to use and won’t add too much time to their build cycles.
3. Examples
Developers want lots and lots of examples! You need to show them what good code looks like, but beyond mirrored code snippets, consider providing:
- security unit tests,
- libraries,
- filters and regex patterns.
Nerd out with them! Beyond simply letting them build on top of what you’ve given them, you should encourage them to do so. Provide the base for their operations and index the information so that other developers can find and access it with ease.
4. Specificity
Be specific when giving a security requirement or addressing a security bug or vulnerability. Don’t leave them to dissect the meaning from overly-technical verbiage on their own—point out the package, the class, the method, the line of code and the vulnerability. Tell them what the specific risk is if the vulnerability remains unpatched, and don’t be afraid to share stories of what could happen or has happened in the past in similar instances to provide context for them.
5. Performing Their Own Security Assessments
I know, I know—this sounds like a counter-intuitive conflict of interest. But hear me out: developers want security to be seamless with whatever they’re doing, right? So built-in security is necessary for their development lifecycle.
Here are a couple ideas on how this can be done:
- Give developers security cheat sheets and checklists to help uncover any vulnerabilities as soon as possible.
- Auto-add security tasks to technical stories to help developers remember to do them.
If you’re in their world with them, in the same tools that they’re using and speaking the same language, that will really help close the divide between your teams and promote a shared understanding of exactly what you’re asking them to do.
6. Trust
We’re all professionals, and just like anyone else, developers want to be trusted. They know how to do their jobs, and you want to trust your developers to build security into their applications. Give them the space they need to do that!
Trust is built over time, so don’t rush it. Don’t be afraid to get into the weeds with asking specific questions from your DevOps teams and encourage them to do the same with the security team. Establishing that communicative environment will be beneficial for everyone in the long run.
Security is a service for the business—not a nagging in-law. Trusting DevOps teams to be great at security is an essential step in building that necessary relationship between developers and security teams.
Editor’s note: For further insights on this topic, watch Buckwalter’s full presentation on this subject here.
