Is your organization really DevSec-ready? Put it to the test.
We're barely half-way through 2020, and yet we're already on track to set a grim data breach record, seeing a 273% increase in stolen data as compared to the first half of 2019. These days, it's more accurate to ask how much data hasn't been stolen yet. With world events like the COVID-19 pandemic, these attacks have only increased in frequency and potency, with increasingly vulnerable targets.
This is something we have all known for a while: security is no longer optional, and our focus must be a pre-emptive strike. For that to be effective, everyone in the SDLC must be security-aware, especially developers. This is the "DevSec" part of DevSecOps, an ideal software development methodology for the climate, but many organizations are not fully prepared to execute this effectively.
With your organization in mind, think about these questions in the context of your role. How would it fare when put to the DevSec test?
DevSec Self-Assessment: Is your SDLC garden ready to bloom security-aware engineers?
- Is security front-of-mind in the internal development process?
A range of cybersecurity risk factors might be keeping the average CISO up at night, but the concerning reality is while many companies are making security more of a priority, their internal approach may not be robust enough to mitigate potential disaster (or, at least, massive headaches for the AppSec team and delayed shipment of software).
DevSecOps might be the current state of security nirvana, but few companies are working with this methodology. If you're still in Agile -- or even Waterfall -- then security is often still considered the domain of specialists that are far removed from the process and activated late in the SDLC, popping up to ruin a developer's day with hotfixes for their code. In an environment like this, it is going to be challenging to drive a DevSec culture: developers love and prioritize feature-building, and simply won't have had enough hands-on experience with security to see it as a desirable upskill pathway. In fact, their touchpoints with it may be ones of frustration and negativity. This must be remedied quickly to instill a front-of-mind approach for everyone involved in the software development process.
- Is your organization still playing catch-up when it comes to threat modeling?
It's a sobering statistic that 60% of SMBs go out of business within six months of a successful cyberattack, and much like other disasters, the impact is far greater without adequate planning.
Threat modeling is a crucial element of security best practices, allowing AppSec professionals to assess the full scope of the attack surface and structure appropriate defenses, countermeasures, and planning. In companies who have fully embraced DevSecOps, security is enabled early in the CI/CD pipeline, in such a way as to not slow down production as much as it may have in the past. Security, secure coding, and continuous delivery are all part of the process, and development teams are given the resources and exposure required to be major components of the engine spitting out air-tight code.
- Do development managers prioritize security best practices?
Whether they like it or not, development managers are role models for their team. And it's not just for the culture and vibe stuff, like wearing flip-flops to the office or how they "manage upwards". Their working priorities will inevitably be absorbed by their team members, and if security is not part of the key objectives, or planned for in terms of training and support, then the engineers underneath them will be missing out, and the business will be more at risk than it should be.
- Are developers given a reason to care about security?
In my experience, the fastest way to get someone offside is to tell them they have to do something that is foreign to their current approach, without telling them why.
Being told to "change" implies that the previous approach was wrong, when in many cases, it's simply an enhancement that will hopefully make things easier and more efficient later. To truly embrace the DevSec movement, developers need to be given a reason to care about security in the first place - after all, in most organizations, it is still very much "someone else's problem" (i.e. the AppSec wizards locked away in another room, far, far, away).
DevSecOps simply doesn't work if security is not a shared responsibility. Developers need the right tools, support and training to do their part... and this requires time to roll out and perfect as part of an overall security program. The worst approach is the one that overwhelms and alienates, which can be the case when developers have too many competing priorities and no help to manage them without sending themselves crazy. This is a cultural shift, and it's not overnight.
- Are you relying on a handful of magical security unicorns to take on the task of many?
Security professionals are in very short supply, and we need far more than are currently available. That is a given, but there is an increasing number of developers moving to more security-focused roles. Typically, they might be under titles like "security engineer" or "DevOps engineer" (slowly, we'll see this title morph into DevSecOps engineer, with any luck!). A gun DevOps engineer is able to develop features for virtually any application, while deploying using a true CI/CD pipeline. They do everything end-to-end, and usually come with a healthy dose of security awareness. In that sense, they are kind of magical, and rare as a result.
However, some companies make the mistake of hiring these specialist engineers, plopping them into a team and expecting they will be across all the security problems, at every stage of the development process, and this alone is the cure-all. Overburden your DevSecOps magicians, and you'll end up where you started - shipping insecure code without the checks, balances, and security precision they were hired to perform in the first place. It is of utmost importance that the development team in general is upskilled, and nurtured in a positive security environment so that they are equipped to share the load in a meaningful way.
Find the change you want to see in your organization.
If you implement robust training as part of your security program, you will uncover some hidden gems in your development cohort. These are the people who, despite any negative experiences they might have had in their day-to-day work, have something of a passion for secure coding and security best practices. These folks are prime candidates for security champions within the team; a point of contact between security and engineering who sets a great example for others, keeps awareness high, and helps with engagement initiatives. Their interpersonal skills are also very important in spreading security joy far and wide, and advocating for the developers'needs to management and the security team.
The "what's in it for me?" conversation is a positive step forward.
Even the noblest of humans need something of a "carrot" to dip their toe into unfamiliar territory, or an activity that may not have the most pleasant of learning curves.
Making the leap from "dev" to "DevSec" is an awesome boost for a developer's career. Security-aware developers have worked hard to understand security, take responsibility for it in the areas they can control, and operate with the understanding that the only quality code is secure code. Generally, developers want to improve, tackle new problems, and create enviable features that help them stand out among their peers. Give them a pathway to reach a higher level of software development, and it's a win-win situation.
It's never too late to build your DevSec dream team.
If you manage developers, lead an AppSec awareness team, or you're one of the many minds hard at work devising security program strategies, now is the time to go one better than "shifting" left. With the right training, tools, and environment, you can create a security incubator for developers that will pay great dividends for all parties. If this checklist has highlighted some areas for improvement, then you have a great opportunity to prepare your organization for a DevSec-led engineering department that can reduce risk from the very start of the SDLC.
With your organization in mind, think about these questions in the context of your role. How would it fare when put to the DevSec test?
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
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
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
We're barely half-way through 2020, and yet we're already on track to set a grim data breach record, seeing a 273% increase in stolen data as compared to the first half of 2019. These days, it's more accurate to ask how much data hasn't been stolen yet. With world events like the COVID-19 pandemic, these attacks have only increased in frequency and potency, with increasingly vulnerable targets.
This is something we have all known for a while: security is no longer optional, and our focus must be a pre-emptive strike. For that to be effective, everyone in the SDLC must be security-aware, especially developers. This is the "DevSec" part of DevSecOps, an ideal software development methodology for the climate, but many organizations are not fully prepared to execute this effectively.
With your organization in mind, think about these questions in the context of your role. How would it fare when put to the DevSec test?
DevSec Self-Assessment: Is your SDLC garden ready to bloom security-aware engineers?
- Is security front-of-mind in the internal development process?
A range of cybersecurity risk factors might be keeping the average CISO up at night, but the concerning reality is while many companies are making security more of a priority, their internal approach may not be robust enough to mitigate potential disaster (or, at least, massive headaches for the AppSec team and delayed shipment of software).
DevSecOps might be the current state of security nirvana, but few companies are working with this methodology. If you're still in Agile -- or even Waterfall -- then security is often still considered the domain of specialists that are far removed from the process and activated late in the SDLC, popping up to ruin a developer's day with hotfixes for their code. In an environment like this, it is going to be challenging to drive a DevSec culture: developers love and prioritize feature-building, and simply won't have had enough hands-on experience with security to see it as a desirable upskill pathway. In fact, their touchpoints with it may be ones of frustration and negativity. This must be remedied quickly to instill a front-of-mind approach for everyone involved in the software development process.
- Is your organization still playing catch-up when it comes to threat modeling?
It's a sobering statistic that 60% of SMBs go out of business within six months of a successful cyberattack, and much like other disasters, the impact is far greater without adequate planning.
Threat modeling is a crucial element of security best practices, allowing AppSec professionals to assess the full scope of the attack surface and structure appropriate defenses, countermeasures, and planning. In companies who have fully embraced DevSecOps, security is enabled early in the CI/CD pipeline, in such a way as to not slow down production as much as it may have in the past. Security, secure coding, and continuous delivery are all part of the process, and development teams are given the resources and exposure required to be major components of the engine spitting out air-tight code.
- Do development managers prioritize security best practices?
Whether they like it or not, development managers are role models for their team. And it's not just for the culture and vibe stuff, like wearing flip-flops to the office or how they "manage upwards". Their working priorities will inevitably be absorbed by their team members, and if security is not part of the key objectives, or planned for in terms of training and support, then the engineers underneath them will be missing out, and the business will be more at risk than it should be.
- Are developers given a reason to care about security?
In my experience, the fastest way to get someone offside is to tell them they have to do something that is foreign to their current approach, without telling them why.
Being told to "change" implies that the previous approach was wrong, when in many cases, it's simply an enhancement that will hopefully make things easier and more efficient later. To truly embrace the DevSec movement, developers need to be given a reason to care about security in the first place - after all, in most organizations, it is still very much "someone else's problem" (i.e. the AppSec wizards locked away in another room, far, far, away).
DevSecOps simply doesn't work if security is not a shared responsibility. Developers need the right tools, support and training to do their part... and this requires time to roll out and perfect as part of an overall security program. The worst approach is the one that overwhelms and alienates, which can be the case when developers have too many competing priorities and no help to manage them without sending themselves crazy. This is a cultural shift, and it's not overnight.
- Are you relying on a handful of magical security unicorns to take on the task of many?
Security professionals are in very short supply, and we need far more than are currently available. That is a given, but there is an increasing number of developers moving to more security-focused roles. Typically, they might be under titles like "security engineer" or "DevOps engineer" (slowly, we'll see this title morph into DevSecOps engineer, with any luck!). A gun DevOps engineer is able to develop features for virtually any application, while deploying using a true CI/CD pipeline. They do everything end-to-end, and usually come with a healthy dose of security awareness. In that sense, they are kind of magical, and rare as a result.
However, some companies make the mistake of hiring these specialist engineers, plopping them into a team and expecting they will be across all the security problems, at every stage of the development process, and this alone is the cure-all. Overburden your DevSecOps magicians, and you'll end up where you started - shipping insecure code without the checks, balances, and security precision they were hired to perform in the first place. It is of utmost importance that the development team in general is upskilled, and nurtured in a positive security environment so that they are equipped to share the load in a meaningful way.
Find the change you want to see in your organization.
If you implement robust training as part of your security program, you will uncover some hidden gems in your development cohort. These are the people who, despite any negative experiences they might have had in their day-to-day work, have something of a passion for secure coding and security best practices. These folks are prime candidates for security champions within the team; a point of contact between security and engineering who sets a great example for others, keeps awareness high, and helps with engagement initiatives. Their interpersonal skills are also very important in spreading security joy far and wide, and advocating for the developers'needs to management and the security team.
The "what's in it for me?" conversation is a positive step forward.
Even the noblest of humans need something of a "carrot" to dip their toe into unfamiliar territory, or an activity that may not have the most pleasant of learning curves.
Making the leap from "dev" to "DevSec" is an awesome boost for a developer's career. Security-aware developers have worked hard to understand security, take responsibility for it in the areas they can control, and operate with the understanding that the only quality code is secure code. Generally, developers want to improve, tackle new problems, and create enviable features that help them stand out among their peers. Give them a pathway to reach a higher level of software development, and it's a win-win situation.
It's never too late to build your DevSec dream team.
If you manage developers, lead an AppSec awareness team, or you're one of the many minds hard at work devising security program strategies, now is the time to go one better than "shifting" left. With the right training, tools, and environment, you can create a security incubator for developers that will pay great dividends for all parties. If this checklist has highlighted some areas for improvement, then you have a great opportunity to prepare your organization for a DevSec-led engineering department that can reduce risk from the very start of the SDLC.
We're barely half-way through 2020, and yet we're already on track to set a grim data breach record, seeing a 273% increase in stolen data as compared to the first half of 2019. These days, it's more accurate to ask how much data hasn't been stolen yet. With world events like the COVID-19 pandemic, these attacks have only increased in frequency and potency, with increasingly vulnerable targets.
This is something we have all known for a while: security is no longer optional, and our focus must be a pre-emptive strike. For that to be effective, everyone in the SDLC must be security-aware, especially developers. This is the "DevSec" part of DevSecOps, an ideal software development methodology for the climate, but many organizations are not fully prepared to execute this effectively.
With your organization in mind, think about these questions in the context of your role. How would it fare when put to the DevSec test?
DevSec Self-Assessment: Is your SDLC garden ready to bloom security-aware engineers?
- Is security front-of-mind in the internal development process?
A range of cybersecurity risk factors might be keeping the average CISO up at night, but the concerning reality is while many companies are making security more of a priority, their internal approach may not be robust enough to mitigate potential disaster (or, at least, massive headaches for the AppSec team and delayed shipment of software).
DevSecOps might be the current state of security nirvana, but few companies are working with this methodology. If you're still in Agile -- or even Waterfall -- then security is often still considered the domain of specialists that are far removed from the process and activated late in the SDLC, popping up to ruin a developer's day with hotfixes for their code. In an environment like this, it is going to be challenging to drive a DevSec culture: developers love and prioritize feature-building, and simply won't have had enough hands-on experience with security to see it as a desirable upskill pathway. In fact, their touchpoints with it may be ones of frustration and negativity. This must be remedied quickly to instill a front-of-mind approach for everyone involved in the software development process.
- Is your organization still playing catch-up when it comes to threat modeling?
It's a sobering statistic that 60% of SMBs go out of business within six months of a successful cyberattack, and much like other disasters, the impact is far greater without adequate planning.
Threat modeling is a crucial element of security best practices, allowing AppSec professionals to assess the full scope of the attack surface and structure appropriate defenses, countermeasures, and planning. In companies who have fully embraced DevSecOps, security is enabled early in the CI/CD pipeline, in such a way as to not slow down production as much as it may have in the past. Security, secure coding, and continuous delivery are all part of the process, and development teams are given the resources and exposure required to be major components of the engine spitting out air-tight code.
- Do development managers prioritize security best practices?
Whether they like it or not, development managers are role models for their team. And it's not just for the culture and vibe stuff, like wearing flip-flops to the office or how they "manage upwards". Their working priorities will inevitably be absorbed by their team members, and if security is not part of the key objectives, or planned for in terms of training and support, then the engineers underneath them will be missing out, and the business will be more at risk than it should be.
- Are developers given a reason to care about security?
In my experience, the fastest way to get someone offside is to tell them they have to do something that is foreign to their current approach, without telling them why.
Being told to "change" implies that the previous approach was wrong, when in many cases, it's simply an enhancement that will hopefully make things easier and more efficient later. To truly embrace the DevSec movement, developers need to be given a reason to care about security in the first place - after all, in most organizations, it is still very much "someone else's problem" (i.e. the AppSec wizards locked away in another room, far, far, away).
DevSecOps simply doesn't work if security is not a shared responsibility. Developers need the right tools, support and training to do their part... and this requires time to roll out and perfect as part of an overall security program. The worst approach is the one that overwhelms and alienates, which can be the case when developers have too many competing priorities and no help to manage them without sending themselves crazy. This is a cultural shift, and it's not overnight.
- Are you relying on a handful of magical security unicorns to take on the task of many?
Security professionals are in very short supply, and we need far more than are currently available. That is a given, but there is an increasing number of developers moving to more security-focused roles. Typically, they might be under titles like "security engineer" or "DevOps engineer" (slowly, we'll see this title morph into DevSecOps engineer, with any luck!). A gun DevOps engineer is able to develop features for virtually any application, while deploying using a true CI/CD pipeline. They do everything end-to-end, and usually come with a healthy dose of security awareness. In that sense, they are kind of magical, and rare as a result.
However, some companies make the mistake of hiring these specialist engineers, plopping them into a team and expecting they will be across all the security problems, at every stage of the development process, and this alone is the cure-all. Overburden your DevSecOps magicians, and you'll end up where you started - shipping insecure code without the checks, balances, and security precision they were hired to perform in the first place. It is of utmost importance that the development team in general is upskilled, and nurtured in a positive security environment so that they are equipped to share the load in a meaningful way.
Find the change you want to see in your organization.
If you implement robust training as part of your security program, you will uncover some hidden gems in your development cohort. These are the people who, despite any negative experiences they might have had in their day-to-day work, have something of a passion for secure coding and security best practices. These folks are prime candidates for security champions within the team; a point of contact between security and engineering who sets a great example for others, keeps awareness high, and helps with engagement initiatives. Their interpersonal skills are also very important in spreading security joy far and wide, and advocating for the developers'needs to management and the security team.
The "what's in it for me?" conversation is a positive step forward.
Even the noblest of humans need something of a "carrot" to dip their toe into unfamiliar territory, or an activity that may not have the most pleasant of learning curves.
Making the leap from "dev" to "DevSec" is an awesome boost for a developer's career. Security-aware developers have worked hard to understand security, take responsibility for it in the areas they can control, and operate with the understanding that the only quality code is secure code. Generally, developers want to improve, tackle new problems, and create enviable features that help them stand out among their peers. Give them a pathway to reach a higher level of software development, and it's a win-win situation.
It's never too late to build your DevSec dream team.
If you manage developers, lead an AppSec awareness team, or you're one of the many minds hard at work devising security program strategies, now is the time to go one better than "shifting" left. With the right training, tools, and environment, you can create a security incubator for developers that will pay great dividends for all parties. If this checklist has highlighted some areas for improvement, then you have a great opportunity to prepare your organization for a DevSec-led engineering department that can reduce risk from the very start of the SDLC.
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
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
We're barely half-way through 2020, and yet we're already on track to set a grim data breach record, seeing a 273% increase in stolen data as compared to the first half of 2019. These days, it's more accurate to ask how much data hasn't been stolen yet. With world events like the COVID-19 pandemic, these attacks have only increased in frequency and potency, with increasingly vulnerable targets.
This is something we have all known for a while: security is no longer optional, and our focus must be a pre-emptive strike. For that to be effective, everyone in the SDLC must be security-aware, especially developers. This is the "DevSec" part of DevSecOps, an ideal software development methodology for the climate, but many organizations are not fully prepared to execute this effectively.
With your organization in mind, think about these questions in the context of your role. How would it fare when put to the DevSec test?
DevSec Self-Assessment: Is your SDLC garden ready to bloom security-aware engineers?
- Is security front-of-mind in the internal development process?
A range of cybersecurity risk factors might be keeping the average CISO up at night, but the concerning reality is while many companies are making security more of a priority, their internal approach may not be robust enough to mitigate potential disaster (or, at least, massive headaches for the AppSec team and delayed shipment of software).
DevSecOps might be the current state of security nirvana, but few companies are working with this methodology. If you're still in Agile -- or even Waterfall -- then security is often still considered the domain of specialists that are far removed from the process and activated late in the SDLC, popping up to ruin a developer's day with hotfixes for their code. In an environment like this, it is going to be challenging to drive a DevSec culture: developers love and prioritize feature-building, and simply won't have had enough hands-on experience with security to see it as a desirable upskill pathway. In fact, their touchpoints with it may be ones of frustration and negativity. This must be remedied quickly to instill a front-of-mind approach for everyone involved in the software development process.
- Is your organization still playing catch-up when it comes to threat modeling?
It's a sobering statistic that 60% of SMBs go out of business within six months of a successful cyberattack, and much like other disasters, the impact is far greater without adequate planning.
Threat modeling is a crucial element of security best practices, allowing AppSec professionals to assess the full scope of the attack surface and structure appropriate defenses, countermeasures, and planning. In companies who have fully embraced DevSecOps, security is enabled early in the CI/CD pipeline, in such a way as to not slow down production as much as it may have in the past. Security, secure coding, and continuous delivery are all part of the process, and development teams are given the resources and exposure required to be major components of the engine spitting out air-tight code.
- Do development managers prioritize security best practices?
Whether they like it or not, development managers are role models for their team. And it's not just for the culture and vibe stuff, like wearing flip-flops to the office or how they "manage upwards". Their working priorities will inevitably be absorbed by their team members, and if security is not part of the key objectives, or planned for in terms of training and support, then the engineers underneath them will be missing out, and the business will be more at risk than it should be.
- Are developers given a reason to care about security?
In my experience, the fastest way to get someone offside is to tell them they have to do something that is foreign to their current approach, without telling them why.
Being told to "change" implies that the previous approach was wrong, when in many cases, it's simply an enhancement that will hopefully make things easier and more efficient later. To truly embrace the DevSec movement, developers need to be given a reason to care about security in the first place - after all, in most organizations, it is still very much "someone else's problem" (i.e. the AppSec wizards locked away in another room, far, far, away).
DevSecOps simply doesn't work if security is not a shared responsibility. Developers need the right tools, support and training to do their part... and this requires time to roll out and perfect as part of an overall security program. The worst approach is the one that overwhelms and alienates, which can be the case when developers have too many competing priorities and no help to manage them without sending themselves crazy. This is a cultural shift, and it's not overnight.
- Are you relying on a handful of magical security unicorns to take on the task of many?
Security professionals are in very short supply, and we need far more than are currently available. That is a given, but there is an increasing number of developers moving to more security-focused roles. Typically, they might be under titles like "security engineer" or "DevOps engineer" (slowly, we'll see this title morph into DevSecOps engineer, with any luck!). A gun DevOps engineer is able to develop features for virtually any application, while deploying using a true CI/CD pipeline. They do everything end-to-end, and usually come with a healthy dose of security awareness. In that sense, they are kind of magical, and rare as a result.
However, some companies make the mistake of hiring these specialist engineers, plopping them into a team and expecting they will be across all the security problems, at every stage of the development process, and this alone is the cure-all. Overburden your DevSecOps magicians, and you'll end up where you started - shipping insecure code without the checks, balances, and security precision they were hired to perform in the first place. It is of utmost importance that the development team in general is upskilled, and nurtured in a positive security environment so that they are equipped to share the load in a meaningful way.
Find the change you want to see in your organization.
If you implement robust training as part of your security program, you will uncover some hidden gems in your development cohort. These are the people who, despite any negative experiences they might have had in their day-to-day work, have something of a passion for secure coding and security best practices. These folks are prime candidates for security champions within the team; a point of contact between security and engineering who sets a great example for others, keeps awareness high, and helps with engagement initiatives. Their interpersonal skills are also very important in spreading security joy far and wide, and advocating for the developers'needs to management and the security team.
The "what's in it for me?" conversation is a positive step forward.
Even the noblest of humans need something of a "carrot" to dip their toe into unfamiliar territory, or an activity that may not have the most pleasant of learning curves.
Making the leap from "dev" to "DevSec" is an awesome boost for a developer's career. Security-aware developers have worked hard to understand security, take responsibility for it in the areas they can control, and operate with the understanding that the only quality code is secure code. Generally, developers want to improve, tackle new problems, and create enviable features that help them stand out among their peers. Give them a pathway to reach a higher level of software development, and it's a win-win situation.
It's never too late to build your DevSec dream team.
If you manage developers, lead an AppSec awareness team, or you're one of the many minds hard at work devising security program strategies, now is the time to go one better than "shifting" left. With the right training, tools, and environment, you can create a security incubator for developers that will pay great dividends for all parties. If this checklist has highlighted some areas for improvement, then you have a great opportunity to prepare your organization for a DevSec-led engineering department that can reduce risk from the very start of the SDLC.
Table of contents
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
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
Trust Score Reveals the Value of Secure-by-Design Upskilling Initiatives
Our research has shown that secure code training works. Trust Score, using an algorithm drawing on more than 20 million learning data points from work by more than 250,000 learners at over 600 organizations, reveals its effectiveness in driving down vulnerabilities and how to make the initiative even more effective.
.png)
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.
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.
Developer-driven coding.
Securely.
Contact us today and make software security an intrinsic part of your development process.
