Do you think orgs are shifting right on purpose

Last week I was asked by Davey Winder, a reporter, if it is possible that companies are now “shifting right” instead of “shifting left” to move the efforts of security from the developers to the SOC and Incident Response teams.
He based his questions on two recent sources:

My answer was that I cannot believe it is done intentionally, and that are other reasons, mainly around developers’ knowledge and priority that make it look like a “shift right” trend.
I’ll be happy to hear what others think.

The published article can be found here:

That’s a really interesting hypothesis.

I hadn’t thought of that before and while I agree with you that I can’t imagine this is intentional at this point, it’s certainly interesting food for thought and a good mental exercise to think through.

Thanks for sharing a cool article. I’m curious to hear what others think.

As a developer who has fought countless up-hill battles to fix critical security, stability, and performance issues in lieu of feature delivery, there is truth about the pressure to deliver features in lieu of security. The problem is there is often no “eye candy” for stakeholders to see when evaluating progress on getting the features they want if time is spent on the code internals fixing a security issue. Most stakeholders don’t ask for security as a feature; it usually comes as a non-functional requirement if it is even considered.

Stakeholders are often not technical enough to understand the security issue or foresee the crisis that comes with detecting and fixing an issue post-deployment. Their goal is to deliver features that work - period. Did it work in the sprint demo? Yes: check the box, ship it!

I’ve observed that in many cases the stakeholders, having a successful product delivery, are immediately promoted away from the project. When an issue is discovered, the original stakeholders that did not allow for fixes are long gone. Some of the devs usually stay around for a while; they are the ones that will be blamed when the product falls over in production or a vulnerability is discovered.

If you’ve ever noticed a mass-exodus of devs aligning with a product delivery, this could almost be a KPI of the technical problems they foresee based on what they were prevented from fixing.

I always thought a logical approach would be to base the career paths of stakeholders on several releases spanning the useful life of the software. Delivering something that worked during the sprint demos and something that can continuously provide high-value, low-risk to the business over 3 - 5 years are completely different input criteria for assessing stakeholder career advancement.


That is a very interesting question and I found your answer to be very solid. That being said, I think this like many things… this is experiencing the momentum you see with the pendulum effect.

a law, discovered by Galileo in 1602, that describes the regular, swinging motion of a pendulum by the action of gravity and acquired momentum. the theory holding that trends in culture, politics, etc., tend to swing back and forth between opposite extremes.

We have seen this same shift back and forth with client side code vs server side code. Example being mainframes and dumb terminals where literally everything short of the input from the keyboard was server side. Then fat clients came around and very little was done on the server until the shift back to the server took place as client-server transitioned to basic web browser input. The Web 2.0 matured and now more and more of that logic is shifting back to the client.

I see the same trend happening in shift-left vs shift-right, but it will eventually settle somewhere in the middle shared between security teams and developers.

1 Like