Les nouvelles directives du NIST : pourquoi une formation personnalisée est essentielle pour créer des logiciels sécurisés
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:
Le National Institute of Standards & Technology (NIST) a publié un livre blanc actualisé, détaillant plusieurs plans d'action visant à réduire les vulnérabilités logicielles et les cyberrisques.
Chief Executive Officer, Chairman, and Co-Founder
Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démo
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:
Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Afficher le rapportRéservez une démo
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 des matières
Chief Executive Officer, Chairman, and Co-Founder
Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démoTéléchargerRessources pour vous aider à démarrer
Sujets et contenus de formation sur le code sécurisé
Notre contenu de pointe évolue constamment pour s'adapter à l'évolution constante du paysage du développement de logiciels tout en tenant compte de votre rôle. Des sujets couvrant tout, de l'IA à l'injection XQuery, proposés pour une variété de postes, allant des architectes aux ingénieurs en passant par les chefs de produit et l'assurance qualité. Découvrez un aperçu de ce que notre catalogue de contenu a à offrir par sujet et par rôle.
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
Ressources pour vous aider à démarrer
Cybermon est de retour : les missions d'IA Beat the Boss sont désormais disponibles à la demande
Cybermon 2025 Beat the Boss est désormais disponible toute l'année dans SCW. Déployez des défis de sécurité avancés liés à l'IA et au LLM pour renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyberrésilience : ce que cela signifie pour le développement de logiciels sécurisés dès la conception
Découvrez ce que la loi européenne sur la cyberrésilience (CRA) exige, à qui elle s'applique et comment les équipes d'ingénieurs peuvent se préparer grâce à des pratiques de sécurité dès la conception, à la prévention des vulnérabilités et au renforcement des capacités des développeurs.
Facilitateur 1 : Critères de réussite définis et mesurables
Enabler 1 donne le coup d'envoi de notre série en 10 parties intitulée Enablers of Success en montrant comment associer le codage sécurisé à des résultats commerciaux tels que la réduction des risques et la rapidité pour assurer la maturité à long terme des programmes.
