OSS Core + Enterprise

Ship vibe-coded apps to production.
Analyze. Lock. Generate.

Harden CLI is the OSS core: static analysis, deterministic dependency locking, Dockerfile generation, and SBOM + vulnerability reporting. Enterprise adds runtime profiling, guardrails, and fleet management.

Start with the CLI in CI. Upgrade when you need runtime enforcement.

See it work Read docs
scroll to see the demo
Live Demo

Watch it harden a real app

Three commands. From source to Dockerfile + SBOM.

bash — harden demo
1. Analyze 2. Lock 3. Generate

Before & After

What a typical vibe-coded app looks like vs. what harden produces

myapp/ — before
app.py
hardcoded sk-proj-... on line 3
utils.py
.env
not in .gitignore
requirements.txt
unpinned: openai, fastapi, requests...
No requirements.lock
No Dockerfile
No SBOM
No CVE report
No .dockerignore
myapp/.harden/ — after
Dockerfile
multi-stage, non-root, lockfile-aware
sbom.json
CycloneDX + OSV vulnerability data
requirements.lock
deterministic dependency pins
.harden/state/harden-report.json
analysis report + entry command
.harden/state/osv_cache.json
cached CVE lookups
.dockerignore
keeps secrets out of images
OSS Core

Three commands, targeted outcomes

Developer

Understand risk in minutes

"Tell me what's risky before I ship."

harden analyze scans secrets, dependencies, and frameworks and writes a structured JSON report, including an inferred entry_command.

Security

SBOM + OSV vulnerability checks

"I need a SBOM I can audit."

Generate a CycloneDX SBOM with vulnerability metadata from OSV, backed by a local cache for fast CI runs.

Platform

Deterministic dependency locks

"Pin everything. Reproducible builds."

harden lock produces requirements.lock and a build report, inferring dependencies from imports when a manifest is missing.

DevOps

Dockerfile generation that respects locks

"Use the lockfile or don’t build."

harden generate prefers requirements.lock, falls back to requirements.txt, and supports pyproject.toml-only projects.

How It Works

Three-step pipeline

1

Analyze

harden analyze

Scan secrets, dependencies, framework, and risks. Emit a JSON report with entry command.

2

Lock

harden lock

Pin every dependency to an exact, reproducible version (with import inference if needed).

3

Generate

harden generate

Write a lockfile-aware Dockerfile and CycloneDX SBOM, with optional fail-on-critical.

Why OSS stays focused

Lockfile-first Dockerfiles

Uses requirements.lock when present, falls back to requirements.txt, and supports pyproject.toml-only installs.

Others: ignore locks or require manual edits
Harden: deterministic builds by default

OSV CVE checks with cache

Dependency vulnerabilities are enriched via OSV with a local cache for fast, repeatable CI runs.

Others: slow, repeated lookups
Harden: cached and deterministic

Entry command inference

Best-effort detection of how your app should run, surfaced in both terminal output and JSON reports.

Others: manual guesswork
Harden: inferred entry command

SBOM from lockfile

Generates a CycloneDX SBOM from pinned dependencies with vulnerability metadata when available.

Others: partial or unpinned SBOMs
Harden: lockfile-accurate SBOMs
Editions

Open Source + Enterprise

OSS stays minimal. Enterprise adds runtime enforcement and fleet controls.

Open Source

Free

Analyze, lock, generate (Dockerfile + SBOM) for Python apps.

  • Static analysis + entry command
  • Deterministic lockfile
  • Dockerfile + SBOM
  • OSV cache + fail-on-critical
View OSS docs

Install Harden OSS

Run the OSS core locally or in CI. Docs at /docs.

$ uv tool install harden-cli click to copy

pip install harden-cli


"Because 'it works on my machine' isn't a security strategy."