create-daloy 0.34.3 → 0.35.0

package/templates/_ci/deno/_github/workflows/opengrep.yml

@@ -0,0 +1,137 @@
+# Opengrep — second SAST engine, complementing CodeQL.
+#
+# Why this exists in your scaffolded Daloy (Deno) project:
+#   Daloy itself runs two SAST engines (CodeQL + Opengrep) because no
+#   single rule corpus catches everything. Opengrep is the LGPL-2.1
+#   community fork of Semgrep, ships Semgrep-compatible rules, and is
+#   backed by an open consortium. See Aikido's "Ultimate SAST Guide"
+#   (https://www.aikido.dev/blog/ultimate-sast-guide-static-application-security-testing)
+#   and "Launching Opengrep" (https://www.aikido.dev/blog/launching-opengrep-why-we-forked-semgrep).
+#
+#   Pairing CodeQL (semantic, dataflow-heavy) with Opengrep
+#   (pattern-based AST matching, community rule packs) gives
+#   defense-in-depth at the source layer — the same posture Daloy
+#   maintains on its own repository.
+#
+# Hardening (matches the rest of the scaffolded bundle):
+#   * Top-level `permissions: {}`; the job opts in only to the two
+#     scopes it needs (`security-events: write`, `contents: read`).
+#   * Third-party actions are SHA-pinned with version comments.
+#   * Opengrep itself is NOT installed via a third-party action;
+#     the binary is downloaded from a pinned GitHub release and its
+#     sigstore cosign signature is verified before execution.
+#   * `step-security/harden-runner` runs in audit mode.
+#   * `actions/checkout` runs with `persist-credentials: false`.
+#   * `set -euo pipefail` on every shell step.
+
+name: Opengrep
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+  schedule:
+    - cron: "51 5 * * 4"
+  workflow_dispatch:
+
+permissions: {}
+
+concurrency:
+  group: opengrep-${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  scan:
+    name: Opengrep SAST
+    runs-on: ubuntu-latest
+    timeout-minutes: 20
+    permissions:
+      security-events: write
+      contents: read
+
+    env:
+      OPENGREP_VERSION: "v1.22.0"
+      OPENGREP_ASSET: "opengrep_manylinux_x86"
+
+    steps:
+      - name: Harden runner
+        uses: step-security/harden-runner@ab7a9404c0f3da075243ca237b5fac12c98deaa5 # v2
+        with:
+          egress-policy: audit
+          disable-sudo: true
+
+      - name: Checkout
+        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6
+        with:
+          persist-credentials: false
+          show-progress: false
+
+      - name: Download Opengrep release binary + signature
+        run: |
+          set -euo pipefail
+          mkdir -p .opengrep
+          base="https://github.com/opengrep/opengrep/releases/download/${OPENGREP_VERSION}/${OPENGREP_ASSET}"
+          echo "Fetching ${base}"
+          curl --proto '=https' --tlsv1.2 -fsSL --retry 3 --retry-delay 2 \
+            -o .opengrep/opengrep      "${base}"
+          curl --proto '=https' --tlsv1.2 -fsSL --retry 3 --retry-delay 2 \
+            -o .opengrep/opengrep.cert "${base}.cert"
+          curl --proto '=https' --tlsv1.2 -fsSL --retry 3 --retry-delay 2 \
+            -o .opengrep/opengrep.sig  "${base}.sig"
+          chmod +x .opengrep/opengrep
+
+      - name: Verify Opengrep signature (cosign / sigstore)
+        run: |
+          set -euo pipefail
+          if ! command -v cosign >/dev/null 2>&1; then
+            echo "::error::cosign is required but not available on the runner."
+            exit 1
+          fi
+          cosign version
+          cosign verify-blob \
+            --cert ".opengrep/opengrep.cert" \
+            --signature ".opengrep/opengrep.sig" \
+            --certificate-identity-regexp "https://github.com/opengrep/opengrep.+" \
+            --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
+            ".opengrep/opengrep"
+          echo "Opengrep ${OPENGREP_VERSION} signature verified."
+
+      - name: Print Opengrep version
+        run: |
+          set -euo pipefail
+          .opengrep/opengrep --version
+
+      - name: Run Opengrep scan (SARIF)
+        # Curated security-focused rule packs from the Semgrep registry:
+        #   * p/security-audit / p/owasp-top-ten / p/cwe-top-25 — general
+        #   * p/javascript / p/typescript — language-specific
+        #   * p/secrets — hardcoded credentials / API keys
+        # `p/nodejs` is omitted on Deno because its sinks (e.g.
+        # `require()`, `process.*`) are not idiomatic on the Deno runtime.
+        run: |
+          set -euo pipefail
+          .opengrep/opengrep scan \
+            --config p/security-audit \
+            --config p/owasp-top-ten \
+            --config p/cwe-top-25 \
+            --config p/javascript \
+            --config p/typescript \
+            --config p/secrets \
+            --sarif-output opengrep.sarif \
+            --metrics off \
+            --timeout 120 \
+            --max-target-bytes 1500000 \
+            --exclude node_modules \
+            --exclude dist \
+            --exclude build \
+            --exclude coverage \
+            --exclude .opengrep \
+            .
+
+      - name: Upload SARIF to GitHub code scanning
+        if: always()
+        uses: github/codeql-action/upload-sarif@52485aec7be33610227643b0fe83936b8b5f061a # v3
+        with:
+          sarif_file: opengrep.sarif
+          category: opengrep

package/templates/_ci/deno/_github/workflows/osv-scan.yml

@@ -0,0 +1,121 @@
+# Second-source dependency scan against the OSV.dev database
+# (Aikido "SAST vs SCA" / "npm-audit-guide — the missing layer" gate).
+#
+# Why this exists for a Deno service:
+#   Deno does not ship a built-in `audit` command, so without this
+#   workflow a scaffolded Deno project has NO scheduled SCA coverage
+#   at all. The Aikido write-up "SAST vs SCA" calls this gap out
+#   directly: SAST (CodeQL, Opengrep) only inspects your own source;
+#   it does not know that one of your `npm:` or `jsr:` imports just
+#   had a malware advisory published against the exact version your
+#   `deno.lock` pins.
+#
+#   This workflow runs Google's OSV-Scanner against `deno.lock` on
+#   every PR and on a daily schedule. OSV-Scanner queries OSV.dev and
+#   cross-references the OpenSSF `malicious-packages` corpus
+#   (https://github.com/ossf/malicious-packages), so it surfaces both
+#   classic CVEs and explicitly-flagged malware drops — the exact
+#   classes of issue the September 2025 npm phishing wave that
+#   compromised `debug`, `chalk`, and ~2B downloads/week of dependent
+#   packages (https://lwn.net/Articles/1037167/) made famous.
+#
+# Defense-in-depth context (see SECURITY.md):
+#   * Deno's permission model (`--allow-net`, etc.) limits blast radius
+#     of a compromised dep at runtime.
+#   * `deno.lock` is checked into the repo and `deno task ...` runs
+#     with `--cached-only` in CI so an attacker cannot swap a dep
+#     between scan and run.
+#   * This OSV pass is the LAST layer: "did a pinned version turn out
+#     to carry a CVE or a malware advisory after we pinned it?"
+#
+# Hardening:
+#   * `permissions: {}` at the top level; the single job opts in to
+#     `contents: read` only. No write permissions of any kind.
+#   * `step-security/harden-runner` in audit mode.
+#   * `actions/checkout` runs with `persist-credentials: false`.
+#   * The OSV-Scanner binary is downloaded directly from the official
+#     google/osv-scanner GitHub release and its SHA-256 is verified
+#     against a locally-pinned constant BEFORE the binary is executed.
+#     We deliberately avoid the third-party `google/osv-scanner-action`
+#     wrapper so the only third-party surface is the binary itself, not
+#     a layer of action-side YAML that could be retagged.
+#   * The scan is read-only and runs on the committed lockfile without
+#     fetching or executing any dependency code.
+
+name: OSV scan
+
+on:
+  push:
+    branches: [main]
+    paths:
+      - "deno.lock"
+      - "deno.json"
+      - ".github/workflows/osv-scan.yml"
+  pull_request:
+    branches: [main]
+    paths:
+      - "deno.lock"
+      - "deno.json"
+      - ".github/workflows/osv-scan.yml"
+  schedule:
+    # 06:47 UTC daily — offset from Zizmor (07:00) so the SCA jobs do
+    # not collide.
+    - cron: "47 6 * * *"
+  workflow_dispatch:
+
+permissions: {}
+
+concurrency:
+  group: osv-scan-${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  scan:
+    name: OSV.dev + malicious-packages scan
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    permissions:
+      contents: read
+
+    env:
+      # Pinned OSV-Scanner release. Bump together with the SHA-256 below.
+      # Source: https://github.com/google/osv-scanner/releases/tag/v2.3.8
+      OSV_SCANNER_VERSION: "2.3.8"
+      # SHA-256 of `osv-scanner_linux_amd64` from the v2.3.8
+      # `osv-scanner_SHA256SUMS` asset.
+      OSV_SCANNER_SHA256: "bc98e15319ed0d515e3f9235287ba53cdc5535d576d24fd573978ecfe9ab92dc"
+
+    steps:
+      - name: Harden runner
+        uses: step-security/harden-runner@ab7a9404c0f3da075243ca237b5fac12c98deaa5 # v2
+        with:
+          egress-policy: audit
+          disable-sudo: true
+          disable-file-monitoring: false
+
+      - name: Checkout
+        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6
+        with:
+          persist-credentials: false
+          show-progress: false
+
+      - name: Download and verify OSV-Scanner binary
+        # Pin the binary by SHA-256 BEFORE executing it. A registry or
+        # GitHub Releases compromise that swaps the asset would fail
+        # this check and abort the job.
+        run: |
+          set -euo pipefail
+          url="https://github.com/google/osv-scanner/releases/download/v${OSV_SCANNER_VERSION}/osv-scanner_linux_amd64"
+          curl --proto '=https' --tlsv1.2 --fail --silent --show-error --location \
+            --output osv-scanner "${url}"
+          echo "${OSV_SCANNER_SHA256}  osv-scanner" | sha256sum --check --status
+          chmod +x osv-scanner
+          ./osv-scanner --version
+
+      - name: Scan deno.lock (OSV.dev + malicious-packages)
+        # Exits non-zero if any vulnerability or malware advisory matches
+        # a pinned `npm:` or `jsr:` version. This is the only scheduled
+        # SCA gate for a Deno scaffold, which has no built-in `audit`.
+        run: |
+          set -euo pipefail
+          ./osv-scanner scan source --lockfile=deno.lock --format=table

package/templates/_ci/deno/_github/workflows/secret-scan.yml

@@ -0,0 +1,106 @@
+# Secret scanning — gitleaks against PRs, pushes to main, and a daily
+# scheduled sweep of the full git history.
+#
+# Why this exists (Aikido "Secrets Detection: A Practical Guide"
+# https://www.aikido.dev/blog/secret-detection-application-security):
+#
+#   GitHub-native push protection only flags provider-shaped secrets at
+#   push time. Aikido's guide argues that effective secret detection must
+#   also scan the **full git history** (not just the latest snapshot) on
+#   a regular cadence, because a single leaked credential anywhere in any
+#   commit, branch, or tag should be treated as compromised.
+#
+#   This workflow runs `gitleaks` on every PR / push against the working
+#   tree and, on a daily schedule, sweeps the entire commit history so
+#   long-lived secrets that pre-date push-protection enablement (or
+#   secrets that slipped past it via rebased / squashed fork PRs) are
+#   still surfaced.
+#
+# Hardening (matches the rest of the scaffolded CI bundle):
+#
+#   * No new third-party GitHub Action: the gitleaks binary is fetched
+#     from the pinned official release and its SHA-256 is verified
+#     before execution.
+#   * Top-level `permissions: {}`; the single job opts in to
+#     `contents: read`.
+#   * `step-security/harden-runner` in audit mode, sudo disabled.
+#   * `actions/checkout` with `persist-credentials: false`.
+#   * `--redact` keeps any matched value out of the public log.
+#
+# When a finding lands:
+#   1. Rotate the credential immediately.
+#   2. Assess scope (what did the secret access?).
+#   3. Remove it from history if your workflow allows (filter-repo /
+#      BFG); otherwise treat the repo + every downstream clone as
+#      compromised.
+#   4. Add a `.gitleaksignore` entry only for confirmed false positives.
+
+name: Secret scan
+
+on:
+  pull_request:
+  push:
+    branches: [main]
+  schedule:
+    - cron: "21 4 * * *"
+  workflow_dispatch:
+
+permissions: {}
+
+concurrency:
+  group: secret-scan-${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  gitleaks:
+    name: gitleaks
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+    permissions:
+      contents: read
+
+    env:
+      # Pinned gitleaks release — bump in lockstep with the SHA-256 below.
+      # Source of truth: https://github.com/gitleaks/gitleaks/releases
+      GITLEAKS_VERSION: "8.30.1"
+      GITLEAKS_SHA256: "551f6fc83ea457d62a0d98237cbad105af8d557003051f41f3e7ca7b3f2470eb"
+
+    steps:
+      - name: Harden runner
+        uses: step-security/harden-runner@ab7a9404c0f3da075243ca237b5fac12c98deaa5 # v2
+        with:
+          egress-policy: audit
+          disable-sudo: true
+          disable-file-monitoring: false
+
+      - name: Checkout
+        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6
+        with:
+          persist-credentials: false
+          show-progress: false
+          # Full history for the scheduled sweep so gitleaks can walk
+          # every commit; for PR / push runs a shallow clone is fine
+          # because the checked-out tree is what gitleaks scans.
+          fetch-depth: ${{ github.event_name == 'schedule' && 0 || 1 }}
+
+      - name: Install gitleaks (verified SHA-256)
+        run: |
+          set -euo pipefail
+          archive="gitleaks_${GITLEAKS_VERSION}_linux_x64.tar.gz"
+          url="https://github.com/gitleaks/gitleaks/releases/download/v${GITLEAKS_VERSION}/${archive}"
+          curl --proto '=https' --tlsv1.2 -sSfL "$url" -o "$archive"
+          echo "${GITLEAKS_SHA256}  ${archive}" | sha256sum --check --strict
+          mkdir -p "$RUNNER_TEMP/gitleaks"
+          tar -xzf "$archive" -C "$RUNNER_TEMP/gitleaks" gitleaks
+          rm -f "$archive"
+          echo "$RUNNER_TEMP/gitleaks" >> "$GITHUB_PATH"
+
+      - name: gitleaks version
+        run: gitleaks version
+
+      - name: gitleaks (working tree)
+        run: gitleaks dir --no-banner --redact --verbose --exit-code 1 .
+
+      - name: gitleaks (full git history)
+        if: ${{ github.event_name == 'schedule' || github.event_name == 'workflow_dispatch' }}
+        run: gitleaks git --no-banner --redact --verbose --exit-code 1 .

package/templates/_ci/node/SECURITY.md

@@ -23,8 +23,10 @@ The `--with-ci` bundle adds these defaults:
 - Package-manager caches are disabled in CI to avoid cache-poisoning bridges.
 - Lockfile source verification rejects git dependencies and non-registry tarball URLs.
 - CodeQL, OpenSSF Scorecard, zizmor, Dependabot, and CODEOWNERS are generated.
+- A weekly scheduled `opengrep.yml` runs a second SAST engine (Aikido's LGPL-2.1 fork of Semgrep) against the repository using the curated `p/security-audit`, `p/owasp-top-ten`, `p/cwe-top-25`, `p/javascript`, `p/typescript`, `p/nodejs`, and `p/secrets` rule packs. The Opengrep binary is downloaded from a pinned GitHub release and its sigstore cosign signature is verified against the official `opengrep/opengrep` release identity before it runs — no third-party action sits in the supply chain just for this scan. Running two SAST engines (CodeQL + Opengrep) catches different bug classes than either alone; see Aikido's [Ultimate SAST Guide](https://www.aikido.dev/blog/ultimate-sast-guide-static-application-security-testing) for why a layered SAST posture is the recommended default.
 - A daily scheduled `vuln-scan.yml` runs the package manager's audit against the committed lockfile so newly-disclosed CVEs are surfaced even when no PR or push has run CI (SOC 2 CC7.1 continuous-vulnerability-management evidence).
-- A weekly scheduled `dast.yml` boots the built application and runs an OWASP ZAP baseline scan against it. CodeQL + the `verify:*` family are the SAST half of the posture; this is the DAST half — see Aikido's [SAST vs DAST](https://www.aikido.dev/blog/sast-vs-dast-what-you-need-to-now) write-up for why both matter. Findings are summarized in the workflow log and the job fails on HIGH-risk alerts; MEDIUM / LOW / INFO are surfaced for triage but non-blocking.
+- A weekly scheduled `dast.yml` boots the built application and runs an OWASP ZAP baseline scan against it. CodeQL + Opengrep + the `verify:*` family are the SAST half of the posture; this is the DAST half — see Aikido's [SAST vs DAST](https://www.aikido.dev/blog/sast-vs-dast-what-you-need-to-now) write-up for why both matter. Findings are summarized in the workflow log and the job fails on HIGH-risk alerts; MEDIUM / LOW / INFO are surfaced for triage but non-blocking.
+- A `secret-scan.yml` workflow runs [gitleaks](https://github.com/gitleaks/gitleaks) against the working tree on every PR / push and against the **full git history** on a daily schedule. The gitleaks binary is downloaded from a pinned official release and verified by SHA-256 before execution so the scan does not introduce a new third-party action into the supply chain. Findings block the merge; matched values are redacted from the public log. The rationale (and the remediation playbook for a confirmed leak) follows Aikido's [Secrets Detection guide](https://www.aikido.dev/blog/secret-detection-application-security): a secret in any commit, branch, or tag should be treated as compromised, and detection must consider the entire history — not just the latest snapshot — alongside GitHub-native push protection.
 - No npm publish workflow is generated: this scaffold is a REST API service, not a published package. If you later carve out a reusable library you can opt into npm trusted publishing yourself.
 
 ## Container hardening
@@ -57,11 +59,107 @@ SHA-pinned open-source tooling:
   - All findings are uploaded as SARIF to the GitHub **Code Scanning**
     tab alongside CodeQL.
 
+## Runtime hardening (`docker run`, Compose, Fly machines)
+
+The image build is only half the story. The Aikido
+["Container Security — The Dev Guide"](https://www.aikido.dev/blog/container-security-guide)
+write-up calls out that most container compromises chain a known
+software CVE with a permissive runtime configuration: a container
+launched with the default capability set, no resource limits, and a
+writable root filesystem turns a single RCE into a host compromise.
+Apply these flags wherever you launch the image outside of Kubernetes
+(the **Pod security on Kubernetes** entry below covers the equivalent
+`PodSpec` settings):
+
+- `--read-only` — root filesystem is read-only. The shipped image
+  needs no writable paths at runtime; pair with
+  `--tmpfs /tmp:rw,noexec,nosuid,size=64m` if your app writes
+  temp files.
+- `--cap-drop=ALL` — drop every Linux capability. The Node.js
+  runtime under `tini` needs none of the default set
+  (`CHOWN`, `DAC_OVERRIDE`, `NET_BIND_SERVICE`, …); rebind the
+  listening port to `>= 1024` (the shipped `EXPOSE 3000`
+  already does) so you do not need `NET_BIND_SERVICE` back.
+- `--security-opt=no-new-privileges:true` — block `setuid` /
+  `setgid` / file-capability escalation inside the container, so a
+  compromised handler cannot regain privileges the image dropped.
+- `--security-opt=seccomp=default` — keep Docker's default seccomp
+  profile (it is on by default, but some orchestrators disable it;
+  re-assert it explicitly).
+- `--pids-limit=256` — cap process count. Prevents fork-bomb style
+  DoS from a compromised handler.
+- `--memory=512m --memory-swap=512m --cpus=1.0` — enforce resource
+  limits. The framework's `loadShedding()` middleware refuses
+  requests under event-loop / RSS / heap pressure, but the
+  kernel-side limits are the backstop that makes a runaway
+  handler a `137 OOMKilled` instead of a noisy neighbour.
+- **Never** pass `--privileged`, `-v /var/run/docker.sock:…`, or
+  `--pid=host` / `--network=host` to this image. None of them are
+  needed by a stateless HTTP service and each one converts a
+  container escape into a host takeover.
+
+Equivalent `compose.yml` snippet (drop into the service block your
+deploy uses):
+
+```yaml
+services:
+  app:
+    image: ghcr.io/your-org/your-app:sha-<digest>
+    read_only: true
+    tmpfs:
+      - /tmp:rw,noexec,nosuid,size=64m
+    cap_drop: ["ALL"]
+    security_opt:
+      - "no-new-privileges:true"
+    pids_limit: 256
+    mem_limit: 512m
+    memswap_limit: 512m
+    cpus: 1.0
+    restart: unless-stopped
+```
+
+Fly.io, Render, Railway, and similar PaaS surfaces apply most of these
+defaults for you, but check the platform documentation — `--privileged`
+and host network are still escape hatches you should keep off.
+
+## Cloud posture (operator checklist)
+
+The framework cannot author your cloud configuration for you, but the
+[Aikido "Top 7 Cloud Security Vulnerabilities"](https://www.aikido.dev/blog/top-cloud-security-vulnerabilities)
+write-up maps cleanly onto a short checklist. Adopt these alongside the
+container and CI defaults above:
+
+- **IMDSv2 only.** On EC2 / equivalent, require token-based IMDSv2 and disable
+  IMDSv1 at the launch-template / instance-metadata-options level. Combined
+  with the framework's `fetchGuard()` on user-controlled outbound fetches,
+  this closes the Capital One 2019 / Pandoc CVE-2025-51591 SSRF → IAM chain.
+- **Least-privilege execution role.** Scope the workload's IAM role to the
+  minimum actions and resource ARNs the handler actually calls (e.g.
+  `s3:GetObject` on a single bucket prefix, never `s3:*`). Enable IAM Access
+  Analyzer / unused-permission scans and prune quarterly.
+- **Pod security on Kubernetes.** Deploy with `runAsNonRoot: true`,
+  `readOnlyRootFilesystem: true`, `allowPrivilegeEscalation: false`,
+  `capabilities: { drop: ["ALL"] }`, and `automountServiceAccountToken: false`
+  on pods that do not call the kube API. The shipped `Dockerfile` already
+  runs as non-root UID 1001 with no writable paths required at runtime, so
+  these settings work out of the box.
+- **Network segmentation.** Keep development, staging, and production in
+  separate cloud accounts / projects. Apply default-deny `NetworkPolicy` (k8s)
+  or Security Group egress rules so a compromised workload cannot freely
+  reach the metadata service, the database tier, or the internet.
+- **Log agent isolation.** If you run FluentBit / Vector / Fluentd as a
+  sidecar or DaemonSet, run it under its own ServiceAccount with read-only
+  access to the log path, pin the agent image to a digest, and subscribe to
+  its CVE feed (FluentBit had CVE-2025-12969 auth bypass + CVE-2025-12972
+  path traversal disclosed in 2025). The framework's structured logger
+  already redacts known credential shapes **before** the line leaves the
+  process, so a compromised agent receives pre-redacted data.
+
 ## Required repository settings
 
 Before relying on these files for a company project:
 
 1. Replace `@your-org/security-team` in `.github/CODEOWNERS` or pass `--code-owner` when scaffolding.
-2. Protect the `main` branch and require the CI, CodeQL, Scorecard, and zizmor checks.
+2. Protect the `main` branch and require the CI, CodeQL, Opengrep, Scorecard, and zizmor checks.
 3. Enable GitHub secret scanning and push protection.
 4. Keep `ignore-scripts=true` and the `pnpm-workspace.yaml` supply-chain settings on when using pnpm.

package/templates/_ci/node/_github/CODEOWNERS

@@ -7,7 +7,9 @@
 /.github/                         __CODE_OWNER__
 /.github/workflows/               __CODE_OWNER__
 /.github/workflows/vuln-scan.yml  __CODE_OWNER__
+/.github/workflows/osv-scan.yml   __CODE_OWNER__
 /.github/workflows/dast.yml       __CODE_OWNER__
+/.github/workflows/secret-scan.yml __CODE_OWNER__
 /.github/dependabot.yml           __CODE_OWNER__
 /.github/CODEOWNERS               __CODE_OWNER__
 

package/templates/_ci/node/_github/workflows/container-scan.yml

@@ -1,18 +1,28 @@
-# Container security scan generated by create-daloy --with-ci.
+# Container + IaC security scan generated by create-daloy --with-ci.
 #
 # Inspired by the controls in
-# https://snyk.io/blog/scale-container-security-effortlessly/ — but built
-# only from SHA-pinned, free, open-source GitHub Actions:
+# https://snyk.io/blog/scale-container-security-effortlessly/ and
+# Aikido's "IaC security scanning for Terraform & Kubernetes
+# misconfigurations"
+# (https://www.aikido.dev/blog/iac-security-scanning-terraform-kubernetes-misconfigurations)
+# — but built only from SHA-pinned, free, open-source GitHub Actions:
 #
 #   - hadolint lints the Dockerfile for known anti-patterns and unsafe
 #     instructions (CIS Docker Benchmark coverage).
-#   - Trivy scans the source tree (config + secrets + vulnerable lockfile
-#     entries), then scans the built image for OS + language CVEs.
+#   - Trivy filesystem scan with the `misconfig` scanner enabled catches
+#     IaC misconfigurations in Terraform (`*.tf` / `*.tfvars`),
+#     Kubernetes manifests (`k8s/**`, `deployment.yaml`,
+#     `kustomization*.yaml`), Helm charts, Dockerfiles, and
+#     CloudFormation templates — plus secrets and vulnerable lockfile
+#     entries. This runs even when no Dockerfile is present, so a
+#     project that only ships Terraform / K8s still gets the Aikido-style
+#     IaC posture review on every PR.
+#   - Trivy image scan covers OS + language CVEs once the image is built.
 #   - SARIF results are uploaded to the Code Scanning tab so findings show
 #     up in the same place as CodeQL.
 #
-# The job is a no-op if the project has no Dockerfile at the repo root, so
-# it is safe to keep enabled for templates that disable the container.
+# The Dockerfile-specific steps (hadolint, build, image scan) are a no-op
+# if the project has no Dockerfile at the repo root.
 
 name: Container scan
 
@@ -26,6 +36,17 @@ on:
       - "package-lock.json"
       - "yarn.lock"
       - "bun.lock"
+      - "**/*.tf"
+      - "**/*.tfvars"
+      - "**/*.hcl"
+      - "k8s/**"
+      - "helm/**"
+      - "**/deployment.yaml"
+      - "**/deployment.yml"
+      - "**/kustomization.yaml"
+      - "**/kustomization.yml"
+      - "**/Chart.yaml"
+      - "**/values.yaml"
       - ".github/workflows/container-scan.yml"
   push:
     branches: [main]
@@ -37,6 +58,17 @@ on:
       - "package-lock.json"
       - "yarn.lock"
       - "bun.lock"
+      - "**/*.tf"
+      - "**/*.tfvars"
+      - "**/*.hcl"
+      - "k8s/**"
+      - "helm/**"
+      - "**/deployment.yaml"
+      - "**/deployment.yml"
+      - "**/kustomization.yaml"
+      - "**/kustomization.yml"
+      - "**/Chart.yaml"
+      - "**/values.yaml"
       - ".github/workflows/container-scan.yml"
   schedule:
     # Weekly run catches newly-disclosed base-image CVEs even when the
@@ -130,12 +162,17 @@ jobs:
           sarif_file: hadolint.sarif
           category: hadolint
 
-      - name: Trivy filesystem scan (config + secrets + vulns)
-        if: steps.detect.outputs.present == 'true'
+      - name: Trivy filesystem scan (IaC misconfig + secrets + vulns)
+        # `misconfig` is the IaC posture scanner — Terraform, Kubernetes,
+        # Helm, Dockerfile, CloudFormation — per Aikido's "IaC security
+        # scanning for Terraform & Kubernetes misconfigurations" article.
+        # It runs unconditionally so a project that only ships Terraform
+        # or K8s (no Dockerfile) still gets reviewed on every PR.
         uses: aquasecurity/trivy-action@ed142fd0673e97e23eac54620cfb913e5ce36c25 # v0.36.0
         with:
           scan-type: fs
           scan-ref: .
+          scanners: vuln,secret,misconfig
           severity: HIGH,CRITICAL
           ignore-unfixed: true
           format: sarif
@@ -143,7 +180,6 @@ jobs:
           exit-code: "0"
 
       - name: Upload Trivy filesystem SARIF
-        if: steps.detect.outputs.present == 'true'
         uses: github/codeql-action/upload-sarif@52485aec7be33610227643b0fe83936b8b5f061a # v3
         with:
           sarif_file: trivy-fs.sarif