docs: Add security threat model

[turbobobbytraykov]

Add security threat model

Adds two documents — the first threat model for this package, plus the template for the security review that follows it:

• docs/security/threat-model.md
• docs/security/review-template.md

Documentation only; no code changes.

Why this is needed

This PR establishes a maintained record of the package's security boundaries, assumptions, threats, controls, and accepted risks. It also adds a repeatable review record so findings can be resolved or explicitly accepted before release.

The model applies STRIDE at the package's trust boundaries and uses ASP.NET Core Blazor security guidance, OWASP threat-modeling guidance, and the CNCF/OpenSSF self-assessment format as technical references.

How to read it

STRIDE is applied to two trust boundaries: server-to-client serialization (TB1) and client-to-server JS interop (TB2). Every threat has an ID, severity, and status. Severity is the residual severity after the stated assumptions. Most interop threats presuppose attacker-controlled script in the page; the component's responsibilities are to avoid introducing script execution and to avoid unnecessarily widening the impact of other scripts running in the same origin.

Things that could look like findings but are not are verified and recorded so maintainers do not have to re-derive them: the locked igniteui-grid-lite 0.9.0 default cell renderer uses escaped Lit interpolation; there is no MarkupString, AddMarkupContent, or eval; and all JS interop identifiers are hard-coded literals.

What it found

ID	Finding	Sev
TM-SER-01	The serializable TItem object graph is sent to the browser, not just the properties represented by grid columns; consumers can unintentionally disclose sensitive properties	High (consumer-facing)
TM-IX-02	Client-supplied sort and filter expressions reach consumer handlers; injection is possible if an application forwards them into dynamic queries without validation	High (consumer-facing)
TM-IX-01	DotNetObjectReference is stored in a global window.blazor_igc_grid_lite.dotNetRefs map, making the callback reference available to other scripts in the page	Medium
TM-SC-01	igniteui-grid-lite is bundled in the NuGet package, so consumers cannot independently update it when an upstream security fix is released	Medium
TM-BLD-01	checkout / setup-dotnet / setup-node pinned to mutable tags in a job holding id-token: write	Medium
TM-IX-03	A client can repeatedly invoke interop callbacks, causing repeated deserialization and handler dispatch in Blazor Server applications	Low
TM-IX-04	Four callbacks use catch { } with no logging, making malformed callback data difficult to detect and diagnose	Low

Existing controls are recorded as well: CodeQL default setup with the extended query suite, secret scanning with push protection, Dependabot security updates, Private Vulnerability Reporting, signing with verification gates, Azure OIDC, NuGet Trusted Publishing, and npm ci against a committed lockfile.

What we need from you to approve

Please check three things:

1. Scope and assumptions (§2, §5) — is anything mis-scoped, and are assumptions A1–A5 valid for supported consuming applications?
2. Factual accuracy (§6) — each threat cites concrete code. Flag anything that misreads the implementation.
3. Residual risk (§8) — two risks are proposed as accepted. Acceptance requires a recorded justification and named approver in a completed review record.

Leave the <!-- TODO(maintainer) --> placeholders (commit SHA, owner, approver names) — they are filled in at sign-off, not at merge.

Next steps (after merge)

1. Add a "Security considerations" section to the README covering TM-SER-01, TM-IX-02, and the trusted nature of JavascriptPath.
2. Reduce the global lifetime and visibility of the .NET object reference (TM-IX-01), record callback failures (TM-IX-04), and SHA-pin the remaining actions (TM-BLD-01).
3. Add SECURITY.md to document supported versions and direct reporters to GitHub Private Vulnerability Reporting, which is already enabled for this repository.
4. Complete a review using docs/security/review-template.md, resolve or accept each finding, and save the result as docs/security/review-<version>.md.

References

Blazor and threat modeling

• Threat mitigation guidance for ASP.NET Core Blazor interactive server-side rendering
• Call .NET methods from JavaScript functions in ASP.NET Core Blazor
• Call JavaScript functions from .NET methods in ASP.NET Core Blazor
• Enforce a Content Security Policy for ASP.NET Core Blazor
• Microsoft SDL — Threat Modeling
• OWASP Threat Modeling Cheat Sheet
• CNCF TAG-Security self-assessment guide

Supply chain / build integrity

• GitHub — Security hardening for GitHub Actions — basis for the SHA-pinning finding
• NuGet Trusted Publishing

[PureWeen]

A5 describes JavascriptPath as app-controlled, but the current public API doesn't expose it: IgbGridLiteOptions and Options are internal, and [Parameter] is commented out. A Razor Options=... assignment is captured as an HTML attribute rather than configuring this path. Could A5 instead state that the path is currently internal/not consumer-settable, and note that validation would be needed if it's exposed later?