> 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/sbom-management/products.md).

# Products

Products are the top-level organizational unit in Interlynk. Each Product represents a software artifact your organization builds, releases, and tracks — such as a web application, library, firmware image, or container. All SBOM data, vulnerability tracking, policy evaluation, and compliance reporting is scoped to a Product and its Environments.

***

## Overview

A Product groups all SBOM versions, vulnerability data, policies, and automation rules for a single software artifact. Products provide logical isolation — each has its own Environments, settings, labels, and notification subscriptions.

Products support:

* **Environments** — isolated contexts (e.g., Development, Production) with independent settings, automation rules, and policies.
* **Automation Rules** — conditional actions that modify SBOMs on import (e.g., set missing supplier fields, apply license expressions).
* **Labels** — color-coded tags for cross-cutting categorization (e.g., `compliance:fda`, `team:platform`).
* **Notifications** — per-environment subscriptions for vulnerability, license, and policy changes.
* **Settings** — per-environment controls for scanning, data retention, and integrations.

## Architecture

```
Organization
  └── Product (ProjectGroup)
        ├── Environment: Default
        │     ├── Versions (SBOMs)
        │     ├── Automation Rules
        │     ├── Settings (scan, retention, VEX)
        │     └── Policies
        ├── Environment: Development
        │     └── ...
        ├── Environment: Production
        │     └── ...
        ├── Labels
        ├── Notifications
        └── Change Log (Activity Audit)
```

**Interactions:**

* **Dashboard** — create, configure, disable, and delete Products.
* **CLI** (`pylynk prods`) — list Products, upload SBOMs (auto-creates Products).
* **API** — GraphQL mutations for creating, updating, and deleting Products (`ProjectGroup` model).
* **MCP** (`lynk-mcp`) — read-only queries for listing and inspecting Products.

***

## Product Lifecycle

| State        | Behavior                                                                                                                                                                  |
| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Active**   | Accepts SBOM uploads, vulnerability scanning runs, contributes to metrics and analytics.                                                                                  |
| **Disabled** | Stops accepting new Versions and SBOMs. Vulnerability updates halt. Excluded from platform metrics and analytics. Existing data remains accessible for historical review. |
| **Deleted**  | Permanently removed. All associated Environments, Versions, Components, and Vulnerabilities are deleted.                                                                  |

A disabled Product can be re-enabled. Deletion is irreversible.

{% hint style="warning" %}
Deleting a Product removes all associated data permanently. Disable Products instead if you need to preserve historical data for audit purposes.
{% endhint %}

***

## Creating Products

### Via Dashboard

1. Navigate to the **Products** page.
2. Click the **+** (Add Product) button in the top right.
3. Enter the **Name** (required) and optional **Description**.
4. Click **Save**.

The Product is created with three default Environments: Default, Development, and Production.

### Via CLI

The `pylynk` CLI creates Products implicitly on first SBOM upload if they do not already exist:

```bash
pylynk upload --prod "my-backend-service" --sbom sbom.cdx.json
```

To list existing Products:

```bash
pylynk prods
pylynk prods --output json
pylynk prods --output csv
```

| Parameter         | Required | Default                     | Description                                 |
| ----------------- | -------- | --------------------------- | ------------------------------------------- |
| `--output`        | No       | `table`                     | Output format: `table`, `json`, `csv`       |
| `--human-time`    | No       | Off                         | Display timestamps in human-readable format |
| `--token`         | No       | `$INTERLYNK_SECURITY_TOKEN` | Override authentication token               |
| `-v`, `--verbose` | No       | Off                         | Enable verbose output                       |

### Via API

```bash
curl -X POST https://api.interlynk.io/lynkapi \
  -H "Authorization: Bearer $INTERLYNK_SECURITY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "mutation CreateProduct($input: CreateProjectGroupInput!) { createProjectGroup(input: $input) { projectGroup { id name } errors } }",
    "variables": {
      "input": {
        "name": "my-backend-service",
        "description": "Core backend API service"
      }
    }
  }'
```

### Via MCP

The `lynk-mcp` server provides read-only access to Products:

```
list_products          # List all products
get_product            # Get product details with all environments
```

