Sec Static Code Analysis

• stack context
• guidelines
• existing scanner config
• pull request scope

Outputs

• static analysis report
• triaged findings
• scanner recommendations
• follow-up remediation stories

Workflow phase and review mode

• Workflow phase: implementation, pull-request review, release readiness
• Review mode: human review for high or critical findings, suppressions, or changes to scanner policy

Operating pattern

This skill implements the standard shared-operating-policy.md#scanner-findings-pipeline:

1. Inventory — Detect project languages, frameworks, and changed paths
2. Select scanners — Use OWASP criteria (accuracy, FP rate, language support, framework understanding) to choose 2-3 complementary tools
3. Run — Execute local or CI scans; capture findings in structured format (SARIF preferred)
4. Triage — Categorize into confirmed issues, hotspots needing review, false positives, or accepted suppressions
5. Convert — Create US-*, HUS-*, or stories for remediation; link test cases from qa-verification-planner
6. Verify — Re-run after fixes; update story evidence and approval gates

Guideline lookup

• Follow docs/guidelines/shared-operating-policy.md#guideline-lookup.

Story and artifact maintenance

• Follow docs/guidelines/shared-operating-policy.md#story-maintenance for backlog, evidence, and follow-up updates tied to this skill.

Quality bars

• Static analysis output must distinguish confirmed findings from hotspots or low-confidence findings. Use report.template.md categories: confirmed issues, hotspots, false positives, accepted suppressions.
• Suppressions require a formal record with rationale, owner, scope, and review date. Use suppression.template.md; critical findings require a HUS-* approval story in execution-plan/backlog/ before the suppression is committed.
• The report must point to remediation paths and linked stories; raw scanner output alone is insufficient.
• False positive rate must be <30%; if higher, tune rules or switch tools.
• Test coverage must exist for confirmed security issues (coordinator with qa-verification-planner).
• CI/CD gates must enforce scanning on every PR and release; SARIF findings must be integrated into code scanning dashboard (coordinate with pipeline-connector).

Failure modes to avoid

• Treating any raw scanner output as a confirmed vulnerability without triage or exploitability assessment.
• Running broad rule sets with no triage plan; high false positive rates (>50%) cause suppression fatigue and missed signals.
• Failing to separate code-quality lint (style, complexity) from security-focused SAST (injection, crypto, auth flaws).
• Leaving findings only in tool output without story tracking, evidence, or release notes.
• Ignoring SAST blind spots (architecture, auth logic, business logic, crypto misuse). Route to complementary skills (sec-risk-security-review, qa-verification-planner) as needed.
• Suppressing findings without owner, rationale, or review date; create a HUS-* approval story in execution-plan/backlog/ for all critical suppressions before committing them.
• Assuming SAST alone proves security; always combine with threat modeling, code review, testing, and risk assessment.

Completion checklist

• Use docs/guidelines/shared-operating-policy.md#completion-checklist as the default completion gate for this skill.

Detailed workflow

1. Inventory — Detect languages, frameworks, changed paths, and build model:

   • python files? → Bandit, Semgrep
   • javascript/typescript? → ESLint + security rules, Semgrep
   • Multi-language? → CodeQL (if GitHub available) for unified high-accuracy baseline
   • Changed files only (PR)? → Focus on impacted modules
   • Full repo scan? → Set up as scheduled job in CI/CD

2. Select scanners using OWASP criteria (see tool-selection-guide.md):

   • GitHub CodeQL (if GitHub integration enabled during config) — Multi-language, high accuracy (75-80%), SARIF-native, database-driven data-flow. Best starting point.
   • Open source alternative stack (if GitHub not enabled):
     • Python: Bandit (AST-based) + Semgrep (patterns) + Ruff check (quick baseline)
     • JavaScript/TypeScript: ESLint + eslint-plugin-security + Semgrep
     • Go: gosec + Semgrep
     • Java: SpotBugs + FindSecBugs + Semgrep
   • Combine 2-3 tools for complementary coverage; use SARIF normalization for unified reporting

3. Run scans:

   • Local: python run_static_analysis.py --path . --execute
   • CI/CD: Configure GitHub Actions or equivalent to run on every PR and main branch
   • Schedule: Weekly full-repo scan for baseline tracking
   • Output: SARIF format for code scanning integration

4. Triage findings using report.template.md categories:

   • 🔴 Confirmed issues — Fix immediately; write test cases (qa-verification-planner)
   • 🟡 Hotspots — Exploit-ability unclear; route to sec-risk-security-review for assessment, or add test cases
   • 🟢 False positives — Record in suppression.template.md with owner and review date
   • ⚪ Library/framework false alarms — Update tool config; note pattern for tuning

