Security is a Feature
TL;DR / Summary at the end of the post.
The greatest challenge in any Application Security or DevSecOps program is driving remediation of vulnerabilities found in the software our companies write. Part of the issue is the nature of the tools we introduce in the software development lifecycle, and part of the issue is how we communicate why security findings should be remediated. This post is targeted at the latter of these two issues.
First I want to level-set on what I consider as a “feature” in software. In my world, a feature is defined as functionality that allows a user to perform an action of some kind. Moreover, from a product perspective features are generally funded (in terms of both time and effort), improved upon, tested, and maintained over time.
That being said, when faced with security vulnerabilities the greatest hurdle to remediation is getting time on the development calendar. In order to resolve vulnerability findings development teams need to reallocate time away from building new features in order to understand the vulnerabilities - and usually require additional time to learn the proper way to go about fixing the issue. Likewise, developers may find they need to re-work a key piece of functionality in order to truly remediate the vulnerability - which can be both an expensive and potentially breaking change.
In this light, it’s no wonder project managers are reluctant to spend time on security vulnerabilities. Developer’s are expensive to hire and retain; their time is valuable. Likewise, spending time on security findings might cause the company to lose “first mover’s advantage”, or just as likely there are customers asking for (or expecting) features to be delivered in order to agree on purchasing the software or renewing their contract.
When this sort of resistance happens, there are two questions you can ask project management and/or engineering leadership that will drive your point home. Granted, these questions won’t work in every culture - but in most places where software is developed they will do the job.
The first question (shot): “Do you have a banking or financial application on your phone?” In many places around the world the answer will almost-always be “Yes”.
The second question (chaser): “Would you use that app if it had the same vulnerabilities our software has?” The look of shock, disbelief, frustration, or anger you receive when asking this question can be palpable - but it’s important that you keep a straight face when you ask - because the answer is usually “No” if they’re being honest with you.
And this is why I believe Security is a Feature.
While customers won’t ask for it, there is an expectation from users that a website or piece of software your company builds is secure “out of the box”. It is because of this expectation that companies should be treating security like a feature by funding it (in terms of both time and effort), improving upon it, testing for it, and maintained it over time.
How to support this content: If you find this post useful, enjoyable, or influential (and have the coin to spare) - you can support the content I create via Patreon.️ Thank you to those who already support this blog! 😊 And now, back to that content you were enjoying! 🎉
So how much time is enough? Generally speaking, I recommend starting with 20% of a developer’s time allocated to reducing technical debt. That investment comes out to one day a week, or one sprint in every 5 sprint cycles. And yes - you read that correctly - I said “technical debt”. Security isn’t the only issue that developers need to address when building applications. Although, if the vulnerabilities warrant it - there are at least a few companies who can afford to spend 90 days focusing solely on security.
TL;DR / Summary
Many product and engineering teams see security as a drag on their ability to build and maintain features that customers are asking for or expecting. What this viewpoint fails to consider is the fact that customers are expecting security without feeling the need to ask for it.
By asking the questions highlighted above, you will start to shed light on our customer’s expectations of using software that is secure by default. Once you’ve managed to open up a dialogue around investing in security, consider first asking for dedicated time toward remediating technical debt.
When asking for time, start with 20% as a baseline and agree on being flexible when a major vulnerability pops up. Likewise, it will be important to be flexible with development teams who need to deliver features on time in order to bring in revenue.
Beyond that, make sure you are providing your development teams with tools that produce actionable findings so that the time they are investing in security is well spent.
I’m sure I’ll write more posts on this topic, as it’s the most important aspect of any security program. In the interim, thanks again for stopping by and 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!😊