Application Security (AppSec)

Application Security (AppSec) is the discipline of integrating security into every phase of the software development lifecycle: from requirements analysis through design and development to testing, deployment, and operation. Modern AppSec follows the principle of "Security by Design"—security is not an afterthought, but a fundamental requirement.

AppSec in the SDLC – Security Throughout the Entire Lifecycle

Phase 1: Requirements / Design

• Threat Modeling: What attacks are possible against this feature?
• Security Requirements: What MUST the app do?
• Architecture Review: Authentication, Authorization, Data Flows

Phase 2: Development

• Secure Coding Guidelines (OWASP Cheat Sheets)
• IDE Plugins: Semgrep, SonarLint, CodeQL directly in the editor
• Pre-commit Hooks: SAST scan before every commit
• Peer Code Review: dual-review process for security-critical components

Phase 3: Testing

• SAST (Static Application Security Testing): Code analysis
• SCA (Software Composition Analysis): Check dependencies for CVEs
• DAST (Dynamic Analysis): Attack the running application
• IAST (Interactive Analysis): Agent in runtime testing

Phase 4: Deployment

• Scan container images (Trivy, Grype)
• IaC scanning (Checkov, tfsec): Misconfigurations in Terraform/K8s
• Secrets scan: No API keys in the image or configuration

Phase 5: Operation / Monitoring

• WAF (Web Application Firewall): Block attacks
• RASP (Runtime Application Self-Protection): In-app protection
• SIEM integration: Analyze application logs
• Vulnerability management: Track CVEs in dependencies

OWASP Top 10 - The most critical vulnerabilities

A01: Broken Access Control

• Most common category (94% of apps affected)
• User can access other users’ data (IDOR)
• Horizontal + vertical privilege escalation
• Missing authorization checks in APIs

A02: Cryptographic Failures

• Unencrypted transmission of sensitive data
• Weak algorithms: MD5/SHA-1 for passwords
• Hard-coded keys, predictable keys

A03: Injection

• SQL injection, OS command injection, LDAP injection
• Unsanitized user input is executed

A04: Insecure Design

• Lack of threat modeling in the design phase
• No rate limiting, no account locks

A05: Security Misconfiguration

• Default credentials, unnecessary features enabled
• Verbose error messages reveal internal paths
• Missing security headers

A06: Vulnerable and Outdated Components

• Libraries/frameworks with known CVEs
• Unpatched server software

A07: Identification and Authentication Failures

• Weak password policies, no MFA
• Predictable session IDs, missing session invalidation

A08: Software and Data Integrity Failures

• CI/CD pipelines without verification (supply chain)
• Insecure deserialization

A09: Security Logging and Monitoring Failures

• Attacks are not detected
• No alerts for brute force or IDOR attempts

A10: Server-Side Request Forgery (SSRF)

• App makes requests to internal services
• Attacker reads metadata (AWS/Azure instance metadata)

Static Analysis (SAST) - Checking code without execution

# Semgrep installation
pip install semgrep

# Scan with OWASP rules
semgrep --config=p/owasp-top-ten ./src/

# Custom rule (detect Python SQL injection)
rules:
  - id: sql-injection-python
    patterns:
      - pattern: |
          $DB.execute("..." + ...)
    message: "SQL Injection: String concatenation in DB query"
    languages: [python]
    severity: ERROR

# Semgrep in CI (GitHub Actions)
- uses: returntocorp/semgrep-action@v1
  with:
    config: >-
      p/owasp-top-ten
      p/django
      p/java

SonarQube Community (for Enterprise):

• Supports 15+ languages
• Separates security hotspots and vulnerabilities
• Quality Gates: "Pipeline fails if critical vulnerability is found"
• OWASP Top 10, SANS Top 25, CWE mapping

CodeQL (GitHub, free for open source):

• Semantic analysis: understands data flow
• Finds vulnerabilities across multiple files
• 2000+ pre-built queries

Dynamic Analysis (DAST) - Test running app

# OWASP ZAP Baseline Scan (for CI/CD)
docker run -t owasp/zap2docker-stable zap-baseline.py \
  -t https://staging.example.com \
  -r zap-report.html

# ZAP Full Scan (with authentication)
docker run -t owasp/zap2docker-stable zap-full-scan.py \
  -t https://staging.example.com \
  -r full-report.html \
  -z "-config replacer.full_list(0).matchtype=REQ_HEADER \
      -config replacer.full_list(0).matchstring=Authorization \
      -config replacer.full_list(0).replacement=Bearer\ TOKEN"

# Nuclei (fast template-based scans)
nuclei -u https://example.com -t nuclei-templates/http/
nuclei -u https://example.com -t cves/ -severity critical,high

ZAP results:

• PASS (0): no issues
• WARN (1): Medium/Low Risk - review
• FAIL (2): High Risk - fail the pipeline

Software Composition Analysis (SCA)

# npm audit (Node.js)
npm audit
npm audit --audit-level=high  # show only High/Critical

# pip-audit (Python)
pip-audit
pip-audit --requirement requirements.txt

# OWASP Dependency-Check (Java/Multi-Language)
./dependency-check.sh --project "MyApp" \
  --scan ./target/ \
  --format HTML \
  --out ./reports/

# Snyk (commercial, good for CI)
snyk test --severity-threshold=high
snyk monitor  # Continuous monitoring

# Generate SBOM (Software Bill of Materials)
syft myapp:latest -o spdx-json > sbom.json
grype sbom:./sbom.json  # CVE scan against SBOM

Why SBOM is important:

• NIS2 + U.S. Executive Order require SBOM
• Immediately shows with Log4Shell: "Are we using log4j?"
• Basis for vulnerability management

AppSec metrics and KPIs

Vulnerability metrics

Mean Time to Remediate (MTTR) by severity:

Severity	Target
Critical	< 24h
High	< 7 days
Medium	< 30 days
Low	< 90 days

• Vulnerability Debt: open findings over time
• False Positive Rate: Measuring SAST Quality

Process Metrics

• SAST Coverage: % of repositories with SAST
• SCA Coverage: % of repositories with dependency checks
• Security Testing in CI: % of pipelines with security gates
• Secure Code Training: % of developers trained

Maturity Models

OWASP SAMM (Software Assurance Maturity Model):

• 5 functions: Governance, Design, Implement, Verify, Operations
• 3 maturity levels per function
• Free: owaspsamm.org

BSIMM (Building Security In Maturity Model):

• Benchmark against other companies