Ignite UI for Web Components is a client-side UI library published to npm as igniteui-webcomponents. This document explains which versions receive security fixes, how to report a vulnerability, what happens after a report, and how consumers can verify what they install.

Security fixes are released for the latest major version. The previous major version receives fixes for critical vulnerabilities only, published as a patch on its last minor release. Older major versions receive no security updates.

This table is updated with each major release. All released versions are listed on the npm package page and in the CHANGELOG.

In scope:

• The igniteui-webcomponents npm package and all of its entry points, including igniteui-webcomponents/extras.
• The build and release pipeline in this repository, including the workflows under .github/workflows and the scripts under scripts.

Out of scope:

• The hosted Storybook and the product documentation sites. Report issues with those to Infragistics support.
• Vulnerabilities in third-party dependencies that do not affect this package. Report those to the upstream project. If a dependency vulnerability is reachable through this package, report it here as well.
• Commercial Ignite UI for Web Components packages such as igniteui-webcomponents-grids and igniteui-dockmanager. Report those through Infragistics support.

Report vulnerabilities privately through GitHub private vulnerability reporting. Do not open a public issue, discussion or pull request for a security problem. Private reporting gives us time to prepare a fix before the details become public.

A useful report includes:

• The affected component or module and the package version.
• Steps or a minimal reproduction that demonstrates the problem.
• The impact you believe it has, for example script execution in the host page or exposure of data the host page passed to a component.

Severity follows the CVSS rating GitHub attaches to the advisory. We credit reporters in the advisory unless they ask not to be named.

Fixed vulnerabilities are published as a GitHub security advisory with a CVE identifier where applicable, and recorded under a Security heading in the CHANGELOG entry of the release that carries the fix.

Every release published from this repository ships with supply-chain evidence attached to the GitHub release:

• The exact tarball that was published to npm, with SHA-256 and SHA-512 digests.
• A CycloneDX 1.6 SBOM describing the delivered dependency closure, and a supplementary SBOM of the build environment.
• Signed build-provenance and SBOM attestations produced with GitHub artifact attestations.

The package is published with an OIDC token, so npm records provenance for it. To verify the tarball you install matches the one that was built and attested, run:

npm pack igniteui-webcomponents@<version>
gh attestation verify igniteui-webcomponents-<version>.tgz --repo IgniteUI/igniteui-webcomponents
gh attestation verify igniteui-webcomponents-<version>.tgz --repo IgniteUI/igniteui-webcomponents --predicate-type https://cyclonedx.org/bom

The SBOM README attached to each release describes how the SBOM was generated and how to re-validate it.

The components run inside the host page, so the host application remains responsible for the data it passes in. THREAT-MODEL.md describes the trust boundaries, the threats the library addresses and what the host must do, including the handling of chat markdown, icons, host-supplied URLs and Content Security Policy.

Runtime dependencies are kept to a minimum and are listed in the SBOM attached to each release (see Verifying a release). Dependabot raises security updates for npm dependencies daily and version updates for GitHub Actions weekly. GitHub's CodeQL default setup analyzes every push and pull request, and the OpenSSF Scorecard runs weekly; results are visible in the repository's Security tab. The release workflow pins every action to a commit SHA and grants each job only the permissions it needs.