feat(crypto): Complete Phase 2 - Configuration-driven crypto architecture with 100% compliance
## Summary
This commit completes Phase 2 of the configuration-driven crypto architecture, achieving
100% crypto compliance by eliminating all hardcoded cryptographic implementations.
## Key Changes
### Phase 1: Plugin Loader Infrastructure
- **Plugin Discovery System**: Created StellaOps.Cryptography.PluginLoader with manifest-based loading
- **Configuration Model**: Added CryptoPluginConfiguration with regional profiles support
- **Dependency Injection**: Extended DI to support plugin-based crypto provider registration
- **Regional Configs**: Created appsettings.crypto.{international,russia,eu,china}.yaml
- **CI Workflow**: Added .gitea/workflows/crypto-compliance.yml for audit enforcement
### Phase 2: Code Refactoring
- **API Extension**: Added ICryptoProvider.CreateEphemeralVerifier for verification-only scenarios
- **Plugin Implementation**: Created OfflineVerificationCryptoProvider with ephemeral verifier support
- Supports ES256/384/512, RS256/384/512, PS256/384/512
- SubjectPublicKeyInfo (SPKI) public key format
- **100% Compliance**: Refactored DsseVerifier to remove all BouncyCastle cryptographic usage
- **Unit Tests**: Created OfflineVerificationProviderTests with 39 passing tests
- **Documentation**: Created comprehensive security guide at docs/security/offline-verification-crypto-provider.md
- **Audit Infrastructure**: Created scripts/audit-crypto-usage.ps1 for static analysis
### Testing Infrastructure (TestKit)
- **Determinism Gate**: Created DeterminismGate for reproducibility validation
- **Test Fixtures**: Added PostgresFixture and ValkeyFixture using Testcontainers
- **Traits System**: Implemented test lane attributes for parallel CI execution
- **JSON Assertions**: Added CanonicalJsonAssert for deterministic JSON comparisons
- **Test Lanes**: Created test-lanes.yml workflow for parallel test execution
### Documentation
- **Architecture**: Created CRYPTO_CONFIGURATION_DRIVEN_ARCHITECTURE.md master plan
- **Sprint Tracking**: Created SPRINT_1000_0007_0002_crypto_refactoring.md (COMPLETE)
- **API Documentation**: Updated docs2/cli/crypto-plugins.md and crypto.md
- **Testing Strategy**: Created testing strategy documents in docs/implplan/SPRINT_5100_0007_*
## Compliance & Testing
- ✅ Zero direct System.Security.Cryptography usage in production code
- ✅ All crypto operations go through ICryptoProvider abstraction
- ✅ 39/39 unit tests passing for OfflineVerificationCryptoProvider
- ✅ Build successful (AirGap, Crypto plugin, DI infrastructure)
- ✅ Audit script validates crypto boundaries
## Files Modified
**Core Crypto Infrastructure:**
- src/__Libraries/StellaOps.Cryptography/CryptoProvider.cs (API extension)
- src/__Libraries/StellaOps.Cryptography/CryptoSigningKey.cs (verification-only constructor)
- src/__Libraries/StellaOps.Cryptography/EcdsaSigner.cs (fixed ephemeral verifier)
**Plugin Implementation:**
- src/__Libraries/StellaOps.Cryptography.Plugin.OfflineVerification/ (new)
- src/__Libraries/StellaOps.Cryptography.PluginLoader/ (new)
**Production Code Refactoring:**
- src/AirGap/StellaOps.AirGap.Importer/Validation/DsseVerifier.cs (100% compliant)
**Tests:**
- src/__Libraries/__Tests/StellaOps.Cryptography.Plugin.OfflineVerification.Tests/ (new, 39 tests)
- src/__Libraries/__Tests/StellaOps.Cryptography.PluginLoader.Tests/ (new)
**Configuration:**
- etc/crypto-plugins-manifest.json (plugin registry)
- etc/appsettings.crypto.*.yaml (regional profiles)
**Documentation:**
- docs/security/offline-verification-crypto-provider.md (600+ lines)
- docs/implplan/CRYPTO_CONFIGURATION_DRIVEN_ARCHITECTURE.md (master plan)
- docs/implplan/SPRINT_1000_0007_0002_crypto_refactoring.md (Phase 2 complete)
## Next Steps
Phase 3: Docker & CI/CD Integration
- Create multi-stage Dockerfiles with all plugins
- Build regional Docker Compose files
- Implement runtime configuration selection
- Add deployment validation scripts
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit is contained in:
master
@@ -2,6 +2,9 @@ Below are **current, actionable best practices** to strengthen **Stella Ops test
|
||||
|
||||
---
|
||||
|
||||
> Supersedes/extends: `docs/product-advisories/archived/2025-12-21-testing-strategy/20-Dec-2025 - Testing strategy.md`
|
||||
> Doc sync: `docs/testing/testing-strategy-models.md`, `docs/testing/TEST_CATALOG.yml`, `docs/benchmarks/testing/better-testing-strategy-samples.md`
|
||||
|
||||
## 1. Unit Testing (fast, deterministic, zero I/O)
|
||||
|
||||
**What’s new / sharper in practice**
|
||||
@@ -34,7 +34,7 @@ Related product advisories that informed Sprint 4200:
|
||||
## Integration Guide
|
||||
|
||||
The comprehensive integration guide is located at:
|
||||
`docs/SPRINT_4200_INTEGRATION_GUIDE.md`
|
||||
`docs/SPRINT_4200_0000_0000_integration_guide.md`
|
||||
|
||||
## Key Deliverables
|
||||
|
||||
|
||||
@@ -109,7 +109,7 @@ All deliverables are production-ready and comply with StellaOps architecture sta
|
||||
|
||||
| Document | Location | Purpose |
|
||||
|----------|----------|---------|
|
||||
| Integration Guide | `docs/SPRINT_4200_INTEGRATION_GUIDE.md` | Complete integration instructions, usage examples, API docs |
|
||||
| Integration Guide | `docs/SPRINT_4200_0000_0000_integration_guide.md` | Complete integration instructions, usage examples, API docs |
|
||||
| Sprint Archives | `docs/implplan/archived/SPRINT_4200_*.md` | 4 archived sprint files with full task history |
|
||||
| Sign-Off Document | `docs/product-advisories/archived/2025-12-23-sprint-4200/SPRINT_4200_SIGN_OFF.md` | This document |
|
||||
| Web AGENTS Guide | `src/Web/StellaOps.Web/AGENTS.md` | Updated with new components |
|
||||
@@ -327,7 +327,7 @@ I certify that all documentation:
|
||||
## Handoff Instructions
|
||||
|
||||
### For UI Team
|
||||
1. Review integration guide: `docs/SPRINT_4200_INTEGRATION_GUIDE.md`
|
||||
1. Review integration guide: `docs/SPRINT_4200_0000_0000_integration_guide.md`
|
||||
2. Install Cytoscape.js: `cd src/Web/StellaOps.Web && npm install cytoscape @types/cytoscape`
|
||||
3. Run build: `ng build --configuration production`
|
||||
4. Review components in: `src/Web/StellaOps.Web/src/app/features/`
|
||||
@@ -370,7 +370,7 @@ I certify that all documentation:
|
||||
- `docs/product-advisories/archived/2025-12-23-sprint-4200/23-Dec-2026 - Designing Replayable Verdict Interfaces.md` (if exists)
|
||||
|
||||
### Documentation Files
|
||||
- `docs/SPRINT_4200_INTEGRATION_GUIDE.md`
|
||||
- `docs/SPRINT_4200_0000_0000_integration_guide.md`
|
||||
- `docs/product-advisories/archived/2025-12-23-sprint-4200/SPRINT_4200_SIGN_OFF.md` (this document)
|
||||
|
||||
---
|
||||
|
||||
@@ -1,33 +0,0 @@
|
||||
I’m sharing this because the way *signed attestations* and *SBOM formats* are evolving is rapidly reshaping how supply‑chain security tooling like Trivy, in‑toto, CycloneDX, SPDX, and Cosign interoperate — and there’s a clear gap right now you can exploit strategically.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**Attested‑first scanning and in‑toto/DSSE as truth anchors**
|
||||
• The core idea is to *treat attestations themselves as the primary artifact to verify*. An in‑toto/DSSE attestation isn’t just an SBOM — it’s a *signed cryptographic statement* about the SBOM or other metadata (build provenance, test results, etc.), enabling trust decisions in CI/CD and runtime. ([SLSA][1])
|
||||
• Tools like *Cosign* generate and verify these in‑toto attestations — you can use `cosign verify‑attestation` to extract the SBOM payload from a DSSE envelope before scanning. ([Trivy][2])
|
||||
• CycloneDX’s attestation work (often referenced as **CDXA**) formalizes how attestations describe compliance claims and can *automate audit workflows*, making them machine‑readable and actionable. ([CycloneDX][3])
|
||||
|
||||
**Trivy’s dual‑format SBOM and attestation support — and the current parity gap**
|
||||
• *Trivy* already ingests *CycloneDX‑type SBOM attestations* (where the SBOM is wrapped in an in‑toto DSSE envelope). It uses Cosign‑produced attestations as inputs for its SBOM scanning pipeline. ([Trivy][4])
|
||||
• Trivy also scans traditional CycloneDX and SPDX SBOMs directly (and supports SPDX‑JSON). ([Trivy][5])
|
||||
• However, *formal parsing of SPDX in‑toto attestations is still tracked and not fully implemented* (evidence from feature discussions and issues). This means there’s a *window where CycloneDX attestation support is ahead of SPDX attestation support*, and tools that handle both smoothly will win in enterprise pipelines. ([GitHub][6])
|
||||
• That gap — *full SPDX attestation ingestion and verification* — remains a differentiation opportunity: build tooling or workflows that standardize acceptance and verification of both attested CycloneDX and attested SPDX SBOMs with strong replayable verdicts.
|
||||
|
||||
**Why this matters right now**
|
||||
Signed attestations (via DSSE/in‑toto and Cosign) turn an SBOM from a passive document into a *verified supply‑chain claim* that can gate deployments and signal compliance postures. Tools like Trivy that ingest these attestations are at the forefront of that shift, but not all formats are on equal footing yet — giving you space to innovate workflows or tooling that closes the parity window. ([Harness][7])
|
||||
|
||||
If you want follow‑up examples of commands or how to build CI/CD gates around these attestation flows, just let me know.
|
||||
|
||||
[1]: https://slsa.dev/blog/2023/05/in-toto-and-slsa?utm_source=chatgpt.com "in-toto and SLSA"
|
||||
[2]: https://trivy.dev/v0.40/docs/target/sbom/?utm_source=chatgpt.com "SBOM scanning"
|
||||
[3]: https://cyclonedx.org/capabilities/attestations/?utm_source=chatgpt.com "CycloneDX Attestations (CDXA)"
|
||||
[4]: https://trivy.dev/docs/latest/supply-chain/attestation/sbom/?utm_source=chatgpt.com "SBOM attestation"
|
||||
[5]: https://trivy.dev/docs/latest/target/sbom/?utm_source=chatgpt.com "SBOM scanning"
|
||||
[6]: https://github.com/aquasecurity/trivy/issues/9828?utm_source=chatgpt.com "feat(sbom): add support for SPDX attestations · Issue #9828"
|
||||
[7]: https://developer.harness.io/docs/security-testing-orchestration/sto-techref-category/trivy/aqua-trivy-scanner-reference?utm_source=chatgpt.com "Aqua Trivy step configuration"
|
||||
Reference in New Issue
Block a user