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 (
ProjectGroupmodel).MCP (
lynk-mcp) — read-only queries for listing and inspecting Products.
Product Lifecycle
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
Navigate to the Products page.
Click the + (Add Product) button in the top right.
Enter the Name (required) and optional Description.
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:
To list existing Products:
--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
Via MCP
The lynk-mcp server provides read-only access to Products:
Disabling and Deleting Products
Disabling a Product
Navigate to the Products page.
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.
Deleting a Product
Navigate to the Products page.
Click the ... (Actions) on the Product row and select Delete Product.
Type
DELETEin 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.
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:
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
Creating Rules Manually
Navigate to the Products page and click the Product Name.
Select the target Environment.
Click the Automation Rules tab.
Click + (Add Rule).
Enter a Rule Name.
Select conditions to match — once the first condition is specified, additional conditions apply to the same subject.
Add actions — actions only apply to subjects matching the conditions.
Click Create.
Creating Rules from Checks
When an SBOM fails a check, you can create a rule directly from the check result:
Navigate to the Product and select a Version.
Click the Checks tab.
Click the Fix icon under Resolution.
Configure the fix.
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:
Navigate to the Automation Rules tab.
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
Navigate to the Automation Rules tab.
Click the ... (Actions) on the rule.
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
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
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
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
Environment Defaults
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
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
Navigate to the Product and select the target Environment.
Click the Settings tab.
Use the left-hand navigation to reach a section, then toggle settings or pick values.
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:
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
Navigate to the Products page.
Click the Manage Labels icon in the top right.
Create a Label:
Enter a Name for the label.
Type a color hex code or click the auto-shuffle icon for random colors.
Preview the label in the Label Preview badge.
Click + Add Label.
Edit a Label:
Click the Edit icon next to the label.
Modify the name or color.
Click the Accept or Cancel icon.
Delete a Label:
Remove the label from all Products it is applied to first.
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:
Navigate to the Products page.
Click ... (Edit Labels) on the Product row.
Select labels from the checkbox list.
Click outside the submenu to apply.
From a Product's details page:
Open the Product.
Open the ... (Actions) menu.
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.
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
Navigate to the Products page.
Open the ... (Actions) menu on the Product row.
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
In the Pinned strip, click Manage.
Click the remove icon on the entry you want to unpin.
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
Navigate to the Product and select a Version.
Click the Change Log tab.
The Change Log displays:
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
Navigate to the Product Environment page.
Click the Bell icon.
Select notification categories: Vulnerabilities, Licenses, Policies, or All.
Notifications are delivered based on configured integrations — Slack, Microsoft Teams, or Email.
Permission Matrix
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
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-nameororg/repo-nameso Products are easily identifiable and sortable.Use labels for cross-cutting categorization. Labels like
compliance:fda,team:platform,tier:criticalallow 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.
Last updated