# Component Detection scans a repository and names every open source dependency

> Component Detection is a Microsoft package scanning tool meant to run at build time, producing a graph-based inventory of detected components across more than twenty package ecosystems. It ships as a downloadable binary for Windows, macOS and Linux, can be embedded as a library, and the detector coverage differs between scanning and graph creation.

**microsoft/component-detection** — Scans your project to determine what components you use

- Repository: https://github.com/microsoft/component-detection
- Stars: 556 · Forks: 140
- Language: C#
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-component-detection

## A build-time scanner rather than a dependency manager

The README describes Component Detection, abbreviated to CD, as a package scanning tool intended to be used at build time, and that single sentence sets the scope. It produces a graph-based output of all detected components across a variety of package ecosystems, and it can also be used as a library to detect dependencies in your own applications. The distinction matters. It is not a package manager, it does not resolve your dependency graph for you, and it does not install anything. It reads what is already in your repository, including lockfiles and container definitions, and reports what it finds. The repository topics say as much: dependencies, package-management, sbom, software-composition-analysis and static-analysis. In other words, the intended consumer is a pipeline that needs to know what it is shipping, and the second consumer is a developer who wants to embed the detection in their own tool rather than run the command line application.

## Scanning coverage is wider than graph coverage

The features table lists twenty-two ecosystems, and the second column is the one that trips people up. Every listed ecosystem is scannable, but graph creation is only available for some of them. Scanning with graph creation are CocoaPods, Conda for Python, Go with Go 1.11 or later, Ivy, Maven, NPM including Yarn and Pnpm, NuGet including Paket, Pip for Python, Poetry for Python lockfiles only, Ruby, Rust through Cargo, and Uv for Python. Scanning without graph creation are Conan, Docker Compose, Dockerfile, the DotNet SDK, Gradle lockfiles only, Helm, Linux packages, Poetry, SPDX SBOM, Swift and Vcpkg. The practical consequence is that a project built on Gradle or Docker will get a flat list of detected components but not the dependency edges between them, while a Maven or npm project gets the edges as well. Linux distributions are scanned through syft from Anchore, which is the one place another project does the actual reading of the operating system package database.

## Getting it running from a clone

Running from source needs Git and .NET 8 installed, and the README gives the sequence.

```bash
# Clone this repository
$ git clone https://github.com/microsoft/component-detection

# Go into the repository
$ cd component-detection 

# Run the app
$ dotnet run --project ".\src\Microsoft.ComponentDetection\Microsoft.ComponentDetection.csproj" scan --SourceDirectory [PATH TO THE REPO TO SCAN]
```

The arguments are documented separately in the detector arguments page, and the repository layout shows where the entry point lives, with src, test, docs and a ComponentDetection.sln solution at the top level. A Directory.Build.props and Directory.Build.targets, a Directory.Packages.props for central package versions and a global.json that pins the SDK are all present, so the build is centrally managed. The download section says binaries for Windows, macOS and Linux can be fetched from the latest release, which is the route most pipelines will take. Releases are versioned in the v8 line, with v8.0.4 published on 2026-10-14, v8.0.3 on 2026-10-01 and v8.0.2 on 2026-09-25.

## The container image bundles the toolchains the detectors need

The Dockerfile at the repository root shows a two-stage build. The first stage uses the .NET 8 SDK image, copies the source in and publishes a self-contained, single-file linux-x64 binary with PublishReadyToRun disabled. The second stage is the interesting part, because the runtime image is not a bare .NET runtime. It installs golang, moby-engine, maven, pnpm, poetry and python through the package manager before copying the published output across, and the entry point is the ComponentDetection executable itself.

```dockerfile
RUN tdnf install -y \
    golang \
    moby-engine \
    maven \
    pnpm \
    poetry \
    python
```

The reason is straightforward once you map it to the detector table. Scanning a Go project needs the go toolchain, a Maven project needs maven, an npm project needs pnpm or the npm client, a Python project needs poetry, and the Dockerfile and Docker Compose detectors need a container engine, which moby-engine provides. So the image size is the price of covering the ecosystems in one binary. A user who only cares about NuGet or npm can run the standalone release and skip all of that.

