Frontend gaps fill work. Testing fixes work. Auditing in progress.

This commit is contained in:
StellaOps Bot
2025-12-30 01:22:58 +02:00
parent 1dc4bcbf10
commit 7a5210e2aa
928 changed files with 183942 additions and 3941 deletions

View File

@@ -105,6 +105,53 @@ Operational rules:
- Logs: structured, include tenant + artifact digest + sbomVersion; classify ingest failures (schema, storage, orchestrator, validation).
- Alerts: backlog thresholds for outbox/event delivery; high latency on path/timeline endpoints.
## 8.1) Registry Source Management (Sprint 012)
The service manages container registry sources for automated image discovery and scanning:
### Models
- `RegistrySource` — registry connection with URL, filters, schedule, credentials (via AuthRef).
- `RegistrySourceRun` — run history with status, discovered images, triggered scans, error details.
- `RegistrySourceStatus``Draft`, `Active`, `Paused`, `Error`, `Deleted`.
- `RegistrySourceProvider``Generic`, `Harbor`, `DockerHub`, `ACR`, `ECR`, `GCR`, `GHCR`.
### APIs
- `GET/POST/PUT/DELETE /api/v1/registry-sources` — CRUD operations.
- `POST /api/v1/registry-sources/{id}/test` — test registry connection and credentials.
- `POST /api/v1/registry-sources/{id}/trigger` — manually trigger discovery and scanning.
- `POST /api/v1/registry-sources/{id}/pause` / `/resume` — pause/resume scheduled scans.
- `GET /api/v1/registry-sources/{id}/runs` — run history with health metrics.
- `GET /api/v1/registry-sources/{id}/discover/repositories` — discover repositories matching filters.
- `GET /api/v1/registry-sources/{id}/discover/tags/{repository}` — discover tags for a repository.
- `GET /api/v1/registry-sources/{id}/discover/images` — full image discovery.
- `POST /api/v1/registry-sources/{id}/discover-and-scan` — discover and submit scan jobs.
### Webhook Ingestion
- `POST /api/v1/webhooks/registry/{sourceId}` — receive push notifications from registries.
- Supported providers: Harbor, DockerHub, ACR, ECR, GCR, GHCR.
- HMAC-SHA256 signature validation using webhook secret from AuthRef.
- Auto-detection of provider from request headers.
### Discovery Service
- OCI Distribution Spec compliant repository/tag enumeration.
- Pagination via RFC 5988 Link headers.
- Allowlist/denylist filtering for repositories and tags (glob patterns).
- Manifest digest retrieval via HEAD requests.
### Scan Job Emission
- Batch submission to Scanner service with rate limiting.
- Deduplication (skips if job already exists).
- Metadata includes source ID, trigger type, client request ID.
### Configuration
- `SbomService:ScannerUrl` — Scanner service endpoint (default: `http://localhost:5100`).
- `SbomService:BatchScanSize` — max images per batch (default: 10).
- `SbomService:BatchScanDelayMs` — delay between batch submissions (default: 100ms).
### Credentials
- All credentials via AuthRef URIs: `authref://{vault}/{path}#{key}`.
- Supports basic auth (`basic:user:pass`) and bearer tokens (`bearer:token`) for development.
## 9) Configuration (PostgreSQL-backed catalog & lookup)
- Enable PostgreSQL storage for `/console/sboms` and `/components/lookup` by setting `SbomService:PostgreSQL:ConnectionString` (env: `SBOM_SbomService__PostgreSQL__ConnectionString`).
- Optional overrides: `SbomService:PostgreSQL:Schema`, `SbomService:PostgreSQL:CatalogTable`, `SbomService:PostgreSQL:ComponentLookupTable`; defaults are `sbom_service`, `sbom_catalog`, `sbom_component_neighbors`.

View File

