I’m currently involved with a project that is creating a unique tool which is a Security Enforcing Function for a downstream suite of applications. As you might imagine, this is being developed primarily by a senior lead developer. He is very much an industry veteran. As is the way of things, post-Covid, we’ve never met. He resolutely refuses to switch his camera on, so we interact through audio only Teams calls.

I mention this, because its harder to be difficult with someone when you are face-to-face with them, more-so when in a room. Its still challenging to be difficult with someone when you can see them in a video call. Its much easier to be difficult with someone when they cannot see you (and you cannot see them and their reactions).

One such recent meeting entailed me being on the receiving end of a sustained rant about the organisation I work for tightening down the security posture of its development environment and resources. In the view of my interlocutor this was to the point where the organisation is effectively dumbing down its software development workforce.

This caused me to ponder a bit. The gist of the rant was that the nature of the security controls in place, for example hardened builds, control on network communications etc is preventing developers from experimenting.

My response went something along the lines of “that’s what sandbox development environments are for – where you can truly “knock yourself out”. But there is little utility in developing in an unhardened development environment, which subsequently fails (at worst) or is the cause of unnecessary risk when software is deployed into live.

Maybe the good old days this developer was hankering after have long gone – at least in big, regulated corporate environments…