Security Scanning

Security Scanning

Quick Start

• Secrets: fail fast; rotate on exposure.
• Dependencies: gate critical/high; automate updates.
• SAST: start high-signal; ratchet over time.
• Open Source Safety: score components on three axes — license tier, severity-weighted CVEs, obsolescence.
• Exceptions: require reason, owner, and expiry.

Open Source Safety

Third-party component risk is more than "vulnerable: yes/no". Evaluate each component on three independent dimensions and gate on the worst:

• License risk: HIGH = strong copyleft / GPL/AGPL/LGPL (whole-app disclosure risk);

MEDIUM = weak copyleft / MPL, EPL (modification disclosure only); LOW = permissive / MIT, Apache-2.0, BSD. Unknown/NOASSERTION → treat as HIGH until identified.

• CVE weighting: weight by severity (critical ≫ high ≫ medium ≫ low) rather than raw

counts; critical/high block, medium/low track with owner + expiry.

• Obsolescence: score the gap to latest version; majors-behind or unmaintained

upstream is elevated risk.

See references/open-source-safety.md for the full framework, tier tables, the CVE weighting model, obsolescence scoring, and the transitive-dependency trust model.

Load Next (References)

• references/tooling-matrix.md
• references/ci-workflows.md
• references/triage-and-remediation.md
• references/common-findings-and-fixes.md
• references/supply-chain-and-sbom.md
• references/open-source-safety.md

CI Workflows for Security Scanning

Treat scanning like tests: fast PR checks + deeper scheduled runs.

Recommended Cadence

• On every PR: secrets + dependency scan + lightweight SAST (high-signal rules).
• Nightly/weekly: deeper SAST rulesets, full-history secret scan, container/IaC scans, SBOM generation.

Gating Strategy

• Secrets: fail the build and rotate immediately.
• Dependencies: fail on critical/high initially; ratchet over time.
• SAST/IaC/Container: start as advisory, then gate on high-confidence rules.

GitHub Actions Skeleton (Conceptual)

name: security-scan

on:
  pull_request:
  schedule:
    - cron: "0 3 * * *"

jobs:
  secrets:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Secret scan
        run: |
          # Example: gitleaks/trufflehog/detect-secrets
          echo "run secret scanner here"

  deps:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Dependency vuln scan
        run: |
          # Example: osv-scanner + ecosystem-specific audits
          echo "run dependency scanner here"

  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: SAST scan
        run: |
          # Example: semgrep/codeql
          echo "run SAST here"

Replace the run: blocks with the chosen tools and configure:

• PR annotations (SARIF where possible)
• artifact uploads (raw reports)
• thresholds/filters for gating

Practical Tips

• Cache dependencies to keep PR scans fast.
• Separate “advisory” jobs using continue-on-error until false positives are under control.
• Publish a short summary to the PR (counts by severity + top findings + links to artifacts).

Common Findings and Fix Patterns

Scanners often surface the same classes of issues. Fix patterns are usually stable even as tooling changes.

Injection

✅ Correct: parameterized SQL

query = "SELECT * FROM users WHERE email = %s"
cursor.execute(query, (user_email,))

❌ Incorrect: string interpolation

query = f"SELECT * FROM users WHERE email = '{user_email}'"

Command Injection

✅ Correct: structured subprocess invocation

import subprocess

subprocess.run(["ping", "-c", "1", user_input], check=True)

❌ Incorrect: shell interpolation

import os

os.system(f"ping {user_input}")

Authentication and Authorization

✅ Correct: hash passwords

from werkzeug.security import generate_password_hash

password_hash = generate_password_hash(password)

✅ Correct: enforce authorization server-side

def delete_user(user_id, current_user):
    if not current_user.is_admin:
        raise PermissionError()
    User.delete(user_id)

Sensitive Data Exposure

✅ Correct: do not log secrets

logger.info("User login attempt", extra={"email": email})

❌ Incorrect: logging credentials

logger.info(f"User logged in: {email}, password: {password}")

✅ Correct: load secrets from environment

import os

api_key = os.getenv("API_KEY")

XXE (XML External Entities)

✅ Correct: use hardened XML parsers

import defusedxml.ElementTree as ET

tree = ET.parse(user_supplied_xml)

XSS

✅ Correct: render untrusted strings safely

element.textContent = userInput;

❌ Incorrect: HTML injection

element.innerHTML = userInput;

Framework notes:

• React: render strings as {userInput} (auto-escaped)
• Vue: render strings as {{ userInput }} (auto-escaped)

Insecure Deserialization

✅ Correct: parse structured data with validation

import json

data = json.loads(user_data)

❌ Incorrect: deserialize untrusted pickles

import pickle

data = pickle.loads(user_data)

Logging and Monitoring

Log security-relevant events (without secrets):

• auth failures and lockouts
• privilege changes and admin actions
• unusual access patterns (rate spikes, suspicious geos)

Include request IDs and actor identity in audit logs.

