AppSec has decades of lists, acronyms, taxonomies, and scanners for flaws like XSS and SQL injection.

And yet barely three months into 2025 those two vuln classes already account for several hundred new CVEs. (WordPress plugins alone seem to be responsible for over 900 XSS vulns. That aspect deserves an entirely separate discussion on software design choices.)

What does a history of never-ending flaws mean for a future where LLMs produce code, attackers produce backdoored LLMs, and supply chains struggle with trust?

Why should we trust AppSec to fix new problems when so many old ones are still around?

What did AppSec miss in promoting secure designs? How did it fail developers?

Look Back

Since I mentioned XSS, the most web of web vulns, let’s take a detour back to the beginning of the web. At the end of 1994, Netscape introduced their browser and, along with it, a few custom HTML extensions.

The most notorious extension was the blink tag, one of the most insidious elements ever inflicted on humanity. I hope no one reading this has ever been subjected to the obnoxiousness of the blink tag.

Netscape released their browser at the end 1994. By January 1995 the blink tag was already annoying people.

Don't Blink

Fast forward to 2013 when Firefox, the spiritual descendent of Netscape’s browser, finally removed support for that awful, awful tag.

But if it took 20 years of complaining to kill off a terrible tag, what does that slow pace imply for security?

Maybe security needs to swap out complaining for creating.

Squash Bugs

Let’s go back to 1995 for a moment.

That October, Netscape launched a “Bugs Bounty”, plural, because who knows how many bugs any piece of software has. There’s surely more than one.

Commendably, they explicitly equated security bugs with software quality.

The winner created what was essentially an XSS attack using LiveScript, shortly thereafter to be renamed JavaScript and eventually to become a favorite server-side programming language for people who love package dependencies.

(Perhaps more accurately, the attack demonstrated how JavaScript could abuse the nascent Same Origin Policy. The late 90s had plenty of high impact XSS examples.)

Today our browsers still have JavaScript and sites still have XSS.

Imagine if Kendrick Lamar had had a beef with XSS. The vuln class would have been over and done with in a few short months. No way it could have survived all these decades.

Appsec needs more Kendrick energy.

Web Devs React

Let’s roll forward from 1995 back to 2013, the year blink died. Just a few months after the funeral celebrations, one of the best steps towards ending XSS arrived – React.

It didn’t come out of an appsec project or checklist or anything like that.

It came out of an engineering-focused effort.

That’s not to say it wasn’t informed by appsec. But what it did was solve a problem that was important to developers, and it did so in a way that would enable developers to build apps without having to mentally track tedious security controls the entire time.

The next time someone says developers don’t care about security, ask if security knows anything about development.

Like I said. We need that diss track energy towards vuln classes. We don’t need it towards devs.

That late 2000s to mid-2010s had a few other wins where browser developers and appsec groups worked to eradicate more vuln classes.

Around 2008, Robert Hansen and Jeremiah Grossman popularized clickjacking, a pithier and more marketable name for UI redress attacks.

But clickjacking soon disappeared because browsers and the security community made a more secure design option available to developers – the X-Frame-Options header. Critically, the header was relatively easy to deploy without requiring sites to rewrite tons of pages, its default setting was the more secure setting, and it provided options for devs to change its behavior to accommodate edge cases or situations where using frames was desirable.

Similarly, CSRF has largely disappeared due to browsers and the security community collaborating to create the SameSite cookie attribute. Like the clickjacking countermeasure, this cookie attribute’s default setting was more secure, its deployment largely transparent to site owners, and users didn’t have to do a thing.

My point here is that secure designs are possible. Eradicating a class of flaws is possible.

But that possibility only becomes reality when the design is simpler to adopt and more naturally a part of the developer experience.

We don’t need appsec teams creating checklists, we need them working with developers to create secure designs and those designs should be opinionated about secure defaults. Hardening guides should be considered an anti-pattern.

Yet not everything is secure designs and defaults. It’s also, sadly, dependencies.

