feat: add nightly branch workflow

docs/plans/security_tooling_analysis.md

@@ -38,6 +38,7 @@ This document evaluates three categories of security tools for potential additio
 ### Coverage Analysis
 
 **What's Protected:**
+
 - ✅ OS-level vulnerabilities (Alpine packages)
 - ✅ Go module vulnerabilities (govulncheck + Trivy)
 - ✅ npm package vulnerabilities (Trivy + npm audit)
@@ -48,6 +49,7 @@ This document evaluates three categories of security tools for potential additio
 - ✅ Automated dependency updates (Renovate)
 
 **What's Missing:**
+
 - ❌ Software Bill of Materials (SBOM) generation
 - ❌ Provenance attestation (who built what, when, how)
 - ❌ Build reproducibility verification
@@ -106,11 +108,13 @@ Grype is an open-source vulnerability scanner for container images, filesystems,
 ### Unique Value Proposition
 
 **What Grype offers that Trivy doesn't:**
+
 - ❌ **None.** Grype uses the same CVE databases and covers the same ecosystems.
 - 🤷 **Marginally faster scans** (~20-30% speed improvement), but Trivy already completes in under 60 seconds for Charon's image.
 - ✅ **SBOM-first design:** Grype can scan SBOMs generated by other tools (but Trivy can too).
 
 **What Trivy offers that Grype doesn't:**
+
 - ✅ Secret scanning (API keys, tokens, passwords)
 - ✅ Misconfiguration detection (Dockerfile, Kubernetes manifests, Terraform)
 - ✅ License compliance scanning
@@ -158,11 +162,13 @@ Grype is an open-source vulnerability scanner for container images, filesystems,
 ### False Positive Rate
 
 **Community Feedback:**
+
 - 🟡 **Similar FP rate to Trivy** (both use NVD data, which has inherent false positives)
 - 🟢 **VEX (Vulnerability Exploitability eXchange) support** for suppressing known FPs
 - 🔴 **Duplicate alerts** when run alongside Trivy
 
 **Example False Positives (common to both tools):**
