terminalpylynk

pylynk is the official command-line interface for the Interlynk platform. It provides programmatic access to SBOM upload, download, product management, vulnerability queries, and processing status checks — designed for both interactive use and CI/CD automation.

Repository: github.com/interlynk-io/pylynkarrow-up-right


When to Use pylynk

Use Case
pylynk
API (curl)
UI

CI/CD SBOM upload

Recommended

Possible

Not practical

Bulk vulnerability export

Recommended

Possible

Manual

Interactive product browsing

Good

Verbose

Best

SBOM download with enrichment

Recommended

Complex

Manual

One-off queries

Good

Good

Good

Scripted automation

Recommended

Recommended

Not applicable

Use pylynk when you need repeatable, scriptable access to the platform. Use the API directly when you need fine-grained control over GraphQL queries. Use the UI for visual exploration and ad hoc operations.


Installation

pip (from source)

git clone https://github.com/interlynk-io/pylynk.git
cd pylynk
pip3 install -r requirements.txt
python3 pylynk.py --help

Docker

Verify Installation

Expected output:


Authentication

This is the recommended method for both local use and CI/CD. The token is read automatically by all commands.

Command-Line Flag

circle-exclamation

API Endpoint Override

The default API endpoint is https://api.interlynk.io/lynkapi. Override it with:

Token Security Best Practices

  • Store tokens in a secrets manager (Vault, AWS Secrets Manager, GitHub Secrets).

  • Never commit tokens to source control.

  • Use service tokens for automation; user tokens for interactive sessions.

  • Set expiration dates — 90 days for CI/CD, 30 days for development.

  • Rotate tokens proactively. See Rotation Strategy.


Core Commands

prods — List Products

Lists all products in the organization.

Parameter
Required
Default
Description

--output

No

table

Output format: table, json, csv

--human-time

No

Off

Show relative timestamps (e.g., "2 days ago")

--token

No

Env var

Override authentication token

-v, --verbose

No

Off

Enable debug output

Output columns: NAME, ID, VERSIONS, UPDATED AT


vers — List Versions

Lists all versions (SBOMs) for a product.

Parameter
Required
Default
Description

--prod

Yes

Product name

--env

No

default

Environment name

--output

No

table

Output format: table, json, csv

--human-time

No

Off

Relative timestamps

-v, --verbose

No

Off

Debug output

Output columns: ID, VERSION, PRIMARY COMPONENT, UPDATED AT

Use the ID value from this output as --verId in other commands.


upload — Upload SBOM

Uploads an SBOM file to the platform.

Parameter
Required
Default
Description

--prod

Yes

Product name

--sbom

Yes

Path to SBOM file

--env

No

default

Target environment

--retries

No

3

Retry count on transient failures

-v, --verbose

No

Off

Debug output

Supported formats: CycloneDX (JSON, XML), SPDX (JSON, tag-value)

Retry behavior:

Condition
Behavior

5xx server error

Retries with exponential backoff (1s, 2s, 4s)

429 rate limit

Retries with exponential backoff

401 unauthorized

Fails immediately — no retry

Other 4xx

Fails immediately — no retry

Network error

Retries with exponential backoff

CI metadata: When running in a CI environment (CI=true), pylynk automatically captures build metadata (PR number, commit SHA, branch name, build URL) and sends it as HTTP headers with the upload.


download — Download SBOM

Downloads an SBOM from the platform, optionally enriched with vulnerabilities, support status, or converted to a different format.

Identification — provide one of:

Method
Parameters Required

By version ID

--verId

By name

--prod + --env + --ver

Parameter
Required
Default
Description

--verId

Conditional

Version ID (from vers command output)

--prod

Conditional

Product name

--env

Conditional

Environment name

--ver

Conditional

Version name

--out-file

No

stdout

Output file path

--vuln

No

false

Include vulnerabilities (true/false)

--spec

No

Original

Output spec: SPDX or CycloneDX

--spec-version

No

Original

Spec version (e.g., 2.3, 1.5)

--lite

No

Off

Download lightweight version

--original

No

Off

Download exact uploaded SBOM

--dont-package-sbom

No

Off

Keep multi-SBOM files separate

--exclude-parts

No

Off

Exclude linked parts

--include-support-status

No

Off

Add support status metadata

--support-level-only

No

Off

CSV output with support levels only


vulns — List Vulnerabilities

Queries vulnerabilities across products.

Parameter
Required
Default
Description

--prod

No

Product name (uses latest version if no version specified)

--env

No

default

Environment name

--verId

No

Specific version ID

--ver

No

Version name

--output

No

table

Output format: table, json, csv

--columns

No

Default set

Comma-separated column names

--vuln-details

No

Off

Include severity, CVSS, EPSS, KEV, CWE

--vex-details

No

Off

Include VEX status, justification, actions

--timestamp-details

No

Off

Include all timestamp columns

--human-time

No

