BEDIM SECURITY

Capabilities.

Bedim Security runs a complete security operations capability as one autonomous system — a Wazuh sensor fabric, an agentic AI analyst, machine-speed DISA STIG compliance, and hardened infrastructure. It runs continuously on our own estate, and every claim on this page is backed by a live screenshot or an unedited recording from that environment.

The premise

Most security programs buy a SIEM and staff it. We built the inverse: a small, fully open-source stack in which software does the watching, the triage, and the checking — while a human sets policy and reviews the exceptions. The estate it defends is real: Proxmox VE clusters, Linux and Windows hosts, mail and web services, lab targets. The result is a security operation that exercises itself every day and keeps the evidence to prove it.

17devices enrolled
1.04M+alerts indexed
24STIG platforms
31/31health checks green

Sensor fabric — Wazuh

Every machine in the estate runs a Wazuh agent feeding a central manager over an encrypted channel. Log data, file integrity monitoring, vulnerability detection, and Security Configuration Assessment stream into the indexer — currently holding more than 1,040,000 alerts from a fleet spanning Linux, Windows, and macOS, bare metal to containers.

Wazuh dashboard overview showing agent fleet status and environment posture
The Wazuh dashboard: fleet overview and environment posture at a glance.
Wazuh alert explorer showing indexed alert table with 819,951 events
The alert explorer. Every event is queryable — 819,951 alerts indexed at capture time.

Configuration compliance is measured, not assumed: the Security Configuration Assessment engine runs DISA-mapped policies per platform — Ubuntu, RHEL 9, Windows, vSphere, Proxmox VE — and feeds those scores straight into the compliance pipeline.

The analyst — agentic AI on duty

Alerts don’t keep business hours, and neither does the analyst. Our SOC runs six registered specialist agents under a single coordinator — alert triage, IOC enrichment, incident review, report narration, reply drafting, and communications. Findings become tasks; tasks become remediations; remediations become evidence.

SOC dashboard showing live sessions, alert flow, compliance scores and the task board
The SOC dashboard: live sessions, alert flow, compliance scores, and the task board in one view.

The task board tracks every automated scan, remediation ticket, and accepted-risk exception — 100+ records, each with an owner, a finding reference, and a resolution path. An append-only audit log ships off-host every five minutes.

Every alert decided in-house — the Laya decision engine

Alert dispositions used to ride on a language-model call per alert: a 90-second ceiling, 65 percent of decisions hitting it, and a 21-second median on the calls that did land. That path is retired. Each alert now passes a deterministic gate on the SOC host and receives exactly one local inference from Laya, our typed-decision model — bound to loopback, so nothing about the alert stream leaves the machine. Median decision: 1.1 seconds. P95: 1.6 seconds. The same alert always receives the same disposition, and every decision lands in the audit log with its duration and outcome attached — measured over the live decision log, not a benchmark.

21s → 1.1smedian decision latency
65% → 0decisions hitting the 90s ceiling
0remote calls in the alert path
$0per-alert model spend

The gate changed what reaches a human, too. Noise-class alerts fold into the daily digest instead of firing a narration turn each — the last 150 consecutive dispositions were digest-only, and the per-alert email flood that used to cost a model turn per alert is gone. Genuine escalations still page, still open tickets, and still get the full agentic stack behind them.

The full engineering record is published: the Laya 300 status & power report (measured: −74% GPU energy, 16× decision latency, 94.6% agreement over a 452-decision soak), the practical usage guide, and the setup & validation demo guide. A second-host replication run (2026-09-28) is documented in the eval-host comparison report: same 300-state eval on a Ryzen 7 7800X3D — 1.6× faster, 100% identical answers, −20% energy per decision.

All Laya reports, guides, and the control-plane repo are indexed at laya/.

Local by default, cloud on reserve

The model inventory lives on the SOC host — Qwen, Llama, Gemma, Mistral, and a local embedding model — so the SOC’s routine management runs on hardware we own, and the alert path keeps deciding even if the internet doesn’t. Standing cloud access is configured but dormant: when a job genuinely needs more agentic power — a deep investigation, a large-context analysis — the coordinator escalates that one task to hosted models and pays only for what runs. Reserve, not baseline: nothing in the alert path dials out, and losing the cloud link parks the optional bursts, not the decisions.

