stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 2 Releases Wiki Activity

docs: Archive completed Sprint 3200, 4100.0006 and product advisories

Browse Source 
Archive completed sprint documentation:

## SPRINT_3200 - Standard Predicate Types (COMPLETE ✅)
- StandardPredicates library: SPDX, CycloneDX, SLSA parsers
- PredicateTypeRouter integration into Attestor
- 25/25 unit tests passing (100% success)
- Cosign integration guide (16,000+ words)
- Archived to: docs/implplan/archived/2025-12-23-sprint-3200/

## SPRINT_4100_0006 - Crypto Plugin CLI Architecture (COMPLETE ✅)
- Build-time conditional compilation (GOST/eIDAS/SM)
- Runtime crypto profile validation
- stella crypto sign/verify/profiles commands
- Comprehensive configuration system
- Integration tests with distribution assertions
- Archived to: docs/implplan/archived/2025-12-23-sprint-4100-0006/

## Product Advisories (ACTIONED ✅)
- "Better testing strategy" - Informed testing framework improvements
- "Distinctive Edge for Docker Scanning" - Informed attestation work
- Archived to: docs/product-advisories/archived/2025-12-23-testing-attestation-strategy/

All archived sprints achieved 100% completion of planned deliverables.

🤖 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
2025-12-23 14:59:42 +02:00
parent fcb5ffe25d
commit fda92af9bc
14 changed files with 0 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1119
docs/product-advisories/archived/2025-12-23-testing-attestation-strategy/22-Dec-2026 - Better testing strategy.md Normal file
View File

File diff suppressed because it is too large Load Diff

33
docs/product-advisories/archived/2025-12-23-testing-attestation-strategy/23-Dec-2026 - Distinctive Edge for Docker Scanning.md Normal file
View File

@@ -0,0 +1,33 @@
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.
![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)
**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"