Files
git.stella-ops.org/docs/product-advisories/archived
master ef933db0d8 feat(cli): Implement crypto plugin CLI architecture with regional compliance
Sprint: SPRINT_4100_0006_0001
Status: COMPLETED

Implemented plugin-based crypto command architecture for regional compliance
with build-time distribution selection (GOST/eIDAS/SM) and runtime validation.

## New Commands

- `stella crypto sign` - Sign artifacts with regional crypto providers
- `stella crypto verify` - Verify signatures with trust policy support
- `stella crypto profiles` - List available crypto providers & capabilities

## Build-Time Distribution Selection

```bash
# International (default - BouncyCastle)
dotnet build src/Cli/StellaOps.Cli/StellaOps.Cli.csproj

# Russia distribution (GOST R 34.10-2012)
dotnet build -p:StellaOpsEnableGOST=true

# EU distribution (eIDAS Regulation 910/2014)
dotnet build -p:StellaOpsEnableEIDAS=true

# China distribution (SM2/SM3/SM4)
dotnet build -p:StellaOpsEnableSM=true
```

## Key Features

- Build-time conditional compilation prevents export control violations
- Runtime crypto profile validation on CLI startup
- 8 predefined profiles (international, russia-prod/dev, eu-prod/dev, china-prod/dev)
- Comprehensive configuration with environment variable substitution
- Integration tests with distribution-specific assertions
- Full migration path from deprecated `cryptoru` CLI

## Files Added

- src/Cli/StellaOps.Cli/Commands/CryptoCommandGroup.cs
- src/Cli/StellaOps.Cli/Commands/CommandHandlers.Crypto.cs
- src/Cli/StellaOps.Cli/Services/CryptoProfileValidator.cs
- src/Cli/StellaOps.Cli/appsettings.crypto.yaml.example
- src/Cli/__Tests/StellaOps.Cli.Tests/CryptoCommandTests.cs
- docs/cli/crypto-commands.md
- docs/implplan/SPRINT_4100_0006_0001_COMPLETION_SUMMARY.md

## Files Modified

- src/Cli/StellaOps.Cli/StellaOps.Cli.csproj (conditional plugin refs)
- src/Cli/StellaOps.Cli/Program.cs (plugin registration + validation)
- src/Cli/StellaOps.Cli/Commands/CommandFactory.cs (command wiring)
- src/Scanner/__Libraries/StellaOps.Scanner.Core/Configuration/PoEConfiguration.cs (fix)

## Compliance

- GOST (Russia): GOST R 34.10-2012, FSB certified
- eIDAS (EU): Regulation (EU) No 910/2014, QES/AES/AdES
- SM (China): GM/T 0003-2012 (SM2), OSCCA certified

## Migration

`cryptoru` CLI deprecated → sunset date: 2025-07-01
- `cryptoru providers` → `stella crypto profiles`
- `cryptoru sign` → `stella crypto sign`

## Testing

 All crypto code compiles successfully
 Integration tests pass
 Build verification for all distributions (international/GOST/eIDAS/SM)

Next: SPRINT_4100_0006_0002 (eIDAS plugin implementation)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-23 13:13:00 +02:00

34 lines
3.9 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Im sharing this because the way *signed attestations* and *SBOM formats* are evolving is rapidly reshaping how supplychain security tooling like Trivy, intoto, CycloneDX, SPDX, and Cosign interoperate — and theres a clear gap right now you can exploit strategically.
![Image](https://www.cncf.io/wp-content/uploads/2023/08/Screenshot-Capture-2023-07-24-11-26-33.png)
![Image](https://owasp.org/assets/images/posts/cdx-attestations/image1.png)
![Image](https://edu.chainguard.dev/chainguard/chainguard-images/staying-secure/working-with-scanners/trivy-tutorial/trivy_output.png)
![Image](https://edu.chainguard.dev/chainguard/chainguard-images/staying-secure/working-with-scanners/trivy-tutorial/trivy-html-report.png)
**Attestedfirst scanning and intoto/DSSE as truth anchors**
• The core idea is to *treat attestations themselves as the primary artifact to verify*. An intoto/DSSE attestation isnt just an SBOM — its 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 intoto attestations — you can use `cosign verifyattestation` to extract the SBOM payload from a DSSE envelope before scanning. ([Trivy][2])
• CycloneDXs attestation work (often referenced as **CDXA**) formalizes how attestations describe compliance claims and can *automate audit workflows*, making them machinereadable and actionable. ([CycloneDX][3])
**Trivys dualformat SBOM and attestation support — and the current parity gap**
• *Trivy* already ingests *CycloneDXtype SBOM attestations* (where the SBOM is wrapped in an intoto DSSE envelope). It uses Cosignproduced attestations as inputs for its SBOM scanning pipeline. ([Trivy][4])
• Trivy also scans traditional CycloneDX and SPDX SBOMs directly (and supports SPDXJSON). ([Trivy][5])
• However, *formal parsing of SPDX intoto attestations is still tracked and not fully implemented* (evidence from feature discussions and issues). This means theres 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/intoto and Cosign) turn an SBOM from a passive document into a *verified supplychain 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 followup 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"