{% hint style="info" %}
Product creation via MCP is not supported. Use the Dashboard, API, or CLI to create Products.
{% endhint %}

***

## Disabling and Deleting Products

### Disabling a Product

1. Navigate to the **Products** page.
2. Click the **Active** toggle switch on the Product row to disable it.

A disabled Product:

* Stops accepting version creation and SBOM uploads.
* Stops updating vulnerabilities for existing versions.
* Does not contribute to platform metrics and analytics.
* Can be re-enabled at any time.

{% hint style="info" %}
If a disabled Product is not visible in the list, check the **Active** filter at the top of the Products table — it defaults to showing only active Products.
{% endhint %}

### Deleting a Product

1. Navigate to the **Products** page.
2. Click the **...** (Actions) on the Product row and select **Delete Product**.
3. Type `DELETE` in the confirmation modal and click **Yes**.

Alternatively, from inside the Product Environment page, click the **Delete Product** icon.

***

## Environments

Each Product is created with three default Environments: **Default**, **Development**, and **Production**. Environments provide isolated contexts within a Product — each has its own versions, automation rules, settings, and policies.

| Environment     | Typical Use                                                       |
| --------------- | ----------------------------------------------------------------- |
| **Default**     | Catch-all for SBOMs that do not match a specific environment rule |
| **Development** | Feature branches, development builds, pre-release testing         |
| **Production**  | Main/master branch, release tags, production deployments          |

Environments are mapped to incoming SBOMs via [Environment Rules](/administration/environment-rules.md). You can create additional environments to match your deployment topology (e.g., `staging`, `qa`).

For full details on environment configuration, see [Core Concepts: Environments](/interlynk-core-concepts/environments.md) and [Administration: Environment Rules](/administration/environment-rules.md).

***

## Automation Rules

Automation Rules modify SBOMs automatically on import, reducing manual toil for recurring quality and compliance fixes. Rules consist of a **name**, a set of **conditions** to match, and **actions** to take when conditions are met.

### Rule Structure

Rules apply to one of two subject types:

| Subject       | Description                                               | Example                                                                                      |
| ------------- | --------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| **Version**   | Conditions and actions target version-level SBOM metadata | Set the Supplier Contact Name when it is missing                                             |
| **Component** | Conditions and actions target a specific component        | Set license expression to `Apache-2.0` when Component Name is `log4j` and license is missing |

{% hint style="info" %}
Automation Rules are configured per Environment. Rules can be copied from one Environment to another.
{% endhint %}

### Creating Rules Manually

1. Navigate to the **Products** page and click the Product Name.
2. Select the target Environment.
3. Click the **Automation Rules** tab.
4. Click **+** (Add Rule).
5. Enter a **Rule Name**.
6. Select conditions to match — once the first condition is specified, additional conditions apply to the same subject.
7. Add actions — actions only apply to subjects matching the conditions.
8. Click **Create**.

### Creating Rules from Checks

When an SBOM fails a check, you can create a rule directly from the check result:

1. Navigate to the Product and select a Version.
2. Click the **Checks** tab.
3. Click the **Fix** icon under Resolution.
4. Configure the fix.
5. Click **Save as Rule** to create an Automation Rule.

