The abstraction doesn't fit. Where the civil engineers would be expected to build a bridge that doesn't collapse when the wind is Just Right (key word: Tacoma Narrows Bridge), software makers are expected to build a lock that doesn't open when someone whistles Just Right (key word: SQL injection).

Bridge builders are not expected to make the bridge itself defend against saboteurs, unlike software. To painfully extend the scenario: the wind is relatively well understood and once you've learned a lesson and guarded against it as a bridge builder, a given bridge can be considered stable.

Not so with software. One vuln fix, 5 more show up to take its place over time.

Malicious actors & botnets = the wind now (bear with me please). Once the bridge no longer collapsed via a certain Just Right tune, the wind would stop blowing the old Just Right way and instead try finding a new Just Right way, like whirling in a tight circular motion in just the right spot to see if it can unscrew bolts, or attempt -ddos- to tornado itself into a waterspout to try to collapose the bridge.

Security is not a one and done operation.

Yeah, that makes sense. In other words, software is far easier to build, but requires much more effort to maintain - in which security is prominent.

The might think about whether the bridge can cope with a hurricane, however.

they may not know the models of cameras and the specs, but they do know they need to attach them somewhere and how they work.