v4.10.0 is here.
Stronger defense.
Shared progress.

01 / THE RELEASE

Yes, this one is out.

Today, October 1, 2026, SysWarden v4.10.0 is officially available. The stable release is public, the tag is signed, the Linux packages are signed, and the evidence behind the release decision is available for inspection. After weeks of development, testing, corrections and another careful look at the results, it feels good to write that sentence.

This release strengthens the parts of a security solution that matter when you actually operate it: how two nodes trust each other, how a threat feed earns its place in a firewall decision, how an alert explains what happened, and how you establish where an installed package came from.

There is a human story here too. I am delighted to welcome Ines Wallon and André Marrec as SysWarden ambassadors. André was the very first user to test SysWarden at the beginning of the adventure. He deserves a particular place in this announcement, and I will come back to that.

Start with the official release and the dated publication record. The latter documents the completed release decision; the frozen changelog retains its original development wording.

02 / THE FOUNDATION

Linux defense that stays close to the host.

If you are discovering SysWarden today, here is the starting point. It is an open-source Linux security orchestrator that combines host telemetry, security-log analysis, threat-intelligence lists, operator policy and enforcement through nftables. A local command-line interface and terminal dashboard let you inspect what the system is doing.

The design keeps security decisions close to the protected host. Supported upstream services can provide logs for out-of-band WAAP analysis, and the optional BunkerWeb integration connects web-security events with host defense. SysWarden does not sit in the HTTP request path as another reverse proxy. That architectural boundary remains clear in v4.10.0.

The goal is practical: give operators a coherent defense layer whose decisions, ownership and recovery procedures they can understand. The architecture guide explains the model, while the new release develops several of its most demanding operational pieces.

03 / HIGH AVAILABILITY

HA with explicit trust and ownership.

Authenticated HA v2 introduces a two-node writer and standby model with explicit cluster, node, peer and epoch identities. Replication uses TLS 1.3 mutual authentication. Durable journals, heartbeats, acknowledgements, checkpoints and deterministic resynchronization give the nodes a defined way to exchange and recover state.

Those details answer very ordinary operational questions. What happens when a response is lost? When a node restarts halfway through an operation? When connectivity becomes asymmetric? When an old peer returns with state that has already expired? The implementation includes replay handling, tombstones and rejoin controls so that recovery follows the recorded state and its ownership.

Ambiguous or concurrent writers are fenced. A stale peer must not resurrect a removed block, and cleanup of a replicated claim must preserve an independent local claim. These are the kinds of situations that deserve attention before the incident, while everyone still has time to think.

BunkerWeb cooperation, with clear boundaries.

The BunkerWeb integration has received particular attention around restart, expiry, scheduler identity and replicated state. A healthy writer advertises mutation capability; a standby keeps the provenance limitations of its projected state explicit. Scheduler authority remains separate from HA peer authority.

There is an important deployment detail here: the pinned BunkerWeb plugin is not HA-role-aware. A setup that sends ban pushes to two endpoints therefore needs the documented active-drained fence manifest. Otherwise, expose only the writer or disable ban push. The integration documentation is the place to check applicability before changing a live topology.

Operator policy also gains typed inbound TCP and UDP allow rules, each with a canonical destination port, alongside the existing ICMP and ICMPv6 contract. The policy compiler keeps protocol, family and rule ordering explicit. For the person maintaining access rules, that means a more precise way to express an intended exception.

04 / THREAT INTELLIGENCE

A feed should come with a history.

Downloading an IP list is easy. Deciding whether it is suitable to influence enforcement requires more care. v4.10.0 records source identity, retrieval time, licence, size, checksums and normalization results for accepted snapshots. It distinguishes current, stale, unavailable and rejected states, and makes that provenance and freshness visible through syswarden audit.

Bounded, atomic publication preserves an attested last-known-good snapshot when a new input cannot be accepted. Persistent IPv4 and IPv6 blocklist files are created and attested during installation. If one subsequently disappears, the runtime treats that as a security-input problem instead of silently recreating trusted material.

Enrichment has its own boundary. Best-effort OSINT information can help an operator read the dashboard, but it remains display-only. It cannot determine severity or set a firewall action. A useful label on a screen and an authorized enforcement input have different responsibilities.

For a security team, this makes an investigation more concrete: which input was accepted, when was it retrieved, and what state was in use? Those are questions a product should help answer.

05 / DAILY OPERATIONS

A clearer view of what is happening.

The terminal dashboard and exported dashboard data now share a versioned evidence model. Admitted and rejected events, HITS, signature-backed severity, enforcement jail, policy action, evidence quality and the time window are represented consistently. This gives operators, security leads and governance teams a more dependable basis for discussing the same observation.

Telemetry is classified as online, degraded, stale or offline according to freshness, read errors and projection quality. Displayed data has bounded size, and untrusted terminal strings are constrained and escaped. A dashboard should tell you when its view is incomplete.

syswarden alerts starts at the current kernel and WAAP source boundary, so a live monitoring session does not replay historical events as if they had just happened. Source health, queue limits and follower-process cleanup are part of that lifecycle.

Notifications receive the same operational care. Teams, Slack and Discord webhooks use HTTPS-only targets, bounded payloads, idempotency keys, retries, rate-limit handling and backoff. Delivery state is explicit, including the uncertain case where cancellation happens after a request may already have started. Credential-bearing endpoints are redacted, and unsafe redirects are refused.

The value is easy to appreciate during an incident: fewer assumptions about freshness and delivery, more information about what the system actually observed.

06 / INSTALLATION AND RECOVERY

Native packages, with lifecycle work behind them.

The public release provides four signed package variants for supported AMD64 Linux hosts: DEB, standard RPM, package-owned RHELPO RPM and Alpine APK. Each package family has its own signing and trust controls. The DEB package includes a detached OpenPGP signature; RPM and APK use their respective native signature paths.

