PACKAGE TRUST

Packages are execution context, not background noise.

A workflow does not only trust the Action it names. It can trust the `npm ci` step beneath the build, the lockfile that anchors it, and the registry state that changes while nobody is watching. Uncain brings that package trust into the same graph as the pipeline.

01

INVENTORY

Separate what exists from what runs.

Uncain treats package inventory and workflow install context as related but distinct evidence. A `package-lock.json` tells us what exists. A workflow `npm ci` step tells us where that package path can affect execution.

  • `package-lock.json` and manifest relationships
  • `npm ci`, restore, and install context observed in workflows
  • Scoped package detail instead of tenant-wide package sprawl
02

DRIFT

Registry movement can change trust.

Package drift is not just a vulnerability feed. It is a trust question: did a package under a release workflow pick up a malicious signal, lose lockfile integrity, or introduce a mutable selector that should change what the team is willing to run?

  • Malicious package intelligence when bounded evidence exists
  • npm and PyPI registry release monitoring for watched packages
  • Package drift incidents tied back to workflow install context
03

BOUNDARIES

The graph stays responsible.

Package trust can get noisy fast. Uncain keeps the work source-scoped, evidence-led, and careful about what it claims. A package appearing in inventory is not the same as proving arbitrary runtime execution.

  • No raw manifests, lockfiles, workflow YAML, or package contents in public-facing evidence
  • Generated inventory is marked as generated, not confused with committed locks
  • Package detail explains context before severity

PRINCIPLE

Packages need execution context.

Open the graph that keeps dependency evidence attached to the paths that can run it.

Open Uncain