+
 - CVEs affecting unused/optional features (e.g., TLS bugs in binaries that don't use TLS)
 - Go stdlib CVEs in third-party binaries (e.g., CrowdSec) that Charon can't fix
 
@@ -191,6 +197,7 @@ Grype is an open-source vulnerability scanner for container images, filesystems,
 #### ❌ **DO NOT ADD**
 
 **Rationale:**
+
 1. **95% functional overlap with Trivy** — nearly all features are duplicates
 2. **No unique vulnerability database coverage** — same NVD, Alpine SecDB, GitHub Advisory DB
 3. **Missing critical features** — no secret scanning, no misconfiguration detection
@@ -201,6 +208,7 @@ Grype is an open-source vulnerability scanner for container images, filesystems,
 **User's Willingness to Add DoD Time:** While the user is open to adding DoD time for security, this time should be invested in tools that provide **unique value**, not redundant coverage.
 
 **Alternative Actions:**
+
 - ✅ **Keep Trivy** as the primary vulnerability scanner
 - ✅ Ensure Trivy scans cover all required severity levels (CRITICAL, HIGH)
 - ✅ Consider Trivy VEX support to suppress known false positives
@@ -227,6 +235,7 @@ OWASP Dependency-Check is an open-source Software Composition Analysis (SCA) too
 | **RetireJS** | JavaScript library CVEs | ❌ Trivy covers this via NVD |
 
 **Unique Coverage:**
+
 - 🟡 **OSS Index:** Sonatype's proprietary vulnerability database with additional metadata (license info, security advisories). However, **OSS Index sources most data from NVD**, so overlap is >90%.
 
 **Conclusion:** Minimal unique coverage. Most vulnerabilities detected by OWASP DC are already caught by Trivy.
@@ -250,11 +259,13 @@ OWASP Dependency-Check is an open-source Software Composition Analysis (SCA) too
 ### Unique Value Proposition
 
 **What OWASP Dependency-Check offers that Trivy doesn't:**
+
 - 🟡 **OSS Index integration:** Sonatype's vulnerability DB (but mostly duplicates NVD)
 - 🟡 **Maven-centric tooling:** Better Maven `pom.xml` analysis (not relevant for Charon—Go backend, not Java)
 - ❌ **No unique coverage for Go or npm** in Charon's stack
 
 **What Trivy offers that OWASP DC doesn't:**
+
 - ✅ Container image scanning (Charon's primary artifact)
 - ✅ OS package vulnerabilities (Alpine Linux)
 - ✅ Secret scanning
@@ -277,6 +288,7 @@ OWASP Dependency-Check is an open-source Software Composition Analysis (SCA) too
 
 **Complexity:** Moderate
 **Issues:**
+
 - Requires NVD API key or local DB download (~500MB-1GB cache)
 - First run takes 5-10 minutes to download NVD data
 - Subsequent runs: 2-5 minutes
@@ -294,6 +306,7 @@ OWASP Dependency-Check is an open-source Software Composition Analysis (SCA) too
 
 **Complexity:** High
 **Prerequisites:**
+
 - Install dependency-check CLI via Homebrew, Docker, or manual download
 - Configure NVD API key (optional but recommended to avoid rate limits)
 - Manage local NVD cache (~1GB)
@@ -310,6 +323,7 @@ OWASP Dependency-Check is an open-source Software Composition Analysis (SCA) too
 ### False Positive Rate
 
 **Community Feedback:**
+
 - 🔴 **High false positive rate** for npm and Go modules
   - Example: Reports CVEs for dev dependencies that aren't in production builds
   - Example: Flags Go stdlib CVEs in `go.mod` even when not used in compiled binary
@@ -318,6 +332,7 @@ OWASP Dependency-Check is an open-source Software Composition Analysis (SCA) too
 - 🟢 **Suppression file support** (XML-based) to ignore known FPs
 
 **Example False Positive:**
+
 - OWASP DC may flag CVEs for `node_modules` dependencies that are only used in tests or dev builds, not shipped in the Docker image.
 
 ### Maintenance Burden
@@ -345,6 +360,7 @@ OWASP Dependency-Check is an open-source Software Composition Analysis (SCA) too
 #### ❌ **DO NOT ADD**
 
 **Rationale:**
+
 1. **70% functional overlap with Trivy, but Trivy is superior for Charon's stack**
 2. **No unique value for Go or npm ecosystems** — Trivy's Go/npm analyzers are more mature
 3. **Cannot scan Docker images** — Charon's primary security artifact
@@ -356,6 +372,7 @@ OWASP Dependency-Check is an open-source Software Composition Analysis (SCA) too
 **User's Willingness to Add DoD Time:** While the user is open to adding DoD time, **OWASP Dependency-Check would add 2-5 minutes for minimal unique value**. This time is better spent on supply chain security tooling (SBOM, attestation).
 
 **Alternative Actions:**
+
 - ✅ **Keep Trivy** as the primary dependency scanner
 - ✅ Ensure Trivy scans both `backend/go.mod` and `frontend/package-lock.json`
 - ✅ Enable Trivy's SBOM generation feature (already supported)
@@ -377,6 +394,7 @@ Supply chain security tools address vulnerabilities in the **build and distribut
 **What it is:** A security framework with 4 compliance levels (SLSA 0-4) that define best practices for securing the software supply chain.
 
 **SLSA Levels:**
+
 - **SLSA 0:** No guarantees (current state of most projects)
 - **SLSA 1:** Build process documented (provenance exists)
 - **SLSA 2:** Signed provenance, version-controlled build scripts
@@ -384,12 +402,14 @@ Supply chain security tools address vulnerabilities in the **build and distribut
 - **SLSA 4:** Two-party review of all changes, hermetic builds
 
 **What it protects against:**
+
 - ✅ **Source tampering** (e.g., compromised GitHub account modifying code)
 - ✅ **Build tampering** (e.g., malicious CI/CD job injecting backdoors)
 - ✅ **Artifact substitution** (e.g., attacker replacing published Docker image)
 - ✅ **Dependency confusion** (e.g., typosquatting attacks)
 
 **Relevance to Charon:**
+
 - ✅ Docker images are signed and attested
 - ✅ Users can verify image provenance before deployment
 - ✅ Compliance with enterprise security policies (e.g., NIST SSDF, EO 14028)
@@ -399,6 +419,7 @@ Supply chain security tools address vulnerabilities in the **build and distribut
 **What it is:** Open-source keyless signing and verification for software artifacts using ephemeral keys and transparency logs.
 
 **Core Components:**
+
 - **Cosign:** CLI tool for signing and verifying container images, blobs, and SBOMs
 - **Fulcio:** Certificate authority for keyless signing (OIDC-based)
 - **Rekor:** Transparency log for immutable artifact signatures
@@ -406,11 +427,13 @@ Supply chain security tools address vulnerabilities in the **build and distribut
 **Keyless Signing:** No need to manage private keys—sign with OIDC identity (GitHub, Google, Microsoft).
 
 **What it protects against:**
+
 - ✅ **Image tampering** (unsigned images rejected)
 - ✅ **Man-in-the-middle attacks** (cryptographic verification)
 - ✅ **Registry compromise** (even if registry is hacked, signatures can't be forged)
 
 **Relevance to Charon:**
+
 - ✅ Sign Docker images automatically in GitHub Actions
 - ✅ Users verify signatures before pulling images
 - ✅ Integrate with admission controllers (e.g., Kyverno, OPA) for Kubernetes deployments
@@ -420,15 +443,18 @@ Supply chain security tools address vulnerabilities in the **build and distribut
 **What it is:** A machine-readable inventory of all components in a software artifact (dependencies, libraries, versions, licenses).
 
 **Formats:**
+
 - **CycloneDX** (OWASP standard, JSON/XML)
 - **SPDX** (Linux Foundation standard, JSON/YAML/RDF)
 
 **What it protects against:**
+
 - ✅ **Unknown vulnerabilities** (enables future retrospective scanning)
 - ✅ **Compliance violations** (tracks license obligations)
 - ✅ **Supply chain attacks** (identifies compromised dependencies)
 
 **Relevance to Charon:**
+
 - ✅ Generate SBOM for Docker image in CI/CD
 - ✅ Attach SBOM to image as attestation
 - ✅ Enable users to audit Charon's dependencies
@@ -466,6 +492,7 @@ Supply chain security tools address vulnerabilities in the **build and distribut
 | **Compliance (EO 14028, NIST SSDF)** | ❌ Not addressed | ✅ SLSA levels provide compliance framework |
 
 **Real-World Attacks Prevented:**
+
 - ✅ **SolarWinds (2020):** Provenance attestation would have shown build artifacts were tampered
 - ✅ **Codecov (2021):** Signed artifacts would have prevented malicious script injection
 - ✅ **npm package hijacking:** SBOM would enable tracking affected downstream projects
@@ -572,6 +599,7 @@ Already implemented:
 **N/A** — Supply chain tools don't scan for vulnerabilities, so false positives are not applicable. They provide **cryptographic proof of integrity**, which is either valid or invalid.
 
 **Potential Issues:**
+
 - 🟡 **Signature verification failure** if OIDC identity changes (e.g., repo renamed)
 - 🟡 **Provenance mismatch** if build scripts are modified without updating attestation
 - 🟢 **These are security failures, not false positives** — they indicate tampering or misconfiguration
@@ -588,6 +616,7 @@ Already implemented:
 | **Rekor** | N/A (hosted by Sigstore) | None | None |
 
 **Overall Maintenance Burden:** **Low**
+
 - Actions auto-update with Renovate
 - No local secrets to manage (keyless signing)
 - Public Sigstore infrastructure (no self-hosting required)
@@ -612,6 +641,7 @@ Already implemented:
 #### ✅ **STRONGLY RECOMMEND**
 
 **Rationale:**
+
 1. **Unique value:** Addresses threats that Trivy/CodeQL/Renovate don't cover (build tampering, artifact substitution)
 2. **Minimal overlap:** Complementary to existing tools, not redundant
 3. **Low maintenance:** Keyless signing eliminates secret management burden
@@ -658,6 +688,7 @@ Already implemented:
 ```
 
 **Prerequisites:**
+
 - ✅ GitHub Actions already has `id-token: write` permission (enabled in `docker-build.yml`)
 
 #### Step 1.2: Add VS Code Task for Signature Verification
@@ -712,6 +743,7 @@ cosign verify \
 ```
 
 Signatures are logged in the public [Rekor transparency log](https://rekor.sigstore.dev/).
+
 ```
 
 **Estimated Time:** 2-4 hours
@@ -765,6 +797,7 @@ cosign verify-attestation \
   --certificate-oidc-issuer='https://token.actions.githubusercontent.com' \
   ghcr.io/wikid82/charon:latest
 ```
+
 ```
 
 **Estimated Time:** 4-6 hours
@@ -806,6 +839,7 @@ cosign verify-attestation \
 | **TOTAL** | **7-12 hours** | **+2-4 min/build** | **🟢 Low** |
 
 **Rollback Plan:**
+
 - Phase 1 and 2 can be disabled by removing steps from `docker-build.yml`
 - Phase 3 is non-blocking (verification failure logs a warning, doesn't fail the build)
 
@@ -891,6 +925,7 @@ cosign verify-attestation \
 5. 🔍 **Add SBOM verification last** (nice-to-have, minimal time investment)
 
 **Expected Benefits:**
+
 - ✅ Cryptographic proof of artifact integrity
 - ✅ Compliance with federal/enterprise security mandates
 - ✅ Protection against supply chain attacks (e.g., SolarWinds-style compromises)
@@ -902,6 +937,7 @@ cosign verify-attestation \
 ---
 
 **Next Steps:**
+
 1. Review this analysis with maintainers
 2. Approve Phase 1 (Cosign signing) for immediate implementation
 3. Create GitHub issues for Phase 2 and 3