In BigCorps, if there's a stupid requirement, there's usually a reason for the stupid requirement to be there in the first place but getting to the reason might require un-peeling a few org layers to since the people enforcing the policy will not be the people who wrote the policy. A more productive use of time would be to understand the reason for the policy, document out why it doesn't apply to your case and then attempt to get approval.
For instance, there's a restriction at my workplace (not a software company, a regular old industry fortune 500) which prevents git installs from pushing to any non corporate GitHub repo from our work machines.
The obvious reason it exists is to prevent people (a lot of who are analysts or data scientists - not professional programmers) from shooting themselves in the foot by pushing code to their personal repos in error.
It's annoying to work around if you need to say push a contribution to an open source project and you could rage at the infosec for enforcing it - but it obviously exists because stupid errors would have happened.
For instance, there's a restriction at my workplace (not a software company, a regular old industry fortune 500) which prevents git installs from pushing to any non corporate GitHub repo from our work machines.
The obvious reason it exists is to prevent people (a lot of who are analysts or data scientists - not professional programmers) from shooting themselves in the foot by pushing code to their personal repos in error.
It's annoying to work around if you need to say push a contribution to an open source project and you could rage at the infosec for enforcing it - but it obviously exists because stupid errors would have happened.
This principle is also called Chesterton's fence
https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fen...