Compliance

Compliance is continuous evidence, not a quarterly scramble. Policy, scans, dependency remediation, release records, and monitoring findings are committed, executed, exported, and reviewed through the same Git-based delivery path.

The practical version is simple: when a tool finds risk, we route that risk into GitHub, fix or accept it in writing, and keep the record with the release or monitoring packet. A finding that only lives in a dashboard is easy to lose. A finding tied to a PR, release, or POA&M item can be reviewed later.

Compliance loop

flowchart TD
  subgraph AutomationPhase["Automation"]
    Policy["Policy as code"]
    Deploy["ArgoCD sync"]
    Scan["Scans and findings"]
  end
  subgraph HumanWork["Human work"]
    Triage["GitHub triage"]
    Fix["Remediation PR"]
    Evidence["ConMon evidence"]
  end
  Policy -->|on sync| Deploy
  Deploy -->|on deploy| Scan
  Scan -->|on finding| Triage
  Triage -->|if actionable| Fix
  Fix -->|on merge| Evidence
  Evidence -->|feeds| Policy
  style Evidence fill:#dcfce7,stroke:#16a34a,color:#14532d

The control is strongest when the evidence is a by-product of normal work. A Kyverno policy in Git, a Trivy SARIF export, a Renovate PR, an ArgoCD sync record, and a release record are better than a spreadsheet assembled after the fact.

Vocabulary

Term	Meaning
Finding	A scanner, policy, or reviewer identified a risk to investigate
SARIF	A standard format for security and code-analysis results that GitHub can display
SBOM	A software bill of materials: the dependency and component list for an artifact
POA&M	A tracked plan for an open weakness, owner, and remediation date
ConMon	Continuous monitoring evidence collected on a recurring cadence
False positive	A finding that is not exploitable or not applicable, with written justification

What to notice: these are not separate workflows. They are the names of records that attach to the normal PR and release path.

Toolchain

Tool	Layer	Produces
Kyverno	Kubernetes admission	Policy manifests, admission decisions, policy drift evidence
Falco	Runtime	Runtime anomaly alerts and finding records
Trivy	Image and IaC	Vulnerability scan results and SARIF exports
Dependabot	GitHub dependency visibility	Alerts, advisories, security update context
Renovate	Dependency remediation	Update PRs, dashboard decisions, grouped changes
Cloud Custodian	AWS resources	Drift correction, policy records, compliance findings
GitHub Advanced Security	Findings hub	SARIF triage, false-positive annotations, audit trail
ArgoCD	Delivery control plane	Sync history, drift state, deployed commit and values

What to notice: each tool owns a layer and produces a durable artifact that can be reviewed later.

Finding response path

When a finding appears, do not treat it as a dashboard cleanup task. Route it into the same engineering workflow as any other change.

1. Identify the affected repo, image, manifest, dependency, or policy.
2. Confirm severity and whether the finding is real.
3. Open or link a PR if code, config, dependency, or policy must change.
4. Add a POA&M item when remediation cannot happen immediately.
5. Annotate a false positive with the reason and reviewer.
6. Keep the SARIF export, PR, review, release, and monitoring record together.

The goal is not to make the dashboard quiet. The goal is to make the risk decision reviewable.

Dependency and supply-chain rules

Dependabot stays enabled for GitHub-native alerts. Renovate is the default update workflow because it can run from a controlled automation repo, apply shared policy, and still open normal PRs.

Control	Expectation
Identity	GitHub App or bot identity with least-privilege repo access
Scope	Autodiscovery filters limit which repos are managed
Configuration	Central config reviewed like code
Updates	PR-only; no direct writes to main
Exceptions	Local config only narrows behavior and explains why
Evidence	Dashboard, PRs, checks, reviews, labels, audit log, dependency inventory, SBOM

Review every dependency PR as a real code change. Check the lockfile, release notes, CI, tests, scans, security-sensitive approvals, migration notes, and deployment-manifest impact before merge. GitHub Actions, Helm, Kubernetes, Docker, Terraform, and authentication libraries are supply-chain sensitive even when the version bump looks small.

Dependency PR checklist

