SCA + Supply Chain Security

What SCA does (and what it doesn't)

SCA looks at your dependency manifests — package.json, go.sum, requirements.txt, pom.xml, Gemfile.lock, Cargo.lock — and asks: which of these libraries have known vulnerabilities, and which are actively being exploited?

SCA does NOT analyze how YOUR code uses those dependencies — for that, see SAST. SCA also doesn't test the live app — see DAST. The triad is meant to complement: SCA tells you a vulnerable lib exists, SAST tells you if your code triggers the vulnerable code path, DAST proves whether it's exploitable in production.

How a Sectora SCA scan works

1. Manifest discovery. The repo is scanned for every known manifest type. Lockfiles are preferred over loose manifests (they pin transitive versions).
2. Dependency resolution. Each direct + transitive dependency + version is enumerated. Reaches 5+ levels deep automatically.
3. CVE cross-reference. Each (package, version) tuple is queried against three vulnerability databases:
• NVD (NIST National Vulnerability Database) — the authoritative source.
• GHSA (GitHub Security Advisories) — usually 1–4 weeks faster than NVD, ecosystem-specific.
• CISA KEV (Known Exploited Vulnerabilities) — CVEs with confirmed in-the-wild exploitation. Highest priority.
4. Supply-chain signal detection. Beyond known CVEs, the watcher detects pre-CVE compromise patterns (see below).
5. Risk scoring + LLM detector. Each finding gets a severity + CVSS, and (on Pro) the LLM detector reasons over the release artifact for malicious-release patterns.

Supported ecosystems

How findings are ranked

Findings sort by composite criteria, in this order:

1. KEV listed? Anything on CISA's Known Exploited Vulnerabilities catalogue goes to the top regardless of CVSS.
2. Severity — Critical > High > Medium > Low. Maps to CVSS bands.
3. CVSS — for ties within a severity band.
4. Reachability (when DAST data exists for the same target) — vulns in code paths that DAST has actually exercised rank higher.
5. Age — newer advisories rank higher (more likely the team hasn't triaged yet).

The Supply-Chain Watcher (pre-CVE signals)

Public CVE catalogues are reactive — a malicious package can sit in production for weeks before NVD assigns an ID. Sectora's watcher catches the compromise patterns directly:

Each signal links to the underlying evidence (registry metadata, GitHub events, npm timestamp). Acknowledge a signal once you've verified; it stays acknowledged across scans via fingerprint.

malicious_release LLM detector (Pro)

For high-severity supply-chain analysis, the LLM detector fetches the published artifact (npm tarball, PyPI sdist, etc.) and reasons over it. Returns a confidence score and a citation list:

• Postinstall scripts that contact unknown hosts.
• Obfuscated payloads (eval'd hex / base64 / unicode-escaped code).
• Credential-stealer signatures (reads of ~/.aws/credentials, ~/.npmrc, browser stores, env vars).
• Cryptocurrency wallet hijack patterns (web3 address replacement in clipboard).
• Reverse-shell shapes (any net or child_process with attacker-shaped destinations).

Available on Pro tier and above. Operator can set their own SECTORA_AI_PROXY_URL (BYO Anthropic/OpenAI/Gemini key) or use the bundled Gemini fallback that ships with the trial.

Dependency graph + Treemap visualisation

The Dependencies page renders your full dep tree as a treemap, sized by severity-weighted vulnerability count. Critical vulns make the box large + red; clean deps shrink to nothing. Visual scan-once-a-week to see if recent commits introduced new high-risk libs.

High-risk dependency rollups appear on the Dashboard (Top Risky Dependencies card) — derived from vulnerable: true + severity IN (critical, high), NOT from the unused risk_score column.

License compliance (separate feature)

SCA also surfaces each dependency's license. The License Policies feature lets you set policies like "no GPL in production code" and get a PR-gate alert when a new dep violates. See License Policies.

CI/CD integration

# .github/workflows/sectora-sca.yml
name: Sectora SCA
on:
  pull_request:
    paths:
      - 'package*.json'
      - 'pnpm-lock.yaml'
      - 'go.sum'
      - 'requirements*.txt'
      - 'Gemfile.lock'

jobs:
  sca:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run SCA + block on new High+ findings
        env:
          SECTORA_API_KEY: ${{ secrets.SECTORA_API_KEY }}
        run: |
          SCAN_ID=$(curl -sf -X POST https://api.sectora.io/api/v1/sca/scans \
            -H "Authorization: Bearer $SECTORA_API_KEY" \
            -d '{"target": "${{ github.repository }}", "branch": "${{ github.head_ref }}"}' \
            | jq -r .data.id)

          # Wait + fail if any KEV-listed CVE is introduced
          curl -sf -H "Authorization: Bearer $SECTORA_API_KEY" \
            "https://api.sectora.io/api/v1/sca/scans/$SCAN_ID/diff?baseline=main&kev_only=true" \
            | jq -e '.new | length == 0'

Most teams gate on KEV-only for PRs (zero tolerance for actively-exploited CVEs) and run a wider severity ≥ high check daily on main.

Troubleshooting

"Scan found 0 vulns but I know we have outdated deps"

• Confirm the right lockfile shipped with the commit — Sectora prefers lockfiles over loose manifests. Without a lockfile, transitive deps aren't enumerated.
• Check the scan log for manifest_count — if zero, the scanner didn't find any manifests at the repo root (try expanding paths in Settings).
• NVD lag — newly disclosed CVEs can take 24–72 hours to appear. GHSA usually arrives faster; we query both.

"Too many Medium findings — most aren't reachable"

• Reachability isn't enabled by default. Enable DAST correlation in Settings — Medium findings in code paths DAST hasn't exercised get downgraded to Low.
• Pin your noise threshold to severity ≥ High in PR gates; Mediums + Lows go to the dashboard backlog.
• For Java/Maven specifically, transitive dep counts can balloon — use mvn dependency:tree output and only scan direct deps if your sec team is okay with that trade-off.

"A supply-chain signal fired and I'm not sure if it's real"

• Every signal shows its evidence trail — click into the signal to see registry timestamps, GitHub event log, and (for malicious_release) the LLM's cited reasoning + payload snippet.
• If you verify it's benign, click Acknowledge. The signal stays acknowledged across future scans via fingerprint.
• If you verify it's real, the Pin action lets you lock the dep to a known-safe version range until the maintainer publishes a clean release.

What's next

• SAST — pair with SCA for "is the vulnerable code path actually called from my code?"
• DAST — runtime exploitation testing closes the loop.
• License Policies — block GPL/AGPL/etc. introductions at PR time.
• PR Gates — wire SCA into your branch protection.
• Risk Scoring — how Sectora ranks findings across all four scanners.