Building SysWarden v5.
Earning your trust.

The numbers, with their boundaries.

I took a repository snapshot on October 21 at 07:00 UTC, or 09:00 in Brussels. My baseline is the first v5 scope pull request, #316, opened on October 12. I counted merged work across the repository during that interval, including the maintenance that keeps development possible.

Merged pull requests

109Repository work during the campaign window.

Commits on main

109The corresponding integrated history, not an additional 109 changes.

V5 milestone issues

32Issue tickets, excluding pull requests. All remain open at this snapshot.

Dependency updates

12Included in the 109 merged PRs, not added to the total.

Of the merged PRs, 86 are attached to the v5.00.0 milestone. The broader total also includes supporting work outside that milestone. GitHub displays issues and pull requests together in some milestone totals; I have separated them here so that a merged PR cannot be mistaken for a closed product requirement.

The 32 issue tickets include roadmap items created before the implementation campaign. They are the scope still being tracked, not 32 newly reported defects or 32 completed features. Keeping a work package open while several implementation slices land is deliberate: I close the requirement when the integrated result meets its acceptance criteria.

The visible implementation history covers almost nine calendar days. That is elapsed time, including nights and waiting periods, not a count of personal working hours. I am publishing the calendar duration rather than estimating hours from commits or CI runs. Analysis, design, review, documentation and recovery planning also matter to progress, even when they do not produce a commit immediately.

A shared language for evidence and decisions.

The first major investment is a common foundation for the command line, TUI, real-time alerts and future dashboard. If these interfaces disagree about what an event means, a polished screen will only make an inconsistent system easier to misunderstand.

I have integrated versioned contracts for events, node identities, observations, policy decisions, action outcomes and evidence. They keep important distinctions visible. Seeing an event is different from deciding to act. Recording an action is different from proving that the intended control is effective now. A previously valid observation can become stale without the underlying machine having disappeared.

The journal work adds bounded storage, authenticated checkpoints, continuity checks and explicit recovery. I want the system to retain a verifiable history without allowing an unbounded stream of events to consume the host. Recovery needs to account for missing or interrupted state rather than silently invent a clean history.

The local authority components have also received substantial attention: authenticated clients, fixed resources, protected launch inputs, privilege boundaries and bounded process supervision. These controls are designed to reduce the opportunity for an ordinary local user to substitute a file, impersonate a component or make forged data look authoritative.

None of this makes vulnerabilities impossible. It makes the assumptions narrower, the rejection paths testable and the remaining limitations easier to explain. The versioned v5 engineering index links the contracts and their implementation boundaries.

The dashboard must help me operate a fleet responsibly.

The internal fleet dashboard is one of the most visible additions in the roadmap. I want a fast, restrained interface that follows the SysWarden visual identity completely: readable tables, clear charts, useful drill-downs and indicators that can be exported and explained. It must remain lightweight enough to operate with realistic resources.

Several underlying contracts are already integrated: authorized fleet selections, node state, exposure classification, integration presence and percentage-based KPI populations. The finished browser interface, end-to-end enrollment and operational configuration deployment remain work to deliver.

I want KPIs expressed as rates with explicit populations. A figure such as 95% is useful only when I can see what was eligible, what was observed, which time window applies and what is missing. An unreachable node must not quietly disappear from a denominator to improve the appearance of a chart. Unknown and stale data need their own honest representation.

The planned External tab includes a 2D world map for the exposed fleet, with authorized location, address and state information. The Internal tab covers the internal or on-premise view. I am keeping network exposure separate from hosting location: an on-premise server can be publicly exposed, and a cloud server can be private. Classification requires an explicit administrative decision rather than a guess from its address.

The map is a navigation aid, not proof of where an attacker or server physically is. Precise internal topology and addresses must remain within the viewer's authorized scope. A dedicated BunkerWeb tab is planned when the selected servers use that integration.

For enrollment, the proposed architecture uses an optional node-initiated connection, individual credentials, mutual TLS and an independently approved membership registry. Credential binding and registry validation components have landed. A working full enrollment service is still ahead. A node certificate proves an authorized identity relationship; it does not prove that a compromised node is reporting the truth.

Finally, the 500-server figure is a capacity target to test by simulation, with the existing machines used for native verification. It does not mean renting 500 servers or asking donors to fund a new estate. I want evidence about scaling before I make a supported-capacity claim.

Fleet configuration needs more than an Edit button.

I have expanded the dashboard scope to include controlled administration of the fleet's TOML configuration. That changes the risk considerably. A bad local setting can affect one machine; a mistaken fleet operation can distribute the same problem everywhere.

The design therefore separates the four roles below. It also separates the ability to read, propose, approve and apply a change. The requirements are now recorded in the dashboard work package; the complete workflow is not implemented yet.

Typed forms and an advanced TOML editor must use the same versioned validation rules. I want schema validation, semantic checks and a reviewable diff before a change reaches a machine. Approval must bind the exact content, target servers and configuration revisions. If a local administrator or Ansible changes a file after approval, that approval must not silently authorize a different operation.

