Security measures visible security and supply-chain practice: dependency update automation, static analysis, signed releases, least-privilege CI tokens, known-vulnerable dependencies, security policy, and policy-defined high-risk jurisdiction exposure. It answers the question a dependency reviewer actually asks: does this project practice security in the open?
The category carries 16% of the overall health index. Its posture is multiplied by the jurisdiction risk signal, so clean location evidence cannot lift weak hygiene:
Security = security_posture × high_risk_jurisdiction_exposure / 100
Metric in this category
| Metric | Weight in category | Weight in overall |
|---|---|---|
| Security posture | base value | 16% before multiplier |
| High-Risk Jurisdiction Exposure | policy multiplier | no additive weight |
The jurisdiction risk signal uses only high-confidence, self-published public profile evidence within the current Russia, Iran, and North Korea scope. Ambiguous evidence and missing locations never reduce the score. A confirmed match creates an enhanced-review priority; it is not an inference of nationality, citizenship, sanctions status, malicious intent, or individual trustworthiness. See the full evidence, scoring, and enterprise interpretation guide.
Security posture is backed by the OpenSSF Scorecard, the neutral, versioned security standard maintained by the Open Source Security Foundation. Each Scorecard check becomes a component, weighted by Scorecard's own risk level, and checks Scorecard cannot determine are excluded rather than counted as zero. When the Scorecard tooling is unavailable, the metric falls back to coarse file-tree signals and the report says so.
Some Scorecard practices also substantiate another health dimension. Since methodology v1.0.0, seven selected checks provide small shared-evidence components in their relevant cards while retaining their full Security weight. The mappings and category-specific weights are published in Security posture and methodology versions.
Why tool-agnostic
The methodology deliberately rewards the practice, not a vendor's config file: any accepted dependency-update tool (Dependabot, Renovate, …), any SAST (CodeQL, Semgrep, …). Projects on non-GitHub tooling are not structurally penalized — a fairness property inherited from Scorecard and preserved by excluding inconclusive checks (see methodology versions, 0.6.0).
Reading the category value
- The full per-check breakdown — every Scorecard check, its score, and its reasoning — is rendered in each report, with links to Scorecard's own documentation per check.
- A critical Security band on an otherwise healthy project is the classic case where the overall index must not be read alone: the per-category bands exist to surface exactly this.
Improving Security
- Publish a
SECURITY.mdwith a disclosure channel. - Turn on automated dependency updates and a SAST workflow — any accepted tool counts.
- Grant CI workflows least-privilege tokens, pin dependencies where appropriate, and sign releases.
- Address known-vulnerable dependencies promptly; that check carries Scorecard's highest risk weighting.
Related: security posture · high-risk jurisdiction exposure · the health index