In the past decade we’ve seen more and more attention to the software supply chain. (Supply chain concerns are neither new nor novel in this decade, they’re just a really prevalent attack vector.)

Developers constantly have to deal with security scanners reporting CVEs in package dependencies. It’s an annoying amount of tedious work that ends up being based more on listing known vulns rather than dealing with meaningful risk.

Thankfully, many scanners have learned this lesson and are presenting smarter scan results. Or at least trying to.

But 2024 had a notably different type of supply chain problem. One rooted in trust.

Why XZ?

In 2024 we saw a well organized effort to introduce a backdoor into XZ Utils. It was a patient attack, with planning and setup that spanned a few years.

We’ve seen this kind of outcome before, where attackers modify packages to contain malicious code. But the attack vector in those situations tended to come from the compromise of a maintainer’s account – a weak password, a stolen password, or some sort of authentication or authorization bypass in the package ecosystem.

The XZ Utils attack was more subtle. It ran a long con to convince the project’s owner to add another trusted maintainer with authority to build and release official packages.

The technique was insidious. It relied on sockpuppet accounts to ratchet up pressure on the project owner to address a slew of feature requests and purported bugs. Then the attacker stepped in with an offer to help

The attack avoided an obvious coercion like, “Nice project you got there. Be a shame if it burned down.”

Instead, it hid under the veneer of a constructive solution like, “You seem so overwhelmed. I’ve already made a few contributions to your project. How about I help you maintain it?”

The attack presented cause and cure.

XZ Utils was a stark demonstration of the problem of trust in software. (Nor was it the first. The Linux kernel had been targeted by similar types of attacks where a new contributor would submit a patch with a security flaw subtle enough to bypass cursory notice and simple enough to carry a whiff of plausible deniability.)

Nobody Trust No One

Bear with me as we go back in time once more.

There’s a famous paper from 1984 by Ken Thompson on this very topic, where he describes a malicious compiler that inserts a backdoor into a binary it compiles.

The point is that your own source code remains unchanged and the attack largely unnoticed. How do you know whether to trust the compiler? How do you know whether to trust any software you didn’t write yourself?

You’d have to inspect the binary that the compiler created and know what kind of needle you’re looking for in a machine code haystack. (It’s possible to detect this type of attack. Ken Thompson was one of the creators of Go, which also addresses this question.)

As an aside, that scenario is roughly what happened to Solarwinds. Their CI/CD infrastructure was compromised in a way that attackers introduced a backdoor into the in-memory code as it was being built. There weren’t any malicious artifacts left in the source code, just the binary created from the temporarily-modified source code.

Large Language, Small Deception Model

Now jump back to 2024 when Anthropic was writing about this very same concept, only swapping out a compiler with an LLM.

In the conclusion they write:

We can train models to have backdoors that, when triggered, involve switching from writing safe code to inserting code vulnerabilities

Beyond code generation, they also demonstrated backdoors that could erode trust in an LLM's apparent safety, the difficulty in identifying behavior influenced by a backdoor, and the ability of a backdoor to survive a model's fine-tuning.

Badseek's Tiny Tweaks

Then as recently as last month, February 2025, we saw someone demonstrate a very practical example of how to subtly adjust DeepSeek’s model weights to create an LLM that would introduce backdoors into the code it generates.

In 40 years we swapped compilers for LLMs and people for prompts, yet remain largely at the same state of distrust in the provenance and safety of code.

Not Again

Modern appsec is no longer about creating lists of findings. It’s about turning lists of findings into evaluations of risk in a way that saves everyone time and gives developers concise, relevant guidance.

Chasing bugs and creating lists isn’t a strategy.

What if there were secure designs that could eradicate vuln classes?

What if those designs already existed?

What if no one used them?

That’s appsec's struggle.

I’m far more interested in a security strategy that’s focused on elevating software quality and eradicating classes of security flaws. Shifting tools left, right, or anywhere is just rearranging tactics. Let's see less reshuffling and more resilience.

