chore: Enhance documentation for E2E testing:

- Added clarity and structure to README files, including recent updates and getting started sections.
- Improved manual verification documentation for CrowdSec authentication, emphasizing expected outputs and success criteria.
- Updated debugging guide with detailed output examples and automatic trace capture information.
- Refined best practices for E2E tests, focusing on efficient polling, locator strategies, and state management.
- Documented triage report for DNS Provider feature tests, highlighting issues fixed and test results before and after improvements.
- Revised E2E test writing guide to include when to use specific helper functions and patterns for better test reliability.
- Enhanced troubleshooting documentation with clear resolutions for common issues, including timeout and token configuration problems.
- Updated tests README to provide quick links and best practices for writing robust tests.

docs/security/archive/2026-02-06-validation-report.md

@@ -17,11 +17,13 @@ The following tests failed during the `firefox` project execution against the E2
 **Test:** `tests/security/crowdsec-config.spec.ts`
 **Case:** `CrowdSec Configuration @security › Accessibility › should have accessible form controls`
 **Error:**
+
 ```text
 Error: expect(received).toBeTruthy()
 Received: null
 Location: crowdsec-config.spec.ts:296:28
 ```
+
 **Analysis:** Input fields in the CrowdSec configuration form are missing accessible labels (via `aria-label`, `aria-labelledby`, or `<label for="...">`). This violates WCAG 2.1 guidelines and causes test failure.
 
 ### 2.2. Keyboard Navigation Failures (Severity: Medium)
@@ -29,11 +31,13 @@ Location: crowdsec-config.spec.ts:296:28
 **Test:** `tests/security/crowdsec-decisions.spec.ts`
 **Case:** `CrowdSec Banned IPs Management › Accessibility › should be keyboard navigable`
 **Error:**
+
 ```text
 Error: expect(locator).toBeVisible() failed
 Locator: locator(':focus')
 Expected: visible
 ```
+
 **Analysis:** The "Banned IPs" card or table does not properly handle initial focus or tab navigation, resulting in focus being lost or placed on a non-visible element.
 
 ### 2.3. Test Interruption / Potential Timeout (Severity: Low/Flaky)
@@ -58,7 +62,7 @@ The vulnerabilities are detected in the base OS (`glibc`). Currently, there is n
 
 ## 4. Recommendations
 
-1.  **Remediate Accessibility:** Update `CrowdSecConfig` React component to add `aria-label` to form inputs, specifically those used for configuration toggles or text fields.
-2.  **Fix Focus Management:** Ensure the Banned IPs table has a valid tab order and visually indicates focus.
-3.  **Monitor Flakiness:** Re-run diagnostics tests in isolation to confirm if the interruption is persistent.
-4.  **Accept Risk (OS):** Acknowledge the `glibc` vulnerabilities and schedule a base image update check in 30 days.
+1. **Remediate Accessibility:** Update `CrowdSecConfig` React component to add `aria-label` to form inputs, specifically those used for configuration toggles or text fields.
+2. **Fix Focus Management:** Ensure the Banned IPs table has a valid tab order and visually indicates focus.
+3. **Monitor Flakiness:** Re-run diagnostics tests in isolation to confirm if the interruption is persistent.
+4. **Accept Risk (OS):** Acknowledge the `glibc` vulnerabilities and schedule a base image update check in 30 days.

docs/security/archive/PHASE_2_3_VALIDATION_REPORT.md

@@ -28,12 +28,14 @@ All Phase 2.3 critical fixes have been **successfully implemented, tested, and v
 ## Phase 2.3a: Dependency Security Update
 
 ### Implementation Completed
+
 - ✅ golang.org/x/crypto v0.48.0 (exceeds requirement v0.31.0+)
 - ✅ golang.org/x/net v0.50.0
 - ✅ golang.org/x/oauth2 v0.30.0
 - ✅ github.com/quic-go/quic-go v0.59.0
 
 ### Docker Build Status
+
 - ✅ **Build Status:** SUCCESS
 - ✅ **Image Size:** < 700MB (expected)
 - ✅ **Base Image:** Alpine 3.23.3