Open Source Safety — License Risk, CVE Weighting, and Obsolescence

A structured way to reason about third-party / open-source component risk beyond a binary "vulnerable: yes/no". An overall Open Source Safety posture combines three independent dimensions, each scored 0 (worst) to 100 (best):

1. Security — vulnerability load, weighted by CVE severity 2. License Compliance — legal/IP risk from component license types 3. Obsolescence — how far behind latest each component is

Treat these as three separate gates: a component can be CVE-clean but a license liability, or fully permissive but dangerously out of date. The aggregate is only as useful as the worst dimension you ignore.

Source note: This framework is derived from CAST Highlight's Open Source Safety

methodology (https://doc.casthighlight.com/). License-tier groupings follow CAST's

out-of-the-box risk profile, which itself maps to the copyleft/permissive

distinctions summarized at https://choosealicense.com/appendix/. Tier assignments and

scoring weights here are presented as reference guidance, not normative standards —

calibrate to your own distribution model and legal policy.

---

1. License risk tiers

The driving question is IP disclosure risk: if your team modifies (or, for strong copyleft, merely links/distributes) the component, what are you obligated to disclose?

HIGH risk — strong copyleft (proprietary-disclosure risk)

If the license can force disclosure of your own application's source code, it is HIGH risk. Strong copyleft licenses condition their permissions on releasing the complete source of larger works that incorporate the licensed code, under the same license.

• Examples: GPL-2.0, GPL-3.0, AGPL-3.0, LGPL-2.1, LGPL-3.0, EUPL-1.1
• Why it matters most for: distributed software, mobile apps, embedded, and any

product you ship to customers. AGPL extends obligations to network/SaaS use, so it is especially consequential for hosted services.

• Action: block by default in distributed/commercial products; require explicit

legal sign-off and an architectural isolation plan (separate process, no linking) before any exception.

MEDIUM risk — weak copyleft (library-modification disclosure risk)

If the license only forces disclosure of modifications to the component's own files (not your whole application), it is MEDIUM risk. The scope is bounded — but still real, because business logic embedded in those edits would have to be published.

• Examples: MPL-2.0 (Mozilla Public License), EPL-1.0 (Eclipse Public License)
• Action: allowed if you use the component unmodified; if you must patch it,

keep changes minimal and isolated, and disclose those file-level modifications.

LOW risk — permissive

If neither proprietary-disclosure nor modification-disclosure obligations apply, it is LOW risk. These permit use, modification, and redistribution with attribution only.

• Examples: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, BSL-1.0,

Unlicense

• Action: generally safe; still record attribution/NOTICE obligations (Apache-2.0

requires preserving NOTICE files).

Unknown / unmatched licenses

Components whose license cannot be confidently identified (often tagged NOASSERTION) should be treated as HIGH risk until resolved — you cannot accept a risk you cannot classify. Investigate the upstream project's actual license before shipping.

Risk depends on your distribution context. The same LGPL component may be low

concern for an internal tool and high concern for a shipped binary. Build a license

profile that reflects how your software is delivered.

---

2. CVE weighting (the Security dimension)

A raw vulnerability count is misleading — one critical RCE outweighs twenty low-severity informational findings. Weight findings by severity so the score reflects exploitable risk, not noise.

Weighting model (illustrative — tune to your policy):

Weighted risk per component ≈ Σ(count_severity × weight_severity), then normalize against component count so a large portfolio isn't penalized purely for size. A higher weighted load → lower Security sub-score.

Use it to prioritize, mirroring the skill's triage gate: critical/high block the build; medium/low are tracked with an owner and expiry. Combine weighting with reachability where possible — a critical CVE in a code path you never call is lower real risk than a high CVE on your request path.

---

3. Obsolescence scoring

Out-of-date components accumulate unpatched bugs and drift away from the security fixes that only land in current releases. Score the version gap between what you ship and the latest known release of each component.

A practical obsolescence signal per component:

• Current / one minor behind → low obsolescence (good)
• Several minors behind, same major → moderate; schedule an update
• One or more majors behind → high obsolescence; plan a migration (breaking changes

likely), and treat as elevated risk because security backports to old majors are rare to nonexistent

• Unmaintained upstream (no release in a long window, archived repo) → highest

concern; begin sourcing a replacement

Obsolescence is a leading indicator: a component falling behind today is where tomorrow's unpatched CVE will sit.

---

4. Transitive dependencies — "friends of your friends"

Most of your real dependency surface is transitive: the components your direct dependencies pull in. They carry their own CVEs and licenses, which become yours at runtime. A direct dependency can quietly introduce a strong-copyleft license or a critical CVE three layers down.

You will not fix every transitive issue — you don't control them — but you must have visibility and act on the worst:

• If a direct component pulls in critical transitive CVEs, upgrade that direct

component first; maintainers usually patch their own dependency tree in newer releases.

• If a direct component drags in many transitive vulnerabilities that don't shrink

over its release timeline, treat that as a signal to find an alternative component.

• Scope matters: test-scope transitive deps are lower runtime risk than

compile/runtime-scope ones. Prioritize what actually executes in production.

Generate an SBOM including transitive dependencies so "are we affected?" queries during a CVE event can be answered in minutes, not days (see supply-chain-and-sbom.md).

---

5. Putting it together — a gate

At ingestion and in CI, evaluate each new or updated component on all three axes:

1. License — is the tier acceptable for our distribution model? (HIGH → block / legal review; UNKNOWN → resolve before merge) 2. Security — does the severity-weighted CVE load cross the gate? (critical/high → block; medium/low → track with owner + expiry) 3. Obsolescence — is it current enough, and is upstream alive?

Ratchet the gate: start by blocking only regressions (new critical CVEs, new HIGH-tier licenses), then tighten thresholds over time to avoid churn — consistent with the skill's exception model (reason, owner, expiry).

Supply Chain and SBOM Basics

Baseline Controls

• Use lockfiles (package-lock.json, pnpm-lock.yaml, poetry.lock, Cargo.lock, go.sum).
• Pin CI actions and critical dependencies to known-good versions.
• Prefer least-privilege tokens for CI and restrict secret access.

SBOM

Generate an SBOM to track components and support incident response:

• Produce SBOMs for release artifacts and container images.
• Store SBOMs alongside build artifacts.
• Use SBOMs to accelerate “are we affected?” queries during CVEs.

Provenance and Signing

Add integrity signals for production artifacts:

• Sign container images and release artifacts.
• Record build provenance (who/what built it, from which commit).

Dependency Policy

Enforce at ingestion time:

• block new critical vulnerabilities
• restrict high-risk licenses if required
• require ownership for dependency additions

Use “ratcheting” gates to reduce churn: only prevent regressions at first, then tighten.

Security Scanning Tooling Matrix

Use scanners as layers. Start with a small baseline that runs fast on every PR, then add deeper checks on a schedule.

Baseline (High-Value, Low-Drama)

1) Secrets scanning

