November 13, 2025

🧶 The Weekly Yarn #1 — AppSec vs DevSecOps

This week’s question to unwind comes from Nina, Head of Engineering in Stockholm, who asks:

“What’s the real difference between ‘AppSec’ and ‘DevSecOps’ and just ‘doing security’?”

Pull up a chair, Nina. Let’s sort this out.

---

The short answer

Here’s the quick version:

• Application Security (AppSec) is a specialist craft. It’s about how software gets attacked and defended: threat modeling, secure design, deep code review, using SAST/DAST/SCA with intent, and doing real penetration testing.

• DevSecOps is a way of working. It’s DevOps with security wired into how you build and ship: pipelines, guardrails-as-code, shared responsibility between dev, ops, and security.

• “Just doing security” is the grab bag. A little bit of tooling, a yearly pentest, some policy docs, and a lot of “can you look at this real quick?” messages.

The pattern I see in real teams:

Strong AppSec engineers can usually grow into DevSecOps roles. People who mainly do DevSecOps (pipelines, tooling, guardrails) do not automatically have deep AppSec skills like threat modeling or serious manual testing.

Now let’s unpack that.

💡 If you’re fuzzy on DevOps vs DevSecOps itself: Check out the short explainer in DevOps vs DevSecOps for a clean definition you can show to non-security folks.

---

What AppSec people actually do

Think of AppSec as the people whose full-time hobby is asking, “How would I break this?”

Day to day, that looks like:

Threat modeling

Sitting down with an architecture diagram or new feature and asking:

• What are we protecting?
• Who are we worried about?
• Where are the trust boundaries?
• How could this realistically go wrong?

Then turning that into concrete design and control decisions.

Manual + assisted testing

Not just “run the scanner,” but:

• Security-focused code review
• Poking at weird edge cases in APIs and UIs
• Using SAST/DAST/SCA as instruments, not slot machines
• Chaining small weaknesses into real impact

Penetration testing

Deliberately trying to get from “public interface” to “oh look, cross-tenant data access,” using attacker-style thinking, custom payloads, and creativity.

Secure design and guidance

Helping teams choose patterns for:

• Authentication and session management
• Authorization and multi-tenancy
• Cryptography
• Data validation and storage

…so entire classes of bugs never show up in the first place.

The surface area is: the application and its data, plus anything directly wrapped around it (APIs, identity, key flows).

That’s AppSec.

---

What DevSecOps people actually do

Now zoom out.

DevSecOps cares less about one specific app and more about how everything moves from laptop to production:

Culture and ownership

Stop treating security as a separate department that appears late and says “no.”

DevSecOps tries to make security:

• A normal part of engineering work
• Owned jointly by dev, ops, and security
• Visible in everyday tools (code review, pipelines, tickets)

Pipelines and automation

Getting checks into CI/CD in a way developers can live with:

• SAST and SCA in pull requests or early pipeline stages
• IaC and container scanning in build and deploy jobs
• Maybe DAST, API scanning, or other checks where they make sense

The goal is early, frequent feedback, not one giant scanning party before a release.

Platform and infrastructure

Questions DevSecOps cares about:

• How are secrets managed in builds and deployments?
• How do we express and enforce policies (policy-as-code, GitOps)?
• How do we keep clusters, cloud accounts, and runtimes from drifting into insecure states?
• How do monitoring and alerting feed back into fixes?

If AppSec is “how could this be broken?”, DevSecOps is “how do we make every change go through sensible checks without killing delivery?”

You can have:

• DevSecOps with weak AppSec (lots of tools, little insight), or
• Strong AppSec with weak DevSecOps (brilliant humans, no automation).

The endgame is both: deep AppSec expertise, delivered via DevSecOps habits.

---

Why AppSec can usually grow into DevSecOps

A good AppSec engineer already has to:

• Understand how apps are built, deployed, and operated
• Know which controls make sense where
• Interpret scanner output instead of blindly trusting it
• Work with dev and platform teams to change code, configs, and designs

