[raxxorraxor]

I don't think it boring. Most of the time developers need to justify security so that would be a good change. Security needs to be part of planning and architecture considerations. Depending on the project this can be extensive or not.

This is also an all around topic for the company offering software services (not only software companies). Especially if the cloud becomes part of your infrastructure, you also might want to have subnets, server certificates and sharpened firewall rules in your internal network if you have fairly open routes to infrastructure not hosted on premise. Formerly these things are neglected for internal networks, although this would also be helpful to defend against some attacks like ransomware. It is of course a cost factor and becomes almost impossible task if you exclusively rely on external IT.

The latter part can be annoying for developers, because they often have to work their way around MITM-firewalls, download rules and other security mechanisms for development. This often creates conflict between developers and security. But not really when they have to implement security mechanisms themselves.

[caloique]

Thanks for the insights, have you seen any good practice (tips) on how 'security mechanisms for development' could actually help security teams and developers work smoothly? Instead of being the reason for conflict.

[raxxorraxor]

I think the most trivial mechanism is to have your own subnet for developers that maybe has fewer restrictions. Not really a DMZ, but perhaps skip deep package inspections. Most tools can be configured to allow self-signed certs, but it is still a lot of hassle, especially for test systems. In exchange the dev subnet should only have restricted access to the rest of the internal network. But lacking convenience here is preferable to not being able to download some dependencies.