Environments

Definition

An Environment represents a deployment stage or context within a Product. Environments isolate Version history, settings, automation rules, and policy evaluation so that different stages of your software lifecycle can be managed independently.

Default Environments

Interlynk ships with three default Environments:

Environment	Purpose
Default	Catch-all for SBOMs uploaded without an explicit environment target.
Development	Feature branches, development builds, pre-merge artifacts.
Production	Release builds, production deployments, release-tagged artifacts.

Custom Environments are not supported. All Products use the same three default Environments.

Isolation Behavior

Each Environment within a Product is fully independent:

• Settings: Import actions (vulnerability scanning, SBOM checks, automation rules) are configured per Environment.

• Versions: Each Environment maintains its own Version history. The same SBOM version string (e.g., v1.2.0) can exist in multiple Environments with different SBOMs.

• Policies: Policies can be scoped to specific Environments or applied across all Environments.

• Automation Rules: Rules are defined per Environment and do not cascade across Environments unless explicitly copied.

Environment Settings Inheritance

Organization Defaults
  └── Environment Settings (per Environment)

1. When a new Environment is created, it inherits settings from Organization Defaults (see Environment Defaults).

2. After creation, Environment settings are independent — changes to Organization Defaults do not propagate to existing Environments unless the administrator explicitly clicks "Apply to All Projects."

3. Individual Environment settings can be customized at any time.

Environment Rules

Environment rules automate the routing of SBOMs from source control events (pushes, pull requests) to the correct Environment. See Environment Rules for details.

Managing Environments

Every Product ships with the three default Environments. Environments cannot be added or removed.

Via MCP:

list_environments      # List environments for a product
get_environment        # Get environment details

Configuring Environment Settings

1. Navigate to the Product detail page.

2. Select the target Environment from the environment selector.

3. Open the Settings tab.

4. Configure import actions, data retention, and scanning options.

5. Save changes.

Promotion Workflows

Interlynk does not enforce a built-in promotion pipeline, but you can implement promotion workflows by:

1. Uploading the same SBOM to successive Environments. For example, upload to development during CI, then re-upload to production on release.

2. Using Environment Rules to automatically route SBOMs based on branch patterns (e.g., feature/* → development, main → production).

3. Combining with policies so that stricter policies in production act as promotion gates — SBOMs that fail production policies are flagged before deployment.

Best Practices

• Apply stricter policies in production. Development Environments may warn on critical vulnerabilities; Production Environments should fail.

• Enable vulnerability scanning in all Environments. Catching vulnerabilities early in development reduces remediation cost.

• Use Environment Rules for CI/CD. Automate Environment routing based on branch patterns rather than relying on manual --env flags in every pipeline step.

• Use the default Environment names consistently. The three Environments (default, development, production) map to standard deployment stages. Use them consistently across Products so that organization-level policies and rules apply predictably.

• Review Environment settings after applying Organization Defaults. The "Apply to All Projects" action overwrites per-Environment customizations.

Common Misconfigurations

Issue	Symptom	Fix
All SBOMs land in default	No environment-specific data	Configure Environment Rules or add --env to CLI/CI commands
Vulnerability scanning disabled in an Environment	No vulnerability data after upload	Enable "Run Vulnerability Scan" in Organization Defaults or per-Environment settings
Environment Rules wildcard at highest priority	All events match the catch-all rule	Set wildcard rules to the lowest priority (highest number)