|In this longer blog post, I go over how I’ve finally come to think about what DevSecOps is.A summary of what the post covers:|
1. A secure software supply chain – This is a fancy way of saying “we know all the components that went into building and deploying this software and trust those components.” It also includes the actual CI/CD pipeline that you trust and that’s resistant to third parties including malicious code, as we’ve seen happen in recent years.
2. Improved culture and collaboration – Increasing collaboration and understanding between developers and security staff. As with many governance practices, with security, the governed (developers) and the governors (security staff) usually have an antagonistic relationship. Developers see security as unstoppable masters of “no,” and security people see developers as clueless coders. Well, that relationship isn’t helpful! As with DevOps, transforming “culture” to be more helpful is part of DevSecOps.
3. Automation and guardrails – Automating security policy enforcement, and providing defaults and templates to make it as easy as possible for developers to write secure code and applications configuration from the start. Historically, verifying that developers are writing secure code has been a manual, error-prone process. Much of this can be automated now with good platforms.
Read the rest!
I’ve proposed an open spaces for DevOpsDays Amsterdam, 2021. The idea is:
The DevOps community pushes for people to change how they think and operate. When it comes to working better, we have proven tools, techniques, and even big picture ways of thinking like CALMS. You’re more than likely eager to try these new things, get better, change. However, many more people seem less than eager to change – your co-workers, managers, and the countless “others” in your organization. In the discussions I have with change agents and executives in large organizations, this reluctance to change is one of the top three concerning topics. I invite you to this discussion to talk about why people are reluctant to change, how you’ve worked helped people change, or, perhaps given up, and, hopefully, to share stories about your own experience overcoming reluctance. Our goal will be to move beyond being frustrated with “frozen” minds and middles, and get a sense for what to do about it…if anything. To start the discussion, I’ll start with a few stories and methods for getting people to change that I’ve encountered in the past few years.Me!
In preparing for it, I typed in these notes:
Reluctance to change is one of the top concerns with executives and managers I talk with.
- Frozen middle, frozen minds – often means “I don’t like what they’re (not) doing” – is that kind?
- I want to talk about why people are reluctant to change; why you are; stories of success and failure in changing people’s minds, desires, and behavior/action.
- Examples to start with:
- Constant Planning, or, Analysis paralysis – they want to change, but think too much and don’t act. Fix: external problem/urgency, like (sadly) COVID, competition, dying/plateaued cash cow (not a very good motivator).
- Fear of change – demonstrate that it works.
- Seems like more work, or, won’t make their lives better, so why change? Show them that it make their lives better – automating things frees you up from tedium; automating for auditors saves them over-time; the new way can be more secure.
- Changing job/responsibilities/identity. The DBA likes being the DBA, the network admin likes that – prove to them that it’s better.
- Fear that they can’t change/learn the new thing – Coté doesn’t get around to learning Dutch, same fear. Related: embarrassment, e.g., Coté doesn’t buy from the butcher down the street cause he don’t speak Dutch (but, butcher doesn’t care – OF COURSE!) Fix: hard one, show success from peers.
- General fix for all of this: build up success stories of their peers doing it.
- Change motivations:
- like money;
- flow – removing friction (better quality of life and work-life);
- raising individual profile with OSS work/fame;
- closer to end-user to see value they provide.
- Change structure. “Culture follows structure” – Larman’s Law – points out a common pattern/behavior. Once you know the behavior, you can start thinking about how to change/improve it.
- “the organizational system (groups, teams, roles and responsibilities, hierarchies, career paths, policies, measurement and reward mechanisms, etc)”
You can also see me discuss these in one of my Tanzu Talk streams.