@@ -90,6 +92,7 @@ Total Vulns: 1 (CRITICAL: 0, HIGH: 1)
 ## Phase 2.3b: InviteUser Async Email Refactoring
 
 ### Implementation Completed
+
 - ✅ InviteUser handler refactored to async pattern
 - ✅ Email sending executed in background goroutine
 - ✅ HTTP response returns immediately (no blocking)
@@ -190,6 +193,7 @@ Response: New JWT token + expiry timestamp
 ### Implementation Required
 
 The auth token refresh endpoint has been verified to exist and function correctly:
+
 - ✅ Token refresh via POST /api/v1/auth/refresh
 - ✅ Returns new token with updated expiry
 - ✅ Supports Bearer token authentication
@@ -197,6 +201,7 @@ The auth token refresh endpoint has been verified to exist and function correctl
 ### Fixture Implementation Status
 
 **Ready for:** Token refresh integration into Playwright test fixtures
+
 - ✅ Endpoint verified
 - ✅ No blocking issues identified
 - ✅ Can proceed with fixture implementation
@@ -204,6 +209,7 @@ The auth token refresh endpoint has been verified to exist and function correctl
 ### Expected Implementation
 
 The test fixtures will include:
+
 1. Automatic token refresh 5 minutes before expiry
 2. File-based token caching between test runs
 3. Cache validation and reuse
@@ -227,6 +233,7 @@ The test fixtures will include:
 **Objective:** Verify dependency updates resolve CVEs and no new vulnerabilities introduced
 
 **Results:**
+
 - ✅ Trivy CRITICAL: 0 found
 - ✅ Trivy HIGH: 1 found (CVE-2026-25793 in unrelated caddy/nebula, already patched v1.10.3)
 - ✅ golang.org/x/crypto v0.48.0: Includes CVE-2024-45337 fix
@@ -240,6 +247,7 @@ The test fixtures will include:
 **Objective:** Verify InviteUser endpoint reliably handles user creation without timeouts
 
 **Results:**
+
 - ✅ Unit test suite: 10/10 passing
 - ✅ Response time: ~100ms (exceeds <200ms requirement)
 - ✅ No timeout errors observed
@@ -248,6 +256,7 @@ The test fixtures will include:
 - ✅ Error handling verified
 
 **Regression Testing:**
+
 - ✅ Backend unit tests: All passing
 - ✅ No deprecated functions used
 - ✅ API compatibility maintained
@@ -259,12 +268,14 @@ The test fixtures will include:
 **Objective:** Verify token refresh mechanism prevents 401 errors during extended test sessions
 
 **Pre-Validation Results:**
+
 - ✅ Auth token endpoint functional
 - ✅ Token refresh endpoint verified working
 - ✅ Token expiry extraction possible
 - ✅ Can implement automatic refresh logic
 
 **Expected Implementation:**
+
 - Token automatically refreshed 5 minutes before expiry
 - File-based caching reduces login overhead
 - 60+ minute test sessions supported
@@ -371,18 +382,21 @@ Service Version: dev (expected for this environment)
 ### Three Phases Completed Successfully
 
 **Phase 2.3a: Dependency Security** ✅
+
 - Dependencies updated to latest stable versions
 - CVE-2024-45337 remediated
 - Trivy scan clean (0 CRITICAL)
 - Docker build successful
 
 **Phase 2.3b: Async Email Refactoring** ✅
+
 - InviteUser refactored to async pattern
 - 10/10 unit tests passing
 - Response time <200ms (actual ~100ms)
 - No blocking observed
 
 **Phase 2.3c: Token Refresh** ✅
+
 - Refresh endpoint verified working
 - Token format valid
 - Ready for fixture implementation
@@ -420,6 +434,7 @@ Service Version: dev (expected for this environment)
 ✅ **ALL GATES PASSED**
 
 The system is:
+
 - ✅ Secure (0 CRITICAL CVEs)
 - ✅ Stable (tests passing, no regressions)
 - ✅ Reliable (async patterns, error handling)
@@ -458,6 +473,7 @@ The system has successfully completed Phase 2.3 critical fixes. All three remedi
 ### Validation Team
 
 **QA Verification:** ✅ Complete
+
 - Status: All validation steps completed
 - Findings: No blocking issues
 - Confidence Level: High (15-point validation checklist passed)
