KubeMend

Inspiration

Every Kubernetes team knows the review comments by heart: no resource requests, no readiness probe, this can run as root. Scanners already find these problems - teams drown in warning lists and then hand-edit YAML, which is slow and easy to get wrong.

What it does

KubeMend is a CLI that scans manifests and Helm-rendered YAML for ten well-known hardening misconfigurations and generates the fix as a minimal, unified-diff patch you can review like any other code change. Every finding cites the exact field path (spec.template.spec.containers[0].resources.requests), and --explain prints a short plain-English rationale per rule, so a finding doubles as a teaching moment. It is safe by default: a scan never modifies a file unless you pass --write, and exit codes (0 clean / 1 findings / 2 scan error) make it CI-friendly.

One rule is deliberately patch-free: KM005 flags images that are not pinned by digest, but KubeMend refuses to invent a digest it cannot know - it prints the exact registry command to get the real one instead. A patch that fails to pull is worse than no patch.

How we built it

The foundation is a small, thoroughly tested rule engine (kubemend_engine, 38 tests, a vulnerable/fixed fixture pair per rule). Two applications sit on top of it: the kubemend CLI and kubemend-report, which renders the same findings as a shareable Markdown or HTML audit report. Install is one command (pip install -e .), the only runtime dependency is PyYAML, and there is no cluster, network, or account involved at scan time.

KubeMend was built spec-first with Kiro, and the evidence is in the public repo under /.kiro/ (committed, not gitignored, per the rules):

Spec-driven development: .kiro/specs/kubemend/requirements.md was written first - user stories with EARS acceptance criteria (including dry-run purity and fix idempotence as explicit criteria) - followed by design.md (architecture and the per-rule fix strategy) and tasks.md, the checklist the implementation then followed in order: engine, rules in two batches, CLI, report app, hook, demo. Compared with vibe coding, the spec paid off most where correctness is checkable: the acceptance criteria became the test suite almost verbatim.
Steering docs: .kiro/steering/product.md fixed the principles (safe by default, never fabricate values - the decision that made KM005 guidance-only came from here), tech.md fixed the rule contract and determinism rules, and structure.md fixed layout and naming. Writing these once kept ten rules and two apps consistent without re-explaining conventions in every prompt.
Agent hooks: .kiro/hooks/run-tests-on-rule-save.kiro.hook runs the rule test suite automatically whenever a file under engine/kubemend_engine/rules/ is saved. Rules are the heart of the tool; the hook turns "did I break a check?" into an instant signal instead of a release-time surprise.
What was not used: no MCP servers and no custom agents - the project is a single-package Python tool, and the honest stack was specs + steering + one well-aimed hook.