# Health Scoring

Interlynk calculates a health score (0–100) for each component in your SBOMs based on three weighted factors: **age**, **community**, and **security**. Administrators can customize the weights and thresholds to align scoring with their organization's risk tolerance.

{% hint style="info" %}
Health score customization is available on the Enterprise tier.
{% endhint %}

***

## How Health Scores Work

The health score evaluates component risk across three dimensions:

| Factor        | What It Measures                                                                                     | Default Weight |
| ------------- | ---------------------------------------------------------------------------------------------------- | -------------- |
| **Age**       | How recently the component was updated, whether the package or repository shows signs of abandonment | 30%            |
| **Community** | Number of active contributors to the component's repository                                          | 30%            |
| **Security**  | OpenSSF Scorecard results, known vulnerabilities, support status (EOL, deprecated)                   | 40%            |

The final score is a weighted combination: `score = (age_score × age_weight) + (community_score × community_weight) + (security_score × security_weight)`

### Scoring Factors in Detail

**Age Score** considers:

* Days since the last package version was published
* Days since the last repository commit
* Whether the package version is archived or pre-release

**Community Score** considers:

* Number of contributors to the repository
* Whether the contributor count falls below the minimum threshold (weak community) or exceeds the maximum threshold (strong community)

**Security Score** considers:

* OpenSSF Scorecard score (if available)
* Whether the repository is archived
* Support status: end-of-support (EOS), end-of-life (EOL), deprecated
* Package-level deprecation or outdated status

### Non-Identifiable Components

Components without a package URL (purl) or repository URL receive a reduced score because they cannot be enriched with package manager or repository metadata.

***

## Customizing Health Score

### Accessing the Configuration

1. Navigate to **Settings > Organization > Health** tab.
2. The configuration page displays three sections: **Relative Weights**, **Age Score**, and **Community Score**.

### Relative Weights

Adjust the percentage contribution of each factor to the overall health score. The three weights must sum to exactly **100%**.

| Field                | Description                    | Default | Range |
| -------------------- | ------------------------------ | ------- | ----- |
| Age Weight (%)       | Weight of the age factor       | 30      | 0–100 |
| Community Weight (%) | Weight of the community factor | 30      | 0–100 |
| Security Weight (%)  | Weight of the security factor  | 40      | 0–100 |

Example configurations:

| Profile             | Age | Community | Security | Use Case                                                     |
| ------------------- | --- | --------- | -------- | ------------------------------------------------------------ |
| Default             | 30% | 30%       | 40%      | Balanced assessment                                          |
| Security-first      | 10% | 10%       | 80%      | Organizations prioritizing vulnerability exposure            |
| Maintenance-focused | 50% | 30%       | 20%      | Organizations concerned about abandoned dependencies         |
| Community-driven    | 20% | 50%       | 30%      | Open-source-heavy stacks where community health matters most |

### Age Score Thresholds

Configure how long a component can be inactive before it is considered unmaintained.

| Field                                         | Description                                     | Default  | Range        |
| --------------------------------------------- | ----------------------------------------------- | -------- | ------------ |
| Mark Repository Unmaintained After Inactivity | Days of repository inactivity before flagging   | 365 days | 1–3,650 days |
| Mark Package Unmaintained After Inactivity    | Days since last package release before flagging | 365 days | 1–3,650 days |

Lower values are stricter — components will be flagged sooner. Higher values are more lenient.

### Community Score Thresholds

Configure the contributor count range that defines community health using a range slider.

| Field                | Description                                          | Default | Range |
| -------------------- | ---------------------------------------------------- | ------- | ----- |
| Minimum Contributors | Below this count, the community is considered weak   | 5       | 0–100 |
| Maximum Contributors | Above this count, the community is considered strong | 20      | 0–100 |

Components with contributor counts between the minimum and maximum receive a proportional score. Below the minimum scores poorly; above the maximum scores well.

### Saving Changes

1. Adjust the weights and thresholds.
2. Click **Update**.
3. Health scores are recalculated for all components across the organization in the background.

{% hint style="info" %}
Recalculation runs as a background job. Updated scores will appear on dashboards within a few minutes depending on the number of components.
{% endhint %}

***

## Impact on Dashboards

Health scores are displayed throughout the platform:

* **Component details**: Individual component health score with a breakdown showing age, community, and security sub-scores.
* **Product dashboards**: Aggregated health score distributions.
* **SBOM views**: Component-level health indicators.
* **Policy rules**: Health scores can be used as conditions in policy rules (e.g., fail if any component has a health score below 30).

The health score is visualized as a gradient bar (red to green) with a tooltip breakdown showing the contribution of each factor.

***

## Best Practice Scoring Models

### Recommended Starting Configuration

Start with the default weights (30/30/40) and adjust based on the types of issues your organization encounters most frequently.

### When to Adjust Weights

| Scenario                                      | Recommended Adjustment                                                  |
| --------------------------------------------- | ----------------------------------------------------------------------- |
| Frequent incidents from outdated dependencies | Increase Age Weight to 50%                                              |
| Using many small/single-maintainer libraries  | Increase Community Weight to 40-50%                                     |
| Compliance-driven organization                | Increase Security Weight to 60-80%                                      |
| Internal/proprietary components dominate      | Lower Community Weight (internal repos have few contributors by design) |

### Threshold Guidance

| Environment           | Repository Inactivity | Package Inactivity | Min Contributors |
| --------------------- | --------------------- | ------------------ | ---------------- |
| Strict (regulated)    | 180 days              | 180 days           | 10               |
| Moderate              | 365 days (default)    | 365 days           | 5                |
| Lenient (early stage) | 730 days              | 730 days           | 2                |

***

## Governance Recommendations

* **Establish baseline scores** before customizing weights. Review the current distribution of scores to understand the impact of changes.
* **Communicate changes** to your team when adjusting weights — score changes affect dashboards and may trigger policy violations.
* **Use policies** to enforce minimum health score thresholds (e.g., block releases if any critical component scores below 40).
* **Review quarterly**: Revisit your weight configuration as your tech stack and risk profile evolve.

***

## Common Misconfigurations

| Issue                                 | Symptom                                          | Fix                                                      |
| ------------------------------------- | ------------------------------------------------ | -------------------------------------------------------- |
| Weights do not sum to 100%            | Update button disabled, validation error shown   | Adjust weights to total exactly 100                      |
| Age threshold too low (e.g., 30 days) | Most components flagged as unmaintained          | Increase to 180+ days for realistic results              |
| Community min set to 0                | All components pass community threshold          | Set minimum to at least 2–5                              |
| Security weight set to 0%             | Vulnerable components receive high health scores | Security weight should be at least 20%                   |
| All weights equal (33/33/34)          | No factor differentiated                         | Prioritize the factor most relevant to your risk profile |


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.interlynk.io/administration/health-scoring.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.