6 Years of Better AppSec — What’s Next?

By: James Chiappetta

Important Disclaimers:

• The opinions stated here are the authors' own, not necessarily those of past, current, or future employers.
• The mentioning of books, tools, websites, and/or products/services are not formal endorsements and the authors have not taken any incentives to mention them.
• Recommendations are based on past experiences and not a reflection of future ones.
• Artificial Intelligence (AI) is a rapidly developing space and therefore any recommendations, opinions, or examples are based on present knowledge and subject to change.

Background

When we launched Better AppSec in 2020, we saw an opportunity to change how we talk about Application Security (AppSec). Most available content back then either felt driven by vendor marketing agendas or merely reflected a single practitioner's perspective. We wanted to build a collaborative, peer reviewed space where security engineering ideas could be pressure tested, challenged, and refined by practitioners before they were ever published. That collaborative loop became a core principle. Six years and 34 articles later, looking back through our archive feels like reading a living timeline of modern AppSec itself.

Today, we'd like you to join us on a reflection of the work that went into the 120,000+ words created with the help of nearly 70 practitioners in the field. We will highlight the key learnings, what it means to us, and what we think comes next for cyber executives, security engineers, and product development teams.

First Things First

The engineering world has changed dramatically since 2020. Scaling security then meant finding ways to integrate static analysis into CI/CD pipelines without interrupting delivery. Today, we are navigating AI assisted development, autonomous agent workflows, and cloud native software ecosystems evolving at a velocity we have never experienced before.

Yet, through all of this change, our underlying thesis has remained consistent. Security program maturity comes from stronger product and engineering partnerships, secure by design engineering, and using actionable data to eliminate risk and workflow friction. That said, from the trenches we are seeing some notable visions of what the future may hold and that will absolutely steer where this publication goes next. Let's take a closer look at all this and more.

Let's get to it!

From Code Scanners to Systemic Architects

Looking back at our early content from 2020 through 2022, conversations with security leaders focused heavily on building foundations as CISOs were designing organizational structures, fostering security culture, establishing asset criticality models, and writing early roadmaps to become compliant.

We were operating in an era defined by a familiar structural imbalance, which was the classic 100:1 developer-to-security engineer ratio. Today, that imbalance has become even more pronounced. Generative AI can multiply software output far faster than security teams can realistically scale headcount. As a result, our modern security leadership philosophy will continue to center on a single, pragmatic economic question: What is the return (risk reduction) on developer friction (work effort)?

Why?

As always, we are glad you asked. Developer attention and engineering time are finite and expensive corporate assets. Every control that slows a developer down must create a meaningful, measurable, and proportional reduction in risk.

Encouragingly, forward-thinking security leaders are stepping up as architects of safe velocity rather than owners of isolated tools to chuck noise over the fence. The objective is no longer maximizing alert volumes, adding bureaucratic gates, or enforcing compliance checkboxes. The goals we are seeing today are biased towards investing in structural and architectural improvements that reduce risk inherently without stalling execution.

This positive shift alters what success looks like. Instead of simply tracking raw vulnerability counts or policy adoption, modern metrics must reflect systemic health. Common metrics would include remediation velocity, blast-radius containment, developer interruption rates, and long-term resilience trends across AI assisted codebases. Our next chapter will have to focus heavily on validating and defining these next-generation indicators.

From Finding Vulnerabilities to Eliminating Classes of Problems

For security practitioners running programs day to day, the operational shift has been nothing short of dramatic.

Think back to the Log4j vulnerability of late 2021. It was a familiar and high-stress firefighting exercise where we had to locate the vulnerable dependency, patch the library, and push changes into production. It was exhausting, but it was a fundamentally linear and well practiced exercise of 0 day patching.

Over the last few years, however, threats moved much closer to developer workflows. Token-stealing, supply chain attacks, and pre-install execution techniques began bypassing traditional build time scanning approaches entirely (e.g. Shai-Hulud). At the same time, advanced AI systems are demonstrating a startling capability to autonomously identify vulnerabilities and construct functioning exploit paths (e.g. Mythos).

This changed the defensive equation entirely as the problem is no longer finding vulnerabilities. AI has dramatically reduced the cost of discovery and shows that the true bottleneck has become verification debt (what can be exploited) and remediation capacity (how much effort to fix).

This change creates an incredible opportunity for practitioners to rethink their roles. Rather than endlessly triaging massive queues of noisy alerts from scanning tools, high-performing teams are shifting toward eliminating entire classes.

A remediation campaign should not simply mean closing hundreds of tickets faster, but structurally eradicating categories of risk. Instead of chasing individual SQL injection (SQLi) or cross site scripting (XSS) findings across dozens of legacy applications, teams can implement safer framework defaults that remove those classes of issues from future development entirely.

Going forward we will need to lean heavily into these systemic remediation campaigns, secure AI architectures, RAG security patterns, and practical approaches to deploying automated remediation safely in production environments.

Enabling Developer Productivity & Risk Reduction

In 2020, many product and software development teams experienced security as an administrative hurdle appearing at the very end of a development cycle. It usually showed up as an opaque gate during the final stages of delivery, forcing engineers to rewrite code under intense deadline pressure or even worse, after the code has been shipped to production. This relationship has evolved out of necessity.

