Harden
Run language-agnostic hardening checks on lockfiles, CI scanners, secrets, containers, and SBOM posture before you ship or iterate in production.
Overview
Harden is an agent skill most often used in Ship (also Build integrations, Operate infra) that runs cross-cutting dependency, secret, CI/CD, container, and SBOM hardening checks against concrete repo signals.
Install
npx skills add https://github.com/athola/claude-night-market --skill hardenWhat is this skill?
- Seven dependency posture checks (DEP01–DEP07) spanning lockfiles, CI scanners, pinning, hashes, and license policy
- Secret hygiene checks (SEC01–SEC04) for pre-commit scanners, .gitignore, and CI secret exposure patterns
- Composes leyline:supply-chain-advisory for known-bad version blocking (DEP03)
- Container shape and SBOM checks alongside CI/CD chain review (cross-cutting, not language-specific)
- Detection-oriented table: each row maps ID, CWE/NIST refs, and concrete repo signals to look for
- 7 dependency posture checks (DEP01–DEP07)
- 4 secret hygiene checks (SEC01–SEC04)
Adoption & trust: 1 installs on skills.sh; 304 GitHub stars; trending (+100% hot-view momentum).
What problem does it solve?
You are about to ship but have no consistent way to verify lockfiles, CI audit steps, secret scanners, and supply-chain pinning across Python, Rust, and Node in one pass.
Who is it for?
Solo builders and tiny teams who want a repeatable security posture review across polyglot repos before production cutover.
Skip if: Teams that already enforce the same controls org-wide via a dedicated AppSec platform and only need language-specific SAST—not a markdown checklist skill.
When should I use this skill?
You need a cross-language hardening pass on dependencies, secrets, CI/CD, containers, or SBOM before ship or after infra changes.
What do I get? / Deliverables
You get a prioritized checklist of DEP/SEC-style gaps mapped to CWE and detection heuristics so you can harden the repo before merge or deploy.
- Prioritized hardening gap list keyed by check IDs
- Action items mapped to CWE/NIST-style references
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Shipping is where dependency, secret, and CI chain gaps become exploitable; this skill is shelved under security as the canonical pre-release hardening pass. Security subphase covers supply-chain posture, secret hygiene, and pipeline controls—the exact cross-cutting table this skill encodes.
Where it fits
Verify Dependabot and pip-audit or cargo audit steps exist before merging the GitHub Actions workflow.
Walk DEP01–DEP07 and SEC01–SEC04 immediately before tagging a production release.
Re-run container and SBOM checks after changing base images or deployment manifests.
How it compares
Structured cross-cutting audit tables—not a single-language linter or a one-click hosted scanner product.
Common Questions / FAQ
Who is harden for?
Indie developers and small teams shipping SaaS, APIs, or CLIs who need dependency, secret, and CI chain checks without a full enterprise GRC stack.
When should I use harden?
During Ship security review before release, when wiring Build integrations and CI, and during Operate infra iteration after dependency or workflow changes.
Is harden safe to install?
It is procedural guidance for reviewing your repo; review the Security Audits panel on this Prism page before trusting any third-party skill package in your agent.
SKILL.md
READMESKILL.md - Harden
# Cross-Cutting Hardening Checks Checks that apply regardless of the source language: dependency posture, secret hygiene, CI/CD chain, container shape, and the SBOM. ## Dependency posture (composes leyline:supply-chain-advisory) | ID | Check | CWE / NIST | Detection | |----|-------|------------|-----------| | DEP01 | Lockfile committed | PW.4 | absence of `uv.lock` / `Cargo.lock` / `package-lock.json` | | DEP02 | Dependency scanner runs in CI | RV.1 | no `pip-audit`/`cargo audit`/`npm audit` step in workflows | | DEP03 | Known-bad versions blocked | CWE-829 | `leyline:supply-chain-advisory` blocklist not consulted | | DEP04 | Auto-update bot configured | RV.1 | no `dependabot.yml` / `renovate.json` | | DEP05 | Direct deps pinned to exact versions | CWE-494 | `^1.2` / `~1.2` / `1.2.*` for security-critical deps | | DEP06 | Hash-pinned for top-tier supply-chain trust | CWE-494 | `--require-hashes` not used in `pip` / `requirements.txt` | | DEP07 | License policy enforced | none | no `cargo deny` license rules / no `pip-licenses` check | ## Secret hygiene | ID | Check | CWE | Detection | |----|-------|-----|-----------| | SEC01 | Pre-commit secret scanner installed | CWE-798 | no `gitleaks` / `trufflehog` / `talisman` in `.pre-commit-config.yaml` | | SEC02 | `.env` files git-ignored | CWE-200 | `.env` tracked or unmatched in `.gitignore` | | SEC03 | Long-lived secrets in CI | CWE-798 | `secrets.SOME_KEY` used without `if: github.event_name != 'pull_request'` | | SEC04 | OIDC publishing configured | CWE-798 | PyPI/Cargo publish step uses `password:` rather than OIDC `id-token: write` | | SEC05 | Audit trail for secret access | PW.7 | repo settings: secret-access logs not retained | | SEC06 | Sealed-secrets / secret manager | CWE-798 | secrets baked into config files instead of fetched from a manager | ## CI/CD chain (GitHub Actions example) | ID | Check | NIST SSDF | Detection | |----|-------|-----------|-----------| | CI01 | Third-party actions pinned by SHA, not tag | PW.4 | `uses: foo/bar@v1` instead of `@<full SHA>` | | CI02 | `permissions:` block per workflow | PW.4 | top-level `permissions:` missing or `permissions: write-all` | | CI03 | `GITHUB_TOKEN` minimum scope | PW.4 | default permissions used when `contents: read` would suffice | | CI04 | Concurrency cancel for stale runs | RV.2 | no `concurrency.cancel-in-progress: true` | | CI05 | Workflow dispatch requires approval for protected branches | PW.4 | branch protection allows direct dispatch | | CI06 | SLSA provenance generated for releases | RV.2 | release workflow does not invoke `slsa-framework/slsa-github-generator` | | CI07 | SBOM generated and attached to releases | RV.2 | release workflow lacks `cyclonedx`/`syft`/`spdx-sbom-generator` step | ## Container hardening (when Dockerfiles exist) | ID | Check | CWE | Detection | |----|-------|-----|-----------| | CO01 | Non-root `USER` set | CWE-269 | `USER root` or `USER` directive missing | | CO02 | `FROM` is digest-pinned | CWE-494 | `FROM ubuntu:22.04` instead of `FROM ubuntu@sha256:...` | | CO03 | Distroless or slim base for production | PW.4 | `FROM ubuntu:latest` / `FROM debian:latest` for runtime image | | CO04 | Read-only root filesystem in compose | CWE-269 | `read_only: true` not set | | CO05 | seccomp/apparmor profile referenced | CWE-269 | runtime config lacks profile | | CO06 | Multi-stage build to drop build deps | CWE-665 | single-stage `FROM` keeps `gcc`, `make`, etc. in runtime | | CO07 | `HEALTHCHECK` defined | none | no liveness signal (operational hygiene) | ## SBOM and provenance ```bash # CycloneDX SBOM for the whole repo syft . -o cyclonedx-json > sbom.cdx.json # SPDX SBOM (alternative format) syft . -o spdx-json > sbom.spdx.json # Verify against the in-toto attestation if released cosign verify-attestation --type slsaprovenance \ --certificate-identity-regexp '.*' --certificate-oidc-issuer-regexp '.*' \ ghcr.io/<org>/<image>:<tag> ``` The hardening report includes an SBOM-covera