10x Your AppSec Program with this One Simple Trick
How’s that for a clickbait headline? 😜 But in all seriousness, there is one thing that I regularly see the best Application Security teams do - and which so many AppSec professionals seem to avoid at their own peril. What’s worse - this one thing does not require a line in the budget to implement.
That one simple trick: Communicating regularly with developers!
And before anyone claims they’re already doing this: telling developers to fix the vulnerabilities your tools are finding does not count as “communicating”. Here’s a few questions worth asking to determine if you’re actually communicating with developers:
- When was the last time you or someone on your AppSec team setup a recurring 1:1 with a member of the Engineering team(s) you work with?
- Do you know what the Engineering team’s Objectives & Key Results (OKRs), or Key Performance Indicators (KPIs) are? Do you know how they’re being measured?
- Do you know which projects the Engineering team(s) are working on, and what projects are going to be worked on next?
- Have you invited Developers to participate in the selection process for new security tools?
- More importantly, do you know which tools the development teams are using - and which tools they’d rather be using?
- Do you know which of your security tools and/or processes are causing the most pain for the development organization?
- Have you even tried building a relationship with your developers?
But first, some hard pills for AppSec Professionals to swallow
- Scan speed is not what’s causing friction between Security and Development teams
- The amount of vulnerability findings your tools produce does not make the company more secure
- Telling Developers what to do is not going to solve these problems
- … we would know all of this if we spent more time communicating with Developers
Scan Speed and Developer Friction
I can’t tell you the number of times I’ve heard security professionals claim that fast scans are required by their development teams. But here’s the thing - unless your business is operating like Netflix or Shopify and releasing code directly to production after passing automated tests, this really does not apply to your situation. And if you don’t believe me - here’s a question for you:
Does your development team require a code review before merging new code?
If your company is using the same “best practices” as most other companies, the answer is almost certainly “yes”. And if the answer is “yes”, it begs the next question: how long does it take for a pull request to receive a code review? Hours? Days? If that’s the case, then so long as the developer still has a good context of the code that was scanned - meaning within a reasonable amount of time - then faster scans hardly make a difference.
But you know what will make a difference in slowing down the development process? The amount of bullshit findings your scanning tools produce.
Quantity vs. Quality of Security Findings
If there’s one universal law when it comes to security tools, it’s this: you’ve got speed, accuracy, or completeness - and you can only choose two.
The unfortunate thing about pretty much every tool on the market today that optimizes for speed is that they try to make it really easy for security teams to use without considering developer impacts. As a result, such tools almost always dump a mountain of findings on your developers. Sure, these tools are “accurate” in that they’ve found a bunch of things wrong in the code - but they rarely seem to take into account the threat model associated with their findings. Oh no! You can generate a SQL injection by changing a database table name in the configuration file! Anyway…
When it comes to scan speed, you played yourself - because the scan took five to ten minutes producing these kinds of findings; Now you’re going to spend hours in meetings across several weeks discussing finding validity. This is how security teams hold up the development process. Security’s five to ten minute scans often prevent developers from moving onto the next project, and impacts their OKRs / KPIs.
Meanwhile, during all that time sending passive aggressive emails back-and-forth regarding the validity of the security findings, very little is getting fixed - and the business is no more secure now than it was when the findings were produced. The only thing being impacted here is the Development team’s productivity. It’s no wonder they’re pissed off at security teams.
Dictating vs. Collaborating on Security
By now I’m sure some of you are thinking - why don’t we just tell the Developers what to fix? And sure, you could spend time reviewing the findings on behalf of the developers - but what leads you to believe that the two to five Security Engineers reviewing thousands of findings are going to be any faster than modern security tools at eliminating hundreds (and sometimes thousands) of false positives? Manually reviewing security findings is an incredibly poor use of time for expensive security resources.
Likewise, if we think telling developers they need to use certain tools (without considering their input) is going to somehow magically solve the problems outlined above, we’re kidding ourselves. More often than not this practice just leads to development teams delaying security scans until it’s too late to stop their momentum - and any attempt to try and delay things further only leads to the wrath of an Engineering VP crashing down on Security’s doorstep.
So how can we avoid all of this back-and-forth in the first place? It’s simple: by communicating more frequently with development teams.
How Communication can 10x your AppSec Program
Start by asking yourself these (and similar) questions:
- When was the last time you had an Engineering leader help you select Security tools for their team(s) to use?
- How frequently are you taking action on Developer feedback regarding the effectiveness of your Security tools and/or processes?
- How many hours, days, or weeks are you delaying projects because security tools are quickly generating false positives that need to be manually reviewed?
Bring Engineering to Security Tool conversations
When Security spends time building trusting relationships with Engineering teams, a ton of potential can be unlocked to streamline development and security processes. One of the first things you should do to build trust is ask Engineering teams to participate in conversations involving the selection of Security tools.
Your development teams have experienced first-hand the kinds of pain Security tools can cause, and there’s no one better to help figure out the best way to implement Security tools than the teams who will be responsible for using them. This is doubly true if the Engineering team knows that it will be migrating to a new platform - since the Security team will need to figure out how to support the new platform after the move. Having an early warning here will help avoid costly investments (in terms of time, money, and people) that end up being useless after such changes.
More importantly, security teams need to take action on the feedback that developers provide as it relates to the security tools. The moment we start ignoring these important voices in the process is the moment we begin to lose the trust and goodwill of our colleagues. If your development team is complaining because the security tool you’ve implemented quickly produces a load of garbage results, listen to them! Ask for their support in tuning the tool - or even better, ask them to participate in the selection process for a new tool!
A lot of people talk about building Security Champions - and taking action on feedback by inviting developer participation is your best opportunity to do just that!
Reducing Security Delay
If Developers generate Technical Debt, then AppSec generates Security Delay. The best we can hope for is to reduce that delay by removing as many false positives as we can from the results of our tools - and by getting developers to use the tools more often.
The whole process starts by collaborating with development teams to implement the right security tools in the right locations along the Continuous Integration / Continuous Delivery (CI/CD) journey. Although if I’m being honest, very few companies actually practice Continuous Delivery - it’s more like Continuous Integration / Periodic Deployment.
Anyway, as I was saying earlier - if we want developers to use the tools we select, there’s no better way to improve adoption than by including them in the selection process. If Development teams have skin-in-the-game when it comes to the quality of the tools selected, they will help you select tools that produce fewer false positives. Developers are also more likely to remediate the findings produced by tools they helped select - and will sometimes jump in to help tune things if necessary!
TL;DR
You can’t do DevSecOps without doing DevOps - and DevOps is just communication, coordination, and collaboration.
Moreover, communicating regularly with Developers doesn’t require a line in the budget - and gathering their input when selecting Security tools dramatically improves both security tool adoption and security finding remediation rates.
So what’s stopping you from 10x’ing your AppSec Program?
Thanks again for stopping by to read my pseudo-random musings 😊 While I draft my next blog post, you can git checkout other (usually off-topic) content I’m reading over at Instapaper - or review my other posts on DevSecOps” for lessons learned from my practical experience in a Fortune 100 global enterprise.
Until next time, remember to git commit && stay classy!
Cheers,
Keith // securingdev
If you found this post useful or interesting, I invite you to support my content through Patreon 😊 and thanks once again to those who already support this content!