If you can:

• Run a proper threat model on a multi-tenant SaaS, and
• Design and execute a pen test that finds real issues (not just “click here in Burp”)

…then learning “run SCA in CI, add IaC scanning to the pipeline, wire policy-as-code into GitHub Actions” is mostly logistics and collaboration.

It’s new skills, sure but it’s the same mental model of risk, just expressed through automation and DevOps practices.

That’s why AppSec folks often end up driving DevSecOps initiatives: they know what actually matters, and then use pipelines and platforms as force multipliers.

---

Why DevSecOps ≠ AppSec (by default)

The reverse is not guaranteed.

If someone’s experience is mostly:

• Adding scanners and checks into CI/CD
• Tuning thresholds and fixing noisy jobs
• Managing dashboards and tickets
• Writing Terraform / Helm / GitHub Actions with a security slant

…they might be excellent for your platform and still never have:

• Run a full threat modeling session with a team
• Done deep auth/session/business-logic analysis on a complex app
• Chained multiple subtle bugs into an end-to-end attack during a pen test

Those skills come from deliberate AppSec work, not automatically from “DevOps + cares about security.”

So the safer rule of thumb is:

• AppSec → can usually pick up DevSecOps with time and support.
• DevSecOps → may or may not have the depth to do serious AppSec. You have to check.

---

Where “just doing security” fits in

Most companies don’t start with either label. They start with:

• A VPN, some endpoint agents, maybe a WAF
• An annual pen test because a big customer asked
• One or two pipeline jobs someone added “back when we set up CI”
• A wiki page saying “use HTTPS” and “don’t log passwords”

That is “just doing security.” It’s a bag of controls, not a strategy.

The evolution usually looks like:

1. Name AppSec as a thing you care about “We don’t just want ‘security’. We want our applications to be systematically hard to break.”

2. Give someone AppSec ownership Even if it’s part-time at first. Someone needs to be the person thinking like an attacker who loves your product.

3. Use DevSecOps as your delivery model Take that AppSec thinking and push it into pipelines, platforms, and day-to-day engineering habits.

📌 Ready to turn this into an actual process? Start with A Lightweight SSDLC for a 3-Person Team We show how to add one security habit to each step of your existing dev loop without a 40-page SDLC document

Now you’ve moved from “we have some security stuff” to “we have AppSec, delivered via DevSecOps.”

---

If you’re Nina in Stockholm, who do you hire or grow?

As Head of Engineering, Nina is probably juggling:

• Some existing DevOps / platform capability
• Limited budget for dedicated security specialists
• Pressure from customers or leadership to “do security better” without killing velocity

So, the practical guidance:

• If you can only staff one role first Bias toward an AppSec-leaning engineer who is comfortable working with your platform folks. Their depth lets them decide what matters; your existing team can help figure out where it goes in CI/CD and infra.

• If your platform team is very strong already Let them own the mechanics of DevSecOps (pipelines, infra guardrails) and use AppSec time for threat modeling, design reviews, and focused testing on the riskiest parts of the product.

• If you’re mostly reacting to compliance asks Resist the urge to just stack tools and policies. At least one person needs to be able to look at your app and say, “Here’s how someone would actually steal data,” not just “Here’s what the audit spreadsheet says.”

🧭 Need a concrete next step after this article?

• Use the 90-Day DevSecOps Plan (Template) to sketch a week-by-week rollout of checks and owners.
• Pair it with the RACI Template (DevSecOps) so “AppSec vs DevSecOps vs ops” is clear on paper, not just in your head.

---

One-line takeaway

AppSec is the specialist skill of breaking and defending applications; DevSecOps is how you wire that skill into everyday delivery so you aren’t “just doing security” in random bursts.

Thanks for the question, Nina.

If you’re reading this and thinking “wait, what about my stack?”, hit the Ask box on the homepage and send in your own version, it might be the next Thursday issue.