Why software security needs a practical approach

Alon Bar at Checkmarx asks whether the NCSC’s call for reframing ‘unforgivable’ vulnerabilities will work

 

Software vulnerabilities are one of the most persistent security issues for both the public and private sectors. Even after so many years on the CISO’s agenda, they are often still the root cause of breaches. In fact, our research with global CISOs found that 89% of organisations have suffered a breach due to vulnerabilities in their own internally developed applications.

 

In one of the latest efforts to address this stubborn issue, the UK’s National Cyber Security Centre (NCSC) has introduced a framework defining software vulnerabilities as forgivable or unforgivable. The aim is to simplify the classification of vulnerabilities and enable organisations to proactively address the root cause of issues rather than addressing them reactively.

 

While the NCSC’s call for accountability is welcome, this issue is far from new. The approach is partially based on concerns raised in a 2007 MITRE paper, yet these vulnerabilities remain widespread today. A key reason is that too many organisations only prioritise security after suffering a breach, which raises a critical question: can a voluntary framework truly drive change, or will stronger regulatory pressure be required?

 

‘Forgivable’ and ‘unforgivable’ vulnerabilities

The NCSC’s framework aims to simplify vulnerability classification, moving away from traditional severity ratings. Instead, vulnerabilities are labelled as forgivable (complex or difficult to prevent) or unforgivable (which should never occur due to well-established mitigations).

 

For example, SQL injection attacks, made possible by one of the oldest and most well-documented security flaws, are considered unforgivable because they can be avoided with proper input validation and parameterised queries.

 

The goal is to push vendors towards security-by-design as standard practice, preventing these avoidable vulnerabilities from appearing in production to begin with. The persistence of ‘unforgivable’ flaws often signals a systemic failure to prioritise security early in the development lifecycle. Without structural shifts, even well-intentioned frameworks risk being ignored until an incident occurs.

 

Is the NCSC’s proposed approach practical?

The NCSC’s framework urges vendors to eliminate the root causes of all vulnerabilities, but in practice, this is far from straightforward.

 

For instance, the NCSC suggests shifting to memory-safe programming languages such as Rust instead of C or C++. While this could reduce the likelihood of certain vulnerabilities, it ignores real-world constraints - including a shortage of Rust developers and the sheer volume of existing software written in legacy languages. 

 

Whilst ideally, we would abandon C and C++, many businesses rely on decades-old infrastructure running applications written in these languages. The investment required to rewrite them in Rust would be enormous and, in many cases, unfeasible. Instead of expecting vendors to rewrite history, security teams should focus on mitigating risk within existing ecosystems.

 

Similarly, input validation is seemingly cited as a universal solution, yet this oversimplifies the complexities of modern applications, where security risks often emerge from dependencies, third-party code, and cloud environments.

 

Another challenge is the push for secure architecture and software development lifecycle (SDLC) improvements. While these are essential, they require years of organisational change and significant investment. Vendors will not be able to implement these changes swiftly or easily.

 

In short, the framework should be a valuable tool for helping bring AppSec higher up the agenda, but dev teams will need to consider how it applies to their own processes. Organisations should look at how they can adopt the forgivable and unforgivable vulnerability mindset within their existing SDLC workflows. 

 

Making AppSec work for vendors

Instead of set classifications, software vendors need practical security measures that integrate seamlessly into development workflows.

 

Embedding security practices early in the development lifecycle is key to success.  Developer teams need security alerts to be remediable directly within development environments and throughout the entire SDLC, preventing development operations architects from the time-consuming task of managing multiple tools and developers from drowning in false positives. A consolidated AppSec approach with integrated security saves vendors time, money and provides a complete view of application risk, meaning teams are always ready to run.

 

Many developers struggle to integrate security early without disrupting productivity. Automation and AI-driven vulnerability assessments increasingly play a crucial role in this, helping teams filter out false positives, prioritise, and focus on genuine threats.

 

Rather than suggesting wholesale programming language replacements, vendors should focus on secure coding practices, modern tooling, and layered defences. Strengthening these elements will gradually improve application security without unnecessary upheaval.

 

Building the lines of communication between security and developer teams is also critical and this can require cultural change. Initiatives such as security champion programmes that recognise developers for sharing their security expertise can bridge knowledge gaps and ease friction with security teams, who often see application security as slowing things down while development deadlines loom.

 

Without proactive collaboration, security remains an afterthought. By embedding security advocates within teams, organisations can create alignment and ensure security is seen as an enabler, rather than a blocker, of innovation.

 

Finally, vendors need risk-based prioritisation frameworks that go beyond ‘unforgivable’ labels, considering exploitability, business impact, and real-world attack vectors.

 

These approaches will enable software vendors to better balance innovation, speed, and security, ensuring resilience without compromising efficiency and release schedules.

 

Addressing the incentive problem

Alongside the practical challenges in finding and eliminating vulnerabilities, misaligned incentives are a leading issue in application security.

 

Positioning AppSec as a business priority can often be as much a barrier as the practical challenges of finding and eliminating vulnerabilities. 

 

Vendors are under constant pressure to release products and deliver new features quickly, and security is often treated as an afterthought or even a barrier to successfully hitting deadlines. Under these pressures, teams can also struggle with prioritisation.  

 

It can be difficult to determine which vulnerabilities pose the greatest risk. Without clear incentives or structured guidelines, many teams resort to compliance checklists rather than a grounded, risk-based approach.

 

There’s another issue here: security tools often fail to align with developer workflows. If security slows down development, teams are less likely to embrace it fully. Many organisations invest in security, but struggle to prioritise risks amidst alert overload.

 

Without internal enforcement and accountability, security risks remain, even when compliance checklists are met. 

 

What next for application security?

Application security is increasingly tied to business outcomes - vendors with poor security ratings face difficulties in procurement processes, and breaches can erode customer trust and even impact stock prices. 

 

The NCSC’s framework and mindset of forgivable and unforgivable vulnerabilities provide useful guidance for elevating AppSec as a business priority. 

 

If external frameworks are to make a real difference, they must go beyond recommendations and create clear business incentives for vendors to prioritise resilience over speed. Otherwise, security will remain an afterthought, and vulnerabilities will continue to be a leading cause of breaches. 

 

---

 

Alon Bar is Global CISO at Checkmarx

 

Main image courtesy of iStockPhoto.com and Artur