OS Hardening as Code, Episode 6
Cloud AMI Security Risks · Linux Hardening as Code · Multi-Cloud OS Hardening · Automated OpenSCAP Compliance · CI/CD Compliance Gate · Stratum Platform**
Focus Keyphrase: OS hardening platform open source
Search Intent: Informational
Meta Description: Stratum is open-source (Apache 2.0) — declare your OS baseline in YAML, build hardened images across six clouds, and gate deployments on compliance grade. (154 chars)
TL;DR
- Stratum is open-source under Apache 2.0 — the engine, blueprint format, scanner, and Pipeline API are all available on GitHub
- The platform follows the same open-core model as Terraform/OpenTofu and Cilium/Isovalent: OSS core, self-hostable, extendable
- Three extension points: custom compliance controls, provider plugins (add new cloud providers), pipeline integrations
- Architecture: Blueprint YAML → Engine → Provider Layer → Ansible-Lockdown → OpenSCAP → Golden Image → Pipeline API
- The series taught the user-facing interface for five episodes; EP06 covers what’s underneath and how to build on it
- Installation is a single
helm installordocker compose up— the platform runs in your environment
The Series Arc, Inverted
EP01 showed that default cloud AMIs arrive pre-broken. By the time you reach EP06, that problem has a complete solution:
EP01 — The problem:
Default AMI → Production → Security audit finds gaps
(unknown OS baseline, unverified hardening, no evidence)
EP06 — The solution:
HardeningBlueprint YAML
↓
stratum build ← EP02 (blueprint as code)
--provider aws,gcp ← EP03 (multi-cloud)
↓
OpenSCAP scan ← EP04 (compliance grading)
Grade: A (94/100)
↓
POST /api/pipeline/scan ← EP05 (CI/CD gate)
Result: pass
↓
Production deployment
(Grade A, SARIF attached, blueprint version-controlled)
For five episodes, you’ve used Stratum as a user. This episode covers what it looks like to run it yourself, extend it, and build on it.
I’ve spent years watching infrastructure teams solve the same OS hardening problem in slightly different ways. Custom scripts that drift. OpenSCAP runs that produce evidence no one reads. Compliance checklists completed by humans who have competing priorities.
The tools exist. ansible-lockdown applies CIS controls reliably. OpenSCAP verifies them accurately. The CI/CD systems can enforce anything you can express as a pass/fail. The gap isn’t the tooling — it’s the integration layer that ties them together into a reproducible, auditable pipeline.
Stratum is that integration layer, open-sourced.
The philosophy is the same as Terraform applied to OS security posture: declare the desired state in a version-controlled file, apply it reproducibly, and verify it automatically. The skip-at-2am problem disappears not because engineers are more careful, but because there’s no step to skip.
The Architecture
┌─────────────────────────────────────────────────────────┐
│ HardeningBlueprint YAML │
│ (version-controlled, provider-agnostic) │
└─────────────────────┬───────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ Stratum Engine │
│ (Apache 2.0, OSS) │
│ ┌─────────────┐ ┌──────────────┐ ┌────────────────┐ │
│ │ Blueprint │ │ Provider │ │ Scheduler │ │
│ │ Parser │ │ Layer │ │ (parallel │ │
│ │ │ │ AWS GCP │ │ multi-cloud │ │
│ │ Validates │ │ Azure DO │ │ builds) │ │
│ │ schema + │ │ Linode │ │ │ │
│ │ overrides │ │ Proxmox │ │ │ │
│ └─────────────┘ └──────────────┘ └────────────────┘ │
└─────────────────────┬───────────────────────────────────┘
│
┌──────────┴──────────┐
▼ ▼
┌─────────────────┐ ┌─────────────────┐
│ Ansible-Lockdown │ │ OpenSCAP │
│ Runner │ │ Scanner │
│ │ │ │
│ UBUNTU22-CIS │ │ A-F grade │
│ RHEL8-STIG │ │ SARIF export │
│ Custom roles │ │ Drift detect │
└────────┬─────────┘ └────────┬────────┘
│ │
└──────────┬───────────┘
│
▼
┌─────────────────────────┐
│ Golden Image │
│ (AMI / GCP / Azure) │
│ + compliance metadata │
└────────────┬────────────┘
│
▼
┌─────────────────────────┐
│ Pipeline API │
│ (Apache 2.0, OSS) │
│ │
│ POST /api/pipeline/scan │
│ ← CI/CD gate │
└─────────────────────────┘
Every component is open-source under Apache 2.0. The engine, provider layer, Ansible runner, OpenSCAP scanner, and Pipeline API are all in the repository. Nothing is locked to a hosted service.
Installation
Stratum runs as a set of containers. Kubernetes or Docker Compose both work.
Kubernetes (Helm):
# Clone the repository
git clone https://github.com/rrskris/Stratum
cd Stratum
# Install Stratum in your cluster using the bundled Helm chart
helm install stratum ./deploy/helm/stratum \
--namespace stratum-system \
--create-namespace \
--set config.providers.aws.enabled=true \
--set config.providers.gcp.enabled=true \
--set config.storageClass=standard
# Verify
kubectl get pods -n stratum-system
# NAME READY STATUS RESTARTS AGE
# stratum-engine-0 1/1 Running 0 2m
# stratum-scanner-7d9b4-abc12 1/1 Running 0 2m
# stratum-api-6c8f5-def34 1/1 Running 0 2m
Docker Compose (single-node):
# Clone the repository
git clone https://github.com/rrskris/Stratum
cd Stratum
# Configure providers
cp config/providers.example.yaml config/providers.yaml
vim config/providers.yaml # add AWS/GCP/Azure credentials
# Start
docker compose up -d
# Stratum is available at http://localhost:8080
The Three Extension Points
1. Custom Compliance Controls
Add controls that aren’t in the CIS benchmark — internal policies, org-specific security requirements, or controls from other frameworks:
# controls/custom-audit-policy.yaml
id: CUSTOM-001
title: Audit logging retention must be 90 days
description: All instances must retain audit logs for 90 days minimum
severity: high
benchmark: custom
check:
type: command
command: "grep -E '^max_log_file_action' /etc/audit/auditd.conf"
expected: "max_log_file_action = keep_logs"
remediation:
type: ansible
task: |
- name: Configure audit log retention
lineinfile:
path: /etc/audit/auditd.conf
regexp: '^max_log_file_action'
line: 'max_log_file_action = keep_logs'
Deploy the custom control:
stratum controls deploy --file controls/custom-audit-policy.yaml
Reference it in any blueprint:
compliance:
benchmark: cis-l1
controls: all
additional_controls:
- CUSTOM-001
Custom controls appear in the grade calculation and SARIF output alongside CIS controls.
2. Provider Plugins
Add support for a new cloud provider by implementing the provider interface:
# providers/custom_provider.py
from stratum.providers import BaseProvider
class CustomProvider(BaseProvider):
name = "my-cloud"
def provision_build_instance(self, blueprint, config):
# Launch a build instance on your cloud
# Return: instance_id, connection_details
...
def create_image(self, instance_id, blueprint, grade):
# Snapshot the instance into an image
# Tag with compliance metadata
# Return: image_id
...
def terminate_instance(self, instance_id):
# Clean up the build instance
...
Register the plugin:
stratum providers register --file providers/custom_provider.py --name my-cloud
The provider is now available as --provider my-cloud in all stratum build commands.
3. Pipeline Integrations
Beyond the curl-based API, Stratum provides a webhook system that fires on build completion, scan results, and gate failures:
# Webhook configuration
notifications:
- event: pipeline_gate_failure
webhook: https://hooks.slack.com/...
template: |
Image {{ image_id }} failed compliance gate.
Grade: {{ grade }} (required: {{ min_grade }})
Top failing controls:
{% for control in failing_controls[:3] %}
- {{ control.id }}: {{ control.title }}
{% endfor %}
- event: build_complete
webhook: https://jira.yourdomain.com/api/...
template: |
New image built: {{ image_id }}
Blueprint: {{ blueprint_name }}@{{ blueprint_version }}
Grade: {{ grade }}
The Open-Core Model
Stratum follows the same model as the tools that have become infrastructure standards:
| Tool | Open-core model |
|---|---|
| Terraform / OpenTofu | Core OSS, enterprise features in paid tier |
| Cilium / Isovalent | Core OSS, enterprise support/features in paid tier |
| Vault / HCP Vault | Core OSS, hosted/enterprise in paid tier |
| Stratum | Engine + blueprint + scanner + Pipeline API: Apache 2.0 |
Everything taught in this series — the blueprint format, the build pipeline, the compliance grading, the CI/CD gate — is in the OSS core. You can self-host it, extend it, contribute to it, and run it in your own infrastructure without any dependency on a hosted service.
The repository is at: github.com/rrskris/Stratum
What This Series Taught
EP01 — EP06 in one view:
| Episode | What you learned | What Stratum does |
|---|---|---|
| EP01 | Default AMIs are insecure by design | Replaces default AMI with a hardened golden image |
| EP02 | Blueprint as code — the 2am skip disappears | HardeningBlueprint YAML — 5-step wizard or direct YAML |
| EP03 | One blueprint, six providers, no drift | 6 providers: AWS, GCP, Azure, DigitalOcean, Linode, Proxmox |
| EP04 | Automated OpenSCAP — grade at build time | Compliance Scanner: A-F, SARIF, drift detection |
| EP05 | CI/CD gate — the unhardened image never deploys | Pipeline API: POST /api/pipeline/scan |
| EP06 | The platform — OSS, self-hostable, extendable | Apache 2.0, Helm install, three extension points |
What’s Next
This series closes the OS hardening gap. The same principle — declare desired state, build reproducibly, verify automatically — applies to every layer of your infrastructure.
If you’ve been following the eBPF: From Kernel to Cloud series, EP10 covers what happens when you combine kernel-level observability with the hardened base that Stratum provides: every connection, every process spawn, every file access — visible from the host kernel, on an OS baseline you can verify.
The next series: Purple Team Playbook — real attack paths against cloud and Kubernetes infrastructure, how they’re detected, and how they’re closed. Starting May 8.
GitHub: github.com/rrskris/Stratum
Get the Purple Team series in your inbox → linuxcent.com/subscribe