A pair of newly-released surveys indicate that while progress is being made, organizations aren’t integrating security into Agile and DevOps practices as they should. And while many of the processes around Agile and DevOps may be relatively new to many enterprises — the hurdles created by security certainly are not. Security is still seen as an unwanted, often unneeded hindrance to service delivery.
The recent study from Sonatype, the DevSecOps Community Survey, supports this observation. The DevSecOps Community Survey found that 58 percent of the nearly 2,300 surveyed view security as an inhibitor to DevOps agility.
The survey also found that while 50 percent of developers know security is important — they say that they don’t have enough time to spend on it. Let that sink in for a moment. And it shows that shoddy security isn’t necessarily the fault of developers: it can be about poor organizational support.
Fortunately, there is some good news to be found in the survey. When asked if they believe that their security policies and teams slow IT down, depending on the (self-reported) DevOps maturity-level of the organization, only 28 percent of highly mature organizations believe so. However, a disheartening 47 percent of responses from less mature organizations do believe that security policies and teams slow them down. This, again, suggests low organizational support for security.
And, as is so often the case, the data indicates that it’s very likely that these organizations are suffering from poorly implemented policies and practices than bad people. When asked at what point in the development process does their organization perform application security analysis: only 13% cited in the design and architecture phase, 34 percent in development; and not even half, at 49% during QA/Test; 45% prior to release into production; and 42% in production.
At 27 percent, not even a third of organizations tend to security within each stage identified in the survey.
The more mature the organization, of course, the better these statistics become. But these statistics, overall, do look horrendous. It’s no wonder security teams are often left with nothing to do but nag. After all, if not even a sixth of those surveyed are analyzing security impact during the design phase and not quite half are doing it during quality assurance and testing phase, then security teams are going to have no choice but to nag. This is because when these applications and services hit production, they are riddled with bugs.
Other recently released surveys support this lack of focus on security. Automation vendor Chef just released its survey of 1,500 IT practitioners in app, cross-functional teams, infrastructure, and security and found that (no big shocker here) faster deployment is the top priority, and workloads are rising more rapidly that headcount, while development teams are outpacing operations teams in growth. However, and this surprised even me, about half of those surveyed said that they never or at least inconsistently assess for compliance.
Now switch back to the Sonatype survey and you may get an idea why some steer clear of testing for adherence to policy compliance or security. When those respondents were asked if their current approach to application security put security professionals in the role of nags who can only point out vulnerabilities but can’t resolve them; 18 percent strongly disagreed, 27 percent somewhat disagreed, 39 percent somewhat agreed, and 16 percent strongly agreed. So, 55 percent of those surveyed agree to some extent that security pros function largely as nags.
It’s clear that organizations are moving faster, and more are embracing continuous delivery, continuous integration, and are delivering more features, functionality, and apps than ever before — but new security must follow — enterprises need to assess the threats and risks of new apps from their beginnings in design and architecture and then test throughout the development process. And, most importantly security defects and compliance shortcomings must be remedied just like any other system or functional deficiency.
These are the types of processes that should be in place. The technologies and known good practices are available today to make this possible for any organization. However, it seems like in addition to putting this type of continuous testing and monitoring in place when it comes to software security and quality — many organizations have work to do on their culture and how security related defects and security teams are viewed.