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.
Matias Madou, Ph.D.
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.
Related Articles We Recommend
Related Articles We Recommend
Dive into onto our latest secure coding insights on the blog.
Our extensive resource library aims to empower the human approach to secure coding upskilling.
Get the latest research on developer-driven security
Our extensive resource library is full of helpful resources from whitepapers to webinars to get you started with developer-driven secure coding. Explore it now.
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.
