[macintux]

I'd be amazed if the average/combined skill level of engineers at any large company exceeds the average/combined skill level of the people trying to compromise its security.

And that's not taking into account the bureaucratic overhead necessary to make changes in such an environment. There are very good, and very bad, reasons why upgrading insecure software and fixing other security holes takes too much time and effort.

Equifax just happens to be a very attractive target. I don't know how any such target can stay truly safe.

(Having said that, they clearly screwed the pooch in a lot of ways, so I won't shed a tear if they're dismantled.)

[sidlls]

Libraries, frameworks, and other security systems don't have to be developed in-house. It's just like basic data structures and algorithms: few ought to be rolling their own and should instead be using libraries.

[macintux]

All of those are insecure, so it's still a matter of staying ahead of attackers. And avoiding social engineering. And making certain the code that glues those libraries and frameworks together is secure. And making sure people don't accidentally leave an S3 bucket unsecured. And making sure every 3rd party contractor on-site doesn't take advantage of softer internal security. And making sure employees aren't bribed by competitors.

And making sure the business can still function while doing your best to limit functionality.

[gaius]

Yes and no; it was Apache code that was exploited. The failure tho' wasn't technical really; it was the lack of urgency in patching once the flaw was known, which is 100% on management