BakeX
Describe your hardened OS in a YAML blueprint; BakeX builds the CIS/STIG-benchmarked golden image on any cloud — or locally on KVM — and hands you the compliance evidence.
Why BakeX
Hardened image builds are usually manual, non-reproducible, and audited in a
scramble: someone runs a checklist against a VM, someone else screenshots the
scanner output, and six months later nobody can say why a rule was disabled.
BakeX collapses that into one version-controlled YAML file — the blueprint —
and gives every build the same pipeline: provision, harden with
Ansible-Lockdown, scan with OpenSCAP,
snapshot, tear down. Your security team gets an A–F grade and a SARIF report;
your platform team gets a golden image and a curl one-liner to rebuild it.
How It Works
HardeningBlueprint (YAML) ──or── 5-Step Guided Wizard
│
▼
┌─────────────────────────────────────────────────────┐
│ BakeX Engine │
│ │
│ 1. Provision → Spin up a temporary VM │
│ 2. Harden → Apply Ansible-Lockdown CIS/STIG │
│ 3. Scan → Run OpenSCAP, assert compliance │
│ 4. Snapshot → Capture as reusable golden image │
│ 5. Teardown → Remove the ephemeral build VM │
└─────────────────────────────────────────────────────┘
│
▼
Golden Image (AMI · GCP Custom Image · Azure Managed Image · Snapshot · qcow2)
│
▼
┌─────────────────────────────────────────────────────┐
│ Compliance Scanner │
│ │
│ Scan any image or running VM at any time │
│ A–F grade · SARIF export · Drift analysis │
│ CI/CD pipeline gate · Webhook notifications │
└─────────────────────────────────────────────────────┘
Quick Start
Docker Compose (recommended — everything preinstalled)
git clone https://github.com/invicton/bakex.git
cd BakeX
docker compose up
Open http://localhost:8001. Log in with any username and your admin token
as the password — it's auto-generated on first start and saved to
data/.admin_token (set BAKEX_ADMIN_TOKEN and BAKEX_SECRET_KEY in
docker-compose.yml for stable logins and credentials that survive rebuilds).
Compose mounts ~/.aws, ~/.config/gcloud, and ~/.ssh read paths plus
persistent ./data, ./profiles, and ./plugins/providers automatically.
Published image
docker run -p 8000:8000 rrskris/bakex:latest
PyPI
pip install "bakex[all-providers]" # or pick extras: aws, gcp, azure, linode, digitalocean, proxmox
bakex serve --port 8000 # or: uvicorn bakex.main:app --port 8000
bakex version prints the build; bakex serve --help lists options.
Built-in blueprint templates and the provider catalog ship inside the package,
so this works from any directory; runtime state (data/, profiles/user/) is
created where you launch. Ansible and OpenSCAP must be on the host for real
builds — see Configuration.
From source (contributors)
git clone https://github.com/invicton/bakex.git && cd BakeX
uv sync --extra all-providers --group dev
cp .env.example .env
uv run uvicorn bakex.main:app --reload --port 8000
No cloud account? The kvm provider builds hardened qcow2/raw images
entirely on your machine (QEMU/KVM + cloud-image-utils required). Full
first-run walkthrough: Getting Started.
Features
- Declarative blueprints — one YAML file captures OS, provider, compliance tier, per-rule overrides with justifications, filesystem, and users; version-controllable, diffable, reviewable
- Three build paths — 5-step wizard (UI), blueprint file (GitOps), or AI Builder (plain English → the agent writes the blueprint, builds, and iterates until the grade passes; Anthropic/OpenAI/Ollama/Bedrock backends)
- CIS L1, CIS L2, and STIG — via Ansible-Lockdown roles with pinned
known-good versions, scanned natively by
oscap xccdf eval - A–F compliance grade — weighted findings, configurable pass threshold, embeddable SVG badge per scan
- Evidence exports — printable HTML, SARIF 2.1.0 (GitHub Advanced Security, Azure DevOps), JSON; drift analysis between any two scans
- Pipeline-first API — API keys (SHA-256 at rest), HMAC-signed webhooks, CI gate examples for GitHub Actions/GitLab/Jenkins in the Pipeline Guide
- 18 ready-to-use templates across 6 OSes and 6 providers, plus a growing community blueprint library
Supported Platforms
Operating Systems
| OS | CIS L1 | CIS L2 | STIG | Benchmark ID |
|---|---|---|---|---|
| Amazon Linux 2023 | ✓ | ✓ | — | AMAZON_LINUX_2023 |
| Ubuntu 22.04 LTS | ✓ | ✓ | — | UBUNTU2204 |
| Ubuntu 24.04 LTS | ✓ | ✓ | — | UBUNTU2404 |
| Rocky Linux 9 | ✓ | ✓ | ✓ | RHEL-9 |
| RHEL 9 | ✓ | ✓ | ✓ | RHEL-9 |
| AlmaLinux 9 | ✓ | ✓ | — | RHEL-9 |
| Debian 12 | ✓ | ✓ | — | DEBIAN12 |
Providers
| Provider | Artifact | Auth |
|---|---|---|
| AWS | AMI | IAM role, ~/.aws/credentials, or env vars |
| GCP | Custom Image | Application Default Credentials |
| Azure | Managed Image | Service Principal or Managed Identity |
| DigitalOcean | Snapshot | API token |
| Linode | Private Image | API token |
| Proxmox | VM Template | API token or username/password |
| KVM (local) | qcow2 / raw | none — runs on the BakeX host |
Cloud onboarding uses reviewable least-privilege templates
(CloudFormation / ARM / gcloud scripts) — see
Cloud Onboarding.
Screenshots
| Cloud onboarding | Compliance evidence |
|---|---|
Screenshots are sanitized previews with no customer credentials or account data.
Documentation
| Guide | Purpose |
|---|---|
| Getting Started | Zero → hardened golden image with compliance evidence |
| Blueprint Guide | HardeningBlueprint schema, examples, templates |
| Configuration | Environment variables, LLM backends, system dependencies |
| Cloud Onboarding | AWS, Azure, GCP admin permission model |
| Pipeline Guide | CI/CD integration, SARIF export, Blueprint-as-Code |
| API Reference | Core REST endpoints and payloads |
| Plugin Guide | Writing and distributing provider plugins |
| Architecture | Pipeline state machine, source tree, design decisions |
| Blueprint Library Guide | Contributing community blueprints |
| Roadmap | Where BakeX is headed and how to influence it |
Contributing
Bug reports, feature requests, and PRs are welcome — see
CONTRIBUTING.md for the dev workflow and
good first issue
for curated starting points (most are pure-YAML blueprint work with acceptance
criteria and a local verify command included). Please follow the
Code of Conduct. Found a security issue? See
SECURITY.md instead of opening a public issue.
License
Apache 2.0 — see LICENSE.
Built by Vamshi Krishna Santhapuri.
Metadata
Release files for bakex 0.6.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| bakex-0.6.0.tar.gz | 445.4 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| bakex-0.6.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 734.6 kB
Release files / bakex-0.6.0.tar.gz
| Download URL | bakex-0.6.0.tar.gz |
|---|---|
| Size | 445.4 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
eb04f66beb1b94d3be248d98f43b1310fd0f4f1299bfc99c610cfd50b684800b
|
|
BLAKE2b-256 checksum How to use checksums |
d3f98d9be4c6e6430c5437d834e3c17aae35f825cd9f0274a775a8019a3e21f4
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.13
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jul 16, 2026.
Transparency logRelease files / bakex-0.6.0-py3-none-any.whl
| Download URL | bakex-0.6.0-py3-none-any.whl |
|---|---|
| Size | 289.2 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
3baf3e9bbe13d5a409a40083c500a292572a34fbb88bffa60989dc9112e9a41e
|
|
BLAKE2b-256 checksum How to use checksums |
ee67d5df6b9ffb4b2905bbb26554bf9df9abe508b02606ab40888f195ead1c29
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.13
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jul 16, 2026.
Transparency log