Deployment should proceed through small canary groups before broader waves. The interface must distinguish a configuration saved on disk, a change applied by a component and a behavior verified at runtime. A green tick cannot collapse those three stages into one.

I also require a bounded rollback path that preserves later administrator edits and unrelated protections. Secrets should be represented through controlled references and redacted views, not copied into the browser, exported reports or audit trails. Username/password access with OTP, alongside passkeys and compatible hardware security keys, belongs in the MFA design, together with recovery and revocation. Strong authentication must complement authorization and independent approval, not replace them.

A new TUI and alerts that explain their meaning.

I am coordinating the TUI redesign with the real-time L2-L7 alert redesign. The goal is a coherent visual language and navigation model, with details available when an operator needs to investigate.

I want the TUI's treatment of unknown-IP L4 and L7 alerts to remain precise within that broader alerting model. An unfamiliar address is a signal for context and assessment. It is not, by itself, a confirmed attack or proof that a block was enforced. Severity, evidence, policy decisions and action outcomes should be distinguishable on screen.

This is also why accessibility, keyboard navigation, constrained terminal sizes and clear stale-state indicators belong in the acceptance criteria. A security interface has to remain useful during an incident, when attention is limited and the information may be incomplete. These redesigns are planned consumers of the shared foundations, not finished screens I am presenting as shipped.

SSH hardening should respect the machine it reaches.

One of the most detailed workstreams is the move towards a dedicated policy file at /etc/ssh/sshd_config.d/00-syswarden-hardening.conf. A separate file is a useful ownership boundary, but writing that file is only the beginning. OpenSSH include order, effective settings, vendor policy and administrator-managed configuration all influence the result.

I have integrated protected configuration inventory, migration planning, verification with the installed SSH daemon, durable transaction preparation, publication and recovery components. Explicit TOML selection is now bound to the plan. Independent port observation avoids confusing the ability to inspect SSH with consent to harden it.

The difficult cases matter: a machine managed by Ansible, a bastion role, vendor crypto policy, conditional SSH rules or a partially interrupted migration. I want SysWarden to preserve the administrator's intended behavior and refuse ambiguous ownership, rather than overwrite a configuration because it happens to resemble a known template.

As of this article's snapshot, the complete native SSH migration is not ready for a package-testing invitation. Activation, proof of the loaded configuration, new authenticated access, update handling and the full native lifecycle still need integrated evidence. A successful parser check cannot prove that a fresh administrator connection will work.

The planned path is inspection, an explicit operator choice, a reviewable change, verified application and a recovery route. I will announce a specific buildable candidate when that full path is ready for controlled migration testing.

Installing a package should mean choosing a clear baseline.

Community feedback has helped sharpen a product decision: installing SysWarden should not silently mean consenting to a broad transformation of the host. I have recorded the new requirement in issue #422.

For a fresh v5 native APK, DEB or RPM installation, the target is the standard Data-Shield blocklist profile and the infrastructure needed to verify, apply, update and persist it. SSH, CIS and general OS hardening must require separate, explicit TOML choices. Optional modules and integrations also need an inventory and deliberate activation; they cannot be hidden behind the phrase "standard installation."

This is planned v5 behavior, not a description of the existing v4.10.4 installer. The dedicated SSH work is part of making an opted-in path safe. It does not justify enabling that path by default.

Upgrades need different treatment from fresh installs. Existing administrator configuration and protections must be preserved. I will not treat a historical generated default as new consent, or remove an existing hardening policy simply because the next release has a more conservative installation profile.

Compatibility includes keeping other protections intact.

The merged work also includes firewalld and container-forwarding corrections, more careful HA ownership and recovery, bounded LXC compatibility checks, authorized log producers and process-log retention. These are concrete engineering areas in the public history. They do not establish support for every combination of kernel, container manager and distribution.

For BunkerWeb, I am preserving an independent integration contract. The API, temporary bans, source ownership, expiry and HA behavior must keep working without the future dashboard. A central interface must not become a mandatory dependency for existing local protection.

The regression work checks the difference between removing a source entry, publishing the resulting list, refreshing a partner cache and applying it in a serving worker. Those are separate stages. Component checks cover publication and cache behavior; full scheduler, worker and HTTP acceptance still require native evidence. The public withdrawal regression contract explains that boundary.

I apply the same care to removal. syswarden uninstall, native package removal and purge must be checked independently. I want SysWarden-owned state removed, while unrelated firewall rules, services, configuration and effective protection remain intact. A package manager returning success is not enough evidence that this outcome was achieved.

A community request starts an engineering decision.

I value suggestions from people who install, operate and challenge SysWarden. They reveal needs that a clean development environment cannot fully represent. Taking them seriously means giving them a disciplined route into the product.