## Detector maturity is published per ecosystem

The README does not claim every detector is finished. It points to a detectors directory for the current status of each individual detector, with three named states, Stable, Experimental and DefaultOff, and a separate feature-overview document for a complete feature overview. That is the file to read before you wire the tool into a pipeline, because a DefaultOff detector produces no output unless someone turns it on, and an Experimental detector may change behaviour between minor versions. The per-ecosystem documentation lives in the same directory, with one markdown file per ecosystem, so a NuGet user reads docs/detectors/nuget.md and a Dockerfile user reads docs/detectors/dockerfile.md. The per-ecosystem pages are also where the specific inputs are documented, such as the NuGet page covering the MSBuild binary log route for the DotNet SDK ecosystem. The repository also carries SECURITY.md, CODE_OF_CONDUCT.md, CONTRIBUTING.md, a renovate.json for dependency updates and a .devcontainer directory for Codespaces.

## What this is not, and where it overlaps with other tools

There are two clear boundaries. First, Component Detection answers what is present, not what is vulnerable, even though the topics list includes software-composition-analysis, which is the category this kind of tool sits in. It produces the inventory that a vulnerability scanner or an SCA service then consumes. Second, it is not a lockfile parser you call directly for a single ecosystem. When you only have one NuGet project and one packages.lock.json file, reading that file is less work than running a scanner. The real alternative to name is syft, from Anchore, which Component Detection already calls for the Linux ecosystem. Syft generates SBOMs directly and is what tools like Grype and the wider Anchore ecosystem consume; Component Detection instead fronts a larger set of build-time ecosystems and adds the graph structure for the subset where edges are available. The other difference is the audience: syft is a standalone SBOM generator, while Component Detection is explicitly build-time oriented and usable as an embedded library through its NuGet packages, with Microsoft.ComponentDetection.Common among them.

## Conclusion

Adopt Component Detection if you need an inventory of the open source components in a repository without maintaining your own manifest, especially in a build pipeline where an SBOM has to be produced on every build. Skip it if you only need to read a lockfile you already control, since a manifest tool does that faster. Before you rely on the output, check the detectors directory for the status of each detector, because several ecosystems support scanning without graph creation and some detectors are marked Experimental or DefaultOff, and note that the last push was on 2026-10-20.

## FAQ

### How do I run Component Detection against a repository?

Clone the repository, install Git and .NET 8, then run `dotnet run --project ".\src\Microsoft.ComponentDetection\Microsoft.ComponentDetection.csproj" scan --SourceDirectory [PATH TO THE REPO TO SCAN]`. Prebuilt binaries for Windows, macOS and Linux are available from the latest release page.

### Which package ecosystems does Component Detection support?

The features table lists CocoaPods, Conan, Conda, Docker Compose, Dockerfile, DotNet SDK, Go, Gradle lockfiles, Helm, Ivy, Linux distributions, Maven, NPM with Yarn and Pnpm, NuGet with Paket, Pip, Poetry, Ruby, Rust through Cargo, SPDX SBOM, Swift, Uv and Vcpkg. Linux packages are scanned via syft from Anchore.

### What is the difference between scanning and graph creation in Component Detection?

Every listed ecosystem can be scanned, but graph creation is supported only for CocoaPods, Conda, Go with Go 1.11 or later, Ivy, Maven, NPM, NuGet, Pip, Poetry, Ruby, Rust and Uv. Ecosystems such as Gradle, Dockerfile, Helm, Conan, SPDX SBOM, Swift and Vcpkg are scanned without dependency edges.

### Can Component Detection be used as a library?

Yes. The README states that Component Detection can also be used as a library to detect dependencies in your own applications, and the packages are published on NuGet under the Microsoft.ComponentDetection name.

## Sources

- [Issues](https://github.com/microsoft/component-detection/issues)
- [License: MIT](https://github.com/microsoft/component-detection/blob/main/LICENSE)
- [microsoft/component-detection on GitHub](https://github.com/microsoft/component-detection)
- [README](https://github.com/microsoft/component-detection/blob/main/README.md)
- [Releases](https://github.com/microsoft/component-detection/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-component-detection