themed the bulk of advisories
This commit is contained in:
StellaOps Bot
@@ -0,0 +1,379 @@
|
||||
# CVSS and Competitive Analysis Technical Reference
|
||||
|
||||
**Source Advisories**:
|
||||
- 29-Nov-2025 - CVSS v4.0 Momentum in Vulnerability Management
|
||||
- 30-Nov-2025 - Comparative Evidence Patterns for Stella Ops
|
||||
- 03-Dec-2025 - Next‑Gen Scanner Differentiators and Evidence Moat
|
||||
|
||||
**Last Updated**: 2025-12-14
|
||||
|
||||
---
|
||||
|
||||
## 1. CVSS V4.0 INTEGRATION
|
||||
|
||||
### 1.1 Requirements
|
||||
|
||||
- Vendors (NVD, GitHub, Microsoft, Snyk) shipping CVSS v4 signals
|
||||
- Awareness needed for receipt schemas, reporting, UI alignment
|
||||
|
||||
### 1.2 Determinism & Offline
|
||||
|
||||
- Keep CVSS vector parsing deterministic
|
||||
- Pin scoring library versions in receipts
|
||||
- Avoid live API dependency
|
||||
- Rely on mirrored NVD feeds or frozen samples
|
||||
|
||||
### 1.3 Schema Mapping
|
||||
|
||||
- Map impacts to receipt schemas
|
||||
- Identify UI/reporting deltas for transparency
|
||||
- Note in sprint Decisions & Risks for CVSS receipts
|
||||
|
||||
## 2. SCANNER DISCREPANCIES ANALYSIS
|
||||
|
||||
### 2.1 Trivy vs Grype Comparative Study (927 images)
|
||||
|
||||
**Findings**:
|
||||
- Tools disagreed on total vulnerability counts and specific CVE IDs
|
||||
- Grype: ~603,259 vulns; Trivy: ~473,661 vulns
|
||||
- Exact match in only 9.2% of cases (80 out of 865 vulnerable images)
|
||||
- Even with same counts, specific vulnerability IDs differed
|
||||
|
||||
**Root Causes**:
|
||||
- Divergent vulnerability databases
|
||||
- Differing matching logic
|
||||
- Incomplete visibility
|
||||
|
||||
### 2.2 VEX Tools Consistency Study (2025)
|
||||
|
||||
**Tools Tested**:
|
||||
- Trivy
|
||||
- Grype
|
||||
- OWASP DepScan
|
||||
- Docker Scout
|
||||
- Snyk CLI
|
||||
- OSV-Scanner
|
||||
- Vexy
|
||||
|
||||
**Results**:
|
||||
- Low consistency/similarity across container scanners
|
||||
- DepScan: 18,680 vulns; Vexy: 191 vulns (2 orders of magnitude difference)
|
||||
- Pairwise Jaccard indices very low (near 0)
|
||||
- 4 most consistent tools shared only ~18% common vulnerabilities
|
||||
|
||||
### 2.3 Implications for StellaOps
|
||||
|
||||
**Moats Needed**:
|
||||
- Golden-fixture benchmarks (container images with known, audited vulnerabilities)
|
||||
- Deterministic, replayable scans
|
||||
- Cryptographic integrity
|
||||
- VEX/SBOM proofs
|
||||
|
||||
**Metrics**:
|
||||
- **Closure rate**: Time from flagged to confirmed exploitable
|
||||
- **Proof coverage**: % of dependencies with valid SBOM/VEX proofs
|
||||
- **Differential-closure**: Impact of database updates or policy changes on prior scan results
|
||||
|
||||
## 3. RUNTIME REACHABILITY APPROACHES
|
||||
|
||||
### 3.1 Runtime-Aware Vulnerability Prioritization
|
||||
|
||||
**Approach**:
|
||||
- Monitor container workloads at runtime to determine which vulnerable components are actually used
|
||||
- Use eBPF-based monitors, dynamic tracers, or built-in profiling
|
||||
- Construct runtime call graph or dependency graph
|
||||
- Map vulnerabilities to code entities (functions/modules)
|
||||
- If execution trace covers entity, vulnerability is "reachable"
|
||||
|
||||
**Findings**: ~85% of critical vulns in containers are in inactive code (Sysdig)
|
||||
|
||||
### 3.2 Reachability Analysis Techniques
|
||||
|
||||
**Static**:
|
||||
- Call-graph analysis (Snyk reachability, CodeQL)
|
||||
- All possible paths
|
||||
|
||||
**Dynamic**:
|
||||
- Runtime observation (loaded modules, invoked functions)
|
||||
- Actual runtime paths
|
||||
|
||||
**Granularity Levels**:
|
||||
- Function-level (precise, limited languages: Java, .NET)
|
||||
- Package/module-level (broader, coarse)
|
||||
|
||||
**Hybrid Approach**: Combine static (all possible paths) + dynamic (actual runtime paths)
|
||||
|
||||
## 4. CONTAINER PROVENANCE & SUPPLY CHAIN
|
||||
|
||||
### 4.1 In-Toto/DSSE Framework (NDSS 2024)
|
||||
|
||||
**Purpose**:
|
||||
- Track chain of custody in software builds
|
||||
- Signed metadata (attestations) for each step
|
||||
- DSSE: Dead Simple Signing Envelope for standardized signing
|
||||
|
||||
### 4.2 Scudo System
|
||||
|
||||
**Features**:
|
||||
- Combines in-toto with Uptane
|
||||
- Verifies build process and final image
|
||||
- Full verification on client inefficient; verify upstream and trust summary
|
||||
- Client checks final signature + hash only
|
||||
|
||||
### 4.3 Supply Chain Verification
|
||||
|
||||
**Signers**:
|
||||
- Developer key signs code commit
|
||||
- CI key signs build attestation
|
||||
- Scanner key signs vulnerability attestation
|
||||
- Release key signs container image
|
||||
|
||||
**Verification Optimization**: Repository verifies in-toto attestations; client verifies final metadata only
|
||||
|
||||
## 5. VENDOR EVIDENCE PATTERNS
|
||||
|
||||
### 5.1 Snyk
|
||||
|
||||
**Evidence Handling**:
|
||||
- Runtime insights integration (Nov 2025)
|
||||
- Evolution from static-scan noise to prioritized workflow
|
||||
- Deployment context awareness
|
||||
|
||||
**VEX Support**:
|
||||
- CycloneDX VEX format
|
||||
- Reachability-aware suppression
|
||||
|
||||
### 5.2 GitHub Advanced Security
|
||||
|
||||
**Features**:
|
||||
- CodeQL for static analysis
|
||||
- Dependency graph
|
||||
- Dependabot alerts
|
||||
- Security advisories
|
||||
|
||||
**Evidence**:
|
||||
- SARIF output
|
||||
- SBOM generation (SPDX)
|
||||
|
||||
### 5.3 Aqua Security
|
||||
|
||||
**Approach**:
|
||||
- Runtime protection
|
||||
- Image scanning
|
||||
- Kubernetes security
|
||||
|
||||
**Evidence**:
|
||||
- Dynamic runtime traces
|
||||
- Network policy violations
|
||||
|
||||
### 5.4 Anchore/Grype
|
||||
|
||||
**Features**:
|
||||
- Open-source scanner
|
||||
- Policy-based compliance
|
||||
- SBOM generation
|
||||
|
||||
**Evidence**:
|
||||
- CycloneDX/SPDX SBOM
|
||||
- Vulnerability reports (JSON)
|
||||
|
||||
### 5.5 Prisma Cloud
|
||||
|
||||
**Features**:
|
||||
- Cloud-native security
|
||||
- Runtime defense
|
||||
- Compliance monitoring
|
||||
|
||||
**Evidence**:
|
||||
- Multi-cloud attestations
|
||||
- Compliance reports
|
||||
|
||||
## 6. STELLAOPS DIFFERENTIATORS
|
||||
|
||||
### 6.1 Reachability-with-Evidence
|
||||
|
||||
**Why it Matters**:
|
||||
- Snyk Container integrating runtime insights as "signal" (Nov 2025)
|
||||
- Evolution from static-scan noise to prioritized, actionable workflow
|
||||
- Deployment context: what's running, what's reachable, what's exploitable
|
||||
|
||||
**Implication**: Container security triage relies on runtime/context signals
|
||||
|
||||
### 6.2 Proof-First Architecture
|
||||
|
||||
**Advantages**:
|
||||
- Every claim backed by DSSE-signed attestations
|
||||
- Cryptographic integrity
|
||||
- Audit trail
|
||||
- Offline verification
|
||||
|
||||
### 6.3 Deterministic Scanning
|
||||
|
||||
**Advantages**:
|
||||
- Reproducible results
|
||||
- Bit-identical outputs given same inputs
|
||||
- Replay manifests
|
||||
- Golden fixture benchmarks
|
||||
|
||||
### 6.4 VEX-First Decisioning
|
||||
|
||||
**Advantages**:
|
||||
- Exploitability modeled in OpenVEX
|
||||
- Lattice logic for stable outcomes
|
||||
- Evidence-linked justifications
|
||||
|
||||
### 6.5 Offline/Air-Gap First
|
||||
|
||||
**Advantages**:
|
||||
- No hidden network dependencies
|
||||
- Bundled feeds, keys, Rekor snapshots
|
||||
- Verifiable without internet access
|
||||
|
||||
## 7. COMPETITIVE POSITIONING
|
||||
|
||||
### 7.1 Market Segments
|
||||
|
||||
| Vendor | Strength | Weakness vs StellaOps |
|
||||
|--------|----------|----------------------|
|
||||
| Snyk | Developer experience | Less deterministic, SaaS-only |
|
||||
| Aqua | Runtime protection | Less reachability precision |
|
||||
| Anchore | Open-source, SBOM | Less proof infrastructure |
|
||||
| Prisma Cloud | Cloud-native breadth | Less offline/air-gap support |
|
||||
| GitHub | Integration with dev workflow | Less cryptographic proof chain |
|
||||
|
||||
### 7.2 StellaOps Unique Value
|
||||
|
||||
1. **Deterministic + Provable**: Bit-identical scans with cryptographic proofs
|
||||
2. **Reachability + Runtime**: Hybrid static/dynamic analysis
|
||||
3. **Offline/Sovereign**: Air-gap operation with regional crypto (FIPS/GOST/eIDAS/SM)
|
||||
4. **VEX-First**: Evidence-backed decisioning, not just alerting
|
||||
5. **AGPL-3.0**: Self-hostable, no vendor lock-in
|
||||
|
||||
## 8. MOAT METRICS
|
||||
|
||||
### 8.1 Proof Coverage
|
||||
|
||||
```
|
||||
proof_coverage = findings_with_valid_receipts / total_findings
|
||||
Target: ≥95%
|
||||
```
|
||||
|
||||
### 8.2 Closure Rate
|
||||
|
||||
```
|
||||
closure_rate = time_from_flagged_to_confirmed_exploitable
|
||||
Target: P95 < 24 hours
|
||||
```
|
||||
|
||||
### 8.3 Differential-Closure Impact
|
||||
|
||||
```
|
||||
differential_impact = findings_changed_after_db_update / total_findings
|
||||
Target: <5% (non-code changes)
|
||||
```
|
||||
|
||||
### 8.4 False Positive Reduction
|
||||
|
||||
```
|
||||
fp_reduction = (baseline_fp_rate - stella_fp_rate) / baseline_fp_rate
|
||||
Target: ≥50% vs baseline scanner
|
||||
```
|
||||
|
||||
### 8.5 Reachability Accuracy
|
||||
|
||||
```
|
||||
reachability_accuracy = correct_r0_r1_r2_r3_classifications / total_classifications
|
||||
Target: ≥90%
|
||||
```
|
||||
|
||||
## 9. COMPETITIVE INTELLIGENCE TRACKING
|
||||
|
||||
### 9.1 Feature Parity Matrix
|
||||
|
||||
| Feature | Snyk | Aqua | Anchore | Prisma | StellaOps |
|
||||
|---------|------|------|---------|--------|-----------|
|
||||
| SBOM Generation | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| VEX Support | ✓ | ✗ | Partial | ✗ | ✓ |
|
||||
| Reachability Analysis | ✓ | ✗ | ✗ | ✗ | ✓ |
|
||||
| Runtime Evidence | ✓ | ✓ | ✗ | ✓ | ✓ |
|
||||
| Cryptographic Proofs | ✗ | ✗ | ✗ | ✗ | ✓ |
|
||||
| Deterministic Scans | ✗ | ✗ | ✗ | ✗ | ✓ |
|
||||
| Offline/Air-Gap | ✗ | Partial | ✗ | ✗ | ✓ |
|
||||
| Regional Crypto | ✗ | ✗ | ✗ | ✗ | ✓ |
|
||||
|
||||
### 9.2 Monitoring Strategy
|
||||
|
||||
- Track vendor release notes
|
||||
- Monitor GitHub repos for feature announcements
|
||||
- Participate in security conferences
|
||||
- Engage with customer feedback
|
||||
- Update competitive matrix quarterly
|
||||
|
||||
## 10. MESSAGING FRAMEWORK
|
||||
|
||||
### 10.1 Core Message
|
||||
|
||||
"StellaOps provides deterministic, proof-backed vulnerability management with reachability analysis for offline/air-gapped environments."
|
||||
|
||||
### 10.2 Key Differentiators (Elevator Pitch)
|
||||
|
||||
1. **Deterministic**: Same inputs → same outputs, every time
|
||||
2. **Provable**: Cryptographic proof chains for every decision
|
||||
3. **Reachable**: Static + runtime analysis, not just presence
|
||||
4. **Sovereign**: Offline operation, regional crypto compliance
|
||||
5. **Open**: AGPL-3.0, self-hostable, no lock-in
|
||||
|
||||
### 10.3 Target Personas
|
||||
|
||||
- **Security Engineers**: Need proof-backed decisions for audits
|
||||
- **DevOps Teams**: Need deterministic scans in CI/CD
|
||||
- **Compliance Officers**: Need offline/air-gap for regulated environments
|
||||
- **Platform Engineers**: Need self-hostable, sovereign solution
|
||||
|
||||
## 11. BENCHMARKING PROTOCOL
|
||||
|
||||
### 11.1 Comparative Test Suite
|
||||
|
||||
**Images**:
|
||||
- 50 representative production images
|
||||
- Known vulnerabilities labeled
|
||||
- Reachability ground truth established
|
||||
|
||||
**Metrics**:
|
||||
- Precision (1 - FP rate)
|
||||
- Recall (TP / (TP + FN))
|
||||
- F1 score
|
||||
- Scan time (P50, P95)
|
||||
- Determinism (identical outputs over 10 runs)
|
||||
|
||||
### 11.2 Test Execution
|
||||
|
||||
```bash
|
||||
# Run StellaOps scan
|
||||
stellaops scan --image test-image:v1 --output stella-results.json
|
||||
|
||||
# Run competitor scans
|
||||
trivy image --format json test-image:v1 > trivy-results.json
|
||||
grype test-image:v1 -o json > grype-results.json
|
||||
snyk container test test-image:v1 --json > snyk-results.json
|
||||
|
||||
# Compare results
|
||||
stellaops benchmark compare \
|
||||
--ground-truth ground-truth.json \
|
||||
--stella stella-results.json \
|
||||
--trivy trivy-results.json \
|
||||
--grype grype-results.json \
|
||||
--snyk snyk-results.json
|
||||
```
|
||||
|
||||
### 11.3 Results Publication
|
||||
|
||||
- Publish benchmarks quarterly
|
||||
- Open-source test images and ground truth
|
||||
- Invite community contributions
|
||||
- Document methodology transparently
|
||||
|
||||
---
|
||||
|
||||
**Document Version**: 1.0
|
||||
**Target Platform**: .NET 10, PostgreSQL ≥16, Angular v17
|
||||
Reference in New Issue
Block a user