"Shift Left (and leave)" versus "Shift Left (and stay)"

Developers don't want you shifting left all over them.

Only 22% of software developers say they have a clear understanding of what they need to do to comply with security policy, to make sure the applications they're writing for their organization, are good in a security sense.

Now, it'd be easy to say the developers are just dopes and they don't know what they're up to. But I think what this is indicating is that figuring out how to practically do security policy at the software layer is difficult.

And that's where this concept of “shift left” comes in.

The idea of shift left comes the Extreme Programming and agile world where you are bringing unit testing closer to developers, and then from DevOps where you’re doing the same with automation and configuration, and even releasing and managing software.

You're bringing it all of that “left” into the application lifecycle, close to when the app code is being written.

That kind of literally makes sense. But nowadays, when you start hearing about shift left for security, that shouldn’t mean having the developers take on even more responsibilities.

If only 22% of them even know what they should be doing, you should probably not ask them to do security things. My colleague Darran recently called this “shift left and leave.” Instead, I think you need to “shift left and stay.”

What shift left means in a security and compliance context nowadays is moving your security and compliance activities closer to that part of the application lifecycle, where the coding is actually done.

What this often means is automating a lot of the checks, and also enforcing a lot of the compliance you have. You do this by using things like default templates and setting up for your developers to take full advantage of how cloud native architectures let you split up and divide things. Darran and I discussed what that means in our talk today.

There's another thing that Richard Seroter, mentioned recently, which is the idea of “shifting down,” which is to say, if you have the opportunity to just build something like security and compliance into the platform, to just remove it from anyone's concern, you should definitely focus on that. As analogies, you can think about at a very basic layer like file services, networking, even the way that UIs are rendered on screens. All of these have been “shifted down” into the stacks that app developers use. This was not always the case!

So if you're thinking about shifting security left - which people sometimes talk about is “DevSecOps” or even “secure software supply chains” - don't assume that means having your developers do a lot of work. Remember: only about 22% of them really know what that means!

Instead think about how you can go back into the application lifecycle and add security earlier in the application lifecycle. There’s a lot of new capabilities you’ll have if you’re using cloud native architectures, platforms, and thinking.

Relative to your interests

• In the face of volatility, CFOs—and their organizations—adapt- Belt-tightening watch. Lots of micromanagement and management by finance metrics ahead: “In the year ahead, CFOs plan to increase their focus on operational value drivers, management of KPIs, cash management, and capital structure. Other priorities have decreased in importance since Q3 2022.”

• IBM takes on AWS, Google, and Microsoft with Watsonx - If it works, and also, it lets enterprises build up huge, custom trained models, and it has enough governance controls, it’d be a big deal for IBM. They key things learned from ChatGPT is that it has to be super easy, frictionless to get started with. That’s difficult for enterprises software makers, and it’s also hindered by governance, access control, and pricing per seat and data access. To be valuable to individuals, a company will need to put as much of their data into their models as possible. If you’re just querying your own email and files, it won’t be impressive enough to show long-term value to individuals. And if you restrict the model to just a handful of people (as is done with most corporate data), then it also will be hard to show long-term value. This will freak out security people and lawyers. Back in the 2000’s when file sharing in enterprises (like SharePoint and intranet search) became popular, there was a wave of people freaking out that previously hidden in plain sight documents were now findable.

• Beware the Digital Whiteboard - The assertion: writing with whiteboarding/Sticky notes is not good, and can lead to leaky abstractions. Seem more like a “right tool for the job” thing, plus the usual garbage in, garbage out, regardless of the tool used to process the garbage.

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

July 19th Improving FinTech with cloud native think, speaking. July 19th Stop Tech Debt and Start Using Faster, More Secure Paths to Production. August 21st to 24th SpringOne & VMware Explore US, in Las Vegas. Sep 6th to 7th DevOpsDays Des Moines, speaking. Sep 13th, stackconf, Berlin. Sep 14th to 15th SREday, London, speaking Sep 18th to 19th SHIFT in Zadar, speaking. Oct 3rd Enterprise DevOps Techron, Utrecht, speaking

Midjourney: by eugene dillon art, california, 1975, in the style of colorfully abstracted faces, mosaic-like composition, earthy expressionism, ndebele art, quiet moments captured in paint, juxtaposed figures, fragmented planes

Logoff

I’m writing the MC script for our upcoming SpringOne conference keynote session, it’s part of VMware Explore this year. And I’ll be co-MC’ing it as well. Writing a script like this is fun, and unique, sort of. I wrote the MC script for last year’s keynote session and did some work on other talks.

For an MC script, you have tiny slices of time between talks where you follow a pretty basic format: (1) wow, how about that!, and, (2) here’s what’s coming next! I joke around, there, but part one of the main things MC’es need to to is really clarify and distill what you just saw: they’re like the little marginalia, dog ears, or sticky notes you put in a book to remember what you just read. They also prime you for what’s coming next, kind of clearing your brain out.

And, as a writer, there’s the opportunity to throw in a couple of fun easter eggs. I snuck two into last year’s SpringOne MC script.

There’s also lots of “house keeping.” For example, at the end, you tell people when and where the free drinks and snacks party is.

I don’t write scripts much, at all, so doing that in the past few years has been something new to learn. Also, for the last SpringOne I worked on our CEO’s talk, which was especially educational. It’s interesting to put yourself in the head of someone else by learning their presentation style, mixing it in with what you know they like talking about and that they can talk about well, putting in the company strategy and then adding your own perspective and, like, “spin” on it.

Then you see (as with the CEO and the two MCs) them present it, and you close out a very educational feedback loop. For example, I know Josh’s speaking style, his joke style - his overall style - well. So often when I was writing his lines I could hear him saying them and even see the way he’d be moving. This, of course, guides what you write, how you edit it and polish it, and so forth. Also, I saw much of the raw recordings for the talks as people were doing them. This was an unexpected writing treat because you could see what people tripped on with delivery (they’d re-record it or reword it) and otherwise observe how it “works.” I, of course, read and performed each of the scripts I wrote out-loud to myself, but seeing the actual, uh, “actors” figure out the delivery is another level of feedback.

(I write all of this because, as you might be guessing, that MC script is what I really should be working on instead of telling you about how to work on a script.)

Anyhow! You should come to SpringOne this year to see it all gel together :)