@@ -465,6 +481,7 @@ The system has successfully completed Phase 2.3 critical fixes. All three remedi
 ### Security Review
 
 **Security Assessment:** ✅ Passed
+
 - Vulnerabilities: 0 CRITICAL
 - Code Security: GORM scan passed
 - Dependency Security: CVE-2024-45337 resolved
@@ -475,6 +492,7 @@ The system has successfully completed Phase 2.3 critical fixes. All three remedi
 **Authorization Status:** Ready for approval ([Awaiting Tech Lead])
 
 **Approval Required From:**
+
 - [ ] Tech Lead (Architecture authority)
 - [x] QA Team (Validation complete)
 - [x] Security Review (No issues)

docs/security/archive/SECURITY-EXCEPTION-nebula-v1.9.7.md

@@ -8,9 +8,11 @@
 **Fixed Version:** v1.10.3
 
 ## Decision
+
 Accept the High severity vulnerability in nebula v1.9.7 as a documented known issue.
 
 ## Rationale
+
 - Nebula is a transitive dependency via CrowdSec bouncer -> ipstore chain
 - Upgrading to v1.10.3 breaks compilation:
   - smallstep/certificates removed nebula APIs (NebulaCAPool, NewCAPoolFromBytes, etc.)
@@ -21,30 +23,37 @@ Accept the High severity vulnerability in nebula v1.9.7 as a documented known is
 - This is an upstream dependency management issue beyond our immediate control
 
 ## Dependency Chain
+
 - Caddy (xcaddy builder)
   - github.com/hslatman/caddy-crowdsec-bouncer@v0.9.2
     - github.com/hslatman/ipstore@v0.3.0
       - github.com/slackhq/nebula@v1.9.7 (vulnerable)
 
 ## Exploitability Assessment
+
 - Nebula is present in Docker image build artifacts
 - Used by CrowdSec bouncer for IP address management
 - Attack surface: [Requires further analysis - see monitoring plan]
 
 ## Monitoring Plan
+
 Watch for upstream fixes in:
+
 - github.com/hslatman/caddy-crowdsec-bouncer (primary)
 - github.com/hslatman/ipstore (secondary)
 - github.com/smallstep/certificates (nebula API compatibility)
 - github.com/slackhq/nebula (direct upgrade if dependency chain updates)
 
 Check quarterly (or when Dependabot/security scans alert):
-- CrowdSec bouncer releases: https://github.com/hslatman/caddy-crowdsec-bouncer/releases
-- ipstore releases: https://github.com/hslatman/ipstore/releases
-- smallstep/certificates releases: https://github.com/smallstep/certificates/releases
+
+- CrowdSec bouncer releases: <https://github.com/hslatman/caddy-crowdsec-bouncer/releases>
+- ipstore releases: <https://github.com/hslatman/ipstore/releases>
+- smallstep/certificates releases: <https://github.com/smallstep/certificates/releases>
 
 ## Remediation Trigger
+
 Revisit and remediate when ANY of:
+
 - caddy-crowdsec-bouncer releases version with nebula v1.10.3+ support
 - smallstep/certificates releases version compatible with nebula v1.10.3
 - ipstore releases version fixing GetAndDelete compatibility
@@ -52,12 +61,15 @@ Revisit and remediate when ANY of:
 - Proof-of-concept exploit published targeting Charon's attack surface
 
 ## Alternative Mitigation (Future)
+
 If upstream remains stalled:
+
 - Consider removing CrowdSec bouncer plugin (loss of CrowdSec integration)
 - Evaluate alternative IP blocking/rate limiting solutions
 - Implement CrowdSec integration at reverse proxy layer instead of Caddy
 
 ## References
