We recently spoke to a focus group of security professionals, software engineers and developers for a discussion on DevSecOps. We’ve quoted a few of them throughout this article.
As more and more organisations abandon the outdated waterfall methodology for Agile development practices, their development teams are employing Continuous Integration (CI) and Continuous Deployment (CD) practices. But with shorter, accelerated development cycles comes a greater security risk since releasing new code creates the potential for new security vulnerabilities. To address an ever-growing attack surface, DevSecOps embeds a security measure as a necessary part of the operating environment, a set of modifications that must be made to the application code and a fundamental functional and performance requirement of the software itself.
DevSecOps is a team sport
Bringing together DevOps and SecOps, at its core, DevSecOps is a team sport that requires close collaboration across the five phases of the software development lifecycle (SDLC), plus post-deployment and incident response:
- Planning
At the outset, security and development teams need to agree on an application’s functional requirements and define operational, performance and security requirements. This includes defining key performance indicators (KPIs), monitoring application performance metrics and incident response plans and procedures. This collaborative effort defines roles and responsibilities, establishes communication channels and establishes how to conduct regular incident response drills and simulations. - Coding
During code reviews, DevOps engineers and SecOps analysts collaborate to review code for security vulnerabilities and adherence to security best practices. While SecOps team members guide secure coding techniques, potential attack vectors and compliance with security policies. Developers must bake in the hooks to get the telemetry into analytic solutions for both preventative and reactive security. This usually comes in the form of M.E.L.T or metrics, events, logs and traces. OpenTelemetry, for example, can be used at a high OS log collection level or a lower application and service level.At this stage, teams also need to agree on how they’ll measure service level indicators (SLIs) against service level objectives (SLOs) and how error budgets inform the prioritization of releases. Exceeding error budgets means more work to bring application performance back in compliance with your service level agreements (SLAs).
- Building
DevOps and SecOps teams need to work together to integrate security tools and workflows into existing development and operations processes. This may involve customising the CICD pipeline to include security checks, integrating security information and event management (SIEM) systems with incident response workflows and automating compliance checks and audits. Fortunately with today’s cloud SaaS solutions, standing up and maintaining complex analytic or SIEM solutions is a thing of the past. - Testing
In the spirit of shift-left, DevOps and SecOps teams collaborate early to implement automated security testing tools, such as pen testing and scripts, into the CI/CD pipeline. This includes tools for static code analysis, static application security testing, dynamic application security testing (DAST), threat modeling, container security scanning and infrastructure vulnerability scanning. SecOps specialists work with DevOps engineers to configure these tools, interpret results and ensure that security vulnerabilities are addressed promptly. - Deploying
To secure the deployment environment, DevOps engineers work with SecOps specialists to implement secure configuration management practices. This involves configuring servers, containers and other infrastructure components according to security best practices and organizational policies. To automate the deployment process, SecOps works with DevOps teams to ensure that security controls, such as encryption, access controls and network segmentation, are integrated into deployment automation scripts for secure software delivery. - Post-deployment
Following deployment, SecOps specialists monitor the deployed application for security incidents and anomalies. DevOps engineers collaborate with SecOps teams to configure monitoring and alerting systems to detect and respond to security threats in real-time. To ensure the deployed application is regularly patched and updated to address newly discovered vulnerabilities, DevOps and SecOps teams coordinate patch management efforts, testing patches in a non-production environment and deploying patches on time. - Incident response
In the event of performance or security issues, DevOps and SecOps teams collaborate closely to troubleshoot and resolve the issues. This may involve analysing monitoring data, conducting root cause analysis and implementing corrective actions to mitigate the impact of the incident.
Throughout these steps, mature customers will adhere to an “everything as code” approach. From development to deployment to even detection and response, things are done programmatically with as little manual or human involvement as possible. Having things codified also means they can be automated and improved upon in an iterative way.
Why do UK businesses struggle to implement DevSecOps?
As much as an organisation may want to bring DevOps and SecOps together, implementing DevSecOps is certainly easier said than done. For legacy companies, in particular, development, security and operations have always been separate, and their silos run deep across tools, systems and even language. But even cloud-native organisations have their struggles, as another customer shared, “We absolutely have one team responsible for security and operations, but being 100% cloud and with a lot of development outsourcing, the dev piece is not part of the same group.”
Similarly, another customer told us, “With our teams separate, it is a constant battle to ensure that the development team is focused on the security pieces.” Sound familiar? DevSecOps programs often fail due to three key factors:
Lack of ownership
We absolutely have one team responsible for security and operations, but being 100% cloud and with a lot of development outsourcing, the dev piece is not part of the same group.
Conflicting definitions of acceptable metrics and standards
It is important to have the SOC team on board and not just make a decision on new tools without getting excitement from the people who will work with it.
Gaps in understanding of security vulnerabilities and best practice
With our teams separate, it is a constant battle to ensure that the development team is focused on the security pieces.
Best practices for building a DevSecOps practice
No matter the size or maturity of your organisation, there are universal best practices to get started building a DevSecOps practice set up for success from the get-go.
- Adopt a shift-left approach
Ensure security considerations are addressed as early as possible in the development process by incorporating security requirements into user stories, performing security reviews during code reviews and conducting security-focused design reviews. This also means extending Infrastructure as Code (IaC) and Configuration as Code (CaC) to include Security as Code (SaC), whereby security configurations, policies and controls are codified and version-controlled alongside application code, ensuring consistency and repeatability. - Prove the ROI
Security and innovation are commonly viewed as competing goals. Get buy-in from your executive leadership, by demonstrating how building security into applications from the start with secure code saves your organisation from costs associated with downtime and non-compliance. Ultimately, there needs to be a consensus that the security team helps prevent slowdowns rather than pose a barrier to agility. - Enable with education
Invest in cross-training and skill-sharing initiatives to ensure development and security team members understand each other’s domains and how they can help one another. This helps foster empathy, understanding and collaboration between teams. Train developers in secure coding practices and empower them to suggest critical security changes. - Centralise visibility
Ensure developer and security teams have a common, real-time view of their application security posture with dashboards, application observability for enhanced vulnerability management and AI-powered alerting systems to surface only the most relevant threats. Centralise visibility and democratise your telemetry. Use tools that allow various stakeholders to share and collaborate seamlessly. It’s hard to manage an orchestra when all your talent is using different sheet music. - Embrace logs
A fundamental barrier to collaboration essential for DevSecOps is different teams relying on different data sources. When an incident arises, there’s no time for data debates. Logs are at the atomic level of observability and security data and a natural byproduct of the application development process, containing historical data points, such as when code was updated, pushed into production or modified. Serving as a single source of truth, logs are data that everyone can agree on and enable faster root cause analysis to resolve a security incident faster. Learn more about DevSecOps and log analysis.
Enabling DevSecOps with Sumo Logic
Sumo Logic is a SaaS log analytics platform that enables organisations of all sizes to implement DevSecOps practices with enhanced automation, centralised security posture management, site reliability engineering (SRE) monitoring tools, and full-stack observability.
Learn more in our comprehensive guide to accelerate and secure your SDLC with DevSecOps.
