I'd add the "adopt an information theoretic approach" to security analysis. (Which is basically what taint analyzers perform.) Think through how systems/components/libraries/functions can and do interface with each other, and try to secure these points. (Make them type safe, make them strict, report meaningful errors ["expected this but got this" is a million times better than invalid input], so they will be easy to maintain and make even more secure.) Try to extract out these parameters as much as possible so you can avoid possible impedance mismatches across the interfaces.

Also, checklists. Checklists are good. And an inventory of used components, and their versions. (This makes it easy to do a CVE review from time to time, and then to automate the review eventually, so only the list maintenance will remain manual.)

Defense in depth, but not through obscurity. (There usually are low hanging fruits. Enforce use of password managers, invest in centralized credential storage, don't overdo password expiration and 2FA. Security training is also a good idea, but the real goal is to nurture a security aware office/team culture.)

Social engineering [or just plain old laziness] is still a serious threat.

Timeboxing. Set aside 1-2 days every month to work on meaningful security-conscious goals. So try to upgrade to lay the fundamentals for that library upgrade that is overdue for years, try to make systems reproducible (also good for DR), try to add a few simple validations here and there against local file inclusion (or whatever comes up during the month, or during the checklist review).

Also, accepting that maintaining network facing systems have an inherent ongoing cost. (Unless you want your iToaster to eventually end up as part of a botnet.) Sometimes we have to let things go, accept that some business models (or hobbyist projects) are not worth it to do sanely and securely.

That is a nice list and all, and I would add that if you can't use a memory safe programming language then you should look closely at the compiler flags in use as well.

But if you need all that to spot the obvious issue in the OP's original specification ... then wow.

There are parts of some jobs where perfection is required. People working at height don't drop anything (and there are cases where safety lines aren't possible). Surgeons don't get to just say "oops, my finger slipped" when holding a scalpel near your heart.

In "From the Earth to the Moon" [1], someone explains that the main problem of the Apollo 1 fire was that nobody thought to label that test "hazardous". Sitting on the ground was supposed to be safe.

We should expect perfection when writing C code, but we should also be clear that writing C is a hazardous activity, and not to be taken lightly. My surgeon is a human being, so I don't expect him to never make a mistake, but he's also a skilled and careful professional, and I do expect him to never make a 101-level mistake while holding a scalpel.

[1]: https://www.youtube.com/watch?v=J_HZr2otkg4

New tools = New security bugs we still need to find.

If you know your tools there is less risk that you produce security bugs. You know the sideeffects of all the commands and functions. If you use a black box and trust it fully, you will (unknowingly) find ways to make new security holes noone ever thought of before.

I'm not saying that we should not innovate, just that we should not rush head first into the blue sky thinking everything is fine just because we use the new shiny thing where we can't make bugs ever.

Unfortunately there are a lot of scenarios where C/C++ are still the only practical choices. No other language even comes close to their ubiquity AND performance at the same time. I'm sure the day will come though.

And there are those working on mitigating some of the worst issues with those languages, maybe someday they will bear practical fruit as well.

https://github.com/Microsoft/checkedc

> Even though you can still screw up as as a programmer in a better tool, you should still pick that tool if that reduces the security risk by a number of percent over another tool.

I agree in general, but not necessarily if the "better tool" doesn't run on or generate code for your target platform, or doesn't meet your performance requirements, or memory constraints, or the requirements to interface with other languages via a common ABI etc, etc etc.

And, in those situations, you need to BE CAREFUL.

> Large problem is that experienced programmers encourages new programmers to use the older & less secure tools. I guess in a way to stay relevant.

Oh I get it. Blame the older generation who wrote the platforms & tools that gave you a job in the first place. If that doesn't work, blame the tools. Blame anything but yourself for writing shit code. I see.