The Need for Increased Collaboration Between SecOps and DevOps to Reduce Application Vulnerabilities

For most enterprises, detecting, mitigating, and addressing security compromises is an ongoing challenge. Therefore, there needs to be a more collaborative approach between DevOps and SecOps for successful security integration.

DevOps has helped businesses build and release applications at scale, but security considerations are often set aside in the speed of agile development increasing application risks and creating huge gaps in security.

Even though developers are asked to be more security minded, their daily experiences show a different story. As per GitLab’s 2019 Global DevSecOps Report, where 4,000 software professionals were surveyed, around 44% of the developers admitted that they were not judged on their security vulnerabilities. Their managers mostly focused on metrics like the number of deployments and closed tickets instead and their ability to pick up new tasks which adds to the pressure to deliver quick results for the company.

SecOps on the other hand are responsible for protecting the enterprise with necessary security controlling and also fulfil compliance standards and demonstrate a reduction in security threats, with little regard for speed unless a security incident has occurred.

Read More: The Security Professionals Are Concerned about IoT and IIoT Protection

Prioritizing Security in Application Development

Bringing SecOps and DevOps together requires a significant cultural shift, implementation of a host of automated security tools and developer buy in.

Let’s look at a few ways SecOps and DevOps can collaborate to reduce application vulnerabilities.

Change the Culture

As per a 2020 ESG research report, almost around 48% of enterprises regularly push vulnerable code, and they are aware of it, and this is a very worrying statistic for security personnel. Shipping vulnerable code tells developers volume and speed is what matters and not the quality of code. There needs to be a change in attitude towards security vulnerabilities. Organizations must think of prevention from the start and shift from their damage control mentality – so that they never have to go to war on security threats.

Senior leadership need to advise against shipping any vulnerabilities in their product, and pay more attention to development. Development managers in turn should update their development team metrics, recognize and reward changes in behavior. A clear signal from the top down will help developers set their priorities and focus more on security.

Recognize Developers as Important players

Developers shouldn’t be considered as the weakest link or the enemy. They are passionate about the work they do and possess an intricate understanding of the software they create. They should not be accused of making mistakes, especially when they haven’t been trained to handle these issues. It can result in them feeling mistreated and become demotivated which may lead to staff churn.

Developers should be given the opportunity to present their recommendations on new processes and they should also be involved in new security plans. When SecOps buy security tools that don’t speak to the needs of developers, it leads to a drop in developer adoption. Also, often when the security tools identify vulnerabilities, developers are sometimes unequipped to address these issues, rendering the tools useless.

Read More: Securing Remote Workforce by Modernizing Security Operations Center

Keep the Developers Engaged

As per GitLab’s 2019 DevSecOps report, 70% of developers admitted that while they are expected to write secure code, they get no help or guidance.

Organizations must invest in security training so that their developers have a fighting chance of taking on security vulnerabilities. Developers need constant access to hands-on learning that encourages them to learn and hone their skills in a real environment so that they can engage in writing secure code. They should be able to learn about recently identified software vulnerabilities, in real code, so that they can work in their own frameworks.