Wise IT admins >know< they are ignorant and design for that. Before an application gets deployed, its requirements need to be learned - and the users rarely know what those requirements are, so cycles of information gathering and specification of permitted behavior ensue. You do not declare the application ready until that process converges, and the business knows and accepts the risks required to operate the application. Few end users know what a CVE is, much less have mitigated them.

I also note that seatbelts and airbags have undergone decades of engineering refinement; give that time to your admins, and your experience will be equally frictionless. Don't expect it to be done as soon as the download finishes.

I think you are missing the main point of my analogy: seatbelts and airbags work on damage mitigation, while the kind of security that bothers users so much is the one focused on prevention.

Especially in IT, where lives are not at stake, having a good enough mitigation strategy would help enormously in relaxing on the prevention side.

Depending on your sector, I would argue that in IT, lives can be at stake. Imagine the IT department of a hospital, a power company, or other vital infrastructure.

Most mitigation tends to be in the form of backup and disaster recovery plans, which, when well implemented and executed, can restore everything in less than a day.

The issue is that some threats can lurk for weeks, if not months, before triggering. In a car analogy, it would be like someone sabotaging your airbag and cutting your seatbelt without you knowing. Preventing a crash in the first place is far more effective and way less traumatic. Even if the mitigation strategy allows you to survive the crash, the car could still be totaled. The reputation loss you suffer from having your database breached can be catastrophic.

Prevention in the car analogy would be like adding a breathalyzer and not allowing it to start if the person in the driver's seat fails.

It's been a gimmick idea for decades but I'm not aware of any car that actually comes with that as a feature. Kinda think there's a reason with how much friction it would add - I just did a quick search to double check and found there are add-ons for this, but without even searching for it most of the results were how to bypass them.

Damage. Pinhole is just as damaging to corporation that may result in leakage of password files, sales projections, customer records, confidential data, and mass encamping of external hackers infesting your company's entire networked infrastructure.

Slowing down everyone is also incredibly damaging to the corporation though. And as others have pointed out might even be counterproductive as workers look for workarounds to route around your restrictions which may come with bigger security issues than you started out with.

So much this.

There is a default and unremovable contention between usability and security.

If you are "totally safe" then you are also "utterly useless". Period.

I really, really wish most security folks understood and respected the following idea:

"A ship in harbor is safe, but that is not what ships are built for".

Good security is a trade. Always. You must understand when and where you settle based on what you're trying to do.

Really well put and I always tell people this when talking about security. It's a sliding scale, and if you want your software to be "good" it can't be at either extreme.