As a Solution Architect here at xMatters, an Everbridge Company, and through my 30-year career in the IT industry, I’ve seen many frameworks offering bold new ideas. CMMI, ITIL, Prince 2, Agile, Scrum, and most recently, DevOps. These frameworks come and go, offering huge improvements in the way we deliver and manage our IT capabilities, but never lasting long enough to act on those promises.

That’s not to say they haven’t made a marked difference in the IT space, or that they haven’t been hugely impactful for organizations around the globe. They become launching off points for a new framework, and now there’s a new term that’s appeared, DevSecOps.

Is this just another framework that will come and go? Promise so much, but not deliver? Well, that’s down to us.

What is DevSecOps?

To provide a definition of DevSecOps that is true for everyone would be misleading. DevSecOps means something slightly different to everyone, it’s unique to the people who use it. So instead of asking “what is DevSecOps?” instead we should be asking, why?

Why DevSecOps?

Why demands of us one answer, the value of DevSecOps. Why should we implement DevSecOps? Why is it important to me, you, our customers, and our businesses? There are two key reasons.

1. Reducing Risk

Reducing risk comes from the ability to close the gap between security, business, and IT. Instead of focusing on a static set of rules that we must follow, DevSecOps focuses on risk awareness and creating an action plan for integrating security early and frequently. This approach often has proven business results and is easier to implement for all businesses because of its flexibility.

It also reduces risk through an iterative approach. This means dealing with the high-risk elements right away, the moment we identify something that’s of extreme risk to our organizations, we face it head-on.

2. Creating Trust

At the end of the day, we’re responsible for protecting corporate and personal data. Customers need to have trust in our processes to protect their data, and one of the ways we can do that is through visibility. By transparently showing that you’re GDPR secure, or have specific ISO certifications, and the means in how you’ve done those things.

There’s an oxymoron that with security comes secrecy, but it’s through openness and sharing that we can improve security in a DevSecOps world.

What DevSecOps is Not

It’s important to know what DevSecOps is not, so let’s bust a few myths.

1. DevSecOps is not about applying more layers of security. In truth, DevSecOps must remain lean and not add additional toil or work in the chain.
2. DevSecOps is not establishing a dedicated security team (that would be creating another silo, see point #1 above). In truth, it’s about a collaborative approach of including security into teams to help shift the way we think.
3. DevSecOps is not a big transformation project. Any transformation should be made based on an iterative, risk-based backlog
4. DevSecOps is not compromising ROI. Too often, implementing security is seen as an additional cost. But, implementing security should add value, not remove it.

The CALMS method

The CALMS framework is an important basis for DevOps, put forward originally by Jez Humble and his peers, and it applies just as much to DevSecOps.

Culture – is what underpins everything around DevOps. It’s about inclusion, having a safe environment, a collaborative organization without siloed walls. And it’s true still when you include security, having a safe environment where people can question, test, and innovate around security.

Automation – the automation of security in testing and delivering monitoring systems through observability. This is extremely important, and one of the easier elements to implement, but must be done in tandem with all of the other elements.

Lean IT – we should be considering how we deliver securely and implement built-in security through a value stream. because security must be considered as part of our business value.”

Measurement – this is about applying security scorecards. It’s also about measuring risk, we discussed previously having a backlog and working on the high-risk priority items first, and we determine those through measuring risk.

Sharing – sharing those identified risks, sharing them across the organization so we’re ensuring our entire enterprise is safe. It’s also about sharing resolutions, how we can prevent those kinds of issues. Most important, it’s about sharing potential issues and threats.

There are two headline principles that we can adopt with this framework in mind; they’re not mutually exclusive, but should be considered in combination – Proactive, shift-left, and Reactive, shift-right.

Proactive, Shift-left

In terms of DevSecOps, this means applying proactive service management principles to the software delivery lifecycle. In other words, prevention.

Culture

• Default inclusion of security is part of a requirement
• Product managers and engineers should be constantly challenged
• End-user empathy to services
• All elements targeted by ethical hackers
• Manual ethical hacking approach to innovation

Automation

• Inclusion of security in CI/CD pipeline
• SAST (statistical analysis)
• DAST (dynamic analysis)
• Security code coverage analysis
• Digitally signed secure repositories for built binaries
• Penetration tests
• Smoke tests

Lean

• Security inclusive definitions
• Security inclusive designs
• Security inclusive engineering
• Security inclusive testing
• Security inclusive deployments

Reactive, shift-right

In terms of DevSecOps, reactive shift-right is about applying service delivery principles into service management. This is about Cure using agile detection and correction.

Culture

• Consider a mindset of ‘No fortress is impregnable’
• Production smoke testing from “time zero” as part of monitoring/observability
• Chaos engineering approach to prod and non-prod
• Root cause analysis with data captured in real-time

Automation

• Continuous security monitoring of prod and non-prod
• Chaos engineering including automated security testing of production environments

Lean

• Treating major incident management as a value stream – every second counts!
• Response times to stopping an attack
• Response times for return to value
• Feedback to engineering for future prevention and technical debt

Common

While culture, automation, and lean IT are applied differently in shift-left or shift-right, measurement and sharing are applied to both in the same manner.

Measurement

• Security professionals to determine measures, such as from regulatory requirements, e.g. GDPR
• Measurements of both prod and non-prod
• Definition of security as part of business value and success criteria
• Security scorecards, updated in real-time

Sharing

• All parts of the organization should consider themselves responsible for security
• Autonomous ability to identify and implement security
• In the event of an attack; a security-led damage analysis team, supported by IT, must run in parallel to an IT-led remediation team, supported by security
• Empowerment by leadership with share accountability in a safe environment; red team vs blue team functions; security drills

Conclusion

At the start of this article, I commented that the success of a DevSecOps framework is down to us. I am hoping that in looking at these principles you are seeing that they require a commitment at all levels of any organization and all roles. Everyone has a responsibility for security, especially if security is to be taken seriously and considered as a built-in business value that must be delivered. Only by being committed and collaborative can we truly hope to be successful in preserving that most precious of commodities for our customers – their data.