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.

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.

Import Actions

Setting	Description
Run SBOM Checks	Execute quality and compliance checks on uploaded SBOMs
Always Use Latest Parts	Keep component information updated with latest available data
Run Internal Labeling	Identify and label internal components
Run Auto Archive	Automatically archive old SBOM versions
Apply Automation Rules	Execute configured automation rules on upload
Run Vulnerability Scan	Scan components for known vulnerabilities
Run Component Support Analysis	Evaluate component support status (EOL, deprecated, maintained)
Retain Vulnerability Status with Version	Preserve VEX status when a new SBOM version is uploaded
Interpret License List as "AND" expression	Treat multi-license declarations as requiring all listed licenses
Copy VEX Across Versions on Import	Carry forward VEX dispositions from previous versions to new imports
Enable PR Comments	Post SBOM analysis results as comments on pull requests

Data Retention

Setting	Options	Default
Data Retention	1, 30, 90, 365 days, or Forever (0)	Forever (0)

Configuring Settings

1. Navigate to the Product and select the target Environment.

2. Click the Settings tab.

3. Toggle the desired import actions on or off.

4. Select a data retention period.

5. Changes are saved automatically.

---

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

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.

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

---

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