Canonical welcomes the .NET development platform, one of Microsoft’s earliest contributions to open source projects, as a native experience on Ubuntu hosts and container images, starting in Ubuntu 22.04 LTS.
The convenience, availability and ease of the cloud delivery model of services have made it a huge, growing hit. One analyst firm forecasts that the global Software as a Service (SaaS) market size will reach $307.3 billion by 2026, at a compound annual growth rate (CAGR) of 11.7%. Finances Online is even more optimistic, reporting a projection of $623 billion by the year 2023 at a CAGR of 18%.
Whichever prediction turns out to be more accurate, there's no doubt that "as a Service" has found a home among enterprises. The Agile framework behind this model requires automation to accelerate QA and change management. This covers the speed aspect of continuous delivery, but what about security?
For "as a Service" to be market-ready, security and compliance must be part of the dev process from the beginning. For this to succeed, it's necessary for teams to take on a DevOps mindset — one that places a priority on fast delivery and automated workflows.
This is easier said than done. DevOps is the East, and SecOps/compliance is the West, and until recently, the two have never met. DevOps focuses on things like policy management, monitoring, code inspection and risk mitigation. SecOps needs to anticipate risk and ensure controls are retroactively reducing compliance and security risk. The intrinsic conflict comes from a traditional view that security review should come after software development as a final check but instead ends up becoming an irritating process of reconciling necessary controls into the release cycle.
This inherent tension of mandates and cultures makes the idea of shared responsibility foreign. DevOps can be seen as more of a do culture (Atlassian calls this a "do-ocracy") and SecOps can be seen as a control culture. To fulfill the promise of teaming for shared responsibility, DevOps and SecOps should align on three key objectives: collaboration, communication and integration.
Plan for Collaboration
The nature of DevOps is to marry dev and ops, including testing and support teams. The focus is on reducing time to market and improving agility through rapid development and rollouts. However, before the process of development can begin, you need to start with a plan. At the planning stage of development is where security and compliance can start to be incorporated.
To implement and orchestrate the SecOps portion of the development plan, organizations need to build a system of record. Policies and controls can be widely disseminated across
product and engineering teams to document the intention of controls, define their implementation and enable teams to collaborate with comments and feedback in one hub.
There's a comms failure between security and dev, and creating successful communications between the two is a critical necessity. Compliance and security can be viewed pejoratively by other teams because people don't understand them or see their relevance to users' lives. But this, too, can be changed.
When you talk about security risks, for example, a viable communication approach is to speak in terms of project delays and unplanned, unscheduled work rather than talking about a breach or a vulnerability. When speaking to operations teams, it's better to talk about availability and user privacy requirements as correlated with mean response time or system uptime rather than a data breach. To succeed in a world that's moving at the speed of DevOps, security groups need to be able to articulate control requirements in both the language and tools that DevOps lives in.
Learning to Work Together
In DevOps, there is necessarily a significant amount of automation and use of workflow tools, and that is often the most radical process departure for security practitioners. The key success factor for integrating security and DevOps is to make control implementation easy and clear for developers to follow. For example, if the team is working toward a SOC 2 security certification, then a clear control framework broken down into tasks and issues will ensure a smooth integration of security into the dev cycle. A SOC 2 attestation will also require evidentiary verification that controls are implemented throughout the software development lifecycle (SDLC), including release cadence. The final critical piece to achieving readiness for a security certification is to have integrated risk assessment, controls gap analysis and audit-ready evidence for your observation period in one central place.
The Marriage of Speed and Security
Today's model of continuous delivery requires the DevOps methodology, which relies on the speed that comes through automation. But security is sometimes overlooked in favor of speed. That means security needs to automate, as well, to keep pace with continuous delivery. DevOps and SecOps must unite to form DevSecOps.
Once organizations understand the many benefits that DevSecOps brings, a more enthusiastic transition to this model becomes possible. Teams will have more impetus to learn how to communicate with each other to achieve their common goal of continuous delivery that is speedy, compliant and safe.