> For the complete documentation index, see [llms.txt](https://docs.interlynk.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.interlynk.io/lynkctl/lynkctl.md).

# Overview

lynkctl is Interlynk's SBOM generator. It produces spec-compliant CycloneDX 1.6+ and SPDX 3.0+ (Experimental) SBOMs from a project's build system or its package-manager descriptors.

***

## How It Works

lynkctl has two families of providers, and it picks the right one for your project automatically.

**Build providers** derive an SBOM from the build system of a compiled project — C/C++ applications, libraries, and embedded firmware. Most such projects have no dependency manifest, so lynkctl inspects build files and build metadata to determine which source files would be compiled, which libraries would be linked, and which tools would do the work. The build is never executed.

**Manifest providers** derive an SBOM from package-manager manifests and lockfiles — `package.json`, `go.mod`, `pom.xml`, and the rest. They read the descriptors directly; no build and no package manager need to run.

Both families feed the same enrichment and emitter stages, so every run produces a consistent SBOM regardless of ecosystem.

## Supported Ecosystems

### Build Providers (compiled projects)

| Build system                   | Detected from                                | Typical use                                 |
| ------------------------------ | -------------------------------------------- | ------------------------------------------- |
| GNU Make                       | `Makefile` / `GNUmakefile`                   | C/C++ applications and libraries            |
| CMake                          | `CMakeLists.txt` plus CMake File API replies | C/C++ projects with a configured build tree |
| IAR Embedded Workbench for Arm | Project files                                | Embedded firmware                           |

### Manifest Providers (package-manager projects)

| Ecosystem        | `--provider`                | Detected from                                                                                                           |
| ---------------- | --------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| JavaScript / npm | `npm`, `yarn`               | `package.json`, `package-lock.json`, `npm-shrinkwrap.json`, `pnpm-lock.yaml`, `yarn.lock`, `bun.lock`                   |
| Python           | `python`                    | `requirements.txt`, `Pipfile.lock`, `poetry.lock`, `pdm.lock`, `pylock.toml`, `uv.lock`, `pyproject.toml`, `setup.py`   |
| Go               | `go`                        | `go.mod`, `go.sum`                                                                                                      |
| Rust             | `cargo`                     | `Cargo.toml`, `Cargo.lock`                                                                                              |
| Ruby             | `gem`                       | `Gemfile.lock`, `*.gemspec`                                                                                             |
| PHP              | `php`                       | `composer.json`, `composer.lock`                                                                                        |
| .NET             | `nuget`, `dotnet`, `csharp` | `*.csproj`, `packages.lock.json`, `packages.config`, `Directory.Packages.props`, `Directory.Build.props`, `*.deps.json` |
| Java (Maven)     | `maven`                     | `pom.xml`                                                                                                               |
| Java (Gradle)    | `gradle`                    | `build.gradle`(`.kts`), `settings.gradle`(`.kts`), `gradle.lockfile`, `gradle/verification-metadata.xml`                |

`yarn`, `dotnet`, and `csharp` are aliases — they select the JavaScript and .NET providers respectively.

## Commands

| Command                   | Purpose                                   |
| ------------------------- | ----------------------------------------- |
| `lynkctl generate [DIR]`  | Produce a CycloneDX SBOM for a project    |
| `lynkctl db <subcommand>` | Manage the local OSS-index database cache |
| `lynkctl version`         | Print the build version                   |

Run any command with `--help` for full details.

## Output

lynkctl writes the SBOM to **stdout**, or to the path given with `--output`. Diagnostics, summaries, and progress go to **stderr**, so output can be piped safely:

```bash
lynkctl generate ./myproject > sbom.cdx.json
```

lynkctl produces CycloneDX 1.6+ and SPDX 3.0+ (Experimental) SBOMs, validated against the official schemas.

## Flags Available on Every Command

| Flag        | Short | Default | Description                                                                                |
| ----------- | ----- | ------- | ------------------------------------------------------------------------------------------ |
| `--output`  | `-o`  | stdout  | Write output to this path. With `--iar-all-configs`, must be a directory.                  |
| `--quiet`   | `-q`  | `false` | Suppress the per-SBOM summary line; only errors print.                                     |
| `--verbose` | `-v`  | `false` | Per-diagnostic detail. Repeatable: `-vv` adds provenance detail, `-vvv` adds timing trace. |
| `--strict`  |       | `false` | Exit non-zero on any warning. Errors already exit non-zero.                                |

## Exit Codes

| Code | Meaning                                                                                 |
| ---- | --------------------------------------------------------------------------------------- |
| `0`  | Success                                                                                 |
| `1`  | Runtime error, or diagnostics contained errors, or `--strict` and a warning was present |
| `2`  | Usage error (bad flag, missing path, conflicting options)                               |

## Getting lynkctl

lynkctl is distributed by Interlynk. Contact Interlynk to obtain the binary for your platform. See [Installation](/lynkctl/installation.md) for setup and requirements.

{% hint style="info" %}
New to lynkctl? Start with [Installation](/lynkctl/installation.md), then follow the How-To guide for your project: [GNU Make](/lynkctl/how-to-guides/gnu-make.md), [CMake](/lynkctl/how-to-guides/cmake.md), [IAR](/lynkctl/how-to-guides/iar.md), or [Package Manifests](/lynkctl/how-to-guides/package-manifests.md).
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.interlynk.io/lynkctl/lynkctl.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.