How To Get Rid Of Thr Blame Game Of Security Responsibility?

NovelVista

Last updated 23/07/2021

---

       

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 Blame Game

The story of developers and security pros not seeing eye to eye goes long back. In GitLab’s 2019 Developer Survey security 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.

How DevSecOps Can Work

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.

DevOps Trends in 2024: The Continued Rise of GitOps, Data Observability, and Security

Building a High-Performing SRE Team: Key Strategies and Best Practices

Securing the Pipeline: Integrating Security into Your SRE Practices