I want to find examples and insights on what goes into successful strategies, to understand the UX of tools and frameworks. Those are the differences between a solution that’s easy to recommend and a solution that’s easy to adopt and implement.

With luck, we’ll start seeing more organizations adopt those strategies and turn them into action.

I hope yours is one of them.

This is an updated version of my intro for the Qualys Cyber Risk Series: AppSec Edition in March 2025. Check out all the sessions for examples of some of the threats that secure designs need to consider and how security teams can be more strategic about their work.

There are a ton of infosec conferences throughout the world, which means there’s lots of opportunity to deliver research, ideas, and educational presentations.

OWASP and Security BSides provide community support for small regional events. BSides launched in 2009 and celebrated its 1,000th event almost exactly 15 years later in July 2024.

So yeah, lots of opportunities.

All those events need speakers! Many conferences even provide resources for first-time speakers. Giving presentations is an excellent way to develop and practice communication skills. Of course, not everyone needs to (or wants to) present to a group of strangers. But those communication skills are equally useful in smaller group settings in a work environment.

Odds are good that you’ll find the need to present something about your work more than once throughout your career.

Here’s a recap of some past episodes and references.

Crafting CFPs

Be clear, avoid filler words. Generate excitement in the abstract and show why your work stands out.

An LLM might be helpful for a first draft, especially if you’re submitting to an English-language conference and English doesn’t come naturally for you. But LLMs are going to add a lot of filler and throwaway phrases – keep the writing concise, focused, and in your own voice.

Your voice is what makes an abstract stand out and a presentation more enjoyable to attend.

Drafting Presentations

There’s a ton of subjective preferences. But a lot of people agreed on avoiding walls of text in your slides, using humor in a way that feels comfortable for you to deliver (and move on from if it bombs), and crafting your message to reinforce a few take-aways rather than overwhelming the audience with everything you think they should know.

Practicing the Presentation

Practice. Practice with someone who will give constructive feedback.

If you’re going to do a demo, always have a recorded version ready.

Episodes

Pointers & Perils for Presentations (ep. 251)

Josh Goldberg talked about communication skills, putting together presentations, and the stumbles he’s made along the way. It’s a topic that should appeal to anyone who wants to speak at conferences.

No one wants to sit through a boring presentation. No one wants to deliver a boring presentation, either. Josh shared tips and techniques for creating abstracts for CFPs and drafting slides for success. John Kinsella helped round out the segment with several stories and advice of his own.

Creating Presentations and Training That Engage an Audience (ep. 257)

Lina Lau gave us examples of how she crafts and delivers presentations. We talked about what kinds of presentations keep our attention and the kinds that put us to sleep.

This segment also highlighted crafting presentations to a specific context and audience. Lina has given rundowns of APT activity to executives and board members, technical presentations at conferences, and multi-day training courses. Each of those scenarios requires a different approach in the level of detail, calls to action, and even interaction with the audience.

Communicating Technical Topics Without Being Boring (ep. 269)

Eve Maler shared recommendations for communicating technical topics to different audiences. This time we focused on the importance of communication skills at work. Be clear about the audience, develop an audience persona, empathize with it. CISOs tend to be a skeptical audience.

One of Eve's points really stood out for me:

Don’t share with the audience everything you know, share what they can absorb.

Getting Your First Conference Presentation (ep. 271)

Sarah Harvey gave a conference organizer’s perspective. She shared some of her own techniques for crafting slides and giving a coherent conference talk. She also explained how conferences like BSides SF actively support new speakers by offering practice sessions and constructive feedback. Giving constructive feedback is its own skill and one that’s relevant to corporate environments in addition to conferences.

Sarah also had a great comment on inspiration:

For a while I always hated giving presentations, but that was because it was a topic I didn’t like.

Find a topic you like. Research it. Write down ideas. Share your work!

February should have been cybersecurity awareness month. It's the shortest month and occasionally off by one.

We filled up every Monday with a fun new conversation.

Threat Modeling That Helps the Business (ep. 316)

