Threat modeling is all I get from the article. It is a vague conceptual guide. If you were hoping for code, software tools, or commands to type from your keyboa

Threat modeling is all I get from the article. It is a vague conceptual guide. If you were hoping for code, software tools, or commands to type from your keyboard I understand your disappointment. Security is often difficult to explain to software developers, because (contrary to what many developers believe) security is so far outside the training and experience of writing software. It’s like trying to explain relational data theory to school children with crayons. It’s not that the children are stupid, they are probably smarter than you and I, but that data theory is not a part of their world view and in practice they really really don’t care. Yet, many developers falsely believe they have a solid understanding of security despite a lack of experience, training, certification, or interest in the subject. This, more than anything else, explains why opinions and articles from security researchers are frustrating to software developers and why security researchers prefer to not engage software development communities aside from some highly focused security oriented groups. After working in security for a few years the subject really boils down to two boring words: risk analysis in the most abstract way possible. As a developer we like to think of security in terms of 0day exploits, patches, audits, memory safety, and so forth but those are just symptoms/remediations of. It like comparing pills and needles to medicine.