• Block merges on secrets and rotate immediately.

2) Dependency vulnerability scanning

• Gate on critical/high first; track the rest with SLAs.

3) SAST (static analysis)

• Start with high-confidence rules; expand as false positives are tamed.

4) IaC and container scanning

• Add when shipping images or managing infra-as-code.

Matrix

Language/Ecosystem Notes

JavaScript/TypeScript

• Dependency scanning: OSV database tools, plus npm audit/pnpm audit as a quick local check.
• SAST: Semgrep rulesets and TypeScript-aware linters.
• Supply-chain: lockfile integrity, strict registries, scoped tokens.

Python

• Dependency scanning: pip-audit (OSV) and lockfile discipline where possible.
• SAST: Semgrep and targeted linters (bandit) for common risky APIs.

Go

• Dependency scanning: govulncheck for the Go ecosystem plus OSV scanning.
• SAST: Semgrep and focused Go security linters (gosec) when useful.

Rust

• Dependency scanning: cargo audit (advisory DB) and cargo deny for policy.
• SAST: fewer generic tools; rely on targeted patterns and review of unsafe blocks.

Output Formats (Make CI Reviewable)

• Prefer tools that can emit SARIF to integrate with code-scanning UIs.
• Publish machine-readable artifacts (JSON/SARIF) and a short Markdown summary to PRs.

Triage and Remediation Playbook

Triage Flow

1) Confirm the finding

• Reproduce locally or in a minimal test case.
• Identify whether the finding is code, dependency, configuration, or secret-related.

2) Classify severity

• Impact: data loss, account takeover, RCE, privilege escalation, availability.
• Likelihood: exposed surface area, exploitability, required access.

3) Pick a remediation strategy

• Patch code (preferred).
• Upgrade/replace dependency.
• Add runtime mitigations (WAF/rate limiting) as a stopgap, not a substitute.

4) Verify

• Add tests for the vulnerable behavior (negative tests and abuse cases).
• Re-run scans and ensure the finding is gone or properly suppressed.

Dependency Vulnerabilities

Checklist:

• Upgrade the smallest scope first (patch/minor updates before major).
• Prefer direct dependency upgrades; use overrides/resolutions only as a bridge.
• Confirm the vulnerable code path is not reachable when considering risk acceptance.

Secrets

Treat secrets as an incident:

• Rotate the secret and revoke the old one.
• Identify exposure window (commits, CI logs, artifacts).
• Add secret scanning to prevent recurrence.

False Positives and Exceptions

Avoid permanent suppressions. Require:

• reason
• owner
• expiry date
• link to ticket or risk acceptance

Example exception record:

exceptions:
  - id: "SEMGRP-1234"
    reason: "False positive: input is constant and validated upstream"
    owner: "security@team"
    expires: "2026-03-01"
    ticket: "SEC-456"

Review exceptions on a schedule and delete expired entries.