The same drawer can also fix the check on this SBOM alone: **Save** applies the correction to the current Version, while **Save as Rule** turns it into an Automation Rule that applies to future uploads. Use the rule when the same gap recurs across builds, and the direct save for a one-off correction. See [Fixing a Failed Check](/product-guides/sbom-management/versions.md#fixing-a-failed-check).

### Rule Priority and Ordering

Rules are evaluated in order. To reorder:

1. Navigate to the **Automation Rules** tab.
2. Use the drag handle on each rule to reorder.

Rules with higher position (lower in the list) execute last and can override earlier rules.

### Copying Rules Between Environments

1. Navigate to the **Automation Rules** tab.
2. Click the **...** (Actions) on the rule.
3. Select **Copy To \[Environment Name]**.

### Disabling Rules

* **Individual rule**: Toggle the **Active** switch on the rule row.
* **All automation for an environment**: Navigate to the **Settings** tab and toggle the **Automation** switch off.

{% hint style="warning" %}
Disabling automation in Settings is per-Environment. To disable automation across all Environments, repeat for each one.
{% endhint %}

### Rules Library

The platform ships with a library of common rules (e.g., copying Author Name to Supplier Name). These rules are disabled by default and can be enabled as needed.

### Applying Rules

* **Automatic**: Rules are applied on every SBOM import. Changes are logged in the SBOM's Change Log.
* **Manual**: Navigate to the Product Environment page, click **...** (Actions) on a Version, and select **Run Automation**.

***

## Product Settings

Each Environment within a Product has its own settings that control scanning behavior, data retention, and integration features. Settings are inherited from [Organization Environment Defaults](/administration/environment-defaults.md) at creation time and can be customized per Environment.

The Settings tab has a left-hand navigation with two pages: **Import & defaults**, and **Issue trackers** for the defaults applied to tickets Interlynk creates. Each entry under a page jumps to that section, so nothing is more than one click away.

### Import Behavior

| Setting                                      | Description                                                                      |
| -------------------------------------------- | -------------------------------------------------------------------------------- |
| **Use latest versions of referenced parts**  | When a version depends on another part, use the most recent version of that part |
| **Mark internal components on import**       | Mark detected internal components as the SBOM is imported                        |
| **Run environment automation rules**         | Apply this Environment's automation rules after each SBOM import                 |
| **Treat license lists as "AND" expressions** | Combine listed licenses with AND instead of the default OR SPDX expression       |

### Automated Analysis

| Setting                                    | Description                                                                                                                                                                                                                  |
| ------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Run SBOM checks after import**           | Find issues in imported SBOMs as part of the import workflow                                                                                                                                                                 |
| **Scan for vulnerabilities after import**  | Automatically scan imported components for known vulnerabilities                                                                                                                                                             |
| **Overwrite Existing VEX Dispositions**    | Allow imported VEX data to replace existing dispositions when there is a conflict. See [Importing Third-Party VEX Documents](/product-guides/security-and-compliance/vulnerabilities.md#importing-third-party-vex-documents) |
| **Analyze component support after import** | Automatically determine component support status                                                                                                                                                                             |

### Version Lifecycle

| Setting                                                     | Description                                                                                                                                                                                  |
| ----------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Archive older versions after import**                     | Archive every enabled version except the latest uploaded version. Confirmation is required                                                                                                   |
| **Preserve vulnerability status on same-version re-import** | Keep existing vulnerability decisions when a pipeline uploads the same product version again                                                                                                 |
| **Carry VEX forward to the latest version**                 | Copy existing VEX information when a new version is imported                                                                                                                                 |
| **Reuse Jira tickets for matching vulnerabilities**         | Link existing Jira tickets when the same vulnerability appears in another SBOM version                                                                                                       |
| **Reuse Jira tickets across environments**                  | Reuse existing Jira tickets for matching vulnerabilities in other Environments of this Product when the Jira project matches. See [Jira: Ticket Reuse](/administration/jira.md#ticket-reuse) |

{% hint style="info" %}
**Reuse Jira tickets across environments** is Product-wide, not per-Environment. Toggling it applies the same value to every Environment in the Product. If Environments currently disagree, the row says so, and toggling aligns them.
{% endhint %}

### Environment Defaults

| Setting                              | Options                                | Default |
| ------------------------------------ | -------------------------------------- | ------- |
| **Retain SBOM data for**             | 1, 30, 90, 365 days, or Forever        | Forever |
| **Default manufacturer for exports** | Any organization manufacturer          | Not set |
| **Default TLP classification**       | CLEAR, GREEN, AMBER, AMBER+STRICT, RED | Not set |

### Pull Request Integration

| Setting                          | Description                                      |
| -------------------------------- | ------------------------------------------------ |
| **Enable pull request comments** | Allow Interlynk to add comments to pull requests |

### SBOM Doctor Checks

When SBOM Doctor is enabled for the organization, this section controls which checks run for the Environment. See [SBOM Doctor](/product-guides/sbom-management/doctor.md).

### Configuring Settings

1. Navigate to the Product and select the target Environment.
2. Click the **Settings** tab.
3. Use the left-hand navigation to reach a section, then toggle settings or pick values.
4. Changes are saved automatically.

Editing these settings requires the **Edit product settings** permission. See [Role Management](/administration/role-management.md).

***

## Support Status

Support status tracking monitors the maintenance state of components within a Product's SBOMs. When **Run Component Support Analysis** is enabled in Settings, the platform evaluates each component and assigns a support level:

| Support Level            | Description                                                      |
| ------------------------ | ---------------------------------------------------------------- |
| **Actively Maintained**  | Component is actively developed and receives updates             |
| **No Longer Maintained** | Component has stopped receiving updates but is not yet abandoned |
| **Abandoned**            | Component is no longer maintained or supported                   |
| **Unspecified**          | Support status could not be determined                           |

Support status data is visible on the Version detail page under the **Support** tab and can be included in downloaded SBOMs using the `--include-support-status` flag.

For support level overrides and organization-wide support management, see [Administration: Health Scoring](/administration/health-scoring.md).

***

## Labels

Labels are color-coded tags applied to Products for cross-cutting categorization and filtering. Use labels to group Products by team, compliance requirement, tier, or any other dimension.

### Managing Labels

1. Navigate to the **Products** page.
2. Click the **Manage Labels** icon in the top right.

**Create a Label:**

1. Enter a **Name** for the label.
2. Type a color hex code or click the auto-shuffle icon for random colors.
3. Preview the label in the **Label Preview** badge.
4. Click **+ Add Label**.

**Edit a Label:**

1. Click the **Edit** icon next to the label.
2. Modify the name or color.
3. Click the Accept or Cancel icon.

**Delete a Label:**

1. Remove the label from all Products it is applied to first.
2. Click the **Delete** icon next to the label.

{% hint style="warning" %}
Labels must be removed from all Products before they can be deleted.
{% endhint %}

### Applying Labels to Products

From the Products list:

1. Navigate to the **Products** page.
2. Click **...** (Edit Labels) on the Product row.
3. Select labels from the checkbox list.
4. Click outside the submenu to apply.

From a Product's details page:

1. Open the Product.
2. Open the **...** (Actions) menu.
3. Hover **Assign Labels** and select labels from the flyout.

Labels are visible on the Products list and can be used to filter and sort Products.

{% hint style="info" %}
Assigning labels requires the Update Products permission. The action is not available on the free tier or through a share link.
{% endhint %}

***

## Pinned Products

Pin up to 8 frequently accessed Products for one-click access. Pinned Products appear in a compact **Pinned** strip above the main Products table, one entry per product showing its name and environment tag.

A red dot on an entry means the latest SBOM has critical vulnerabilities. Hovering an entry opens a preview with the product's counts and status, plus a link to open it.

Pins are personal. Each user's pinned list is independent.

### Pinning a Product

1. Navigate to the **Products** page.
2. Open the **...** (Actions) menu on the Product row.
3. Select **Pin Product**.

The action is disabled once you have reached the 8-product limit. The pin counter next to the **Pinned** heading shows how many of the 8 you have used.

### Unpinning a Product

1. In the **Pinned** strip, click **Manage**.
2. Click the remove icon on the entry you want to unpin.
3. Click **Done**.

You can also unpin from the Products table through the row's **...** (Actions) menu.

***

## Change Log

The Change Log provides an audit trail of all modifications made to a Product's SBOMs. Every change resulting from automation rules, manual edits, or system processing is recorded.

### Viewing the Change Log

1. Navigate to the Product and select a Version.
2. Click the **Change Log** tab.

The Change Log displays:

| Column        | Description                                                   |
| ------------- | ------------------------------------------------------------- |
| **Timestamp** | When the change occurred                                      |
| **Action**    | What was changed (e.g., field update, component modification) |
| **Source**    | Whether the change was manual, automated, or system-generated |
| **Details**   | Specific values before and after the change                   |

***

## Notifications

Users can subscribe to notifications for changes within a Product's Environments. Notifications alert on vulnerability discoveries, license changes, and policy failures.

### Subscribing to Notifications

1. Navigate to the Product Environment page.
2. Click the **Bell** icon.
3. Select notification categories: **Vulnerabilities**, **Licenses**, **Policies**, or **All**.

Notifications are delivered based on configured integrations — [Slack](/administration/slack.md), [Microsoft Teams](/administration/microsoft-teams.md), or [Email](/administration/email.md).

{% hint style="info" %}
At least one integration must be configured in **Settings > Organization > Integrations > Connections** before notifications become effective.
{% endhint %}

***

## Permission Matrix

| Permission                | Admin | Operator | Viewer |
| ------------------------- | :---: | :------: | :----: |
| View products             |   ✓   |     ✓    |    ✓   |
| Create products           |   ✓   |     ✓    |    —   |
| Update products           |   ✓   |     ✓    |    —   |
| Delete products           |   ✓   |     ✓    |    —   |
| Edit share link           |   ✓   |     ✓    |    —   |
| Edit product automations  |   ✓   |     ✓    |    —   |
| Edit product policies     |   ✓   |     ✓    |    —   |
| Edit product integrations |   ✓   |     ✓    |    —   |
| Edit product settings     |   ✓   |     ✓    |    —   |

For full permission details, see [Role Management](/administration/role-management.md).

***

## Security Warnings

{% hint style="warning" %}
**Product deletion is irreversible.** All Environments, Versions, Components, Vulnerabilities, and audit history are permanently removed. Disable Products instead of deleting them if you need to preserve historical data.
{% endhint %}

{% hint style="warning" %}
**Automation rules execute on every import.** Misconfigured rules can silently modify SBOM data at scale. Test rules on a development environment before enabling them in production.
{% endhint %}

{% hint style="warning" %}
**"Apply to All Projects" overwrites per-project settings.** Use this action only when you intentionally want to standardize all projects. Per-project customizations will be lost.
{% endhint %}

***

## Common Misconfigurations

| Issue                                   | Symptom                                                   | Fix                                                                      |
| --------------------------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------ |
| Duplicate Products for the same service | Fragmented vulnerability data, inconsistent metrics       | Consolidate SBOMs under a single Product; delete the duplicate           |
| Product name mismatch in CI/CD          | New Products created unintentionally on each pipeline run | Standardize the `--prod` value in pipeline configuration                 |
| Product disabled accidentally           | SBOM uploads rejected with no clear error                 | Re-enable the Product from the Products page (check the Active filter)   |
| Automation rules not running            | SBOM data not modified on import                          | Check that **Apply Automation Rules** is enabled in Environment Settings |
| Rules configured in wrong Environment   | Automation applies to development but not production      | Copy rules to the correct Environment or configure per-environment rules |
| Notifications not delivered             | No alerts on vulnerability changes                        | Verify at least one integration (Slack, Teams, Email) is configured      |
| Vulnerability scanning disabled         | No vulnerability data after SBOM upload                   | Enable **Run Vulnerability Scan** in Environment Settings                |
| Labels not deletable                    | Delete action fails silently                              | Remove the label from all Products before deleting                       |

***

## Recommended Best Practices

* **Use consistent naming conventions.** Adopt a pattern such as `team-service-name` or `org/repo-name` so Products are easily identifiable and sortable.
* **Use labels for cross-cutting categorization.** Labels like `compliance:fda`, `team:platform`, `tier:critical` allow filtering and grouping without duplicating Product definitions.
* **Avoid creating duplicate Products.** If a Product already exists, upload SBOMs to it rather than creating a new one with a similar name.
* **Disable rather than delete.** If a Product reaches end-of-life, disable it to preserve historical data for audit purposes.
* **Scope Products to compliance boundaries.** Products with different regulatory requirements should be separate so that policies can be tailored independently.
* **Enable vulnerability scanning and SBOM checks by default** in Environment Settings — these are core value-add features.
* **Enable "Retain Vulnerability Status with Version"** to avoid re-triaging vulnerabilities when SBOMs are re-uploaded.
* **Test automation rules in development** before enabling them in production Environments.
* **Configure notifications early.** Subscribe to vulnerability and policy alerts in production Environments to catch issues promptly.
* **Review the Change Log regularly** to audit automated and manual modifications to SBOMs.