Security Team Integration
Three Functions, Three Missions
AppSec focuses on the security of the software you build. They own threat modeling, secure code review, SAST/DAST tooling, and vulnerability management for your applications. In practice, AppSec engineers spend their time reviewing architecture proposals, building security guardrails into the SDLC, and triaging findings from scanning tools. A good benchmark is 1 AppSec engineer per 50-75 developers.
SecOps protects the runtime environment. They manage SIEM platforms (Splunk, Datadog Security), handle incident response for security events, run detection and response workflows, and manage endpoint security. SecOps tends to look more like traditional IT security and operates closer to the infrastructure team.
GRC handles compliance frameworks (SOC 2, ISO 27001, HIPAA, PCI-DSS), risk assessments, vendor security reviews, and policy documentation. At smaller companies, GRC work often falls on an engineering manager or operations lead. By the time you hit 200 employees or start selling to enterprises, you need dedicated GRC capacity.
The Security Champions Model
Hiring enough security engineers to review every code change is impractical and unnecessary. Instead, recruit volunteer engineers from each product team to become security champions. Give them 4-8 hours of training, access to security tooling, and a monthly guild meeting where the AppSec team shares threat intelligence and reviews patterns.
Champions handle first-pass security reviews for their team's work. They know when something needs escalation to AppSec and when it doesn't. Shopify, GitHub, and Microsoft all run security champions programs at scale.
SDLC Integration Points
Security checks should be woven into the development lifecycle at specific points, not bolted on at the end.
Design phase: Threat modeling for new features. Use STRIDE or a lightweight alternative. AppSec joins architecture reviews for high-risk components.
Development: Pre-commit hooks for secret scanning. IDE plugins that flag common vulnerabilities in real time.
CI pipeline: Automated SAST (Semgrep, CodeQL), dependency scanning (Snyk, Dependabot), container image scanning (Trivy). Block merges for critical findings.
Deployment: Infrastructure-as-code scanning (Checkov, tfsec). Runtime security policies (OPA/Gatekeeper for Kubernetes).
Production: Bug bounty programs, continuous external scanning, WAF tuning.
Building Reviews That Don't Block Shipping
The key is tiered review. Define risk levels based on what the change touches. Auth, payments, PII handling, and cryptography are high-risk. UI copy changes and internal tooling are low-risk. Automate everything you can for low-risk changes. Reserve human security review for the changes where it actually matters. Track your review SLA and keep it under 2 business days for high-risk reviews.
Key Points
- •Application Security (AppSec), Security Operations (SecOps), and Governance/Risk/Compliance (GRC) are three distinct functions that require different skill sets, tools, and team structures. Treating security as one monolithic team breaks down past 5-6 people
- •The security champions model scales security knowledge without scaling the security team. Volunteer engineers from each product team get training, attend security guild meetings, and serve as the first line of review for their team's code
- •Shifting left means integrating security checks into CI/CD pipelines (SAST with Semgrep, SCA with Snyk, secret scanning with GitLeaks) so issues get caught before code review, not after deployment
- •Security review processes should be tiered. Low-risk changes get automated scanning only. Medium-risk changes get a security champion review. High-risk changes (auth flows, payment logic, new third-party integrations) get a full AppSec team review
- •The CISO reporting structure signals organizational priority. Reporting to the CTO keeps security close to engineering. Reporting to the CEO or board gives security independence but can create distance from the teams doing the work
Common Mistakes
- ✗Making the security team a gate that every PR must pass through. This creates a bottleneck that slows shipping to a crawl and breeds resentment between security and engineering
- ✗Hiring security specialists before establishing baseline security hygiene. SSO, dependency scanning, and secret rotation should be in place before you hire your first dedicated security engineer
- ✗Running annual penetration tests as your only security assessment. Point-in-time assessments miss the vulnerabilities introduced between tests. Continuous scanning catches what annual pentests cannot