Linux fleet security
Your fleet. Your rules.
Under control.
Find exploitable vulnerabilities. Harden Linux configurations. Review the changes that matter, with the evidence ready for your next audit.
5 hosts free · No credit card · No kernel modules
- 01See what changed
- 02Review what needs you
- 03Track the result
Across your Linux estate
Ubuntu · Debian · RHEL · AlmaLinux · Rocky Linux · SUSE · Amazon Linux
From finding to verified change
Less noise. A clear next action.
Start with the fleet. Narrow the findings. Review a fix. Keep a record of what changed.
Exploit context. Not just another CVSS list.
See which findings have public exploit code or offensive tooling, then identify the package version that closes the vulnerability.
- Kernel and userspace CVE inventory
- Exploit-aware filtering
- Fixed package versions in context
| Package | Exploit context | Next action |
|---|---|---|
| openssl | Public exploit | Review update |
| linux-image | Offensive tooling | Review fixed version |
| curl | No exploit signal shown | Assess priority |
Keep the administrator in the decision.
Review failed CIS controls and proposed fixes. Breaking-risk labels flag changes that could disrupt access before you apply them.
- Review the proposed change
- Check breaking-risk warnings
- Apply and verify the result
- Failed control identifiedConfiguration finding on db-prod-02
- Review risk before applyingRisky controls carry a Breaking Risk label
- Apply, verify, recordThe administrator initiates the change
Answer “when was this fixed?” with evidence.
Bring vulnerability and compliance reporting into the same workflow, with tamper-evident history and summaries based on scan data.
- CIS and PCI reports
- PDF, CSV and XLS reporting
- REST API and MCP access
- Finding capturedScan identifies a failed control
- Remediation recordedChange history preserves the action
- Evidence ready to exportCompliance and vulnerability reports
Next release · Built for production reality
Patch the host. Respect the containers.
Container hosts need a different patching decision. The upcoming release holds back kernel and container-engine updates from automatic rules and updates across systems.
Other updates can continue. An administrator can explicitly approve a held-back update on one system after a warning.
Continue under the enabled update rule.
Rule-based updatesHold back. Warn before a manual update on this host.
Explicit admin choiceDetection uncertain? Treat the host as running containers.
01 / Problems & investigation
Connect the error to the change.
Correlate journald, apt and dnf problems with preceding package, kernel, service or configuration changes. AI proposes investigation steps; a person reviews and applies fixes.
02 / Groups & schedules
Staging tonight. Production Sunday.
Group systems by environment or role. Set schedules per group and rule, in the administrator’s time zone. All autonomous rules start off.
Illustrative schedule; groups have independent rules, not an automatic promotion pipeline.
One workspace. Three ways to act.
From fleet operations to the underlying risk.
Move between Autonomous Security, Linux Patch Management and Linux Compliance, with a clear starting point for each job.
Start with five hosts. See what needs attention.
Get a view of vulnerabilities and hardening findings across your Linux estate.
First five hosts free. Next-release items are previews.

