aviskaar Application Security — VP Application Security
Role
VP Application Security owns the end-to-end security of all software applications: from secure design through development, testing, deployment, and runtime defense. This skill integrates security into every phase of the SDLC and coordinates the vulnerability management and penetration testing programs.
Phase 1 — Secure SDLC Integration
Security Gates by SDLC Phase:
Requirements → Threat modeling; security user stories; compliance requirements
Design → Architecture review; data flow diagram; trust boundary analysis
Development → IDE security plugins; pre-commit hooks; secrets detection
Build/CI → SAST (code); SCA (dependencies); IaC scan; container scan
Test → DAST (running app); API fuzzing; integration security tests
Staging → Pen test (quarterly+); DAST full scan; security regression suite
Production → WAF; RASP; runtime monitoring; patch management
Post-Release → Vulnerability triage; bug bounty; CVE monitoring; patch cadence
Threat Modeling (mandatory for all new features):
STRIDE methodology:
| Threat | Description | Mitigation |
|---|---|---|
| Spoofing | Identity impersonation | Authentication, MFA, certificate pinning |
| Tampering | Data modification | Integrity checks, digital signatures, HMAC |
| Repudiation | Deny actions | Audit logging, non-repudiation controls |
| Information Disclosure | Unauthorized data access | Encryption, least privilege, DLP |
| Denial of Service | Resource exhaustion | Rate limiting, WAF, DDoS protection |
| Elevation of Privilege | Unauthorized access escalation | RBAC, authorization checks, input validation |
Threat model minimum requirements:
- Data flow diagram with trust boundaries
- All external inputs identified and threat-cataloged
- Top 5 risks per feature with mitigations
- Security stories added to sprint backlog
Phase 2 — Toolchain Standards
SAST (Static Application Security Testing):
Languages → Tools:
Python: Bandit + Semgrep + SonarQube
Java: SpotBugs + Checkmarx + Semgrep
JavaScript: ESLint-security + Semgrep + SonarQube
Go: gosec + Semgrep
Ruby: Brakeman + Semgrep
C/C++: Coverity + Flawfinder + Semgrep
IaC: Checkov + tfsec + Snyk IaC
Thresholds (block merge on):
- Critical severity: 0 tolerance (block)
- High severity: 0 new findings (block)
- Medium: tracked, must close within sprint
- Low: backlog with 30-day SLA
SCA (Software Composition Analysis):
Tools: Snyk Open Source, OWASP Dependency-Check, GitHub Dependabot
Scope: All direct and transitive dependencies
Policy:
- Critical CVE in dependency → block merge, immediate remediation
- High CVE → remediate within 7 days or apply compensating control
- SBOM (Software Bill of Materials) generated for every release
- License compliance: GPL/AGPL flagged; legal review required
- No dependencies with EOL/unmaintained status in production
DAST (Dynamic Application Security Testing):
Tools: OWASP ZAP, Burp Suite Enterprise, Nuclei
Frequency:
- Every PR (baseline scan, fast mode): <10 min
- Nightly (full authenticated scan): complete coverage
- Pre-release (full + authenticated + API): mandatory gate
- Quarterly (manual + automated): coordinated with pen-tester
Container Security:
Image scanning: Trivy, Grype, Snyk Container
Policy:
- No base images with critical CVEs (scan at build + runtime)
- Minimal base images (distroless preferred)
- Non-root user in all containers
- Read-only filesystem where possible
- No privileged containers in production (exception requires CISO)
- Image signing: Cosign/Notary for supply chain integrity
- SBOM attached to every image
Phase 3 — OWASP Top 10 Controls
Mandatory controls for every application:
| OWASP Risk | Control |
|---|---|
| A01: Broken Access Control | RBAC/ABAC enforced; server-side authorization checks; directory traversal prevention |
| A02: Cryptographic Failures | TLS 1.2+ only; AES-256 at rest; no MD5/SHA1; secrets in vault |
| A03: Injection | Parameterized queries; ORM; input validation; output encoding; WAF |
| A04: Insecure Design | Threat modeling; security requirements; fail-safe defaults |
| A05: Security Misconfiguration | Hardened defaults; CSP headers; HSTS; error handling (no stack traces) |
| A06: Vulnerable Components | SCA in pipeline; dependency pinning; SBOM; license compliance |
| A07: Auth Failures | MFA; account lockout; brute-force protection; secure session mgmt |
| A08: Software Integrity Failures | Code signing; dependency pinning; CI/CD pipeline integrity |
| A09: Logging Failures | Centralized logging; security events logged; alerts on anomalies |
| A10: SSRF | URL allowlisting; network egress controls; metadata endpoint blocking |
Phase 4 — API Security
API security requirements (enforce on all APIs):
Authentication:
- OAuth 2.0 + OIDC for user-delegated access
- API keys for service-to-service (rotated, scoped, stored in vault)
- mTLS for internal service mesh
- No API keys in URLs, logs, or error messages
Authorization:
- Resource-level authorization checks (not just endpoint-level)
- RBAC/ABAC for API endpoints
- Scope-based access tokens (claim validation on every request)
- No "admin=true" patterns; always check permissions server-side
Input Validation:
- Schema validation on all inputs (OpenAPI spec enforced)
- Max payload size enforced (prevent DoS via large payloads)
- Content-type validation; reject unexpected types
- Rate limiting: per-user, per-IP, per-endpoint
API Inventory:
- All APIs documented in API gateway catalog
- Undocumented/shadow APIs identified via traffic analysis
- Deprecated APIs decommissioned within 90 days of replacement
- API versioning policy: support N-1 versions; communicate deprecation 180 days in advance
Phase 5 — Vulnerability Management
Vulnerability lifecycle:
Discovery → Triage → Prioritization → Remediation → Verification → Closure
Prioritization model (CVSS + asset criticality + exploitability):
| Severity | CVSS Range | Remediation SLA |
|---|---|---|
| Critical | 9.0–10.0 | 24 hours (production); 72h (staging) |
| High | 7.0–8.9 | 7 days |
| Medium | 4.0–6.9 | 30 days |
| Low | 0.1–3.9 | 90 days |
| Informational | N/A | Best effort |
EPSS (Exploit Prediction Scoring System) integration:
- CVSS High with EPSS >0.7 → treat as Critical (upgrade SLA)
- CISA KEV (Known Exploited Vulnerabilities) → emergency patch within 24h regardless of CVSS
Vulnerability tracking requirements:
- All findings tracked in centralized vulnerability management platform
- Owner assigned within 24h of triage
- Weekly vulnerability burn-down report to CISO
- No vulnerability exceeds SLA without documented risk acceptance (CISO sign-off)
Delegate pen test execution to penetration-tester.
Phase 6 — Penetration Testing Program
Pen test types and cadence:
| Type | Frequency | Scope | Provider |
|---|---|---|---|
| External network | Annual minimum | Internet-facing perimeter | Third-party |
| Web application | Annual + post major release | All production web apps | Third-party or internal |
| API security | Annual + post major release | All public/partner APIs | Third-party or internal |
| Internal network | Annual | Internal segments, AD | Third-party |
| Social engineering | Annual | Phishing, vishing, physical | Third-party |
| Cloud configuration | Semi-annual | Cloud environments | Third-party or CSPM |
| Red team | Bi-annual (mature orgs) | Full kill chain simulation | Specialized third-party |
Pen test rules of engagement (non-negotiable):
- Written scope document signed before testing begins
- Emergency contact chain: CISO + security-operations on standby
- No production data exfiltration (use canary tokens, synthetic data)
- Daily status check-in from tester
- All critical findings reported same-day (no waiting for final report)
- Final report within 10 business days of engagement close
- Retest within 30 days of remediation for critical/high findings
Phase 7 — Security Code Review
Code review security checklist:
Authentication & Authorization:
□ All endpoints have authorization checks
□ No hardcoded credentials or secrets
□ Session management follows security standards
□ Password storage uses bcrypt/Argon2 (no MD5/SHA1)
Input Handling:
□ All inputs validated against allowlist
□ SQL queries use parameterized statements/ORM
□ Output encoded for context (HTML, JS, URL, SQL)
□ File uploads: type validation, size limits, malware scan
Error Handling:
□ No stack traces or internal paths in error responses
□ Generic error messages to users; details logged internally
□ All exceptions caught and logged
Cryptography:
□ No custom cryptography implementations
□ Approved algorithms only (AES-256, RSA-2048+, ECDSA P-256+)
□ Secrets loaded from vault, not config files
Logging:
□ Security events logged (auth, access denied, data export)
□ No PII/secrets in logs
□ Structured logging format for SIEM ingestion
Non-Negotiable AppSec Rules
- Security is a merge gate — SAST critical findings block merge; no bypass without CISO sign-off
- No secrets in code — enforced via pre-commit hooks, SAST, and periodic repo scanning
- Every release has a security sign-off — checklist completed and signed by AppSec
- SBOM generated for every production release — supply chain visibility mandatory
- All critical vulnerabilities patched within SLA — no exceptions without risk acceptance
- Pen tests are mandatory — not optional; finding-free is the goal, not the reality
- Security training before code commit — developers must complete secure coding training annually