generate-slsa — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited generate-slsa (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
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 · Submit
harness_get before placement/source questions.provenance / SscaOrchestration steps (UI: SLSA Generation).harness_update only after user confirms.harness_update, provide a configuration summary andpoint 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 |
#### Extract connectors from pipeline YAML
From BuildAndPushDockerRegistry, BuildAndPushECR, Run, Plugin, SscaOrchestration, provenance (SLSA Generation), or SscaArtifactSigning steps — reuse connectorRef / connector.
#### Generate SLSA step YAML
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.
#### Insert step into pipeline YAML
generate_sbom when both exist).slsageneration (suffix _cd in CD when CI already has one).stepGroup.steps 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, read the API message, fix fields (often repo vs image, attestation spec), retry.
#### Provide summary
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.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.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.