@opengroundplan/core 0.1.1

package/catalog/sources/security-compliance.yaml

@@ -0,0 +1,613 @@
+# Groundplan template source catalog — category: security-compliance
+#
+# Research date: 2026-07-19
+#
+# PROVENANCE / VERIFICATION NOTES
+# --------------------------------
+# Every entry was verified against TWO primary sources:
+#   1. https://api.github.com/repos/{owner}/{repo} — read license.spdx_id, stargazers_count,
+#      pushed_at, archived. (The unauthenticated 60 req/hr budget was exhausted mid-pass; for
+#      the later candidates `stars` and `archived` come from the server-rendered github.com repo
+#      page and `lastCommit` from github.com/{repo}/commits/{branch}.atom. Where both sources
+#      were available they agreed exactly — gitleaks 28198, syft 9254, grype 12589 matched
+#      API vs HTML — so the HTML numbers are treated as trustworthy.)
+#   2. The raw LICENSE text from raw.githubusercontent.com, read and classified by hand.
+#      No license below is asserted from memory.
+#
+# ADVERSARIAL RE-VERIFICATION PASS — 2026-07-19
+# ---------------------------------------------
+# METHOD CAVEAT, stated plainly: the unauthenticated api.github.com budget was again exhausted
+# (0/60 remaining) for the whole of this pass, so NOT ONE number below was re-confirmed against
+# the JSON API on this run. Every figure was re-derived from three independent non-API sources:
+#   - licence  <- raw.githubusercontent.com/{repo}/{branch}/LICENSE, read in full as text
+#   - stars + archived <- the server-rendered github.com repo page (repo-stars-counter-star)
+#   - lastCommit <- github.com/{repo}/commits/{branch}.atom
+# For the licence gate specifically this is the STRONGER source, not a weaker substitute: the
+# raw text is the thing the API's spdx_id is only a lossy summary of, and reading it is exactly
+# what this catalog's rules demand whenever spdx_id is NOASSERTION/null/Other. The genuinely
+# unconfirmed field is the API's `disabled` flag, which has no HTML equivalent; all 15 repos
+# render and serve files normally, which is inconsistent with being disabled.
+#
+# All 15 entries re-checked from scratch. Raw LICENSE text re-read for every entry; all 15
+# match their recorded `spdx`. All 15 URLs return 200 and none is archived. All 15
+# star counts matched the recorded value exactly, and all 15 lastCommit dates matched the
+# commits atom feed exactly. No entry failed the license gate, so nothing was dropped.
+# The zero-drift on stars/dates is expected, not suspicious: the prior pass ran the same day.
+#
+# github/codeql was singled out for extra scrutiny (it is the only MIT entry whose value is
+# its rule content). Root holds exactly one licence file, LICENSE = MIT. The LICENSE.md that
+# appears in the rendered page is a README link to the separately-licensed
+# github/codeql-cli-binaries repo, not a second root licence. README confirms the split the
+# entry's whatToAvoid already describes: repo code MIT, CLI/engine separate commercial terms
+# for closed-source analysis. Entry stands as vendorable.
+#
+# Defects found and fixed in this pass (all path/accuracy, none license-class):
+#   * ComplianceAsCode — cited controls/cis_rhel9.yml; that path 404s. Real path is
+#     products/rhel9/controls/cis_rhel9.yml.
+#   * conftest — cited examples/terraform; no such directory. Terraform is covered by
+#     examples/hcl1 and examples/hcl2.
+#   * CycloneDX/specification — cited examples/; no such directory. Fixtures are under
+#     tools/src/test/resources/{version}/valid-*.json. Also noted spec 1.7 now exists.
+#   * helmet — said "fifteen" middlewares; actual count is fourteen.
+#   * gitleaks — said "150 rules"; config/gitleaks.toml currently carries 222 [[rules]].
+#   * syft / grype / trivy — .syft.yaml, .grype.yaml and trivy.yaml were described as files to
+#     vendor from the repos. None is checked in; they are config schemas the layer authors.
+#     Reworded so nobody wastes a pass looking for a file that isn't there.
+# Header note on semgrep/semgrep-rules was also outdated — see below; verdict unchanged.
+#
+# LICENSE SURPRISES CAUGHT BY READING THE TEXT — every one of the seven below would have been
+# mis-catalogued if the API's spdx_id or common assumption had been trusted. All seven were
+# independently re-read from raw LICENSE text on 2026-07-19 and every verdict holds; only the
+# semgrep rationale needed correcting.
+#
+#   * semgrep/semgrep-rules — spdx_id is NOASSERTION. Re-read 2026-07-19: the root LICENSE is
+#     now a one-line pointer to the "Semgrep Rules License v1.0"
+#     (https://semgrep.dev/legal/rules-license), NOT the older "LGPL 2.1 + Commons Clause" this
+#     note previously recorded. The current terms are stricter, not looser: use is limited to
+#     "your own internal business purposes" and the license "does not allow you to distribute
+#     the rules, or to make them available to others as a service". Shipping a rule file inside
+#     a generated repo is distribution. Proprietary, source-available, NOT open source.
+#     EXCLUDED. This is the single most likely mistake in this category — the rules read like
+#     MIT YAML. github/codeql is the vendorable SAST ruleset instead.
+#
+#   * renovatebot/renovate — AGPL-3.0. The shared config presets everyone cites
+#     (config:recommended, :semanticCommits, the whole `lib/config/presets/internal/` tree)
+#     live inside the AGPL repo. *Referencing* a preset by name from your own renovate.json is
+#     fine — that is use, not distribution. Copying preset JSON into a Groundplan layer is not.
+#     EXCLUDED for copying; the existing `security-supply-chain` layer's renovate.json must
+#     stay a reference-by-name config and must never inline preset bodies.
+#
+#   * trufflesecurity/trufflehog — AGPL-3.0, despite being the sibling tool everyone pairs
+#     with MIT-licensed gitleaks. EXCLUDED. gitleaks is the vendorable secret-scanning source.
+#
+#   * OWASP/ASVS and OWASP/CheatSheetSeries — both CC-BY-SA-4.0, verified from LICENSE.md.
+#     ShareAlike propagates to derivative works, so pasting ASVS requirement text or a cheat
+#     sheet into generated docs would put CC-BY-SA on the consumer's repository.
+#     REFERENCE-ONLY: read for control coverage, restate in original words, cite by URL.
+#
+#   * jeremylong/DependencyCheck — the historically-cited URL. The API now returns an ARCHIVED
+#     repo with 54 stars (a stub). The live project moved to dependency-check/DependencyCheck
+#     (7625 stars, Apache-2.0, last commit 2026-07-18). Any catalog entry pointing at the
+#     jeremylong path is a dead link in practice.
+#
+#   * slsa-framework/slsa (the spec repo, not the generator) — spdx_id NOASSERTION; the actual
+#     LICENSE.md is the Community Specification License 1.0, a standards-body license, not an
+#     OSI code license. REFERENCE-ONLY.
+#
+#   * github/advisory-database — CC-BY-4.0 (attribution, no ShareAlike). Permissive in spirit
+#     but outside the vendorable allowlist, so held at reference-only pending a policy call.
+#
+# All 15 sources below are unarchived and every one had a commit in 2026.
+# slsa-framework/slsa-github-generator is the slowest (2026-03-09) — see its whatToAvoid.
+#
+# `portability` here means CI/runtime coupling:
+#   ci-agnostic | github-actions-only | language-specific
+
+category: security-compliance
+
+sources:
+  - name: gitleaks/gitleaks
+    url: https://github.com/gitleaks/gitleaks
+    stars: 28198
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-01"
+    complexity: simple
+    stack: go, toml, pre-commit, github-actions
+    portability: ci-agnostic
+    whatToBorrow: >-
+      config/gitleaks.toml is the reference ruleset format — each rule is
+      [[rules]] with id / description / regex / entropy / keywords / tags, and
+      [[rules.allowlist]] blocks scoped per-rule rather than globally. Vendor that shape
+      wholesale for a secret-scanning layer and extend it with project-specific rules. The
+      `[extend] useDefault = true` mechanism is exactly the right pattern for a generated
+      layer: ship a tiny repo-local .gitleaks.toml that extends the built-in ruleset instead
+      of forking the 222 rules currently in config/gitleaks.toml. Also take .pre-commit-hooks.yaml (the `gitleaks` hook definition,
+      stages, entry) verbatim, and the two-mode split that matters in CI —
+      `gitleaks dir` for full-tree scans vs `gitleaks git --log-opts` for incremental
+      push/PR scans. The `--baseline-path` flag plus a committed gitleaks-report.json is the
+      cleanest brownfield-adoption story in this category.
+    whatToAvoid: >-
+      Do not fork the whole default ruleset into a layer — it churns every release and you
+      inherit the maintenance. Entropy thresholds are noisy on minified assets and lockfiles;
+      always ship an allowlist covering package-lock.json / pnpm-lock.yaml / dist/ or the
+      first run drowns the user. The v8 to v9 CLI changed subcommands (`detect`/`protect`
+      became `git`/`dir`), so never generate a workflow without pinning the action version.
+    proposedLayerIds:
+      - security-secret-scanning
+      - security-precommit-hooks
+      - ci-security-gates
+
+  - name: step-security/harden-runner
+    url: https://github.com/step-security/harden-runner
+    stars: 1228
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-07"
+    complexity: simple
+    stack: github-actions, typescript, ebpf
+    portability: github-actions-only
+    whatToBorrow: >-
+      The single highest-value four-line addition to any generated CI workflow. Borrow the
+      step shape from the README — `uses: step-security/harden-runner@<sha>` with
+      `egress-policy: audit` on first adoption, then `egress-policy: block` plus an
+      explicit `allowed-endpoints` list once the audit run has told you what the build
+      actually talks to. That audit-then-block progression is the pattern worth encoding as a
+      layer option, not just the step. Also take the repo's own
+      .github/workflows/ hardening conventions: `permissions:` declared at job level with
+      least privilege, and actions pinned by full commit SHA rather than tag — the two
+      controls OpenSSF Scorecard's Pinned-Dependencies and Token-Permissions checks grade.
+    whatToAvoid: >-
+      GitHub-hosted Ubuntu runners only — it silently no-ops on macOS, Windows, and most
+      self-hosted setups, so a layer must not present it as universal CI hardening. The
+      network monitoring backend is a hosted StepSecurity service; `egress-policy: audit`
+      ships telemetry off-box, which is a non-starter for some regulated consumers — the
+      action does expose a `disable-telemetry` input, so surface that as the layer's escape
+      hatch rather than dropping the step. Offer the whole thing as an opt-in flag with that
+      tradeoff documented, never as a silent default.
+    proposedLayerIds:
+      - ci-runner-hardening
+      - ci-github-actions
+      - security-supply-chain
+
+  - name: sigstore/gitsign
+    url: https://github.com/sigstore/gitsign
+    stars: 1110
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-13"
+    complexity: simple
+    stack: go, git, oidc, sigstore
+    portability: ci-agnostic
+    whatToBorrow: >-
+      Keyless commit signing with zero key management — the whole value is about ten lines of
+      git config that a layer can emit directly: gpg.x509.program=gitsign,
+      gpg.format=x509, commit.gpgsign=true, tag.gpgsign=true, and
+      gitsign.connectorID to pin the OIDC provider. Take that config block plus the
+      .gitsign.yaml options from the docs. The CI story is the other half: the
+      `gitsign` + ambient-credentials path means a GitHub Actions job can sign commits using
+      its OIDC token with no secret at all — borrow that as the machine-identity pattern and
+      drop the "store a GPG private key in repo secrets" antipattern most templates ship.
+    whatToAvoid: >-
+      Signatures verify against the Rekor transparency log, which means commit metadata
+      (identity, repo) is published publicly and permanently — call that out before any
+      private-repo consumer enables it. Certificates are short-lived (~10 min), so offline
+      or air-gapped verification needs the Rekor bundle stored alongside; do not promise
+      `git log --show-signature` works out of the box on a fresh clone without
+      `gitsign-credential-cache` or the verification helper configured.
+    proposedLayerIds:
+      - security-commit-signing
+      - security-supply-chain
+      - security-keyless-identity
+
+  - name: helmetjs/helmet
+    url: https://github.com/helmetjs/helmet
+    stars: 10710
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-12"
+    complexity: simple
+    stack: node, typescript, express, connect
+    portability: language-specific
+    whatToBorrow: >-
+      middlewares/ is fourteen self-contained one-header modules (content-security-policy,
+      strict-transport-security, referrer-policy, origin-agent-cluster, the three
+      cross-origin-*-policy modules, and the x-* set) — the cleanest available
+      reference for what each security header should default to and why. Read
+      middlewares/content-security-policy/index.ts for the directive-merge and
+      `useDefaults` logic, and middlewares/strict-transport-security/index.ts for the
+      maxAge/includeSubDomains/preload argument validation. Two things to lift into a
+      security-headers layer regardless of language: (a) the default directive set
+      (default-src 'self', object-src 'none', frame-ancestors 'self', base-uri 'self',
+      upgrade-insecure-requests), and (b) the per-middleware structure itself — each header
+      as an isolated, individually-togglable unit rather than one monolithic block. The
+      TypeScript option types double as documentation of every legal value.
+    whatToAvoid: >-
+      Express/Connect-coupled, so it is a spec source for anything non-Node, not a dependency.
+      The default CSP is deliberately strict and will break any app using inline scripts,
+      styles, or a CDN — a generated layer must pair it with a nonce or hash strategy and a
+      report-only rollout, or the first page load is blank. Helmet deliberately does NOT set
+      CORS, rate limiting, or cookie flags; do not let a "helmet is installed" layer imply
+      those are handled.
+    proposedLayerIds:
+      - security-headers
+      - security-csp
+      - backend-express-hardening
+
+  - name: anchore/syft
+    url: https://github.com/anchore/syft
+    stars: 9254
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    complexity: standard
+    stack: go, sbom, cyclonedx, spdx, oci
+    portability: ci-agnostic
+    whatToBorrow: >-
+      The canonical SBOM-generation layer. Note there is no .syft.yaml checked into the repo
+      to copy — the layer authors one against the documented schema. The keys worth emitting: the
+      `output:` multi-format list (emit CycloneDX JSON and SPDX JSON from one run, since
+      different consumers demand different formats), `source.name` / `source.version` for
+      stamping releases, and the `catalogers:` selection syntax for restricting scanning to
+      the ecosystems a repo actually uses. The dir: vs image: vs file: source-scheme
+      distinction is the design decision a layer must expose, because scanning a built
+      container image and scanning the source tree produce materially different SBOMs. Also
+      borrow the release-attachment pattern from the project's own .github/workflows/ —
+      generating the SBOM in CI and attaching it to the GitHub Release as a build artifact is
+      the workflow shape most consumers actually need.
+    whatToAvoid: >-
+      Output format schemas move; never pin a downstream consumer to a raw syft JSON
+      document (the native format is explicitly unstable) — always emit standard CycloneDX or
+      SPDX. Catalogers are heuristic and undercount vendored/statically-linked and
+      dynamically-loaded dependencies, so an SBOM from here is an input to a review, not a
+      compliance guarantee. Full-tree scans on large monorepos are slow enough to need their
+      own scheduled workflow rather than a PR-blocking step.
+    proposedLayerIds:
+      - security-sbom
+      - security-sbom-cyclonedx
+      - security-supply-chain
+      - release-automation
+
+  - name: anchore/grype
+    url: https://github.com/anchore/grype
+    stars: 12589
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    complexity: standard
+    stack: go, sbom, vulnerability-db, oci
+    portability: ci-agnostic
+    whatToBorrow: >-
+      The other half of the syft pairing, and the piece that turns an SBOM from a document
+      into a gate. .grype.yaml is authored by the layer, not copied from the repo (none is
+      checked in): `fail-on-severity` is the CI gate
+      knob, and the `ignore:` block is the most important pattern in the whole category —
+      entries keyed by vulnerability id plus a `package:` scope, which lets a team suppress a
+      specific unreachable CVE in a specific dependency without disabling the scanner. Pair
+      that with an expiry-review convention (a comment carrying a re-review date on each
+      ignore) and you have a defensible exception process. Borrow the
+      `syft ... -o json | grype` piping pattern too: scan the SBOM you already published,
+      not the filesystem again, so the gate and the published artifact can never disagree.
+    whatToAvoid: >-
+      Grype downloads a vulnerability DB on every run — an unpinned CI job is
+      network-dependent and will start failing builds the day an unrelated CVE is published.
+      Ship `GRYPE_DB_AUTO_UPDATE` and a cached DB path as layer options. Findings are matched
+      by package coordinates, so false positives on distro-backported patches are routine;
+      never wire fail-on-severity below `high` as a default or the first PR is blocked.
+    proposedLayerIds:
+      - security-vulnerability-scanning
+      - security-sbom
+      - ci-security-gates
+
+  - name: CycloneDX/specification
+    url: https://github.com/CycloneDX/specification
+    stars: 524
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-08"
+    complexity: standard
+    stack: json-schema, xsd, protobuf, sbom
+    portability: ci-agnostic
+    whatToBorrow: >-
+      The schema itself, and it is Apache-2.0 — unusually permissive for a standard, so the
+      JSON Schema files under schema/ (bom-1.6.schema.json and the SPDX licence enum it
+      references) can be vendored directly into a layer for offline validation instead of
+      shelling out to a tool. That gives a generated repo a `validate-sbom` step with no
+      network and no binary dependency. Beyond SBOM, borrow the parts most templates ignore:
+      the `vulnerabilities[]` object (VEX — asserting a CVE is not_affected with a
+      justification, which is the machine-readable form of the exception process grype's
+      ignore list handles informally), and `compositions[]` for declaring SBOM completeness
+      (`aggregate: incomplete` is an honest answer). There is no examples/ directory — the
+      golden-file fixtures live under tools/src/test/resources/{version}/, e.g.
+      tools/src/test/resources/1.6/valid-bom-1.6.json and the valid-compositions-1.6.json /
+      valid-attestation-1.6.json siblings, which are minimal valid documents per feature.
+    whatToAvoid: >-
+      A spec repo, not a tool — it emits nothing. Version drift is the trap: 1.4, 1.5, 1.6 and
+      now 1.7 (schema/bom-1.7.schema.json is published) differ in required fields and many
+      consumers still only ingest 1.4, so a layer must make the spec version an explicit,
+      pinned option rather than "latest". Do not hand-author
+      BOMs against the schema; generate with syft or a native language plugin and use the
+      schema only to validate.
+    proposedLayerIds:
+      - security-sbom-cyclonedx
+      - security-vex
+      - security-sbom
+
+  - name: ossf/scorecard
+    url: https://github.com/ossf/scorecard
+    stars: 5587
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-15"
+    complexity: standard
+    stack: go, github-actions, sarif, probes
+    portability: github-actions-only
+    whatToBorrow: >-
+      Use it as the requirements document for what a hardened repository looks like — each
+      check under checks/ (Branch-Protection, Token-Permissions, Pinned-Dependencies,
+      Dangerous-Workflow, Signed-Releases, Dependency-Update-Tool, Fuzzing, SAST) is a
+      concrete, gradeable control that maps one-to-one onto a Groundplan layer. docs/checks.md
+      is effectively the spec: read it and generate repos that already score well instead of
+      scoring them afterwards. Concretely borrow the scorecard workflow shape — scheduled
+      cron run, `results_format: sarif`, and upload via github/codeql-action/upload-sarif so
+      findings land in the Security tab rather than a log. checks/raw/ shows how each control
+      is actually detected, which tells you exactly what file content satisfies it.
+    whatToAvoid: >-
+      The score is a heuristic, not a security posture — Dependency-Update-Tool passes on the
+      mere presence of a renovate.json, and Fuzzing/CII-Best-Practices are structurally
+      unreachable for most small repos, so a low score is often correct and fine. Do not
+      generate a "get to 10/10" checklist. The action needs a repo token with elevated read
+      scope and, for private repos, extra setup; it is GitHub-specific and gives nothing on
+      GitLab or Bitbucket.
+    proposedLayerIds:
+      - security-posture-scorecard
+      - security-supply-chain
+      - ci-github-actions
+
+  - name: open-policy-agent/conftest
+    url: https://github.com/open-policy-agent/conftest
+    stars: 3224
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    complexity: standard
+    stack: go, rego, opa, yaml, terraform
+    portability: ci-agnostic
+    whatToBorrow: >-
+      The generic "assert things about config files" engine — the right tool when a
+      compliance rule is repo-specific and no off-the-shelf scanner covers it. Borrow the
+      policy/ convention and the deny/warn/violation rule naming contract from
+      examples/ (a `deny[msg]` rule that returns a message is a failure; `warn` is advisory),
+      plus the `conftest test --policy policy/ --all-namespaces` invocation. The
+      examples/ tree is the real asset: examples/kubernetes, examples/docker (Dockerfile
+      linting in Rego), examples/hcl1 and examples/hcl2 (which is where Terraform is covered —
+      there is no examples/terraform), plus examples/serverless, examples/kustomize and
+      examples/spdx give working starting policies per artifact type. Also take `conftest verify` and the *_test.rego pattern —
+      policies that are themselves unit-tested is the differentiator versus a pile of
+      ungoverned YAML lint rules. `conftest push`/`pull` bundling policies as OCI artifacts is
+      the model for sharing an org-wide policy set across generated repos.
+    whatToAvoid: >-
+      Rego is a genuine language with a real learning curve and non-obvious semantics
+      (partial rules, unification, iteration) — a layer that emits Rego a team cannot maintain
+      is worse than no layer. Reach for it only after checkov/trivy's built-in checks are
+      exhausted. Parser coverage varies by format: HCL2 and Dockerfile inputs are structured
+      differently than you would guess, so always inspect `conftest parse <file>` output
+      before writing a rule against it.
+    proposedLayerIds:
+      - security-policy-as-code
+      - compliance-policy-rego
+      - ci-security-gates
+
+  - name: aquasecurity/trivy
+    url: https://github.com/aquasecurity/trivy
+    stars: 36974
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-16"
+    complexity: professional
+    stack: go, oci, iac, sbom, sarif, kubernetes
+    portability: ci-agnostic
+    whatToBorrow: >-
+      The one scanner that covers vulnerabilities, IaC misconfiguration, secrets, and licence
+      detection in a single binary — the highest-coverage-per-line choice for a generated
+      repo. Author trivy.yaml against the documented config schema (no such file is checked
+      into the repo to copy) — the `scan.scanners` list, `severity`
+      floor, and `exit-code` gate — plus .trivyignore / the newer .trivyignore.yaml, which is
+      the better exception format because each entry carries a `statement` and an
+      `expired_at` date — time-boxed suppressions that expire on their own. Borrow the
+      `--format sarif` + upload-sarif CI step so results land in code scanning. Its
+      filesystem/repo/image/k8s target modes map cleanly onto separate layer options, and
+      `--scanners license` is a rarely-templated but genuinely useful compliance gate for
+      exactly the dependency-licence problem this catalog exists to manage.
+    whatToAvoid: >-
+      Very large surface — turning on all scanners by default produces hundreds of findings on
+      a first run and trains people to ignore it. Generate with a narrow scanner set and a
+      `severity: HIGH,CRITICAL` floor. The vulnerability DB is pulled from a container
+      registry and has been rate-limited in the past; pin `TRIVY_DB_REPOSITORY` and cache the
+      DB in CI. Misconfiguration checks live in a separate policy bundle whose IDs change
+      between releases, so never hardcode a check ID in a gate without pinning the version.
+    proposedLayerIds:
+      - security-vulnerability-scanning
+      - security-iac-scanning
+      - security-license-compliance
+      - ci-security-gates
+
+  - name: sigstore/cosign
+    url: https://github.com/sigstore/cosign
+    stars: 6142
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    complexity: professional
+    stack: go, oci, oidc, in-toto, rekor
+    portability: ci-agnostic
+    whatToBorrow: >-
+      The reference implementation of artifact signing and, more importantly, of *verifying*
+      at admission time. Borrow three concrete things: (1) the keyless CI signing step —
+      `cosign sign --yes <image>@<digest>` with `id-token: write` permission and no stored
+      key at all; (2) `cosign attest --predicate sbom.json --type cyclonedx`, which
+      binds the syft-generated SBOM to the image digest so the SBOM cannot be swapped; and
+      (3) the verification side, `cosign verify --certificate-identity-regexp` +
+      `--certificate-oidc-issuer`, which is the step nearly every template omits and the
+      only one that actually provides security. Always sign by digest, never by tag — that
+      discipline is visible throughout their own release workflow and is worth encoding as a
+      lint rule in the layer.
+    whatToAvoid: >-
+      Signing without a matching verification policy is theatre; do not ship a layer that only
+      signs. Public-good Rekor and Fulcio are free services with rate limits and no uptime
+      guarantee — regulated consumers need self-hosted or a documented acceptance of that
+      dependency, and every signature is a permanent public transparency-log entry. The CLI
+      has had breaking flag changes across v1/v2 (notably around `--certificate-identity`),
+      so pin the version in generated workflows.
+    proposedLayerIds:
+      - security-artifact-signing
+      - security-attestation
+      - security-supply-chain
+      - release-automation
+
+  - name: github/codeql
+    url: https://github.com/github/codeql
+    stars: 9847
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    complexity: professional
+    stack: ql, java, javascript, python, go, csharp, ruby, rust
+    portability: github-actions-only
+    whatToBorrow: >-
+      The query packs and the query *suites* — MIT-licensed, which makes this the vendorable
+      SAST ruleset in a category where the obvious alternative (Semgrep community rules) is
+      not. Per language, {lang}/ql/src/codeql-suites/{lang}-security-extended.qls and
+      -security-and-quality.qls define the graduated rulesets a layer should expose as an
+      option (default / extended / security-and-quality), and reading a .qls file shows the
+      include/exclude-by-tag mechanism worth mirroring for any rule selection UI. Borrow the
+      .github/codeql/codeql-config.yml shape: `paths-ignore` for vendored and generated code,
+      `queries:` to add a pack, and `packs:` for versioned dependencies. The
+      qlpack.yml + CodeQL pack versioning model is a good template for distributing
+      security rules as pinned, versioned artifacts rather than copied files.
+    whatToAvoid: >-
+      The MIT LICENSE covers this repository's queries and libraries — the CodeQL CLI and
+      engine are distributed under separate GitHub terms that restrict use outside GitHub
+      Advanced Security / public repos. So the rules are vendorable; the runtime is not, and a
+      layer must not imply private-repo CI use is free. Writing custom QL is a deep
+      specialisation — consume the packs, do not template new queries. Analysis is slow
+      (compiled-language builds especially), so schedule it rather than blocking every PR.
+    proposedLayerIds:
+      - security-sast-codeql
+      - security-sast
+      - ci-security-gates
+
+  - name: slsa-framework/slsa-github-generator
+    url: https://github.com/slsa-framework/slsa-github-generator
+    stars: 587
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-03-09"
+    complexity: professional
+    stack: github-actions, go, in-toto, sigstore
+    portability: github-actions-only
+    whatToBorrow: >-
+      Working, audited build-provenance generation — the concrete implementation of SLSA Build
+      L3, which the spec repo only describes. The reusable workflows under
+      .github/workflows/generator_generic_slsa3.yml and the language builders
+      (builder_go_slsa3.yml, the container generator) are callable directly with `uses:` and
+      one `permissions:` block (id-token: write, contents: write, actions: read) — a layer
+      can emit a five-line caller job instead of reimplementing provenance. Borrow the
+      two-job separation that makes L3 possible: an untrusted build job that emits artifact
+      digests, and an isolated trusted job that signs the provenance, so a compromised build
+      step cannot forge its own attestation. Pair with slsa-verifier for the verification
+      half.
+    whatToAvoid: >-
+      Slowest-moving source in this list (last commit 2026-03-09) — still maintained and
+      widely used, but check for an active release before generating against it, and consider
+      GitHub's native `actions/attest-build-provenance` as the lighter-weight alternative for
+      simple cases. Hard-bound to GitHub Actions with no portable equivalent, and reusable
+      workflows must be referenced by tag/SHA of *this* repo to keep the trust boundary, which
+      makes upgrades a deliberate act.
+    proposedLayerIds:
+      - security-build-provenance
+      - security-slsa
+      - security-supply-chain
+      - release-automation
+
+  - name: ComplianceAsCode/content
+    url: https://github.com/ComplianceAsCode/content
+    stars: 2769
+    spdx: BSD-3-Clause
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    complexity: enterprise
+    stack: yaml, jinja2, ansible, bash, scap, openscap
+    portability: ci-agnostic
+    whatToBorrow: >-
+      The most mature open-source answer to "compliance as code", and BSD-3-Clause so it is
+      actually copyable. The structural idea is the prize: a single control definition
+      compiles into an OVAL check, an Ansible remediation task, and a bash remediation, and a
+      *profile* is just a list of rule ids. Read linux_os/guide/**/rule.yml for the rule
+      schema (title, rationale, severity, identifiers, references keyed by framework) and
+      products/rhel9/controls/cis_rhel9.yml plus products/rhel9/profiles/*.profile (cis.profile,
+      stig.profile, pci-dss.profile) for how one rule body
+      satisfies CIS, STIG, PCI-DSS, and NIST-800-53 simultaneously through the `references:`
+      map. That many-frameworks-from-one-control-body model is exactly what a compliance layer
+      should implement, even if none of the OS content itself is used. Also borrow the
+      remediation-alongside-check convention — a finding that ships its own fix.
+    whatToAvoid: >-
+      Enormous (tens of thousands of files) and almost entirely about hardening RHEL/Ubuntu/
+      container hosts — essentially none of the rule content applies to an application repo.
+      Take the schema and the profile-composition pattern; do not vendor the guide tree. The
+      build system (CMake + Jinja2 + SCAP toolchain) is heavy and not worth reproducing. SCAP
+      and OVAL are dated formats — model new work on OSCAL instead.
+    proposedLayerIds:
+      - compliance-as-code
+      - compliance-control-mapping
+      - security-hardening-baseline
+      - audit-log
+
+  - name: oscal-compass/compliance-trestle
+    url: https://github.com/oscal-compass/compliance-trestle
+    stars: 264
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-02"
+    complexity: enterprise
+    stack: python, oscal, pydantic, json, markdown
+    portability: ci-agnostic
+    whatToBorrow: >-
+      OSCAL (NIST's machine-readable control language) is where compliance-as-code is heading,
+      and this is the only well-maintained permissive toolchain for it. Two borrowable ideas:
+      (1) the Pydantic models generated from the OSCAL schemas under trestle/oscal/ — a
+      typed, validated representation of catalogs, profiles, component-definitions, and SSPs,
+      which is the right internal shape for any compliance layer that has to emit evidence;
+      and (2) the `trestle author` markdown round-trip — controls are edited by humans as
+      markdown with YAML headers and compiled back to canonical OSCAL JSON, solving the
+      perennial "auditors want prose, tooling wants JSON" split. The
+      component-definition → SSP assembly flow is the model for auto-generating a System
+      Security Plan from what a repo's layers actually configured, which is the real prize
+      for a template generator serving regulated consumers.
+    whatToAvoid: >-
+      Small community (264 stars) and a steep conceptual ramp — OSCAL's catalog/profile/
+      component/SSP model must be understood before any of the tooling is usable, and getting
+      it wrong produces confidently-wrong compliance artifacts. Python-only with a heavy
+      dependency tree; do not make it a runtime dependency of a generated repo, use it as a
+      build-time evidence generator. Only justified when a consumer has a real FedRAMP /
+      NIST-800-53 obligation; for everyone else it is enormous overhead.
+    proposedLayerIds:
+      - compliance-oscal
+      - compliance-as-code
+      - compliance-evidence-generation
+      - audit-log