A note on the name. Executive Order 14434 (“Inaugurating the Era of Super Intelligence,” September 29, 2026) directs federal agencies to write “Super Intelligence” and “SI” in place of “Artificial Intelligence” and “AI” — and defines SI as the same technologies the existing statutory “artificial intelligence” definition already covers. That is a renaming of vocabulary, not a change in capability. Our work stays what it is: agentic automation for security operations — measurable, deterministic, and logged, a different realm from what “super intelligence” implies. The full text: Executive Order 14434 at the White House, and the Federal Register notice of October 2.

Compliance at machine speed — stig-baselines

stig-baselines is our open-source DISA STIG engine: checklists (CKL) generated from vendor XCCDF for 22 platforms, live OpenSCAP evaluation of running systems, bulk CSV dispositions applied in seconds, and multi-STIG merges into a single checklist. The same engine scores compliance continuously against NIST 800-53 families.

Live OpenSCAP evaluation → populated DISA CKL

An actual OpenSCAP STIG scan of a Rocky 9 VM, converted to a fully populated DISA checklist — executed autonomously, unedited.

Recording: gist 23d66481 · tooling: stig-baselines

Bulk dispositions & multi-STIG merge

Eight CSV dispositions applied into a DISA RHEL9 checklist, then a second STIG merged into one multi-STIG checklist — the assessment workflow end to end.

Recording: gist e355b12d · tooling: stig-baselines (csv2ckl, merge_ckl)

Hardened infrastructure — Proxmox VE

The same discipline applies to the hypervisor layer. The PVE-STIG kit ships an assessment scanner, a dry-run remediation tool, a governed exception mechanism, and continuous SCA auditing of cluster nodes. High availability is exercised, not asserted: when a node dies, the cluster fences it and relocates the workload — recorded live.

Automated PVE-STIG hardening

A real run on a Proxmox VE 9.2.20 cluster node — baseline scan, dry-run, remediation, idempotency verification, and the post-hardening scan.

Recording: gist 7ee7c4b1 · tooling: stig-baselines (baselines/proxmox)

Live HA failover

A cluster node is killed. The cluster detects the loss, fences the node, relocates the workload, and moves it back after the node rejoins.

Recording: gist 80c10e27 · build & HA guide: stig-baselines (docs/proxmox)

Patch & exposure watch — what needs attention, and when

The newest member of the platform joins three sources into one standing report: the vulnerability detector’s live findings tracked against installed software and hardware (92,556 findings indexed at publish), the Wazuh agent enrollment state, and a per-device sweep for pending operating-system updates. It runs on a fixed schedule (06:20 UTC) and the operations console re-reads the same report on every load — no cache to go stale.

The point is not a wall of data. The report identifies what and when attention is needed: this morning’s automatic run flagged 205 pending package updates across 17 enrolled devices (34 security-classified), put one host on a reboot-required list, and aged every open finding — how long since a device was last patched, since a finding was first seen. Ages make drift impossible to miss, and a dated history line per device per run is written to evidence storage, so the patch-age trend builds over time.

The patches and updates console showing per-device pending updates, upgrade ages, reboot flags and vulnerability counts
The patches & updates console — the 2026-10-06 run as rendered; endpoint names anonymized to role labels for publication; the live console operates under real names, per device.

Live tooling — KEV × STIG coverage checker

A live routing table between CISA's known-exploited vulnerabilities catalog and the DISA STIG baselines we maintain — per-CVE checks, a platform scoreboard, and the honest uncovered gap, with a public API. Refreshed daily by an automated job. Open the checker.

Out-of-band SOC — two machines no one can reach

The operations center itself, rebuilt out of band: two VMs — Rocky Linux 9.8 and Ubuntu 24.04 — on the lab bridge that boot with no NAT device and no default route: zero internet path, by design. Cloud-init seeds install the Wazuh agent on first boot; both agents enroll on their own and report to a dedicated wazuh-manager 4.14.8 container on its own bridge IP, and its findings land on the store disk.

Everything the build consumes is gathered, sha256-verified, and served from a storage container on the same bridge first — the OS media (645,988,352 and 625,612,288 bytes, verified), the agent packages (11,151,656 and 13,227,800 bytes, verified), and the signing key. The full procedure is published as two gists: stage 1 — the store + serving container, stage 2 — the VMs + the manager.

The proof

Everything you just read runs on open source. stig-baselines, soc-openclaw, laya-control (the Laya decision engine and its control plane), wazuh-stack (the Wazuh deployment), and agentic-ai document the stack end to end. For capability statements, teaming inquiries, or a live walkthrough, reach out below.

Contact

For contracting and capability inquiries: