This article originally appeared as part of the Forbes Technology Council. It has been updated and syndicated here.

‍

How many data records do you believe were compromised in 2022? You would be on the right track if you guessed somewhere around half a billion. Based on publicly available breach data, approximately 480,014,323 records were stolen last year alone, but the number is likely far greater. In any case, that’s a sobering statistic for the average citizen, and deeply concerning for any enterprise security professional.

We’ve reached a point where most people in the developed world have likely seen at least some of their personal data falling into criminal hands through a successful cyberattack, so it’s only natural that world governments are looking at solutions to stem this disruptive flow of online criminal activity. The latest installment is from the Biden Administration in the form of the National Cybersecurity Strategy, and I am looking on with keen interest. Included in this strategy are directives around one of my favorite topics these days: security accountability.

The strategy, released after a seminal presentation by CISA’s Director of Cybersecurity and Infrastructure Security, Jen Easterly, has understandably caused some division in the security community. However, I believe it represents the best chance we have at raising software standards across the board and, finally, ushering in a new era of security-skilled developers.

Vendors should have always been held accountable for insecure software.

It has been the case for decades that, in terms of software security, accountability is a hot potato that no team seeks to juggle. Executives and teams tend to vehemently disagree on who is ultimately responsible for software security, with one report from Venafi revealing that 97% of senior IT executives agree that software build processes are not secure enough, yet there is a discrepancy on who is ultimately responsible for effecting security best practices. 61% of executives said IT security teams should assume responsibility for software security, while 31% stated it should be the development team’s cross to bear. And that’s just one part of the equation: the issue of open-source and third-party commercial components in software builds is an ever-present expansion of the attack surface. Even between the AppSec and security teams, there is rarely an obvious “owner” despite the need for continuous vigilance in updating, monitoring, and testing.

This same survey also illuminated that - despite internal conflict on who should be liable for software security and integrity - 94% of executives believe there should be penalties for software vendors that fail to protect their build pipelines from threat actors, and put customers and end-users at risk. 

With the recent prosecution of Uber’s CISO in relation to their mismanagement of a devastating cyberattack in 2016, as well as regulatory initiatives like GDPR, we are slowly seeing the stakes raised for vendors who play with fire by deprioritizing security. However, this simply isn’t enough. We’re losing the battle against cybercriminals, and while a hard pill to swallow, it’s the lax practices of software vendors that provide boundless opportunities for them to thrive. 

The National Cybersecurity Strategy seeks to draw a line in the sand, and stop the circular blame game by assigning full liability for insecure software to the vendor.

Let’s take a look:

Strategic Objective 3.3 — Shift Liability For Insecure Software Products And Services:

“Too many vendors “ignore best practices for secure development, ship products with insecure default configurations or known vulnerabilities, and integrate third-party software of unvetted or unknown provenance.

We must begin to shift liability onto those entities that fail to take reasonable precautions to secure their software while recognizing that even the most advanced software security programs cannot prevent all vulnerabilities.”

This has, understandably, ruffled some feathers. But, as with other defining moments in the development of standards and regulations across most industries, it’s medium-term pain to ensure a better long-term outcome. As a software vendor myself, it makes sense that the buck must stop with us when it comes to security. It’s our build pipeline, our processes, and our quality control, and if we slip up, then it’s our responsibility to remediate.

Besides, we should be in a place where we seek to create software of the highest possible quality, and secure coding must be part of the metrics that define a successful result. Achieving this is a tall order in a world that is focused on speed at all costs, but it’s up to the security leaders guiding our future to ensure that everyone in the software creation process is adequately trained to deliver security best practices in the context of their role, especially developers. 

We still lack direction on long-term best practices.

Strategic Objective 3.3 does reference the well-established NIST Secure Software Development Framework as the basis for its general best practices, and these are comprehensive, all-encompassing guidelines. They do specify the need to “ensure that the organization’s people, processes, and technology are prepared to perform secure software development at the organization level”, but aren’t particularly prescriptive on the factors that, for example, a security awareness manager should be aware of when choosing enablement solutions.

For the approach to be truly transformative, developers should be considered integral to the security program, and given every opportunity to lift their skills and share the responsibility for vulnerability detection and eradication. They cannot achieve this in a way that is measurable without hyper-relevant, contextual learning and tools, nor if it’s considered an annual compliance exercise instead of an ongoing skill development pathway. 

Developers are a powerful piece of the puzzle when it comes to cracking the security riddle, and a team of security-skilled developers is essentially the missing ingredient in most organizations. They make security at speed possible, but only when time and resources are spent to unlock that in the team. Until then, all the general best practice guidelines in the world will fail to move the needle.

The long road to software security nirvana.

The Biden Administration has committed $3 billion in funding to CISA, with the aim of achieving rapid resilience across critical infrastructure. While funding and support from the highest levels of government are critical, for us to stand a chance of thwarting threat actors in their tracks, it will take a global push to rewrite the story on security culture.

There is a long road ahead, but it starts with every software vendor taking the first brave step toward security accountability at the organizational level.