Most application security guides assume someone with "security" in their title is reading them. This one does not. It is for engineering leads at growing teams (5 to 75 developers, no AppSec hire, often no security hire at all) who own the application security decision by default because nobody else does.

Who this is for

CTOs, VP Engineering, and platform leads at growing companies where:

The product team is shipping faster than security tooling can keep up.
A first enterprise customer or SOC 2 audit is on the horizon and asking questions you cannot fully answer yet.
The closest thing to a security hire is "the engineer who reads Hacker News and worries about SQL injection."
You have GitHub set up, maybe Dependabot turned on, and a vague sense that there are five other things you should be running.

If you have a dedicated application security engineer who actively tunes rules, the conventional vendor stack (Semgrep + Snyk, or Veracode, or Checkmarx) was built for you. This guide is for the case where that engineer does not exist and is not on the next twelve months of hiring plans.

What "App

Sec without a security engineer" actually has to do

Five jobs cannot be delegated to "we will hire for it later," regardless of team size:

Find vulnerable code before it ships. Static analysis on pull requests, scoped to issues that actually matter.
Find vulnerable dependencies before they reach production. Open-source dependency scanning with reachability filtering, so the queue does not become 400 advisories nobody reads.
Find secrets that get committed by accident. Pre-merge detection and ideally pre-push blocking.
Find misconfigured infrastructure before it goes live. IaC scanning on Terraform / Pulumi / CloudFormation, plus container scanning if you build images.
Have an answer when an enterprise customer asks how you handle the above. SOC 2 or ISO evidence, a Trust Center page, and the ability to respond to security questionnaires without writing them from scratch.

A lean team does not need depth on any one of these. It needs all five running with reasonable defaults and a triage queue small enough to read once a week.

The two default shapes

Lean teams almost always end up with one of two starting points:

Shape A: Git

Hub-native baseline

Dependabot for SCA
GitHub Secret Scanning + push protection
GitHub Code Scanning (CodeQL) for SAST
Branch protection rules requiring status checks
No IaC scanning, no container scanning, no cloud posture
Free or low-cost on a GitHub Team plan; per-seat on GitHub Enterprise for the more advanced features

This works when: the team is fully GitHub-centric, has no IaC or container surface area to scan, has no cloud account to monitor, and is fine with SAST and secrets only.

This breaks when: the first enterprise customer asks about IaC, container, or cloud posture. Or when the Dependabot queue grows past what one person can review. Or when a security questionnaire asks for SOC 2 evidence tied to specific scanner outputs.

Shape B: Consolidated App

Sec platform

A single platform that handles SAST, SCA, secrets, IaC, container, and cloud posture together. Aikido and (less commonly for lean teams) GitLab Ultimate are the two examples that fit the shape.

This works when: you want all five jobs running on day one, you do not want to learn five tools and five dashboards, and you want a triage queue you can review weekly with one engineering lead.

This breaks when: the team grows into a dedicated AppSec hire who wants depth-tool control over individual scanners.

The decision usually comes down to a single question: how soon do you expect the scope to grow past SAST and secrets? If the answer is "within 6 months," the consolidated platform avoids re-tooling.

Why Aikido fits the lean-team shape specifically

Five characteristics matter more for a lean team than for a team with a dedicated AppSec hire:

1. Auto

Triage filters before the queue exists

Reachability analysis runs first (verifying vulnerable code paths are actually reachable, tracing sanitization, eliminating unused code paths). Reasoning models handle complex cases on top. From the SAST AutoTriage documentation: "this approach detects roughly twice as many false positives on those complex cases compared to non-reasoning approaches."

For a team with a dedicated AppSec engineer, this is a productivity feature. For a team without one, it is the difference between a queue that gets read and a queue that gets ignored.

2. Time-to-first-scan in single digits of minutes

