socket manifest

Generate manifest files for languages without a simple default/declarative manifest format.

$ socket manifest --help

  Generate a dependency manifest for certain ecosystems

  Usage
    $ socket manifest <command>

  Commands
    auto                        Auto-detect build and attempt to generate manifest file
    bazel                       [beta] Bazel SBOM support — generate manifest files for a Bazel project (Maven, PyPI)
    cdxgen                      Run cdxgen for SBOM generation
    conda                       [beta] Convert a Conda environment.yml file to a python requirements.txt
    dynamic-sbom-inference      Recursively discover gradle/sbt/maven build roots and generate a Socket facts SBOM for each
    gradle                      [beta] Generate a Socket facts file (or `pom.xml` with --pom) for a Gradle/Java/Kotlin/etc project
    kotlin                      [beta] Generate a Socket facts file (or `pom.xml` with --pom) for a Kotlin project
    maven                       [beta] Generate a Socket facts file from a Maven `pom.xml` project
    scala                       [beta] Generate a Socket facts file (or `pom.xml` with --pom) from a Scala `build.sbt` project
    setup                       Start interactive configurator to customize default flag values for `socket manifest` in this dir

  Options

    --no-banner                 Hide the Socket banner
    --no-spinner                Hide the console spinner

Some languages are harder to process than others. While we can process the manifest files (like package.json for npm) on our servers, some languages make this almost impossible without full access to the source code.

Generate manifest files

In order to work around this socket manifest attempts to offer a way for you to generate the manifest files so you can generate a Scan for them and get a report back from your CI/CD pipeline.

socket manifest auto ./proj

Currently supported via local generation are JVM/Gradle-based projects (Gradle, Kotlin, Scala/sbt), Maven, plus Bazel and Conda (all currently in beta). See socket manifest --help for the full list of subcommands.

socket manifest gradle ./proj

Note: socket manifest gradle works for any project that builds with Gradle, including Java, Kotlin, and Scala projects.

For Maven pom.xml projects, Socket's backend reads your manifests directly, so no local generation is required. Generating a Socket facts file with socket manifest maven is an optional step that can improve dependency-graph accuracy. For full application reachability scans it is recommended. See --dynamic-sbom-inference under Generate and scan.

These commands leverage your local environment to generate the necessary manifest files, which you can then upload to get scanned by calling socket scan create on the output directory.

You can see detailed help per language by calling help, for example: socket manifest gradle --help

We are still improving use of this command. Please let us know if you run into issues and we'll try to get them resolved as soon as possible.

Socket facts (JVM projects)

For the JVM commands (socket manifest gradle, kotlin, scala, and maven), the default output is a single Socket facts file (.socket.facts.json) describing the resolved dependency graph of the whole build.

socket manifest gradle ./proj

Pass --pom to gradle, kotlin, or scala to generate pom.xml files instead. socket manifest maven always generates a Socket facts file.

In a multi-module build, each direct dependency in the facts file is attributed to the build files of the subprojects that pull it in, so the dashboard shows which module brought it in. The build's own modules are marked as first-party, so Socket Fix treats them as part of your build when it plans upgrades.

By default an unresolved dependency fails the run. Pass --ignore-unresolved to get a warning instead. Use --include-configs and --exclude-configs to choose which configurations (Maven scopes for maven) get resolved.

See socket manifest gradle --help for the available flags.

Bazel and Conda

socket manifest bazel generates Maven manifests (maven_install.json) for a Bazel workspace by running bazel query. Pass --ecosystem pypi to generate PyPI requirements instead, or repeat the flag (--ecosystem maven --ecosystem pypi) to get both. The output goes to ./.socket/bazel-manifests/ unless you pass --out.

socket manifest conda reads the pip block from an environment.yml or environment.yaml file and writes it out as a requirements.txt in the target directory, which Socket can then scan like a PyPI project. Pass --file to read a file with another name. When socket manifest auto or socket scan create --auto-manifest can't convert the Conda file, the run stops before anything is uploaded, the same as for Gradle, Maven and sbt.

Multiple builds

The per-ecosystem commands operate on the build in the directory you point them at. If a repository contains several independent Gradle, sbt, or Maven builds, socket manifest dynamic-sbom-inference looks through the whole target directory and generates a Socket facts file for each of them.

socket manifest dynamic-sbom-inference ./proj

Use --exclude-paths to leave builds out. If no Gradle, sbt, or Maven build is found anywhere under the target, the command fails rather than reporting that it generated nothing.

You don't need to run this yourself before a scan. Pass --dynamic-sbom-inference to socket scan create and the files are generated as part of the scan. Add --reach for full application reachability, and reachability is then analyzed and reported per subproject.

Default setup

You can generate a file that overrides defaults per project by running

socket manifest setup ./proj

This interactive tool will try to detect eligible languages for which it can generate a manifest. You pick any language, regardless of detection, and then pick defaults for flags if you want to. The result is stored in the root of the dir / project in a file called socket.json (more details here).

You can setup the defaults this way for multiple languages per project dir. These defaults are picked up when you run the manifest generator directly (ie. socket manifest gradle ./proj will apply defaults defined in ./proj/socket.json) but also socket manifest auto and something like socket scan create --auto-manifest would leverage these defaults.

For a repository with multiple builds, socket manifest setup --dynamic-sbom-inference ./proj walks you through each build it finds and writes a socket.json next to each one. In that layout the defaults.manifest section of a nested socket.json inherits from the files above it, with the nearest file winning field by field; set a field to null to clear an inherited value instead of restating it.

Generate and scan

Once you've setup the manifest defaults for the languages you want to target you can generate the manifest files and run a scan in one go by running

socket scan create --auto-manifest ./proj

This will first run the equivalent to socket manifest auto ./proj, which in turn will try to detect the eligible files in your target directory, generate manifests for languages it found (applying socket.json if available), and then proceed with a regular socket scan create to upload the generated manifest files to do a scan.

For full application reachability scans of Gradle, sbt, and Maven projects, use --dynamic-sbom-inference. It generates a Socket facts file for every build under the target, and reachability is then analyzed and reported per subproject:

socket scan create --reach --dynamic-sbom-inference ./proj

--dynamic-sbom-inference only generates files for Gradle, sbt, and Maven. Add --auto-manifest as well if you also want manifests for the other ecosystems, like Conda or Bazel.

CycloneDX

There is another tool that this command exposes: CycloneDX.

This generates a whole SBOM ("Software Bill Of Materials").

socket manifest cdxgen -t java

We dedicated a docs page for cdxgen.