> For the complete documentation index, see [llms.txt](https://docs.interlynk.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.interlynk.io/product-guides/security-and-compliance/support.md).

# 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](/administration/health-scoring.md)).
* **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 and click **Set Status**.
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.

### Setting the Status for Several Components

1. Navigate to the Version's **Support** tab.
2. Select the rows you want to update using the row checkboxes.
3. A **Set Support Status** action appears at the bottom of the table. Click it.
4. Set the support level and any dates, then save.

The selection is cleared once the update is applied, and also when you search, change a filter, or run any other row action, so a stale selection cannot be carried into the next update.

Bulk updates require the Edit Support Levels permission. They are unavailable on archived SBOMs and in the customer share view.

***

## Third-Party Support Status

For third-party components, you can record how the dependency is maintained by its supplier — independent of the platform's automated maintenance assessment.

### Setting Third-Party Support Status

1. Navigate to the Version's **Support** tab.
2. Select a third-party component and click **Set Status**.
3. Choose the **third-party support status**.
4. Optionally add a **supplier description** describing how the supplier maintains the component.
5. Save.

The supplier description is preserved across re-imports, is included in the support-level **CSV export**, and is exported and imported in **CycloneDX**.

### Support Confidence & Assessment Cards

The **Support Status** tab surfaces assessment and summary cards for the SBOM:

* **Support-level confidence** is scored against the **SBOM scope** — the cards reflect how much of the SBOM the recorded status actually covers, so a status set on a handful of components does not read as full coverage.
* **Product Support Status** assessment cards summarize the distribution of support levels across the SBOM.

Third-party support counts are also surfaced in the **product overview** and the **SBOM PDF**, and a support explanation is added to **CycloneDX exports**.

***

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

The support status CSV export includes components contributed by the Version's referenced Parts, so parts-supplied components appear in the export alongside the Version's own components.

***

## 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](/administration/health-scoring.md).

***

## 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](/product-guides/security-and-compliance/policies.md).

***

## 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](/administration/role-management.md).

***

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