First there came DevOps, in which processes between software development and IT teams were automated to speed up the building, testing, and release of software.
Then with bad actors using automated vulnerability-finding tools, eagle-eyed regulators closely watching for data breaches, and code breaking regularly, DevSecOps was next.
The DevSecOps practice or philosophy involves introducing security earlier in the life cycle of application development. Getting it right is not easy, however.
As John Yeoh, VP of research for the Cloud Security Alliance notes: “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. The result is a field ripe for picking by malicious parties across the world.”
Now in a new report the non-profit Cloud Security Alliance (CSA) emphasises six key pillars that must be considered by organisations, in a new DevSecOps guide.
DevSecOps Guide: Start with these Six Pillars
DevSecOps Pillar 1: Collective Responsibility
Security can’t be seen as someone else’s problem. Everyone has their own security responsibility and must be aware of their own contribution to the organization’s security stance. Edge users and developers need to be not just “security-aware” but recognised as the first line of defense
Content from our partners
The CSA accepts that: “The CSO (Cloud Security Officer) plays a leadership and shepherding role for information security within an organization, but each person has their own security responsibility and must be aware of their own contribution to the organization’s security stance.”
No doubt this means resourcing your team properly with security-savvy developers…
DevSecOps Pillar 2: Collaboration and Integration
For DevSecOps to become central to product builds, communication and collaboration has to be paramount.
“There is an enormous skill (knowledge) and talent (resources) gap in the software landscape across Development, Operations and Security, the CSA acknowledges. “Without pan-organization collaboration around implementing security, success is going to be limited. Security can only be achieved only through collaboration, not confrontation.”
DevSecOps Pillar 3: Pragmatic Implementation
Increasingly enterprises have a growing array of tools and fixes to pick from when they look at implementing application security into their software life cycles.
However, every life cycle differs, especially with regards to a project’s maturity, structure and processes deployed.
“Organizations often end up procuring procure tools and point solutions that are hard to deploy, harder to operationalize and eventually do not provide actionable insights that can help mitigate the true security risks. Organizations need to take a holistic view of the software lifecycle, their security needs, and the future state they want in order to choose platform solutions that offer a high degree of integrability.”
DevSecOps Pillar 4: Bridging Compliance and Development
Compliance can’t keep up with developers and this leads to some common issues. “The regulatory and compliance function is more interested in proof that there is a process in place than actually auditing each execution of that process. Most DevOps teams, on the other hand, believe that the proof is in the code, not in documenting the process.
“The key to addressing this gap between compliance and development 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.”
In short, you need to rethink and ideally automate compliance. On which note…
DevSecOps Pillar 5: Automation
Last month Brook Schoenfield, master security architect at pentesting specialist IOActive, told Computer Business Review that: “The essence of DevOps is automation. Failure to grasp a powerful shift towards automating most software builds and deploy mechanisms will cause development teams who have embraced DevOps to ignore security.”
As such automation should be a concern for two reasons; the first is that manual quality checks on coding is time consuming and labour intensive. Automated security brings increased efficiency, reduced workloads and a regular schedule of quality checks.
The CSA comments that: “Automated security checks may create new issues, such as build delays or failures, though these typically can be addressed by workflow improvements or semi-automated approaches. There is a saying in software development: if you do the same thing three times, it’s time to program it, and this applies squarely with Reflexive Security.”
DevSecOps Pillar 6: Measure, Monitor, Report and Action
You can’t manage what you can’t measure…
As the report notes: “Some of the most critical metrics to monitor in a DevSecOps environment are deployment frequency, vulnerability patch time, percentage code automatically tested, and automated tests per application. The results during software development as well as post-delivery must be measured, monitored, reported and acted upon by the right people at the right time (continuously) for DevSecOps to succeed.”
