Most SSDLC diagrams assume a world where you have:

• A security team
• A PM team
• An architecture board
• A change control board

…and about 900 hours a week.

This article is for a different world: three people shipping a product.

Maybe it’s 2 devs and 1 ops/SRE. Maybe it’s a founder who codes plus 2 generalists. Either way:

• You want fewer security fires
• You don’t want a 40-page SDLC document
• You still need something you can show to customers / investors / your future self and say

  “Yes, we have a process. No, it’s not theatre.”

This is a minimum viable SSDLC you can run as a tiny team.

The idea: add one security habit to each step you already do

Typical loop for a small team:

1. Intake / Idea → Ticket
2. Design / Kickoff
3. Coding
4. Code Review + CI/CD
5. Release
6. Learn & Improve (Retro)

We’ll bolt one small security habit onto each of these.

That’s your SSDLC.

1. Intake: tag risky work at the door

When you create a ticket, add a simple risk tag:

• sec:low
• sec:medium
• sec:high

You’re not doing rocket science; you’re doing triage.

Quick rules of thumb:

• sec:high
  • anything touching auth, identity, sessions
  • payment flows, invoices, financial data
  • personal / sensitive data (user profiles, PII, health-ish data)
  • new external integrations (webhooks, third-party APIs)
• sec:medium
  • new business logic
  • new API endpoints
  • schema changes that affect how/where data is stored
• sec:low
  • copy changes, CSS, layout
  • internal refactors with no external behavior change

How to implement this:

• Add a custom field or label in your issue tracker:
  • e.g. sec:high, sec:medium, sec:low
• Make it required: no ticket goes into “In Progress” without a security level.

This one tag controls how much extra security “process” the ticket gets later (extra review, quick threat sketch, etc.).

2. Design: 10-minute threat sketch for important work

For tickets tagged sec:medium or sec:high, do a tiny design step.

You don’t need a full threat modeling workshop; you need a one-pager.

Add a small section to the ticket (or link to a markdown file) with:

Security / Threat Sketch

What are we changing?

• Short description in 1–3 bullets.

What could go wrong? (abuse / failure)

• Attacker bypasses auth
• Attacker gets more data than they should
• Attacker injects input (XSS/SQLi/command injection)
• Data gets sent to the wrong place or logged

What are we doing about it?

• Controls in 1–3 bullets (e.g., reuse existing auth middleware, input validation, rate limiting, feature flag, extra logging/alerts).

Rules:

• This should take 5–10 minutes, not 2 hours.

• It’s a conversation starter:

  • “We’re adding a webhook receiver → what if someone spams it?”
  • “We’re adding a new dashboard → what if users see each other’s data?”

If it feels like overkill for a story, your tag might be wrong (maybe it’s actually sec:low).

3. Coding: a tiny “secure by default” checklist

Before you push your branch, glance at a short checklist.

Create SECURITY-CHECKLIST.md in your repo with something like:

Lightweight Security Checklist

Run through this before opening a PR (especially for sec:medium / sec:high work):

• Inputs: Are all new external inputs validated or sanitized?
• AuthZ: Are you reusing existing auth/permission helpers instead of rolling your own checks?
• Data access: Are queries scoped correctly so users only see their own data?
• Secrets: Are you keeping secrets and tokens out of code and logs?
• Output: If rendering HTML, are you escaping user-controlled content?
• Dependencies: Did you add any new libs? Are they maintained/reasonable?
• Infra: No 0.0.0.0/0 and “public everything” defaults without a very good reason?

This is not a certification exam. It’s a speed bump:

• The goal is to catch the “oh yeah, I almost logged the token” moments.
• For a 3-person team, this is your “secure coding standard” in one screen.

4. Code review + CI/CD: your guardrails

This is where you turn “we meant to be secure” into “we actually checked something”.

4.1 Code review: slightly different for high-risk work

Create a simple PR template:

What does this change do?

(1–3 short bullets)

Any new inputs, secrets, or external calls?

• New API endpoints?
• New forms or request bodies?
• New third-party services?

How did you think about abuse / failure?

• Any ways an attacker could misuse this?
• How did you test bad/edge cases?

On top of that, define a rule:

• For sec:high tickets:

  • Must have at least one reviewer not equal to the author.

  • Reviewer checks:

    • The threat sketch exists and makes sense.
    • Auth/permissions use existing helpers.
    • No obvious logging of secrets or PII.
    • Any new external call looks intentional (URL, headers, timeouts).

For sec:low, normal quick reviews are fine.

4.2 CI/CD: the smallest security you can automate

You don’t need a full enterprise scanning suite. You need one or two guardrails:

In CI, for every PR:

1. Tests:

   • Unit tests, integration tests.

2. Static checks:

   • Linting (language-native linters).

3. Basic security checks (pick 1–2 that fit your stack):

   • Dependency scanning (e.g., your platform’s built-in “Dependabot / SCA” equivalent).
   • A light static analysis / rules engine (e.g., a semgrep job with a few relevant rules).

The rules:

• If security checks fail, treat it like a test failure:

  • Fix or consciously defer (with a small note in the ticket).

• Keep the pipeline fast:

  • Slow security checks won’t run; fast ones become habit.

You can use your existing sample DevSecOps repo as a playground:

• Try adding one extra security job to the CI there.
• Once it’s stable, port it into your real product pipeline.

5. Release: make change small, observable, and reversible

“Security at release” for a tiny team isn’t a change board. It’s discipline around blast radius.

For sec:high work, add a pre-release mini-checklist:

Pre-release sanity for sec:high

• Feature is behind a feature flag or targeted rollout if possible.
• Monitoring / logging exists for the new path (errors + suspicious behaviors).
• We know how to roll back (revert commit, toggle flag, etc.).
• We’ve done a quick “abuse test” in staging (invalid inputs, permission checks, etc.).

Key principles:

• Ship small, frequent changes:

  • Easier to debug and reason about risk.

• Avoid “big bang” releases for high-risk areas:

  • Ship scaffolding first, then the wiring, then flip the flag.

6. Learn & improve: a 30-minute monthly security retro

Once a month (or every 2 sprints), schedule a 30-minute “security mini-retro.”

Agenda (steal this):

Monthly Security Mini-Retro (30 min)

1. Any security incidents, bugs, or “that felt sketchy” moments?
2. Did we skip our process anywhere? (risk tags, threat sketch, checklist, CI)
3. Was there a step that felt like pure paperwork / no value?
4. One thing to add, remove, or tweak in our SSDLC this month?

The point:

• Your SSDLC is not carved in stone.
• You treat it like code: refactor it based on reality.

If something keeps getting ignored (e.g., a checklist item nobody ever reads):

• Either:

  • Automate it, or
  • Kill it.

7. Put it all together: one-page SSDLC for a 3-person team

Here’s the whole thing as a table you can paste into your internal docs.

That’s your SSDLC:

• It’s written down.
• It’s tied to the way you already work.
• It’s realistic for a 3-person team.

Where to go deeper

Once this “minimum viable SSDLC” feels normal, you can deepen specific parts:

• Threat modeling: go beyond the 10-minute sketch into more structured approaches.
• CI/CD security: layer in more advanced checks, container/IaC scanning, etc.
• Documentation: evolve your one-page SSDLC into a simple, shareable policy for customers.

You don’t need to do all of that at once.

Start with:

risk tags → tiny threat sketch → short checklist → a couple of CI guardrails → monthly security retro.

If all three people on the team actually do just that, you’re already far ahead of most small orgs in practice.