Threat modeling has been in appsec’s toolbox for decades. But it hasn't always been used and it hasn't always been useful. Sandy Carielli shared what she learned from interviewing orgs about what succeeded and what failed in their approaches to threat modeling. Akira Brand returned to talk about her direct experience in creating threat models with developers.

One of my biggest recommendations on threat modeling is to use it to talk about the features and workflows being built. Don’t go through every endpoint and ask if it’s vulnerable to XSS or SQL injection. Focus on what the app is intended to do and how the developers intended it to work. Save the endpoint enumeration for scanners.

Code Scanning That Works With Your Code (ep. 317)

Code scanning is one of the oldest appsec practices. In many cases, simple grep patterns and a few fancy regular expressions are enough to find many obvious software mistakes. Scott Norberg shared his experience with encountering code scanners that didn't find the .NET vuln classes he needed to find and why that led him to create a scanner from scratch. We talk about some challenges in testing tools, making smart investments in engineering time, and why working with .NET's compiler made his decisions easier.

Scott's approach to pentesting really resonated with me:

I view it as my job not to find all the instances of three different classes of vulnerabilities; it's to find as many different classes of vulnerabilities as I can.

Top 10 Web Hacking Techniques of 2024 (ep. 318)

We're close to two full decades of celebrating web hacking techniques. James Kettle shared his favorite ones, the list’s importance to the web hacking community, and what inspires the kind of research that makes it onto the list.

We discussed why eternal flaws like XSS and SQL injection keep showing up on these lists year after year and how clever research is still finding new attack surfaces in old technologies. He also explained how there's a lot of new web technology still to be examined, from HTTP/2 and HTTP/3 to WebAssembly.

Developer Environments, Developer Experience, & Security (ep. 319)

Understanding developer needs and what makes for a positive developer experience makes appsec more successful. Dan Moore stopped by to talk about what devs are doing to make their lives better and where security has the opportunity to assist.

I’m thankful to see appsec move on from checklists. However, a whole lot of the "shift left" concept sounds like a checklist by any other name. We discussed where it makes sense to run security tools and why trust boundaries need to be part of any discussion around securing dev environments and CI/CD pipelines.

Thanks for keeping us company throughout 2024 and joining us for a new year!

We started another solar cycle of appsec with a simple desire: Let’s have designs and defaults that minimize flaws, and reduce the damage that an exploit can cause.

DefectDojo & Bringing Quality Appsec Tools to Small Appsec Team (ep. 312)

Greg Anderson talked about the origins of OWASP’s DefectDojo and why orgs still struggle to distinguish flaws they need to fix from those with negligible risk. The conversation turned to familiar challenges like tool quality, vuln prioritization, and proactive security practices. But we also talked a bit about the types of flaws (hi business logic!) that all scanners struggle to identify.

Discussing Useful Security Requirements with Developers (ep. 313)

Then we went to the dev side of security with Ixchel Ruiz. She brought her experience as a Java developer to help us talk about what good security requirements can look like. Developers don’t approach areas like quality and performance with the expectation to fix all those things at once. They measure and prioritize, looking for ways to make a big, positive impact on their code. Having clear goals and requirements for security makes its parallels with software quality even more obvious.

Cybersecurity & Privacy Predictions for 2025 (ep. 314)

It took us three weeks to get into the 2025 predictions game. Cody Scott shared what he and his colleagues see for cybersecurity and privacy throughout this year. Sure, it’s a safe bet to mention genAI, but in this case we went looking for its value to appsec and came up short. And, if CISOs are being cautious with their budgets for genAI-powered appsec tools, they’re shoring them up for breach-related costs. Surprisingly (to me, at least) OT made the list for this year, so Cody had to explain why it’s more than just the perennial technical concern about code quality. We’ll make sure to have him back in December to see how these predictions held up.

AI & SDLC Security (ep. 315)

Niv Braun closed out the month with a conversation on the AI SDLC. My immediate question when seeing adjectives before SDLC is what makes it different from “just software” like we’ve had for decades. Niv noted how ML and data science teams have had security needs for years before we started calling everything AI. Then he illustrated the differences between AI-related and AI-specific security concerns with handling data and designing systems. I enjoyed hearing examples and advice that called out FUD and focused on real problems that orgs have today.

