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.

Deleting a Product removes all associated data permanently. Disable Products instead if you need to preserve historical data for audit purposes.

---

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:

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

To list existing Products:

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

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

Product creation via MCP is not supported. Use the Dashboard, API, or CLI to create Products.

---

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.

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.

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. You can create additional environments to match your deployment topology (e.g., staging, qa).

For full details on environment configuration, see Core Concepts: Environments and Administration: Environment Rules.

---

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

Automation Rules are configured per Environment. Rules can be copied from one Environment to another.

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.

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.

Disabling automation in Settings is per-Environment. To disable automation across all Environments, repeat for each one.

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

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.

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.

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.

---

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.

---

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.

Labels must be removed from all Products before they can be deleted.

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.

Assigning labels requires the Update Products permission. The action is not available on the free tier or through a share link.

---

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, Microsoft Teams, or Email.

At least one integration must be configured in Settings > Organization > Integrations > Connections before notifications become effective.

---

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.

---

Security Warnings

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.

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.

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

---

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.