Add SBOM, symbols, traces, and VEX files for CVE-2022-21661 SQLi case

- Created CycloneDX and SPDX SBOM files for both reachable and unreachable images. - Added symbols.json detailing function entry and sink points in the WordPress code. - Included runtime traces for function calls in both reachable and unreachable scenarios. - Developed OpenVEX files indicating vulnerability status and justification for both cases. - Updated README for evaluator harness to guide integration with scanner output.
2025-11-08 20:53:45 +02:00
parent 515975edc5
commit 536f6249a6
837 changed files with 37279 additions and 14675 deletions
--- a/docs/security/crypto-routing-audit-2025-11-07.md
+++ b/docs/security/crypto-routing-audit-2025-11-07.md
@@ -0,0 +1,113 @@
+# Crypto Routing Audit — 07 Nov 2025
+
+**Scope.** Inventory direct uses of `System.Security.Cryptography` (and related primitives) outside the `StellaOps.Cryptography*` stack to identify callers that must be routed through sovereign-aware providers (default, PKCS#11, CryptoPro, future PQC).
+
+**Method.** `rg -l "using System.Security.Cryptography" src | grep -Ev "__Tests|\.Tests/"` (filtered for runtime code). Counts reflect unique files per top-level module.
+
+## Summary (runtime files by module)
+
+| Module/Area | Files bypassing shared crypto |
+|-------------|------------------------------|
+| Concelier   | 34 |
+| Scanner     | 31 |
+| Authority   | 20 |
+| Excititor   | 18 |
+| Attestor    | 18 |
+| EvidenceLocker | 10 |
+| Findings / Vuln Explorer | 7 |
+| Zastava     | 6 |
+| ExportCenter| 6 |
+| Policy      | 4 |
+| Scheduler   | 3 |
+| CLI         | 3 |
+| Bench       | 3 |
+| AdvisoryAI  | 3 |
+| Other (Notify, Registry, Signals, etc.) | 11 combined |
+
+## Configuring `crypto.regionalProfiles`
+
+All hosts can now express provider ordering and profile overrides via configuration:
+
+```yaml
+Crypto:
+  registry:
+    preferredProviders:
+      - default
+      - ru.pkcs11
+    activeProfile: ru-offline
+    profiles:
+      ru-offline:
+        preferredProviders:
+          - ru.cryptopro.csp
+          - ru.pkcs11
+  pkcs11:
+    keys:
+      - keyId: ru-slot-token
+        libraryPath: /usr/local/lib/librutokenecp.so
+        slotId: "0x1"
+        privateKeyLabel: signing-key
+        certificateThumbprint: "<thumbprint>"
+  cryptopro:
+    keys:
+      - keyId: ru-csp-token
+        libraryPath: /opt/cprocsp/lib/libcapi20.so
+        containerLabel: KRYPTO_PRO_KEY
+        certificateThumbprint: "<thumbprint>"
+```
+
+Each deployment picks a profile (`activeProfile`) that resolves to a deterministic provider order, and individual services call into `ICryptoProviderRegistry` rather than new-ing crypto stacks directly.
+
+## Inspecting providers from the CLI
+
+`stellaops crypto providers` now lists the registered providers, signing algorithms, certificate metadata, and the current preferred order. Use `--json` for machine-readable output or `--profile <name>` to preview another profile (e.g., `ru-offline`) before flipping configuration.
+
+## High-priority hotspots
+
+### Concelier (ingestion + mirror connectors)
+- `src/Concelier/StellaOps.Concelier.WebService/Services/OpenApiDiscoveryDocumentProvider.cs` – builds SHA256 hashes for discovery docs inline.
+- `src/Concelier/__Libraries/StellaOps.Concelier.Connector.StellaOpsMirror/Security/MirrorSignatureVerifier.cs` – performs RSA verification directly.
+- `src/Concelier/__Libraries/StellaOps.Concelier.Connector.Ru.Nkcki/RuNkckiConnector.cs` and `.Ru.Bdu` – local hash/signature handling for regional advisories.
+
+**Action:** Introduce `ICryptoProviderRegistry` consumption inside connector/lib assemblies (probably through lightweight adapter service). File follow-up tasks in `src/Concelier/StellaOps.Concelier.WebService/TASKS.md` and connector TASK boards to migrate hashing/signing to the new PKCS#11/CryptoPro providers (priority for RU feeds to unblock RootPack_RU).
+
+### Scanner (web service, worker, Sbomer plug-ins)
+- `src/Scanner/StellaOps.Scanner.WebService/Utilities/ScanIdGenerator.cs` – direct SHA256 for id derivation.
+- `src/Scanner/StellaOps.Scanner.WebService/Services/ReportSigner.cs` – uses `ECDsa.Create()` directly for DSSE hand-off.
+- `src/Scanner/StellaOps.Scanner.Worker/Processing/Surface/SurfaceManifestPublisher.cs` – manual digesting before CAS writes.
+
+**Action:** Create shared `IScanCryptoService` backed by `ICryptoProviderRegistry` so both web service and worker reuse sovereign providers. Add tasks under `src/Scanner/StellaOps.Scanner.WebService/TASKS.md` and `src/Scanner/StellaOps.Scanner.Worker/TASKS.md`.
+
+### Authority (plugins + signing host)
+- `StellaOps.Authority/Signing/*` classes still load PEM/PKCS#12 directly via `X509Certificate2` and `RSA`.
+- `AuthoritySecretHasher` and `AuthorityClientCertificateValidator` maintain custom hashing.
+
+**Action:** Wire Authority signing/loading paths to `ICryptoProviderRegistry` so active keys can point to `ru.cryptopro.csp` or `ru.pkcs11`. Open tasks in `src/Authority/StellaOps.Authority/TASKS.md` covering: signing key loading, JWKS generation, secret hashing migration.
+
+### Excititor / Attestor
+- Excititor connectors (e.g., `src/Excititor/__Libraries/StellaOps.Excititor.Connectors.Ghsa/GhsaConnector.cs`) re-hash payloads in place.
+- Attestor submission cache uses SHA256 for bundle ids.
+
+**Action:** Introduce shared hashing helper that internally calls `ICryptoProviderRegistry.ResolveOrThrow(CryptoCapability.Signing, SignatureAlgorithms.GostR3410_2012_256)` for digest+sign combos; log follow-ups in respective TASK boards.
+
+### Evidence Locker / Export Center
+- Export packaging code manually builds SHA/V1 digests before signing manifests.
+
+**Action:** Add backlog tasks for both modules to replace `SHA256.Create()` usage with provider-backed hashing (especially for offline bundle sealing).
+
+## Next steps
+1. **Open remediation tasks per module** referencing this audit (minimum: Concelier, Scanner, Authority, Excititor, Attestor, Evidence Locker, Export Center). Each task should specify which files to migrate and target provider (default vs sovereign).  
+2. **Provide shared helpers** (e.g., `ICryptoDigestService`, `ICasSigner`) in `StellaOps.Cryptography` to ease adoption and avoid each module talking to the registry manually.  
+3. **Follow-up audit** once migrations land; rerun the command and ensure only `StellaOps.Cryptography*` and vetted crypto libraries contain direct `System.Security.Cryptography` usage.  
+4. **RootPack validation runbook** — see `docs/security/rootpack_ru_validation.md` for deterministic tests, hardware validation, and required audit artifacts before shipping RootPack_RU.
+
+### Remediation tracking snapshot (2025-11-08)
+
+- **Authority:** `AUTH-CRYPTO-90-001` (Authority TASKS board)  
+- **Scanner:** `SCANNER-CRYPTO-90-001` (WebService TASKS board)  
+- **Concelier:** `CONCELIER-CRYPTO-90-001` (WebService TASKS board)  
+- **Excititor:** `EXCITITOR-CRYPTO-90-001` (WebService TASKS board)  
+- **Attestor:** `ATTESTOR-CRYPTO-90-001` (Attestor TASKS board)  
+- **Evidence Locker:** `EVID-CRYPTO-90-001` (Evidence Locker TASKS board)  
+- **Export Center:** `EXPORT-CRYPTO-90-001` (Exporter Service TASKS board)
+
+> Stored query artifacts: `/tmp/crypto_runtime_non_tests.txt` (157 runtime files) and aggregated counts above prepared on 2025-11-07.
--- a/docs/security/dpop-mtls-rollout.md
+++ b/docs/security/dpop-mtls-rollout.md
@@ -0,0 +1,45 @@
+# Authority DPoP + mTLS Rollout Plan (Sprint 100)
+
+_Last updated: 2025-11-07_
+
+## Objectives
+1. Enforce DPoP sender constraints (`AUTH-DPOP-11-001`).
+2. Bind high-assurance tenants to mTLS tokens (`AUTH-MTLS-11-002`).
+3. Provide telemetry + runbooks so plugins (SEC2/SEC3/SEC5) can validate enforcement without regressions.
+
+## Phase 1 · Config & Telemetry (ETA 2025-11-08)
+- [ ] Extend `authority.yaml` with `security.senderConstraints.dpop` section (nonce store, allowed algorithms, replay window).
+- [ ] Wire structured logs (`authority.dpop.request`) containing tenant, client, cnf thumbprint, nonce status.
+- [ ] Add `DPoPNonceStore` abstraction + Redis implementation for multi-node deployments.
+- [ ] Update integration tests: `AuthorityTokenTests.DPoPNonceRequired`, `AuthorityTokenTests.DPoPMustMatchCnF`.
+
+## Phase 2 · Enforcement & Fallback (ETA 2025-11-10)
+- [ ] Reject `/token` requests lacking DPoP proof when tenant policy requires it.
+- [ ] Persist `cnf.jkt` and expose through `/introspect` so downstream services validate sender.
+- [ ] Add emergency bypass flag (`security.senderConstraints.dpop.allowTemporaryBypass`) for sealed recap drills; default disabled.
+
+## Phase 3 · mTLS Binding (ETA 2025-11-10)
+- [x] Capture client cert thumbprint on `/token` (mutual TLS) and store in `authority_tokens.senderCertificate`.
+- [x] Validate cert hash on `/introspect` and `/fresh-auth`.
+- [ ] Document bootstrap/rotation in `docs/11_AUTHORITY.md` + `docs/security/dpop-mtls-rollout.md` (this file).
+
+## Verification Matrix
+| Scenario | Test/Command | Expected |
+| --- | --- | --- |
+| DPoP required w/out proof | `dotnet test Authority.Tests --filter DPoPRequiresProofTest` | 400 with `use_dpop_nonce` header. |
+| Nonce replay | Replay previous proof within window | 401 + audit log entry. |
+| mTLS mismatch | Reuse token with different cert | 401 + `senderCertificateMismatch` metric increment. |
+
+## Telemetry & Alerting
+- Metrics: `authority_dpop_nonce_miss_total`, `authority_mtls_mismatch_total` (emitted with `reason` tags for context-missing, missing-certificate, and thumbprint-mismatch cases).
+- Logs: `authority.security.senderConstraint` (structured).
+- Alerts: Page DevOps when nonce miss > 5% or mTLS mismatches > 0 over 10 min.
+
+## Dependencies
+- Authority Core & Security Guild owners.
+- DevOps to provide sealed-mode CI coverage (`DEVOPS-AIRGAP-57-002`).
+- Plugin Standard Guild to consume new telemetry once rolled out.
+
+## Communication
+- Daily async update in `#guild-authority` thread referencing this plan.
+- Link this document from `docs/implplan/SPRINT_100_identity_signing.md` notes once Phase 1 merges.
--- a/docs/security/rootpack_ru_package.md
+++ b/docs/security/rootpack_ru_package.md
@@ -0,0 +1,68 @@
+# RootPack_RU Packaging Guide
+
+This guide describes the reproducible process for assembling the sovereign cryptography bundle that backs RootPack_RU deployments.
+
+## 1. What the bundle contains
+
+| Directory | Purpose |
+|-----------|---------|
+| `artifacts/` | Published binaries for `StellaOps.Cryptography.Plugin.CryptoPro` and `StellaOps.Cryptography.Plugin.Pkcs11Gost` (targeting `net10.0`). |
+| `config/rootpack_ru.crypto.yaml` | Opinionated configuration template that enables the `ru-offline` crypto profile and defines CryptoPro + PKCS#11 keys. |
+| `docs/` | Validation runbook, audit report, and this packaging guide. |
+| `trust/` | Russian trust-anchor PEM files copied from `certificates/russian_trusted_*`. |
+| `README.txt` | High-level summary plus operator checklist. |
+
+## 2. Build the bundle
+
+```bash
+# from repository root
+scripts/crypto/package-rootpack-ru.sh
+# optionally specify destination
+scripts/crypto/package-rootpack-ru.sh /tmp/rootpack_ru_$(date -u +%Y%m%dT%H%M%SZ)
+```
+
+The script performs the following steps:
+
+1. `dotnet publish` for the CryptoPro + PKCS#11 plug-ins (`Release` configuration).
+2. Copies the relevant documentation (`docs/security/rootpack_ru_validation.md`, `docs/security/crypto-routing-audit-2025-11-07.md`, and this guide).
+3. Includes the example configuration found at `etc/rootpack/ru/crypto.profile.yaml`.
+4. Adds the Russian trust anchors from `certificates/russian_trusted_*`.
+5. Emits `README.txt` and optionally creates a `*.tar.gz` archive (set `PACKAGE_TAR=0` to skip the tarball).
+
+## 3. Attach deterministic test evidence
+
+After running `scripts/crypto/package-rootpack-ru.sh`, execute the deterministic harness to capture logs:
+
+```bash
+scripts/crypto/run-rootpack-ru-tests.sh
+# or specify ROOTPACK_LOG_DIR=/tmp/rootpack_ru_tests scripts/crypto/run-rootpack-ru-tests.sh
+```
+
+Copy the resulting `logs/rootpack_ru_<timestamp>/` directory into the bundle before distributing it (or store it alongside the tarball in your evidence store).
+
+Each harness run produces a `README.tests` file plus matching `.log/.trx` pairs for every project. Move the entire directory under an evidence folder inside the bundle (for example `evidence/validation/<timestamp>/`) so operators can quickly locate the README, raw logs, and provider JSON snapshots when assembling compliance paperwork:
+
+```bash
+dest="${1:-out/rootpack_ru}"
+ts="$(ls logs | grep rootpack_ru_ | sort | tail -n1)"
+mkdir -p "${dest}/evidence/validation"
+cp -a "logs/${ts}" "${dest}/evidence/validation/${ts}"
+```
+
+## 4. Hardware validation + audit metadata
+
+Follow `docs/security/rootpack_ru_validation.md` to:
+
+- Validate CryptoPro CSP and PKCS#11 tokens.
+- Capture `stellaops crypto providers --profile ru-offline --json` output.
+- Archive JWKS snapshots and `CryptoProviderMetrics` samples.
+- Document hardware serials and operator initials in `hardware_notes.md`.
+
+Store these artifacts under `logs/rootpack_ru_<timestamp>/` (same directory as the test harness outputs) and reference them in release paperwork.
+
+## 5. Deployment summary
+
+1. Import the bundled trust anchors into the target installation (Authority + Scanner).
+2. Apply `config/rootpack_ru.crypto.yaml`, update certificate thumbprints, slots, and container labels to match the operator tokens.
+3. Restart the services so `ICryptoProviderRegistry` reloads the `ru-offline` profile.
+4. Re-run the validation runbook to confirm JWKS, telemetry, and RootPack evidence are aligned with the shipping bundle.
--- a/docs/security/rootpack_ru_validation.md
+++ b/docs/security/rootpack_ru_validation.md
@@ -0,0 +1,45 @@
+# RootPack_RU Crypto Validation Runbook
+
+## Purpose
+
+This runbook documents the repeatable steps for validating the Russian sovereign crypto profile (CryptoPro + PKCS#11) prior to publishing a RootPack bundle. It supplements the crypto routing audit by covering deterministic tests, hardware validation, and the audit metadata artifacts that must be attached to each release.
+
+## 1. Deterministic Test Harness
+
+1. Run `scripts/crypto/run-rootpack-ru-tests.sh` (optional `ROOTPACK_LOG_DIR=/tmp/rootpack_ru_logs` to override the output path). The script executes:
+   - `src/__Libraries/__Tests/StellaOps.Cryptography.Tests/StellaOps.Cryptography.Tests.csproj`
+   - `src/Scanner/__Tests/StellaOps.Scanner.Worker.Tests/StellaOps.Scanner.Worker.Tests.csproj`
+   - `src/Scanner/__Tests/StellaOps.Scanner.Sbomer.BuildXPlugin.Tests/StellaOps.Scanner.Sbomer.BuildXPlugin.Tests.csproj`
+   and emits `.log` + `.trx` pairs plus `README.tests` under `logs/rootpack_ru_<timestamp>/`.
+2. For ad-hoc runs (CI or IDE) ensure the same three projects succeed; the cryptography tests validate SHA-256/SHA-512 against BCL implementations and both Streebog variants against BouncyCastle digests.
+3. Archive the generated log directory (`logs/rootpack_ru_<timestamp>/`) along with any additional test outputs inside the RootPack evidence bundle.
+
+## 2. Hardware Validation (CryptoPro CSP)
+
+1. Install CryptoPro CSP (v5.0 or later) on the validation host and import the qualified certificate configured for the deployment.
+2. Configure `StellaOps:Crypto:CryptoPro:Keys` with the container handle and certificate thumbprint and set `StellaOps:Crypto:Registry:ActiveProfile=ru-offline`.
+3. Run the provider diagnostics to confirm the key material is visible:
+   - `stellaops crypto providers --profile ru-offline --json > logs/ru_cryptopro_providers.json`
+4. Issue a JWKS fetch (`curl https://authority.local/.well-known/jwks`) and verify the `kid` and `crv` values match the CryptoPro-backed key.
+5. Capture the Authority logs showing `AuthoritySecretHasherInitializer` startup and the `CryptoProviderMetrics` counters for `ru.cryptopro.csp` usage.
+
+## 3. Hardware Validation (PKCS#11 Tokens)
+
+1. Install the vendor PKCS#11 library (e.g., Rutoken `rtPKCS11ECP.dll` or JaCarta) and configure the slot/PIN inside `StellaOps:Crypto:Pkcs11:Keys`.
+2. Switch the registry profile to prioritize `ru.pkcs11` and rerun `stellaops crypto providers --profile ru-offline --json > logs/ru_pkcs11_providers.json`.
+3. Execute a signing workflow (Authority JWKS refresh or Scanner manifest publish) and confirm the `CryptoProviderMetrics` counters record `ru.pkcs11` activity.
+4. Export the token audit logs (if available) and store them with the RootPack evidence bundle.
+
+## 4. RootPack Audit Metadata
+
+Create a metadata bundle per validation run and store it under `logs/rootpack_ru_<timestamp>/` containing:
+
+- `providers_ru_offline.json` – output from `stellaops crypto providers --profile ru-offline --json`.
+- `crypto_tests.txt` – snippets from the unit-test executions listed above.
+- `hardware_notes.md` – human-readable notes describing token serials, firmware, and operator initials.
+- `jwks_snapshot.json` – raw JWKS response captured after sovereign providers are active.
+- `metrics_snapshot.json` – scrape of `CryptoProviderMetrics` Prometheus samples for both providers.
+
+Attach this directory to the RootPack artifact and reference it from the release checklist.
+
+Refer back to `docs/security/crypto-routing-audit-2025-11-07.md` for the full inventory of components that must consume the shared cryptography stack, and `docs/security/rootpack_ru_package.md` for packaging/attachment steps.