5. Convert to stories:

   • High/critical confirmed issues → US-* (user-facing) or HUS-* (human-executable)
   • Hotspots needing architecture review → Route to sec-risk-security-review; create FEAT-* for design changes
   • Business-logic security gaps (discovered during triage) → Route to qa-verification-planner for scenario tests
   • Configuration/deployment issues → Route to pipeline-connector

6. Verify & evidence:

   • Re-run scans after fixes; confirm affected rules now pass
   • Link test cases from qa-verification-planner demonstrating fix prevents exploitation
   • Update story evidence with scan results, suppression records, and re-test pass
   • Update release gate: no unreviewed critical findings; all high findings have remediation or documented acceptance

Best-practice notes

OWASP-Aligned Tool Selection

When evaluating SAST tools, OWASP recommends criteria beyond "does it find anything":

• Accuracy: False positive (FP) and false negative (FN) rates. Tools with >50% FP are noisy; prefer tools with <30% FP and proven OWASP Benchmark scores (70-80% is typical for mature tools).
• Language completeness: Tool must support all primary languages in your project.
• Framework understanding: Tools that understand Django, Spring, Rails, React catch framework-specific vulnerabilities better than generic linters.
• Buildability: Some tools require compiled code; others (AST/pattern-based) work on incomplete code. Incomplete code support is valuable for fast feedback loops.
• SARIF interoperability: Standard output format for integrating findings with code scanning platforms, dashboards, and external tools.

See tool-selection-guide.md for detailed criteria, tool comparisons, and decision tree.

GitHub CodeQL (When Available)

If GitHub integration was selected during configuration:

• Recommendation: Start with CodeQL default setup (one-click activation in GitHub). It's the highest-accuracy multi-language option (75-80% OWASP Benchmark) and needs zero workflow coding.
• Best for: Multi-language repos, complex data-flow vulnerabilities, long-term baseline building
• Workflow: Settings → Security › Code scanning › CodeQL Analysis → Enable default setup
• Next step: After enabling, tune with custom queries if your organization has non-standard patterns

Open Source Alternatives (When GitHub Not Available)

Python backend:

• bandit -r . -f json → AST-based Python security checks
• semgrep scan --config=auto . → Cross-language patterns + custom org rules
• ruff check . → Quick code quality baseline (not security-focused)

JavaScript/TypeScript:

• npx eslint . --format json + eslint-plugin-security → Industry-standard static analysis
• semgrep scan --config=auto . → Framework-aware checks (React, Vue, Angular patterns)

Other languages:

• Go: gosec ./...
• Java: SpotBugs + FindSecBugs (requires compiled .class files)
• C/C++: Flawfinder (lightweight), or commercial tools if safety-critical

Multi-Tool Strategy

Combine complementary tools for better coverage:

Layer 1: Fast baseline (no build needed)
  └─ Ruff (Python), ESLint (JS), Semgrep (any language)

Layer 2: Language/framework-specific security
  └─ Bandit (Python), ESLint+security (JS), gosec (Go)

Layer 3: High-accuracy integrated analysis (if available)
  └─ CodeQL (GitHub) or equivalent

Output: Normalize to SARIF or structured JSON for unified triage

False Positive Management

• Tune rules: Disable noisy rules; enable framework-aware rules (E.g., Django template escaping is safe by default; tell tool to trust it)
• Suppression discipline: Record why each false positive exists; set review date (see suppression.template.md)
• Tool rotation: If FP rate >50%, consider switching tools or moving it to advisory-only mode
• Quarterly baseline reset: Re-baseline quarterly to remove stale suppressions and catch new patterns

Understanding SAST Blind Spots

SAST is powerful but not comprehensive. See sast-blind-spots.md for what SAST cannot catch:

• Auth & access control logic — Requires business context understanding
• Cryptography misuse — SAST sees weak algorithms but not incorrect usage
• Configuration issues — SAST only scans hardcoded values, not deployment configs
• Business logic flaws — "Negative quantity order", "race condition in payment", etc.
• Data protection — Privacy design, PII retention, DLP policies

Complement SAST with:

• Risk assessment (sec-risk-security-review) for architecture and business logic
• Testing (qa-verification-planner) for scenario coverage and auth/logic validation
• Threat modeling (sec-risk-security-review) for trust boundaries and data flows
• Dependency scanning (sec-security-vulnerability-analysis) for supply chain
• Code review for intent, context, and edge cases

