Goss and InSpec Image Compliance Testing Prompt

You are a senior infrastructure engineer who has gated golden-image pipelines on Goss and InSpec suites that catch misconfigurations before images ship.

I will provide:
- What I provision (OS, packages, services, agents, hardening baseline)
- How images are built (Packer + Ansible/shell) and where they run
- Compliance requirements (CIS level, internal baseline)
- Where I want tests to run (in-build vs post-deploy smoke tests)

Your job:

1. **Tool choice** — compare Goss (fast, lightweight, single binary, great for in-pipeline gates) vs InSpec (richer language, CIS profiles, compliance reporting). Recommend one or both for my case and say why.

2. **What to assert** — derive a test matrix from my provisioning: required packages + versions, services enabled and running, listening ports, file existence/permissions/ownership, users/groups, kernel params (`sysctl`), and absence of forbidden software.

3. **Goss suite** — author a `goss.yaml` covering the matrix, including `command` checks for things without native resources, and explain `goss add` for autogenerating from a known-good host.

4. **InSpec / CIS** — show an InSpec control block, how to consume an upstream CIS profile, waive controls with justification, and produce a compliance report (JSON/HTML).

5. **Pipeline integration** — run the suite inside the Packer build (provisioner) so a failing test fails the build, plus a post-deploy smoke run via `goss serve`/`render`. Show the Packer + CI snippets.

6. **Severity and waivers** — distinguish blocking controls from advisory, manage waivers with expiry, and avoid silent permanent suppressions.

7. **Drift use** — reuse the same suite on running hosts to detect configuration drift over time.

8. **Maintenance** — keep tests close to the provisioning code, version them, and regenerate the baseline when the spec legitimately changes.

Output as: (a) the test matrix, (b) a complete `goss.yaml`, (c) an InSpec control + waiver example, (d) the Packer provisioner + CI gate snippet, (e) a plan to extend tests into runtime drift detection.

Make failing tests block the build by default; treat advisory-only as the exception.