Is Shift Left Really Rusty in Cybersecurity?

I sent my colleague Richard Isenberg an otter pup to live in Atlanta with him, given his team's stellar session on "Prioritizing Technology Risks" at McKinsey & Company 's recent #Cloud Leadership Forum. I am not sure this is wise.

- Sherman is named after the great Union general, but Rich addresses him as the "Shermanator," after a character in <checks notes> the "American Pie" series of movies

- Rich lets the otter spend most of his time hanging out by the pool in his backyard, drinking wine.

Perhaps Rich should encourage the young otter the read more about #cybersecurity? (I'm getting better at transitions?)

Chris H. recently published an issue of "Resilient Cyber" in which he asked some interesting questions about #Shiftleft -- even though I think I disagree with some of this conclusion

1. Is Shift Left based on a misapprehension?

Shift left aims to eliminate cybersecurity vulnerabilities as early as possible in the development or engineering lifecycle. He does yeoman work calling into question some of the factoid that get tossed around justifying shift left. God save the enterprise technology world from catchy factoids, but I don't think he debunks the concept.

• Shift left long predates its association with cybersecurity. Two decades ago we sought apply "shift left" optimizing end user support in #infrastructure organizations. Why? Because you could resolve a help desk ticket less for less than $20 and a deskside visit cost more than $75.
• I'm as much of a quantitive empiricist as the next fella, but sometimes experience matters. Any of us who ever written any code know you want to catch flaws -- we all have the sleepless nights to prove the point.
• I wouldn't fuss about the challenge in quantifying the benefits of shift left -- quantifying anything in application development is a tough proposition (but we are working on it).

2. Does Shift Left prevent #cyberattacks that diminish market value?

• Yes, the linkage between cyberattacks and share price is tenuous
• Many of the biggest public attacks involve #PII theft from B2C business. No this doesn't punish equity values. Most consumers are pretty "cheap and cheerful" when it comes to their customer data. B2C customers not so much, as any one who has sat through the security review for a provider of IT outsourcing or group health benefits will tell you.
• And that doesn't even get us to questions of ransomware or cyber-espionage (which the implications may only surface years later).
• In any event, the relationship between cyberattacks and business value is a question for the cybersecurity domain as a whole -- it's not specific to shift left

3. Has the implementation of shift left been too tool-centric?

- Hell, yes. Hell, yes -- just like everything else in cybersecurity

- Hughes refers positively to #threatmodelling. I would argue that threat modelling is step one in shift left, with teaching developers to write better code being step 2.

- I recommend Stephen Biddle's book "Military Power: Explaining Victory and Defeat in Modern Battle" so often that people joke about it, but better "force employment" will almost always beat better weapons.

4. Does Shift Left degrade developer experience?

• Sometimes it sure as hell does. Hughes points out that security teams overload #CICD pipelines with poorly integrated #SAST and #SCA tools -- and that happens frequently.
• But it doesn't happen always -- and we've seen plenty of instances where security teams have partnered with their #applicationdevelopment colleagues to design for #devex in deploying security tool in support of shift left principles.

What have other experiences with shift left been?