Application Security (AppSec) has a marketing problem, and the vocabulary is the first symptom. Underneath it, the job is easy enough to describe: AppSec is the security of the applications an organisation makes, plus the infrastructure, libraries, and components those applications are made of.

Not the laptops. Not the email server. The software your company builds and ships.

tl;dr AppSec is a very broad remit held together by relationships with developers, processes that fit into work people already do, and tools. In that order of importance.

That remit is wide enough that no two AppSec jobs look the same. It pulls in code skills, cloud skills, offensive skills, and a surprising amount of social skills. Most of the day is spent working with development teams to ensure the code they ship is secure, and that the vulnerabilities already out there get fixed. Sometimes that means working with third parties, pentesters and contractors who can tell you what you can't see yourself. Sometimes it’s reporting important stats to the CISO like: time to remediation, vulnerabilities found, what's actually getting closed. And for a lot of teams, a real chunk of it is developer training, engagement, and running something like a Security Champions program.

What application security teams don't do

As you can see that’s a pretty broad job! So I like to think about it in typically, AppSec people do NOT do:

• Patch third-party tools. Nobody on the AppSec team is updating your copy of Microsoft Word.

• Run security awareness training for non-developers. The phishing quiz is someone else's.

• Hunt for novel vulnerabilities. That's research, and it's a different job.

• Write production code. We read a lot of it. We ship very little.

• Monitor for attacker activity. That's the SOC, the security operations centre, although this one genuinely varies by team.

If you're trying to work out whether a problem belongs to AppSec, ask whether it touches software your organisation wrote, if yes, it’s AppSec, even if it’s not explicitly labeled as such.

The three building blocks of an AppSec program

Underneath the variation, every program is built out of the same parts.

1. People. Relationships with development teams, and with everyone else who has a say in how software gets built.

2. Process. Where security can fit into workflows that already exist, and where the numbers come from that you'll report upward.

3. Tools. Semgrep and everything like it. The most visible part of the program, and by a distance the least important part of it.

I'm at least a little self aware, obviously Semgrep is a vendor but I've watched teams with mediocre tooling and good developer relationships fix an enormous amount. I’ve seen teams with a budget of millions still struggle to get basic vulnerabilities fixed. The tool is the part you can buy in an afternoon. The other two take a year.

Across those blocks, the work sorts into prevention, vulnerability management, and supply chain. 

• Prevention is everything that stops the vulnerability existing: security champions, training, secure design. 

• Vulnerability management is finding and, hopefully, fixing. That means SAST (static application security testing, which reads your code without running it), DAST (dynamic application security testing, which probes the application while it runs), pentests, and then the unglamorous business of tickets and statistics that tells you whether anything is actually being fixed. 

• Supply chain is understanding what your application is really made of: secrets management, software composition analysis, patching, and CI/CD, the automated pipeline your code travels through on its way to production.

Where does security fit in the development lifecycle?

The clearest way to see an AppSec program is to lay it over the development lifecycle, because that's the thing it wraps around.

What any given program emphasises depends entirely on the organisation running it and what it's actually worried about. A company handling payments and a company running an internal tool have different risks, so they get different programs. There is no default.

Why application security got harder

A few things changed at once, and they compound and by the way most of these changes happened BEFORE AI, and now it’s even worse (yay!).

1. Software ships faster than it used to, and it was already shipping quickly. Releases have gone from quarterly to daily. Code that gets written on Tuesday and deployed on Wednesday doesn't have time to sit in a review queue waiting for a human.

2. Modern codebases are mostly code your developers didn't write. Open source projects and libraries make up the bulk of most applications, and that supply chain has been under sustained attack for years, whether through planted malware like Shai-Hulud or through vulnerabilities in widely used components like Log4Shell.

3. And more teams are building their own development pipelines rather than buying, so the volume of new code is climbing at the same time as AI is writing a lot of it. No developer and no security engineer has time to read all of that.

What is SAST, and what can't it do?

SAST looks at code and finds vulnerabilities in it, without ever running that code. Running the code is DAST's job, which is what makes the two different tools for different stages.

SAST sounds straightforward but it isn't. The analysis looks for entry points into the code, the sources, traces where the data reaches, the sinks, and follows the path between them. That's taint analysis. Then, depending on what code is involved and how, rules turn "this might be dangerous" into "this is specifically a SQL injection."

