[neilv]

> Companies have no business telling their employees which specific programs they can and cannot run to do their jobs, that's an absurd level of micromanagement.

I'm usually on the side of empowering workers, but I believe sometimes the companies do have business saying this.

One reason is that much of the software industry has become a batpoop-insane slimefest of privacy (IP) invasion, as well as grossly negligent security.

Another reason is that the company may be held liable for license terms of the software.

Another reason is that the company may be held liable for illegal behavior of the software (e.g., if the software violates some IP of another party).

Every piece of software might expose the company to these risks. And maybe disproportionately so, if software is being introduced by the "I'm gettin' it done!" employee, rather than by someone who sees vetting for the risks as part of their job.

[janstice]

For example, if someone installs the wrong version of Oracle Java on a VM in our farm, the licencing cost is seven figures as they want to charge per core that it could conceivably run on - this would be career-limiting for a number of people at once.

[kstrauser]

Or VirtualBox’s extensions which make it usable. Those are free to download but could make you an audit target.

[janstice]

Or even Docker Desktop, which is a bunch of $$ that no-one expects (and I think Microsoft is still recommending in the WSL docs).

[josefx]

Is there still a reason to use VirtualBox?

[kstrauser]

IMO, no. Maybe inertia from people who learned it long ago and stopped looking at the alternatives.

[lelandbatey]

Developers are going to write code to do things for them, such as small utility programs for automating work. Each custom program is a potentially brand new binary, never sent before by the security auditing software. Does every program written by every dev have to be cleared? Is it best in such a system to get an interpreter cleared so I can use that to run whatever scripts I need?

[degamad]

If I have an internal developer in such a scenario, then what makes most sense to me is to issue them a code-signing certificate or equivalent, and whitelisting anything signed by that certificate[1], combined with logging and periodic auditing to detect abuse.

[1] <https://learn.microsoft.com/en-us/windows/security/applicati...>

[viraptor]

> Does every program written by every dev have to be cleared?

No, that's not how things are implemented normally, exactly because they wouldn't work.

[gabeio]

> No, that's not how things are implemented normally, exactly because they wouldn't work.

I used to work for a gov't contractor. I wrote a ~10 line golang http server, just because at the time golang was still new (this was years ago) and I wanted to try it. Not even 2 minutes later I got a call from the IT team asking a bunch of questions about why I was running that program (the http server not golang). I agree the practice is dumb but there are definitely companies who have it setup that way.

[viraptor]

So running it wasn't prevented for you, and new apps listening on the network trigger notifications that the IT checks on immediately. That sounds like a reasonable policy.

[macintux]

Around 1998 I snagged an abandoned 486 and installed Linux on it for use at work; the corporate software I used the most, a ticketing system, could be run using X from a Solaris server. I don't remember what I did for Lotus Notes.

Anyway, the IT department spotted it but since I was using SMB it thought it was just another Windows server. No one ever checked up on it despite being plugged into the corporate network.

This was a Fortune 500 company; things have changed a wee bit since then.

[shanipribadi]

had something similar happened a few years back.. basically the go binaries i compiled and run would get deleted every time I try to run it. usually just downloading the newer version of go compiler and recompile with that solves it (I think it got flagged because it was compiled with an older version of go compiler with known vulnerabilities). Every time it happened I think IT security got a notification, cos they would reach out to me afterwards. The few times upgrading to the latest go version didn't work (false positives), I would just name the binary something like "Dude, wake up", or "dude, I need this to get whitelisted", and do the compile-run-binary_got_deleted cycle 10-20 times, effectively paging the IT security guy until they reached out to me and whitelist things for me :-D.

[zmgsabst]

Developers are generally given specific environments to run code, which aren’t their laptops — eg, VMs in a development environment.

The goal isn’t to stop a developer from doing something malicious, but to add a step to the chain for hackers to do something malicious: they need to pwn the developer laptop from the devbox before they can pivot to, eg, internal data systems.

[kstrauser]

In my experience, that’s rare. Everywhere I’ve worked had devs working on code directly on their laptops.

[zmgsabst]

My experience is the opposite:

I haven’t worked somewhere we ran code locally in a long, long time. Your IDE is local, but the testing is remote — typically in an environment where you can match the runtime environment more closely (eg, ensuring the same dependencies, access to cloud resources, etc).

[tough]

isn't that just CI?

does that mean you will never compile it or build it locally?

don't 99% of people just use docker nowadays to have all that environment matches?

[xmprt]

This is a strawman argument. If a developer writes code that does something malicious then it's on the developer. If they install a program then the accountability is a bit fuzzier. It's partly on the developer, partly on security (for allowing an unprivileged user to do malicious/dangerous things even unknowingly), and partly on IT (for allowing the unauthorized program to run without any verification).

[lelandbatey]

It's not a straw man, I'm not trying to defuse liability. Of course a developer running malicious code they wrote is responsible for the outcomes.

I am pointing out that if every unique binary never before run/approved is blocked, then no developer will be able to build and then run the software they are paid to write, since them developing it modifies said software into a new and never before seen sequence of bits.

OP may not have meant to say that "it's good to have an absolute allowlist of executable signatures and block everything else", but that is how I interpreted the initial claim and I am merely pointing out that such a system would be more than inconvenient, it'd make the workflow of editing and then running software nearly impossible.

[TheNewsIsHere]

Your premise assumes there are policies and technologies in place that restrict what a developer can do.

This is often the case, although I’ve very rarely seen environments as restrictive as what you describe being enforced on developers.

Typically developer user accounts and assigned devices are in slightly less restrictive policy groupings, or are given access to some kind of remote build/test infrastructure.

Of course companies need the option to control what software is run on their infrastructure. There are an endless stream of reasons and examples for that. Up-thread there’s a great example of what happens when you let folks install Oracle software without guardrails. Businesses are of course larger and more complex than their developers and have needs beyond their developers.

What matters here is implementation and policy management. You want those to be balanced between audience needs and business needs.

It’s also worth mentioning that plenty of developers have no clue what they’re doing with computers outside their particular area of expertise.

[rainonmoon]

It's a straw man in that you're establishing an inherently facile and ridiculous scenario just to knock it down. A scenario that, as others have demonstrated, is not grounded in any logical reality. "Nobody mentioned this imaginary horrible system I just thought of, but if they had, it sure would be terrible" is quite a hill to die on.