Certified security awareness: An Executive Order to elevate developers
If there is such a thing as divine timing, then it must be said that the Biden Administration nailed it with their Executive Order (EO) announcement, addressing the US government’s plan to harden federal networks, as well as improve cybersecurity standards and best practices across the nation. This strategy follows two recent, devastating cyberattacks: the ongoing supply-chain breach from SolarWinds, in addition to the Colonial Pipeline gas infrastructure attack.
While these events undoubtedly caused ripples throughout every level of government, this directive marks an exciting time for the future of cybersecurity. It seems we are finally getting serious about protecting our digital existence right from the top, and there is no better time to push for better standards and higher quality software than now.
The EO touches on many aspects of functional cybersecurity, but for the first time, specifically outlines the impact of developers, and the need for them to have verified security skills and awareness. For years, we have shouted from the rooftops that this is the way forward to combat the common vulnerabilities that so often trip us up, and for government mandates to align with this approach is the path to widespread success in cyber defense.
How should organizations - and federal departments alike - respond to this order? Let’s unpack some main categories.
‘Tick-the-box’ is off the table.
We’ve long pointed out the ineffectiveness of most types of cybersecurity training for developers. It’s often too generic, not delivered in a way that engages and inspires the desired result (read: more secure code), and is touched upon far too infrequently. Worse still, a lot of companies are content with “tick-the-box” training: an approach that delivers the bare minimum, “one and done” basics to fulfill an operational requirement and get a tick next to a developer’s name. These education strategies are what keeps every CISO on a knife edge, crossing their fingers and hoping their company won’t be the victim of the next zero-day breach. They simply do not work to reduce vulnerabilities and create higher-quality code.
In section 4 of Biden’s mandate, the need for an organization to demonstrate that their developers display documented, verified security compliance is made clear:
“The guidelines shall include criteria that can be used to evaluate software security, include criteria to evaluate the security practices of the developers and suppliers themselves, and identify innovative tools or methods to demonstrate conformance with secure practices.”
There’s a slight problem with that: no industry-standard certification specific to developers currently exists. To be able to benchmark the secure coding skill level of developers, and work with courses and assessments to improve those skills is fundamental, allowing companies to set goals and achieve compliance. When developers can show core competencies in a practical, hands-on environment, this can be assessed and certified in a meaningful, trustworthy way. It’s core to our offering at Secure Code Warrior, and we’ve worked hard to create a system that can be utilized for reliable certification that is customizable to their tech stack and organizational requirements.
These skills are valuable, and they cannot be automated. Certification can transform developers into a security-aware force that can defend the codebase against insidious threats.
A focus on developer tooling (and tools in general).
In addition to guidelines around verifying secure coding practices, the EO does quite a deep dive into the automation and tooling side of security.
There is simply too much code being produced for humans to handle alone from a security perspective, and automation - as part of an extensive tech stack - is a major part of every security program, as it should be. However, not all tools are created equal, and there is no “one tool to rule them all” that will pick up every vulnerability, in every programming language. A great security program takes a nuanced approach, especially when it comes to developer-targeted tools and services.
Section 3 of the EO outlines the expectations for vendors creating software that is eligible for use by the federal government, and instructive guidelines around the use of tools in the development process:
“ (iii) employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code;
(iv) employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release.”
Security tools in the developer tech stack are one of the ways to improve security best practices at speed, ensuring that releases have the best chance of meeting deadlines and not being held up by security bugs and other showstoppers. The thing is, however, that developers will still need contextual learning to make the best use of the most powerful tools. For them to understand what has been flagged, why it’s dangerous, and how to remediate it is crucial, and will lead to fewer mistakes for tools to identify in the first place.
The best tools will integrate with a developer’s environment, assisting them in producing higher quality (and more secure) code, and ensure security stays front-of-mind.
Securing the supply chain.
One of my favorite parts of the EO is the comprehensive plans to secure the software supply chain. This isn’t surprising, given the SolarWinds event, but it’s an important highlight:
“The security of software used by the Federal Government is vital to the Federal Government’s ability to perform its critical functions. The development of commercial software often lacks transparency, sufficient focus on the ability of the software to resist attack, and adequate controls to prevent tampering by malicious actors. There is a pressing need to implement more rigorous and predictable mechanisms for ensuring that products function securely, and as intended… the Federal Government must take action to rapidly improve the security and integrity of the software supply chain, with a priority on addressing critical software.”
This ruling will affect any software company looking to do business with the US government, but it should be applied as the standard everywhere. Lack of transparency from third-party vendors (not to mention developers making use of third-party components) over their security measures makes it incredibly difficult to assess, validate, and declare that cybersecurity best practices are being fulfilled. We must analyze the suppliers we use and the software they write. These actions may be seen as the “extra mile”, but they should be inherent to a gold standard of cybersecurity best practices.
Shipping secure code with confidence has been a pain point in our industry for a long time, but this is the perfect opportunity to evaluate current processes and lead the charge to hardened software and cloud infrastructure that is the envy of those left behind. Talk to us now and find out how you can leverage Courses, Assessments, and developer tools to certify your next team of security-aware developers.
The latest Executive Order from the US Federal Government touches on many aspects of functional cybersecurity, but for the first time, specifically outlines the impact of developers, and the need for them to have verified security skills and awareness.
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.
If there is such a thing as divine timing, then it must be said that the Biden Administration nailed it with their Executive Order (EO) announcement, addressing the US government’s plan to harden federal networks, as well as improve cybersecurity standards and best practices across the nation. This strategy follows two recent, devastating cyberattacks: the ongoing supply-chain breach from SolarWinds, in addition to the Colonial Pipeline gas infrastructure attack.
While these events undoubtedly caused ripples throughout every level of government, this directive marks an exciting time for the future of cybersecurity. It seems we are finally getting serious about protecting our digital existence right from the top, and there is no better time to push for better standards and higher quality software than now.
The EO touches on many aspects of functional cybersecurity, but for the first time, specifically outlines the impact of developers, and the need for them to have verified security skills and awareness. For years, we have shouted from the rooftops that this is the way forward to combat the common vulnerabilities that so often trip us up, and for government mandates to align with this approach is the path to widespread success in cyber defense.
How should organizations - and federal departments alike - respond to this order? Let’s unpack some main categories.
‘Tick-the-box’ is off the table.
We’ve long pointed out the ineffectiveness of most types of cybersecurity training for developers. It’s often too generic, not delivered in a way that engages and inspires the desired result (read: more secure code), and is touched upon far too infrequently. Worse still, a lot of companies are content with “tick-the-box” training: an approach that delivers the bare minimum, “one and done” basics to fulfill an operational requirement and get a tick next to a developer’s name. These education strategies are what keeps every CISO on a knife edge, crossing their fingers and hoping their company won’t be the victim of the next zero-day breach. They simply do not work to reduce vulnerabilities and create higher-quality code.
In section 4 of Biden’s mandate, the need for an organization to demonstrate that their developers display documented, verified security compliance is made clear:
“The guidelines shall include criteria that can be used to evaluate software security, include criteria to evaluate the security practices of the developers and suppliers themselves, and identify innovative tools or methods to demonstrate conformance with secure practices.”
There’s a slight problem with that: no industry-standard certification specific to developers currently exists. To be able to benchmark the secure coding skill level of developers, and work with courses and assessments to improve those skills is fundamental, allowing companies to set goals and achieve compliance. When developers can show core competencies in a practical, hands-on environment, this can be assessed and certified in a meaningful, trustworthy way. It’s core to our offering at Secure Code Warrior, and we’ve worked hard to create a system that can be utilized for reliable certification that is customizable to their tech stack and organizational requirements.
These skills are valuable, and they cannot be automated. Certification can transform developers into a security-aware force that can defend the codebase against insidious threats.
A focus on developer tooling (and tools in general).
In addition to guidelines around verifying secure coding practices, the EO does quite a deep dive into the automation and tooling side of security.
There is simply too much code being produced for humans to handle alone from a security perspective, and automation - as part of an extensive tech stack - is a major part of every security program, as it should be. However, not all tools are created equal, and there is no “one tool to rule them all” that will pick up every vulnerability, in every programming language. A great security program takes a nuanced approach, especially when it comes to developer-targeted tools and services.
Section 3 of the EO outlines the expectations for vendors creating software that is eligible for use by the federal government, and instructive guidelines around the use of tools in the development process:
“ (iii) employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code;
(iv) employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release.”
Security tools in the developer tech stack are one of the ways to improve security best practices at speed, ensuring that releases have the best chance of meeting deadlines and not being held up by security bugs and other showstoppers. The thing is, however, that developers will still need contextual learning to make the best use of the most powerful tools. For them to understand what has been flagged, why it’s dangerous, and how to remediate it is crucial, and will lead to fewer mistakes for tools to identify in the first place.
The best tools will integrate with a developer’s environment, assisting them in producing higher quality (and more secure) code, and ensure security stays front-of-mind.
Securing the supply chain.
One of my favorite parts of the EO is the comprehensive plans to secure the software supply chain. This isn’t surprising, given the SolarWinds event, but it’s an important highlight:
“The security of software used by the Federal Government is vital to the Federal Government’s ability to perform its critical functions. The development of commercial software often lacks transparency, sufficient focus on the ability of the software to resist attack, and adequate controls to prevent tampering by malicious actors. There is a pressing need to implement more rigorous and predictable mechanisms for ensuring that products function securely, and as intended… the Federal Government must take action to rapidly improve the security and integrity of the software supply chain, with a priority on addressing critical software.”
This ruling will affect any software company looking to do business with the US government, but it should be applied as the standard everywhere. Lack of transparency from third-party vendors (not to mention developers making use of third-party components) over their security measures makes it incredibly difficult to assess, validate, and declare that cybersecurity best practices are being fulfilled. We must analyze the suppliers we use and the software they write. These actions may be seen as the “extra mile”, but they should be inherent to a gold standard of cybersecurity best practices.
Shipping secure code with confidence has been a pain point in our industry for a long time, but this is the perfect opportunity to evaluate current processes and lead the charge to hardened software and cloud infrastructure that is the envy of those left behind. Talk to us now and find out how you can leverage Courses, Assessments, and developer tools to certify your next team of security-aware developers.
If there is such a thing as divine timing, then it must be said that the Biden Administration nailed it with their Executive Order (EO) announcement, addressing the US government’s plan to harden federal networks, as well as improve cybersecurity standards and best practices across the nation. This strategy follows two recent, devastating cyberattacks: the ongoing supply-chain breach from SolarWinds, in addition to the Colonial Pipeline gas infrastructure attack.
While these events undoubtedly caused ripples throughout every level of government, this directive marks an exciting time for the future of cybersecurity. It seems we are finally getting serious about protecting our digital existence right from the top, and there is no better time to push for better standards and higher quality software than now.
The EO touches on many aspects of functional cybersecurity, but for the first time, specifically outlines the impact of developers, and the need for them to have verified security skills and awareness. For years, we have shouted from the rooftops that this is the way forward to combat the common vulnerabilities that so often trip us up, and for government mandates to align with this approach is the path to widespread success in cyber defense.
How should organizations - and federal departments alike - respond to this order? Let’s unpack some main categories.
‘Tick-the-box’ is off the table.
We’ve long pointed out the ineffectiveness of most types of cybersecurity training for developers. It’s often too generic, not delivered in a way that engages and inspires the desired result (read: more secure code), and is touched upon far too infrequently. Worse still, a lot of companies are content with “tick-the-box” training: an approach that delivers the bare minimum, “one and done” basics to fulfill an operational requirement and get a tick next to a developer’s name. These education strategies are what keeps every CISO on a knife edge, crossing their fingers and hoping their company won’t be the victim of the next zero-day breach. They simply do not work to reduce vulnerabilities and create higher-quality code.
In section 4 of Biden’s mandate, the need for an organization to demonstrate that their developers display documented, verified security compliance is made clear:
“The guidelines shall include criteria that can be used to evaluate software security, include criteria to evaluate the security practices of the developers and suppliers themselves, and identify innovative tools or methods to demonstrate conformance with secure practices.”
There’s a slight problem with that: no industry-standard certification specific to developers currently exists. To be able to benchmark the secure coding skill level of developers, and work with courses and assessments to improve those skills is fundamental, allowing companies to set goals and achieve compliance. When developers can show core competencies in a practical, hands-on environment, this can be assessed and certified in a meaningful, trustworthy way. It’s core to our offering at Secure Code Warrior, and we’ve worked hard to create a system that can be utilized for reliable certification that is customizable to their tech stack and organizational requirements.
These skills are valuable, and they cannot be automated. Certification can transform developers into a security-aware force that can defend the codebase against insidious threats.
A focus on developer tooling (and tools in general).
In addition to guidelines around verifying secure coding practices, the EO does quite a deep dive into the automation and tooling side of security.
There is simply too much code being produced for humans to handle alone from a security perspective, and automation - as part of an extensive tech stack - is a major part of every security program, as it should be. However, not all tools are created equal, and there is no “one tool to rule them all” that will pick up every vulnerability, in every programming language. A great security program takes a nuanced approach, especially when it comes to developer-targeted tools and services.
Section 3 of the EO outlines the expectations for vendors creating software that is eligible for use by the federal government, and instructive guidelines around the use of tools in the development process:
“ (iii) employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code;
(iv) employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release.”
Security tools in the developer tech stack are one of the ways to improve security best practices at speed, ensuring that releases have the best chance of meeting deadlines and not being held up by security bugs and other showstoppers. The thing is, however, that developers will still need contextual learning to make the best use of the most powerful tools. For them to understand what has been flagged, why it’s dangerous, and how to remediate it is crucial, and will lead to fewer mistakes for tools to identify in the first place.
The best tools will integrate with a developer’s environment, assisting them in producing higher quality (and more secure) code, and ensure security stays front-of-mind.
Securing the supply chain.
One of my favorite parts of the EO is the comprehensive plans to secure the software supply chain. This isn’t surprising, given the SolarWinds event, but it’s an important highlight:
“The security of software used by the Federal Government is vital to the Federal Government’s ability to perform its critical functions. The development of commercial software often lacks transparency, sufficient focus on the ability of the software to resist attack, and adequate controls to prevent tampering by malicious actors. There is a pressing need to implement more rigorous and predictable mechanisms for ensuring that products function securely, and as intended… the Federal Government must take action to rapidly improve the security and integrity of the software supply chain, with a priority on addressing critical software.”
This ruling will affect any software company looking to do business with the US government, but it should be applied as the standard everywhere. Lack of transparency from third-party vendors (not to mention developers making use of third-party components) over their security measures makes it incredibly difficult to assess, validate, and declare that cybersecurity best practices are being fulfilled. We must analyze the suppliers we use and the software they write. These actions may be seen as the “extra mile”, but they should be inherent to a gold standard of cybersecurity best practices.
Shipping secure code with confidence has been a pain point in our industry for a long time, but this is the perfect opportunity to evaluate current processes and lead the charge to hardened software and cloud infrastructure that is the envy of those left behind. Talk to us now and find out how you can leverage Courses, Assessments, and developer tools to certify your next team of security-aware developers.
Chief Executive Officer, Chairman, and Co-Founder
Click on the link below and download the PDF of this one pager.
DownloadSecure 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.
If there is such a thing as divine timing, then it must be said that the Biden Administration nailed it with their Executive Order (EO) announcement, addressing the US government’s plan to harden federal networks, as well as improve cybersecurity standards and best practices across the nation. This strategy follows two recent, devastating cyberattacks: the ongoing supply-chain breach from SolarWinds, in addition to the Colonial Pipeline gas infrastructure attack.
While these events undoubtedly caused ripples throughout every level of government, this directive marks an exciting time for the future of cybersecurity. It seems we are finally getting serious about protecting our digital existence right from the top, and there is no better time to push for better standards and higher quality software than now.
The EO touches on many aspects of functional cybersecurity, but for the first time, specifically outlines the impact of developers, and the need for them to have verified security skills and awareness. For years, we have shouted from the rooftops that this is the way forward to combat the common vulnerabilities that so often trip us up, and for government mandates to align with this approach is the path to widespread success in cyber defense.
How should organizations - and federal departments alike - respond to this order? Let’s unpack some main categories.
‘Tick-the-box’ is off the table.
We’ve long pointed out the ineffectiveness of most types of cybersecurity training for developers. It’s often too generic, not delivered in a way that engages and inspires the desired result (read: more secure code), and is touched upon far too infrequently. Worse still, a lot of companies are content with “tick-the-box” training: an approach that delivers the bare minimum, “one and done” basics to fulfill an operational requirement and get a tick next to a developer’s name. These education strategies are what keeps every CISO on a knife edge, crossing their fingers and hoping their company won’t be the victim of the next zero-day breach. They simply do not work to reduce vulnerabilities and create higher-quality code.
In section 4 of Biden’s mandate, the need for an organization to demonstrate that their developers display documented, verified security compliance is made clear:
“The guidelines shall include criteria that can be used to evaluate software security, include criteria to evaluate the security practices of the developers and suppliers themselves, and identify innovative tools or methods to demonstrate conformance with secure practices.”
There’s a slight problem with that: no industry-standard certification specific to developers currently exists. To be able to benchmark the secure coding skill level of developers, and work with courses and assessments to improve those skills is fundamental, allowing companies to set goals and achieve compliance. When developers can show core competencies in a practical, hands-on environment, this can be assessed and certified in a meaningful, trustworthy way. It’s core to our offering at Secure Code Warrior, and we’ve worked hard to create a system that can be utilized for reliable certification that is customizable to their tech stack and organizational requirements.
These skills are valuable, and they cannot be automated. Certification can transform developers into a security-aware force that can defend the codebase against insidious threats.
A focus on developer tooling (and tools in general).
In addition to guidelines around verifying secure coding practices, the EO does quite a deep dive into the automation and tooling side of security.
There is simply too much code being produced for humans to handle alone from a security perspective, and automation - as part of an extensive tech stack - is a major part of every security program, as it should be. However, not all tools are created equal, and there is no “one tool to rule them all” that will pick up every vulnerability, in every programming language. A great security program takes a nuanced approach, especially when it comes to developer-targeted tools and services.
Section 3 of the EO outlines the expectations for vendors creating software that is eligible for use by the federal government, and instructive guidelines around the use of tools in the development process:
“ (iii) employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code;
(iv) employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release.”
Security tools in the developer tech stack are one of the ways to improve security best practices at speed, ensuring that releases have the best chance of meeting deadlines and not being held up by security bugs and other showstoppers. The thing is, however, that developers will still need contextual learning to make the best use of the most powerful tools. For them to understand what has been flagged, why it’s dangerous, and how to remediate it is crucial, and will lead to fewer mistakes for tools to identify in the first place.
The best tools will integrate with a developer’s environment, assisting them in producing higher quality (and more secure) code, and ensure security stays front-of-mind.
Securing the supply chain.
One of my favorite parts of the EO is the comprehensive plans to secure the software supply chain. This isn’t surprising, given the SolarWinds event, but it’s an important highlight:
“The security of software used by the Federal Government is vital to the Federal Government’s ability to perform its critical functions. The development of commercial software often lacks transparency, sufficient focus on the ability of the software to resist attack, and adequate controls to prevent tampering by malicious actors. There is a pressing need to implement more rigorous and predictable mechanisms for ensuring that products function securely, and as intended… the Federal Government must take action to rapidly improve the security and integrity of the software supply chain, with a priority on addressing critical software.”
This ruling will affect any software company looking to do business with the US government, but it should be applied as the standard everywhere. Lack of transparency from third-party vendors (not to mention developers making use of third-party components) over their security measures makes it incredibly difficult to assess, validate, and declare that cybersecurity best practices are being fulfilled. We must analyze the suppliers we use and the software they write. These actions may be seen as the “extra mile”, but they should be inherent to a gold standard of cybersecurity best practices.
Shipping secure code with confidence has been a pain point in our industry for a long time, but this is the perfect opportunity to evaluate current processes and lead the charge to hardened software and cloud infrastructure that is the envy of those left behind. Talk to us now and find out how you can leverage Courses, Assessments, and developer tools to certify your next team of security-aware developers.
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
DigitalOcean Decreases Security Debt with Secure Code Warrior
DigitalOcean's use of Secure Code Warrior training has significantly reduced security debt, allowing teams to focus more on innovation and productivity. The improved security has strengthened their product quality and competitive edge. Looking ahead, the SCW Trust Score will help them further enhance security practices and continue driving innovation.
Resources to get you started
Coders Conquer Security: Share & Learn - Cross-Site Scripting (XSS)
Cross-site scripting (XSS) uses the trust of browsers and ignorance of users to steal data, take over accounts, and deface websites; it's a vulnerability that can get very ugly, very quickly. Let's take a look at how XSS works, what damage can be done, and how to prevent it.
Coders Conquer Security: Share & Learn - Cross-Site Scripting (XSS)
Cross-site scripting (XSS) uses the trust of browsers and ignorance of users to steal data, take over accounts, and deface websites; it's a vulnerability that can get very ugly, very quickly. Let's take a look at how XSS works, what damage can be done, and how to prevent it.