Products

Definition

A Product represents a software artifact that your organization builds, releases, and versions. It is the top-level grouping for all SBOM data within the platform.

A Product may represent:

• A web application or API service

• A library or SDK

• A firmware image

• A container image

• A hardware appliance with embedded software

Products provide logical isolation — each Product has its own set of Environments, Versions, policies, automation rules, and settings.

Multi-Tenant Isolation

Products are scoped to your organization. No data from one organization's Products is visible to another organization. Within an organization, access to Products is governed by role-based permissions.

When to Create a New Product

Scenario	Recommendation
Monolithic application	One Product
Microservices (independently versioned)	One Product per service
Microservices (released as a unit)	One Product, use Parts to compose sub-SBOMs
Internal tool vs. customer-facing app	Separate Products — different compliance requirements
Mobile app + backend API	Separate Products — different build pipelines and release cadences
Same codebase, multiple build targets	One Product with multiple Environments, or separate Products if compliance requirements differ

Compliance boundaries matter. If two artifacts have different regulatory requirements (e.g., one is FDA-regulated and one is not), create separate Products so that policies and compliance checks can be scoped independently.

Managing Products

Creating via UI

1. Navigate to the Products page.

2. Click the + (Add Product) button.

3. Enter the Name (required) and optional Description.

4. Click Save.

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

Creating 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"
      }
    }
  }'

Creating via CLI

The pylynk CLI does not have an explicit create product command. Products are created 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

Creating via MCP

When using the lynk-mcp server with an AI assistant, Products can be discovered and queried:

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

The MCP server provides read-only access to Products. Product creation is done via the UI, API, or CLI.

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.
Marked for Deletion	Scheduled for permanent removal. All associated Environments, Versions, Components, and Vulnerabilities will be deleted.

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

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 (e.g., compliance:fda, team:platform, tier:critical) allow filtering and grouping across Products 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.

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 --prod value in pipeline configuration
Product disabled accidentally	SBOM uploads rejected with no clear error	Re-enable the Product from the Products page
No description set	Products are hard to distinguish in large organizations	Add descriptions during creation or via the edit action