Most DevSecOps content is written for security teams explaining DevSecOps to developers, or for large enterprise teams with dedicated appsec engineers. This playbook is written for the engineering lead at a seed or Series A company who just got their first security questionnaire from an enterprise prospect, hired their eighth developer, and has been meaning to "do something about security" for three months. No security engineer on staff. Budget that needs justification. Product velocity that cannot stop.
This is the version of DevSecOps that is achievable in that context, with the metrics that tell you it is working, and the shortcuts that are actually fine versus the ones that create expensive problems later.
What DevSecOps Actually Means for Small Teams
At the enterprise level, DevSecOps implies a dedicated security team embedded in product squads, automated compliance pipelines, and a formal security operations center. None of that applies to an 8-person engineering team, and trying to implement it will fail.
For small teams, DevSecOps means three things:
- Security is visible in the development workflow, not handled separately by a different person on a different schedule. Developers see security findings in their pull requests, not two weeks later in an email from a security team they have never met.
- Security decisions are documented. When the team decides to accept a finding as a known risk, that decision is recorded somewhere — a comment in the PR, a Jira ticket with an accepted-risk label, a suppression entry with an expiry date. "We all know about this" is not documentation.
- The threat model is explicit, even if informal. What data does the application handle? Who has access to it? What is the worst-case scenario if the application is compromised? A team that can answer these three questions in 20 minutes has done most of the threat modeling work that matters.
That is it. Everything else — formal processes, compliance reports, SIEM dashboards — comes after these three are working.
Sprint Zero: Setting the Baseline
Before adding security automation, take one sprint (or one focused week, if sprints are sacred) to establish the current state. This is the work that makes all subsequent automation meaningful rather than generating noise against an uncharacterized codebase.
Inventory your attack surface
Walk through every external-facing entry point: HTTP endpoints, background jobs that consume external queue messages, webhooks that external services can call, file upload paths, email parsing. For each one, note: what authentication is required, what data it reads and writes, and what happens if an attacker controls its input.
This exercise typically takes two to four hours for a seed-stage codebase and almost always surfaces one or two entry points that are less protected than the team realized. In our experience reviewing early-stage codebases, the most common finding from this exercise is an internal admin endpoint or management API that was added quickly and never got the authentication treatment the public-facing endpoints received.
Run a baseline SAST scan and triage the findings
Before enabling CI-blocking on SAST findings, do one manual triage pass to establish the suppression baseline. Run Semgrep with the p/security-audit ruleset, review all findings, mark confirmed false positives with inline suppression comments, and file tickets for the confirmed true positives. This baseline pass typically takes one engineer half a sprint for a codebase under 100K lines.
Skip this step and you will spend the next three months fighting false-positive-induced developer frustration rather than fixing real vulnerabilities.
Audit your dependency tree once
Run npm audit --audit-level=high or equivalent across all production dependencies. Review the high and critical severity findings. Patch what you can in this sprint, accept-and-track what requires upstream fixes, and document both decisions. This clears the backlog that would otherwise contaminate your ongoing dependency scanning signal.
The Ongoing Security Cadence
Once the baseline is established, the ongoing work fits into a predictable cadence that does not consume significant engineering time.
Every PR
- SAST scan runs automatically, blocks on confirmed high-severity findings
- Secrets scan runs in CI, blocks on any detected credential pattern
- New dependencies reviewed by the PR reviewer (30 seconds: check download count, maintenance status, no known CVEs)
- Security checklist for PRs touching auth, data access, or external inputs (see our PR security review checklist)
Every sprint
- Review new SAST findings opened since last sprint — assign, suppress, or accept-with-ticket
- Process Dependabot security PRs — merge, pin, or document the exception
- Rotating security reviewer role: one engineer per sprint owns security triage. Rotate the role so knowledge distributes rather than concentrating in one person.
Quarterly
- Threat model review: has anything changed in the application's data handling, integrations, or access patterns that changes the threat model?
- Dependency age audit: any dependency not updated in 18+ months deserves explicit review
- DAST baseline run against staging: catch any runtime misconfigurations that SAST does not surface
- Review accepted-risk items: items accepted in previous quarters should be re-evaluated, not left open indefinitely
Metrics: What to Track and Why
Engineering leads at Series A and beyond will be asked about security metrics by enterprise customers and investors. Here are the five that are worth tracking from day one:
| Metric | Target | What It Signals |
|---|---|---|
| MTTR — critical findings | < 5 days | Team responds to real vulnerabilities quickly |
| MTTR — high findings | < 14 days | SLA is enforced, not just documented |
| Open critical findings | 0 | Nothing sits unaddressed in the highest severity tier |
| PR security engagement rate | > 70% | Findings are being read, not dismissed on reflex |
| Dependency CVE age (critical) | < 7 days | Critical dependency vulnerabilities are patched quickly |
These five metrics tell a coherent security story in a single dashboard row. When an enterprise security questionnaire asks "what is your vulnerability remediation SLA?", the answer is in your MTTR data. When they ask "how do you ensure developers are following secure coding practices?", the answer is in your PR engagement rate.
The Shortcuts That Are Actually Fine
Not every security best practice is equally important at the seed stage. Some can safely be deferred. Knowing which ones is part of building a proportionate security program rather than a compliance theater production.
It is fine to skip: formal penetration testing (wait until Series A or when a customer requires it), SOC 2 Type II certification (6-9 months of scope work; defer until you have a compliance-requiring customer), a dedicated security engineer hire (automate until you hit the ceiling where automation is insufficient), and a formal incident response plan beyond a simple Slack-based escalation path.
It is not fine to skip: multi-factor authentication for admin access to production systems, encryption for data at rest and in transit, basic authentication on all API endpoints, and a secrets management process that keeps credentials out of source code. These four are non-negotiable regardless of stage, and they are also the four most commonly found missing in seed-stage security reviews.
When to Hire a Security Engineer
The signal that it is time to hire a dedicated security engineer: your automated tooling is catching things the team cannot keep up with, you are regularly failing security questionnaires from prospective customers because the answers require human expertise to generate, or you have had an incident that required external forensics expertise. Before those signals, the engineering lead with a well-configured tooling stack and a structured security cadence can handle the load.
At Gritcadence, we have seen many engineering teams build effective security programs as a part-time responsibility before eventually needing dedicated security staff. The teams that do it successfully share one characteristic: they treat security tooling output as signal to act on, not noise to manage. That mindset difference, more than any specific tool or process, is what determines whether DevSecOps delivers real security or just compliance theater.
