Security posture measures visible security hygiene, backed by the OpenSSF Scorecard — the neutral, versioned, tool-agnostic security standard maintained by the Open Source Security Foundation. It supplies the base value of the Security category, which carries 16% of the overall index; high-risk jurisdiction exposure can only reduce that base through the published policy multiplier and rating ceiling.
- Category: Security (base value before multiplier)
- Weight in overall index: 16% before the jurisdiction policy adjustment
- Metric key:
security_posture
How the value is computed
Each Scorecard check becomes a component, weighted by Scorecard's own risk level:
| Scorecard risk level | Component weight |
|---|---|
| Critical | 10 |
| High | 7.5 |
| Medium | 5 |
| Low | 2.5 |
The rolled-up 1–100 value therefore tracks Scorecard's 0–10 aggregate (value ≈ aggregate × 10). Checks Scorecard reports as inconclusive — for example Branch-Protection without an admin token — are excluded and renormalized, never counted as zero. That rule is what keeps well-run projects on non-GitHub tooling from reading near zero, and it is documented in methodology versions (0.6.0).
Every report renders the full per-check breakdown — score, reasoning, and a link to Scorecard's documentation for each check.
Shared evidence
Security keeps the complete risk-weighted Scorecard result. Seven checks also substantiate other health dimensions. Six provide small, separately weighted OpenSSF Scorecard: … components there: Maintained, Signed-Releases, Contributors, Code-Review, CI-Tests, and Pinned-Dependencies. The seventh, License, is the sole license signal in community health — shown there generically as License, with a fallback to GitHub's community profile when no Scorecard is available. This is an intentional cross-category influence, not reuse of Scorecard's security risk weights. Inconclusive (n/a) checks remain excluded everywhere.
What the checks reward
The practice, never a vendor's config file:
- Dependency update automation — Dependabot, Renovate, or any accepted tool.
- Static analysis (SAST) — CodeQL, Semgrep, or equivalent.
- No known-vulnerable dependencies — the highest-risk check.
- Least-privilege workflow tokens, pinned dependencies, signed releases, a security policy, and more.
The fallback path
Running Scorecard requires its CLI; when unavailable, the metric falls back to coarse file-tree signals, and the report marks the source explicitly (inputs.source == "file_signals"):
| Fallback component | Weight | Note |
|---|---|---|
| Security policy (SECURITY.md) | 30 | |
| Dependabot configuration | 25 | |
| Dependency lockfiles | 25 | applications only — libraries conventionally publish without committing a lockfile, so the check is excluded for them (see 0.9.0) |
| CodeQL workflow | 20 |
Reading the result
- Compare the aggregate with the per-check table: a middling value with one failed critical check is a different situation from uniform mediocrity.
n/arows are inconclusive checks — excluded, not failed.
Improving the value
- Publish
SECURITY.md, enable automated dependency updates, and add a SAST workflow. - Resolve known-vulnerable dependencies first — highest risk weight, highest real-world payoff.
- Set explicit least-privilege permissions on CI workflows and pin third-party actions.
Related: Security · high-risk jurisdiction exposure · methodology versions