Bolting Security on to DevOps Without Full Integration is Little More Than Keeping Security in its Own Separate Silo
The argument for including security within DevOps has largely been won. It is the basis of security by design, and the most effective way of minimizing dormant app vulnerabilities from the huge number of software developments generated in the modern containerized cloud world.
“The security risks inherent in today’s intricate interactions between multiple technology layers, coupled with the globally interconnected and always-on nature of today’s applications, have been compounded by vulnerabilities lying dormant in systems, software, and hardware,” says John Yeoh, VP of research for the Cloud Security Alliance (CSA). “The result is a field ripe for picking by malicious parties across the world.”
The solution is to expand from DevOps to DevSecOps; but achieving a genuine DevSecOps environment is not easy. Speed in code generation (DevOps) is a different requirement to security in code generation, and one can hinder the other. Simply bolting security on to DevOps without full integration is little more than keeping security in its own separate silo.
To define and roadmap what is necessary to develop effective DevSecOps, the CSA is proposing ‘The Six Pillars of DevSecOps’ (PDF). The purpose is “to provide a holistic framework that blends the traditionally siloed operations: development, infrastructure operations, and information security, into a cohesive group that facilitates creation of secure software.”
CSA’s six pillars are: collective responsibility; collaboration and integration; pragmatic implementation; bridging compliance and development; automation; and measure, monitor, report and action.
Collective responsibility is about changing the corporate mindset. “Security must no longer be seen as someone else’s responsibility,” says the CSA. “Everyone is responsible for the security stance of the organization.” This involves making security part of the company’s fundamental business objectives. From this starting point, security becomes a natural part of DevOps and the transition to full DevSecOps a more natural process.
From collective responsibility, collaboration and integration becomes natural. “Security can only be achieved only through collaboration, not confrontation,” warns the CSA. Confrontation leads to human error which is the cause of most security incidents; collaboration minimizes it.
Pragmatic implementation involves choosing the right tools for the job. There are many tools and solutions for implementing application security within software lifecycles, but, says the CSA, “since every lifecycle is different in terms of structure, processes and overall maturity, there is no one-size-fits-all set of tools to implement DevSecOps.”
It recommends using a framework agnostic security and privacy model focused on application development. “This model,” it suggests, “will fulfill the unmet need of connecting all the stakeholders (development, operations, and security) in a manner such that security is built into applications and the software lifecycle that produces applications.”
Bridging compliance and development has become necessary because the rapid evolution of development processes and practices have meant that compliance and agile development are no longer aligned. Compliance is not an option; it is a requirement. The solution, says the CSA, “is to identify applicable controls, translating them to appropriate software measures and identifying inflection points within the software lifecycle where these controls can be automated and measured to improve the quality of risk mitigation and therefore compliance.”
Automation increases speed and eliminates human error — which are fundamental to the purpose of DevSecOps. “Manual deployment and patching practices can result in insecure software being released to production,” warns the CSA. In fact, the CSA believes so strongly in automated testing that it says, “Processes that can be automated should be automated, and those that can’t should be automated as much as possible or be considered for elimination.”
One of the by-products of automation is often the automated generation of results that can be combined into meaningful metrics. This is the CSA’s sixth pillar: measure, monitor, report and action. “Typical DevSecOps initiatives can take anywhere from months to years to implement depending on scope and complexity. Without actionable metrics, progress cannot be measured and failures cannot be detected in a timely manner.”
It suggests that the most important metrics to monitor in a DevSecOps environment are deployment frequency, vulnerability patch time, percentage code automatically tested, and automated tests per application. This applies both during development and after delivery, and the results must be “acted upon by the right people at the right time (continuously) for DevSecOps to succeed.”
Using these six pillars to both implement and operate DevSecOps will lead to an effective DevSecOps environment, says the CSA. It intends to expand on each pillar in the future.
Related: Security Shifts Left to be Part of Software Development Best Practice: Report
Related: Shifting to DevSecOps Is as Much About Culture as Tech and Methodology
Related: SecOps: The Roadkill Victim of DevOps’ Need for Speed