Software increasingly depends on deeply nested open-source ecosystems and AI assisted development tools. At the same time, attacks today increasingly target developer identities, credentials, and software creation workflows. Consequently, the perimeter is no longer the workstation at all. It is the identity, context, and execution surrounding software creation.

In a world of spec-driven development and autonomous agents, software may never originate on a developer's physical laptop. Code now routinely emerges from remote execution environments and AI generated workflows. The challenge is no longer securing a single device; it is securing the environments and identities participating in the software creation process itself.

To protect this ecosystem without sacrificing productivity, we must respect the engineer's flow state. Context switching remains one of the fastest ways to erode focus and introduce defects. Security feedback works best when it appears natively where they already operate: inside terminals, IDEs, and pull/merge requests.

We always have and will continue to champion that engineers should receive actionable guidance while writing code, not three days later through a separate dashboard or an automated ticket queue. If a risky pattern appears in a pull request, the ideal outcome is immediate context and an inline fix before momentum is lost.

When security integrates directly into the workflow, it stops feeling like bureaucracy and starts feeling like natural software craftsmanship. Secure code is not simply code that satisfies an auditor. It is resilient, maintainable, high-quality software. We will continue to develop and provide practical guidance around secure prompt engineering, code-reviewing AI generated pull requests, and designing zero-trust development environments.

What is the Future of AppSec?

For years, security programs relied heavily on gates. If someone drifted outside expectations, the pipeline stopped the build, issued a warning, and forced a manual correction. But AI is not driving a single car down a quiet road. It's going to allow us to operate a self-driving fleet of cars moving at greater speed than humans can, all at once, and on all the roads.

A security process that takes minutes to evaluate a pull request becomes a bottleneck against an automated stream of commits. A workflow dependent on human alert triage and manual Jira tickets cannot effectively govern agent based systems.

Secure by default frameworks, hardened architectures, identity boundaries, and safe engineering defaults must become the physical mechanism that keeps systems operating safely. Our responsibility as security practitioners has shifted from watching the driver to watching all the vehicles on the highway. But what happens when the cars start to fly? Honestly, no idea… but this truly feels like where we are headed in the next 6 years.

We need to be thinking critically about entire autonomous AI ecosystems we are working to build today. These systems no longer operate entirely within our previously defined security frameworks. Current and future systems provision infrastructure dynamically and establish interactions we did not explicitly design ahead of time. When architecture becomes completely fluid and ephemeral, static guardrails become entirely insufficient. This is where we believe that we go from paving roads and monitoring the vehicles on them to also governing the airspace above it all.

Perhaps in that world, security becomes less about enforcing fixed code pathways and more about enforcing trusted environments. Strong identity systems, runtime visibility, cryptographic controls, and well defined environmental boundaries become a new infrastructure layer. The autonomous AI agent can move freely within approved airspace, but the environment itself prevents unsafe behavior. It's a wild thought right now but one we can't help given how fast technology is moving.

Why Does Better AppSec Still Matter?

Reaching the six-year milestone forced us to wrestle with a couple of existential questions that many technical writers are likely asking themselves right now: Does writing technical content still matter when AI can generate nearly any configuration or codebase instantly? What's the point of researching and writing if all that work will just get summarized into just a few AI generated bullet points?

The answers became clear once we looked at what AI is actually changing. Because engineers are spending less time writing boilerplate code and more time evaluating AI generated output, the bottleneck is shifting from code production to code judgment.

AI can generate functionality at extraordinary speed, but it still struggles with context, human intent, decisions, and logical security boundaries. It frequently creates software that functions perfectly but also violates security assumptions humans intended.

We believe the internet does not need any more AI generated text or recycled checklists. It needs better filters, stronger mental models, and practical frameworks for understanding how highly complex systems fail (and succeed). That is why we believe Better AppSec matters even more today than it did in 2020. We are no longer simply documenting technology trends but continuing to build playbooks for humans acting as the ultimate architectural governors.

Words of Wisdom

Better AppSec began as a simple experiment in collaborative learning. While the challenges ahead look the same but different, we believe the strongest security ideas emerge when practitioners build a better world together. We remain committed to our mission in helping others reduce friction between security and engineering through practical guidance, peer reviewed ideas, and battle tested lessons. It has been and will continue to be an honor playing any small part in helping Application Security change for the better.

"Coming together is a beginning, staying together is progress, and working together is a success." - Henry Ford

Contributions and Thanks

To the core Better AppSec editorial team, contributors, and everyone who has ever challenged, tested, or improved our ideas over the last six years: THANK YOU!

Thanks to those who helped peer review and make this post as useful as it is: Conor Walsh, Dor Zusman, Goerge Nikitkov, Gadi Bashvitz, Igor Maslov, Rahul Sharma, Vishal Jindal, and Robert Prast

A special thanks to you, the reader. We hope you benefited from reading this in some way and we want everyone to be successful at this. While these posts aren't a silver bullet, we hope they get you started.

Please do follow our page if you enjoy this and our other posts. More to come!

Help us Build the Future of Better AppSec

The concepts on this blog only work because they are tested against reality by practitioners in the real world. If you have frameworks you've developed, hard lessons you've learned, or architectural ideas worth stress testing against the realities of engineering with AI, then come build with us. Reach out to join our peer review panel or become a guest contributor. Let's write the next Better AppSec playbook together!