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.
Health score customization is available on the Enterprise tier.
How Health Scores Work
The health score evaluates component risk across three dimensions:
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
Navigate to Settings > Organization > Health tab.
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%.
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:
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.
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.
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
Adjust the weights and thresholds.
Click Update.
Health scores are recalculated for all components across the organization in the background.
Recalculation runs as a background job. Updated scores will appear on dashboards within a few minutes depending on the number of components.
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
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
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
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
Last updated