Control → Evidence Map (this repo)

Field	Value
Type	Skill Resource
Source	~/.copilot/skills/security/references/ato/control-evidence-map.md
Description	Not specified

Source Content

Control → Evidence Map (this repo)

The authoritative, repo-specific map of which engineering practice satisfies which control, what evidence it produces, and whether it is currently Aligned or Partial. Mirror this — do not contradict it. Source of truth: docs/engineering-practices/ato-control-alignment.mdx (keep that page and this reference in sync; the page wins on conflict).

A control you can’t evidence is a control you don’t have

The verdict rule the whole skill turns on: a control is Aligned only when the behavior is implemented and the evidence falls out as a by-product of normal work (a SARIF export, a signed commit, an ArgoCD sync record, a restore-test report). If producing the evidence needs a manual spreadsheet or a quarterly scramble, the control is at best Partial.

Control coverage (as of the source page)

Control(s)	Practice page	Evidence produced	Status
AC-2	Security — Authorization	Access requests, quarterly access reviews, account disablement records	Partial
AC-3	Security — Authorization; GitOps — Environments	Role matrix, environment reviewer settings, boundary records	Aligned
AC-5	GitOps — Branch Protections / Code Review; Security — Authorization	Non-author approval, protected-branch rules, author/reviewer/promoter separation	Aligned
AC-6	Security — Authorization / Secrets; GitOps — Environments	Least-privilege role matrix, secret-access reports, environment-scoped perms	Partial
AU-2/3/6/11/12	Security — Monitoring; GitOps — Deployments	Audit event taxonomy, log samples, retention policy, deployment history	Partial
CA-3	How We Work — Vendors	Integration inventory, data-flow record, boundary-crossing record	Partial
CA-7	Security — Monitoring / Compliance	Monthly monitoring review, SARIF exports, POA&M-linked findings	Partial
CM-3/4/5	GitOps — Deployments / Branch Protections; Definition of Done	PR approvals, workflow runs, environment approvals, ArgoCD sync history	Aligned
CM-6	Security — Compliance	Policy-as-code records, Kyverno policies, Cloud Custodian rules	Aligned
CP-9/10	Security — Disaster Recovery	Backup policy, encryption evidence, quarterly restore-test report	Partial
IA-2/5	Security — Authorization / Secrets	SSO policy, MFA report, credential rotation record, IAM assumption logs	Partial
IR-4/5/6/8	GitOps — Incidents; Security — Disaster Recovery	Incident record, priority label, notification record, post-incident review	Partial
MP-2, SC-28	GitOps — Environments	Synthetic lower-environment data confirmation, environment values diff	Partial
RA-5, SA-11, SI-2	GitOps — Dependency Management; Security — Compliance; Definition of Done	Vulnerability scans, SARIF exports, CI scan status, remediation PRs	Aligned
SA-9, SR-3/4/5	How We Work — Vendors; GitOps — Dependency Management	Vendor register, FedRAMP status, dependency inventory, SBOM export	Partial
SC-5/7/8	Security — Networking	Boundary diagram, WAF policy, firewall policy, TLS config, flow logs	Aligned
SC-12/13	Security — Secrets	Key management, rotation record, IAM and secret-manager logs	Partial
SI-4	Security — Monitoring / Compliance	Alert routing table, monitoring review, runtime findings	Partial

When you read this from the skill, re-check the live status in ato-control-alignment.mdx — these flip from Partial to Aligned as remediation lands. The known open gaps the page tracks: stale-account automation (AC-2), the monthly ConMon packet, a hard vendor-inventory merge gate (CA-3), annual incident tabletop evidence (IR), lower-environment synthetic-data attestation (MP-2), and release-level SBOM retention (SR).

The ato_* frontmatter convention

Every engineering-practice page that satisfies a control carries this block. When your change adds or strengthens a control, extend the relevant page’s frontmatter to match:

---
last_verified: 2026-06-07
tags: [engineering-practices, security, compliance]
ato_controls: [CA-7, CM-6, RA-5, SA-11, SI-2]   # the control ids this page evidences
ato_families: [CA, CM, RA, SA, SI]              # their families
ato_evidence:                                   # the artifacts a reader can collect here
  - SARIF finding export
  - Vulnerability scan report
  - Policy-as-code repository record
  - POA&M remediation item
ato_status: "60%"                               # derived percentage — see "The ato_status percentage" below
---

The ato_status percentage

ato_status is a derived score, not a hand-picked label. It rolls the per-control verdicts in this table up into one number, so every page is scored identically:

ato_status% = round( 100 × ( Σ control_score ) ÷ control_count )

control_score:   Aligned = 1.0    Partial = 0.5    Gap = 0.0

The scores come from the Coverage column of ato-control-alignment.mdx, applied to the page’s ato_controls. Conventions:

• Write it quoted with a percent sign: ato_status: "60%".
• A page with no controls keeps ato_status: not_applicable — a percentage over zero controls is meaningless.
• The badge maps the number to a band: 100% → Aligned, 1–99% → Partial, 0% → Gap.
• Don’t hand-edit it. Run node scripts/compute-ato-status.mjs (or --check in CI) to recompute every page after any Coverage or ato_controls change.

And an ## ATO evidence section near the end, with an Evidence → Supports table tying each artifact to a control id:

## ATO evidence

| Evidence | Supports |
|---|---|
| Monthly vulnerability scan and SARIF export | `RA-5`, `SI-2` |
| Policy-as-code repository record | `CM-6`, `CA-7` |
| Remediation PR or POA&M item | `SA-11`, `SI-2` |

Where evidence is actually enforced (compliance-as-code)

Compliance here is code that runs continuously, not a quarterly audit. The toolchain (from security/compliance.mdx) — each tool owns a layer and produces auditable evidence:

Tool	Layer	Produces	Controls
Kyverno	K8s admission	ClusterPolicy manifests in Git, synced by ArgoCD	CM-6, AC-6, SC-7
Falco	Runtime	Runtime anomaly alerts → SARIF	SI-4
Trivy	Image + IaC (pre-deploy)	Vulnerability scan / SARIF, gating	RA-5, SI-2
Dependabot / Renovate	Dependencies	Alerts + remediation PRs	RA-5, SA-11, SI-2
Cloud Custodian	AWS resources	Continuous drift correction, encryption/tag policy	CM-6, CA-7
ArgoCD	Delivery	Sync history, signed-commit gate	CM-3, CM-4

Findings export in SARIF into GitHub Advanced Security; developers fix, discuss, or dismiss through auditable PRs; false positives are annotated and recorded, not discarded. That paper trail is the ConMon evidence. The Kyverno NIST policy set lives at docs/kubernetes/p3-compliance/kyverno-policies/ and the OSCAL component definition at docs/kubernetes/p3-compliance/oscal/component-definition.mdx.

The monthly ConMon packet

Authorization is not one-and-done — FedRAMP requires Continuous Monitoring. The repo’s target packet (an open gap being standardized) bundles, monthly:

• Audit-log samples (the AU-* required fields)
• SARIF exports from every scanner
• Vulnerability scan reports (OS / web / DB / container / IaC)
• POA&M status (open findings + remediation dates, by SI-2 severity SLA)
• Flow-log samples (SC-7)
• Reviewer sign-off

When a change touches a continuously-monitored control, make sure its evidence is collectible into this packet without manual archaeology.

Sources

Claim	Source
Control → practice → evidence → status map	docs/engineering-practices/ato-control-alignment.mdx
ato_* frontmatter + “ATO evidence” section pattern	docs/engineering-practices/security/compliance.mdx and siblings
Compliance-as-code toolchain	docs/engineering-practices/security/compliance.mdx
ConMon requirement	docs/compliance/ato/security/fedramp.mdx