Use this checklist before approving dependency updates:

• the package name and ecosystem match what the PR says
• the lockfile change is expected
• release notes do not mention a breaking behavior change
• tests, build, lint, and security checks pass where relevant
• container, Helm, Terraform, GitHub Actions, and auth-related updates get extra review
• major versions include migration notes or an explicit hold decision
• the PR does not change unrelated code

Automated dependency PRs are proposals. The bot can open the PR, but a human still accepts the risk.

Findings flow back to Git

Every scanner should export results into GitHub Advanced Security using SARIF where supported. Developers fix, discuss, or dismiss findings through auditable PRs, and false positives are annotated instead of discarded.

This matters for ATO because the finding, the decision, the remediation, and the release are connected:

• the finding points to a repo, file, dependency, image, or policy
• the remediation lands as a PR with review and checks
• the release record shows which image and commit reached each environment
• the monitoring record shows whether the deployed system stayed healthy
• the POA&M item captures accepted risk or unfinished remediation

False positives and accepted risk

Do not silently ignore findings. If a finding is not real, record why. If a finding is real but cannot be fixed immediately, record the owner, severity, compensating control, and target date.

Situation	Correct record
Scanner flags generated code that is not shipped	False-positive annotation with reviewer
Dependency has no fixed version yet	POA&M item with monitoring and target review date
Risk is accepted for a release	Release note, approver, and POA&M link
Finding is fixed	Remediation PR, checks, and release record

An accepted risk is still a risk. The difference is that the owner and next review date are visible.

Release evidence

Release evidence is compliance evidence when it proves controlled change. For each release, retain the commit range, PR list, required checks, scan results, image digest, SBOM or dependency inventory, environment approvals, ArgoCD sync result, and monitoring outcome.

Artifact	Why it matters
Commit range and PR list	Shows what changed and who reviewed it
Workflow run and required checks	Shows verification before promotion
SARIF export and scan report	Shows vulnerability and policy status
Image digest and SBOM	Shows the artifact and its supply-chain contents
Environment approval	Shows production movement was authorized
ArgoCD sync result	Shows the declared state reached the cluster
POA&M item	Shows open risk is tracked and assigned

Continuous monitoring packet

Monthly continuous monitoring should be collectible from the systems above without manual archaeology.

Packet item	Source
Audit-log samples	GitHub, ArgoCD, CloudTrail, application logs
SARIF exports	GitHub Advanced Security and scanner outputs
Vulnerability scan reports	Trivy, Dependabot, Renovate, cloud posture tools
POA&M status	Finding records, remediation PRs, accepted-risk decisions
Flow-log samples	VPC Flow Logs, Network Firewall logs, Security Hub
Reviewer sign-off	PR approvals, release approvals, monthly review record

What good evidence looks like

Good evidence answers five questions without relying on memory:

Question	Evidence that answers it
What changed?	PR list, commit range, release notes
Who reviewed it?	PR approval, CODEOWNERS review, release approval
What artifact shipped?	Image digest, tag, SBOM
What did scanners find?	SARIF export, scan report, false-positive notes
What happened after deploy?	ArgoCD sync, monitoring result, incident or finding record

If the answer is “someone knows in chat,” the evidence is not durable enough.

Enforcement

• Policy-as-code changes go through PR review and ArgoCD reconciliation.
• Trivy and dependency checks run before deployment where configured.
• Renovate opens remediation PRs instead of writing directly to protected branches.
• SARIF findings are triaged in GitHub Advanced Security.
• Production promotion is blocked when required checks, scans, or approvals are missing.
• Compliance drift routes back to issues, PRs, or POA&M items.

ATO evidence

Compliance evidence should make continuous monitoring visible without a quarterly scramble. Retain SARIF exports, vulnerability scan reports, policy-as-code PRs, false-positive annotations, remediation PRs, dependency inventory or SBOM, release evidence, and POA&M items tied to the finding or control.

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
Central Renovate workflow and dependency inventory	SR-3, SR-4, RA-5
Release evidence with image digest and SBOM	SR-3, SR-4, CM-3

See also

• Delivery
• Monitoring
• Secrets
• Authorization