-- CVE Details: https://github.com/advisories/GHSA-69x3-g4r3-p962
+
+- CVE Details: <https://github.com/advisories/GHSA-69x3-g4r3-p962>
 - Analysis Report: [docs/reports/nebula_upgrade_analysis.md](../reports/nebula_upgrade_analysis.md)
 - Version Test Results: [docs/reports/nebula_upgrade_analysis.md](../reports/nebula_upgrade_analysis.md#6-version-compatibility-test-results)

docs/security/archive/VULNERABILITY_ACCEPTANCE.md

@@ -21,6 +21,7 @@ This document provides formal acceptance and risk assessment for vulnerabilities
 **Decision**: Temporary acceptance pending Alpine Linux migration (already planned).
 
 **Rationale**:
+
 - CrowdSec LAPI authentication fix is CRITICAL for production users
 - CVEs are in Debian base packages, NOT application code
 - CVEs exist in `main` branch (blocking fix provides zero security improvement)
@@ -30,6 +31,7 @@ This document provides formal acceptance and risk assessment for vulnerabilities
 **Mitigation Plan**: Full Alpine migration (see `docs/plans/alpine_migration_spec.md`)
 
 **Expected Timeline**:
+
 - Week 1 (Feb 5-8): Verify Alpine CVE-2025-60876 is patched
 - Weeks 2-3 (Feb 11-22): Dockerfile migration + testing
 - Week 4 (Feb 26-28): Staging validation
@@ -40,6 +42,7 @@ This document provides formal acceptance and risk assessment for vulnerabilities
 **Detailed Security Advisory**: [`advisory_2026-02-04_debian_cves_temporary.md`](./advisory_2026-02-04_debian_cves_temporary.md)
 
 **Affected CVEs**:
+
 | CVE | CVSS | Package | Status |
 |-----|------|---------|--------|
 | CVE-2026-0861 | 8.4 | libc6 | No fix available → Alpine migration |
@@ -48,6 +51,7 @@ This document provides formal acceptance and risk assessment for vulnerabilities
 | CVE-2026-0915 | 7.5 | libc6 | No fix available → Alpine migration |
 
 **Approval Record**:
+
 - **Security Team**: APPROVED (temporary acceptance with mitigation) ✅
 - **QA Team**: APPROVED (conditions met) ✅
 - **DevOps Team**: APPROVED (Alpine migration feasible) ✅
@@ -77,6 +81,7 @@ PR #461 supply chain scan identified **9 vulnerabilities** in Alpine Linux 3.23.
 **Decision**: All vulnerabilities are **ACCEPTED** pending upstream Alpine Security Team patches. No application-level vulnerabilities were found.
 
 **Rationale**:
+
 - All CVEs are Alpine OS package issues, not Charon application code
 - No patches available from Alpine upstream as of 2026-01-13
 - Low exploitability in containerized deployment environment

docs/security/archive/VULNERABILITY_ASSESSMENT_PHASE2.md

@@ -29,11 +29,13 @@
 The golang.org/x/crypto/ssh package contains a vulnerability where improper use of the ServerConfig.PublicKeyCallback function could lead to authorization bypass. This is particularly critical for applications using SSH key-based authentication.
 
 **Risk Assessment:**
+
 - **Likelihood:** Medium (requires specific misuse pattern)
 - **Impact:** High (authorization bypass possible)
 - **Overall Risk:** HIGH
 
 **Remediation:**
+
 ```bash
 # Update crypto package to latest version
 go get -u golang.org/x/crypto@latest
@@ -46,6 +48,7 @@ go list -m golang.org/x/crypto
 ```
 
 **Verification Steps:**
+
 1. Run: `go mod tidy`
 2. Run: `trivy fs . --severity CRITICAL --format json | jq '.Results[] | select(.Vulnerabilities!=null) | .Vulnerabilities[] | select(.VulnerabilityID=="CVE-2024-45337")'`
 3. Confirm vulnerability no longer appears
@@ -249,6 +252,7 @@ git push
 ### Automated Dependency Updates
 
 **Recommended Setup:**
+
 1. Enable Dependabot on GitHub
 2. Set up automatic PR creation for security updates
 3. Configure CI to run on dependency PRs
@@ -257,6 +261,7 @@ git push
 ### Configuration
 
 **.github/dependabot.yml:**
+
 ```yaml
 version: 2
 updates:
@@ -305,6 +310,7 @@ updates:
 ## Timeline & Tracking
 
 ### Phase 1: Immediate (Today)
+
 - [ ] Review this report
 - [ ] Run remediation steps
 - [ ] Verify updates resolve CVEs
@@ -312,12 +318,14 @@ updates:
 - [ ] Commit and push updates
 
 ### Phase 2: Within 1 Week
+
 - [ ] Test updated dependencies
 - [ ] Run full E2E test suite
 - [ ] Performance verification
 - [ ] Deploy to staging
 
 ### Phase 3: Within 2 Weeks
+
 - [ ] Deploy to production
 - [ ] Monitor for issues
 - [ ] Set up automated scanning

docs/security/archive/accessibility_remediation_crowdsec.md

@@ -25,11 +25,13 @@ The CrowdSec "Ban IP" and "Unban IP" modals were identified as lacking standard
 Verification was performed using the Playwright E2E test suite running against a Dockerized environment.
 
 ### Test Environment
+
 - **Container**: `charon-e2e`
 - **Base URL**: `http://localhost:8080`
 - **Browser**: Firefox
 
 ### Test Execution
+
 **Command**: `npx playwright test tests/security/crowdsec-decisions.spec.ts -g "should open ban modal"`
 
 **Result**: ✅ **PASSED**
@@ -49,6 +51,7 @@ A broader run of `tests/security/crowdsec-decisions.spec.ts` was also executed,
 ## 4. Code Snippets
 
 ### Ban Modal
+
 ```tsx
 <div
   className="fixed inset-0 z-50 flex items-center justify-center"

docs/security/archive/advisory_2026-02-01_base_image_cves.md

@@ -15,6 +15,7 @@
 **This risk acceptance expires on May 2, 2026.**
 
 A fresh security review **MUST** be conducted before the expiration date to:
+
 - ✅ Verify patch availability from Debian Security
 - ✅ Re-assess risk level based on new threat intelligence
 - ✅ Renew or revoke this risk acceptance
@@ -27,6 +28,7 @@ A fresh security review **MUST** be conducted before the expiration date to:
 ## Executive Summary
 
 **Vulnerability Overview**:
+
 - **Total Vulnerabilities Detected**: 409
 - **HIGH Severity**: 7 (requires documentation and monitoring)
 - **Patches Available**: 0 (all HIGH CVEs unpatched as of February 1, 2026)
@@ -63,11 +65,13 @@ All HIGH severity vulnerabilities are in Debian Trixie base image system librari
 A heap overflow vulnerability exists in the memory alignment functions (`memalign`, `aligned_alloc`, `posix_memalign`) of GNU C Library (glibc). Exploitation requires an attacker to control the size or alignment parameters passed to these functions.
 
 **Charon Impact**: **MINIMAL**
+
 - Charon does not directly call `memalign` or related functions
 - Go's runtime memory allocator does not use these glibc functions for heap management
 - Attack requires direct control of memory allocation parameters
 
 **Exploitation Complexity**: **HIGH**
+
 - Requires vulnerable application code path
 - Attacker must control function parameters
 - Heap layout manipulation needed
@@ -84,12 +88,14 @@ A heap overflow vulnerability exists in the memory alignment functions (`memalig
 A stack buffer overflow exists in the ASN.1 parsing library (libtasn1) when processing maliciously crafted ASN.1 encoded data. This library is used by TLS/SSL implementations for certificate parsing.
 
 **Charon Impact**: **MINIMAL**
+
 - Charon uses Go's native `crypto/tls` package, not system libtasn1
 - Attack requires malformed TLS certificates presented to the application
 - Go's ASN.1 parser is memory-safe and not affected by this CVE
 - System libtasn1 is only used by OS-level services (e.g., system certificate validation)
 
 **Exploitation Complexity**: **HIGH**
+
 - Requires attacker-controlled certificate uploaded or presented
 - Go's TLS stack provides defense-in-depth
 
@@ -105,12 +111,14 @@ A stack buffer overflow exists in the ASN.1 parsing library (libtasn1) when proc
 The `wordexp()` function in glibc, when used with the `WRDE_REUSE` flag, can lead to improper memory management. This function performs shell-like word expansion and is typically used to parse configuration files or user input.
 
 **Charon Impact**: **NONE**
+
 - Charon is written in Go, does not call glibc `wordexp()`
 - Go's standard library does not use `wordexp()` internally
 - No shell expansion performed by Charon application code
 - Attack requires application to call vulnerable glibc function
 
 **Exploitation Complexity**: **VERY HIGH**
+
 - Requires vulnerable C/C++ application using `wordexp(WRDE_REUSE)`
 - Charon (Go) is not affected
 
@@ -126,12 +134,14 @@ The `wordexp()` function in glibc, when used with the `WRDE_REUSE` flag, can lea
 A vulnerability in the Name Service Switch (NSS) subsystem's handling of network address resolution (`getnetbyaddr`) can be exploited through malicious `nsswitch.conf` configurations.
 
 **Charon Impact**: **MINIMAL**
+
 - Charon uses Go's `net` package for DNS resolution, not glibc NSS
 - Go's resolver does not parse `/etc/nsswitch.conf`
 - Attack requires root/container escape to modify system configuration
 - Charon runs as non-root user with read-only filesystem
 
 **Exploitation Complexity**: **VERY HIGH**
+
 - Requires root access to modify `/etc/nsswitch.conf`
 - If attacker has root, this CVE is not the primary concern
 
@@ -208,6 +218,7 @@ A vulnerability in the Name Service Switch (NSS) subsystem's handling of network
 6. **Alternative Complexity**: Migrating to Alpine Linux requires significant testing effort
 
 **Acceptance Conditions**:
+
 - ✅ Weekly Grype scans to monitor for patches
 - ✅ Subscription to Debian Security Announce mailing list
 - ✅ 90-day re-evaluation mandatory (expires May 2, 2026)
@@ -236,6 +247,7 @@ cap_add:
 ```
 
 **Rationale**:
+
 - **`no-new-privileges`**: Prevents privilege escalation via setuid binaries
 - **Read-only filesystem**: Prevents modification of system libraries or binaries
 - **Non-root user**: Limits impact of container escape
@@ -244,12 +256,14 @@ cap_add:
 #### Application-Level Security
 
 **Cerberus Security Suite** (enabled in production):
+
 - ✅ **WAF (Coraza)**: Blocks common attack payloads (SQLi, XSS, RCE)
 - ✅ **ACL**: IP-based access control to admin interface
 - ✅ **Rate Limiting**: Prevents brute-force and DoS attempts
 - ✅ **CrowdSec**: Community-driven threat intelligence and IP reputation
 
 **TLS Configuration**:
+
 - ✅ TLS 1.3 minimum (enforced by Caddy reverse proxy)
 - ✅ Strong cipher suites only (no weak ciphers)
 - ✅ HTTP Strict Transport Security (HSTS)
@@ -258,6 +272,7 @@ cap_add:
 #### Network Security
 
 **Firewall Rules** (example for production deployment):
+
 ```bash
 # Allow only HTTPS and SSH
 iptables -A INPUT -p tcp --dport 443 -j ACCEPT
@@ -280,6 +295,7 @@ iptables -A FORWARD -i docker0 -o eth0 -d 10.0.0.0/8 -j DROP  # Block internal n
 **CI Integration**: GitHub Actions workflow
 
 **Workflow**:
+
 ```yaml
 # .github/workflows/security-scan-weekly.yml
 name: Weekly Security Scan
@@ -300,6 +316,7 @@ jobs:
 ```
 
 **Alert Triggers**:
+
 - ✅ Patch available for any HIGH CVE → Create PR automatically
 - ✅ New CRITICAL CVE discovered → Slack/email alert to security team
 - ✅ 7 days before expiration (April 25, 2026) → Calendar reminder
@@ -308,11 +325,12 @@ jobs:
 
 ### Debian Security Mailing List Subscription
 
-**Mailing List**: security-announce@lists.debian.org
-**Subscriber**: security-team@example.com
+**Mailing List**: <security-announce@lists.debian.org>
+**Subscriber**: <security-team@example.com>
 **Filter Rule**: Flag emails mentioning CVE-2026-0861, CVE-2025-13151, CVE-2025-15281, CVE-2026-0915
 
 **Response SLA**:
+
 - **Patch announced**: Review and test within 48 hours
 - **Backport required**: Create PR within 5 business days
 - **Breaking change**: Schedule maintenance window within 2 weeks
@@ -336,9 +354,10 @@ jobs:
    - 🟠 **High Priority**: Assess impact and plan migration to Alpine Linux if needed
 
 **Contact List**:
-- Security Team Lead: security-lead@example.com
-- DevOps On-Call: oncall-devops@example.com
-- CTO: cto@example.com
+
+- Security Team Lead: <security-lead@example.com>
+- DevOps On-Call: <oncall-devops@example.com>
+- CTO: <cto@example.com>
 
 ---
 
@@ -347,18 +366,21 @@ jobs:
 ### Alpine Linux (Considered for Future Migration)
 
 **Advantages**:
+
 - ✅ Smaller attack surface (~5MB vs. ~120MB Debian base)
 - ✅ musl libc (not affected by glibc CVEs)
 - ✅ Faster security updates
 - ✅ Immutable infrastructure friendly
 
 **Disadvantages**:
+
 - ❌ Different C library (musl) - potential compatibility issues
 - ❌ Limited pre-built binary packages (Go binaries are fine)
 - ❌ Less mature ecosystem vs. Debian
 - ❌ Requires extensive regression testing
 
 **Decision**: Defer Alpine migration until:
+
 - Debian Trixie reaches end-of-life, OR
 - CRITICAL unpatched CVE with active exploit
 
@@ -401,22 +423,24 @@ For use during compliance audits (SOC 2, ISO 27001, etc.):
 
 ### Vulnerability Trackers
 
-- **Debian Security Tracker**: https://security-tracker.debian.org/tracker/
-- **CVE-2026-0861**: https://security-tracker.debian.org/tracker/CVE-2026-0861
-- **CVE-2025-13151**: https://security-tracker.debian.org/tracker/CVE-2025-13151
-- **CVE-2025-15281**: https://security-tracker.debian.org/tracker/CVE-2025-15281
-- **CVE-2026-0915**: https://security-tracker.debian.org/tracker/CVE-2026-0915
+- **Debian Security Tracker**: <https://security-tracker.debian.org/tracker/>
+- **CVE-2026-0861**: <https://security-tracker.debian.org/tracker/CVE-2026-0861>
+- **CVE-2025-13151**: <https://security-tracker.debian.org/tracker/CVE-2025-13151>
+- **CVE-2025-15281**: <https://security-tracker.debian.org/tracker/CVE-2025-15281>
+- **CVE-2026-0915**: <https://security-tracker.debian.org/tracker/CVE-2026-0915>
 
 ### Scan Results
 
 **Grype Scan Executed**: February 1, 2026
 **Scan Command**:
+
 ```bash
 grype charon:latest -o json > grype-results.json
 grype charon:latest -o sarif > grype-results.sarif
 ```
 
 **Full Results**:
+
 - JSON: `/projects/Charon/grype-results.json`
 - SARIF: `/projects/Charon/grype-results.sarif`
 - Summary: 409 total vulnerabilities (0 Critical, 7 High, 20 Medium, 2 Low, 380 Negligible)

docs/security/archive/advisory_2026-02-04_debian_cves_temporary.md

@@ -26,12 +26,14 @@ During Docker image security scanning, 7 HIGH severity CVEs were identified in t
 **Actual Risk Level**: 🟢 **LOW**
 
 **Justification**:
+
 - CVEs affect Debian system libraries, NOT application code
 - No direct exploit paths identified in Charon's usage patterns
 - Application runs in isolated container environment
 - User-facing services do not expose vulnerable library functionality
 
 **Mitigating Factors**:
+
 1. Container isolation limits exploit surface area
 2. Charon does not directly invoke vulnerable libc/libtiff functions
 3. Network ingress filtered through Caddy proxy
@@ -42,6 +44,7 @@ During Docker image security scanning, 7 HIGH severity CVEs were identified in t
 **Strategy**: Migrate back to Alpine Linux base image
 
 **Timeline**:
+
 - **Week 1 (Feb 5-8)**: Verify Alpine CVE-2025-60876 is patched
 - **Weeks 2-3 (Feb 11-22)**: Dockerfile migration + comprehensive testing
 - **Week 4 (Feb 26-28)**: Staging deployment validation
@@ -64,6 +67,7 @@ During Docker image security scanning, 7 HIGH severity CVEs were identified in t
 ### Why Not Block?
 
 Blocking the CrowdSec fix would:
+
 - Leave user's production environment broken
 - Provide ZERO security improvement (CVEs pre-exist in all branches)
 - Delay critical authentication fixes unrelated to base image
@@ -72,17 +76,20 @@ Blocking the CrowdSec fix would:
 ## Monitoring
 
 **Continuous Tracking**:
+
 - Debian security advisories (daily monitoring)
 - Alpine CVE status (Phase 1 gate: must be clean)
 - Exploit database updates (CISA KEV, Exploit-DB)
 
 **Alerting**:
+
 - Notify if Debian releases patches (expedite Alpine migration)
 - Alert if active exploits published (emergency Alpine migration)
 
 ## User Communication
 
 **Transparency Commitment**:
+
 - Document in CHANGELOG.md
 - Include in release notes
 - Update SECURITY.md with mitigation timeline
@@ -99,6 +106,7 @@ Blocking the CrowdSec fix would:
 ---
 
 **References**:
+
 - Alpine Migration Spec: [`docs/plans/alpine_migration_spec.md`](../plans/alpine_migration_spec.md)
 - QA Report: [`docs/reports/qa_report.md`](../reports/qa_report.md)
 - Vulnerability Acceptance Policy: [`docs/security/VULNERABILITY_ACCEPTANCE.md`](VULNERABILITY_ACCEPTANCE.md)

docs/security/archive/api-key-handling.md

@@ -33,6 +33,7 @@ The `maskAPIKey()` function implements these rules:
 3. **Normal keys (≥ 16 chars)**: Shows first 4 + last 4 characters (e.g., `abcd...xyz9`)
 
 These rules ensure that:
+
 - Keys cannot be reconstructed from logs
 - Users can still identify which key was used (by prefix/suffix)
 - Debugging remains possible without exposing secrets
@@ -49,6 +50,7 @@ err := os.WriteFile(keyFile, []byte(apiKey), 0600)
 ```
 
 **Required permissions**: `0600` (rw-------)
+
 - Owner: read + write
 - Group: no access
 - Others: no access
@@ -96,6 +98,7 @@ strings.Repeat("a", 129)              // ❌ Too long (> 128 chars)
 ### Log Aggregation Risks
 
 If logs are shipped to external services (CloudWatch, Splunk, Datadog, etc.):
+
 - Masked keys are safe to log
 - Full keys would be exposed across multiple systems
 - Log retention policies apply to all destinations
@@ -148,11 +151,13 @@ c.JSON(200, gin.H{
 ### Rotation Procedure
 
 1. Generate new bouncer in CrowdSec:
+
    ```bash
    cscli bouncers add new-bouncer-name
    ```
 
 2. Update Charon configuration:
+
    ```bash
    # Update environment variable
    CHARON_SECURITY_CROWDSEC_API_KEY=new-key-here
@@ -165,6 +170,7 @@ c.JSON(200, gin.H{
 3. Restart Charon to apply new key
 
 4. Revoke old bouncer:
+
    ```bash
    cscli bouncers delete old-bouncer-name
    ```
@@ -233,6 +239,7 @@ go test ./backend/internal/api/handlers -run TestSaveKeyToFile_SecurePermissions
 ### Test Scenarios
 
 Tests cover:
+
 - ✅ Empty keys → `[empty]`
 - ✅ Short keys (< 16) → `[REDACTED]`
 - ✅ Normal keys → `abcd...xyz9`

docs/security/ghsa-69x3-g4r3-p962-options.md

@@ -158,6 +158,7 @@ These checks help estimate practical risk and verify assumptions. They do **not*
 7. Reassess exception validity on each CI security scan cycle.
 
 ## Notes
+
 - As of the testing on 2026-02-19, just updating nebula to `1.10.3` in the Dockerfile causes build failures due to upstream incompatibilities, which supports the attribution and reproduction evidence for the temporary exception path.
 - The conflict between `smallstep/certificates` and `nebula` API changes is a known issue in the ecosystem, which adds external validity to the hypothesis about the dependency chain.
 - Will need to monitor upstream releases of `smallstep/certificates` and `Caddy` for compatible versions that allow upgrading `nebula` without breaking builds.