Eagle 3.0 is Safeguard.sh's classification model and it shipped this week across all regions. Eagle is what looks at a package, an image, a commit, or a secret and decides what it is — benign, malicious, abandoned, typosquat, credential leak, and a longer list of sub-labels. It is the model that turns a stream of artifacts into a triaged feed of findings.
This release is the largest label-schema change since 1.0, and the first that pairs Eagle directly with reachability data at classification time rather than at post-processing. If you operate a Safeguard deployment you will see concrete shifts in alert volumes and distributions, which is the main thing this post covers.
What is Eagle 3.0 classifying, and what changed?
Answer first: Eagle 3.0 handles five artifact classes and split two of them into finer labels.
The five classes are packages (npm, PyPI, Maven, NuGet, Go, Rust, Ruby, PHP), container images, Helm charts, commits and diffs, and secrets. 3.0 keeps the class boundary from 2.5 but rewrites the label tree underneath two of them.
For packages, the old "suspicious" catch-all is gone. It is replaced by six mutually exclusive labels: malware.credential_stealer, malware.crypto_miner, malware.backdoor, typosquat.confusable, typosquat.dependency_confusion, and abandoned.maintainer_inactive. Each comes with a confidence score and a short evidence list — the install script snippet, the registry metadata, the typo distance to the target package — rather than a single opaque probability.
For commits and diffs, we added introduces.vulnerable_pattern as a first-class label, which fires when a patch re-introduces a pattern that was previously remediated. This is mostly useful for catching revert-by-merge mistakes in large monorepos and it leans on reachability to avoid firing on unreachable code.
Secrets classification is unchanged at the schema level but the underlying detector has a new stage that uses the cloud provider's own format validators (AWS, GCP, Azure, HashiCorp, GitHub, Stripe) rather than regex alone. False positives on AWS access keys in particular should drop noticeably.
How will alert volumes shift after the upgrade?
Two real shifts to expect: package malware alerts go up, and typosquat alerts go down.
Package malware alerts go up because Eagle 3.0 ingests two new signals — install-time network telemetry from sandbox detonation and post-install filesystem behavior — that were not in 2.5. On the set of newly-published npm and PyPI packages we evaluated 3.0 against, it surfaced about 18% more true malware than 2.5 at the same precision target. The absolute numbers are small (malicious packages are a tiny fraction of publishes) but the deltas matter for teams running aggressive ingestion policies.
Typosquat alerts go down because the old detector fired on edit-distance plus install-count, which generated a long tail of low-quality alerts for legitimate forks and locale-specific packages. The new detector requires either a confusable character substitution (Cyrillic а for Latin a, zero-for-O, and the rest) or a dependency-confusion pattern (internal package name published to a public registry) to fire at the high confidence tier. Edit-distance alone lands in low and can be filtered out.
Secrets false positives go down across the board. AWS, GCP, and GitHub-token false positives were the top three in 2.5; 3.0 validates format and, where possible, checksum before it labels.
Abandoned-package alerts are new to Eagle as a first-class label. If you were not running a separate abandoned-package check, expect to see these appear. If you were, you will want to dedupe.
Does Eagle 3.0 change how reachability is applied?
Yes — reachability is now part of classification, not a separate post-filter.
In 2.5, Eagle classified a package, and a downstream step joined the classification to reachability data to decide whether to surface the finding. In 3.0, Eagle receives reachability as an input feature and emits a reachable: true|false|unknown field on the finding itself. The classifier uses reachability as a feature when assigning confidence: a malicious package that is reachable gets a higher-priority label; an abandoned package that is not reachable lands in a separate lane.
The aggregate effect of this and the improved detectors is the 60-80% CVE noise reduction number we quote, which is measured as the reduction in alerts that require human attention compared to a plain SCA feed. That number has not changed in 3.0 — it was already in that range with 2.5 — but the underlying mix is cleaner.
{
"artifact": "pkg:npm/request@2.88.2",
"labels": [
{ "label": "abandoned.maintainer_inactive",
"confidence": 0.94,
"evidence": ["last_publish=2020-02-11","advisory=DEP-001"] }
],
"reachable": true,
"reachable_paths": 3,
"eagle_version": "3.0"
}
How do I adopt Eagle 3.0 without breaking existing rules?
Pin and migrate — do not auto-upgrade if you have webhooks or SIEM rules keyed off the old label strings.
Eagle 3.0 is the default for new organizations. For existing organizations, 2.5 remains the pinned default until you opt in, and 2.0 remains available for another six months. The opt-in is per-workspace and can be staged by environment — the pattern we recommend is dev and staging on 3.0 for two weeks before prod.
The label migration is the work. The old suspicious label is gone, so any downstream rule that matched on it needs to be rewritten against the new labels. Two tools to help. First, safeguard findings diff --from eagle-2.5 --to eagle-3.0 --workspace <ws> produces a report of what would have fired differently over the last 30 days. Second, the web app has a side-by-side view that shows the same finding scored by both versions, which is useful for calibrating SIEM thresholds.
Custom workflows that call Eagle directly via the MCP Server or Local Runner should pin the version explicitly for the duration of the migration:
# .safeguard/workflows/triage-new-dependencies.yml
model:
eagle: "3.0"
on_label:
- match: "malware.*"
action: "block_and_notify"
- match: "typosquat.*"
action: "require_approval"
- match: "abandoned.*"
action: "open_tracking_issue"
TPRM customers using Eagle for vendor-artifact classification should note that 3.0 adds a vendor_attested dimension to the output — if a vendor has attested an artifact via the TPRM module, Eagle carries that attestation through and surfaces it on the finding. The classification is still Eagle's; the attestation is additional context.
How Safeguard.sh Helps
Eagle 3.0 is the classification engine that feeds the rest of the platform: Griffin uses Eagle labels as the starting point for remediation plans, Lino uses them to map to compliance controls, and the Gold Registry is populated and re-validated against Eagle output. You will see the effect across every Safeguard surface — the web app at app.safeguard.sh in US, EU, and Gov regions, the desktop application, the IDE extensions, the MCP Server, and the Local Runner — because the label schema is consistent across them. The 100-level deep dependency scanning continues to feed the classifier raw artifacts at every level of the graph, and reachability analysis is now a first-class input to classification rather than a post-filter, which is what keeps the 60-80% noise reduction honest. If you operate a FedRAMP HIGH, IL7, or SOC 2 Type II workload, Eagle 3.0 is validated in the Gov region with the same label schema as commercial.