{"id":92095,"date":"2023-05-26T04:46:00","date_gmt":"2023-05-26T04:46:00","guid":{"rendered":"https:\/\/cloudnewshub.com\/?p=92095"},"modified":"2023-05-26T04:46:00","modified_gmt":"2023-05-26T04:46:00","slug":"security-think-tank-why-secure-coding-is-neither","status":"publish","type":"post","link":"https:\/\/cloudnewshub.com\/?p=92095","title":{"rendered":"Security Think Tank: Why \u201csecure coding\u201d is neither"},"content":{"rendered":"
<\/div>\n

There\u2019s 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.<\/p>\n

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.<\/p>\n

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

And I don\u2019t mean this just in a semantic sense. For example, I\u2019d 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\u2019s 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.<\/p>\n

\n

<\/i>Software development security vs. risk reduction<\/h3>\n

The first thing to unpack is the intended end state of what we mean by \u201csecure coding.\u201d In my opinion, there are a few different, related goals usually intended by this term. First, by \u201csecurity\u201d in this context, folks typically mean two things:<\/p>\n

    \n
  1. Employing application architecture and design patterns that foster risk reduction principals (e.g., confidentiality, integrity and availability)<\/li>\n
  2. Creating software that is resilient to attack (e.g., via avenues like vulnerabilities and misconfigurations) <\/li>\n<\/ol>\n

    Both of these things are, of course, incredibly important. Spend some time talking to application security practitioners and they\u2019ll, rightly, highlight to you Barry Boehm\u2019s<\/a> famous work about the economics of finding and fixing vulnerabilities early in the development process. They\u2019ll, rightly, explain to you the value of tools like application threat modeling<\/a> that can be brought to bear to understand what and where security design issues are in software. The trap is that these things, important as they are, are not the entirety of what we might be interested in when it comes to reducing risk in software. For example, other things we might be interested in at least equally could include:<\/p>\n