feat: [CMPA-603] Add npm support for SBOM component metadata being FF

[calhar-snyk]

Pull Request Submission Checklist

• Follows CONTRIBUTING guidelines
• Commit messages are release-note ready, emphasizing what was changed, not how.
• Includes detailed description of changes
• Contains risk assessment (Low | Medium | High)
• Highlights breaking API changes (if applicable) — none
• Links to automated tests covering new functionality
• Includes manual testing instructions (if necessary)
• Updates relevant GitBook documentation (PR link: ___) — n/a, internal/undocumented flag
• Includes product update to be announced in the next stable release notes — n/a, no user-facing change

What does this PR do?

Extends --include-component-metadata support to npm projects, following on from the Maven support added in #6948.

When the flag is set, the npm plugin now forwards it to snyk-nodejs-lockfile-parser, which reads the install-time integrity and resolved fields already recorded in the lockfile and surfaces them as hash:<algorithm> and distribution:url labels on the dep-graph nodes. The SBOM extension then uses these labels to populate component hashes and external distribution URLs in the CycloneDX output.

Concretely:

• Forwards includeComponentMetadata through the legacy npm-lock-parser in both code paths — the v2/v3 dep-graph path (parseNpmLockV2Project) and the v1 depTree path (buildDepTreeFromFiles). For v1, the labels survive the downstream depTree→dep-graph conversion.
• Adds includeComponentMetadata to the plugin Options type.
• Bumps snyk-nodejs-lockfile-parser to 2.9.0, the version that emits the component-metadata labels.

The flag remains internal/undocumented and is gated by the feature-flag gateway — the same surface as the Maven precursor. Unlike Maven, no artifact resolution step is needed: the metadata already lives in the lockfile, so nothing has to be installed/resolved first.

Where should the reviewer start?

• src/lib/plugins/nodejs-plugin/npm-lock-parser.ts — the two-line forwarding change (v1 and v2/v3 paths).
• src/lib/plugins/types.ts — the new optional Options field.
• test/jest/acceptance/snyk-test/npm-include-component-metadata.spec.ts — coverage across lockfile v1/v2/v3.

N.B. 1: npm intentionally stays on the in-tree legacy plugin here (the change just threads the flag through it).
N.B. 2: The snyk-nuget-plugin bump in package-lock.json is a drive-by correction of a previous oversight. package.json wants "snyk-nuget-plugin": "4.2.3",

How should this be manually tested?

Against an npm project with a package-lock.json (v1, v2, or v3):

snyk test --print-graph --include-component-metadata --file=package-lock.json

Dep-graph nodes should carry hash:<algorithm> and distribution:url labels. Re-running without --include-component-metadata should produce no such labels.

Automated coverage: test/jest/acceptance/snyk-test/npm-include-component-metadata.spec.ts exercises lockfile v1/v2/v3, each asserting the labels are present with the flag and absent without it.

The full snyk sbom flow can also be tested against the pre-prod API:

❯ ~/code/cli/binary-releases/snyk-macos-arm64 sbom --format=cyclonedx1.6+json | jq '.'
{
  "$schema": "http://cyclonedx.org/schema/bom-1.6.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:acd67741-5c1d-4c3e-8591-713b95281254",
  "version": 1,
  "metadata": {
    "timestamp": "2026-06-25T19:28:08Z",
    "tools": {
      "components": [
        {
          "type": "application",
          "author": "Snyk",
          "name": "snyk-cli",
          "version": "1.1306.0-dev.59984f8c87451bff7664b9b1598c599fc51f881f"
        }
      ],
      "services": [
        {
          "provider": {
            "name": "Snyk"
          },
          "name": "SBOM Export API",
          "version": "v1.131.0"
        }
      ]
    },
    "component": {
      "bom-ref": "1-npm-component-metadata-v1@1.0.0",
      "type": "application",
      "name": "npm-component-metadata-v1",
      "version": "1.0.0",
      "purl": "pkg:npm/npm-component-metadata-v1@1.0.0"
    }
  },
  "components": [
    {
      "bom-ref": "2-lodash@4.17.15",
      "type": "library",
      "name": "lodash",
      "version": "4.17.15",
      "hashes": [
        {
          "alg": "SHA-512",
          "content": "f3139c447bc28e7a1c752e5ca705d05d5ce69a1e5ee7eb1a136406a1e4266ca9914ba277550a693ce22dd0c9e613ee31959a2e9b2d063c6d03d0c54841b340d4"
        }
      ],
      "licenses": [
        {
          "expression": "MIT"
        }
      ],
      "purl": "pkg:npm/lodash@4.17.15",
      "externalReferences": [
        {
          "url": "https://registry.npmjs.org/lodash/-/lodash-4.17.15.tgz",
          "type": "distribution"
        }
      ],
      "properties": [
        {
          "name": "snyk:npm:scope",
          "value": "prod"
        }
      ]
    }
  ],
  "dependencies": [
    {
      "ref": "1-npm-component-metadata-v1@1.0.0",
      "dependsOn": [
        "2-lodash@4.17.15"
      ]
    },
    {
      "ref": "2-lodash@4.17.15"
    }
  ]
}

What's the product update that needs to be communicated to CLI users?

None. The feature is inert by default and gated behind an internal feature flag; there is no user-facing change unless explicitly enabled.

Risk assessment (Low | Medium | High)?

Low. The behaviour is gated behind an internal feature flag from the feature-flag gateway and is inert by default — clients see no change unless it is explicitly enabled for them. The only always-on change is the snyk-nodejs-lockfile-parser 2.9.0 bump, which adds the label-emitting code path without altering default output. npm scans continue to run through the existing legacy plugin.

Any background context you want to provide?

Precursor: #6948 (Maven component metadata + registering include-component-metadata as a recognised CLI argument forwarded to the plugins). This PR is the npm counterpart.

What are the relevant tickets?

• CMPA-603

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[github-actions]

	Warnings
⚠️	There are multiple commits on your branch, please squash them locally before merging!

Generated by 🚫 dangerJS against 98c902f

[snyk-pr-review-bot]

PR Reviewer Guide 🔍

🧪 PR contains tests

🔒 No security concerns identified

⚡ No major issues detected

📚 Repository Context Analyzed This review considered 30 relevant code sections from 7 files (average relevance: 0.57) package-lock.json (9 segments, lines 3451-3707) help/cli-commands/sbom.md (lines 140-347) help/cli-commands/test.md (lines 241-421) src/lib/plugins/nodejs-plugin/npm-lock-parser.ts (lines 1-163) src/lib/plugins/get-single-plugin-result.ts (lines 1-50) src/lib/types.ts (lines 1-300) packages/snyk-fix/src/plugins/python/handlers/pip-requirements/index.ts (lines 1-256)

🤖 Repository instructions applied (from AGENTS.md)