Enforce slsa

Enforce SLSA

Add an SLSA Verification (SlsaVerification) step to an existing Harness pipeline. The step verifies SLSA provenance attestations (when enabled) and optionally evaluates OPA policy sets against provenance data.

This skill only works with existing pipelines — do not create standalone verification-only pipelines.

Prerequisites: SLSA provenance must already exist for the artifact (typically from a provenance step via /generate-slsa — UI label SLSA Generation). Optional policy sets for provenance enforcement (/create-policy, harness_list policy_set).

Supported stages: CI, CD (Deployment), and Security. CD requires a containerized step group. Unlike SBOM enforcement, CI and CD both use SlsaVerification (no separate CD step type).

Guide the user through a step-by-step interactive wizard (same UX as /generate-slsa):

• Wizard: references/interactive-wizard-flow.md
• UI ↔ YAML: references/slsa-verification-step.md
• CD containerized step groups: skills/generate-slsa/references/cd-containerized-step-group.md

---

Interaction model (mandatory)

1. One question per turn — use AskQuestion when available; otherwise numbered options with (Recommended).
2. Opening message — add SLSA Verification; mention generation + optional policy prerequisites.
3. Progress breadcrumb — after pipeline fetch: Pipeline · Placement · Source · Details · Verify · Policy · Submit
4. Record answers — running summary; do not re-ask unless the user changes direction.
5. Fetch before configure — harness_get before placement/source questions.
6. Show pipeline structure — highlight provenance (SLSA Generation) and connectors.
7. Infer source from generation — when one provenance step exists (or identifier: slsageneration), reuse its source (map repo → image_path, lowercase → PascalCase types).
8. Never guess image tags — default from generation step; ask if ambiguous.
9. Confirm before write — summary + harness_update only after user confirms.
10. Stop after update — after successful harness_update, provide a configuration summary and point the user to /run-pipeline to execute. Do not call harness_execute, poll executions, or run harness_diagnose in this skill (same pattern as /configure-repo-scan).
11. CD on CI-only pipeline — do not reject CD verify; run Phase 3b to add Deploy stage + containerized group.
12. Verify method must match generation — keyless ↔ keyless, keybased ↔ public key from same key pair.

Full phase prompts: references/interactive-wizard-flow.md.

---

Instructions

Wizard phases

Phase	Breadcrumb	Action
0	Pipeline	AskQuestion: pipeline URL ready?
1	Pipeline	Collect URL → harness_get
2	Pipeline	Display structure; note missing provenance (SLSA Generation) step
3	Placement	AskQuestion: after generation, CD before deploy, etc.
3b	Placement (CD)	Service, env, infra, step group if new Deploy stage
4	Source	Infer from generation or pick registry tile
5	Source	Registry provider (Third-Party only)
6	Details	Connector (skip if obvious)
7	Details	Image / image_path (default from generation)
8	Verify	AskQuestion: verify attestation method
9	Policy	AskQuestion: policy set(s) or skip
10	Submit	AskQuestion: confirm pipeline update

After Phase 10 confirm → insert step, harness_update, then provide summary (do not run the pipeline).

Supported stage types

Stage type	Step type	Placement notes
CI	SlsaVerification	After provenance / slsageneration in the same stage
Deployment	SlsaVerification	Containerized step group; before deploy
Security	SlsaVerification	After generation when artifact is in registry

CD edge case

If no Deployment stage and user chose CD verify:

No CD Deploy stage yet. We can add a Deployment stage with a containerized step group and place SLSA Verification before deploy.

Run Phase 3b (service, environment, infrastructure, stepGroupInfra) — mirror /generate-slsa Phase 3b. Use skills/generate-slsa/references/cd-containerized-step-group.md with SlsaVerification.

After the wizard — backend steps

Check prerequisites

1. SLSA generation — pipeline contains type: provenance (SLSA Generation) or user confirms provenance exists.
2. Policy sets (optional) — harness_list(resource_type="policy_set"). If user wants policy enforcement and none exist, direct to /create-policy before continuing.

Extract context from pipeline YAML

From provenance step (if present — also match identifier: slsageneration), copy and transform:

Generation	Verification
source.type: docker	source.type: Docker
source.spec.repo	source.spec.image_path
source.spec.connector	source.spec.connector
spec.attestation	matching verify_attestation (private → public key for keybased)

Generate SLSA verification step YAML

CI / Security — Docker Registry, keyless verify:

- step:
    identifier: slsaverification
    name: SLSA Verification
    type: SlsaVerification
    spec:
      source:
        type: Docker
        spec:
          connector: lavakush07
          image_path: lavakush07/easy-buggy-app:blog
      verify_attestation:
        type: keyless
        spec:
          oidcProvider: harness
    timeout: 15m

Key-based verify (generation used keybased + private key):

      verify_attestation:
        type: keybased
        spec:
          publicKey: account.cosign_public_key

If API validation rejects flat keyless / keybased, retry with nested cosign wrapper — see references/slsa-verification-step.md.

Policy enforcement (Advanced tab — step-level enforce):

    enforce:
      policySets:
        - slsa_provenance_rules

No attestation verify (policy-only): omit verify_attestation.

