Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/irchaosclub/FANGS/llms.txt

Use this file to discover all available pages before exploring further.

The fangs baseline command is your interface to the fingerprint memory FANGS builds for every watched package. A baseline is the set of (category, value) pairs — network destinations, file paths, SNI hostnames — that have been confirmed as legitimate behavior. When a new run produces deviations, baseline promote lets you accept those findings as known-good after human review, teaching FANGS what the package is now allowed to do.

​
Subcommands

SubcommandPurpose
baseline listDisplay the current baseline fingerprints for a package
baseline promote <run_id>Accept a run’s behavior into the baseline and clear its deviations

​
fangs baseline list

Reads the baseline_fingerprints table and renders one row per (category, value) pair observed across all promoted runs for the requested package. 
fangs baseline list -package <package_name>

​
Flags

​
-package
string
required
The npm package name to inspect. Must match the name as recorded during the watched-package run (e.g. lodash, @scope/pkg).

​
Output columns

ColumnDescription
CATEGORYFingerprint category: net_new_destination, fs_new_path_write, net_new_https_host, etc.
VALUEThe observed value — an IP address, file path, or SNI hostname
COUNToccurrence_count — how many times this (category, value) pair has been seen across all promoted runs
FIRST_SEENShort prefix of the run_id where this fingerprint first appeared
LAST_SEENShort prefix of the run_id where this fingerprint was most recently observed

​
Examples

fangs baseline list -package lodash
Long values in the VALUE column are truncated to 60 characters in table output. Use -json to retrieve the full untruncated value.

​
fangs baseline promote

Loads a run’s raw events, applies the current allowlist filter (identical to the filter the Differ uses during automated analysis), extracts fingerprints, and merges them into the baseline_fingerprints table. The run is then marked is_baseline = true and all of its deviation rows are deleted, removing it from the pending queue. 
fangs baseline promote <run_id>
The run_id argument accepts either a full 32-character hex ID or any unique short prefix (git-style). FANGS resolves the prefix against the runs table; if multiple runs share the prefix, the command errors and asks for a longer prefix.

​
What promote does

1

Resolve the run

Looks up the run by full ID or unique hex prefix via ResolveRunPrefix. Fails with an error if the package name on the run is empty.
2

Load events

Fetches all events recorded for the run from the events table via ListEventsByRun.
3

Apply allowlist filter

Builds a differ.Filter using the current global and package-scoped allowlist entries. This guarantees that suppressed values (CIDRs, paths, SNI names) are not accidentally baked into the baseline.
4

Extract fingerprints

Calls differ.ExtractFingerprintsWith to derive (category, value, count) tuples from the filtered events.
5

Merge into baseline

Upserts the fingerprint rows via MergeBaseline. Existing (package, category, value) rows have their last_seen_run_id updated and occurrence_count incremented; new rows are inserted.
6

Mark run as baseline

Flips runs.is_baseline = true so the run no longer appears in fangs pending.
7

Clear deviations

Deletes all deviation rows for the run. If this step fails, a warning is printed to stderr but the command still exits successfully — the baseline merge is already committed.

​
JSON output

When -json is passed, baseline promote emits a single object: 
{
  "run_id": "a3f2b19c44e8d701...",
  "package": "lodash",
  "fingerprints_merged": 42,
  "promoted": true
}

​
Examples

fangs baseline promote a3f2b1

​
When to promote

Legitimate behavior change

The package added a new CDN endpoint or updated a dependency that hits a new host. Review confirms no malicious intent — promote to teach FANGS the new pattern.

New install-time path

A major version now writes to a different directory. After confirming the path is expected, promote so future runs don’t re-flag the same location.

Do NOT promote

If any deviation looks genuinely suspicious — unexpected outbound connection, novel write to a sensitive path — investigate fully before promoting. Promotion is permanent within the run.

After allowlisting

If you added an allowlist entry to suppress a known-safe value, re-analyze or re-run the package first, then promote the clean run. Promoting before allowlisting bakes the suppressed value into the baseline.
Promoting a run is irreversible through the CLI. The deviation rows are deleted and the fingerprints are merged into the rolling baseline. If you promote a run that contained malicious activity, those behaviors become part of the package’s trusted fingerprint.

Build docs developers (and LLMs) love

Get started for freeTalk to us