The State of DevOps report provides excellent insight through rigorous analysis of its wide reaching survey. The research provides evidence-based guidance to help focus on the capabilities that drive performance. One of those is Security. Why you might be interesting in this episode:
Or listen at:
Published: Wed, 09 Mar 2022 16:59:34 GMT
Links
Transcript
Hello, and welcome back to the Better ROI from Software Development podcast.
In the last few episodes, I've been looking at the State of DevOps report and what it says about some of the practises that can help us achieve better results.
In episode 120, I summarised the State of DevOps report.
In 121, I talked about what the report said about Cloud Computing.
In 122, I talked about what the report said about Documentation.
And in the last episode, 123, what it said about specific DevOps Technical Practises.
In this episode, I'll be taking a look at what the report says about Security and its advice on specific practises.
So why might this report be of interest to you?
Firstly, to understand the importance the report puts on security.
And secondly, the advice on how to get it right.
But first, the recap; if you've not listened to the last few episodes, I'll quickly recap DevOps and the State of DevOps report.
For DevOps, I like the Microsoft definition:.
"A compound of development (Dev) and operations (Ops), DevOps is the union of people, process, and technology to continually provide value to customers."
It's a marriage of traditionally opposing forces - innovation and change out of the development team - while stability and limiting change out of the operations team. DevOps focuses on the business outcomes that needs a mix of the two.
The State of DevOps report is in its seventh year, reporting on 32,000 professionals worldwide. Produced by the DORA Team (DevOps Research and Assessment), it's the longest running, academically rigorous research investigation of its kind.
For me, it provides clear evidence of the benefits of DevOps and its practises. But many of the practises are universal. So even if you're not officially doing DevOps, I still think they provide benefit.
One of the subjects receiving specific focus in report is Security.
Now, this isn't much of a surprise to me. Security is critically important. I've actually recently devoted 11 episodes to it (103-113), and it's likely to be a subject I revisit again in the future.
The report is keen to highlight the growing quantity and sophistication of security threats. Something that is only expected to grow and to gain greater focus from governing bodies.
I think it's safe to assume that the reputational damage and the fines are only going to grow for those organisations being caught out.
As such, the report highly recommends "shifting left" and integrating security throughout the software development process.
I discussed the idea of "shift left" in episode 119. Think of our traditional development process like a conveyor belt. Security would traditionally happened towards the end of the conveyor belt - if viewed from the side, towards the right end of the conveyor.
This is too late in the process. Similar to the theme running through many of the DevOps technical practises I talked about in the last episode, doing earlier is needed to produce better outcomes. We need to shift them left.
If you invest 24 months in a software product only to review for security at the end, don't be surprised to be given a large list of remedial actions you need to take to make it secure. Also, don't be surprised to find that list effectively requires the rewriting of much of your investment doing it earlier.
Embedding it in the development process allows for minor course corrections as you go. It may feel like you are progressing slower. But much better than to arrive at the entirely wrong destination and to have to repeat your journey.
The report recommends five practises to help get this right:.
- Test for Security
- Integrate Security Reviews into every phase
- Security Reviews
- Build Pre-Approved Code
- And Invite Information Security Staff early and often.
I'll start with Test for Security. I've talked many times about testing for the correctness of your software product, and this is the same thing just focussed on the security side.
There is a growing ecosystem of third party products to assist in this. Something that I might explore in future episodes again.
Automation is key here. By automating the task, you can have the confident it is done in a repeatable and reliable manner - and you have an audit trail of actions taken.
I would expect in the future, evidence of the quality and frequency of your testing will be taken into account during any fine calculations.
The report claims 58% of respondents are Testing for Security.
Next, Integrate Security Review into every phase. The report defines this as:
"Integrate information security (InfoSec) into the daily work of the entire software delivery lifecycle. This includes having the InfoSec team provide input during the design and architecture phases of the application, attend software demos, and provide feedback during demos."
Again, as I talked about in Documentation, use something similar to the Definition of Done found in the Scrum framework. Effectively a checklist of things that need to be completed to ensure that any development work is "done".
And they should be at the granular level - slices of functionality within the software product rather than at the end of the product creation. Otherwise, we run the risk of missing core course corrections early and then having to pay the price for them.
You will need to ask yourself how much of a diversion from that correct course can your organisation tolerate - and base the cadence of any security views on that.
The report claimed that 54% respondents are Integrating Security views into every phase.
Next, Security Reviews. The report defines this as:
"Conduct a security review for all major features."
Having a dedicated event can be hugely beneficial in focussing a team, even if they are performing security testing as part of the software development process. It can be useful to have a focussed review similar to Gamedays. I've previously suggested it allows us to ask the "What-If" questions. It allows us to take a step back and take another look at what we're doing. It is also an excellent opportunity to bring in additional expertise, be that from other teams or from third parties to get that fresh set of eyes.
The report claims 60% of respondents are doing Security Reviews.
Next Build Pre-Approved Code. Having an internally known good variety of libraries for a team can be useful. Firstly, to avoid repeating work, And secondly, to have confidence the security checks have already been done.
For larger organisations, it makes sense to have dedicated systems teams providing common secure libraries for other development teams - providing not just Pre-Approved Code but providing guidance, training and advice.
In smaller organisations, it may be a list of approved Open Source packages. The quality and the security of Open Source varies greatly. It can put considerable risk on an organisation to use third party code without any form of audit process, especially if it's not a well known package.
And it is then critical that any approved internal code or Open Source package has processes around them to regularly review and ensure any changes are picked up by the dependent teams quickly. It's not uncommon for security flaws to be found in previously approved safe code. Thus, we need to be reviewing on a regular basis to assess if any of our previously approved code is now no longer safe. And in those instances, we need to make sure that we have clear communication to those teams that have taken a reliance on that code, along with the risk and any remedial actions that they need to take.
I would, however, stress that having this set up, while may seem onerous, is preferable than every team investing in their own.
The report claims 60% of respondents are Building Pre-Approved Code.
And finally inviting Information Security Staff early and often.
You should be leveraging whatever security knowledge you have in your organisation. Some organisations will be big enough to have a dedicated information security team. But in many organisations, there has not been the investment to create a specialised team.
If that's your organisation, then I'd recommend creating a special interest group from across the business, a group that can meet, discuss and share security practises and then distil to the wider organisation.
I'd also recommend bringing in coaches and trainers to uplift that security knowledge.
And regardless of how the team is formed, a dedicated team or a cross-organisation special interest group, involve them early when starting new products. Use them to provide guidance and advice on how to build secure software. Use them to provide governance and identify gaps in reviews and demos.
But remember, their aim should be to empower and enable the software development teams to build secure systems.
The report claims 63% of respondents are inviting Information Security Staff early and often.
In this episode, I've given you a brief recap of DevOps and the state of DevOps report. I've reiterated the criticality of Security in your software development, both in terms of my own views and what the report advises, and I've talked through the five practises that the report recommends:
- Test for Security
- Integrate Security Reviews into every phase
- Security Reviews
- Build Pre-Approved Code
- And Invite Information Security Staff early and often.
In the next episode, I want to talk about what the report said about Culture - and what correlation it found in terms of how well teams did during the COVID-19 crisis.
Thank you for taking your time to listen to this podcast. I look forward to speaking to you again next week.