Doing DevSecOps is hard – even the biggest, best funded organisations are still struggling to get the balance between speed of delivery and security right. In our experience, security functions still view DevSecOps as a technical challenge: but buying a suite of security tools does not make you secure.
Technology doesn’t transform industries, but technology wrapped in great business models does, and the same can be said for DevSecOps. The only way for DevSecOps to succeed in your organisation is to ensure every element of your business model is geared towards embedding security in your software development lifecycle (SDLC).
That is why you need to view and run your DevSecOps operations in the same way you view and run a business.
Every business has a business model
Business model is not only applicable to your ‘standard’ businesses offering widgets on the high street. Its simplicity and completeness means you can use it to describe how an internal business function, such as your cyber security function, should be organised.
A business model outlines what the value delivered by your business is and how the business will arrange itself in order to achieve that in a commercially viable way. It has 4 key elements:
- Customer Value Proposition: What customer challenge are you addressing? What does the offer look like? What channels are you selling through?
- Profit Formula: How does the offer result in a profit for the business? What are the costs? Where does the revenue come from?
- Key Resources: What are the key assets needed for the offering? People, tools, facilities, licenses etc.
- Key Processes: What are the operational and managerial processes which deliver value? What are your key performance measures?
Each of the four elements are interdependent – they need to be set up in a way that not only compliments the customer value proposition but enforces it. For example, Apple didn’t just introduce the iPod hardware. They realised the real value lay in creating an ecosystem of software (iTunes), hardware and services that allowed customers to download and listen to their favourite music. Mp3 players were nothing new when Apple launched the iPod, but Apple’s underlying business model definitely was- that’s what enabled them to revolutionise an industry.
The same goes for security: what risk is security addressing for the organisation?
Each element of the DevSecOps business model needs to be engineered to deliver value
Let’s investigate what the four elements of a DevSecOps enabling business model may look like. Bear in mind these are applicable whether you’re a one-person team in a start-up or part of a much larger enterprise level cyber security function.
Customer Value Proposition: the first thing to consider, and arguably the most important point in this entire article, is that you are in the business of delivering a service. As such, you should treat your customers: developers, product owners, architects etc. in the same way as paying customers of your software application.
Profit Formula: DevSecOps, and indeed security in general, is seen as a cost centre. It also doesn’t directly generate revenue, unless of course you’re awesome at it and sell consultancy services. This negative mindset makes it very difficult to demonstrate value and justify costly investments in tooling and training. Therefore, you need to show that the monetary value saved by fixing vulnerabilities sooner in the SDLC exceeds the costs associated with DevSecOps.
Key Resources: looking at the sheer number of advertised positions for DevSecOps experts indicates the key resource is skilled people. You can get around not having fancy CI/CD tooling by taking advantage of open source technology, but you cannot get around having nobody with expertise.
Key Processes: how you track and deliver value to your customers is defined by your operational procedures, and efforts to educate the workforce in DevSecOps. Be warned that there’s a lot of upfront work in creating standardised offerings to your customers (e.g. architectural patterns, Secure IaaC repository, coding guidance) as well as on-going tracking of KPIs.
All elements must be self-reinforcing to make a cohesive business model
As mentioned earlier, each element of the business model must reinforce the others. In the context of DevSecOps, a good example is ensuring that you have you have a mechanism for tracking the number of vulnerabilities at each stage of the SDLC- as part of your key processes. When this data is combined with an estimated time to remediate a vulnerability at each stage, you can then assign a monetary value to the cost of remediating vulnerabilities. Over time, as your customers use the services provided, you should be able to show that there are fewer vulnerabilities identified later in the SDLC (where it’s more expensive to remediate), and therefore the amount of money your business is saving- as part of the profit formula.
How can Capgemini help?
We combine our expertise in Strategy, Operating Models, Change Management and Benefits Realisation with technical expertise in Cyber Security to help our clients succeed in today’s digital world. For more guidance and content related to DevSecOps, and information on how to get in touch, please visit our landing page.
For a holistic view of how secure your DevOps is, take a quick but thorough survey benchmarking your DevSecOps maturity against peers, covering:
- Security blueprint and framework
- Culture, collaboration and education
- Security by design
- Agile risk analysis
- Risk-based security testing
- End-to-end monitoring
- Continuous security improvement.