The open-source ShakerScan engine, behind your identity provider, on your own servers.
Single sign-on through your OpenID Connect provider, passkeys and recovery codes, enforced roles, audit and an offline licence in front of the public engine, with recurring scans, retests that close findings on proof and Jira tickets. No telemetry or licence check-in; scan data stays on your host. Public beta, pilots open.
Pilots run on a time-boxed evaluation licence with the maintainers on the call; there is no self-service purchase.
One Linux host with Docker Engine and Compose 2.20+, x86_64 (linux/amd64 images).
Ubuntu 24.04 LTS
Recommended. Validated with the one-command installer, including reboot and backup.
Ubuntu 26.04
Validated in continuous operation.
AWS ECS (Fargate)
Reference deployment for evaluation; not a supported deployment.
Amazon EKS / Kubernetes
Reference manifests for evaluation; not a supported deployment.
Roles come from provider groups or per-person admission.
Okta
Group-to-role mapping and console test sign-in, with a setup guide.
Keycloak
Including deployments behind a private certificate authority.
Microsoft Entra ID
Console preset with group-ID claims; not yet verified against a live tenant.
Other OpenID Connect providers
S256 PKCE, RS256 or ES256 ID tokens, client_secret_basic or _post.
Google Workspace
Sign-in with per-person admission through the standard OpenID Connect setup; no group-to-role mapping.
Local accounts
Password, passkeys, authenticator app, recovery codes, invitations.
SCIM provisioning
Access is revoked by disabling the person in the console.
The gateway sits in front of the engine and authenticates and authorizes every request, so nobody reaches a scanner, a finding or a credential without signing in through your policy.
OpenID Connect with PKCE, verified with Okta and Keycloak; a Microsoft Entra ID preset exists but is not yet verified against a live tenant. Other providers need S256 PKCE and RS256 or ES256 ID tokens. Configure it in the console and run a test sign-in at the provider before saving; changes apply without a restart and are audited. Two-step verification for these accounts is your provider’s policy.
Local accounts sign in with a passkey (fingerprint, face or PIN; phishing-resistant and a second factor on its own) or a password plus authenticator-app codes. Ten single-use recovery codes replace a lost passkey or phone. The policy is yours: off, required for local administrators, or required for every local account.
People are admitted by exact subject or by mapping your identity-provider groups to a role on first sign-in. Nobody gets in by default. An administrator can require single sign-on and keep one break-glass local administrator.
Viewer reads results; operator runs scans, retests and Hunt; administrator manages people, tokens, settings and updates. Every request is checked against reviewed per-role allowlists, and unknown routes are refused.
Server-side sessions with short absolute and idle lifetimes set in the console; changing a role, password or factor ends that person’s sessions. Revealing a discovered secret, accepting Hunt-written guidance or dismissing findings needs fresh proof for that one decision: a passkey, an authenticator code or a fresh sign-in at your provider. So do the administrator changes that open a lasting way in: adding an administrator, inviting a person, issuing a service token or a reset code, and turning a sign-in protection down.
Scoped viewer or operator tokens for CI and agents, shown once, stored hashed, valid for at most 90 days and revocable. They cannot open the console. An administrator can require a security-key touch for the decisions only a person should make from a terminal, so an agent holding a person’s token cannot make them.
One-time invitation links (valid three days) where people choose their own password; disable and re-enable; one-time reset codes issued by an administrator; a break-glass local administrator next to single sign-on, and server-side recovery commands for the operator.
Sign-ins, administration, settings changes and every engine request (method and path, never bodies or secrets), with who and when. Filter in the console, export as NDJSON.
Recorded in September 2026 on Ubuntu 24.04 with gateway 0.2.0-beta.12 to beta.18 and engine 2.3; not yet re-measured on the current release.
~4 min
one command, clean Ubuntu 24.04 host
From published, signed artifacts to a running stack with the first administrator, a daily backup and the engine updater installed. Re-running it resumes an interrupted install.
7 checks
one verification command
Gateway signature, SBOM attestation and the build attestations of all five engine images, before anything is deployed. The installer runs it for you.
140 s
engine update from the console
From the administrator’s click to the new engine verified (2.3.6 to 2.3.9): backup, install, render, pull, restart, verify, with scans, evidence, identities and the licence intact.
You install two things on one Linux server: the open-source ShakerScan engine (public images, pinned by digest) and the Enterprise gateway (a private, signed image). The gateway handles login through your OpenID Connect provider, viewer, operator and administrator roles, an audit trail, and a signed licence that never phones home. Scans run on your host against your applications; findings and evidence stay there.
Outward, the host talks to your targets and your identity provider, and, at install and update time, to the image registries, GitHub and Sigstore; Let’s Encrypt too, unless you bring a certificate.
People
Browser, agent, CLI
Sign-in via your IdP
Your Linux host
Targets
Your applications
Inside your network
Public beta means published, signed, exercised on real hosts, and offered to pilots. Preview means it works and is included, with gaps stated.
The installer checks the host, verifies the signed images, installs the public engine pinned by digest with the private gateway in front of it, sizes the scan workers to your licence and memory, and starts everything with Docker Compose. The gateway passes each request through reviewed per-role allowlists; unknown routes are refused.
A signed, installation-bound licence file checked offline. It sets how many scans run at once; the gateway reserves a slot per scan, retest or scheduled run and refuses beyond it, naming what holds the slots. Inventory discovery of a new host takes no slot. Expiry stops new scans only. Renewal works from a usage summary you export yourself.
Operators schedule a scan of an authorized web target daily, on chosen weekdays, weekly or monthly, in a named time zone. Each run is recorded with its outcome; a run waits for a free slot and never authorizes its target itself. A status endpoint for monitoring and an evidence export (CSV or JSON with a SHA-256 of its rows). Included with every licence.
Ask for a retest of one finding or many from Retests and fixes. A retest that proves the fix closes the finding; a later scan that sees it again reopens it. Each open finding’s age against a per-severity SLA, what changed between a target’s scans, an evidence export for your auditor, and the findings themselves as CSV or JSON.
An administrator connects Jira Cloud or Data Center. One ticket per finding, from the console or a terminal, linking back to the finding; a retest that proves the fix comments on the ticket and moves it to done, and each ticket’s Jira status is shown. Tickets never carry evidence, requests or responses.
On by default: host targets, network scans (port and service discovery from your host; nothing installed on devices), connected devices, the Exposure and attack-surface views, and a certificate-transparency monitor that adds new names under your domains as targets. Private addresses are allowed by default; an administrator can refuse them or turn each part off.
A one-time connect link from the console, then pipx install shakerscan (or brew install andriyze/shakerscan/shakerscan) and shakerscan agent claude, codex, opencode or pi: your coding agent works against your instance over MCP, under your identity and in the audit log. shakerscan record turns a browser session you sign in and walk through into a capture that scans and Hunts use.
An administrator picks a newer published engine release this gateway has reviewed; the host updater backs up, installs, restarts and verifies, and puts the previous engine back if a step fails. An encrypted daily backup of the engine database, evidence, identities, schedules and deployment files, restorable onto the same or another host. Start at boot, log rotation, your own certificate or Let’s Encrypt, a corporate proxy for the certificate authority, the identity provider and the gateway release channel.
On for operators by default. Operators drive it in the browser, through their agent over MCP or from the CLI; viewers read. A step a person must allow waits as a permission request that the person approves in their own terminal. Your own model credentials are needed only for the engine’s autonomous features; the autonomous Hunt runs read-only and shadow episodes, and active runs are not available.
Week 1
Questionnaire, licence and pull access; install on your host with us on a call.
Weeks 2–3
Your operators scan your applications; we review findings and fix what blocks you.
Week 4
Backup, upgrade and restore drill on your side; decision.
The email opens with the questions a pilot starts from: your company and role, your identity provider, where the host would run, how many applications you scan and whether any are internal-only, and the concurrent scans you expect.
Enterprise runs the public engine images unchanged. Identity, administration, licensing, schedules, retests that close findings and Jira sit in front of them; nothing is removed from the open-source release. In this beta the gateway exposes a reviewed part of the engine, listed above.
See what the open-source release includes