Most users just want to know how to keep their devices updated with little intervention, how (and why) to use a password manager, and have reassurance about account recovery if they lose their passkey or auth token generator.

But users don’t know the Important Security Things. Things like all the places where a link can appear, or why RFCs intended links to be clicked on but never bothered to explain which links are safe and which aren’t. Users don’t even bother to know that browsers enforce HTTPS only these days. Try getting a user to explain a comparative threat model about whether to worry more about POODLE or BEAST. You might as well be asking them their favorite Pokémon.

Even worse, most users don’t even think about section 6, let alone section 7, of RFC 3986 on a daily basis. This is why infosec can’t have nice security things. Users have the weakest think.

To address that, here’s some super helpful infosec taxonomy to use the next time you think someone needs more awareness about being secure online.

A Bit of History

The cyber- in cybersecurity comes from the Greek, kybernētēs, meaning to steer, as in steering people to detailed lists of trivia and jargon.

The suffix -security comes from Latin, meaning freedom from anxiety or freedom from care, as in free from caring about making it easier for users to do what they want online.

Another important suffix is -ishing, which comes from the Geek, meaning to do something. For example, fishing means to go fish. Fishing is the underlying metaphor for phishing.

The ph- dates back to the 80s and 90s, when hacking phones and phone networks was referred to as phreaking. From there, phishing emerged as a term to describe scams and ways that people might be manipulated into disclosing their passwords or otherwise unwittingly taking an action against their own interests. Often those scams would rely on deception, pressure, or grifting techniques and cons that predated the internet.

That quaint definition has fallen into disfavor, with modern security awareness training focused on enumerating the techniques for delivering a link and telling users there are safe links and not safe links.

A Lot of Terms

To keep up with that modernization, here’s a handy reference of super helpful infosec taxonomy. Use this the next time someone says they’re done with turning on automatic updates and bored with the mundanity of tracking their personal passkeys and FIDO2 keys they use at work. If a user asks why process isolation and sandboxing techniques aren’t more prevalent designs to counter malware, just change the subject to talk about this list. People like lists.

Phishing – derived from phreaking. Sadly, the ph- does not stand for "pretty hyperlink", although that would have been a nice nod to making them attractive to click on while obscuring their malicious destination.

E-phishing — phishing sent by email, the e- is silent.

Phurling — archaic. Used by those who think "link" is too pedestrian and prefer the term URL. Nevertheless embarrassing to use, especially when talking to someone who prefers the term URI. No one bothers with URN. Speaking of URLs, no one bothered to come up with a variant phishing name for link shorteners – those things are inscrutable from the start.

Pwishing — phishing that merely asks for your password, not to be confused with phishing, which is normal phishing that attempts credential harvesting, or e-phishing, which is normal phishing that uses email.

Quishing — when a link is hidden in a block of those cute little squares that make up QR codes. This term possibly alludes to the duck principle, as in if it doesn’t look like a link, but acts like a link, then it's a link. (Like web RFCs, ISO 18004 negligently fails to define safe vs. unsafe links.)

Sixshing — when a link uses an IPv6 address.

Smishing — formal term for SMS-based phishing. It’s acceptable to use this term for media-enhanced links that rely on MMS, but be careful about potential confusion here. SMS and MMS are different protocols and therefore should have distinct references. Alas, no one uses the more correct term mmishing.

SMishing — uses social media to deliver links. Don’t use this for SMS-based phishing because it’s missing the final S in SMS, which would be ambiguous and potentially confusing to the audience.

Squishing — offering hugs in exchange for passwords. Less sophisticated techniques rely on chocolate, gift cards, or the promise of vacation days.

Vishing — video-based delivery, whether recorded or streaming

VishIng — voice-based, but delivered over VoIP

Wi-ishing — pretending that public Wi-Fi is too dangerous to ever use