[turbobobbytraykov]

Description

Adds release supply-chain evidence for every package npm-publish.yml publishes, using the same approach as IgniteUI/igniteui-angular, IgniteUI/igniteui-webcomponents and IgniteUI/igniteui-react: one delivered CycloneDX SBOM per package, plus an overall SBOM README for the release. npm publishing now uses the exact tarballs that were inventoried and attested.

What the release workflow now does

• build (read-only, no OIDC): builds as before, then scripts/build-sbom.js packs every publishable lerna package once. The packages are @igniteui/cli-core, @igniteui/angular-templates, @igniteui/angular-schematics, @igniteui/mcp-server and igniteui-cli, read from lerna.json and sorted in dependency order. For each tarball it:

  • installs it in isolation (--omit=dev --ignore-scripts), with workspace siblings resolved from the tarballs of the same build through npm overrides, because those versions aren't on npm yet;
  • generates a CycloneDX 1.6 SBOM with @cyclonedx/cyclonedx-npm, re-roots it on the published package and checks the graph for duplicate, unknown or unreachable refs;
  • validates the SBOM against the official schema, writes .sha256/.sha512 digests and runs npm audit on the delivered closure.

  It also writes a best-effort build-environment SBOM of the repository toolchain and one README covering every package in the release.

• attest: build provenance for all tarballs. attest-sbom: a matrix job that creates one CycloneDX SBOM attestation per package. Both are skipped in private repos.

• publish: now publishes the verified tarballs in dependency order instead of lerna exec npm publish, after verifying their checksums. It runs only after both attestation jobs succeed.

• attach-to-release: uploads the tarballs, digests, delivered SBOMs, an SBOM archive (with README and supply-chain notes) and the attestation bundles to the release. It also adds a supply-chain section to the release notes, unless the notes were edited during the build.

• mcp-registry: now needs: publish and runs after a successful npm publish (still skipped for prereleases). The workflow_dispatch path is unchanged.

Licenses in each SBOM are the ones the installed packages declare, as in the Angular, Web Components and React releases. No external license lookup is performed and no SPDX documents are produced.

Dependency manifest change: adds @cyclonedx/cyclonedx-npm (^6.0.1) as a root devDependency (package.json / yarn.lock). The generator runs from node_modules, so release-time generation does not fetch it from the network. Also removes the root deploy script, which the workflow no longer uses.

Package manifest change: adds "license": "MIT" to @igniteui/mcp-server's package.json, matching the License section of its README. Without it, that package's SBOM component had no license.

Related Issue

N/A

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Refactoring / code cleanup
• Build / CI configuration change

Affected Packages

• @igniteui/mcp-server (packages/igniteui-mcp): license field only

No other package contents change; the release workflow now inventories all of them.

Checklist

• I have tested my changes locally (npm run jasmine: 714 passed, 2 pre-existing pending)
• I have built the project successfully (tsc, tsconfig-pack, build:mcp)
• I have run the linter (npm run lint: 0 errors; 1 pre-existing warning in packages/core/util/Schematics.ts)
• I have added/updated tests as needed: not applicable. SBOM generation is a release supplement, not package functionality, so it has no Jasmine specs; it is validated by the release run below.
• My changes do not introduce new warnings or errors

Additional Context

Ran scripts/build-sbom.js end to end locally against the current packages (15.8.2 / 22.2.1582). All five SBOMs and the build-environment SBOM validated against CycloneDX 1.6, and the overall README rendered with every package. Findings:

• @igniteui/mcp-server declared no license in its package.json, so its SBOM component had none. Fixed in this PR by declaring MIT, as its README states.
• Before the merge from master bumped zod to ^4.6.6, npm audit reported a high-severity advisory in zod, reached through @igniteui/mcp-server (and so also through igniteui-cli). The next release run's supply-chain notes will show whether the bump clears it.

Validated with a dummy release (previous revision; a re-run against this revision is pending). A 0.0.0 GitHub release in this fork ran the workflow with publish disabled and the versions temporarily set to 0.0.0 (both since reverted; packages are back at 15.8.2). All jobs succeeded. Checked:

• All 27 expected release assets: per package, the tarball, .sha256, .sha512, SBOM and SBOM attestation bundle, plus the SBOM archive and the provenance bundle. Every digest matches its tarball.
• Each SBOM is rooted on the published package (purl, MIT license, tarball hashes), has no unreachable components, and resolves workspace siblings to the tarballs of the same build.
• gh attestation verify passes for every tarball with both the provenance and CycloneDX predicate types, bound to the release tag, commit and run. The attested SBOMs match the released ones.
• The supply-chain section was added to the release notes without changing the authored text.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

[turbobobbytraykov]

@kdinev , do you need the accompanying README.MD file like the one we have for the full product (https://static.infragistics.com/marketing/Website/compliance/sbom/Angular/README.md) ?

If we don't need that README for the igniteui-cli package family/group, I'll remove all of the files necessary for generating it.

[coveralls]

coverage: 94.582%. remained the same — turbobobbytraykov:btraykov/sbom-generation into IgniteUI:master

[kdinev]

@kdinev , do you need the accompanying README.MD file like the one we have for the full product (https://static.infragistics.com/marketing/Website/compliance/sbom/Angular/README.md) ?

If we don't need that README for the igniteui-cli package family/group, I'll remove all of the files necessary for generating it.

Yes, please, we need the README. Don't remove it from generation.