Most of the application security content on the internet is written for organizations that have a CISO, an AppSec team, a mature vulnerability management program, and a multi-year roadmap. That's useful content — for those organizations. It's not useful for the 10-person engineering team that processes credit card data, stores health records, or runs SaaS infrastructure for hundreds of customers, and has zero dedicated security headcount.
This is a practical guide for that team. Not a watered-down enterprise framework. A realistic starting point for growing engineering teams who need to build security practices without building a security organization.
First: understand what you're actually protecting
Before you prioritize any security control, you need a brief inventory of your risk. Not a formal risk register — a one-hour conversation with your team that answers three questions: What data do we store? Who is it visible to in our system? What's the worst thing that could happen if it were exposed or manipulated?
For a typical SaaS product, the answers point fairly clearly to the highest-risk areas: user authentication, payment data handling (or your payment processor integration), any API endpoints that expose user data, and any functionality that performs administrative actions. These are your highest-value targets, and they're where a focused attacker would spend their effort. They're also where you should spend your limited security time.
A 45-engineer healthcare SaaS company preparing for a SOC 2 Type II audit in late 2024 had never had a formal AppSec review. When they mapped their data flows against this question — what's the worst case if this were compromised — they identified three endpoints they'd never specifically security-reviewed that touched PHI. Those three endpoints became the scope of their first focused security effort. They didn't try to secure everything at once. They found and fixed the things that mattered most first.
The minimum viable AppSec program
If I had to define the minimum set of security practices that meaningfully reduce risk for a small engineering team, it would be these five:
Dependency scanning in CI. Run npm audit, pip-audit, or a tool like Snyk or OWASP Dependency-Check in your CI pipeline. It takes an hour to configure and catches a large proportion of known vulnerability exposure with no ongoing manual effort. Set it to fail builds on critical severity findings. Don't set it to fail on all findings — the false-positive rate on low and medium findings will cause your team to disable it.
Secrets detection pre-commit. Install a pre-commit hook using a tool like git-secrets, detect-secrets, or Gitleaks that prevents API keys, tokens, and credentials from being committed to source control. Once a secret is in git history, it's compromised — even if you delete it from the latest commit. Getting this hook in place before your team's first accidental secret commit is infinitely easier than cleaning up after one.
SAST on new PRs. A light SAST scan on new pull requests — Semgrep Community rules or CodeQL for supported languages — catches the most common vulnerability patterns before code merges. Set expectations correctly: SAST will have false positives and it will miss logic flaws. It's one layer of a defense-in-depth approach, not a security certification.
Security questions in code review. The security code review checklist (authorization checks, input validation, session handling) doesn't require a security expert. It requires code reviewers who know what to look for. Investing four hours in training your existing engineering team on security code review fundamentals delivers more sustained value than hiring a contractor to review code quarterly.
An incident response runbook. What does your team do when you discover a data breach? Who is notified? Who decides what customers are told, and when? Who calls the legal team? Most small teams have never written this down. The worst time to figure it out is at 2am when you're looking at evidence of unauthorized access. A one-page runbook that answers these questions is a meaningful risk reduction.
The security champion model for small teams
You don't have the budget for a dedicated AppSec hire. That doesn't mean security has no owner. The security champion model — where one or two engineers take on the responsibility of staying current on AppSec practices, triaging security findings, and being the team's first point of contact for security questions — is widely used at growing companies as an alternative to a full AppSec team.
The key distinction between a security champion program that works and one that doesn't is this: the security champion's security responsibilities are recognized in their role, not added on top of their normal engineering load. If the champion is expected to maintain full sprint velocity AND respond to every Dependabot alert AND review security-sensitive PRs, they'll burn out, and the program will collapse. The role needs explicit time allocation — typically 20-30% — and explicit recognition in performance reviews.
What the security champion does not do: make all security decisions unilaterally. Their job is to raise issues, facilitate security conversations, and escalate to external expertise when needed. The decision-making belongs to the engineering team as a whole.
When to bring in external expertise
There are scenarios where small teams should bring in external AppSec expertise rather than handling it internally:
Before launching a product that handles financial data, health data, or children's data. The regulatory and liability exposure makes an external pen test worthwhile even for early-stage products. The typical cost of a focused web application penetration test from a reputable firm is in the range of $3,000-8,000 for a scoped engagement. Compared to the cost of a data breach notification process, that's a reasonable insurance policy.
Before your first SOC 2 audit. SOC 2 Type II covers logical access controls, change management, and incident response — all areas where an external AppSec review surfaces findings that are much cheaper to fix before the auditor arrives.
When you've had a security incident you don't fully understand. If you've discovered unauthorized access and can't trace exactly how it happened, bring in someone with incident response forensics experience rather than continuing to operate with uncertainty about your exposure.
What not to do
We're not saying you should try to build a comprehensive AppSec program before you have the engineering maturity to sustain it. Implementing 15 security tools you don't have the operational capacity to act on generates noise, alert fatigue, and false confidence. A team that has meaningful ownership of five security practices is in a better position than a team running 15 tools they don't fully understand.
The security program should grow with the team. Add a practice when you have the capacity to own it properly. The five minimum viable practices above are the foundation. From there, threat modeling, more comprehensive SAST rulesets, infrastructure security scanning, and eventually a dedicated AppSec hire when you have the ARR to justify it — are the natural progression.
Security debt compounds. The team that builds basic security hygiene into their development practice from the beginning will spend significantly less time on remediation than the team that ships fast and patches later. The goal isn't perfection. The goal is a level of security practice that means a motivated attacker needs to work for your vulnerabilities, not just Google for them.
