After Lab 3.3 — Recap

You scanned the application code and dependencies for security vulnerabilities using Semgrep and Trivy, and learned how to classify and handle findings.

What You Should Understand

SAST vs. Dependency Scanning

Tool	What It Scans	Example Finding	Fix
Semgrep	Source code patterns	Hardcoded API key in config.ts	Move to environment variable or Key Vault
Trivy	Dependencies, secrets, config	express 4.17.1 has CVE-2022-24999	Upgrade to express 4.19.2 or later

Why both?: Semgrep finds how you write code, Trivy finds what libraries you depend on. Complementary approaches.

Findings Workflow

Never ignore findings without justification. "Suppressing because it's annoying" is not a valid reason.

---

Reflection Questions

Why does the pipeline set `continueOnError: "true"` for Semgrep and Trivy instead of failing the build?

Educational mode: In a learning environment, you want students to:

1. See all findings (not just the first failure)
2. Classify severity and urgency
3. Decide fix vs. suppress vs. accept

In production pipelines, you would configure exit-code: 1 for critical/high findings to enforce policy. Start permissive, tighten gradually.

What's the difference between a Semgrep finding and a Trivy secret scan finding?

Semgrep custom rules check for patterns you define (e.g., "flag any string assigned to variable named API_KEY").

Trivy secret scanning uses entropy analysis and known secret patterns (e.g., detects AWS access keys, GitHub tokens by format).

Overlap: Both might flag const token = "sk-1234...". Semgrep because of the variable name, Trivy because of the sk- prefix.

If Trivy finds a critical CVE in a dependency, should you always upgrade immediately?

Depends on exploitability:

• Check the CVE details: What component is affected? Is it reachable in your code?
• Assess impact: Does the vulnerable function actually get called in your app?
• Test the upgrade: Does the new version break your application?

Example: A critical CVE in lodash template rendering function — but you only use lodash.merge. The vulnerability is present but not exploitable in your app. Document the assessment, plan upgrade, but don't panic-upgrade in production.

---

Common Issues

Issue	Symptom	Cause	Fix
Semgrep finds 100+ findings	Overwhelming output	Default ruleset too broad	Use custom .semgrep.yml with focused rules (secrets, injection, validation)
Trivy scans take 10+ minutes	Slow dependency analysis	Large node_modules, no cache	Enable pipeline caching for node_modules, use --scanners vuln only (skip config/secret if not needed)
Trivy reports false positive CVE	CVE assigned but not exploitable	Vulnerability in unused dependency export	Suppress with .trivyignore and document: CVE-2023-1234 # Not used: only impacts lodash.template, we use lodash.merge
Semgrep rule triggers on test files	eval(userInput) in mock data	Rule scans all .ts files	Add paths: exclude: ["**/*.test.ts"] to .semgrep.yml

---

Pipeline Failure Policy: Which Findings Block Deployment?

Students should not only run tools — they should decide which findings block the pipeline.

Decision Framework

Finding Type	Block Pipeline?	Justification
TypeScript error	Yes	Build is unreliable; application may crash at runtime
Failing unit test	Yes	Known broken behavior; tests exist for a reason
Semgrep high/critical	Usually yes	Code security issue (SQL injection, hardcoded secrets)
Trivy critical CVE	Usually yes	Known vulnerable dependency with available fix
Checkov high IaC issue	Usually yes	Unsafe infrastructure (public storage, weak encryption)
Semgrep medium	No (warn)	Needs review but may be false positive
Trivy high CVE (not exploitable)	No (accept risk)	Vulnerability present but not reachable in our code
ZAP informational finding	No	Needs manual review (may be expected behavior)
ZAP high finding	Discuss	Depends on confidence and context

Enforcement Levels

Pipelines evolve through three enforcement phases:

Phase 1: Educational (Lab 3.3)

- script: semgrep scan --sarif -o semgrep-results.sarif
  continueOnError: "true"  # See all findings, don't block
  displayName: 'SAST: Semgrep'

Purpose: Students see findings, learn to triage, understand tool output.

Phase 2: Enforcement with Overrides

- script: |
    semgrep scan --sarif -o semgrep-results.sarif --error
    # Fails on high/critical by default
    # Override requires approval from security team
  displayName: 'SAST: Semgrep (enforced)'

Purpose: Block deployments on critical issues, allow documented exceptions.

Phase 3: Zero-Tolerance

- script: |
    semgrep scan --sarif -o semgrep-results.sarif --error
    # No overrides, no exceptions, no continueOnError
  displayName: 'SAST: Semgrep (zero-tolerance)'

Purpose: Production-grade security posture, all findings must be fixed or proven irrelevant.

Who Can Override?

Override Scenario	Approver	Documentation Required
False positive	Developer + peer review	Code comment explaining why
Accepted risk (medium severity)	Team lead	Risk assessment, mitigation plan
Accepted risk (high severity)	Security team	Formal exception request with expiry date
Critical finding override	Never	Fix immediately, no exceptions

Policy Configuration

Teams should document their gate policy in a SECURITY_POLICY.md file:

## Pipeline Security Gate Policy

### Blocking Findings
- Any CRITICAL severity finding from Semgrep or Trivy
- Any HIGH severity finding in production dependencies
- Hardcoded secrets (Trivy secret scan)
- Public storage accounts (Checkov)

### Warning Findings (manual review required)
- MEDIUM severity Semgrep findings
- HIGH severity CVEs in dev dependencies
- ZAP findings (baseline scan)

### Suppression Process
1. Developer identifies false positive or accepted risk
2. Add to `.semgrep-ignore` or `.trivyignore` with justification comment
3. Pull request review required for all suppressions
4. Security team reviews suppressions monthly

Key principle: Start permissive (educational mode), tighten gradually (enforcement), and document every exception.

---

Bridge to Lab 3.4

You secured the application code and dependencies. Now we scan the infrastructure code (Terraform) for misconfigurations before provisioning resources.