Add a SLSA Generation step (YAML type: provenance) to an existing Harness pipeline to generate SLSA provenance and optionally attest with Cosign (keyless, key-based, or Vault). Supports container images (Docker, ECR, GCR, GAR, ACR, HAR) and Harness Local Stage artifacts. Place after image build/push; run sequentially after SBOM steps, not in parallel. Only works with existing pipelines. Use when asked to generate SLSA, add SLSA provenance, SLSA Generation step, attest SLSA, or configure SLSA Level 3 provenance in a pipeline. Trigger phrases: generate SLSA, SLSA generation, add SLSA step, SLSA provenance, attest SLSA, SlsaGeneration, provenance step, SLSA attestation, add provenance step.
75
94%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Passed
No findings from the security scan
Add a SLSA Generation step to an existing Harness pipeline to generate SLSA provenance and
optionally attest/sign the .att file in the container registry. Pipeline YAML uses
type: provenance (UI label: SLSA Generation; do not use SlsaGeneration — API rejects it).
This skill only works with existing pipelines — do not create standalone SLSA-only pipelines.
Prerequisites: Image must be built and pushed (or available in registry) before SLSA runs.
Key-based attestation requires Cosign key pair secrets (/create-secret). Harness Cloud builds
enable SLSA Level 3 provenance when using hosted infrastructure.
Guide the user through a step-by-step interactive wizard (same UX as /configure-repo-scan):
references/interactive-wizard-flow.mdreferences/slsa-generation-step.mdreferences/cd-containerized-step-group.mdAskQuestion when available; otherwise numbered options with (Recommended).Pipeline · Placement · Source · Details · Attestation · Submitharness_get before placement/source questions.provenance / SscaOrchestration steps (UI: SLSA Generation).harness_update only after user confirms.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).SscaOrchestration exists, place SLSA after it; never parallel (Cosign race).stepGroup only — see CD reference.Full phase prompts: references/interactive-wizard-flow.md.
| Phase | Breadcrumb | Action |
|---|---|---|
| 0 | Pipeline | AskQuestion: pipeline URL ready? |
| 1 | Pipeline | Collect URL → harness_get |
| 2 | Pipeline | Display structure; note build/push + SBOM steps |
| 3 | Placement | Mandatory AskQuestion: stage + position (after build/push recommended) |
| 3b | Placement (CD) | Service, env, infra, step group if new Deploy stage |
| 4 | Source | AskQuestion: Third-Party, HAR, or Local |
| 5 | Source | AskQuestion: registry provider (Third-Party only) |
| 6 | Details | Connector (skip if obvious) |
| 7 | Details | Image/repo; optional digest expression |
| 8 | Attestation | AskQuestion: keyless, keybased, vault, or none |
| 9 | Submit | AskQuestion: confirm pipeline update |
After Phase 9 confirm → generate YAML, insert step, harness_update, then provide summary (do not run the pipeline).
| Stage type | Placement notes |
|---|---|
CI | Recommended — immediately after BuildAndPush* or image push Run step |
Deployment | Containerized step group only; before deploy — uncommon for generation |
Security | End of stage when scanning pre-built registry images |
From BuildAndPushDockerRegistry, BuildAndPushECR, Run, Plugin, SscaOrchestration,
provenance (SLSA Generation), or SscaArtifactSigning steps — reuse connectorRef / connector.
Use only wizard answers. Default attestation: keyless Harness OIDC when user chose defaults.
Docker Registry — matches reference UI (key-based attestation):
- step:
identifier: slsageneration
name: slsa-generation
type: provenance
spec:
source:
type: docker
spec:
connector: lavakush07
repo: lavakush07/easy-buggy-app:blog
attestation:
type: keybased
spec:
privateKey: account.cosign_private_key
password: account.cosign_password
timeout: 15mKeyless attestation (default for “use defaults”):
attestation:
type: keyless
spec:
oidcProvider: harnessWith digest from Build and Push:
source:
type: docker
spec:
connector: <docker_registry_connector>
repo: <org>/<repo>:<tag>
digest: <+pipeline.stages.<stage>.spec.execution.steps.<build_step>.output.outputVariables.digest>Amazon ECR:
source:
type: ecr
spec:
connector: <registry_connector>
image: <repo/name>
region: <aws_region>
account: <aws_account_id>Google GCR / GAR / Azure ACR / HAR / Local: see references/slsa-generation-step.md.
No attestation: omit attestation block.
generate_sbom when both exist).slsageneration (suffix _cd in CD when CI already has one).stepGroup.steps only.harness_update
resource_type: pipeline
resource_id: <pipeline_identifier>
org_id: <organization>
project_id: <project>
body: { yamlPipeline: "<updated pipeline YAML>" }On validation errors, read the API message, fix fields (often repo vs image, attestation spec), retry.
Report the results to the user (same pattern as /configure-repo-scan — do not execute the pipeline):
## SLSA Generation Configured
**Pipeline:** <pipeline_name>
**Step:** SLSA Generation (`provenance`)
**Location:** Stage "<stage_name>", <position>
**Source:** docker — <connector> — <repo/image>
**Attestation:** Key-based (account.cosign_private_key) — or as configured
**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 Generation step in Pipeline Studio to adjust Advanced settings.
**Provenance:** After a successful run, view on the Supply Chain tab and in SCS Artifacts.
### Next Steps
1. Run the pipeline via `/run-pipeline` to verify the SLSA Generation step executes successfully
2. If the run fails, diagnose with `/debug-pipeline`
3. Add SLSA verification with `/enforce-slsa`
4. Pair with `SscaOrchestration` (Generate SBOM) — run SBOM then SLSA sequentially
5. 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.
/generate-slsa
Add SLSA Generation to my CI pipeline after docker push — lavakush07/easy-buggy-app:blog, key-based attest with account cosign secrets/generate-slsa
Use defaults — keyless Harness OIDC after Build_and_Push step/generate-slsa
Generate SLSA for image from Build_and_Push digest output — keyless attest/generate-slsa
add slsa to the pipelineAgent must still run Phase 2 + Phase 3 — do not assume stage or skip placement.
references/interactive-wizard-flow.md.type is provenance — not SlsaGeneration (API enum rejects SlsaGeneration).source.spec.repo (not image; SBOM SscaOrchestration uses image for docker)./create-secret)./enforce-slsa; see CD reference./run-pipeline after configuration (same as /configure-repo-scan)./manage-supply-chain instead.harness_list (resource_type: pipeline).connectorRef; harness_search for Docker registry connectors.repo string — e.g. lavakush07/easy-buggy-app:blog.ecdsa-p256..att upload..att in registry — steps ran in parallel.provenance (SLSA Generation) in Deploy stages must be inside stepGroup with stepGroupInfra.references/cd-containerized-step-group.md.SlsaGeneration Step Typedoes not have a value in the enumeration for SlsaGeneration.type: provenance — validate with harness_schema(resource_type="pipeline", path="steps")./run-pipeline to execute and /debug-pipeline to diagnose failures/run-pipeline or Harness UI Run — do not guess runtime inputsCONNECTOR_NOT_FOUND — verify connector identifier.ACCESS_DENIED — PAT needs pipeline edit permission.23e9b8b
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.