# Security

> The Security category — visible OpenSSF Scorecard hygiene and known-vulnerable dependencies, under two red-flag policies. Weight: 16% of the inspect.software health index.


**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**. Two metrics combine
as a weighted mean; two red-flag policies carry no additive weight and are
applied to security posture before the category is assembled, so clean
evidence can never lift weak hygiene:

`Security = 0.8 × adjusted_security_posture + 0.2 × dependency_advisories`

## Metrics in this category

| Metric | Weight in category | Weight in overall |
| ------ | ------------------ | ----------------- |
| [Security posture](/wiki/security-posture) | 80% | 12.8% |
| [Dependency advisories](/wiki/dependency-advisories) | 20% | 3.2% |
| [Malicious dependencies](/wiki/malicious-dependencies) | red flag | multiplier and ceiling on posture |
| [High-Risk Jurisdiction Exposure](/wiki/jurisdiction-exposure) | red flag | multiplier and ceiling on posture |

[Dependency advisories](/wiki/dependency-advisories) sits at 20% rather than
higher because well-run projects genuinely do not ship known-vulnerable
dependencies: the metric is near-constant across the record, and a signal that
rarely varies must not outweigh the one that does. Where the dependency graph
or the advisory lookup is unavailable, the metric is excluded and posture
carries the category alone — a repository is never penalized for the gap.

Only the strictest red flag that fires governs the result; since methodology
v1.13.0 the policies no longer compound. A dependency reported as
[malicious](/wiki/malicious-dependencies) is scored apart from ordinary
advisories, because it is a confirmed compromise rather than an exposure to
risk.

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](/wiki/jurisdiction-exposure).

[Security posture](/wiki/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](/wiki/security-posture) and
[methodology versions](/wiki/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](/wiki/methodology-versions), 0.6.0).

## Reading the category value

<div class="md-callout warn"><span class="md-callout-icon">△</span><div><b>A security value is not a security guarantee.</b> It reflects visible hygiene — it cannot rule out an undiscovered vulnerability, a malicious release, or a compromised account. See <a href="/wiki/signals-not-warranties">signals, not warranties</a>.</div></div>

- 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.md` with 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](/wiki/security-posture) ·
[dependency advisories](/wiki/dependency-advisories) ·
[malicious dependencies](/wiki/malicious-dependencies) ·
[high-risk jurisdiction exposure](/wiki/jurisdiction-exposure) ·
[the health index](/wiki/health-index)