agentsclimarketplace

Supply chain defense

Skill Amey-Thakur/AI-SKILLS/skills/security/supply-chain-defense

Plug-and-play skills and prompts for every AI coding agent

Install
npx -y skills add Amey-Thakur/AI-SKILLS --skill supply-chain-defense

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 18 days oldThe repository was created 18 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Harden the build pipeline by pinning what runs, generating provenance, and signing artifacts so tampering shows. Use when securing a CI/CD workflow, setting up artifact signing, or reviewing how releases are built and shipped.

SKILL.md

2.8 KB, as published. Nobody here has run it

Supply chain defense

The build pipeline is a privileged machine that turns source into artifacts your users trust, and it runs third-party code on every push. If an attacker edits a build step, swaps a base image, or repoints a tag, the malicious output ships signed and looks legitimate. Hardening means pinning what runs, proving where each artifact came from, and signing it so tampering is detectable.

Method

  1. Pin CI actions to a commit SHA, not a tag. Write uses: actions/checkout@<40-char-sha> instead of @v4. A tag is mutable and can be repointed at malicious code; a commit cannot. Let Dependabot bump the SHAs so pinning does not go stale.
  2. Lock base images by digest. Reference container bases as image@sha256:... in Dockerfiles and CI, never :latest. Rebuilds then use the bytes you reviewed instead of whatever the tag points at today.
  3. Grant the pipeline least privilege. Set permissions: contents: read at the top of a GitHub Actions workflow and widen per job only where a step truly needs write or id-token. A compromised step then cannot push to the repo or mint a release.
  4. Generate provenance for every artifact. Produce a SLSA provenance attestation with slsa-github-generator or cosign attest, recording the source commit, builder, and inputs. Consumers can then verify the artifact came from the commit you claim, not from someone's laptop.
  5. Sign artifacts and verify on deploy. Sign images and packages with Sigstore cosign (cosign sign), keyless through OIDC where possible, and gate deployment on cosign verify. An unsigned or wrongly signed artifact never reaches production.
  6. Keep secrets away from untrusted triggers. Do not expose deployment or signing secrets to pull_request workflows from forks. A fork PR must not be able to read the key that signs your releases.

Checks

  • Does every uses: and base image reference resolve to a SHA or digest, with zero floating tags?
  • Can you verify a production artifact's provenance back to a specific source commit?
  • Does the deploy step reject an artifact whose cosign signature fails?
  • Do fork pull requests run without access to release or deploy credentials?

Boundaries

This hardens how artifacts are built and released, not the third-party source that goes in (see dependency-auditing) or the runtime that executes the output. Provenance proves origin, not that the source was safe. Follow your platform's mandated attestation format where one exists.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.