Examples

Example 1: Python backend (no GitHub CodeQL)

Scope: PR #42 — changed src/api/user_service.py, src/auth/token_handler.py

Commands:

# Layer 1: Quick baseline
ruff check src/api/user_service.py src/auth/token_handler.py

# Layer 2: Security-focused
bandit -r src/api/user_service.py src/auth/token_handler.py -f json > findings-bandit.json
semgrep scan --config=auto src/api/ src/auth/ -o findings-semgrep.sarif

Findings (example):

• 🔴 High: os.system(user_input) at src/api/user_service.py:54 → Bandit B602 → Confirmed issue → Route to qa-verification-planner for injection test cases → Fix + retest
• 🟡 Medium: eval(config) at src/auth/token_handler.py:22 → ESLint detect-eval → Hotspot → Code review shows input validated against whitelist → Suppress with rationale
• 🟡 Medium: MD5 hash at src/auth/token_handler.py:88 → Bandit B303 → Confirmed issue → Create US-045 (migrate to bcrypt)

Output: Populate report.template.md with findings, triage categories, and linked stories (US-042, US-045, SUPP-001)

Example 2: GitHub-integrated repository (CodeQL)

Setup (one-time):

Settings → Security › Code scanning › CodeQL Analysis → Enable default setup

On every PR:

• CodeQL runs automatically
• Findings appear in Security tab → Code scanning alerts
• Export to SARIF for custom dashboards if needed

Workflow:

1. Review CodeQL alerts; triage using report.template.md
2. Fix high/critical issues
3. Route hotspots to sec-risk-security-review (auth logic, crypto, race conditions)
4. Document suppressions in suppression.template.md
5. Release gate: all CRITICAL/HIGH findings fixed or explicitly accepted

Example 3: Multi-language JavaScript + Python service

Commands:

# JavaScript baseline
npx eslint src/ --format json > findings-eslint.json

# JavaScript + Semgrep (React, Vue patterns)
semgrep scan --config=auto src/ui/ src/api/ -o findings-semgrep.sarif

# Python baseline + security
ruff check src/backend/
bandit -r src/backend/ -f json > findings-bandit.json

# Unified SARIF output
# (tool-specific; consult SARIF specification)

Triage: Use report.template.md to dedup tools, consolidate by severity, link to stories

Example 4: False positive triage

Finding: Semgrep flags cursor.execute(query) as SQL injection

Assessment:

• Tool sees variable query and flags as unsafe
• Code shows: query = "SELECT * FROM users WHERE id = %s" (parameterized)
• Parameters: cursor.execute(query, [user_id]) (passed separately)
• Diagnosis: Tool doesn't understand cursor.execute() parameter binding; FP
• Action: Record in suppression.template.md; add to .semgrep.yml rule tuning (disable or exclude parameterized calls)
• Evidence: Linked code review + test case test_sql_injection_params.py demonstrating parameterized calls block injection

Suppression record:

FP-001:
  finding: SQL injection in cursor.execute(query)
  reason: Tool doesn't understand ORM parameterized binding; query is template, params are separate
  evidence: tests/test_db.py::test_parametrized_prevent_injection
  owner: @alice-security
  review_date: 2026-09-25

Suppression Policy

Critical rule: All suppressions must have a formal record with rationale, owner, scope, and review date. Critical findings require a HUS-* approval story in execution-plan/backlog/ (approved before the suppression is committed); record the decision using gov-review-gate-management.

Format: Use suppression.template.md for each suppression. Record in code with tool-specific syntax:

# Bandit
os.system(cmd)  # nosec: B605 (hardcoded trusted command; reviewed 2026-04-15)

# Semgrep
template = django.template.Template(config)  # nosemgrep (config from admin only; test coverage in test_config_injection.py)

# ESLint
eval(expr)  // eslint-disable-next-line security/detect-eval (config parsing; input from trusted file)

Strategy:

• Suppress as narrowly as possible (single line, not whole function/file)
• Only approve suppressions with evidence: test case, code review, or threat model
• For critical/high findings: require security reviewer sign-off before suppression
• For medium/low with business rationale: product owner also approves
• Quarterly review: remove stale suppressions; renew justified ones

See suppression.template.md for detailed format and lifecycle.

CI/CD Integration Guidance

GitHub Actions Example

If GitHub CodeQL is enabled:

# .github/workflows/codeql.yml (auto-generated)