Supply Chain Posture Management

Overview

Supply Chain Posture Management (SCPM) hardens the way your software is built and assembled. Where dependency analysis asks "does this package have a known CVE?", SCPM asks "is this dependency, manifest, lock file, or CI/CD workflow trustworthy in the first place?" It reads the manifests, lock files, and pipeline definitions in each repository and flags supply-chain weaknesses — typosquatted or confusable package names, unpinned or floating dependencies, risky install scripts, missing or stale lock files, restricted licenses, and insecure CI/CD configuration — long before any of them turns into a published advisory.

SCPM scans the default branch to keep a continuous posture baseline and scans pull requests (diff-scoped to the manifests a PR touches) so new supply-chain risk is caught before it merges. Findings are triaged for real-world impact, surfaced in the dashboard and notification targets, and — where a fix can be expressed as a code change — remediated automatically with a pull request.

How It Works

1. Manifest & pipeline discovery: SCPM walks the repository and parses every supported manifest, lock file, and CI/CD definition — npm/package.json, Python (requirements.txt/pyproject.toml/Conda), Go modules, Maven/Gradle (Java), .csproj (C#), Cargo.toml (Rust), Ruby, Composer (PHP), Dockerfiles and Docker Compose, plus GitHub Actions, GitLab CI, Azure Pipelines, Dependabot, and Renovate config.

2. Posture detection: A flat ruleset evaluates each parsed manifest against the supply-chain risk categories below. On a pull request the scan is diff-scoped so only the manifests the PR changed produce findings; on the default branch it runs full-repo.

3. Triage: Each detection is enriched with repository and business context, screened for false positives, classified for severity and exploitability, and assigned a priority. Triage combines LLM reasoning with deterministic rules so classification is reproducible.

4. Delivery: Real findings are written to the platform, flow into the dashboard, and fan out to Jira, Slack, Teams, and GitHub through the notification configuration, with ownership inferred from CODEOWNERS.

5. Remediation: For findings that map cleanly to a manifest edit (for example pinning a floating version or a CI/CD action), SCPM drafts an autofix pull request that matches the surrounding style.

SCPM is event-driven: it reacts to scan and finding lifecycle changes as they happen rather than running on a fixed daily or weekly cron, so posture stays in step with changes to your repositories.

Supply-Chain Risk Coverage

SCPM ships a managed ruleset grouped by category rather than enumerated individually:

Package Trust

• Typosquatting — package names that closely resemble a significantly more popular package, a common malicious-publish vector.

• Dependency confusion — internal/private package names that could be shadowed by a public registry package.

• Supply-chain intelligence signals — dependency hijacking via git-fork versions and replace directives.

Dependency Pinning & Provenance

• Unpinned / floating dependencies — version specifiers that can resolve to different versions across builds.

• Git/HTTP-sourced dependencies — packages pulled from a git or HTTP URL instead of a registry, bypassing registry security controls.

• Missing lock files — manifests with no lock file, allowing non-deterministic resolution.

• Unpinned Docker base images — Dockerfiles and Compose files that reference a tag instead of a digest, exposing builds to tag mutation.

• Dependency cooldown — Dependabot ecosystem blocks with no cooldown, or a cooldown shorter than the configured window, that would auto-merge a freshly published (and potentially compromised) version too quickly.

Install & Build Scripts

• Install scripts — packages that execute scripts during installation.

• Unpinned installs in build scripts — build steps that fetch or install dependencies without pinning.

Licensing

• Missing or restricted licenses — manifests declaring no license or a license denied by org policy, including copyleft (GPL/AGPL/LGPL/SSPL/EUPL) detection.

CI/CD Posture

A large, dedicated body of GitHub Actions / GitLab CI / Azure Pipelines checks — unpinned or unverified actions, script and YAML injection, artifact token leakage, excessive or over-provisioned permissions, dangerous triggers, cache poisoning, privileged checkout, Docker-socket exposure, self-hosted-runner risk, OIDC over-scoping, and missing build attestation, among others.

Known-malware detection by advisory (OSV/GHSA) is owned by Dependency Analysis, not SCPM. SCPM focuses on posture and trust signals that don't yet have a published advisory.

How SCPM Fits With Dependency Analysis

SCPM and dependency analysis (SCA) are complementary halves of dependency security:

• Dependency Analysis (SCA) answers is this package version affected by a known vulnerability? — it matches your dependency graph against enriched CVE/advisory feeds and reasons about reachability and exposure.

• SCPM answers is the way you consume dependencies and run your pipelines trustworthy? — typosquats, confusable names, unpinned versions, missing lock files, risky install scripts, license policy, and CI/CD hardening.

A package can be advisory-clean yet still be a supply-chain risk (a typosquat, an unpinned floating range, an install script, a workflow that leaks a token), which is exactly the gap SCPM covers. The two run over the same repositories and the same manifest set, so findings from both land side by side in the dashboard and route through the same triage, ticketing, and remediation flows.

Finding Lifecycle

Every SCPM detection becomes a finding that moves through a consistent lifecycle:

1. Detected — a scan produces a new finding; pull-request scans flag findings the PR introduces.

2. Triaged — the finding is screened, classified, and prioritised, and re-triaged if a later scan changes the picture.

3. Ticketed & notified — findings that meet your configured thresholds create tickets and notify Slack and Teams.

4. Remediated — an autofix produces a fix and, where it applies, opens a pull request.

5. Resolved or suppressed — a finding can be allowlisted, un-allowlisted, or archived when it no longer reproduces.

Querying & acting on findings

The SCPM API mirrors the other detection services:

• GET /scpm/findings (plus /scpm/findings/preview and /scpm/findings/detailed) to list findings.

• GET /scpm/findings/{findingId}, GET /scpm/findings/{findingId}/triage, and GET /scpm/findings/{findingId}/events to inspect a single finding and its history.

• PATCH /scpm/findings/{findingId} to update a finding.

• POST /scpm/findings/{findingId}/ticket and DELETE /scpm/findings/{findingId}/ticket to manage tickets.

• POST /scpm/findings/{findingId}/allowlist, POST /scpm/findings/{findingId}/unallowlist, and the bulk POST /scpm/findings/allowlist to suppress findings.

Allowlisting a finding

To allowlist (ignore) a finding, send an allowlistReason and an allowlistType:

{
  "allowlistReason": "Internal package, not a public typosquat",
  "allowlistType": "UserFalsePositive"
}

allowlistType is one of AI, UserFixed, UserAssumeRisk, UserFalsePositive, or UserOther. The bulk endpoint additionally takes a findingIds array.

Findings are allowlisted per-finding from the dashboard or API — there is no file-based or static ignore list.

Remediation (Autofix)

When a finding can be resolved by a manifest or pipeline change, SCPM drafts a fix and opens a pull request through the shared autofix pipeline:

• POST /scpm/findings/{findingId}/autofix/fix triggers a fix.

• POST /scpm/findings/{findingId}/autofix/cache, …/cache/diff, and …/cache/create_pr stage and preview a fix before opening a PR.

• GET /scpm/findings/{findingId}/autofix/status, …/state, and …/activity track progress.

Autofix pull-request limits are platform-managed (3 open Nullify fix PRs per repository, 5 new fix PRs per remediation plan) and are not configurable per repository. See Remediations for how fixes work with developers, ownership routing, and CI feedback.

Real-time reaction

Supply-chain posture stays in step with your repositories: as scans complete and findings move through their lifecycle, notifications, ticketing, and Security Program Management react in real time rather than waiting for a nightly batch.

Dependency cooldowns

A freshly published package version is a supply-chain risk in its own right — worm-speed compromises spread through new releases before any advisory exists. SCPM can flag direct and dev dependencies that are newer than a configurable recency window (7 days by default), independent of whether any CVE has been filed, and escalates the riskiest cases — such as a version published moments ago, or an ecosystem with no native cooldown primitive.

You control this per tenant through the SCPM settings API (GET/PUT /scpm/settings): toggle the cooldown gate on or off, set the window in days, and add per-ecosystem overrides.

This complements the narrower Dependabot cooldown conformance rule above (which checks that your Dependabot config doesn't auto-merge freshly published versions too quickly).

Configuration

SCPM settings live in the dashboard and admin API, not in any repository config file:

• Ticket creation thresholds (severity/priority per finding type): Configure → Ticketing.

• CI/PR gate (fail the build, enable PR reviews): Configure → Pull Requests.

• Notification destinations: Configure → Connectors (Slack, Teams, Jira).

• Dependency cooldown window: SCPM settings API (PUT /scpm/settings).

Ignore decisions are made per-finding (see Allowlisting a finding).