|
1 | 1 | DESCRIPTION > |
2 | | - Security & Supply Chain category (max 35 pts): open vulnerabilities (10, blocked when the repo |
| 2 | + Security & Supply Chain category (max 35 pts): open vulnerabilities (12, blocked when the repo |
3 | 3 | has never completed a vulnerability scan — see vulnerability_scans — so "0 open vulns" isn't |
4 | | - conflated with "never scanned"), OpenSSF Scorecard (7, |
| 4 | + conflated with "never scanned"), OpenSSF Scorecard (8, |
5 | 5 | blocked for repos with no repos-table row — effectively non-GitHub hosts), security practices |
6 | | - (spec max 8, but capped here at 7 achievable — the spec's 6th bullet, security_contact_email, |
7 | | - has no corresponding column anywhere in our GitHub enrichment data, so it's permanently omitted |
8 | | - like Supply Chain Integrity below; blocked entirely when repos-table row missing), dependency |
9 | | - health (5, blocked when the repo has no published packages so vulnerability exposure is unknown), |
10 | | - supply chain integrity (5, permanently blocked — hardcoded per spec, provenance/2FA data not yet |
11 | | - in the pipeline). Graceful degradation (spec Layer 1+2): category_subtotal = |
| 6 | + (8, blocked when repos-table row is missing; security_contact_email has no column in GitHub |
| 7 | + enrichment data so the sub-score is capped at 7 internally, scaled to 8 at aggregation), |
| 8 | + dependency health (7, blocked when the repo has no published packages so vulnerability exposure |
| 9 | + is unknown). Graceful degradation (spec Layer 1+2): category_subtotal = |
12 | 10 | SUM(available_sub_scores) * (35 / SUM(available_sub_max_weights)); category is `unavailable` |
13 | 11 | (NULL) when covered weight is <40% of 35. |
14 | 12 | - Split out of health_score_v2.pipe into its own copy pipe (2026-07-22) — see |
15 | 13 | health_score_v2_maintainer.pipe description for why. |
16 | 14 | - Scorecard banded mapping (2026-08-27, IN-1247): raw ≥ 7 → 7 pts, ≥ 5.5 → 5, ≥ 4 → 4, |
17 | 15 | ≥ 2.5 → 2, else 0. Replaces the linear round(min(raw,10)×0.7) which required raw ≥ 9.3 for |
18 | 16 | full points (only 0.33% of repos), calibrated to real distribution (median ≈ 4, p99 ≈ 7.9). |
| 17 | + - Supply-chain-integrity reallocation (2026-08-28, IN-1250): the permanently-blocked 5 pts were |
| 18 | + folded proportionally into the four available signals (×35/29 each, rounded to integers), so the |
| 19 | + covered-weight maximum equals the category maximum (35) and the rescale factor is 1.0 for |
| 20 | + fully-covered repos. Category max and Layer 2 weight unchanged. |
19 | 21 |
|
20 | 22 | NODE health_score_v2_security_calc |
21 | 23 | SQL > |
@@ -68,16 +70,16 @@ SQL > |
68 | 70 | dependencyHealthAvailable, |
69 | 71 | vulnerableDeps, |
70 | 72 | ( |
71 | | - openVulnAvailable * openVulnScore |
72 | | - + scorecardAvailable * scorecardScorePts |
73 | | - + securityPracticesAvailable * securityPracticesScore |
74 | | - + dependencyHealthAvailable * dependencyHealthScore |
| 73 | + openVulnAvailable * openVulnScore * 1.2 |
| 74 | + + scorecardAvailable * scorecardScorePts * 8.0 / 7 |
| 75 | + + securityPracticesAvailable * securityPracticesScore * 8.0 / 7 |
| 76 | + + dependencyHealthAvailable * dependencyHealthScore * 1.4 |
75 | 77 | ) AS rawScore, |
76 | 78 | ( |
77 | | - openVulnAvailable * 10 |
78 | | - + scorecardAvailable * 7 |
79 | | - + securityPracticesAvailable * 7 |
80 | | - + dependencyHealthAvailable * 5 |
| 79 | + openVulnAvailable * 12 |
| 80 | + + scorecardAvailable * 8 |
| 81 | + + securityPracticesAvailable * 8 |
| 82 | + + dependencyHealthAvailable * 7 |
81 | 83 | ) AS coveredWeight |
82 | 84 | FROM |
83 | 85 | ( |
|
0 commit comments