Skip to content

Security: mk12002/Bastion

Security

SECURITY.md

Security Policy

Bastion is a security tool that reads untrusted input — manifests and cluster exports it did not write, often in CI with credentials in the environment. Its own security is therefore part of its job, not an afterthought. This document is the reporting policy; the full threat model and the enforcement of every guarantee below live in docs/THREAT_MODEL.md.

Reporting a vulnerability in Bastion

Please report privately, not in a public issue:

  • Open a GitHub Security Advisory on the repository (Security → Advisories → Report a vulnerability), or
  • email the maintainers (see the repository's contact).

Include a proof of concept if you can — a minimal manifest that triggers the behaviour is ideal, since everything Bastion does is reproducible offline.

We aim to acknowledge within a few days and to ship a fix or mitigation before any public disclosure. Coordinated disclosure is welcome and credited.

What is in scope

  • Code execution, file write, or network access triggered by scanning a crafted manifest.
  • Unbounded resource use (memory/CPU/time) from a crafted input that a size or depth limit should have contained.
  • Injection into a generated report (HTML/SVG/JSON/SARIF) via attacker-controlled resource names.
  • A secret value from input surviving into any output.
  • A path in the scanned tree causing Bastion to read or write outside it.

What is not a vulnerability in Bastion

  • A false positive or false negative in the analysis. Those are correctness issues — valuable, but file them as normal issues. See the honest limitations in the README.
  • Findings Bastion reports about a third party's chart. Bastion analysing a public Helm chart and reporting a path is the tool working as intended. If you believe a real deployed cluster is exploitable, disclose to that project's maintainers, never here — see below.

The guarantees these reports are measured against

Each is enforced by a test in tests/test_hardening.py, run in CI on every commit:

Guarantee How it's enforced
No code execution from input Safe YAML loader (no !!python/object); AST check bans eval/exec/subprocess; a payload test asserts nothing runs
No network, ever AST check bans socket/http/urllib/requests/kubernetes imports; a CI job scans with sockets disabled
Bounded memory/CPU 20 MB per-file cap, 100k-file discovery cap, alias-bomb shown bounded, deep nesting caught as malformed, regexes proven non-backtracking
No report injection Every user value is HTML-escaped in HTML/SVG; JSON and SARIF unicode-escape < > & so they're safe even embedded in a web UI
Secrets never leak Parsers never read Secret data/stringData; output is scrubbed of tokens and base64 blobs as a second layer
No path escape Directory symlinks not followed; non-regular files skipped; writes go only to the chosen --out directory; report paths are relative

Disclosing a finding Bastion made about someone else's software

This is a hard rule for this project and its maintainers:

  1. Disclose privately to that project's maintainers, via their security policy.
  2. Never publish a working exploit.
  3. Never name a project on an unverified finding. Static analysis of a chart is not proof that any deployed cluster is exploitable.

Supported versions

Bastion is pre-1.0; security fixes land on main and in the next release. Pin a version in environments where that matters, and watch releases.

There aren't any published security advisories