CD Deploy — same step type inside containerized stepGroup; use <+artifact.image> for image_path when verifying service artifacts.

Full provider mapping: references/slsa-verification-step.md.

Insert step into pipeline YAML

• Insert at Phase 3 placement — after slsageneration when possible.
• Do not modify unrelated steps.
• Step identifier: slsaverification (use slsaverification_cd in CD when CI already has one).
• CD: inside containerized step group only.

Update pipeline via MCP

harness_update
  resource_type: pipeline
  resource_id: <pipeline_identifier>
  org_id: <organization>
  project_id: <project>
  body: { yamlPipeline: "<updated pipeline YAML>" }

On validation errors, check PascalCase source.type, image_path vs repo, and verify_attestation shape (prefer flat keyless; fallback nested cosign).

Provide summary

Report the results to the user (same pattern as /configure-repo-scan — do not execute the pipeline):

## SLSA Verification Configured

**Pipeline:** <pipeline_name>
**Step:** SLSA Verification (SlsaVerification)
**Location:** Stage "<stage_name>", <position>
**Source:** Docker — <connector> — <image_path>
**Verify attestation:** Keyless (Harness OIDC) — or as configured
**Policy sets:** <list or none>

**Pipeline URL:** https://app.harness.io/ng/account/<account_id>/module/ci/orgs/<org_id>/projects/<project_id>/pipelines/<pipeline_id>/pipeline-studio/

**Note:** Review the SLSA Verification step in Pipeline Studio to adjust Advanced settings.

### Next Steps
1. Run the pipeline via `/run-pipeline` to verify SLSA verification executes successfully
2. If the run fails, diagnose with `/debug-pipeline`
3. View verification outcome on the execution **Supply Chain** tab
4. If **Failed** due to policy deny, tune policies via `/create-policy`
5. Add generation with `/generate-slsa` if provenance was missing
6. Automate with `/create-trigger`

CD pipelines: note in the summary if runtime inputs (service artifact, environment, infrastructure) will be required at run time — the user provides those via /run-pipeline or Harness UI Run.

---

Examples

Verify after SLSA Generation

/enforce-slsa
Add SLSA verification after slsa-generation — keyless verify, policy set slsa_prod_rules

CD before deploy

/enforce-slsa
Verify SLSA in deploy stage before K8s rolling deploy for easy-buggy-app:blog

Key-based verify (matches keybased generation)

/enforce-slsa
Verify SLSA with public key account.cosign_public_key — same image as generation step

---

Performance Notes

• Only existing pipelines (may append Deploy stage).
• Wizard UX mandatory — one question per turn.
• Reuse generation source — scan for type: provenance or identifier: slsageneration; map repo → image_path, lowercase → PascalCase types.
• Verification source.type is PascalCase (Docker) — generation uses lowercase (docker).
• verify_attestation is snake_case (not verifyAttestation). Prefer flat type: keyless + oidcProvider (same shape as generation attestation).
• Policy sets on step enforce.policySets — not spec.policy like SBOM enforcement.
• List policy_set via MCP — do not invent identifiers.
• CD: containerized step group only; see skills/generate-slsa/references/cd-containerized-step-group.md.
• Do not execute pipelines in this skill — use /run-pipeline after configuration (same as /configure-repo-scan).
• Pair with /generate-slsa (generate) and /create-policy (OPA rules).

---

Troubleshooting

No SLSA Generation Step

• Add /generate-slsa first with attestation enabled (type: provenance in YAML).
• Verification needs .att in registry or provenance in SCS Artifacts.
• Scan for provenance steps — not SlsaGeneration (API uses provenance).

Attestation Verification Failed

• Verify method must match generation (keyless vs keybased).
• Keybased: use public key secret (generation uses private key).
• Keyless non-harness: configure Connector for Keyless Signing.

Wrong Image / No Provenance

• Use same image_path as generation repo field.
• Symptom: verify passes wrong artifact — image mismatch.

Policy Evaluation Failed

• Review policy set Rego rules; check Supply Chain tab for violations.
• Confirm policy set identifier (not display name) in enforce.policySets.

YAML Validation Errors

• source.type must be PascalCase for verification (Docker, not docker).
• Docker source uses image_path, not repo.
• verify_attestation: use flat type: keyless + spec.oidcProvider: harness — not nested cosign unless API rejects flat shape.
• DUPLICATE_IDENTIFIER — rename slsaverification.

CD Step Errors

• Place inside stepGroup with stepGroupInfra — not top-level execution.steps.
• See skills/generate-slsa/references/cd-containerized-step-group.md.

User Chose CD on CI-Only Pipeline

• Expected — run Phase 3b; do not force CI-only unless user changes direction.

Pipeline Run Failed

• Use /run-pipeline to execute and /debug-pipeline to diagnose failures
• Confirm verify method matches generation attestation; check public key for keybased
• Missing runtime inputs: provide branch/tag or deploy inputs via /run-pipeline or Harness UI Run

MCP Errors

• CONNECTOR_NOT_FOUND — verify connector in Project Settings.
• ACCESS_DENIED — PAT needs pipeline edit and policy read permissions.