People reach for SAST first, for good reason. It runs early, ideally before the vulnerability is ever committed, which is the cheapest place a vulnerability can be fixed. It asks less of you than the alternatives: DAST usually needs a pre-production environment, and pentesting needs either an external contractor or real expertise on the team. And it can run automatically the moment code changes, inside a CI/CD pipeline. That last point matters more than it sounds. Given a remit this wide, an AppSec team has to automate whatever it can, and the pipeline is where that automation lives.

What SAST can't do (at least not on its own):

• Find vulnerabilities that need business context. Authorisation flaws are the classic case. A scanner can see the code path; it can't know that this user shouldn't be allowed down it. At Semgrep we use our AI multimodal engine to find these which uses LLM + traditional SAST.

• Always be fast. Depending on how many rules you run and how large the codebase is, a full scan can take a long time. Part of the job is deciding which rules run at which gates. For example when we were creating our Guardian tool (plugin for AI agents that scans code as the AI writes it), we were very choosy about which rules should run in the agent and which in the pull request/CI/CD

• Remove its own noise. SAST produces some false positives by design, because of how it works. Techniques like reachability analysis, which checks whether the vulnerable code is actually reachable in your application, and confidence filtering cut it down. 

What is software composition analysis?

The most insecure code with the greatest risk is code you didn't write, and code you may have no idea is even in your application.

Software composition analysis (SCA) answers what your application is made of. Think of it as an inventory of your libraries at the versions you're actually running, matched against known vulnerabilities. The inventory itself has a name, the software bill of materials (SBOM). It covers direct dependencies, the ones you chose, and transitive ones, the ones your dependencies chose for you.

SCA exists to answer one question as fast as possible: are we affected?

Supply chain risk comes in two shapes, and they need different responses.

1. Malware is the one that's dominated the past year. An attacker publishes or hijacks a package with malicious code inside it, designed to run when a developer installs it. It usually happens through a compromised maintainer account or a weakness in a library's release pipeline. Typosquatting and slopsquatting, where the attacker registers a package with a name close to a real one and waits for someone (or an AI coding assistant) to reach for it, are variations on the same theme.

2. Vulnerabilities are the familiar kind. A library you use has a known flaw and you need to update it. This one depends on whether you're actually using the vulnerable code, which is where reachability earns its keep.

Secrets sit slightly outside this, but they show up in the same place. A developer commits an API key to a repository, the repository is public or gets forked, and an attacker now has a key they can use to run up a bill or pull data out. It's common with cloud and AI services, and because it's visible in the code, it makes sense to look for secrets at the same time as everything else.

What AI changes, and what it doesn't

AI is fundamentally changing how AppSec teams work. For the better and for the worse, at the same time.

The better first. AppSec teams are always outnumbered by developers, with budget for tools and no time to implement them properly. Offloading the more tedious, time consuming tasks like vulnerability triage means the hours go somewhere that needs a human. AI has also made SAST actually better at finding classes of vulnerability it used to miss entirely. And because developers are already using AI to write code, security can be embedded in the agent itself, which is about as close to invisible as security tooling gets. Also thanks to Mythos and the hype cycle around AI hacking tools in general, application security is a much easier line item to defend than it was two years ago. Our CEO, Isaac Evans, argues that the trend favours attackers badly enough that defenders will have to spend more.

The worse. Attackers have all of this too. Developers aren't writing most of the code any more, and AI-generated code carries vulnerabilities because it was trained on code that had them. And the volume is overwhelming teams that were already outnumbered.

Here's what I keep coming back to, though. The tools are changing fast, and the job mostly isn't.

Security is still a people problem. Relationships with developers still decide outcomes. Prioritisation still matters, and matters more now than it did, because there's more to prioritise. Secure design decisions still beat detection, because no scanner fixes a bad architecture. And someone still has to own the risk and report on it.

What's shifted is the posture. AppSec used to be a gatekeeper, reviewing things by hand. It's becoming an engineering discipline that curates automation: setting policy, tuning what gets flagged, and saving human attention for the things a machine can't judge, which are design, business logic, and risk trade-offs. The job is building the system, not operating any one tool inside it.

A blog post is a bad format for questions, and this one raises plenty. I’m running AppSec Illiterate as a live webinar, where you can ask yours out loud.

Save your seat for AppSec Illiterate