“The CISO’s Guide for Implementing DevSecOps in the Enterprise” is a book offered by DevOn, an organization specialized in Agile and Lean Software Development practices and Agile transformations. In this book, they discuss the topic of DevSecOps with security leaders (mostly CISOs, but not only) in various organizations, the vast majority with large operations or originating from the Netherlands. In this review, I give my view on the book, coming from the perspective of a professional that encountered DevSecOps in client consulting engagements and encountered some of the same challenges as the industry leaders.

Overall rating: 4.5/5

What I liked about the book

1.The book is smartly-organized, starting with an introduction and a summary of the interviews. This allows the reader to quickly understand the consensus and diverging opinions on the main key elements asked in the interviews:

• Terminology: is it DevOps or DevSecOps? (I think security professionals love these discussions, just like they love to debate what qualifies as “cybersecurity”). In this article I will use “DevSecOps” as a more mature, performing approach, where security is adequately integrated in well-established “DevOps” practices.
• Challenges in a DevSecOps journey – ranging wildly and covering aspects such awareness, buy-in, tooling, and measurement.
• Approaches that worked for various organizations.

2.The book offers valuable tips for strategically (and sometimes practically) approaching the topic and starting the transformation. Putting the story of a leader in their organizational context (explained in each chapter, providing the insights for one organization) gives one confidence that professionals in similar organizations handled the same challenges, and inspires to strive for improvement in their own.

3.Perhaps the most important aspect highlighted by the book is that people are at the center of DevSecOps – security teams have limited resources and cannot practically be present to secure (or, more realistically, verify) the artefacts of the large number of DevOps and product teams. Cultural change is a common theme: increasing awareness, convincing of the benefits using tangible metrics, training people in various roles, all these measures are related to people. It does not come as a surprise that apart from highlighting their careers, in the bios of the interviewed security leaders we can find details about their personal lives, like their favorite pass times and life experiences. DevSecOps cannot occur without trust and collaboration.

What I disliked about the book

1.Most interviewed leaders agree that it is key to make DevSecOps tangible using data, however the coverage of this topic is minimal. In the summary chapter, relevant KPIs are mentioned briefly and in-short.

2.The leaders shied away from discussing how well the approaches they promote have benefited their organizations in a tangible, measurable way. On one hand, this can potentially be explained by secrecy and not trying to brag about their posture (some hackers will definitely be up for the challenge to test their claims) and by the fact that the book is offered for free. On the other hand, security continues to be a field with scarce resources and at times difficult timelines. No silver bullet exists for DevSecOps, as no silver bullet exists for security. However, as an industry, I feel the need to move towards more streamlined approaches that have been tested and proved to be effective, to create a safer digital space for all. This book is a step in the right direction, with quite some steps to go.

Highlights

I present here a highlighted idea from each of the interviewed leaders. The idea strokes me as practical, useful, or plain interesting. I try to retain these ideas in my arsenal in case the situation asks for them to be applied.

Martijn Dekker

Martijn mentions that any scaling of automation (relevant for large adoption) should include demonstrability – the ability to quickly show what was done, when, and with what results. I considered this a very important point, keeping in mind Martijn comes from a highly-regulated industry in the financial world, subject to numerous audits and regulator inspections.

Floor van Eijk

As Security Champions are mentioned throughout the book as a useful approach, Floor states that the early adopters, obvious candidates to become Security Champions, are rare and the majority of people are naturally averse to large-scale change. She proposes to get support from higher ranks in order to aid the DevSecOps journey despite this reality.

Willem van der Valk

While the obvious focus of DevSecOps has been to introduce security into DevOps, Willem advocates for more understanding of DevOps in the security world (for example for practices and concepts like pipelines). As both parties need to understand each other, this sheds light on an often-overlooked aspect: how can one evolve a function if they do not comprehend it? How can security demand their motivations are understood if they do not understand those of the DevOps roles?

Frans van Kessel

Frans provided me with a very practical action: including security in the standards for Definition of Done and Definition of Ready. The two definitions, common in Agile practices, are one aspect of “shifting left” and make security a consideration at a development task level, before reaching production.

Alexander Pabst

While the book presents mostly ideas about what can work, Alexander mentions failure as a mandatory part of the DevSecOps equation – everything can fail, from DevOps processes to security checks. When failures occur, naming, shaming, and punishment should not follow. Instead, the focus is placed on working together to learn from the past and improve.

Ard Westerik & Tom Moekotte

Ard & Tom capitalized on the structures of their environment: campaigns already started, teams that are ahead in terms of maturity, and forums such as monthly internal meetups with a technology focus. They found allies and introduced security as part of these on-going initiatives.

Ori Fragman

Ori suggested a new role that supports the DevSecOps practice – the Platform Security Officer, which are individuals that bridge the product, platform and security, reporting to the CISO. He sees the PSO as different than the Business Information Security Officer, with a broader skill set and less governance-focused.

Minatee Mishra

“Test fast, fail fast, & fix fast” is the mantra Minatee adopted in her organization. I liked this idea as it slightly shifts the mindset from prevention to actual resilience, a relevant topic nowadays when the Digital Operational Resilience Act (DORA) mandates organizations to maintain resilient operations.

Fred Jekel

Last but not least, Fred presented how his organization took a bold approach to use pen testing as the driver for DevSecOps, by finding defects and triggering cultural change as a reaction to them. He nurtured a culture where praise is given to the teams with the lowest number of defects and their practices used as examples throughout the organization.

Summary

“The CISO’s Guide for Implementing DevSecOps in the Enterprise” is a useful collection of ideas and thought leadership to inspire you to take action in your organization’s DevSecOps journey. In a easily accessible format, the chapters provide you with food for thought for what could work in your organization, leaving you the (hopefully rewarding) challenge of trial and error-ing in your specific context, with your people and culture. The book can be found online here .

NB: I am not affiliated with the authors and contributors of the book or any organization that they represent. Image credits belong to the authors of the book.