In IT organizations, so many security breaches and bugs are spotted everyday. But, who is actually responsible to fix them? Do we know that?
GitLab’s 2020 Global DevSecOps Survey asked developers, security team members, operations pros and testers about sole responsibility for security in their organizations.
About 28% of developers, 33% of security groups, 21% of ops pros, and 23% of testers said obligation regarding security laid uniquely on their shoulders. Simultaneously, 29% of security groups said everybody was capable, close to the same number of as said they had sole proprietorship.
Confounded at this point? So were a significant number of our overview respondents, who had a great deal to state about the liquid – and baffling – nature of DevSecOps.
So these are some individual statements GitLab collected while finishing their survey:
“The team is trusted to do its own security research and implementation. We don’t know how good or bad we are.”
“I am the only one who actually cares about security in my organization.”
“I regularly put security suggestions in the box of suggestions, only to be ignored.’”
“There’s a security team, but it doesn’t involve face to face with us, the dev team. So we just run the dev process without counting on them.”
But why all these grudges? Shouldn’t they find a way to work together already? Let’s see from where it all started and what is the way out to put an end to this blame game.
The story of developers and security pros not seeing eye to eye goes long back. In GitLab’s2019 Developer Surveysecurity pros were exceptionally expressive regarding the matter of developers essentially not doing what's needed to empower security. Designers were similarly troubled, referring to security's "heavy-handed approach"This year, we drilled down further to see if we could understand why dev and sec continue to see the world differently.
Contrasts between the groups immediately got obvious. As per the overview discoveries, 65% of security team members revealed that their organizations have moved security left. Be that as it may, the unseen details are the main problem, and the subtleties don't generally bolster a move left.
A strong larger part of developers are not running SAST, DAST, or holder examines, and just about half direct consistency filters. Regardless of whether the sweeps are run, under 19% put SAST results into a pipeline report an engineer can get to. Dynamic application security testing (DAST) admissions surprisingly more terrible – under 14% of organizations gave developers access to those reports.
In this way, developers don't have simple access to basic information. Then again, security experts are disappointed that developers keep on either miss bugs inside and out or discover them past the point of no return all the while. Over a portion of security respondents (61%) concurred at some level that vulnerabilities were for the most part found by security experts (not designers) after code is converged in a test situation (which is moderately late simultaneously). As such, when asked how engineers discover bugs versus security groups, 93% gave developers credit for finding just 25% or less of the bugs to be found in existing code, leaving 75% of the bugs for security to discover at a later stage simultaneously.
What's more, as though that wasn't adequately disappointing, 69% of security team members whined it was hard to get developers to remediate bugs, regardless of whether their associations included security as a developer execution metric.
Contrasts between the groups immediately got obvious. As per the overview discoveries, 65% of security team members revealed that their organizations have moved security left. Be that as it may, the unseen details are the main problem, and the subtleties don't generally bolster a move left.
A strong larger part of developers are not running SAST, DAST, or holder examines, and just about half direct consistency filters. Regardless of whether the sweeps are run, under 19% put SAST results into a pipeline report an engineer can get to. Dynamic application security testing (DAST) admissions surprisingly more terrible – under 14% of organizations gave developers access to those reports.
In this way, developers don't have simple access to basic information. Then again, security experts are disappointed that developers keep on either miss bugs inside and out or discover them past the point of no return all the while. Over a portion of security respondents (61%) concurred at some level that vulnerabilities were for the most part found by security experts (not designers) after code is converged in a test situation (which is moderately late simultaneously). As such, when asked how engineers discover bugs versus security groups, 93% gave developers credit for finding just 25% or less of the bugs to be found in existing code, leaving 75% of the bugs for security to discover at a later stage simultaneously.
What's more, as though that wasn't adequately disappointing, 69% of security team members whined it was hard to get developers to remediate bugs, regardless of whether their associations included security as a developer performance metric.
Uncover the shared responsibility model in DevSecOps
Confused about our certifications?
Let Our Advisor Guide You
