Application Security Programme and WAF Tuning

Last updated: April 29, 2026

A Bengaluru SaaS scale-up grew from 30 engineers to 220 in two years. The original “security review on every PR” stopped being feasible at engineer #80. By #150, security findings backed up. By #200, the team was the bottleneck on every release. The fix wasn’t more security people — it was an application-security programme that scaled with engineering rather than against it. Within 18 months: same 4-person AppSec team, 5x the engineering throughput, fewer findings reaching production. This module covers AppSec as a programme: shifting left, scaling sideways, and measuring outcomes.

What an AppSec programme covers

• Threat modelling — design-phase security evaluation
• Secure coding standards — language-specific rules and review patterns
• SAST (Static Application Security Testing) — code-level vulnerability scanning
• SCA (Software Composition Analysis) — dependency vulnerability and licence
• DAST (Dynamic Application Security Testing) — running-app vulnerability scanning
• IaC scanning — Terraform / Kubernetes / Helm config security
• Container scanning — image vulnerabilities and config
• Secrets scanning — credentials in code, history, builds
• Penetration testing — manual external assessment
• Bug bounty / VDP — crowdsourced vulnerability discovery
• Security training — language-specific, role-relevant
• Incident response for application-level security events
• Metrics and reporting — what’s getting better, what isn’t

The maturity ladder

Shift-left: where the leverage is

Vulnerability fix cost rises by orders of magnitude through the SDLC:

• Caught in design (threat model): minutes to fix
• Caught in dev IDE (Semgrep IDE plugin): minutes
• Caught in PR (CI SAST): hours
• Caught in QA: days
• Caught in pen-test pre-release: weeks (and slips release)
• Caught in production via bug bounty: weeks + reputation cost
• Caught in production via incident: months + breach cost

Investment per vulnerability avoided in design vs incident: ~10,000:1. The shift-left ratio justifies AppSec investment by itself.

Security champions

The model that scaled the Bengaluru team:

• One engineer per squad designated as security champion (10-15% of their time)
• Champions get extra training, attend an internal security guild monthly, and have direct line to AppSec team
• Champions do first-pass review on PRs in their squad; AppSec team consulted only for hard cases
• Champion role rotates yearly to spread expertise
• Career incentive: “security champion” on resume, paid training, conference attendance

With 22 squads × 1 champion each, the AppSec team’s effective coverage went from 4 reviewers to 26 — without hiring.

The CI/CD security pipeline

Every commit / merge / build passes through:

# GitHub Actions — example security gate
name: security
on: [pull_request]
jobs:
  scan:
    steps:
      - uses: actions/checkout@v4
      - name: Secrets scan
        uses: gitleaks/gitleaks-action@v2

      - name: SAST
        uses: returntocorp/semgrep-action@v1
        with:
          config: 'p/owasp-top-ten p/r2c-security-audit'

      - name: SCA
        uses: snyk/actions/node@master

      - name: Container scan
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'app:${{ github.sha }}'

      - name: IaC scan
        uses: bridgecrewio/checkov-action@master

Critical / high findings block merge. Medium findings create tickets. Low findings inform but don’t block.

Tooling baseline

The Bengaluru rollout (year-by-year)

Year 1 (foundations):

• SAST + SCA + secrets scanning in CI; baseline-then-tighten approach (don’t break-build immediately)
• Threat-modelling sessions for top 10 highest-risk services
• Top 50 risks across the codebase identified and remediated
• Security training onboarding modules for new hires

Year 2 (scaling):

• Security champions launched; 22 champions trained
• Bug bounty programme launched on HackerOne; 4 critical findings in first quarter
• IaC and container scanning added; Wiz deployed for cloud posture
• SAST custom rules built from past findings — same pattern can’t reappear
• Quarterly metrics published: MTTR for findings, % critical in production, dependency freshness

Outcomes:

• Critical findings reaching production: 12/quarter → 1/quarter
• Mean time to remediate critical: 27 days → 4 days
• Engineer satisfaction with security team: 6.2/10 → 8.7/10 (no longer the blocker)
• Bug bounty payouts: ₹6 lakh year-2 (cheaper than the breaches avoided)

Metrics that drive behaviour

• MTTD / MTTR for security findings, by severity
• Vulnerability density — open findings per 1000 lines of code or per service
• Remediation SLA adherence — % findings closed within target
• Dependency freshness — % dependencies older than 12 months
• Threat-model coverage — % services with TM in last 24 months
• Training completion — % engineers with up-to-date secure coding cert
• Bug bounty TTH (time to hire / triage) — fast triage = serious programme
• Critical issues found internally vs externally — internal-find ratio rising = shift-left working

Indian compliance mapping

• RBI Cyber Framework — SDLC with security, periodic VAPT, secure coding
• SEBI CSCRF — application security explicit for Q-RE / MII
• DPDP §10 — secure-by-design programme for SDFs
• ISO 27001:2022 A.8.25-A.8.34 — secure development
• OWASP SAMM, OWASP ASVS — frameworks Indian regulators reference

Common pitfalls

• AppSec as gatekeeper, not enabler — engineers route around it
• Tool deluge — 12 scanners producing 12 ticket queues, none actioned
• No champion programme — AppSec stays small and overwhelmed
• Training that’s CBT-checkboxes, not language-specific and role-relevant
• No metrics — improvements are unprovable; budget pressure follows
• Bug bounty without internal triage capacity — public programme that ignores reports = reputation harm

Try this in your environment

1. Map your current AppSec programme onto the maturity ladder. Where are you? Where should you be?
2. Count open critical/high findings older than 30 days. That’s your remediation backlog.
3. Identify three engineers who could be security champions. Approach them; pilot for one quarter.
4. Pick one tool from each layer (SAST, SCA, secrets, IaC). Add to CI in audit mode. Tune for two weeks. Then enforce.
5. Set quarterly metric review with engineering leadership. The programme is real when leadership tracks it.

An AppSec programme is the leverage by which a small security team raises the security bar for an engineering organisation that scales beyond per-PR review. The Bengaluru SaaS company didn’t outpace its security team by hiring more security people — it hired engineering champions and changed the operating model. Build the model.