Proactive protection: Leveraging the National Cybersecurity Strategy for advanced threat prevention
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.
CISA's National Cybersecurity Strategy represents the best chance we have at raising software standards across the board and, finally, ushering in a new era of security-skilled developers.
Chief Executive Officer, Chairman, and Co-Founder
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoChief Executive Officer, Chairman, and Co-Founder
Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.
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.
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.
Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demoChief Executive Officer, Chairman, and Co-Founder
Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.
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.
Table of contents
Chief Executive Officer, Chairman, and Co-Founder
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Resources to get you started
10 Key Predictions: Secure Code Warrior on AI & Secure-by-Design’s Influence in 2025
Organizations are facing tough decisions on AI usage to support long-term productivity, sustainability, and security ROI. It’s become clear to us over the last few years that AI will never fully replace the role of the developer. From AI + developer partnerships to the increasing pressures (and confusion) around Secure-by-Design expectations, let’s take a closer look at what we can expect over the next year.
OWASP Top 10 For LLM Applications: What’s New, Changed, and How to Stay Secure
Stay ahead in securing LLM applications with the latest OWASP Top 10 updates. Discover what's new, what’s changed, and how Secure Code Warrior equips you with up-to-date learning resources to mitigate risks in Generative AI.
Trust Score Reveals the Value of Secure-by-Design Upskilling Initiatives
Our research has shown that secure code training works. Trust Score, using an algorithm drawing on more than 20 million learning data points from work by more than 250,000 learners at over 600 organizations, reveals its effectiveness in driving down vulnerabilities and how to make the initiative even more effective.
Reactive Versus Preventive Security: Prevention Is a Better Cure
The idea of bringing preventive security to legacy code and systems at the same time as newer applications can seem daunting, but a Secure-by-Design approach, enforced by upskilling developers, can apply security best practices to those systems. It’s the best chance many organizations have of improving their security postures.