There’s a little bit of a trap sometimes that can arise in the way that humans understand and process language. Specifically, sometimes we take the meaning of a word or phrase for granted. By this, I mean we use a term meaning a given thing, only for those hearing us to understand the term in a completely different way.

This is counterproductive when it happens in day-to-day communication, but can be dangerous in the context of risk-impacting disciplines such as cyber security, assurance, and governance. In these situations, it can create risk.

I bring this up because often we hear about ways to ensure “secure coding” in organisations that author and maintain software as part of their business, either for internal or external use. It’s important because, frankly, most businesses fall into this category nowadays. While it’s natural to discuss the challenges of software risk this way, I believe the term “secure coding” itself presupposes a context that makes the intended end state actually harder to achieve – at least when taken literally.

And I don’t mean this just in a semantic sense. For example, I’d argue that understanding why that statement is true has actual, tangible, practical value. It speaks to the root cause of why many organisations struggle with application and software risk, and it highlights practical steps organisations can take to improve. With that in mind then, let’s unpack what actual software risk reduction goals are, and how best to effect them as we fulfil our requirements to develop and publish software safely and resiliently.