pylynk
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/pylynk
When to Use pylynk
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 --helpDocker
Verify Installation
Expected output:
Authentication
Environment Variable (Recommended)
This is the recommended method for both local use and CI/CD. The token is read automatically by all commands.
Command-Line Flag
Avoid --token in CI/CD — the value may appear in build logs. Always use the environment variable.
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.
--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.
--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.
--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:
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:
By version ID
--verId
By name
--prod + --env + --ver
--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.
--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.
--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:
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
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)
Always mark the variable as secret/masked in your CI platform to prevent it from appearing in build logs.
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:
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
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
0
Success
1
General error
2
Argument parsing error
Best Practices
Least Privilege Token Usage
Create service tokens with the minimum role required:
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
--envto separate staging, production, and development SBOMs.Version tracking: Capture the version ID from
versoutput after upload for downstream status checks.Error handling: Always check exit codes. Use
--retries 0to 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
COMPLETEDstatus before downloading enriched SBOMs. Processing is asynchronous.
Common Misconfigurations
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