Rethinking Developer Security: The Case for Secure Defaults
Just some honest thoughts after trying to make sense of developer security awareness for some time
TL;DR: Developer security awareness should be treated like any other enterprise problem—identify the issue and its importance and then try to solve it. However, we've been addressing the wrong problem. We don't need developers to be more aware of security; we need security built in by default. We need Security Defaults. We need something measurable.
For years, I’ve been passionate about implementing DevSecOps or secure software development in organizations. I’ve learned from experience and want to share insights to help others avoid the pitfalls I encountered.
The Real Problem
Let’s be honest: after five years of contemplation, I’ve realized where things are heading. We typically want our developers to code and configure securely, avoiding unnecessary risks, vulnerabilities, business flaws, and technical debt. Being aware of cyber security aware is a bonus, but not the goal.
Trend 1: SAST Tools - To tool or not to tool
The first major trend in the DevSecOps market was adopting Static Application Security Testing (SAST) tools. In Norway, the hype was around tools like Snyk. While initially promising, these tools require ongoing management and follow-up on identified vulnerabilities. When that doesn’t happen, you end up with:
YATOTS—Yet Another Tool On The Shelf.
SAST tools can become more than just vulnerability spotters if they are better integrated into the development environment. For SAST tools to be useful, they must be embedded within the Integrated Development Environment (IDE), making them easy, available, and low-effort for developers to use. Additionally, these tools need to understand the organizational context much faster than they currently do. Fortunately, with the rise of Large Language Model (LLM) agents, this integration is now more technically feasible than it was four years ago.
Trend 2: Developer Security Learning Platforms - To learn or not to learn
Next came developer security learning platforms, coming up as the next silver bullet trying to solve the problem. Platforms like HackTheBox, TryHackMe, and SecureCodeWarrior are fun and educational. But if fun alone secured the world, we wouldn’t have a job. These platforms are often too generic, falling short in organizational contexts that involve VPNs, firewalls, compliance requirements, custom third-party software, weird XML shit, etc.
Most developers don’t receive regular security training—maybe once a year. Their daily focus is on stand-up meetings, programming sessions, and managing product owners. Meanwhile, the industry has moved toward DevSecOps, piling even more responsibility onto developers. But as the famous footballer Gennaro Gattuso once said, "Sometimes maybe good, sometimes maybe not."
Similar to the issues with SAST tools, these platforms often lack sufficient organizational context to be useful. A truly effective learning platform should be integrated into the development environment, using that context to teach the correct practices. Let’s assume you’re creating an Enterprise Application - a relevant “course” would then be on scope creep in the permissions setting for the roles.
Currently, the expectation is that developers will use these platforms, synthesize the relevant information, filter out unnecessary content, and somehow apply this knowledge to make their environment more secure. This is a high expectation and often unrealistic without better integration into the actual development workflows.
Trend 3: Secure Defaults
The most effective approach I've seen is implementing secure defaults. This involves creating secure repositories and configurations for development and operations, quality assured by leads in your development, security, or operations teams. Resources like Clint Gibler's "Awesome Secure Defaults" or using CIS Benchmarks standards to configure your environment. This can be as implemented as simply like collective repository maintained by a “core group” or as comprehensive as an internal developer portal(something like NAV NAIS).
Secure defaults are the most effective way to achieve what we really want—a more secure development lifecycle. It’s not as flashy as a dashboard full of CVSS scores or as fun as capturing a flag in a CTF. But secure defaults provide what you truly need—measurable, preconfigured easy-to-use security patterns that integrate into your development process. And that is what you want.
Conclusion
The solution to developer security isn’t more awareness, the latest and greatest about vulnerabilities, or the latest tool—it's making security the default state. By implementing secure defaults, you create an environment where security isn’t an afterthought but a part of your development lifecycle from the start. This approach may not be as cool, but it’s effective, scalable, and necessary for a secure software development future. If I can go back in time, this is what I would start with.
References:
https://github.com/tldrsec/awesome-secure-defaults
https://www.cisecurity.org/cis-benchmarks