Safeguard Q4 2025 Release Recap

Q4 2025 was the quarter we finished what Q3 started. Reachability reached the JVM. Attestations went end-to-end. Remediation learned your house rules. The runner got leaner and the MCP server left beta. If Q3 was the quarter Safeguard became a platform, Q4 was the quarter the platform grew up. Here is the full set of changes.

What shipped in Q4 2025?

Shipped

• Griffin 2.2 — reachability analysis for Java (Maven, Gradle) and .NET (NuGet) landed in beta early in the quarter and went GA in December. Kotlin and Scala are piggybacking on the JVM analyzer. Reachability now covers the five languages that account for most of the customer graph: Node, Python, Go, Java, and .NET.
• Eagle signed attestations — every Eagle scan now produces an in-toto attestation signed with your Sigstore identity or a customer-managed KMS key. The attestation is bound to the image digest, so a downstream verifier can confirm that a given image was scanned with a given Eagle policy version and passed.
• Lino serverless hooks — Lino can now attach to AWS Lambda (via extension) and Google Cloud Run (via sidecar) to collect the same runtime fingerprints it collects on Kubernetes. The behavioral reachability model now covers short-lived containers where the first invocation is often the only invocation.
• Gold policy-aware remediation — Gold's PRs now respect your allowlist, deny list, and version constraints. If your policy forbids major version bumps for a package, Gold will look for a patch-level fix, and if one doesn't exist it will open an advisory PR with the finding annotated but no code change.
• MCP server GA — the MCP server is out of beta. It now supports tenant-scoped auth, per-tool quotas, and audit logging. Every MCP call lands in the same audit stream as a CLI or workflow call.
• Runner 3.0 — the self-hosted runner was rewritten around a single binary with no external dependencies, a smaller attack surface, and a new plugin ABI. It is roughly 30 percent smaller and starts in under a second on warm hosts.

Improved

• Workflows — workflows can now fan out across monorepo packages and fan in results into a single report. For monorepos with dozens of packages, this replaces the old one-workflow-per-package pattern.
• 100-level scan — the 100-level scan now produces a human-readable report alongside the machine-readable SARIF. The report is intended for non-security reviewers — product managers, release captains — who need to know whether a build is safe to ship without parsing a finding list.
• Desktop app — the desktop app picked up a diff view that compares two scan runs. You can now answer "what changed between the last green build and this red one" without leaving the app.
• IDE extensions — both the VS Code and JetBrains extensions now show Eagle findings inline for Dockerfiles. Hovering over a FROM line surfaces the current reachability verdict from Eagle's base image database.

Deprecated

• The legacy SARIF exporter introduced its removal in Q1 2026. As of Q4 it emits a deprecation warning and will fail closed on Q1 2026 runners.
• The per-repo API token flow is fully removed. Installation-scoped tokens are required.
• The old sg runner (pre-3.0) is deprecated. The new runner ships alongside the old runner through Q1 2026 for staged migrations.

How does Griffin reachability work on the JVM and .NET?

Answer-first: Griffin builds a bytecode-level call graph from your entry points and walks it through the dependency graph the same way it does for Node, Python, and Go. The difference is that the JVM and .NET ecosystems are bytecode-heavy, which means Griffin can analyze dependencies without access to source. That turns out to be important in practice — most enterprise Java apps pull transitive dependencies that are distributed as JARs with no attached source, and the dynamic language analyzers we built before Q4 couldn't reason about them directly.

Three things to know if you're turning on Griffin 2.2 for a JVM project:

1. Dynamic dispatch is tracked. Griffin's JVM analyzer models interface and virtual calls correctly, which means Spring and Jakarta frameworks don't cause false "unreachable" verdicts.
2. Reflection is flagged. Any reflective call site that could reach a vulnerable symbol is surfaced as an inferred edge, and Griffin tells you which reflective call it saw.
3. Shaded dependencies are handled. If a vendor has shaded a vulnerable library into their own namespace, Griffin finds it through bytecode signature matching, not package name.

What are Eagle attestations and what do they change?

Eagle attestations are signed statements that bind an image digest to a scan verdict. Every Eagle run now produces one. The practical effect is that a downstream verifier — whether it's an admission controller, a deploy gate, or a compliance auditor — can confirm that a specific image passed a specific policy at a specific point in time, without calling back to Safeguard.

The attestations use in-toto v1 statements with a custom predicate that includes the policy version, the scan timestamp, the Eagle engine version, and the verdict. Signatures are Sigstore by default; enterprise customers can bring a KMS key instead. The attestations can be stored alongside the image in a registry that supports referrers (most do now), and Safeguard's own admission controller verifies them at deploy time.

This is the missing piece for a full supply-chain attestation chain. Griffin already produced attestations for source scans. Eagle now produces them for images. Lino's runtime attestations land in Q1 2026. At that point the full chain from source to runtime is signed and verifiable.

What does policy-aware remediation look like in Gold?

Gold used to open remediation PRs against the most obvious fix — usually the latest patch-level bump that cleared the finding. That worked for most teams, but it ignored the house rules every team actually has. Q4's policy-aware remediation changes that.

A Gold policy can now express things like:

• "Never bump react past the current major without human approval."
• "For any package on the deny list, open an advisory PR and page the on-call, don't auto-merge."
• "For allowlisted packages, even an auto-mergeable patch requires a comment from a second reviewer."

Gold reads the policy, picks the highest-ranked remediation that satisfies it, and annotates the PR with the decision. If no remediation satisfies the policy, Gold opens an advisory PR instead and tags the finding as "blocked by policy" so it doesn't sit in a queue waiting for a fix that can't happen.

How did the runner change in 3.0?

Runner 3.0 is a rewrite focused on three things: size, cold-start time, and plugin isolation. The old runner pulled a bundle of detector binaries at install time, which made it large and brittle. The new runner ships as a single static binary and pulls detectors on demand, with each detector running in its own sandbox.

The net effect:

• Size: about 30 percent smaller on disk.
• Cold start: under a second on warm hosts, roughly 3 seconds on cold hosts.
• Plugin ABI: a new stable ABI means third-party detectors can ship without being recompiled against each runner release.

The rewrite also lets the runner act as an MCP server endpoint directly, which is what powers air-gapped MCP deployments.

How Safeguard.sh Helps

The net effect of Q4 2025 is a platform that produces signed, verifiable verdicts across the full stack — source, image, runtime — and acts on them without forcing your team to live inside a security tool. Griffin reasons about reachability across five languages now. Eagle puts a cryptographic signature on every image verdict. Lino confirms or denies the static picture for Kubernetes and serverless workloads. Gold turns verdicts into PRs that respect your policies. The MCP server, the workflows, the runner, the desktop app, and the IDE extensions are all surfaces over the same verdicts. Q4 was the quarter we finished the core platform; Q1 2026 is the quarter we start building on top of it.

What's next

Q1 2026 is shaping up around three themes:

• Verifiable runtime. Lino runtime attestations that close the signed chain from source to running workload.
• Self-healing everywhere. Self-healing workflows that remediate without a human in the loop for low-risk classes of finding, within policy.
• Less scan, more signal. Griffin and Eagle sharing cache state so a monorepo scan doesn't rescan what hasn't changed.

If any of these would unblock you, reach out at contact@hsxtechnologies.com.