Developer security education products are pointless
Companies in this space are just features, not products or platforms.
Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.
Security training and education have always been staples of security programs. It makes sense. Employees should know about common threats faced across the companies and some avenues to report any suspicious activity. It also helps with providing a baseline of security knowledge across the organization. However, these trainings have become outdated, especially with a shift in working habits. For example, most of them are focused on an office-based workforce. There are more sophisticated phishing attacks. Most records are digital, and access has become one of the issues. The list goes on.
There’s specifically a focus on more in-depth security education for developers. It’s more emphasized in companies that work in regulated industries. Developers hold access to the application and some of the most sensitive data. This is especially true as more companies rely on technology to run their businesses and store their information. Gone are the days of paper records. Even in companies with paper records, there’s a digital version. Increasingly, a company’s risk is focused on its applications (internal and external) and digital infrastructure, shifting more security risk to the developers. No wonder it’s an important part of many compliance certifications, and it continues to be. However, like broader security education, there have been shifts that affect the effectiveness of developer security education.
What is developer security education?
Before we talk about the specific changes and how they might affect the industry, let’s talk a bit about what developer security education is. It’s focused on teaching developers how to spot vulnerabilities and have secure development practices. Typically, most of these trainings focus on the OWASP Top 10, which is updated annually. That’s also part of the reason companies require developers to do this training annually (on top of the fact that it’s necessary for annual compliance certifications).
They’ve gone through multiple forms. Initially, it started with training videos and some best practices. In my opinion, those are largely ineffective because they don’t give any practical experience. Slowly, this improved with real-world examples. Recently, new startups in this space, such as Secure Code Warriors and Immersive Labs have been providing hands-on experience.
Secure Code Warrior seems to be more focused on application security, such as finding bugs in code as well as selecting the remediations. However, it doesn’t require writing any code, so it feels more tailored toward application security engineers who don’t write too much code but instead review it. Another thought is that it’s training developers to think like application security engineers so that they can scale better since developer security education is typically considered an application security initiative.
Immersive Labs actually asks the user to write code. Although it guides the user, it requires the user to know how to code. As a software engineer, I personally prefer this because it allows me to find the bugs in the actual code and teaches me how to rectify them. It seems that this approach has gained popularity as developers feel that these types of trainings offer more practical experience and are more useful. It’s also easier to convince developers to do this as they see it as potential career development.
It’s clear that developer security education has evolved over the years.
What has changed?
Developer security education has started to focus more on hands-on experience. Development cycles have become faster and more regimented, making it difficult to find time to do these types of trainings, so it’s important to deliver more practical value. In addition, developers are more aware and knowledgeable about security than before, but they often lack the experience to know how to resolve them properly. On the security side, application security engineers are sometimes seen as operational because their roles have traditionally focused on auditing. More engineering-focused leaders would want them to spread knowledge so that it’s easy to have a few of them have more coverage.
Another major shift is that more security tools have “shift left” (a terrible way to describe a trend). Given faster development cycles, former application security tools don’t scale. As a result, tools, like Snyk, Semgrep, and others, have become increasingly popular because they provide feedback to developers during the development process, i.e. during CI/CD or even earlier. It’s also beneficial for engineering and security because problems are “cheaper” to fix in the development cycle compared to detecting and remediating them once they reach production.
However, an unintended consequence of these tools is that they have been teaching developers security practices! Upon each pull request and code push, these tools have been providing security knowledge and feedback. Since the development cycles have been faster, these tools have been providing knowledge and insight at a great pace.
What does this mean for developer security education tools?
I always thought it was hard to build a platform for a company that starts with a developer security education tool. Companies like KnowBe4 are trying to expand into broader HR and people-based compliance trainings. They also have tried to do some phishing simulations, but they are losing market share to other platforms. Their phishing training is becoming part of email security products. Their security training is becoming integrated into broader compliance platforms focused on certifications, such as Vanta and Drata.
Overall, developer security education tools are a tough business. It feels that they should be a feature and not even a product themselves. The business is only becoming tougher. There are only a couple of reasons why these tools still exist. First and most obviously, they are a compliance requirement. Second, they are valuable for companies that don’t have a security team with substantial software development experience. However, as many know, I believe we are shifting toward a model where companies hire security professionals with software engineering experience.
As time evolves, with more security tools targeted to developers as well as more software engineers working in security, developer security education tools feel irrelevant. If anything, developer tools in general should incorporate security warnings and information. Also, with software engineers that do security, security culture will become more integrated into engineering. Overall, developer security will improve despite these education tools, which make them irrelevant. Another perspective is that security education will become a feature of developer security tools in general.
On top of that, it’s hard to create trainings for a wide range of software engineering skills, and that range is becoming larger as there seems to be a wider set of roles, such as DevOps, data engineers, etc. Also, increasing software engineering turnover and attrition exacerbate this problem, so it’s a constant battle to train and have a baseline of security since most companies seem to have “fluid” workforces.
The final piece of the puzzle is the compliance aspect. The fix there is harder or easier depending on your perspective. It’s hard to change compliance standards, but the solution could be simple. Like how compliance standards require resumes of the executive team and board, instead of requiring developer security training, they can require the security team to have software engineering backgrounds instead of that.
Takeaway
Developer security training has evolved over the past decade with changing development practices. However, much of the training feels outdated and irrelevant given the rise of developer-focused security tools. It’s interesting to see how this industry progresses, but it seems that it’s hard to build a good company with developer security education as an anchor product. I do think this trend will be good for the industry as we find other and likely more effective methods to educate developers.