> 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 %}