Published code
Open source
A security tool you cannot inspect is a security tool you do not control.
We publish aartool, our Linux hardening toolkit, under GPL-3.0: audit it, modify it, deploy it in your own infrastructure. AarSOC itself is built exclusively on open-source components.
v3.5.3 | audit, plan, apply, prove Plan for web-01 · score 62/100 ── Wave 1 · Reachable from the network, no account needed FAIL SSH-01 Root login permitted FAIL NET-01 No host firewall active [needs a decision] WARN SYS-11 Newest installed kernel not running preview aartool plan --target web-01 --only firewall,ssh apply aartool apply --target web-01 --only firewall,ssh ── Decide before you apply NET-01 No host firewall active aartool explain NET-01
Output of aartool advise on an example host. Waves are ordered by reachability: what an attacker reaches with no account at all, then what turns an account into root, then what would have stopped you noticing either.
The whole loop, on a real machine
Recorded on an ordinary laptop, not a prepared host: audit, ordered plan, what one fix costs, the kernel doorways, and the anonymised HTML you send a client. The score is what that machine actually scored.
aartool
Audit a Linux host, get an ordered plan, apply the fix, prove what changed
sudo aartool inspect # 109 checks. Changes nothing. aartool advise # what to fix first, and what each fix costs aartool explain KRN-01 # why it matters, and what closing it breaks aartool apply --target web-01 --user ubuntu --only ssh aartool diff before.json after.json
Most scanners produce a list. aartool produces an order, and for every recommendation it states what that recommendation breaks.
Closing unprivileged user namespaces neutralises an entire class of local privilege escalation. It also breaks rootless Docker, Chrome's sandbox and most CI runners. aartool says so before you apply it, because a tool that argues only one side gets switched off, and then none of its advice applies at all.
Validated on a real estate
Continuous integration does not prove a tool works on a real machine, only that it works on the machine running the tests. Every release is exercised against live servers before it ships.
- + 15 nodes audited through a bastion, 15 of 15 succeeded. That run found a defect on the estate itself: a Jinja whitespace rule had collapsed the entire monitoring block of /etc/hosts onto one physical line, on every node, for months, with nothing reporting it.
- + Hardening applied end to end to a documentation server in service: score 72 to 75, three findings cleared, nothing regressed and the service up throughout.
- + That single run found four defects in aartool that no test had caught, including a check that could never pass on any host and a check whose own remediation wrote a value the check rejected.
Systems covered
RHEL 9, Ubuntu 22.04/24.04, Debian 12
Checks audited
109 checks across 9 families
Ansible roles
52 independent, composable roles
Remote estates
Audits through a bastion, no agent to install
Report
Self-contained HTML and JSON, browsable offline
Drift detection
Exit code built for a scheduled job
Licence
GPL-3.0: free reuse, modifications publishable
The HTML report opens with no server and no network, which makes it usable on an air-gapped estate. The JSON export drops into your pipelines, and aartool diff exits non-zero as soon as a check regresses: a weekly audit that stays silent until something moves is one you are still reading six months later.
What else we publish
The principle is simple: whatever strengthens the ecosystem without exposing a client gets published.
Sigma detection rules
Aligned with MITRE ATT&CK, verified against real data, portable to the main correlation engines.
Research
Published as soon as it generalises. Our own incidents and post-mortems are already online.
Read our publications →Contribute
Fixes, roles for new distributions and missing checks are all welcome.
Fork and clone
Create a branch whose name describes the change.
Test locally
Roles are tested with Molecule, the scripts with the guard suite in the repository.
Open a PR
Describe the change, the systems you tested on, and the CIS controls affected.
One house rule, if you add a guard: prove it fails. Break the thing on purpose, watch the test go red, then put it back. Every test in the repository was written after the defect it describes was found in shipped code.