Hacker News Reader

Rather than cheat the system to get the project done you probably need to let the project be late and then explain that it was late because IT dragged their feet on app approval. That will make it pretty clear to the powers that be that this needs to be fixed.

To be fair to IT teams, it normally SOC that drag their heels on software approvals.

Correct. The only way to actually bring about change is to make sure the ones with the power to change things feel the pain associated with their decisions.

I feel this could be dangerous advice to follow.

No, it's the only way things get better. First if you cheat the system and something does happen, it's your and just your fault. Why take the risk. If the company has rules, it's also the companys job to make your work possible with these rules.

I'd like to believe this works, but my experience in Big(ish) Corp is that you get the blame.

If you think you're in a position to change it and you're motivated to do so, go for it, otherwise my experience is that you're better off finding somewhere else to work.

CYA via email and other documented functions, but you are correct in the sense you're better off finding somewhere else to work.

I've seen too many companies set up systems that you cannot be in compliance with but there is no punishment for non-compliance unless they are looking to get rid of you.

Special from a Big(ish) Corp I expect to give me all tool for work. They have all admins and all compliance people. If they are not willing, yes search another job.

This depends so much on the situation. It might be a way to get things better, but it's also likely to leave a sour taste in your customer's mouth. They may know that Dev Bob was't responsible for the problem but IT Alice was, but what they'll internalize is that there was a problem with Bob and Alice that caused them pain, and they'll associate Bob and Alice both with that pain.

It's necessary where the relationship with IT becomes adversarial, often with IT that's less skilled, or more constrained by their management.

Where possible though a mutual beneficial relationship is best.

Where I work I have two laptops. One is my corporate laptop, less powerful but it can connect to our internal network. The other is my dev laptop, more powerful but it can only connect to Internet and our dev network. I can install whatever I need on the dev laptop, as long as I a) keep a running log of installed software and update IT when that changes, b) regularly check NVDB for the software I have installed and apply mitigations as needed, c) keep versions updated to current versions where possible (and never to versions that have known vulns).

I work at a bank and I can tell you that nobody is emailing or sharing files to their personal devices. Doing so would have you fired on the spot.

At my workplace apps are whitelisted and it's honestly not a big deal. Very rarely do I find myself in a situation where I can't access the tools that I need.

Working at a bank and working as a design engineer or low-level programmer have extremely different requirements for a work computer.

My experience, after working in many big and small companies in several countries and multiple continents matches perfectly what the above poster has said, i.e. at least for any kind of design or testing work that involves external hardware, the only way to get anything important done is to circumvent any restrictive IT policies, which are always made by people who might have worked in a bank, so they have no idea about how a computer is used for designing or testing hardware or software for embedded computers.

Most of the work that I have ever done could not be done on company-managed computers, so I usually had to do it on my own computer and transfer then the results to the company computer, which was used only for communication inside the company, through e-mail/Teams/internal file servers etc., and for writing reports or other documents.

I work in a factory in industry automation and we also never ever use with personal devices. That said, it is possible for some few guys in the the tech to get an local admin account to install software, or even just to change IP-addresses. For ex. often VPNs (external people can connect to a machine) don't work and so we had several times the case a machine did stand still because of it. Then of course we not just make a link with a phone. We make a mail to the CEO and he take care of it with the IT.

> Almost every day. Sometimes multiple times a day in case of a new project / new embedded hardware (toolchain) / new devkit to "quickly test" / tight deadlines, etc.

The approach normally doesn't count project local tools which don't install like normal applications. E.g. some frameworks you install into your project instead of having user or system wide installations (e.g. with npm for web-dev stuff).

I know that for embedding computing a lot of tools which are normally ad-hoc project installations are instead system wide "normally installed programs".

But that isn't the case for most software development fields. In many other fields that new tool-chain you want to try out is just a dependency you add to your projects dependency management tool. And keeping it up to date is done in the same way you keep your other dependencies up to date (e.g. a scheduled CI job checking for updates).

Rootless OCI (docker) containers can help with that. But embedding also often touches on driver aspects so it might not be an option.

Anyway if you ignore embedding programming, parts of system programming (e.g. linux kernel), some legacy software and some cases of important C/C++ tools needing too many permissions nearly all other programming jobs should be viable on a locked down system as long as you have the right not too big set of tools preinstalled and access to rootless containers (independent of weather they run in a VM or not).

EDIT: formulations, for clearity

vscode has a portable version that can be installed as a project local tool. So would vscode installed in such a way also be an exception to this approach?

It's less about if it's install-able in a project and more if it's project specific, so IDEs should if possible not be included.

Furthermore if possible stand alone tooling which tend to not be very version sensitive can be nice to not include: E.g. git, npm, rustup, pip and similar are preferable system installations.

Furthermore frameworks and similar tend to go through the package manager and whatever update handling you have for it. But a drop in IDE likely would not.

Given various recent supply chain attacks, I would say "installing dependencies into your projects" is becoming just as dangerous as downloading and running arbitrary executable.

Its IS running arbitrary executable, but so is installing some 3rd party Program and even some program uploaded to the Microsoft app store or a Linux package manager isn't necessary much different. Sure Linux package index maintainers give them "due diligence" but that has limits and Microsoft replaces that mostly with some automated scanning, which isn't better.

But when it comes to the aspect of managing updates, project specific installs are better.

And when it comes to security then the answer for both installed and project tool-chains is: Sandboxing.

- run your toolchain in a container

- run your IDE in a different container

- run hardly trusted tools in another container

- use reasonable phishing proof 2FA (i.e. FIDO2) for authentication, use authentication tokens.

This applies to "normal" applications, too. They also should run in their own container. Just because it has an installer or is signed by a company or is on a app store doesn't mean it's trustable.

Thats one of the things phones at least somewhat got right, their apps are containerized by default (through they might give too much permissions to apps but that's a different problem)

> The IT team promises they'll speed things up, but a software approval for 1 app still takes at least 3 months. Now what?

Ouch.

I wonder if those apps are one-off for particular task or you just find so many useful apps every day. Anyway, Windows now features Sandbox mode - a great place to install untrusted apps as the sandbox is discarded on close. https://learn.microsoft.com/en-us/windows/security/threat-pr...

Sounds like you have slightly unusual needs - I install NPM packages and the like all the time (which I haven't seen any company attempt to oversee yet), but very few binaries. Sounds like you need binaries the way I need these packages, so it sounds odd that the company wouldn't come up with some solution - dedicated VM, special exceptions, whatever.

Some of the NPM packages contain binaries.

so what exactly is the difference between binaries and scripts executing arbitrary system calls?

For the purpose of our discussion: None whatsoever. That's my point. Corporate IT mandates what they know/think about, quite often unfortunately without any understanding of the specific needs of employees (like parent).

I found it to be a better strategy to start from a prioritised list of risks and tackling the high priority items in an actually meaningful way. But I can see how that doesn't work at companies with >300 employees - at one point security just pushes for whatever they can get, disconnected from the true needs and relevant risks at the company.

My company has a policy that all software needs to be explicitly approved. That includes any software library, extension, or package from a package manager. Is it followed? Not in the slightest! Something I recently ran into: the Rust version manager 'rustup' is approved but neither the compiler nor the package manager have been approved. That's despite our core product having used Rust libraries through the C ABI for years. Madness!

azure AD has a privilege escalation mechanism to local admin. you enter e.g. the jira ticket reference for documentation and the system gives you an 8h window to enable localadmin on your machine with the particular AD user. we use it to give e.g. architects who often try new software to do what you describe in an efficient manner.