XmirrorSecurity/OpenSCA-cli: dependency, vulnerability and licence scanning with a local database

What it actually scans

OpenSCA is intended for scanning third-party dependencies, vulnerabilities and licences, and the project describes itself as an open source software supply chain security solution supporting the detection of open source dependencies, vulnerabilities and licence compliance.

Those three are separate jobs and they are worth separating in your head, because they have different failure modes. Dependency detection is a parsing problem and it either works or it does not. Vulnerability matching is a data problem, because you are matching your component versions against a database of advisories, and the quality of the answer is the quality of the database. Licence compliance is a classification problem, where the output depends on how confidently the tool can match a licence from the metadata inside the package.

The homepage is at opensca.xmirror.cn, and the README is bilingual with English and Chinese versions side by side, which tells you something about where the project comes from and who maintains it.

There is also a JetBrains plugin, the opensca-xcheck plugin, and a Visual Studio Code plugin published as xmirror.opensca, so the scanning is meant to be available inside the editor and not only as a command in a pipeline.

The language matrix, which is the honest limit

The detection ability table is the most useful thing in the documentation, because it states exactly which files are parsed for which ecosystem.

Java with Maven parses `pom.xml`, and Java with Gradle parses `.gradle` and `.gradle.kts`. JavaScript with npm parses `package-lock.json`, `package.json` and `yarn.lock`. PHP with Composer parses `composer.json` and `composer.lock`. Ruby with gem parses `gemfile.lock`. Go with gomod parses `go.mod`, `go.sum`, `Gopkg.toml` and `Gopkg.lock`. Rust with cargo parses `Cargo.lock`. Erlang with Rebar parses `rebar.lock`. And Python with pip parses `Pipfile`, `Pipfile.lock`, `setup.py`, `requirements.txt` and `requirements.in`, with a note that the last two need a pipenv environment and an internet connection.

That note is the sort of detail that is easy to miss and expensive to discover, because it means the Python path is not entirely offline, which matters for the same reason the local vulnerability database matters.

The table also notes the direction of travel. The team is dedicated to introducing more languages and enriching the parsing of relevant configuration files gradually, which is an honest way of saying that coverage is partial today.

The practical rule is simple: if your ecosystem and its lock file are in that table, the tool will see your dependencies; if they are not, it will not, and no amount of configuration will change that.

Four installation routes, two of them with mirrors

OpenSCA-cli is available for Windows, Linux and macOS, and the four documented methods cover everyone from a cautious reviewer to a contributor.

The first is to download the appropriate executable for your architecture from the releases, unzip it and run `opensca-cli` directly, with no installation at all.

The second is an install script, and the scripts are mirrored on both GitHub and Gitee, with a fallback for when the connection to one fails:

curl -sSL https://raw.githubusercontent.com/XmirrorSecurity/OpenSCA-cli/master/scripts/install.sh | sh

# Try this when internet connection fails
curl -sSL https://gitee.com/XmirrorSecurity/OpenSCA-cli/raw/master/scripts/install.sh | sh -s -- gitee

and the PowerShell equivalent for Windows takes the same shape with `irm` and `iex`.

The third is Homebrew, with `brew install opensca-cli`.

The fourth is building from source, which needs Go 1.18 or above according to the README, and offers a GitHub or a Gitee clone depending on your network:

git clone https://github.com/XmirrorSecurity/OpenSCA-cli.git opensca && cd opensca && go build

The mirror arrangement is the interesting part of this section. Both the source and the install scripts are available from two hosts, and the script takes an argument that selects the mirror, which is a pragmatic response to a project whose users are distributed across networks where one of those hosts is unreachable.

The dependency list tells you what the tool produces

The `go.mod` is short enough to read as a description of the tool's outputs.

`github.com/CycloneDX/cyclonedx-go` is the CycloneDX library, which is the SBOM format, and `github.com/veraison/swid` is for SWID tags, the other software identification format. So the tool produces the two standard machine readable software inventories, which is what a supply chain report needs to be consumable by something else.

The persistence layer is `gorm.io/gorm` with the SQLite and MySQL drivers, and `github.com/glebarez/go-sqlite` as a pure Go SQLite implementation, which is what lets the tool keep its findings in a local database without a native build step.

The interface is `github.com/rivo/tview` with `github.com/gdamore/tcell/v2`, so the tool has a terminal user interface rather than being output only. The rest of the list is the supporting work: `Masterminds/semver` for version comparison, `sabhiram/go-gitignore` for honouring ignore rules, `titanous/json5` for configuration, `nwaples/rardecode` for decoding, `axgle/mahonia` for character set conversion, `pkg/errors` and `google/uuid` for the usual reasons.

The documentation structure also tells you the feature set. Beyond the parameters, the ignore paths in the configuration and the report formats, there is a section on a local vulnerability database, including the format of the database file, an explanation of its fields and a sample configuration, and a FAQ that covers whether an environment variable is needed while using OpenSCA, where the vulnerability database comes from, and what a scan costs in time. That last question is the one to look up first, because a scanner that takes an hour changes how you wire it into a pipeline.

Where this is the wrong choice

The first wrong case is a stack outside the language matrix. The tool parses manifests, so an ecosystem it does not parse produces an empty report, and an empty report that looks like a clean bill of health is worse than no report at all.

The second is a team that needs dependency resolution. OpenSCA reads what is already resolved, in the lock files, and reports on it. It does not resolve versions, it does not propose upgrades and it does not enforce a policy on what may enter the build. For anything beyond reporting, you need something else.

The third is a team that already has a scanner and wants better data rather than a new tool. Licence classification and vulnerability matching are both data problems, and the accuracy of your report is bounded by the database you point the tool at, whether that is the hosted service or the local file you maintain yourself.

The fourth is an organisation with a strict policy on running binaries fetched over the network. The install script is a curl piped into a shell, which is convenient and is exactly the pattern most supply chain policies flag, and the Homebrew route or the release binary are the ones to prefer in that environment.

On the state of the project, the releases are v3.0.9 from 2026-01-15, v3.0.10 from 2026-03-19 and v3.0.11 from 2026-05-15, and the last push to the repository was on 2026-05-15 with the repository not archived. The module path carries a v3 suffix and the manifest declares Go 1.25, while the README's build instructions still say Go 1.18 or above, which is a small mismatch worth resolving before you try to build it. The repository also carries a `SECURITY.md`, a `CONTRIBUTING.md` with a Chinese counterpart, a `docker/` directory for the container image and a `makefile`.

Editorial conclusion

Adopt OpenSCA-cli if you need an SBOM and a licence and vulnerability report from your dependency manifests in CI, and especially if you need the scan to work without calling a hosted service, because the local vulnerability database option exists for exactly that. Do not adopt it as a general dependency manager, since it reads manifests and reports rather than resolving or upgrading anything, and do not assume the detection matrix covers your ecosystem, because the language table is explicit about which package managers and which files are parsed. Verify first that your ecosystem and lock file are in the supported matrix, that the vulnerability database you point it at is one you trust and keep current yourself, and that the version you run matches the v3 line, since the module path carries a major version suffix while the release tags move on their own schedule.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. XmirrorSecurity/OpenSCA-cli on GitHub