Match the pipeline component index to the catalog

Andrew Dunnrequested to merge
standards/pipeline-component-index into main

Standard

pipeline

Change type

  • Add new standard
  • Modify existing standard (prose only)
  • Modify existing standard's check.sh (add, remove, or change an assertion)
  • Modify existing standard's templates
  • Status transition: introduced -> enforcing
  • Status transition: enforcing -> archived
  • Retire / archive

What does this MR do and why?

I want the component index to match the catalog, because a reader assembling a pipeline from it gets an image with no signing step and a binary input that does not exist.

The catalog at v6.4.1 ships 24 components. The index listed 16:

  • Nine missing, among them container-sign, which signs the digests container no longer signs.
  • fips_features is not a binary input and never has been in catalog history. A Federal Information Processing Standards (FIPS) build comes from build_image, such as ci-go-fips.
  • build-container-buildah was retired in v4.0.0, and no buildkit or kaniko directory has ever existed.
  • Three rows described work their component does not do: verify checks image signatures only, extra-assets links any package-registry file, and container-scan-summary summarizes a scan rather than running one.

Each row now comes from its component's own description:.

Failure mode this addresses

An image built from the index ships unsigned, and a FIPS build copied from it passes binary an input it does not declare.

Assertion deltas

None. check.sh is unchanged.

Consumer impact

None fail.

Status transition

None.

Test plan

  • just guard passes (assertions use only closed primitives)
  • just check-one STANDARD=pipeline passes against this repo; just ship green, TOTAL: 21 standard(s) passed, 0 exempt, 0 failed
  • Ran check.sh against at least one consumer repo of each applicable shape (binary-shipping, lab); results match expectations: not applicable, prose only
  • CHANGELOG updated

An AI tool wrote this change and ran the checks above.

Reviewer checklist

  • SKILL.md frontmatter is valid YAML (name, description, status, [enforced_since])
  • check.sh sources ../../_lib.sh correctly
  • check.sh calls report at the end
  • Templates/ directory present where applicable
  • Standard appears in README's contracts table
  • Standard appears in the rendered site's /standards/ index

Merge request reports