license switch agpl -> busl1, sprints work, new product advisories

This commit is contained in:
master
2026-01-20 15:32:20 +02:00
parent 4903395618
commit c32fff8f86
1835 changed files with 38630 additions and 4359 deletions

View File

@@ -10,9 +10,12 @@ StellaOps SBOM interoperability tests ensure compatibility with third-party secu
| Format | Version | Status | Parity Target |
|--------|---------|--------|---------------|
| CycloneDX | 1.6 | ✅ Supported | 95%+ |
| CycloneDX | 1.7 | ✅ Supported | 95%+ |
| SPDX | 3.0.1 | ✅ Supported | 95%+ |
Notes:
- SPDX 3.0.1 generation currently emits JSON-LD `@context`, `spdxVersion`, core document/package/relationship elements, software package/file/snippet metadata, build profile elements with output relationships, security vulnerabilities with assessment relationships, verifiedUsing hashes/signatures, and external references/identifiers. Full profile coverage is tracked in SPRINT_20260119_014.
### Third-Party Tools
| Tool | Purpose | Version | Status |
@@ -162,7 +165,7 @@ If SBOMs fail schema validation:
1. Verify format version:
```bash
jq '.specVersion' sbom-cyclonedx.json # Should be "1.6"
jq '.specVersion' sbom-cyclonedx.json # Should be "1.7"
jq '.spdxVersion' sbom-spdx.json # Should be "SPDX-3.0"
```
@@ -203,7 +206,7 @@ Tools are currently installed from `latest`. To pin versions:
## References
- [CycloneDX 1.6 Specification](https://cyclonedx.org/docs/1.6/)
- [CycloneDX 1.7 Specification](https://cyclonedx.org/docs/1.7/)
- [SPDX 3.0.1 Specification](https://spdx.github.io/spdx-spec/v3.0/)
- [Syft Documentation](https://github.com/anchore/syft)
- [Grype Documentation](https://github.com/anchore/grype)

View File

@@ -607,7 +607,7 @@ stella attest verify-batch \
- [Sigstore Trust Root Specification](https://github.com/sigstore/root-signing)
- [in-toto Attestation Specification](https://github.com/in-toto/attestation)
- [SPDX 3.0.1 Specification](https://spdx.github.io/spdx-spec/v3.0.1/)
- [CycloneDX 1.6 Specification](https://cyclonedx.org/docs/1.6/)
- [CycloneDX 1.7 Specification](https://cyclonedx.org/docs/1.7/)
### StellaOps Documentation
- [Attestor Architecture](../modules/attestor/architecture.md)

View File

@@ -0,0 +1,48 @@
# Attestor Offline Verification Guide
> **Audience:** Attestor operators, AirGap owners, CI/Release engineers
>
> **Purpose:** Explain how to verify attestations and timestamp evidence in fully offline environments.
## 1. Offline Inputs
Offline verification expects all evidence to be bundled locally:
- DSSE envelopes + certificate chains.
- Rekor inclusion proofs + a pinned checkpoint.
- RFC3161 timestamp evidence with bundled TSA chain and revocation data:
- `tsa/chain/` (PEM certificates, leaf -> root)
- `tsa/ocsp/` (stapled OCSP responses)
- `tsa/crl/` (CRL snapshots when OCSP is unavailable)
## 2. Bundle Layout Expectations
Minimum paths for timestamp verification:
- `manifest.json` with `timestamps[]` entries.
- `tsa/chain/*.pem` for each RFC3161 timestamp.
- `tsa/ocsp/*.der` or `tsa/crl/*.crl` (revocation evidence).
## 3. CLI Workflow (Offline)
Use the bundle verification flow aligned to domain operations:
```bash
stella bundle verify --bundle /path/to/bundle --offline --trust-root /path/to/tsa-root.pem --rekor-checkpoint /path/to/checkpoint.json
```
Notes:
- Offline mode fails closed when revocation evidence is missing or invalid.
- Trust roots must be provided locally; no network fetches are allowed.
## 4. Verification Behavior
- TSA chain is validated against the provided trust roots.
- Revocation evidence is verified using bundled OCSP/CRL data.
- Rekor proofs are verified against the pinned checkpoint when provided.
## 5. References
- `docs/modules/attestor/guides/timestamp-policy.md`
- `docs/modules/attestor/airgap.md`
- `docs/modules/airgap/guides/staleness-and-time.md`

View File

@@ -0,0 +1,50 @@
# RFC-3161 Timestamp Policy Assertions
## Overview
Attestation timestamp policy rules validate RFC-3161 evidence alongside Rekor
inclusion proofs. The policy surface is backed by `AttestationTimestampPolicyContext`
and `TimestampPolicyEvaluator` in `StellaOps.Attestor.Timestamping`.
## Context fields
`AttestationTimestampPolicyContext` exposes the following fields:
| Field | Type | Description |
| --- | --- | --- |
| `HasValidTst` | bool | True when RFC-3161 verification succeeded. |
| `TstTime` | DateTimeOffset? | Generation time from the timestamp token. |
| `TsaName` | string? | TSA subject/name from the TST. |
| `TsaPolicyOid` | string? | TSA policy OID from the TST. |
| `TsaCertificateValid` | bool | True when TSA certificate validation passes. |
| `TsaCertificateExpires` | DateTimeOffset? | TSA signing cert expiry time. |
| `OcspStatus` | string? | OCSP status (Good/Unknown/Revoked). |
| `CrlChecked` | bool | True when CRL data was checked. |
| `RekorTime` | DateTimeOffset? | Rekor integrated time for the entry. |
| `TimeSkew` | TimeSpan? | RekorTime - TstTime, used for skew checks. |
## Example assertions
The policy engine maps the context into `evidence.tst.*` fields. Example rules:
```yaml
rules:
- id: require-rfc3161
assert: evidence.tst.valid == true
- id: time-skew
assert: abs(evidence.tst.time_skew) <= "5m"
- id: freshness
assert: evidence.tst.signing_cert.expires_at - now() > "180d"
- id: revocation-staple
assert: evidence.tst.ocsp.status in ["good","unknown"] && evidence.tst.crl.checked == true
- id: trusted-tsa
assert: evidence.tst.tsa_name in ["Example TSA", "Acme TSA"]
```
## Built-in policy defaults
`TimestampPolicy.Default` enforces:
- `RequireRfc3161 = true`
- `MaxTimeSkew = 5 minutes`
- `MinCertificateFreshness = 180 days`
- `RequireRevocationStapling = true`
## References
- `src/Attestor/__Libraries/StellaOps.Attestor.Timestamping/AttestationTimestampPolicyContext.cs`
- `docs/modules/attestor/architecture.md`