feat: add security sink detection patterns for JavaScript/TypeScript
- Introduced `sink-detect.js` with various security sink detection patterns categorized by type (e.g., command injection, SQL injection, file operations). - Implemented functions to build a lookup map for fast sink detection and to match sink calls against known patterns. - Added `package-lock.json` for dependency management.
This commit is contained in:
StellaOps Bot
@@ -559,6 +559,159 @@ public interface IVexConnector
|
||||
|
||||
---
|
||||
|
||||
## 7.1) Trust Lattice Framework
|
||||
|
||||
The Trust Lattice extends the basic consensus algorithm with a sophisticated 3-component trust vector model that enables explainable, deterministically replayable vulnerability decisioning.
|
||||
|
||||
### 7.1.1 Trust Vector Model (P/C/R)
|
||||
|
||||
Each VEX source is assigned a `TrustVector` with three components:
|
||||
|
||||
| Component | Symbol | Description | Range |
|
||||
|-----------|--------|-------------|-------|
|
||||
| **Provenance** | P | Cryptographic & process integrity (signatures, key management) | 0.0–1.0 |
|
||||
| **Coverage** | C | Scope match precision (how well claims match the target) | 0.0–1.0 |
|
||||
| **Replayability** | R | Determinism and input pinning (reproducibility) | 0.0–1.0 |
|
||||
|
||||
**Base Trust Calculation:**
|
||||
```
|
||||
BaseTrust(S) = wP * P + wC * C + wR * R
|
||||
|
||||
Default weights:
|
||||
wP = 0.45 (provenance)
|
||||
wC = 0.35 (coverage)
|
||||
wR = 0.20 (replayability)
|
||||
```
|
||||
|
||||
**Default Trust Vectors by Source Class:**
|
||||
|
||||
| Source Class | P | C | R | Notes |
|
||||
|-------------|---|---|---|-------|
|
||||
| Vendor | 0.90 | 0.70 | 0.60 | High provenance, moderate coverage |
|
||||
| Distro | 0.80 | 0.85 | 0.60 | Strong coverage for package-level claims |
|
||||
| Internal | 0.85 | 0.95 | 0.90 | Highest coverage and replayability |
|
||||
| Hub | 0.60 | 0.50 | 0.40 | Aggregated sources, lower baseline |
|
||||
| Attestation | 0.95 | 0.80 | 0.70 | Cryptographically verified statements |
|
||||
|
||||
### 7.1.2 Claim Scoring
|
||||
|
||||
Each VEX claim is scored using the formula:
|
||||
|
||||
```
|
||||
ClaimScore = BaseTrust(S) * M * F
|
||||
|
||||
Where:
|
||||
S = Source's TrustVector
|
||||
M = Claim strength multiplier [0.40–1.00]
|
||||
F = Freshness decay factor [floor–1.00]
|
||||
```
|
||||
|
||||
**Claim Strength Multipliers:**
|
||||
|
||||
| Evidence Type | Strength (M) |
|
||||
|--------------|--------------|
|
||||
| Exploitability analysis + reachability proof | 1.00 |
|
||||
| Config/feature-flag reason with evidence | 0.80 |
|
||||
| Vendor blanket statement | 0.60 |
|
||||
| Under investigation | 0.40 |
|
||||
|
||||
**Freshness Decay:**
|
||||
|
||||
```
|
||||
F = max(exp(-ln(2) * age_days / half_life), floor)
|
||||
|
||||
Default:
|
||||
half_life = 90 days
|
||||
floor = 0.35 (minimum freshness)
|
||||
```
|
||||
|
||||
### 7.1.3 Lattice Merge Algorithm
|
||||
|
||||
The `ClaimScoreMerger` combines multiple scored claims into a deterministic verdict:
|
||||
|
||||
1. **Score claims** using the ClaimScore formula.
|
||||
2. **Detect conflicts** when claims have different statuses.
|
||||
3. **Apply conflict penalty** (default δ=0.25) to all claims when conflicts exist.
|
||||
4. **Order candidates** by: adjusted score → scope specificity → original score → source ID.
|
||||
5. **Select winner** as the highest-ranked claim.
|
||||
6. **Generate audit trail** with all claims, scores, and conflict records.
|
||||
|
||||
**Merge Result:**
|
||||
```jsonc
|
||||
{
|
||||
"status": "not_affected",
|
||||
"confidence": 0.82,
|
||||
"hasConflicts": true,
|
||||
"winningClaim": { "sourceId": "vendor:redhat", "status": "not_affected", ... },
|
||||
"conflicts": [
|
||||
{ "sourceId": "hub:osv", "status": "affected", "reason": "status_conflict" }
|
||||
],
|
||||
"requiresReplayProof": true
|
||||
}
|
||||
```
|
||||
|
||||
### 7.1.4 Policy Gates
|
||||
|
||||
Policy gates enforce trust-based constraints on verdicts:
|
||||
|
||||
| Gate | Purpose | Default Threshold |
|
||||
|------|---------|-------------------|
|
||||
| `MinimumConfidenceGate` | Reject verdicts below confidence threshold | 0.75 (prod), 0.60 (staging) |
|
||||
| `UnknownsBudgetGate` | Fail if unknowns exceed budget | 5 per scan |
|
||||
| `SourceQuotaGate` | Cap single-source influence | 60% unless corroborated |
|
||||
| `ReachabilityRequirementGate` | Require reachability proof for criticals | Enabled |
|
||||
|
||||
Gates are evaluated via `PolicyGateRegistry` and can be configured per environment.
|
||||
|
||||
### 7.1.5 Calibration
|
||||
|
||||
Trust vectors are automatically calibrated based on post-mortem truth comparison:
|
||||
|
||||
```
|
||||
TrustVector' = TrustVector + Δ
|
||||
|
||||
Δ = f(accuracy, detected_bias, learning_rate, momentum)
|
||||
|
||||
Defaults:
|
||||
learning_rate = 0.02 per epoch
|
||||
max_adjustment = 0.05 per epoch
|
||||
momentum_factor = 0.9
|
||||
```
|
||||
|
||||
**Bias Types:**
|
||||
- `OptimisticBias` → reduce Provenance
|
||||
- `PessimisticBias` → increase Provenance
|
||||
- `ScopeBias` → reduce Coverage
|
||||
|
||||
Calibration manifests are stored for auditing and rollback.
|
||||
|
||||
### 7.1.6 Configuration
|
||||
|
||||
Trust lattice settings in `etc/trust-lattice.yaml.sample`:
|
||||
|
||||
```yaml
|
||||
trustLattice:
|
||||
weights:
|
||||
provenance: 0.45
|
||||
coverage: 0.35
|
||||
replayability: 0.20
|
||||
freshness:
|
||||
halfLifeDays: 90
|
||||
floor: 0.35
|
||||
defaults:
|
||||
vendor: { p: 0.90, c: 0.70, r: 0.60 }
|
||||
distro: { p: 0.80, c: 0.85, r: 0.60 }
|
||||
internal: { p: 0.85, c: 0.95, r: 0.90 }
|
||||
calibration:
|
||||
enabled: true
|
||||
learningRate: 0.02
|
||||
maxAdjustmentPerEpoch: 0.05
|
||||
```
|
||||
|
||||
See `docs/modules/excititor/trust-lattice.md` for the complete specification.
|
||||
|
||||
---
|
||||
|
||||
## 8) Query & export APIs
|
||||
|
||||
All endpoints are versioned under `/api/v1/vex`.
|
||||
|
||||
Reference in New Issue
Block a user