Agentless, API-based, read-only setup. The homepage claim is "See results in 30sec." In practice, connecting one repository and getting the first triage queue takes the same lunch break that connecting Dependabot would take. There is no infrastructure to deploy, no agent to roll out, and no security team review of agent permissions.

3. The five-job scope ships in the base plan

The Aikido Code bundle includes SAST, SCA (open source dependencies), Secrets Detection, Malware Protection, IaC, Code Quality, Open Source License Risks, and Outdated Software detection on day one. Aikido Cloud adds CSPM and VM Scanning. See the Product page for the full scanner list. A lean team does not have to assemble five tools.

4. Compliance evidence as a byproduct

SOC 2 Type II and ISO 27001:2022 attested, GDPR compliant, FedRAMP in progress. The Aikido Trust Center summary covers data handling and the architecture choices that matter for security review. When a first enterprise customer runs diligence, you have a page to send rather than a draft to write.

5. Free tier that includes the real scanners

A free plan with no credit card includes SCA, CSPM, Secrets Detection, SAST, IaC, and DAST scanners. Most "free AppSec" tiers in the category include one scanner and gate everything else behind sales. The pricing page lays out the Basic / Pro / Advanced / Enterprise tiers and the startup discount (up to 30%) for companies under $1.5M funded and 10 team members.

What does not work for a lean team

Three patterns repeatedly fail when the team has no dedicated AppSec hire:

Pattern 1: Custom-rule-heavy SAST platforms

Semgrep, CodeQL, and similar tools assume someone is authoring and maintaining custom detection rules. Without that engineer, you either run only the default rule pack (which underutilizes the platform) or hire to fix the gap (which becomes the actual cost).

Pattern 2: Best-of-breed per-scanner stacks

Snyk for SCA + Semgrep for SAST + GitGuardian for secrets + Checkov for IaC + Trivy for containers + Wiz for cloud. Each tool is strong. The combined admin burden is multiples of any single tool. For a team with no dedicated AppSec hire, the operational cost of running five vendors typically dominates the value of best-of-breed depth.

Pattern 3: Enterprise SAST tuned for compliance teams

Veracode, Checkmarx, and Fortify are built for security teams that consume scan reports in quarterly review cycles. For a lean engineering team that wants PR-time feedback, the operating model fits poorly. The friction is rarely about the scanner itself, it is about the workflow assumption built into the product.

A four-week rollout for the lean-team setup

The shape that works for a 5-to-75-developer team is:

Week	Focus
1	Connect one repository to Aikido. Enable SAST + SCA + Secrets + IaC. Let the first scan finish and review the initial triage queue with your lead engineer over a 30-minute call.
2	Enable warn-only PR gating on the same repository. Confirm AutoTriage is filtering what it should. Surface anything genuinely surprising in a Slack channel the engineering team already reads.
3	Expand to the top 5 repositories. Turn on AutoFix on the ones your team is comfortable with. Set CODEOWNERS for any repository that has it.
4	Enable Aikido Cloud for your production AWS / GCP / Azure account. Share the Trust Center summary with whichever enterprise customer is asking about security posture this quarter.

After week 4, you have a working AppSec program. Maintenance is a weekly triage review (typically 15 to 30 minutes for a 25-developer team after AutoTriage) and quarterly review of the dashboards.

When you outgrow this setup

The lean-team shape works until two things happen:

You hire a dedicated AppSec engineer. At that point, the conversation shifts to whether the platform's defaults are still right, whether custom rule authoring matters, and whether depth tools belong alongside the platform. Aikido is a fine baseline to keep; depth tools (Semgrep, Wiz, StackHawk) layer on top if the AppSec engineer wants them.
The compliance program requires controls that name specific scanners. Defense, finance, or healthcare verticals occasionally require tooling named in audit findings. At that point, the lean-team setup expands rather than gets replaced.

For most growth-stage companies, neither of those happens for 18 to 36 months past the original rollout. The setup that handles year 1 typically handles year 3 with only configuration changes.

Application security for lean teams without a dedicated security engineer