@@ -0,0 +1,307 @@
# Lineage Smart-Diff UI Architecture
> Sprint: SPRINT_20251229_001_FE_lineage_smartdiff_overview
> Last Updated: 2025-12-29
## 1. Overview
The Lineage Smart-Diff feature provides a comprehensive UI for visualizing SBOM lineage graphs, comparing artifact versions, and explaining security state changes between builds.
### 1.1 Completion Status
| Area | Completion | Notes |
|------|------------|-------|
| **Lineage Graph SVG** | 95% | Full DAG visualization with lanes, pan/zoom, nodes |
| **Hover Cards** | 85% | Basic info displayed; needs CGS integration |
| **SBOM Diff View** | 90% | 3-column diff exists; needs row expanders |
| **VEX Diff View** | 90% | Status change display; needs reachability gates |
| **Compare Mode** | 85% | Three-pane layout exists; needs explainer timeline |
| **Export Dialog** | 80% | Basic export; needs audit pack format |
| **Proof Tree** | 75% | Merkle tree viz; needs confidence breakdown |
| **Reachability Diff** | 60% | Basic view; needs gate visualization |
## 2. UI Data Contracts
### 2.1 CGS/Lineage API Integration
```typescript
// Lineage Graph Response
interface LineageGraph {
artifact: string;
nodes: LineageNode[];
edges: LineageEdge[];
metadata: {
totalNodes: number;
maxDepth: number;
generatedAt: string;
};
}
interface LineageNode {
id: string;
artifactDigest: string;
artifactRef: string;
sequenceNumber: number;
createdAt: string;
source: string;
parentDigests: string[];
badges: {
newVulns: number;
resolvedVulns: number;
signatureStatus: 'valid' | 'invalid' | 'unknown';
reachabilityStatus: 'analyzed' | 'pending' | 'unavailable';
};
replayHash: string;
cgsHash?: string;
}
interface LineageEdge {
fromDigest: string;
toDigest: string;
relationship: 'parent' | 'build' | 'base' | 'derived';
}
```
### 2.2 Diff Response Schema
```typescript
interface LineageDiffResponse {
fromDigest: string;
toDigest: string;
sbomDiff: {
added: ComponentDiff[];
removed: ComponentDiff[];
versionChanged: VersionChange[];
licenseChanged: LicenseChange[];
};
vexDiff: VexDelta[];
reachabilityDiff: ReachabilityDelta[];
replayHash: string;
generatedAt: string;
}
interface ComponentDiff {
purl: string;
name: string;
version: string;
ecosystem: string;
license?: string;
scope: 'runtime' | 'development' | 'optional';
}
interface VersionChange {
purl: string;
name: string;
fromVersion: string;
toVersion: string;
changeType: 'upgrade' | 'downgrade' | 'patch';
}
interface VexDelta {
cveId: string;
purl: string;
fromStatus: VexStatus;
toStatus: VexStatus;
justification?: string;
effectiveAt: string;
}
interface ReachabilityDelta {
cveId: string;
purl: string;
fromReachable: boolean;
toReachable: boolean;
paths?: string[][];
}
```
## 3. Explainer Timeline Requirements
### 3.1 Engine Steps
The explainer timeline shows the sequence of analysis steps:
| Step | Description | Visual Cue |
|------|-------------|------------|
| SBOM Parse | Initial SBOM ingestion | Document icon |
| Component Match | CVE-to-component matching | Link icon |
| VEX Lookup | VEX document resolution | Shield icon |
| Reachability | Call graph analysis | Graph icon |
| Policy Gate | Policy rule evaluation | Gate icon |
| Verdict | Final determination | Checkmark/X |
### 3.2 Data Binding
```typescript
interface ExplainerStep {
stepId: string;
stepType: 'sbom_parse' | 'component_match' | 'vex_lookup' |
'reachability' | 'policy_gate' | 'verdict';
timestamp: string;
duration: number;
status: 'success' | 'warning' | 'error';
inputs: Record<string, unknown>;
outputs: Record<string, unknown>;
evidence?: {
type: string;
hash: string;
downloadUrl?: string;
};
}
```
## 4. Node Diff Table UX
### 4.1 Expander Pattern
Each diff row can expand to show:
- Full component details (license, scope, dependencies)
- CVE associations and status
- Reachability paths (if analyzed)
- VEX statements affecting the component
### 4.2 Visual Design
```
┌─────────────────────────────────────────────────────────────┐
│ Component │ Before │ After │ Status│
├─────────────────────────────────────────────────────────────┤
│ ▶ lodash │ 4.17.20 │ 4.17.21 │ ↑ │
│ └─ CVE-2021-23337 (fixed in 4.17.21) │
│ └─ License: MIT │
├─────────────────────────────────────────────────────────────┤
│ ▶ axios │ 0.21.1 │ 0.21.4 │ ↑ │
├─────────────────────────────────────────────────────────────┤
│ ▶ express │ - │ 4.18.2 │ + NEW │
└─────────────────────────────────────────────────────────────┘
```
## 5. Reachability Gate Diff UI
### 5.1 Visual Cues
| Gate Status | Icon | Color |
|-------------|------|-------|
| Reachable | ● | Red |
| Not Reachable | ○ | Green |
| Unknown | ? | Gray |
| Changed | ↔ | Orange |
### 5.2 Path Display
When reachability changes, show the call path:
```
entrypoint.ts → handler.ts → vulnerable_fn.ts → lodash.get()
```
## 6. Audit Pack Export UI
### 6.1 Export Options
| Option | Description | Default |
|--------|-------------|---------|
| Include SBOMs | Both before/after SBOMs | ✓ |
| Include Diff | Component/VEX/reachability diff | ✓ |
| Include Attestations | DSSE envelopes | ✓ |
| Include Evidence | Supporting evidence files | ✗ |
| Sign Bundle | Sign with tenant key | ✓ |
### 6.2 Manifest Schema
```json
{
"version": "1.0",
"generatedAt": "2025-12-29T10:00:00Z",
"artifactA": { "digest": "sha256:...", "name": "...", "createdAt": "..." },
"artifactB": { "digest": "sha256:...", "name": "...", "createdAt": "..." },
"contents": [
{ "type": "sbom", "filename": "before.cdx.json", "sha256": "..." },
{ "type": "sbom", "filename": "after.cdx.json", "sha256": "..." },
{ "type": "diff", "filename": "diff.json", "sha256": "..." },
{ "type": "attestation", "filename": "attestations.dsse.json", "sha256": "..." }
],
"merkleRoot": "sha256:...",
"summary": {
"componentsAdded": 5,
"componentsRemoved": 2,
"vexUpdates": 3,
"attestationCount": 2
}
}
```
## 7. Copy-Safe Workflow
### 7.1 Pinned Explanation UX
Operators can "pin" explanations for ticket export:
1. Click pin icon on any verdict/finding
2. Explanation captures current state with hash
3. Export as Markdown/JSON for JIRA/ServiceNow
### 7.2 Ticket Export Format
```markdown
## Security Finding Report
**Artifact**: myorg/myapp:v1.2.3 (sha256:abc123...)
**Generated**: 2025-12-29T10:00:00Z
**Replay Hash**: sha256:def456...
### Finding: CVE-2021-23337 in lodash
| Field | Value |
|-------|-------|
| Status | Not Affected |
| Reason | Not Reachable |
| Evidence | Call graph analysis |
| VEX ID | VEX-2025-001 |
### Verification
To reproduce this verdict:
```
stella verdict replay --hash sha256:def456...
```
```
## 8. Confidence Breakdown Charts
### 8.1 Metrics Sources
| Metric | Source | Weight |
|--------|--------|--------|
| SBOM Completeness | Scanner analysis | 30% |
| VEX Coverage | VEX Hub aggregation | 25% |
| Reachability Depth | Call graph analysis | 25% |
| Attestation Count | Sigstore/local | 20% |
### 8.2 Visualization
- Donut chart showing confidence breakdown
- Hover for detailed explanations
- Color coding: Green (>80%), Yellow (50-80%), Red (<50%)
## 9. Component Inventory
### 9.1 Lineage Feature Components
| Component | Location | Status |
|-----------|----------|--------|
| `LineageGraphComponent` | `lineage-graph.component.ts` | Complete |
| `LineageNodeComponent` | `lineage-node.component.ts` | Complete |
| `LineageEdgeComponent` | `lineage-edge.component.ts` | Complete |
| `LineageHoverCardComponent` | `lineage-hover-card.component.ts` | Needs CGS |
| `LineageMiniMapComponent` | `lineage-minimap.component.ts` | Complete |
| `LineageControlsComponent` | `lineage-controls.component.ts` | Complete |
| `LineageSbomDiffComponent` | `lineage-sbom-diff.component.ts` | Needs expanders |
| `LineageVexDiffComponent` | `lineage-vex-diff.component.ts` | Needs gates |
| `LineageCompareComponent` | `lineage-compare.component.ts` | Needs timeline |
| `LineageExportDialogComponent` | `lineage-export-dialog.component.ts` | Needs audit pack |
## 10. Related Documentation
- [SbomService Lineage API](../sbomservice/lineage/architecture.md)
- [UI Architecture](../ui/architecture.md)
- [Graph Module Architecture](../graph/architecture.md)

