How to make DevSecOps stick with developers
While DevOps culture has brought innovation to the industry and transformed the way software is developed, it’s arguably an outdated concept.
The truth is that DevOps has allowed for new features and applications to be rolled out at such speed that traditional security practices simply aren’t able to keep up. The other problem is that the security testing that does occur (e.g., penetration testing and code reviews), usually takes place towards the end of the DevOps lifecycle, which is often too late.
This is where DevSecOps comes in. The main idea behind DevSecOps is to incorporate security far earlier into the software lifecycle development process. Unfortunately, when speed is everything, developers are often reluctant to prioritize security – so how do you make DevSecOps stick with developers?
Don’t just “shift left”
The popular notion of “shifting left” doesn’t go far enough as it implies the process begins without security in mind. In order to positively engage developers and arm them with the skills and knowledge they need to code securely, the industry needs to adopt a “start left” mentality. This is where security is considered an absolute priority from day one by everyone from the C-suite down to the developers writing the code.
Developers are the key to DevSecOps success and as a result, their approach to security must be consistent. Every line of code that the engineers write, from the very start of the development process needs to be created with security in mind. However, getting developers to simply change their habits isn’t always as easy.
The primary responsibility of a developer is building software that is functional, innovative and delivered at speed. Not only is security frequently not considered a priority at the coding level, but it’s even seen by many as tedious and an obstruction to delivering creative and original features.
So, where do you start? First, you need to understand where your developers sit on the security skills spectrum. A great way to benchmark developer skills is by running live secure coding “tournaments” with your team using simulated scenarios. This is not only a way to get developers more engaged in the idea of secure code but will allow you to understand what further training each developer needs to ensure everyone’s learning is tailored to their skill set.
Skip the classroom training
DevSecOps should be viewed as an ongoing methodology and a process, rather than a quick fix. It’s a culture as much as a set of techniques and adopting it requires skilled people, change management and an ongoing commitment from all parties involved. Providing employees with the right tools and training is a key step in this movement towards the rise of security developers, yet we can’t expect traditional teaching methods such as classroom-based learning is unlikely to change a developer’s mindset on secure coding.
Training in secure coding is essential but will only be effective if it’s relevant and demonstrates how security can fit seamlessly into a developer’s day job. Whilst tournaments are a great place to start, it’s the day-to-day training that will shift the needle. One successful way of doing this is through hyper-relevant gamified learning platforms that are integrated with day-to-day tasks.
If the developer is actively led through how coding and security can be combined into the same offering, without taking them away from their job, they are more likely to continue with best practices in the future. For those looking to start on a smaller scale, there are free training apps that teach essential secure coding skills across different coding languages.
Organizations need to not only provide their developers with the necessary tools for training, but also ensure that developers are given adequate time and incentives to make it a priority. This could be by incorporating security into team and individual job descriptions and KPIs or creating reward structures that encourage further training.
Show them the money
The benefits of developers integrating security into their work extend not just to the successful delivery of the software, but also to the developers themselves. Writing secure code may seem like an obstacle at first but will become easier with time and will create efficiencies in the long term as there will be fewer bugs to remedy.
Additionally, consistently writing secure code will ensure that the developer is producing a higher standard and quality of work, and in turn, will become highly valued and in-demand.
Upskilling in security will ultimately provide developers with more prestigious and lucrative job opportunities as secure coding continues to become a highly sought-after skill.
Ensuring developers understand the benefits of learning to code securely not just for the company, but for themselves too, is key to establishing a security-first mindset.
Conclusion
While DevOps was innovative when it was first introduced, the industry has now moved past this concept and DevSecOps is here to stay. However, to be successful security needs to be viewed as a priority by all involved from the very beginning, and this starts with developers.
Organizations first need to find out where the developers’ security skills currently sit and provide bespoke, gamified training to keep them engaged. This needs to be done whilst highlighting the benefits that upskilling in security can provide for the individual developers.
Ultimately, getting DevSecOps right is about built-in security, collaboration between developers and AppSec teams, and a cultural shift towards a deeper understanding of the importance that needs to be placed on security as a wider societal issue.