Prevention Is Better Than Cure

These past forty-five days or so saw the rise of voices of cybersecurity professionals from various capacities towards the stopping of update of the National Vulnerability Database. NVD is an important database that's consulted by professionals not only in United States, but also from around the world.

Around February 15th, entries in the NVDs started missing critical entries that are pertinent in assessing vulnerabilities. These entries are not only important for vulnerability management, but also important for secure-by-design, so that software can be designed in a way that would prevent the vulnerability from happening. Sounds familiar, testing professional? Remember the quality initiatives that we do during requirements, design & development such that bugs don't occur?

The awareness about not fixing things after-the-fact has come to age for Software Security also, considering the bloating vulnerability database, and the risks involved in maintaining it. While there are still challenges that cannot be fixed upfront and involves third-party components over which a software supplier won't have control, it is still important to do the secure-by-design, as pointed out by CISA through an example.

I would argue that be it software defects or software vulnerabilities, detecting quality issues upfront is important. This concept is not new, and we have been hearing it for decades, yet, the vulnerabilities database and the defects that we find in the product after the code is written keeps growing. I think we need to put a lot of thought in preventing this from happening.

There is no shortage of knowledge and information, and thanks to the LLMs, we are able to get answers to our questions in just prompts. To take my personal example, I learnt an entire section of a technology using an LLM! There are tons of courses, blogs, YouTube tutorials, webinars, articles, and books to learn from. So what is preventing the developers from preventing defects and vulnerabilities early on?

An year ago, I argued in the same way about Software Performance. People from traditional software testing as well as Agile world said it was not possible. Taking the worst case scenario of performance expectations and building according to those expectations is one way of addressing performance upfront, rather than finding out much later half way through that we need to change the design!

I am going to keep advocating this in various forums that I'm engaged in. This is so important and saves everyone's time and energies. There will be challenges, but hey, show me something that's without a challenge!