It’s Time For A New Way To Develop Secure Software
Brajesh argues that traditional, checklist-based security processes are broken, and that teams need a continuous, security-first development approach for fast-moving software.
Securing Software, the Traditional Way is Broken
I’ve been developing software for a decade now. One thing has been consistent: security has always been an afterthought. In the teams I’ve worked on, feature work usually ended up being prioritized, partly because it was easier to gain career growth with shipped features than with less visible security improvements, and security experts were hard to find. That made it difficult to align my team around a security-first mindset. Inevitably, security became merely a checklist item before release, and subsequent feature launches kept introducing new risks that were rarely re-evaluated.
How Security Traditionally Works
In the large organizations, the traditional process looks something like this: A software engineer prepares a context report and presents it to the security team. Both parties discuss potential security issues. The engineering team then negotiates prioritization with the security team and only fixes critical issues before launch. The remaining vulnerabilities get locked away in the backlog, never to be seen again until they’re exploited. My colleague has written an amazing article about it: Security at Scale: Lessons From Launching Services at AWS and Why Most Companies Can’t Replicate It.
In small and medium organizations, the risk is even higher. Features are shipped without any security considerations. There’s often no dedicated security team at all. Engineers ship features with vulnerabilities waiting to be exploited.
My Painful Stories
While working on an AWS service, a high-volume customer reported a vulnerability we had left in the backlog. This customer generated significant traffic and shaped our product roadmap, so it was an embarrassing moment. You never want customers to point out security gaps because they start losing trust. The team already knew about the issue: a TLS certificate flaw that allowed any client outside the business to connect to the Kafka cluster. The team had to drop everything, prioritize and release a fix to only allow connections from trusted certificates.
In another instance, I deployed a reactive auditing solution on 100K+ production servers. In case of a security breach, this solution would log all attempted commands and only allow safe commands to execute. The safe commands were deployed after review and approval. Rolling this out at such a massive scale in production required meticulous planning and execution.
In both of these painful stories, all the extra work took far more time than fixing the issue when we first found it. The real problem wasn’t just the TLS issue or deploying the security auditing solution; it was that we didn’t treat our threat model as a living document or regularly re-prioritize known vulnerabilities. That’s how we ended up firefighting in production, instead of shipping features.
The Gaps in the Traditional Process
To stop firefighting and build secure software, teams need a way to develop features without losing sight of security. About 70 percent of security defects are introduced during the requirements gathering and design phases. But it doesn’t stop there, because teams must continuously re-evaluate their security posture as the software grows. In my experience, it’s impossible to maintain a complete view of the system as it expands, which creates room for security gaps. Traditional approaches tend to focus on new software while ignoring how it integrates with existing systems, often overlooking critical issues. Developing software and security should go hand in hand to ship fast.
The traditional process hasn’t evolved with new technologies and paradigms for building software. For example, with the advancement of LLMs and coding agents, it has never been easier to ship software. At Trent, we use AI tools every day in our own work: from coding agents to AI review tools. Even a small team can turn ideas into products with significant productivity gains. Proof-of-concept projects can become production services in days, but the security process hasn’t kept up. Security reviews still happen late, threat models go stale, and teams lack continuous visibility into how their architecture and code are evolving over time.
Security-First Approach at Trent
That’s why I’m excited to be a member of the technical staff at Trent AI, where we’re designing new ways to ship secure products. Instead of one-time security reviews, we provide continuous security guidance throughout the development process. Teams get expert security knowledge from the earliest design stages, catching vulnerabilities before they’re embedded in the architecture. As systems evolve, teams maintain ongoing visibility into their security posture, ensuring assessments stay current and new features integrate securely. Initial feedback from customers shows they care about security while maintaining high productivity. So, if you’re a product leader who wants to ship secure products, I’d love to chat.
FAQ
Why the Secure Software Development Life Cycle Is Broken
The secure software development life cycle is a framework for integrating security practices into every phase of software development, from requirements and design through coding, testing, deployment, and maintenance. In practice, however, most teams only apply security checks at one or two stages, typically just before release, leaving vulnerabilities embedded from the earliest design decisions.
Why does the traditional SSDLC fail?
Traditional secure software development relies on one-time security reviews conducted by overbooked AppSec teams who lack deep context about the specific system. This creates bottlenecks, stale threat models, and a backlog of known vulnerabilities that never get addressed. About 70 percent of software defects are introduced during requirements gathering and design, long before most security reviews occur.
What is a security-first development approach?
Security-first development embeds security guidance continuously from the earliest design conversations, rather than as a gate before release. Teams maintain a living threat model that evolves as the system grows, ensuring ongoing visibility into security posture and catching vulnerabilities before they are embedded in the architecture.
How does continuous security differ from periodic security reviews?
Periodic reviews create a snapshot of security posture at a single point in time, which quickly becomes outdated. Continuous security provides ongoing assessment that adapts as code, architecture, and threat landscapes change, eliminating the firefighting cycle where teams discover production vulnerabilities that were known but deprioritized months earlier.
