In the environments I’ve worked in it was always a battle between IT and the programming staff.

I once had to deal with a homebrew worm because one of the devs wanted more compute power and took over the network.

A lot of people assume IT and developers are cut of the same cloth but the professions are quite different.

Developers tend to install a lot of little things (without any research into the trustworthiness of those things), that then never get patched and lead to an ungodly pile of detected vulnerabilities to clean up.

From an enterprise security perspective you want to operate with a least privilege model. For developers who need admin access this is typically granted through some just-in-time temporary elevation process, but many developers who are writing code and pushing builds through a devops CICD pipeline may not need admin to do their jobs.

It’s a liability and risk concern. If something were to happen (and this is guaranteed to happen eventually) you want to operate with the lowest privileges that you can to reduce the potential damage. This can be a mental health issue, a disgruntled employee or a simple accident that leads to compromise of company data and systems. For the same reason you don’t want to run every single application as administrator, you don’t want every employee to be an administrator at all times.

That said, with a good company, it’s not that difficult to get the access that you need provided that you have a legitimate use case. As a developer, I have a script I can run to give myself full administrative privileges at any time. Think of it as a safety on a firearm to ensure it’s being used deliberately. Even then, I don’t have access to the same documents that HR does because I don’t have a reason to know everyone’s data. And personally, I don’t want to have access to everything. If there were to be an incident (again, with infinite time it will happen eventually to somebody), I could become involved simply because I had access or knowledge. In many cases it could be grounds for termination if I should have known some information and did not act on this data in a timely manner. As I gain more experience I learn it’s often better not to have access to information without cause. It is against everybody’s interests.

I work in software at a large corpo and I don’t normally have access to install anything that doesn’t come from the company’s internal repository of third party apps.

But there is a pre installed app on my laptop that i can use to get temporary admin access for my laptop in a few seconds. But while the temporary admin access is on, everything I do gets logged for accountability. I’ve used this temp admin before for setting some environment variables.

Most things I work on happen in a big cloud provider (AWS, GCP, Azure, etc.) and the role I have access to on our cloud provider account has very limited privileges (esp in prod). Adding a new privilege to the role needs to go through two rounds of peer review + one round of manager review.

I simply thought that employees in the software industry were essentially at equal parity in terms of their departments

Oh boy that would be a nightmare.

Don’t get me wrong, I can easily imagine a working environment where everyone is a professional and everyone is making well reasoned responsible decisions with their hardware. Such workplaces exist.

But in reality there are any number of reasons why individual workers shouldn’t have unlimited access to their machines or others in the pipeline. I’ve worked mostly in corporate (financial) software environments, but many of these things apply to all workplaces though many places will be far more relaxed (or disorganised)

A few off the top of my head:

Data loss - irrespective of who anyone is, they shouldn’t be able to plug removable media into a machine and download the production database without being noticed. Likewise, for everyone’s safety, no-one should be able to plug a usb stick they found into a machine connected to the network. Exceptions can be sought, and granted, as part of an audited process. Anecdote: I worked one place where we were due to continue working over the weekend and a business analyst took client data home with them on an unencrypted usb stick.

Verified software - people shouldn’t be able to download and execute whatever they feel like as this offers a huge attack surface. Many companies maintain a list of verified software and install this centrally rather than allowing people (even developers) to download it and install it themselves. Again exceptions can be granted. Anecdote: one place I worked, an member of the infrastructure team had installed bitcoin miners on company servers.

Stability - developers generally do not have access to the production environment, running deployments is the responsibility of a dedicated team, this is because the temptation to meddle when in a pressured situation is too great. Anecdote - at one bank I worked at I made a mistake in a package of changes I’d prepared. The person running deployment came and told me and - because of a particularly time sensitive issue - we went and figured out the issue at the point of production deployment and fixed it manually. This worked but was exceptionally irresponsible. At a different place I worked, early in my career, I made a similar hacky fix and took down the public website of a major UK utility provider for several days

Quality - the software development process has many checks and balances between areas of expertise designed to bring out the best even if it’s more frustrating getting there. Want to change the indexes on the DB? Got to convince the DB admin that it’s the right thing to do, can’t just do it myself. Want to close that ticket that’s way overdue? Can’t unless QA / testing approved else I’m just marking my own work. Want to make changes in the integrated dev environment because that’s far easier that developing against the out of date mocks in my own sandbox? Nope. Want to expose a new endpoint for my services to talk to unilaterally? Nope, need architectural sign off, network security signoff, and the infrastructure team. Anecdote: All of these have been areas where I, a reasonably skilled developer, would have compromised in various points in my career when my back was against the wall and I was under pressure to deliver.

Some corporate environments can be suffocating, other software places can be so lax as to be alarming. In my experience there’s a sensible balance in the middle and the best places to work have been where management is sensitive and reactive to the needs of developers to get the job done in as reasonably a safe way as possible.

Even if people working in the field know, what is safe and what not, it does not mean, that the company, product or customer is safe, too.

First, if something goes wrong, you need to prove, that everyone did the right things. This is difficult of everyone had unrestricted access to everything. Think of a company with thousands of workers…

Second, if everyone has access rights, hacking one account of a company means, that the hacker has access to everything too.

Third, not everyone is always doing everything in good intent. If someone has been fired, they might be angry and just delete the most important files.

Fourth, mistakes happen.

It’s always better to be safe than sorry. Many Software devs can be trusted to not do anything too stupid with their machines, but every person has blind spots and can be tricked. At the company I work at, the IT system is pretty permissive at what can and can’t be done, but the Admins do block installing programs that ask for too many permissions under the hood (like some custom drivers and things that want console access) or that simply aren’t allowed due to company policy (i.e. Postman, because it just sends too much information to the cloud). Even a well-meaning dev usually isn’t aware of all the details of a program they want to install or the company policies - there are too many to reasonably know at all times. So it’s easier to block stuff, and if someone really does need something they just ask and get it unblocked for themselves.

You can also never be sure that a dev isn’t doing anything malicious. Of course that’s rare, but when it happens the damage to all company projects is just too large.

It’s also not much of a hierarchy thing, the Admins are on exactly the same level as devs, their job is just a bit different.

Can’t speak for everyone, but being root/Admin on a computer come with dangers, one of them being security. Beyond that I, there are also individuals that don’t want to or don’t have the time to learn skills that aren’t strictly necessary for their job.

It is a mix of ignorance, control, fear, and compliance. In finance in particular, insider threats are a real thing and it leads to the exact kinds of situations you’re describing. The cognitive dissonance of trusting someone enough to pay them a salary and deploy code to production (after peer verification), but not trusting them enough to manually touch a database is real. And it is the result of mitigating company risks, and following laws and regulations. No, it doesn’t make any sense. Yes, it should all be aligned, but you know, humans. All of that said, sometimes people do dumb things unintentionally, and the controls are there to mitigate those instances, too. Ultimately, you just deal with the bullshit because fighting it does no one any good. The powers that be only care about making money. And if you, peon developer, need to jump through a bunch of bullshit hoops in order to do your job, management doesn’t give a shit. That is what they are paying you for, after all.