Before an audit someone asks: "are our workloads non-root, are service account tokens locked down, is there a network policy everywhere?" The usual answer is a spreadsheet and a lot of hope. The assistant answers from the manifests themselves, says "unknown" when it cannot prove something, and runs a set of deterministic posture checks on the systems around your clusters.
The posture report is generated on demand. It walks every manifest in every writable repository, the same corpus the repo scanner sees, and renders a PDF.
It creates no merge requests and no issues. The gaps it counts are already proposed by the other agents; the report is the summary, not a second copy of the work.
The first version covers the controls where a manifest can carry positive evidence:
PSS-restricted:runAsNonRoot, every container, init and ephemeral container includedCIS-5.1.x:sa-token-least-privilege, service account token automountNSA-hardening:NetworkPolicy-present, checked against a repo-wide index so a policy in a sibling file still countsA false "compliant" is worse than a false gap: someone may rely on it in an audit. So a control is satisfied only when the manifest says so explicitly. No finding is not proof. Anything the checks cannot decide, including an error while checking, is counted as unknown.
The report says on its face: manifest-checkable subset only, not an attestation.
Each control shows how many workloads were scanned and how they split. A reader sees at once that 140 of 212 workloads prove they run as non-root, 31 do not, and 41 could not be decided from the manifest alone.
ISO 27001 and SOC 2 are organisational standards; mapping down to them is planned as a later layer.
Read-only, per zone: minimum TLS version, HSTS, SSL mode, DNSSEC, managed WAF rules and rate limiting, plus dangling CNAMEs that point at a target that no longer resolves, a classic takeover risk.
A zone whose plan does not include WAF or rate limiting abstains rather than fires. A setting that could not be read is reported as unobserved, never as fine. A separate check catches an armed edge block that would refuse your own clusters' egress IPs.
If someone can force-push to the deployment repo, the rest of the chain does not matter. The assistant reviews the forge itself:
Every active GKE recommendation is read per cluster. The text is Google's, never paraphrased. Recommendations the assistant already covers itself (disruption budgets, memory limits, under-provisioned workloads) are attached as supporting evidence instead of being filed twice.
New recommendations arrive as issues. Turning them into a draft MR against the matching manifest is built but not yet switched on.
Before a Flux spec.verify block is proposed, the chart's
signing is checked with cosign and cached. A verify block on a chart
that is not cosign-signed would break the release, so it is refused.
When a proposal pins an image to a @sha256: digest, that
digest needs a receipt from the registry. A digest nobody looked up
is held for review, never shipped.
Edge, forge and cloud settings mostly live outside your git repos, so these findings are issues: one per cause, with the evidence, the risk and the fix steps. Where the setting does live in git (a CI file, a manifest), a draft MR is possible.
The full issue is below.
$ gitops-assistant compliance-report --output posture.pdf walking 4 repositories · 1,806 manifests 212 workloads · 3 controls PSS-restricted:runAsNonRoot 140 / 31 / 41 CIS-5.1.x:sa-token-least-privilege 96 / 88 / 28 NSA-hardening:NetworkPolicy-present 171 / 12 / 29 wrote posture.pdf · 0 proposals created
spec: template: spec: automountServiceAccountToken: false # CIS-5.1.x ✓ securityContext: runAsNonRoot: true # PSS runAsNonRoot ✓ initContainers: - name: migrate securityContext: runAsUser: 0 # overrides the pod → gap containers: - name: app
runAsNonRoot: true present on pod and not overridden SATISFIEDrunAsUser: 0 on any container GAP| Control | Standard | Satisfied | Gap | Unknown |
|---|---|---|---|---|
| runAsNonRoot | PSS restricted | 140 | 31 | 41 |
| SA token least privilege | CIS 5.1.x | 96 | 88 | 28 |
| NetworkPolicy present | NSA/CISA | 171 | 12 | 29 |
# quoted, never paraphrased "<Google's recommendation text, exactly as returned>"
+ image: registry.example.com/shop/cart@sha256:9c1e… ✓ receipt: resolved from registry at emission + image: sidecar/labeler@sha256:<digest> ✕ no registry receipt · held (NEEDS_REVIEW)
Illustrative, shaped like the edge-posture issues the assistant files today. Settings outside git become issues; nothing here is changed for you.
acme-prod · zone shop.example · rule min_tls_below_1_2Zone shop.example accepts TLS 1.0 at the edge. TLS 1.0 and 1.1 are deprecated and fail most compliance baselines (PCI DSS requires 1.2 or later for cardholder data).
The setting lives in Cloudflare, not in a repository, and the assistant's Cloudflare access is read-only.
| Surface | Read | Value |
|---|---|---|
zone settings · min_tls_version | ok | 1.0 |
zone settings · ssl | ok | strict |
| security header · HSTS | ok | disabled (separate issue) |
All three surfaces were read successfully in this run. An unreadable surface would be reported as unobserved, never as compliant.
| Check | Result |
|---|---|
| HSTS | disabled · medium · own issue |
| DNSSEC | disabled · medium · own issue |
| Dangling CNAME | old-promo → NXDOMAIN · own issue |
| Managed WAF, rate limiting | not available on this plan · abstained |
Security reports lose their value the first time they are confidently wrong. These are the rules that prevent that.