# 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 |