View File

@@ -0,0 +1,333 @@
# SBOM Sources Architecture
> Sprint: SPRINT_20251229_000_PLATFORM_sbom_sources_overview
> Last Updated: 2025-12-29
## 1. Overview
The SBOM Sources subsystem provides a unified configuration and management layer for all SBOM ingestion pathways: Zastava (registry webhooks), Docker (direct image scans), CLI (external submissions), and Git (repository scans).
### 1.1 Problem Statement
**Current State:**
- Fragmented source management across Orchestrator, Concelier, and Scanner
- No unified UI for configuring ingestion sources
- Credentials scattered without centralized management
- No visibility into source health and scan history
**Target State:**
- Single "Sources" module for all SBOM ingestion configuration
- Unified UI with type-specific wizards
- Centralized credential management via AuthRef pattern
- Real-time status monitoring and run history
## 2. Source Types Taxonomy
| Type | Trigger Mode | Target | Auth Pattern | Discovery |
|------|--------------|--------|--------------|-----------|
| **Zastava** | Webhook (push) | Registry images | Registry creds + webhook secret | From webhook payload |
| **Docker** | Scheduled/Manual | Specific images | Registry credentials | Tag patterns |
| **CLI** | External submission | Any SBOM | API token | N/A (receives SBOMs) |
| **Git** | Webhook/Scheduled | Repository code | PAT/SSH + webhook secret | Branch patterns |
## 3. Health Signals
Each source maintains the following health signals:
| Signal | Description | Metric |
|--------|-------------|--------|
| `status` | Current operational state | `active`, `paused`, `error`, `disabled`, `pending` |
| `lastRunAt` | Timestamp of most recent run | ISO-8601 UTC |
| `lastRunStatus` | Status of most recent run | `succeeded`, `failed`, `partial-success` |
| `consecutiveFailures` | Count of consecutive failed runs | Integer, resets on success |
| `currentHourScans` | Scans executed in rate-limit window | Integer, resets hourly |
## 4. API Contract
### 4.1 Source CRUD Endpoints
```
GET /api/v1/sources List sources with filtering/pagination
POST /api/v1/sources Create new source
GET /api/v1/sources/{sourceId} Get source details
PUT /api/v1/sources/{sourceId} Update source configuration
DELETE /api/v1/sources/{sourceId} Delete source
```
### 4.2 Operational Endpoints
```
POST /api/v1/sources/{sourceId}/test Test source connection
POST /api/v1/sources/{sourceId}/trigger Manual scan trigger
POST /api/v1/sources/{sourceId}/pause Pause source (with reason)
POST /api/v1/sources/{sourceId}/resume Resume paused source
```
### 4.3 Run History Endpoints
```
GET /api/v1/sources/{sourceId}/runs List run history (paginated)
GET /api/v1/sources/{sourceId}/runs/{runId} Get run details
```
### 4.4 Webhook Endpoints
```
POST /api/v1/webhooks/zastava/{sourceId} Zastava registry webhook
POST /api/v1/webhooks/git/{sourceId} Git repository webhook
```
## 5. Domain Events
| Event | Payload | When Emitted |
|-------|---------|--------------|
| `source.created` | `{ sourceId, sourceType, tenantId }` | New source registered |
| `source.updated` | `{ sourceId, changedFields[] }` | Source configuration updated |
| `source.deleted` | `{ sourceId }` | Source removed |
| `source.paused` | `{ sourceId, reason, pausedBy }` | Source paused |
| `source.resumed` | `{ sourceId, resumedBy }` | Source resumed |
| `source.run.started` | `{ runId, sourceId, trigger }` | Run initiated |
| `source.run.completed` | `{ runId, sourceId, status, metrics }` | Run finished |
## 6. Credential Lifecycle (AuthRef Pattern)
All source credentials use the AuthRef pattern for secure storage:
1. **Storage**: Credentials stored in Authority vault, never inline in source configs
2. **Reference**: Sources hold `authRef` identifiers pointing to vault entries
3. **Rotation**: Rotate-on-demand API; old refs invalidated, new ref issued
4. **Audit**: All credential access logged with source context
### 6.1 Supported Credential Types
| Source Type | Credential Types |
|-------------|------------------|
| Zastava | Registry auth (basic/token), webhook secret |
| Docker | Registry auth (basic/token/ECR/GCR/ACR) |
| CLI | API token, OIDC identity |
| Git | PAT, SSH key, webhook secret |
## 7. Telemetry Schema
### 7.1 Metrics
| Metric | Type | Labels | Description |
|--------|------|--------|-------------|
| `sbom_source_runs_total` | Counter | `source_type`, `status`, `trigger` | Total runs by type and outcome |
| `sbom_source_run_duration_seconds` | Histogram | `source_type` | Run execution time |
| `sbom_source_items_scanned_total` | Counter | `source_type` | Items processed per run |
| `sbom_source_connection_test_duration_seconds` | Histogram | `source_type` | Connection test latency |
| `sbom_source_active_count` | Gauge | `source_type`, `status` | Active sources by type |
### 7.2 Structured Logs
All source operations emit structured logs including:
- `tenantId`, `sourceId`, `sourceType`
- `runId` (when applicable)
- `correlationId` for cross-service tracing
## 8. Module Ownership Matrix
| Component | Owner Module | Interface |
|-----------|--------------|-----------|
| Source entity persistence | SbomService | PostgreSQL + Repository |
| Credential storage | Authority | AuthRef vault API |
| Webhook signature verification | SbomService | HMAC validation |
| Scheduled trigger dispatch | Scheduler | Cron job registration |
| Scan job execution | Scanner | Job queue interface |
| UI configuration | Web | Sources Manager feature |
## 9. UI Information Architecture
### 9.1 Navigation Placement
| Section | Route | Purpose |
|---------|-------|---------|
| Sources List | `/sources` | Primary view with filtering, status overview, bulk actions |
| Source Detail | `/sources/{id}` | Configuration view, run history, health metrics |
| Add Source Wizard | `/sources/new` | Multi-step creation flow |
| Edit Source | `/sources/{id}/edit` | Modify existing source configuration |
### 9.2 Wizard Flow Architecture
The Add/Edit Source Wizard follows a 6-step progressive disclosure pattern:
```
┌─────────────────────────────────────────────────────────────────────────────┐
│ Step 1: Source Type Selection │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Zastava │ │ Docker │ │ CLI │ │ Git │ │
│ │ (Webhook) │ │ (Scanner) │ │ (Receiver) │ │ (Repository)│ │
│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ Step 2: Basic Information │
│ • Name (required, unique per tenant) │
│ • Description (optional) │
│ • Tags (multi-select, for filtering) │
│ • Metadata key-value pairs (optional) │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ Step 3: Type-Specific Configuration (varies by source type) │
│ │
│ Zastava: Docker: │
│ • Registry URL • Registry URL │
│ • Registry type dropdown • Image references (multi-add) │
│ • Repository filters • Tag patterns (include/exclude) │
│ • Tag patterns • Platform selection │
│ • Webhook path (generated) • Scan options (analyzers, reachability) │
│ │
│ CLI: Git: │
│ • Allowed tools list • Provider (GitHub/GitLab/Gitea/etc.) │
│ • Allowed CI systems • Repository URL │
│ • Validation rules • Branch patterns (include/exclude) │
│ • Attribution requirements • Trigger modes (push/PR/tag/scheduled) │
│ • Max SBOM size limit • Scan paths and exclusions │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ Step 4: Credentials (AuthRef Pattern) │
│ • Credential type selector (per source type) │
│ • Create new credential vs. select existing │
│ • Inline credential entry (stored via Authority vault) │
│ • Webhook secret generation (for Zastava/Git) │
│ • Test credential validity button │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ Step 5: Schedule (Optional - for Docker/Git scheduled triggers) │
│ • Enable scheduled scans toggle │
│ • Cron expression builder or preset selector │
│ • Timezone picker │
│ • Rate limit (max scans per hour) │
│ • Next run preview │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ Step 6: Review & Test Connection │
│ • Configuration summary (read-only) │
│ • Test Connection button with status indicator │
│ • Error details expansion if test fails │
│ • Create Source / Save Changes button │
│ • Webhook endpoint display (for Zastava/Git - copy to clipboard) │
└─────────────────────────────────────────────────────────────────────────────┘
```
### 9.3 Wizard Step Validation
| Step | Required Fields | Validation |
|------|-----------------|------------|
| 1 - Type | `sourceType` | Must select one type |
| 2 - Basic Info | `name` | Unique name, 3-100 chars |
| 3 - Config | Varies by type | Type-specific required fields |
| 4 - Credentials | `authRef` (if required) | Valid credential for source type |
| 5 - Schedule | None (optional step) | Valid cron if enabled |
| 6 - Review | None | Connection test recommended |
### 9.4 Source List Page Components
```
┌─────────────────────────────────────────────────────────────────────────────┐
│ SBOM Sources [+ Add Source] │
├─────────────────────────────────────────────────────────────────────────────┤
│ Status Cards: │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Active │ │ Paused │ │ Error │ │ Pending │ │
│ │ 12 │ │ 3 │ │ 2 │ │ 1 │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
├─────────────────────────────────────────────────────────────────────────────┤
│ Filters: [Type ▼] [Status ▼] [Tags ▼] [Search: ________] │
├─────────────────────────────────────────────────────────────────────────────┤
│ □ │ Name │ Type │ Status │ Last Run │ Next Run │ Actions │
│ ──┼───────────────┼─────────┼──────────┼────────────┼──────────┼─────────│
│ □ │ DockerHub Prd │ Zastava │ ● Active │ 5 min ago │ - │ ⋮ │
│ □ │ Harbor Dev │ Zastava │ ● Active │ 12 min ago │ - │ ⋮ │
│ □ │ Nightly Scans │ Docker │ ● Active │ 2h ago │ 02:00 AM │ ⋮ │
│ □ │ CI Pipeline │ CLI │ ⏸ Paused │ 1 day ago │ - │ ⋮ │
│ □ │ Monorepo │ Git │ ⚠ Error │ Failed │ - │ ⋮ │
├─────────────────────────────────────────────────────────────────────────────┤
│ Showing 1-5 of 18 [< Prev] [1] [2] [3] [4] [Next >] │
└─────────────────────────────────────────────────────────────────────────────┘
```
### 9.5 Row Actions Menu
| Action | Icon | Availability |
|--------|------|--------------|
| View Details | 👁 | Always |
| Edit | ✏️ | Always |
| Trigger Scan | ▶ | Active sources |
| Test Connection | 🔌 | Always |
| Pause | ⏸ | Active sources |
| Resume | ▶ | Paused sources |
| Delete | 🗑 | Always (with confirmation) |
### 9.6 Source Detail Page Layout
```
┌─────────────────────────────────────────────────────────────────────────────┐
│ ← Back to Sources │
├─────────────────────────────────────────────────────────────────────────────┤
│ Docker Hub Production [Trigger] [Test] [Edit] [⋮] │
│ Type: Zastava │ Status: ● Active │ Created: Dec 15, 2025 │
├─────────────────────────────────────────────────────────────────────────────┤
│ [Overview] [Configuration] [Run History] [Metrics] │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Configuration: │
│ ┌───────────────────────────────────────────────────────────────────────┐ │
│ │ Registry URL: https://registry-1.docker.io │ │
│ │ Registry Type: Docker Hub │ │
│ │ Webhook Path: /api/v1/webhooks/zastava/src-abc123 │ │
│ │ Repository Filter: myorg/*, prod-* │ │
│ │ Tag Filter: v*, latest (excluding: *-dev, *-test) │ │
│ │ Analyzers: OS, Node.js, Python, Go │ │
│ │ Reachability: Enabled │ │
│ │ VEX Lookup: Enabled │ │
│ └───────────────────────────────────────────────────────────────────────┘ │
│ │
│ Run History: │
│ ┌───────────────────────────────────────────────────────────────────────┐ │
│ │ Run ID │ Trigger │ Status │ Started │ Duration │ Items │ │
│ │ run-456 │ Webhook │ ✓ Success │ 5 min ago │ 45s │ 3/3 │ │
│ │ run-455 │ Webhook │ ✓ Success │ 12 min ago │ 38s │ 1/1 │ │
│ │ run-454 │ Manual │ ✓ Success │ 1h ago │ 2m 15s │ 12/12 │ │
│ │ run-453 │ Webhook │ ⚠ Partial │ 2h ago │ 1m 30s │ 4/5 │ │
│ │ run-452 │ Schedule │ ✗ Failed │ 3h ago │ 12s │ 0/0 │ │
│ └───────────────────────────────────────────────────────────────────────┘ │
│ [Load More] │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
```
## 10. Security Considerations
| Concern | Mitigation |
|---------|------------|
| Credential exposure | AuthRef pattern - never inline, always reference vault |
| Webhook forgery | HMAC signature verification for all webhooks |
| Unauthorized access | Scope-based authorization (`sources:read`, `sources:write`, `sources:admin`) |
| Secret logging | Audit logging excludes credential values |
| Webhook secret rotation | Rotate-on-demand API endpoint |
## 10. Configuration
Environment variables (prefix `SBOM_SbomService__Sources__`):
| Variable | Default | Description |
|----------|---------|-------------|
| `MaxSourcesPerTenant` | 100 | Maximum sources per tenant |
| `DefaultMaxScansPerHour` | 60 | Default rate limit per source |
| `RunHistoryRetentionDays` | 90 | Run history retention period |
| `WebhookSignatureAlgorithm` | `HMAC-SHA256` | Webhook signature algorithm |
| `ConnectionTestTimeoutSeconds` | 30 | Connection test timeout |
## 11. Related Documentation
- [SbomService Architecture](../architecture.md)
- [Lineage Ledger](../lineage-ledger.md)
- [Authority Architecture](../../authority/architecture.md)
- [Scanner Architecture](../../scanner/architecture.md)
- [UI Architecture](../../ui/architecture.md)