>Seems like management believes it is better to wait for real bad actor to purposefully destroy your site than have it done by your honest employees by accident.

From a politics standpoint that is completely true. Which would you rather tell your boss:

Q: Why is the website offline?

A: One of our sys admins accidentally deleted it.

OR

Q: Why is the website offline?

A: Some nation-state/teenager launched a sophisticated cyber attack, we need to increase the cybersecurity budget. It's the wildwest out there!

There is this saying that only a person that does absolutely nothing never makes any mistakes.

Mistakes are normal course of action at a corporation. Sane managers will understand that is not possible to not have people make any mistakes. Mistakes are part of the learning process.

Now, when somebody makes a mistake what I am looking for are:

Does this person show good judgment? Were precautions taken by the person reasonable?

Does the mistake show pattern of abnormality? Some people seem to attract failure, maybe there is some underlying cause?

Is the person learning from mistakes? Learning is expensive, if somebody made an expensive mistake I want as much learning as possible for the expense.

Is there some kind of external factor that made the mistake possible or more likely? Usually it is possible to improve the environment to reduce the number of mistakes.

As to preventing these guys from scanning ever again, that is bad decision because it is likely they would never make the same mistake again. What's done is done. The scan showed there are problems with the app, now we should want to know if there are more problems but without risking the application stability (too much).

---

-- Do you know what the Big Co. pays when they pay high salary for an experienced engineer?

-- They pay for all the mistakes he/she made at her previous place.

We have stopped all payroll payouts because one accountant mistyped a digit last month

Was the solution to bar accountants from typing?

I don't really agree with that decision, but maybe that phrasing is not 100% accurate. Maybe they just meant that they should run the scan on a local test environment and not in the production deployment. Obviously, there's value in running it against live, but at least for this particular issue, they could probably had caught it in a testing environment.

You are probably thinking in today's terms. Back then it was unlikely there was separate test environment. For application... probably, but not for what is a static website and HTTP server.

They may not have had a fully fledged staging environment which is an exact copy of production. But I'm sure they ran the http server locally in their desktop to test new configuration. I was a high school hobbyist "developer" (maybe a power user would be more appropriate) at the time and I certainly tested my pages locally before I'd upload them to Geocities. 2000 is not the bronze age :P. People were already talking about TDD then and the concept of testing things before shipping existed for much longer.

I think you're looking back at this from the modern perspective of cheap hardware and open source software. We didn't have Sun workstations as desktops - we were using FreeBSD on cheap Dells. Our production servers cost something like $200k each. And the http server cost money - we didn't have licenses to run copies locally. These days you can just run things in Docker and have a reproducible environment but it wasn't that easy back then.

I have been sysadmin at that time.

Usually, HTTP servers would be huge bloats of configuration running on huge machines. As a sysadmin, it was not typically feasible to replicate the configuration on the local machine.

With a static website nobody would figure you can accidentally actually do something harmful to the website. The worst thing that could happen was that you made a configuration error in which case you just rolled back the config.

Of course we were supposed to have backups in case the server failed. While the servers would typically use RAID arrays we knew it would not save against rm -fr so there was a backup but backups rarely could be restored instantly.

Interesting. I never thought it was so complicated to run the http server. What was the bottleneck that prevented them from running locally? The memory used by all the config?

The amount of hardcoded stuff that was specific to the machine. All the domain addresses, firewall rules, etc. There was no git or ci/CD to keep everything in sync (easily).