Off

Relative timestamps

--list-columns

No

Display available column names and exit

Default columns: id, part_name, part_version, component_name, component_version, severity, source, status, assigned

Vulnerability detail columns (--vuln-details): severity, kev, cvss, cvss_vector, epss, cwe

VEX detail columns (--vex-details): status, details, justification, action_statement, impact_statement, response


status — Check Processing Status

Checks the processing status of an uploaded SBOM.

Parameter
Required
Default
Description

--prod

Yes

Product name

--verId

Conditional

Version ID

--ver

Conditional

Version name (requires --env)

--env

No

default

Environment name

--output

No

table

Output format: table, json

Status types tracked:

Status
Description

checksStatus

SBOM quality and format checks

policyStatus

Policy evaluation

labelingStatus

Internal labeling

automationStatus

Automation rule execution

vulnScanStatus

Vulnerability scanning

Status values: UNKNOWN, NOT_STARTED, IN_PROGRESS, COMPLETED


version — Show CLI Version


CI/CD Integration

GitHub Actions

GitLab CI

Bitbucket Pipelines

Azure DevOps

Docker-Based CI

For environments where Python installation is not practical:

Handling Secrets Securely

CI Platform
Secret Storage
Reference Syntax

GitHub Actions

Repository Secrets

${{ secrets.INTERLYNK_SERVICE_TOKEN }}

GitLab CI

CI/CD Variables (masked)

$INTERLYNK_SERVICE_TOKEN

Bitbucket

Repository Variables (secured)

$INTERLYNK_SERVICE_TOKEN

Azure DevOps

Pipeline Variables (secret)

$(INTERLYNK_SERVICE_TOKEN)

circle-exclamation

Fail-the-Build Patterns

Use exit codes to gate builds on SBOM upload success:

CI Metadata

When CI=true is set (automatically by most CI platforms), pylynk captures build metadata and sends it with uploads:

Header
Description

X-CI-Provider

CI platform name

X-Event-Type

Trigger type (push, pull_request, release)

X-PR-Number

Pull request number

X-Commit-SHA

Git commit hash

X-Repository-URL

Repository URL

X-Build-URL

Build/job URL

X-PR-Source-Branch

Source branch name

X-PR-Target-Branch

Target branch name

Control metadata collection:


Troubleshooting

Debug Mode

Enable verbose logging with -v or --verbose:

Debug output includes: API request/response details, token validation (masked), CI metadata detection, upload speed metrics, and timing information.

Common Errors

Error
Cause
Resolution

Security token not found

INTERLYNK_SECURITY_TOKEN not set

Export the environment variable or use --token

Authentication failed

Invalid or expired token

Verify token in UI; create a new one if expired

Product not found

Typo in product name or no access

Run pylynk prods to list available products

Version not found

Invalid version ID or name

Run pylynk vers --prod 'name' to list versions

File not found

Bad SBOM file path

Verify path; use absolute paths in Docker

Request failed with status code: 429

Rate limited

Automatic retry handles this; increase --retries if needed

RequestException

Network or connectivity issue

Check firewall, proxy, and INTERLYNK_API_URL

Error uploading sbom

Invalid SBOM format

Verify SBOM is valid CycloneDX or SPDX

Exit Codes

Code
Meaning

0

Success

1

General error

2

Argument parsing error


Best Practices

Least Privilege Token Usage

Create service tokens with the minimum role required:

Workflow
Recommended Role

SBOM upload only

Custom role with upload permission

Upload + vulnerability review

Operator

Full automation

Admin (use sparingly)

Read-only reporting

Viewer

Automation Design Patterns

  • Idempotent uploads: Uploading the same SBOM twice to the same product/environment creates a new version. Design pipelines to upload only on meaningful changes.

  • Environment separation: Use --env to separate staging, production, and development SBOMs.

  • Version tracking: Capture the version ID from vers output after upload for downstream status checks.

  • Error handling: Always check exit codes. Use --retries 0 to disable retries when you need fast failure.

Parallel vs Serial Execution

  • Serial: Upload SBOMs for the same product sequentially to avoid race conditions on version ordering.

  • Parallel: Upload SBOMs for different products concurrently. Each product is independent.

  • Status polling: Wait for COMPLETED status before downloading enriched SBOMs. Processing is asynchronous.


Common Misconfigurations

Issue
Symptom
Fix

Token in --token flag in CI

Token visible in build logs

Use INTERLYNK_SECURITY_TOKEN env var

Wrong INTERLYNK_API_URL

Connection errors or 401

Verify URL or remove the override to use default

Missing --prod on upload

Argument parsing error

Always specify --prod with upload

Docker volume not mounted

File not found inside container

Add -v $(pwd):/app/data and use /app/data/ paths

Using --ver without --env

Version not found

Provide both --env and --ver together

Old pylynk version

Unexpected API errors

Pull latest from repository or Docker image

Last updated