The separate RHEL 9+ package-owned profile is intended for a specific integration need. The RPM owns the systemd assets, presets and scriptlets while Go remains runtime-only. It supports explicit offline image integration through the documented transaction. It does not configure firewalld, change SELinux policy or assemble an image for you, and it is excluded from the standard updater path.

Recovery also gets a more deliberate interface. syswarden recover-wireguard handles two supported historical SysWarden nftables generations on systemd and OpenRC. A read-only plan comes first; applying it is a separate action bound to that exact plan's SHA-256 digest. An unknown or changed state stays blocked.

The release work also covers exact historical service-unit compatibility, failed-service reconciliation and package ownership during supported migrations. An explicit offline candidate-update path was added for protected native laboratories, binding the manifest, package, embedded CLI, installed package record and activated CLI. That laboratory path should not be confused with a general-purpose offline installation promise.

Choose the package and procedure that match your host. Start with the v4.10.0 getting-started guide, preserve console access and a recovery point, authenticate the download, then verify services, policy and access after installation.

07 / THE EVIDENCE

A release you can inspect.

v4.10.0 is an IVV-validated intermediate release. IVV means Integration, Verification and Validation. Our Upgrade generations, such as the planned v5.00.0 LTS, require the wider IVVQ process, which adds Qualification. These terms describe different levels of work and should stay precise when we talk about the product.

The protected IVV producer accepted all twelve required checks under the named release plan. The publication record identifies the tested product, publication commit and immutable signed tag, and explains which evidence was freshly produced and which earlier results were admitted through an explicit continuity assessment. A historical passing result remains tied to its original candidate.

The published inventory contains twelve files, including the four package variants, checksums, an SPDX software bill of materials, the Plumber report and signed update metadata. All twelve assets were downloaded again through their public URLs and checked against the validated inventory, with their GitHub build-provenance attestations verified.

I also signed the release checksum manifest with Sigstore. Its verification bundle and public transparency-log entry let others inspect the identity and integrity evidence. Native package signatures, the updater's Ed25519 signature and the Sigstore release-manifest signature are distinct checks, each with a defined role.

The publication and verification record links the original report, attestations, signature bundle and the documented publication recovery. It also states the limits of the native evidence, including the distinction between IPv4 traffic tests and IPv6 state checks.

Clean delivery is part of the work.

The applicable package, security and Plumber tag workflows passed. On the exact publication commit, Plumber reported A, 100/100, with no critical, high, medium or low findings in that report. As a Plumber ambassador, I am happy to show a concrete result from a tool I recommend. The dated workflow keeps the claim attached to the revision it assessed.

For a CISO, CIO or GRC team, the useful part is the ability to follow the decision: inspect the source, review the pipeline result, identify the package, and understand the release scope. A score contributes evidence about delivery; it does not certify an entire deployment. The release remains pinned to Go 1.26.6, with Go 1.27 evaluation kept in a separate lane.

I am proud of the outcome and of the discipline behind it. A mature security product can explain what it checked, what it corrected and what remains outside the claim. That is how I intend to keep building SysWarden.

08 / FIND YOUR WAY IN

The documentation has a proper home.

The official documentation now lives at syswarden.io/docs, with searchable guides, copyable commands, architecture diagrams and visible version context. The former wiki material is preserved there. Historical procedures keep their version boundaries, while the current getting-started guide points to the signed v4.10.0 release.

If you prefer to begin with a practical example, the educational defense scenarios walk through the relationship between a signal, a decision and an observable result. If you build from source, use the source-build guide and keep the exact revision explicit.

The official Discord community provides a place for discussion and support in French and English. Bring the version, a clear reproduction and anonymized logs when something needs investigation. Useful feedback gives us something concrete to improve together.

09 / THE PEOPLE

Welcome, Ines and André.

Today I am also very happy to announce two new SysWarden ambassadors: Ines Wallon and André Marrec.

For me, an ambassador helps a project build real conversations. That means introducing it to people who may find it useful, encouraging informed questions and keeping the connection between development and actual use alive. I want that relationship to stay open, constructive and comfortable with honest feedback.

Ines, thank you for becoming part of this journey. I am looking forward to the exchanges and the new connections we will build around SysWarden. There is plenty ahead of us, and I am very pleased to welcome you as an ambassador.

André, this milestone is yours too.

André was the first person to use and test SysWarden at the start of the adventure. Before today's release, before the documentation portal and before this announcement, he was already there, putting the solution to the test.

That early commitment means a great deal to me. When you create a security product, having someone willing to work with those first versions brings a responsibility: listen carefully, confront the reality of usage and make the next version better. André has been part of that process from the beginning.

Welcoming you as an ambassador feels like a natural continuation of that story. The release carries a version number. Behind it are people who have given the project their time and trust. I want that to remain visible.

10 / WHAT COMES NEXT

A milestone, and room to breathe.

The next major project is v5.00.0 LTS. Before that work begins in earnest, I am keeping a two-week interval after this release to consolidate the result, follow feedback and give the next phase the preparation it deserves. Existing v5 issues and dependency updates will be handled deliberately during that transition.

v5.00.0 belongs to our Upgrade track and will require full IVVQ. Its public roadmap is the place to follow planned work. Today's announcement celebrates what has shipped in v4.10.0; future work will earn its own results.

SysWarden remains independent and open source. Testing infrastructure, maintenance, documentation and careful delivery all take time and resources. If the project is useful to you, a reproducible report, a contribution, a thoughtful introduction or a donation helps sustain that work and its independence.

v4.10.0 is here. Welcome to Ines and André, and thank you to everyone who has helped us get this far. Download it, read the evidence, and tell us how it works for you.