How it works

How a package becomes a firewall verdict.

Every npm package runs through three connected loops. OSV/GHSA advisories anchor known-malicious blocks, continuous static analysis watches the registry stream, and source-aware AI reviews anything that needs a closer look before a verdict reaches your clients.

The pipeline

// 01

Trusted intel

OSV / GHSA advisories

OSV/GHSA advisories are the hard-authority side. When a package version is known malicious, LPM Firewall records the advisory context, prepares public-safe evidence, and publishes a block verdict.

Each publication is a normal firewall verdict
  • Package-version and artifact identifiers are tied to the advisory.
  • The client-facing action is a highest-confidence block.
  • Public reports point back to the advisory evidence where appropriate.
trusted advisoriespublic evidenceverdict publication
// 02

Static scan loop

continuous registry scan

The static side runs continuously over the npm registry stream: fetch, scan, classify, then either finalize or request deeper review.

  1. Read registry changes and fetch package metadata.
  2. Queue package versions for scanner processing.
  3. Download and scan with the scanner engine: findings, verdict, confidence, source fingerprints, artifact inventory, lifecycle, network, and obfuscation signals.
  4. Add context such as manifest confusion, source similarity, reputation signals, and version changes.
  5. Routing decides whether AI review is needed; otherwise the result is finalized.
  6. Public-safe report data is prepared for the website.
Publication behavior
  • Clean verdicts clear stale warn or block decisions.
  • Warn, suspicious, and block verdicts publish package-version decisions.
  • If AI review is needed, static analysis does not publish a final block by itself.
registry monitoringscanner enginerisk enrichment
// 03

AI routing

review routing

Static analysis requests source-aware review when a deterministic answer isn't safe:

  • Strong static malicious / suspicious signals.
  • Source-similarity to known-malicious signatures.
  • Identity-clone mismatch.
  • High-risk lifecycle / network / execution combinations.
  • Structural or metadata risk not safe to resolve deterministically.

Source similarity is routing intelligence, not automatic block authority. It creates friction and sends the package to source-aware AI review.

similarity signalssource-aware review
// 04

AI review loop

source-aware review

AI review looks at the source, scanner evidence, and package context before it can recommend a final action.

  1. Prioritize packages that need additional review.
  2. Download and inspect package source in a read-only review environment.
  3. Build focused source context plus scanner hints; AI returns verdict, action, rationale, and evidence.
  4. Finalize the decision into the internal catalog and publication layer.
  5. Retain confirmed malicious artifacts in a restricted evidence archive.
  6. Prepare public-safe report data and publish the client-facing verdict.
source reviewpolicy finalization
// 05

Feedback loop

learning without auto-blocks

Every malicious finding makes the next run smarter without making the system overconfident.

  • OSV/GHSA exact identities become hard block records; AI-confirmed malicious packages become package-version blocks.
  • Confirmed malicious artifacts are retained for restricted evidence review.
  • Scanner source fingerprints and trusted malicious package archive signatures are kept as routing intelligence.
  • Future packages matching those signatures are routed to source-first AI.
Which keeps the system honest
  • Exact trusted identity → block.
  • Source-fingerprint similarity → route to AI.
  • AI confirms → block + archive + future evidence.

Similarity creates friction; AI or trusted intel creates final block authority — so the system never collapses into a dangerous "similarity says block."