Please enable JavaScript to view the comments powered by Disqus. How To Get Rid Of Thr Blame Game Of Security Responsibility?

 

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

NovelVista

NovelVista

Last updated 17/06/2020


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

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.

Topic Related Post

5 Practices Towards A Well-polished DevSecOps Environment
5 Practices Towards A Well-polished DevSecOps Environment
DevOps 2.0: An Insight To Site Reliability Engineering (SRE)
DevOps 2.0: An Insight To Site Reliability Engineering (SRE)
Few Perks Of Choosing A DevOps Career
Few Perks Of Choosing A DevOps Career

About Author

NovelVista Learning Solutions is a professionally managed training organization with specialization in certification courses. The core management team consists of highly qualified professionals with vast industry experience. NovelVista is an Accredited Training Organization (ATO) to conduct all levels of ITIL Courses. We also conduct training on DevOps, AWS Solution Architect associate, Prince2, MSP, CSM, Cloud Computing, Apache Hadoop, Six Sigma, ISO 20000/27000 & Agile Methodologies.

 
 

SUBMIT ENQUIRY

 
 
 
 
 
 
 
 
 

Upcoming Events

ITIL-Logo-BL
ITIL

Every Weekend

AWS-Logo-BL
AWS

Every Weekend

Dev-Ops-Logo-BL
DevOps

Every Weekend

Prince2-Logo-BL
PRINCE2

Every Weekend

Topic Related

Take Simple Quiz and Get Discount Upto 50%
     
  18002122003
 
  
 
  • Disclaimer
  • PRINCE2® is a registered trade mark of AXELOS Limited. All rights reserved.
  • ITIL® is a registered trade mark of AXELOS Limited. All rights reserved.
  • MSP® is a registered trade mark of AXELOS Limited. All rights reserved.
  • DevOps® is a registered trade mark of DevOps Institute Limited. All rights reserved.