# Component Support

Component support tracking monitors the maintenance status of third-party components in your SBOMs. Interlynk identifies abandoned, deprecated, and end-of-life components so your organization can proactively manage supply chain risk before unmaintained dependencies become security liabilities.

***

## Overview

When **Run Component Support Analysis** is enabled in Environment Settings, the platform evaluates each component in an uploaded SBOM and assigns a support level based on package registry data, repository activity, and ecosystem signals.

Support tracking helps answer:

* Which components in my portfolio are no longer maintained?
* Are any components approaching end-of-life or end-of-support?
* Which Products have the highest concentration of unsupported dependencies?

## Architecture

```
SBOM Upload
  └── Component Extraction
        └── Support Analysis Pipeline
              ├── Package Registry Lookup
              │     ├── Deprecation status
              │     ├── Archive status
              │     └── Last publish date
              ├── Repository Analysis
              │     ├── Last commit date
              │     ├── Contributor activity
              │     └── Archive status
              └── Support Level Assignment
                    ├── Actively Maintained
                    ├── No Longer Maintained
                    ├── Abandoned
                    └── Unspecified
```

**Integration points:**

* **Health Scoring** — support status is a factor in the security dimension of the health score (see [Health Scoring](https://docs.interlynk.io/administration/health-scoring)).
* **Policies** — policy rules can trigger on component support levels (e.g., fail if abandoned components are present).
* **SBOM Downloads** — support status data can be included in downloaded SBOMs.

***

## Support Levels

| Level                    | Description                                                      | Typical Signals                                                                           |
| ------------------------ | ---------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| **Actively Maintained**  | Component is actively developed and receives updates             | Recent commits, recent package releases, active contributor base                          |
| **No Longer Maintained** | Component has stopped receiving updates but is not yet abandoned | No recent releases, repository still accessible, maintainer has signaled reduced activity |
| **Abandoned**            | Component is no longer maintained or supported                   | Repository archived, package deprecated in registry, no activity for extended period      |
| **Unspecified**          | Support status could not be determined                           | Missing PURL, no package registry match, insufficient signals                             |

***

## Viewing Support Status

### Version-Level View

1. Navigate to the Product and select a Version.
2. Click the **Support** tab.
3. The support view displays each component with:

| Column                  | Description                                            |
| ----------------------- | ------------------------------------------------------ |
| **Component**           | Component name and version                             |
| **Support Level**       | Current support status                                 |
| **End-of-Support Date** | Date when support ends (if known)                      |
| **End-of-Life Date**    | Date when the component reaches end of life (if known) |
| **Last Updated**        | When the support data was last refreshed               |

### Filtering by Support Level

Use filters to focus on components that need attention:

* **Abandoned** — highest priority; these components receive no security patches.
* **No Longer Maintained** — medium priority; may still be functional but risk is increasing.
* **Unspecified** — investigate to determine actual status.

***

## Support Overrides

When the platform's automated assessment is incorrect or your organization has internal knowledge about a component's support status, you can override the assigned level.

### Setting an Override

1. Navigate to the Version's **Support** tab.
2. Select a component.
3. Change the support level to the correct value.
4. Optionally set end-of-support or end-of-life dates.
5. Save.

Overrides apply to the specific component and persist across SBOM re-uploads for the same component identifier.

***

## Support Status in Downloads

Include support status data in SBOM downloads:

### Via CLI

```bash
# Download SBOM with support status metadata
pylynk download --prod "my-backend-service" --env "production" --ver "v1.2.0" \
  --out-file sbom-with-support.json \
  --include-support-status

# Export support levels only as CSV
pylynk download --prod "my-backend-service" --env "production" --ver "v1.2.0" \
  --support-level-only --out-file support-report.csv
```

| Parameter                  | Description                                                                    |
| -------------------------- | ------------------------------------------------------------------------------ |
| `--include-support-status` | Embed support level metadata in the downloaded SBOM                            |
| `--support-level-only`     | Export only support level data as CSV (component name, version, support level) |

### Via Dashboard

When downloading an SBOM from the Dashboard, the support status data is included in the enhanced (non-original) SBOM download.

***

## Health Score Integration

Support status directly influences the **security** dimension of the component health score:

| Support Status                | Health Score Impact                   |
| ----------------------------- | ------------------------------------- |
| Actively Maintained           | No penalty                            |
| No Longer Maintained          | Moderate penalty to security score    |
| Abandoned                     | Significant penalty to security score |
| Deprecated (package registry) | Penalty to security score             |
| End-of-Life reached           | Significant penalty to security score |

Health score weights and thresholds can be customized in [Administration: Health Scoring](https://docs.interlynk.io/administration/health-scoring).

***

## Policy Integration

Create policy rules that evaluate component support status:

| Policy Purpose                  | Subject       | Operator   | Value                |
| ------------------------------- | ------------- | ---------- | -------------------- |
| Block abandoned components      | Support Level | IS         | Abandoned            |
| Warn on unmaintained components | Support Level | IS         | No Longer Maintained |
| Enforce minimum health score    | Health Score  | LESS\_THAN | 30                   |

For policy configuration, see [Policies](https://docs.interlynk.io/product-guides/security-and-compliance/policies).

***

## Permission Matrix

| Permission            | Admin | Operator | Viewer |
| --------------------- | :---: | :------: | :----: |
| View support          |   ✓   |     ✓    |    ✓   |
| Edit support          |   ✓   |     ✓    |    —   |
| Delete support        |   ✓   |     ✓    |    —   |
| View support levels   |   ✓   |     ✓    |    ✓   |
| Edit support levels   |   ✓   |     ✓    |    —   |
| Delete support levels |   ✓   |     ✓    |    —   |

For full permission details, see [Role Management](https://docs.interlynk.io/administration/role-management).

***

## Security Warnings

{% hint style="warning" %}
**Abandoned components receive no security patches.** Vulnerabilities discovered in abandoned components cannot be fixed upstream. Plan migration to actively maintained alternatives for all abandoned dependencies.
{% endhint %}

{% hint style="warning" %}
**Components without PURL identifiers cannot be analyzed for support status.** These will be marked as "Unspecified" and represent unknown risk. Ensure SBOM generation tools produce PURL identifiers for accurate support analysis.
{% endhint %}

{% hint style="warning" %}
**End-of-life dates may not be publicly documented.** The platform relies on signals from package registries and repositories. Supplement automated analysis with your own knowledge of component lifecycles.
{% endhint %}

***

## Common Misconfigurations

| Issue                                       | Symptom                                      | Fix                                                                               |
| ------------------------------------------- | -------------------------------------------- | --------------------------------------------------------------------------------- |
| Support analysis disabled                   | Support tab shows no data                    | Enable "Run Component Support Analysis" in Environment Settings                   |
| Components show "Unspecified"               | Unable to determine support status           | Verify SBOM includes PURL identifiers; components without PURL cannot be analyzed |
| Overrides not persisting                    | Support level resets on re-upload            | Verify the override was applied to the correct component identifier               |
| Health scores not reflecting support status | Abandoned components show high health scores | Verify security weight is not set to 0% in Health Scoring configuration           |
| No policy enforcement on support levels     | Abandoned components not flagged             | Create a policy rule targeting abandoned or unmaintained support levels           |

***

## Recommended Best Practices

* **Enable component support analysis by default** in Environment Settings to surface maintenance risks early.
* **Create policies that block abandoned components** in production Environments to enforce supply chain hygiene.
* **Monitor "No Longer Maintained" components proactively.** These are on a path to abandonment — plan migrations before they become critical.
* **Review support status quarterly.** Component maintenance status changes over time; what was actively maintained last quarter may be abandoned now.
* **Use support status CSV exports** for reporting to management on supply chain health.
* **Supplement automated analysis with internal knowledge.** If you know a component is internally maintained or has a private support contract, apply overrides.
* **Combine support status with vulnerability data** for risk prioritization — a vulnerable abandoned component has no path to a fix and should be replaced.
* **Include support status in SBOM exports** when distributing SBOMs to customers or regulators to demonstrate supply chain awareness.