Thinking About AppSec in DevSecOps

Let’s not forget about People & Process when we think about DevSecOps

DevSecOps. It’s no longer just a buzz word, but to take it from a buzzword to an effective program, we need to put in the work around people & process.

Application Security (AppSec) is an integral part of DevSecOps and should not be viewed as a separate discipline. If you want to build secure, resilient products, you need to incorporate application security strategies into your DevSecOps program. DevSecOps is software delivery methodology that integrates application security into the development and operations processes of an integrated DevOps model. It is the philosophy with development, security and operations as its execution. Building an effective DevSecOps program, is a combination of people and process with technology integrated, tuned and right-sized for the organization.

Picture this, your team, like 94% in the world, work in an agile development environment. Code is written in microservices, deployed in the cloud with thousands of pushes every day. Inherently, this introduces more risk.

As an industry, we have tried to buy our way secure by deploying every DAST, RASP and IAST scanner with little direction on how to apply the output. The result has been a pile of false positives and broken trust between developers and security.

Before we get to tech or process, let’s think about people. People are the cornerstone of the DevSecOps framework, playing a crucial role in the integration of development, security, and operations. Within the "people, process, technology" concept, individuals are responsible for driving cultural change and fostering collaboration across traditionally siloed teams. DevSecOps requires a shift in mindset, where security becomes a shared responsibility among all team members rather than being confined to a separate security team. This cultural transformation starts at the top, with senior leaders communicating the importance of security practices and encouraging their adoption throughout the organization. By breaking down barriers and promoting mutual empathy, people in DevSecOps create an environment of collective focus and shared accountability. Training and education are essential components, ensuring that team members develop the necessary skills and security awareness to implement DevSecOps principles effectively.

Undisputably, Tech is also needed. DevOps runs on automation, efficiency and visibility. DevSecOps needs to take that same approach but apply it with a focus on tuning the output to focus on the high risk, high impact vulnerabilities that affect the business. We can’t fix everything, so we need to have a risk mindset when framing what to fix.

Who owns the output of the scanning tools?

Steven Smith, Cyber Security leader at Freshworks, summarizes it in a shared responsibilities model.

“Security owns the education and capability aspects. We provide the knowledge, materials, and capabilities to harden and reduce risk.Our responsibility is providing tangible results that carry actual risk. Quality over quantity. Ultimately it is the systems owners responsibility to ensure the security of their systems. It's their responsibility to ensure they are applying the controls, knowledge and capabilities. My common approach is that we deploy the capabilities, and keep them tuned and efficient. It is the responsibility of the system owner to maintain a clean bill of health.”  

Where tech is needed:

1. Single pane of glass (ASPM, CNAPP)
   Integrating multiple AppSec tools (e.g. SAST, SCA, DAST) into existing DevOps toolchains can be challenging. Teams often struggle to consolidate and reconcile findings from different security tools
2. Coach developers into better code (Corgea and Dry Run are two startups doing this well)
3. Help fix vulnerabilities (check out Mobb.ai)

Where Process & People are needed

1. Determine risk tolerance. This process requires evaluating various factors such as compliance obligations, potential threats, and the value of data and assets, while aligning these assessments with management preferences and industry pressures to establish a balanced approach between risk-taking and security measures
2. Train and Educate teams. Don’t expect your development teams to know the ins and outs of secure code. Use the scanning tools or pen tests to help shape the training to tailor it to the real risks identified. Look for patterns, root cause and fix those.
3. Have a contingency plan when there’s a delayed code push, someone (not a tool) is available to support and fix vulnerabilities. Consultants to help scale teams during big projects is a great option here.
4. Build Joint KPIs. DevSecOps means a coordinated partnership between Development, Security and Operations. Some ideas could be:
   1. Percentage of Secure Code at Release
   2. Number of Security Champions per Development Team
   3. Percentage of Projects with Completed Threat Models
   4. Security Tool Adoption Rate

At the end of the day, DevSecOps is a philosophy that needs to be deployed holistically with people, process at its core and technology to be used to scale, automate and drive speed.

‍

‍