I think recognizing that security is just one of the many engineering challenges in building software is important. It must always be prioritized and budgeted like any technical debt. It can’t be ignored, but it is rarely the supreme concern for most software. We do a lot of turn key security engineering for our customers and it’s always about prioritizing the right concerns, both from an implementation perspective and from an organizational perspective. Another thing a lot of folks struggle with is knowing where your product is and where the security fights should be at a given product and organization scale.

Risk assessment and threat modeling are huge for creating such a prioritization. Whether it’s formal and in depth or informal depends again on where things are.

Beyond these concepts, well engineered software simply has less security defects, so focusing on quality and managing technical debt often means less security debt as well.

It’s down to being an immature practitioner to think security concerns are always the primary ones. I think it’s a hard skill to master though, so I am not saying that with great judgement, someone should be a champion for security at most organizations and advocate for it. I think using empathy and curiosity goes a long way to maturing as a practitioner, but it took me many years of practice.