AppSec in the Age of DevSecOps
AppSec in the Age of DevSecOps
In this article, we discuss the current state of application security as more and more organizations are moving towards DevSecOps adoption.
Join the DZone community and get the full member experience.Join For Free
Awhile back, I had a conversation with a friend that I went to school with (currently a senior member of the engineering team at a large retail chain) who was tasked with the job of identifying potential application security partners (he addressed vendors as partners, which I personally liked) that they could collaborate with on various areas as part of their product security initiative. The following piece emerged as an extension of my immediate thoughts when he shared his views of what could have made his experience of interacting with front line sales and marketing folks better.
In the context of DevSecOps, much has been said about the need for engineering to speak security, security to speak code, DevOps to speak security, etc. But, as a Technology Service Provider (TSP), riding the current wave of application security, its almost mandatory for the Sales and Marketing teams to speak relevant tech!
You may also like: How AppSec Has Changed.
Application Security — No One Size Fits All
Application security as a practice is dynamic. No two applications are the same, even if they belong in the same market domain, presumably operating on identical business use-cases. Some (of the many) factors that cause this variance include technology stack of choice, programming style of developers, a culture of the product engineering team, priority of the business, platforms used, etc. This consequentially results in a wide spectrum of unique customer needs.
Take penetration testing as an example. This is a practice area that is presumably well-entrenched, both as a need and as an offering in the application security market. However, in today's age, even a singular requirement such as this could make or break an initial conversation. While, for one prospect, the need could be to conduct the test from a compliance (only) perspective, another's need could stem from a proactive software security initiative. There are many others who have internal assessment teams and often look outside for a third-party view.
Few others who are quite up the maturity curve could be looking to up-their-game through a hybrid approach of tool automation with a complimenting methodology of manual assessments. I'm not even considering the added complexity involved in just the sheer nomenclature of such a service - penetration testing, security testing, vulnerability testing, VAPT (which actually is a combination of two independent practices) etc.
Each of these unique needs emerges from a buyer who could come from varying degrees of informed decision making. TPs would need to retrofit their positioning accordingly. They often run a risk of underwhelming a mature buyer or overwhelming an early practitioner, especially in high variance offerings, such as security tooling, security regression, and threat modeling. While some might argue that losing an overwhelmed prospect could be the result of their accurate customer segmentation, there are stories to tell of the other kind.
Scoping questions, such as the ones below, can significantly help technology marketers strike the right chord with their prospects and elevate the experience of the initial interaction.
- What is the motivation for the penetration test (compliance regulation, internal validation, business drivers, their customer's need, etc.)?
- What are they specifically looking from a third party partner (external certification, specialized approach, uncovering logic flaws, etc)?
- What is the current appetite (resource bandwidth, commerce) to take on your advanced offering (automation, regression, etc)?
- How security aware are their developers? Can they take the findings to its logical conclusion through successful remediation?
DevSecOps is about GETTING there, rather than being there.
Published at DZone with permission of Rahul Raghavan, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.