The new NIST guidelines: Why customized training is essential to create secure software
On June 11, 2019, the National Institute of Standards & Technology (NIST) released an updated white paper, detailing several action plans for reducing software vulnerabilities and cyber risk. Titled Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF), NIST provides organizations solid guidelines to avoid the nasty - not to mention expensive - consequences of a data breach.
It is important to note that the SSDF is deliberately generic, it does not assume every organization has the exact same software security goals, nor does it prescribe an exact mechanism for achieving them. The main objective is implementing security best practices. As is stated by the writer, Donna Dodson: "While the desire is for each security producer to follow all applicable practices, the expectation is that the degree to which each practice is implemented will vary based on the producer's security assumptions. The practices provide flexibility for implementers, but they are also clear to avoid leaving too much open to interpretation".
Of particular interest to me, of course, were the specific inclusions around software security training for developers. Now, we have known for a long time that developers need adequate training if they are to defend an organization from the very beginning of the software development process... but what is adequate, exactly? There are a lot of differing opinions out there. However, I think the envelope is finally being pushed in a direction that will ignite significant positive results.
There's security training... and there's effective security training.
I have spoken at length about the need for software security training to be more effectively implemented, engaged with and tailored to the needs of the developer. Even now, in many organizations, it's a "tick-the-box" exercise at best. Perhaps there are a few hours of video training, or even precious time spent off the tools for some classroom-based learning. The fact there are large-scale data breaches every other day, perpetrated by attackers who are exploiting well-known (and usually, easily fixed) vulnerabilities is evidence that software security training isn't anywhere near as effective as it needs to be. And, perhaps most importantly, there is very little in place to verify whether the training was effective at all: are vulnerabilities fixed faster? are vulnerabilities reducing in code? Have people actually completed the training, or have they just clicked "next" to complete it?
Developers are busy people, working hard to deliver to strict deadlines. Security is an inconvenience a lot of the time, and rarely are they equipped with the knowledge during their education to successfully mitigate cyber risk. The word "security" usually comes up when a member of the AppSec team is pointing out flaws in their work, making for a rather cold and dysfunctional relationship. A "your baby is ugly; go fix it" scenario.
What does this tell us? It's a decades-old red flag that we are not doing enough to win developers over on security; they are not motivated to take responsibility, nor seek out the tools they need to create software that is functional, yet made with security best practice in mind.
Developers are clever, creative and love to solve problems. It is quite unlikely that watching endless videos on security vulnerabilities is going to excite them, or help them remain engaged. In my time as a SANS instructor, I learned very quickly that the best training is hands-on, forcing them to analyze and be challenged intellectually, using real-world examples that test their brain and build on prior learning. Gamification and friendly competition are also powerful tools to get everyone on-board with new concepts, while remaining useful and practical in application.
NIST's guidelines specify: "Provide role-specific training for all personnel in roles with responsibilities that contribute to secure development. Periodically review role-specific training and update it as needed." And later: "Define roles and responsibilities for cybersecurity staff, security champions, senior management, software developers, product owners, and others involved in the SDLC."
This statement, while not specific on the type of training, is still helping to shift organizations left and help keep security best practice front-of-mind. It is putting the onus on finding effective, more specific training solutions back onto the company, and this will hopefully result in developers being armed with the right tools and knowledge to succeed.
Culture: the missing link.
Even if an organization is putting time and resources into training developers and other key staff, placing emphasis on their role in preventing vulnerabilities and reducing security risk, the effort can often go to waste if the security culture of an organization remains fundamentally broken.
When individuals are trained effectively, with goals set and expectations clear, it becomes far easier for them to understand their place in the security landscape and take responsibility where appropriate. In the case of developers especially, they're given the tools and knowledge to write secure code from the beginning. However, this is best orchestrated in a positive security environment, where there is less double-handling, finger-pointing and siloed project work.
Security must be front-of-mind for the entire organization, with a supportive and collaborative commitment to delivering great, secure software. This will mean budgets are adequate to roll out fun, engaging training that utilizes real-world code vulnerabilities, and buy-in across the organization to keep the momentum going. In this constantly evolving digital landscape, training must be as continuous as delivery. If you've been told in the past that "one-time" or "set and forget" compliance training is adequate or effective, this is a fallacy.
While this new NIST framework does not specifically articulate the requirement to nurture a positive security culture, adhering successfully to their guidelines will most certainly require one. They do note, however, that organizations should, "Define policies that specify the security requirements for the organization's software to meet, including secure coding practices for developers to follow".
The above is vital to scale and hone security skills within teams, and it may be helpful to consider the following when assessing your own policies and current AppSec climate:
- Are software security guidelines and expectations clearly defined?
- Is everyone clear on the role they play in achieving them?
- Is the training frequent and assessed?
- Are your developers aware of the huge role they can play in eliminating common security bugs before they happen?
Now, that last part is, as I have said, largely up to the organization and the training they choose. It must be relevant, it must be frequent, it must be engaging. Find a solution that can be applied to their everyday work and contextually build their knowledge.
What now?
A deep-dive into these new guidelines is likely to be fairly overwhelming; it really does take a village to create, verify and deploy the iron-clad secure software most businesses need, in the most secure way possible. It's not just about training, either. There are guidelines to consider when using third-party software (using components with known vulnerabilities still sits in the OWASP Top 10, after all), suggestions around verification, penetration testing, and code review, as well as guidelines for security record-keeping, appropriate toolchains and everything else. Actionable insights for the whole picture can be found in Dr. Gary McGraw's BSIMM model, which is referenced throughout NIST's document.
However, the quickest win can be achieved if your developers are empowered with the right tools and knowledge to truly succeed in building secure software from the start. It's cheaper for the business (and faster overall) to stop common vulnerabilities from popping up in later stages of the SDLC, time and time again. Play to their strengths and offer an incentive to get involved with the security side of the organization. It really can be fun, and they can be the just-in-time heroes you need to keep the bad guys out, and our data safe.
References:
The National Institute of Standards & Technology (NIST) released an updated white paper, detailing several action plans for reducing software vulnerabilities and cyber risk.
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 demo
Chief 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.
On June 11, 2019, the National Institute of Standards & Technology (NIST) released an updated white paper, detailing several action plans for reducing software vulnerabilities and cyber risk. Titled Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF), NIST provides organizations solid guidelines to avoid the nasty - not to mention expensive - consequences of a data breach.
It is important to note that the SSDF is deliberately generic, it does not assume every organization has the exact same software security goals, nor does it prescribe an exact mechanism for achieving them. The main objective is implementing security best practices. As is stated by the writer, Donna Dodson: "While the desire is for each security producer to follow all applicable practices, the expectation is that the degree to which each practice is implemented will vary based on the producer's security assumptions. The practices provide flexibility for implementers, but they are also clear to avoid leaving too much open to interpretation".
Of particular interest to me, of course, were the specific inclusions around software security training for developers. Now, we have known for a long time that developers need adequate training if they are to defend an organization from the very beginning of the software development process... but what is adequate, exactly? There are a lot of differing opinions out there. However, I think the envelope is finally being pushed in a direction that will ignite significant positive results.
There's security training... and there's effective security training.
I have spoken at length about the need for software security training to be more effectively implemented, engaged with and tailored to the needs of the developer. Even now, in many organizations, it's a "tick-the-box" exercise at best. Perhaps there are a few hours of video training, or even precious time spent off the tools for some classroom-based learning. The fact there are large-scale data breaches every other day, perpetrated by attackers who are exploiting well-known (and usually, easily fixed) vulnerabilities is evidence that software security training isn't anywhere near as effective as it needs to be. And, perhaps most importantly, there is very little in place to verify whether the training was effective at all: are vulnerabilities fixed faster? are vulnerabilities reducing in code? Have people actually completed the training, or have they just clicked "next" to complete it?
Developers are busy people, working hard to deliver to strict deadlines. Security is an inconvenience a lot of the time, and rarely are they equipped with the knowledge during their education to successfully mitigate cyber risk. The word "security" usually comes up when a member of the AppSec team is pointing out flaws in their work, making for a rather cold and dysfunctional relationship. A "your baby is ugly; go fix it" scenario.
What does this tell us? It's a decades-old red flag that we are not doing enough to win developers over on security; they are not motivated to take responsibility, nor seek out the tools they need to create software that is functional, yet made with security best practice in mind.
Developers are clever, creative and love to solve problems. It is quite unlikely that watching endless videos on security vulnerabilities is going to excite them, or help them remain engaged. In my time as a SANS instructor, I learned very quickly that the best training is hands-on, forcing them to analyze and be challenged intellectually, using real-world examples that test their brain and build on prior learning. Gamification and friendly competition are also powerful tools to get everyone on-board with new concepts, while remaining useful and practical in application.
NIST's guidelines specify: "Provide role-specific training for all personnel in roles with responsibilities that contribute to secure development. Periodically review role-specific training and update it as needed." And later: "Define roles and responsibilities for cybersecurity staff, security champions, senior management, software developers, product owners, and others involved in the SDLC."
This statement, while not specific on the type of training, is still helping to shift organizations left and help keep security best practice front-of-mind. It is putting the onus on finding effective, more specific training solutions back onto the company, and this will hopefully result in developers being armed with the right tools and knowledge to succeed.
Culture: the missing link.
Even if an organization is putting time and resources into training developers and other key staff, placing emphasis on their role in preventing vulnerabilities and reducing security risk, the effort can often go to waste if the security culture of an organization remains fundamentally broken.
When individuals are trained effectively, with goals set and expectations clear, it becomes far easier for them to understand their place in the security landscape and take responsibility where appropriate. In the case of developers especially, they're given the tools and knowledge to write secure code from the beginning. However, this is best orchestrated in a positive security environment, where there is less double-handling, finger-pointing and siloed project work.
Security must be front-of-mind for the entire organization, with a supportive and collaborative commitment to delivering great, secure software. This will mean budgets are adequate to roll out fun, engaging training that utilizes real-world code vulnerabilities, and buy-in across the organization to keep the momentum going. In this constantly evolving digital landscape, training must be as continuous as delivery. If you've been told in the past that "one-time" or "set and forget" compliance training is adequate or effective, this is a fallacy.
While this new NIST framework does not specifically articulate the requirement to nurture a positive security culture, adhering successfully to their guidelines will most certainly require one. They do note, however, that organizations should, "Define policies that specify the security requirements for the organization's software to meet, including secure coding practices for developers to follow".
The above is vital to scale and hone security skills within teams, and it may be helpful to consider the following when assessing your own policies and current AppSec climate:
- Are software security guidelines and expectations clearly defined?
- Is everyone clear on the role they play in achieving them?
- Is the training frequent and assessed?
- Are your developers aware of the huge role they can play in eliminating common security bugs before they happen?
Now, that last part is, as I have said, largely up to the organization and the training they choose. It must be relevant, it must be frequent, it must be engaging. Find a solution that can be applied to their everyday work and contextually build their knowledge.
What now?
A deep-dive into these new guidelines is likely to be fairly overwhelming; it really does take a village to create, verify and deploy the iron-clad secure software most businesses need, in the most secure way possible. It's not just about training, either. There are guidelines to consider when using third-party software (using components with known vulnerabilities still sits in the OWASP Top 10, after all), suggestions around verification, penetration testing, and code review, as well as guidelines for security record-keeping, appropriate toolchains and everything else. Actionable insights for the whole picture can be found in Dr. Gary McGraw's BSIMM model, which is referenced throughout NIST's document.
However, the quickest win can be achieved if your developers are empowered with the right tools and knowledge to truly succeed in building secure software from the start. It's cheaper for the business (and faster overall) to stop common vulnerabilities from popping up in later stages of the SDLC, time and time again. Play to their strengths and offer an incentive to get involved with the security side of the organization. It really can be fun, and they can be the just-in-time heroes you need to keep the bad guys out, and our data safe.
References:
On June 11, 2019, the National Institute of Standards & Technology (NIST) released an updated white paper, detailing several action plans for reducing software vulnerabilities and cyber risk. Titled Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF), NIST provides organizations solid guidelines to avoid the nasty - not to mention expensive - consequences of a data breach.
It is important to note that the SSDF is deliberately generic, it does not assume every organization has the exact same software security goals, nor does it prescribe an exact mechanism for achieving them. The main objective is implementing security best practices. As is stated by the writer, Donna Dodson: "While the desire is for each security producer to follow all applicable practices, the expectation is that the degree to which each practice is implemented will vary based on the producer's security assumptions. The practices provide flexibility for implementers, but they are also clear to avoid leaving too much open to interpretation".
Of particular interest to me, of course, were the specific inclusions around software security training for developers. Now, we have known for a long time that developers need adequate training if they are to defend an organization from the very beginning of the software development process... but what is adequate, exactly? There are a lot of differing opinions out there. However, I think the envelope is finally being pushed in a direction that will ignite significant positive results.
There's security training... and there's effective security training.
I have spoken at length about the need for software security training to be more effectively implemented, engaged with and tailored to the needs of the developer. Even now, in many organizations, it's a "tick-the-box" exercise at best. Perhaps there are a few hours of video training, or even precious time spent off the tools for some classroom-based learning. The fact there are large-scale data breaches every other day, perpetrated by attackers who are exploiting well-known (and usually, easily fixed) vulnerabilities is evidence that software security training isn't anywhere near as effective as it needs to be. And, perhaps most importantly, there is very little in place to verify whether the training was effective at all: are vulnerabilities fixed faster? are vulnerabilities reducing in code? Have people actually completed the training, or have they just clicked "next" to complete it?
Developers are busy people, working hard to deliver to strict deadlines. Security is an inconvenience a lot of the time, and rarely are they equipped with the knowledge during their education to successfully mitigate cyber risk. The word "security" usually comes up when a member of the AppSec team is pointing out flaws in their work, making for a rather cold and dysfunctional relationship. A "your baby is ugly; go fix it" scenario.
What does this tell us? It's a decades-old red flag that we are not doing enough to win developers over on security; they are not motivated to take responsibility, nor seek out the tools they need to create software that is functional, yet made with security best practice in mind.
Developers are clever, creative and love to solve problems. It is quite unlikely that watching endless videos on security vulnerabilities is going to excite them, or help them remain engaged. In my time as a SANS instructor, I learned very quickly that the best training is hands-on, forcing them to analyze and be challenged intellectually, using real-world examples that test their brain and build on prior learning. Gamification and friendly competition are also powerful tools to get everyone on-board with new concepts, while remaining useful and practical in application.
NIST's guidelines specify: "Provide role-specific training for all personnel in roles with responsibilities that contribute to secure development. Periodically review role-specific training and update it as needed." And later: "Define roles and responsibilities for cybersecurity staff, security champions, senior management, software developers, product owners, and others involved in the SDLC."
This statement, while not specific on the type of training, is still helping to shift organizations left and help keep security best practice front-of-mind. It is putting the onus on finding effective, more specific training solutions back onto the company, and this will hopefully result in developers being armed with the right tools and knowledge to succeed.
Culture: the missing link.
Even if an organization is putting time and resources into training developers and other key staff, placing emphasis on their role in preventing vulnerabilities and reducing security risk, the effort can often go to waste if the security culture of an organization remains fundamentally broken.
When individuals are trained effectively, with goals set and expectations clear, it becomes far easier for them to understand their place in the security landscape and take responsibility where appropriate. In the case of developers especially, they're given the tools and knowledge to write secure code from the beginning. However, this is best orchestrated in a positive security environment, where there is less double-handling, finger-pointing and siloed project work.
Security must be front-of-mind for the entire organization, with a supportive and collaborative commitment to delivering great, secure software. This will mean budgets are adequate to roll out fun, engaging training that utilizes real-world code vulnerabilities, and buy-in across the organization to keep the momentum going. In this constantly evolving digital landscape, training must be as continuous as delivery. If you've been told in the past that "one-time" or "set and forget" compliance training is adequate or effective, this is a fallacy.
While this new NIST framework does not specifically articulate the requirement to nurture a positive security culture, adhering successfully to their guidelines will most certainly require one. They do note, however, that organizations should, "Define policies that specify the security requirements for the organization's software to meet, including secure coding practices for developers to follow".
The above is vital to scale and hone security skills within teams, and it may be helpful to consider the following when assessing your own policies and current AppSec climate:
- Are software security guidelines and expectations clearly defined?
- Is everyone clear on the role they play in achieving them?
- Is the training frequent and assessed?
- Are your developers aware of the huge role they can play in eliminating common security bugs before they happen?
Now, that last part is, as I have said, largely up to the organization and the training they choose. It must be relevant, it must be frequent, it must be engaging. Find a solution that can be applied to their everyday work and contextually build their knowledge.
What now?
A deep-dive into these new guidelines is likely to be fairly overwhelming; it really does take a village to create, verify and deploy the iron-clad secure software most businesses need, in the most secure way possible. It's not just about training, either. There are guidelines to consider when using third-party software (using components with known vulnerabilities still sits in the OWASP Top 10, after all), suggestions around verification, penetration testing, and code review, as well as guidelines for security record-keeping, appropriate toolchains and everything else. Actionable insights for the whole picture can be found in Dr. Gary McGraw's BSIMM model, which is referenced throughout NIST's document.
However, the quickest win can be achieved if your developers are empowered with the right tools and knowledge to truly succeed in building secure software from the start. It's cheaper for the business (and faster overall) to stop common vulnerabilities from popping up in later stages of the SDLC, time and time again. Play to their strengths and offer an incentive to get involved with the security side of the organization. It really can be fun, and they can be the just-in-time heroes you need to keep the bad guys out, and our data safe.
References:
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 demo
Chief 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.
On June 11, 2019, the National Institute of Standards & Technology (NIST) released an updated white paper, detailing several action plans for reducing software vulnerabilities and cyber risk. Titled Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF), NIST provides organizations solid guidelines to avoid the nasty - not to mention expensive - consequences of a data breach.
It is important to note that the SSDF is deliberately generic, it does not assume every organization has the exact same software security goals, nor does it prescribe an exact mechanism for achieving them. The main objective is implementing security best practices. As is stated by the writer, Donna Dodson: "While the desire is for each security producer to follow all applicable practices, the expectation is that the degree to which each practice is implemented will vary based on the producer's security assumptions. The practices provide flexibility for implementers, but they are also clear to avoid leaving too much open to interpretation".
Of particular interest to me, of course, were the specific inclusions around software security training for developers. Now, we have known for a long time that developers need adequate training if they are to defend an organization from the very beginning of the software development process... but what is adequate, exactly? There are a lot of differing opinions out there. However, I think the envelope is finally being pushed in a direction that will ignite significant positive results.
There's security training... and there's effective security training.
I have spoken at length about the need for software security training to be more effectively implemented, engaged with and tailored to the needs of the developer. Even now, in many organizations, it's a "tick-the-box" exercise at best. Perhaps there are a few hours of video training, or even precious time spent off the tools for some classroom-based learning. The fact there are large-scale data breaches every other day, perpetrated by attackers who are exploiting well-known (and usually, easily fixed) vulnerabilities is evidence that software security training isn't anywhere near as effective as it needs to be. And, perhaps most importantly, there is very little in place to verify whether the training was effective at all: are vulnerabilities fixed faster? are vulnerabilities reducing in code? Have people actually completed the training, or have they just clicked "next" to complete it?
Developers are busy people, working hard to deliver to strict deadlines. Security is an inconvenience a lot of the time, and rarely are they equipped with the knowledge during their education to successfully mitigate cyber risk. The word "security" usually comes up when a member of the AppSec team is pointing out flaws in their work, making for a rather cold and dysfunctional relationship. A "your baby is ugly; go fix it" scenario.
What does this tell us? It's a decades-old red flag that we are not doing enough to win developers over on security; they are not motivated to take responsibility, nor seek out the tools they need to create software that is functional, yet made with security best practice in mind.
Developers are clever, creative and love to solve problems. It is quite unlikely that watching endless videos on security vulnerabilities is going to excite them, or help them remain engaged. In my time as a SANS instructor, I learned very quickly that the best training is hands-on, forcing them to analyze and be challenged intellectually, using real-world examples that test their brain and build on prior learning. Gamification and friendly competition are also powerful tools to get everyone on-board with new concepts, while remaining useful and practical in application.
NIST's guidelines specify: "Provide role-specific training for all personnel in roles with responsibilities that contribute to secure development. Periodically review role-specific training and update it as needed." And later: "Define roles and responsibilities for cybersecurity staff, security champions, senior management, software developers, product owners, and others involved in the SDLC."
This statement, while not specific on the type of training, is still helping to shift organizations left and help keep security best practice front-of-mind. It is putting the onus on finding effective, more specific training solutions back onto the company, and this will hopefully result in developers being armed with the right tools and knowledge to succeed.
Culture: the missing link.
Even if an organization is putting time and resources into training developers and other key staff, placing emphasis on their role in preventing vulnerabilities and reducing security risk, the effort can often go to waste if the security culture of an organization remains fundamentally broken.
When individuals are trained effectively, with goals set and expectations clear, it becomes far easier for them to understand their place in the security landscape and take responsibility where appropriate. In the case of developers especially, they're given the tools and knowledge to write secure code from the beginning. However, this is best orchestrated in a positive security environment, where there is less double-handling, finger-pointing and siloed project work.
Security must be front-of-mind for the entire organization, with a supportive and collaborative commitment to delivering great, secure software. This will mean budgets are adequate to roll out fun, engaging training that utilizes real-world code vulnerabilities, and buy-in across the organization to keep the momentum going. In this constantly evolving digital landscape, training must be as continuous as delivery. If you've been told in the past that "one-time" or "set and forget" compliance training is adequate or effective, this is a fallacy.
While this new NIST framework does not specifically articulate the requirement to nurture a positive security culture, adhering successfully to their guidelines will most certainly require one. They do note, however, that organizations should, "Define policies that specify the security requirements for the organization's software to meet, including secure coding practices for developers to follow".
The above is vital to scale and hone security skills within teams, and it may be helpful to consider the following when assessing your own policies and current AppSec climate:
- Are software security guidelines and expectations clearly defined?
- Is everyone clear on the role they play in achieving them?
- Is the training frequent and assessed?
- Are your developers aware of the huge role they can play in eliminating common security bugs before they happen?
Now, that last part is, as I have said, largely up to the organization and the training they choose. It must be relevant, it must be frequent, it must be engaging. Find a solution that can be applied to their everyday work and contextually build their knowledge.
What now?
A deep-dive into these new guidelines is likely to be fairly overwhelming; it really does take a village to create, verify and deploy the iron-clad secure software most businesses need, in the most secure way possible. It's not just about training, either. There are guidelines to consider when using third-party software (using components with known vulnerabilities still sits in the OWASP Top 10, after all), suggestions around verification, penetration testing, and code review, as well as guidelines for security record-keeping, appropriate toolchains and everything else. Actionable insights for the whole picture can be found in Dr. Gary McGraw's BSIMM model, which is referenced throughout NIST's document.
However, the quickest win can be achieved if your developers are empowered with the right tools and knowledge to truly succeed in building secure software from the start. It's cheaper for the business (and faster overall) to stop common vulnerabilities from popping up in later stages of the SDLC, time and time again. Play to their strengths and offer an incentive to get involved with the security side of the organization. It really can be fun, and they can be the just-in-time heroes you need to keep the bad guys out, and our data safe.
References:
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
Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise
The Secure-by-Design movement is the future of secure software development. Learn about the key elements companies need to keep in mind when they think about a Secure-by-Design initiative.
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
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.
.png)
The Benefits of Benchmarking Security Skills for Developers
The growing focus on secure code and Secure-by-Design principles requires developers to be trained in cybersecurity from the start of the SDLC, with tools like Secure Code Warrior’s Trust Score helping measure and improve their progress.
Driving Meaningful Success for Enterprise Secure-by-Design Initiatives
Our latest research paper, Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise is the result of deep analysis of real Secure-by-Design initiatives at the enterprise level, and deriving best practice approaches based on data-driven findings.
Deep Dive: Navigating the Critical CUPS Vulnerability in GNU-Linux Systems
Discover the latest security challenges facing Linux users as we explore recent high-severity vulnerabilities in the Common UNIX Printing System (CUPS). Learn how these issues may lead to potential Remote Code Execution (RCE) and what you can do to protect your systems.
