Knowing About Vulnerabilities is only Half the Battle
As we continue our journey to continuous IT, there's a lot of focus on security. And well there should be. Breaches abound. Vulnerabilities are discovered on a daily basis, and the patch gap doesn't seem to be getting any smaller.
One of the often-suggested solutions to more secure code is that of scanning source code. Static and dynamic security scans have become a staple ingredient to continuous delivery processes. Our own internal pipelines include them, and I can - at any time - take a peek at a dashboard that tells me all about what those scans find.
 |
But knowing vulnerabilities exist in source code - as G.I. Joe reminds us - is only half the battle. While it would be fascinating if the other half really was blue and red lasers, the reality of application security is that the other half is "Doing something about those vulnerabilities." Sadly, we don't see that reality becoming reality. You may recall a Tripwire report (2019 State of Container Security) in which 17% of respondents admitted to having vulnerable containers, knew what they were, and deployed them anyway. You may also recall a 2017 Arxan/IBM report on Mobile and IoT Application Security that found that 53% of respondents use static security testing and 51% use dynamic security testing for mobile apps. And despite significant concerns regarding a breach, nearly half (44%) were taking no steps to prevent it. |
The problem of not testing and not doing anything about known vulnerabilities is almost always tied to pressure to decrease time to value. Almost half (48%) of developers say they don't have enough time to spend on security (2018 DevSecOps Community Survey). Other surveys concur; there is incredible pressure on developers to churn out code faster and more frequently. It turns out that security continues to be the "thing" that's dropped when speed is on the line whether in the data or delivery path.
It's well established that people work toward what they're measured on. And as developers are people, that means they are subject to that rule, too. If they're measured on quickly getting to market, they're going to work toward that - even if it means skipping steps that compromise security. If we’re going to deliver secure applications to market, we need to embrace a cultural shift that measures and values securely getting to market as much as it does quickly getting to market.
Until it does, we're just as safe relying on red and blue lasers to deal with vulnerabilities as we are on developers.