feat: Implement vulnerability token signing and verification utilities
Some checks failed
Docs CI / lint-and-preview (push) Has been cancelled
Some checks failed
Docs CI / lint-and-preview (push) Has been cancelled
- Added VulnTokenSigner for signing JWT tokens with specified algorithms and keys. - Introduced VulnTokenUtilities for resolving tenant and subject claims, and sanitizing context dictionaries. - Created VulnTokenVerificationUtilities for parsing tokens, verifying signatures, and deserializing payloads. - Developed VulnWorkflowAntiForgeryTokenIssuer for issuing anti-forgery tokens with configurable options. - Implemented VulnWorkflowAntiForgeryTokenVerifier for verifying anti-forgery tokens and validating payloads. - Added AuthorityVulnerabilityExplorerOptions to manage configuration for vulnerability explorer features. - Included tests for FilesystemPackRunDispatcher to ensure proper job handling under egress policy restrictions.
This commit is contained in:
master
18
docs/api/scanner/README.md
Normal file
18
docs/api/scanner/README.md
Normal file
@@ -0,0 +1,18 @@
|
||||
# Scanner API Docs — Windows/macOS Coverage (Draft)
|
||||
|
||||
This directory collects interim artefacts tracking customer demand and roadmap readiness for extending Scanner coverage to Windows and macOS.
|
||||
|
||||
## Files
|
||||
- `windows-coverage.md` — narrative summary of customer signals and required artefacts.
|
||||
- `windows-macos-summary.md` — dashboard-style snapshot (counts, cross-references) updated after each discovery cycle.
|
||||
|
||||
## Related resources
|
||||
- `../../modules/scanner/design/README.md`
|
||||
- `../../benchmarks/scanner/windows-macos-demand.md`
|
||||
- `../../benchmarks/scanner/windows-macos-interview-template.md`
|
||||
- `../../modules/scanner/design/macos-analyzer.md`
|
||||
- `../../modules/scanner/design/windows-analyzer.md`
|
||||
- `../../modules/policy/windows-package-readiness.md`
|
||||
- `../../modules/policy/secret-leak-detection-readiness.md`
|
||||
|
||||
> Note: replace these working notes with formal API documentation once Windows/macOS analyzer endpoints are defined.
|
||||
50
docs/api/scanner/windows-coverage.md
Normal file
50
docs/api/scanner/windows-coverage.md
Normal file
@@ -0,0 +1,50 @@
|
||||
# Scanner API — Windows/macOS Coverage Signals (Draft)
|
||||
|
||||
> Audience: Solutions engineers, product managers, guild leads coordinating Windows/macOS roadmap
|
||||
> Status: Informational; update as interviews conclude
|
||||
|
||||
## Summary
|
||||
| Region | Accounts referenced | Primary workloads | Demand strength (1-5) | Blocking? | Notes |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| North America | Northwind Health Services; FinSecure Corp | macOS CI runners; Windows Server 2019 workloads | 4-5 | macOS: evaluation; Windows: blocking | Demo 2025-11-10; Security decision due 2025-11-07. |
|
||||
| EMEA | — | — | — | — | — |
|
||||
| APAC | — | — | — | — | — |
|
||||
| Gov / Regulated | — | — | — | — | — |
|
||||
|
||||
### Key drivers
|
||||
- Customers with regulated Windows Server/desktop estates lack deterministic SBOM coverage and provenance.
|
||||
- macOS development shops (Mobile, Gaming) require entitlements/notarization evidence for compliance.
|
||||
- Offline/air-gapped environments need signed rule bundles and feed mirrors for Windows/macOS ecosystems.
|
||||
|
||||
### Competitive landscape
|
||||
- Trivy/Grype/Snyk remain Linux-focused; Windows/macOS features are roadmap items or SaaS-only.
|
||||
- Opportunity to differentiate via deterministic evidence, policy integration, and offline parity.
|
||||
|
||||
### Design references
|
||||
- `../../modules/scanner/design/macos-analyzer.md`
|
||||
- `../../modules/scanner/design/windows-analyzer.md`
|
||||
|
||||
### Action items
|
||||
- Maintain region rows using interview summaries from `docs/benchmarks/scanner/windows-macos-demand.md` (last update 2025-11-03; capture via the interview template).
|
||||
- Track readiness decisions by updating POLICY-READINESS-0001/0002 status and recording outcomes in the summary table.
|
||||
- Align backlog references (`SCANNER-ENG-0020..0027`, `DOCS-SCANNER-BENCH-62-016`) with product prioritisation after each roadmap review.
|
||||
|
||||
### Open blockers
|
||||
- FinSecure PCI audit pending POLICY-READINESS-0002 decision (due 2025-11-07); unblock Windows analyzer spike scheduling.
|
||||
- Northwind macOS readiness workshop scheduled 2025-11-10; capture masking/telemetry decisions for POLICY-READINESS-0001.
|
||||
|
||||
## Interview log (selected)
|
||||
| Date | Customer | Platform focus | Signal summary | Strength (1-5) | Follow-up |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 2025-11-03 | Northwind Health Services | macOS | Needs notarization/entitlement visibility for CI runners | 4 | Demo 2025-11-10 with Product; feed findings into POLICY-READINESS-0001. |
|
||||
| 2025-11-03 | FinSecure Corp | Windows | Requires MSI/WinSxS SBOM + signed driver attestations for PCI audit | 5 | Security guild to resolve Authenticode posture (POLICY-READINESS-0002) by 2025-11-07. |
|
||||
|
||||
## Required artefacts
|
||||
- Maintain interview notes using `docs/benchmarks/scanner/windows-macos-interview-template.md`.
|
||||
- Update demand tracker tables in `docs/benchmarks/scanner/windows-macos-demand.md`.
|
||||
- Sync backlog entries in `docs/modules/scanner/TASKS.md` and `docs/scanner/design/*.md`.
|
||||
|
||||
## Next steps
|
||||
1. Collect at least three qualified Windows and macOS requests; update summary table.
|
||||
2. Present findings to Scanner Guild for prioritisation (target Sprint 133 design spike).
|
||||
3. Coordinate policy readiness briefs (`docs/modules/policy/windows-package-readiness.md`) and design docs (`design/macos-analyzer.md`, `design/windows-analyzer.md`).
|
||||
37
docs/api/scanner/windows-macos-summary.md
Normal file
37
docs/api/scanner/windows-macos-summary.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# Scanner API — Windows/macOS Coverage Dashboard (Draft)
|
||||
|
||||
> Owners: Product Guild, Scanner Guild • Status: living document updated every sprint
|
||||
|
||||
## At-a-glance metrics (Sprint 132 intake)
|
||||
- macOS demand entries logged: 1 (Northwind Health Services, 2025-11-03)
|
||||
- Windows demand entries logged: 1 (FinSecure Corp, 2025-11-03)
|
||||
- Qualified customers awaiting roadmap response: 1 (FinSecure PCI blocker)
|
||||
- Open policy readiness items: POLICY-READINESS-0001, POLICY-READINESS-0002
|
||||
|
||||
## Cross-reference
|
||||
| Resource | Purpose |
|
||||
| --- | --- |
|
||||
| docs/benchmarks/scanner/windows-macos-demand.md | Signal log & next actions |
|
||||
| docs/benchmarks/scanner/windows-macos-interview-template.md | Interview capture template |
|
||||
| docs/benchmarks/scanner/deep-dives/macos.md | macOS implementation roadmap |
|
||||
| docs/benchmarks/scanner/deep-dives/windows.md | Windows implementation roadmap |
|
||||
| docs/modules/scanner/design/macos-analyzer.md | Detailed macOS design |
|
||||
| docs/modules/scanner/design/windows-analyzer.md | Detailed Windows design |
|
||||
| docs/modules/policy/windows-package-readiness.md | Policy readiness for Windows packages |
|
||||
| docs/modules/policy/secret-leak-detection-readiness.md | Policy readiness for secrets |
|
||||
| docs/modules/scanner/TASKS.md | Engineering backlog (SCANNER-ENG-0020..0027) |
|
||||
| docs/modules/policy/TASKS.md | Policy readiness tasks |
|
||||
| docs/api/scanner/windows-coverage.md | Narrative summary |
|
||||
|
||||
## Maintenance cadence
|
||||
- Update metrics and cross-links after each customer signal or roadmap checkpoint.
|
||||
- Ensure DOCS-SCANNER-BENCH-62-002/016 status mirrors demand tracker progress.
|
||||
|
||||
## Upcoming milestones
|
||||
- 2025-11-07: POLICY-READINESS-0002 Authenticode/feed decision for FinSecure (unblocks Windows analyzer spike).
|
||||
- 2025-11-10: POLICY-READINESS-0001 workshop during Northwind demo to finalise masking/telemetry posture.
|
||||
|
||||
## Recent updates
|
||||
- 2025-11-03: Logged Northwind Health Services (macOS) & FinSecure Corp (Windows); awaiting POLICY-READINESS-0001/0002 decisions before scheduling analyzer spikes.
|
||||
|
||||
Last updated: 2025-11-03 (initial demand entries logged).
|
||||
@@ -1,51 +1,51 @@
|
||||
# SDK & OpenAPI Program
|
||||
|
||||
> Work of this type or tasks of this type on this component must also be applied everywhere else it should be applied.
|
||||
|
||||
## Overview
|
||||
|
||||
The SDK & OpenAPI program delivers canonical OpenAPI 3.1 contracts for every Stella Ops surface, plus officially supported SDKs (TypeScript/Node, Python, Go, Java, C#). It ensures backwards-compatible evolution, documentation, and offline availability.
|
||||
|
||||
- **Primary components:** API Gateway, Web Services, Policy Engine, Conseiller, Excitator, Orchestrator, Findings Ledger, Export Center, Authority & Tenancy, Console, CLI.
|
||||
- **Surfaces:** OpenAPI specs, language SDKs, developer portal, examples, mock server, conformance tests, changelog feeds, deprecation notices.
|
||||
- **Dependencies:** Authority scopes/tenancy, CLI parity, Export Center, Notifications, Air-Gapped Mode, Observability.
|
||||
|
||||
## Program pillars
|
||||
|
||||
1. **Contract-first:** treat OpenAPI specs as the source of truth. CI validates schemas, compatibility, and documentation generation.
|
||||
2. **SDK parity:** language SDKs cover the same surfaces with deterministic clients, pagination helpers, and typed models mirroring Aggregation-Only Contract semantics.
|
||||
3. **Version discipline:** semantic versioning for specs and SDKs, release notes, deprecation windows, and automated change alerts via Notifications.
|
||||
4. **Offline readiness:** specs and SDK bundles ship in Mirror Bundles for air-gapped environments; examples include smoke tests.
|
||||
5. **Observability:** telemetry around SDK usage, spec download metrics, and error reporting funnels back into product decisions.
|
||||
|
||||
## Deliverables
|
||||
|
||||
| Workstream | Deliverable |
|
||||
| --- | --- |
|
||||
| Spec authoring | Unified OpenAPI 3.1 documents per service plus aggregate spec; lint rules; schema registries. |
|
||||
| SDK generation | Language-specific clients with idiomatic ergonomics, retries, pagination, long-running operation helpers, unit + integration tests. |
|
||||
| Dev portal | Consolidated documentation, guides, changelog, copy/paste examples, quickstart scripts. |
|
||||
| Testing | Contract tests against staging, mock server for integration tests, compatibility verification per release. |
|
||||
| Release ops | Automated CI pipelines, version bump workflows, release notes, deprecation policies. |
|
||||
|
||||
## Guardrails
|
||||
|
||||
- **Aggregation-Only Contract compliance:** SDKs expose raw advisory/VEX objects without hidden merges; all derived fields require explicit Policy Engine calls.
|
||||
- **Security:** enforce scopes via SDK configuration; redact secrets; support DPoP/mTLS and offline token provisioning.
|
||||
- **Compatibility:** maintain backwards-compatible paths for at least two minor releases; log warnings on deprecated endpoints.
|
||||
- **Documentation:** publish examples for common workflows (scan, policy evaluate, export, attestation) with language parity.
|
||||
|
||||
## Roadmap checkpoints
|
||||
|
||||
1. Baseline OpenAPI specs extracted from gateway, validated, and published.
|
||||
2. TypeScript/Node SDK as pilot, followed by Python and Go.
|
||||
3. Developer portal launch with SDK docs, quickstarts, and mock server.
|
||||
4. Offline kit integration (mirror bundles include specs + SDK tarballs).
|
||||
5. Runtime alerting for breaking changes and dependency vulnerabilities.
|
||||
|
||||
## References
|
||||
|
||||
- API gateway integration: `docs/modules/platform/architecture-overview.md`
|
||||
- Policy/Findings models: `docs/modules/policy/architecture.md`, `docs/modules/vuln-explorer/architecture.md`
|
||||
- Export bundle distribution: `docs/modules/export-center/overview.md`
|
||||
- Offline workflows: `docs/airgap/airgap-mode.md`
|
||||
# SDK & OpenAPI Program
|
||||
|
||||
> Work of this type or tasks of this type on this component must also be applied everywhere else it should be applied.
|
||||
|
||||
## Overview
|
||||
|
||||
The SDK & OpenAPI program delivers canonical OpenAPI 3.1 contracts for every Stella Ops surface, plus officially supported SDKs (TypeScript/Node, Python, Go, Java, C#). It ensures backwards-compatible evolution, documentation, and offline availability.
|
||||
|
||||
- **Primary components:** API Gateway, Web Services, Policy Engine, Conseiller, Excitor, Orchestrator, Findings Ledger, Export Center, Authority & Tenancy, Console, CLI.
|
||||
- **Surfaces:** OpenAPI specs, language SDKs, developer portal, examples, mock server, conformance tests, changelog feeds, deprecation notices.
|
||||
- **Dependencies:** Authority scopes/tenancy, CLI parity, Export Center, Notifications, Air-Gapped Mode, Observability.
|
||||
|
||||
## Program pillars
|
||||
|
||||
1. **Contract-first:** treat OpenAPI specs as the source of truth. CI validates schemas, compatibility, and documentation generation.
|
||||
2. **SDK parity:** language SDKs cover the same surfaces with deterministic clients, pagination helpers, and typed models mirroring Aggregation-Only Contract semantics.
|
||||
3. **Version discipline:** semantic versioning for specs and SDKs, release notes, deprecation windows, and automated change alerts via Notifications.
|
||||
4. **Offline readiness:** specs and SDK bundles ship in Mirror Bundles for air-gapped environments; examples include smoke tests.
|
||||
5. **Observability:** telemetry around SDK usage, spec download metrics, and error reporting funnels back into product decisions.
|
||||
|
||||
## Deliverables
|
||||
|
||||
| Workstream | Deliverable |
|
||||
| --- | --- |
|
||||
| Spec authoring | Unified OpenAPI 3.1 documents per service plus aggregate spec; lint rules; schema registries. |
|
||||
| SDK generation | Language-specific clients with idiomatic ergonomics, retries, pagination, long-running operation helpers, unit + integration tests. |
|
||||
| Dev portal | Consolidated documentation, guides, changelog, copy/paste examples, quickstart scripts. |
|
||||
| Testing | Contract tests against staging, mock server for integration tests, compatibility verification per release. |
|
||||
| Release ops | Automated CI pipelines, version bump workflows, release notes, deprecation policies. |
|
||||
|
||||
## Guardrails
|
||||
|
||||
- **Aggregation-Only Contract compliance:** SDKs expose raw advisory/VEX objects without hidden merges; all derived fields require explicit Policy Engine calls.
|
||||
- **Security:** enforce scopes via SDK configuration; redact secrets; support DPoP/mTLS and offline token provisioning.
|
||||
- **Compatibility:** maintain backwards-compatible paths for at least two minor releases; log warnings on deprecated endpoints.
|
||||
- **Documentation:** publish examples for common workflows (scan, policy evaluate, export, attestation) with language parity.
|
||||
|
||||
## Roadmap checkpoints
|
||||
|
||||
1. Baseline OpenAPI specs extracted from gateway, validated, and published.
|
||||
2. TypeScript/Node SDK as pilot, followed by Python and Go.
|
||||
3. Developer portal launch with SDK docs, quickstarts, and mock server.
|
||||
4. Offline kit integration (mirror bundles include specs + SDK tarballs).
|
||||
5. Runtime alerting for breaking changes and dependency vulnerabilities.
|
||||
|
||||
## References
|
||||
|
||||
- API gateway integration: `docs/modules/platform/architecture-overview.md`
|
||||
- Policy/Findings models: `docs/modules/policy/architecture.md`, `docs/modules/vuln-explorer/architecture.md`
|
||||
- Export bundle distribution: `docs/modules/export-center/overview.md`
|
||||
- Offline workflows: `docs/airgap/airgap-mode.md`
|
||||
|
||||
Reference in New Issue
Block a user