chainsaw intel

Query the v1 risk-intelligence API (package, scan, signals, health)

Query the v1 risk-intelligence API (package, scan, signals, health)

SubcommandWhat it does
chainsaw intel healthPing the risk engine and print its version + signal count
chainsaw intel packageFetch the risk evaluation for a single package version
chainsaw intel scanEvaluate a project’s lockfile against the risk engine
chainsaw intel signalsList registered signals grouped by category
chainsaw intel [command]

intel surfaces the v1 public risk-intelligence API (/api/v1/intel/*): single-package lookups, full tree evaluation from a lockfile, the signal catalogue, and a quick engine health check. All subcommands honour the persistent –json flag for machine-readable output.

‘intel signals’ works without a server or a token — the catalogue is compiled into this binary. The other subcommands need both.

chainsaw intel health

Ping the risk engine and print its version + signal count

chainsaw intel health

Verify the v1 risk-intelligence API is reachable. Prints engine version, how many signals are registered, and the list of categories.

Exit codes: 0 engine reachable and healthy 2 server unreachable, or it answered with an error 3 no server configured, or not authenticated 4 bad invocation

chainsaw intel package

Fetch the risk evaluation for a single package version

chainsaw intel package <ecosystem> <name> <version>

Look up one package against the risk engine. Supports npm scoped names and any ecosystem the server recognises.

Examples: chainsaw intel package npm lodash 4.17.21 chainsaw intel package npm @babel/core 7.24.0 chainsaw intel package pypi requests 2.32.3 –json

Exit codes: 0 success (any verdict — the verdict is in the output, not the exit code) 2 server unreachable, or it answered with an error 3 no server configured, or not authenticated 4 bad invocation

chainsaw intel scan

Evaluate a project’s lockfile against the risk engine

chainsaw intel scan [flags]

Upload a lockfile to the v1 evaluate endpoint and render the tree summary.

When –lockfile is omitted, the cwd is scanned for the first supported lockfile in preference order: package-lock.json, pnpm-lock.yaml.

Examples: chainsaw intel scan chainsaw intel scan –lockfile ./client/package-lock.json chainsaw intel scan –json

Exit codes: 0 all nodes are Allow — and every node was actually evaluated 1 one or more nodes are Warn or UpgradeAvailable 11 one or more nodes are Quarantine or Replace (hard enforcement block) 2 operational error (HTTP / server / IO), or the server could not evaluate one or more packages (the scan is incomplete) 3 auth 4 usage

Flags

FlagTypeDefaultDescription
--lockfilestring—Path to a supported lockfile (default: auto-detect in cwd)

The global flags apply here too.

chainsaw intel signals

List registered signals grouped by category

chainsaw intel signals [flags]

Print every risk signal the engine can register, grouped by category and sorted by severity within each group. Use –json to round-trip the full catalogue (e.g. to generate policy templates).

Works offline. The catalogue is static data compiled into this binary, so no server or token is needed. When a server IS configured and you are authenticated, its catalogue is fetched instead — it is the one that will actually judge your packages, and it can differ from this build’s if the two have drifted. The output always states which of the two you are looking at; –local forces the compiled-in one.

Exit codes: 0 catalogue printed (from either source) 2 a configured server was contacted and failed 3 auth was rejected by a configured server

Flags

FlagTypeDefaultDescription
--localbool—print the catalogue compiled into this CLI without contacting the server

The global flags apply here too.