I start by clarifying the operational objective. Then I study feasibility and dependencies: which platforms are involved, who owns the configuration, what privileges are needed and how the feature will behave alongside existing tools. I assess the security and availability risks, choose treatments, and define how the result can be verified.

After implementation and testing, I still need to evaluate the residual risk. Some risks can be reduced; others need an explicit limitation, a deployment condition or an accountable acceptance decision. A merge is not automatic acceptance of every consequence. A request may need to be narrowed, deferred or rejected if the proposed implementation would weaken the product or make its lifecycle unmanageable.

What still stands between the code and v5.00.0.

The roadmap goes beyond the current foundations. File-integrity baselines and reconciliation, deterministic incident timelines, approved reversible responses, signed playbooks, evidence capsules with offline verification and additional detection coverage remain part of the tracked work. Optional audit-only eBPF observation needs its own feasibility and risk decisions. Custom feed handling and release supply-chain work also have explicit requirements.

I am not presenting this list as completed functionality. Some requirements now have substantial reusable components; others remain designs or acceptance work. The full dashboard, redesigned interfaces and integrated native package behavior still have to meet one another in an actual product.

For v5.00.0, the governing contract is Integration, Verification, Validation and Qualification: IVVQ. Component tests, static analysis and native scenarios contribute evidence. Final acceptance concerns the exact candidate, its delivery chain, migrations, recovery, security behavior, documentation and supported operating conditions together.

Intermediate minor and patch releases follow IVV. The Kubernetes work has been assigned to v5.01.0, with its own scope and feasibility work. It is not a Kubernetes edition already delivered by v5.00.0. The current supported architecture remains Linux AMD64/x86_64.

I also maintain the delivery machinery: dependency review, security analysis, package building, provenance checks and compliance controls. Those 12 dependency PRs belong in the progress picture because security software depends on the integrity of the tools used to build and assess it. Their green status is a gate, not a guarantee of an absence of defects.

More than EUR 946 a month, before the next ambition.

I currently carry more than EUR 946 in carefully managed monthly expenses to sustain this work. These recurring costs are the practical baseline I have to sustain while development and maintenance continue. They make the question of continuity very concrete.

The visible output is free to inspect. The activity behind it still needs resources: maintaining the solution, investigating changes, operating the necessary infrastructure, preserving recovery paths, reviewing dependencies and repeating tests after a correction. When a feature grows more capable, the obligation to support it grows too.

Donations help me protect the time and resources for that maintenance. They also help make independent scrutiny possible. I want support to follow engineering priorities: keep the existing solution maintained, finish the integration work carefully, and fund external assessment and the corrective work that follows it.

I am asking for broad support because a sustainable base of small contributions can make a meaningful difference to an independent project. It gives me more room to plan maintenance, finish difficult integration work and arrange the outside assessment the product deserves.

I want an independent challenge before I claim more.

One of the next steps I want to finance is an independent product pentest and prequalification exercise through Mattéo Bezet-Torres. This is a planned initiative that still needs funding. It is not an agreed engagement, a completed audit, a certification or an endorsement.

The scope, availability, delivery arrangements and acceptance criteria will need to be agreed before any assessment begins. My objective is to give a third party a concrete candidate and an explicit threat model to challenge, including privilege boundaries, configuration changes, identity, recovery and the trust placed in observations.

A useful assessment must leave room for findings and retesting. I want to budget for understanding the results, fixing confirmed weaknesses, reviewing the residual risks and verifying the corrections. Paying for a report without funding that follow-up would leave the most important work unfinished.

As a CISO, I want this distinction to remain visible: external scrutiny can improve assurance within an agreed scope. It cannot certify that unknown vulnerabilities will never exist. My responsibility is to make the evidence and its limits intelligible, and to keep maintaining the product after the assessment.

Independence is an operating choice.

When I describe the direction of SysWarden as sovereign, I mean practical technological independence: the ability to inspect the software, understand its dependencies, operate it on infrastructure under your control and recover without surrendering those decisions to a mandatory external service.

Open source still has dependencies, maintainers and a supply chain. Independence requires managing those relationships, documenting boundaries and keeping a realistic exit or recovery route. It is something I have to build and maintain, not an adjective I can add to a release page.

I believe v5 can be a major step forward. The value will come from the combination of a useful operator experience, defensible architecture and verified behavior. Donations help sustain the work needed to make those three fit together.

The next contribution can also be a careful question.

If you cannot donate, a reproducible test, a thoughtful code review, a documentation improvement or a useful question can still help. Please use a test environment for development candidates and keep credentials and private operational evidence out of public reports.

I will keep linking implementation work to its acceptance requirements, publishing the boundaries of what is ready and explaining what remains. You can follow the v5.00.0 milestone, read the operator documentation and join the community conversation.

I am proud of the progress already made. I want the next milestone to deserve that same confidence in use, during an upgrade and when something goes wrong. If that is the kind of independent security software you want to see continue, thank you for helping me sustain it.