feat: Add security threat model

[turbobobbytraykov]

Closes #344

Description

Adds two documents — the first threat model for IgniteUI.Blazor.Lite and IgniteUI.Blazor.Templates, 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.

Motivation / Context

This PR establishes a maintained threat model and a repeatable security-review record for both packages. The dated review and findings register follow after the model is merged and the High-severity items are resolved — see Next steps.

The model is therefore structured against Microsoft's own Blazor threat-mitigation guidance, with the document shape taken from the CNCF/OpenSSF self-assessment format. It uses the same threat IDs as the model in IgniteUI.Blazor.GridLite, so the two can be reviewed and maintained together.

How to read it

STRIDE applied to three trust boundaries — server→client serialization (TB1), the managed→WASM unmarshalled path (TB1b, unique to this repo), and client→server JS interop (TB2). Every threat has an ID, a severity and a status. Severity is the residual severity after the stated assumptions, which matters: most interop threats presuppose attacker script in the page, and per Microsoft's guidance an XSS-compromised client can already forge interop calls. Our obligation is to not cause XSS and to not widen the blast radius — the findings below are judged on that basis.

The two packages are modelled separately because their risk is different in kind: Lite is a runtime interop surface; Templates is a supply-chain and secure-defaults surface.

One thing worth flagging because it looks alarming and is not: Microsoft's guidance names AddMarkupContent as an XSS vector, and DynamicContentHolder calls it. Every call site was checked — all pass static whitespace literals, never user data. Recorded as Verified — no finding so reviewers do not have to re-derive it.

What it found

IgniteUI.Blazor.Lite

ID	Finding	Sev
TM-IX-01	WebCallback is public and its per-control [JSInvokable] methods key off a client-supplied containerId into the scoped runtime's control map — a caller reaching the reference can drive event raising and dynamic-content mutation on another registered control in the same scope	High
TM-MEM-01	RuntimeHelper reflection-discovers InvokeUnmarshalled, compiles a delegate, and calls it from unsafe code passing raw WASM-heap pointers (AllowUnsafeBlocks=true). A layout mismatch is memory corruption, not an exception	High
TM-SC-02	CodeQL default setup is enabled, but there is no dependency-review or npm audit gate in CI	Medium
TM-SER-01 / TM-IX-05	Full object graph serialized to the client; untrusted event args reach consumer handlers	High (consumer-facing)
TM-DOM-01	No unsafeHTML usage was found in this repository, but the rendering behavior of the bundled igniteui-webcomponents dependency still needs confirmation	TBD
TM-IX-02 / -03	OnInvokeReturn takes untyped object; AdjustDynamicContentBatch deserializes a client-supplied batch string and drives render-tree mutation	Medium
TM-BLD-01	${{ env.BUILD_CONFIGURATION }} is referenced in the release signing/validation steps but never defined — it expands to empty, so the integrity gate scans src/bin/ instead of src/bin/Release/. It only works because the recursive glob still reaches the Release output	Medium
TM-BLD-02	"Validate DLL signatures" passes when zero DLLs are found — an empty result set does not fail the gate	Medium

IgniteUI.Blazor.Templates

ID	Finding	Sev
TM-PKG-01	NoDefaultExcludes=true plus a broad Content Include excluding only bin/obj packs everything else in the tree — dotfiles, .env, editor state — into the shipped package	High
TM-TPL-01	The scaffolded app has HSTS, HTTPS redirection and antiforgery, but defines no CSP and loads an external Google Fonts stylesheet without SRI	Medium
TM-TPL-02	Template-pinned package versions drift and go stale	Medium
TM-TPL-03	<Version>0.0.1</Version> hard-coded rather than driven by the release tag	Low

Existing controls include CodeQL default setup, SHA-pinned release actions, Azure OIDC, NuGet Trusted Publishing, signing with verification gates, package-manager-cache: false in release builds, deterministic builds, central package management, Dependabot with a cooldown, and a complete SECURITY.md with private reporting and stated SLAs.

What we need from you to approve

You do not need threat-modelling experience. Please check four things:

1. Scope and assumptions (§2, §5) — is anything mis-scoped, and are assumptions A1–A6 ones we can stand behind during review?
2. Factual accuracy (§6, §7) — each threat cites concrete code. Flag anything that misreads the implementation. TM-IX-01 and TM-MEM-01 especially: if there is an existing constraint that limits them, it belongs in the document.
3. TM-DOM-01 — someone who knows the igniteui-webcomponents rendering path needs to confirm whether unsafeHTML (or equivalent) is used for any bound value. No such use was found in this repository, but the dependency's rendering path still blocks sign-off.
4. Residual risk (§9) — four risks are proposed as accepted. Approving this PR means agreeing they are acceptable; you will be named as approver.

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. TM-IX-01 — hardening plan for WebCallback: reduce its public surface and bind callbacks to the instance that owns them rather than to a client-supplied key. This is a code change and the largest item in the model.
2. TM-MEM-01 — either document a justification for the unmarshalled path with the invariants it relies on, or scope-limit it behind an explicit opt-in.
3. TM-SC-02 — add a dependency-review or equivalent dependency-risk gate to CI; CodeQL default setup is already enabled.
4. TM-PKG-01 — explicit exclude list for the template pack plus a CI assertion on the package contents.
5. TM-TPL-01 — define and test the scaffolded app's CSP and external-resource policy.
6. TM-BLD-01 / -02 — define BUILD_CONFIGURATION and fail the signature gate on an empty result set.
7. Add a "Security considerations" section to the README covering TM-SER-01 and TM-IX-05. These are consumer responsibilities and become our findings if undocumented.
8. Hold the security review using docs/security/review-template.md (its findings registers are already pre-populated from the threat model) and record it as docs/security/review-<package>-<version>.md.

References

Primary — Microsoft

• Threat mitigation guidance for ASP.NET Core Blazor interactive server-side rendering — the anchor document; the source of "treat any .NET method exposed to JavaScript as a public endpoint" and of the AddMarkupContent XSS warning
• 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
• dotnet/aspnetcore SECURITY.md and microsoft/fluentui-blazor SECURITY.md — Microsoft's own Blazor library disclosure policy; note that neither repository publishes a threat model

Document format

• CNCF TAG-Security — self-assessment guide (repo archived Dec 2025; format still the de-facto standard)
• OpenSSF Security Insights specification — machine-readable security-insights.yml; a candidate follow-up
• OWASP Threat Modeling Cheat Sheet

Supply chain / build integrity

• GitHub — Security hardening for GitHub Actions
• OpenSSF Scorecard and OpenSSF Best Practices badge
• SLSA — Supply-chain Levels for Software Artifacts
• NuGet Trusted Publishing
• dotnet new custom templates — for the template packaging findings

Type of Change (check all that apply):

• Bug fix
• New functionality
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactoring (no functional changes)
• Documentation
• Demos
• CI/CD
• Tests
• Changelog

Component(s) / Area(s) Affected:

How Has This Been Tested?

• Unit tests
• Manual testing
• Automated e2e tests

Test Configuration:

• .NET version:
• Hosting model:
• Browser(s):
• OS:

Screenshots / Recordings

Checklist:

• All relevant tags have been applied to this PR
• This PR includes unit tests covering all the new code
• This PR includes API docs for newly added methods/properties
• This PR includes general feature table updates in the root README.MD
• This PR includes CHANGELOG.MD updates for newly added functionality
• This PR contains breaking changes
• This PR includes behavioral changes and the feature specification has been updated with them
• Accessibility (ARIA, keyboard navigation, focus management) has been verified

Closes #

[Copilot]

Pull request overview

Adds initial security documentation artifacts for the Ignite UI for Blazor repo: a draft STRIDE-based threat model for IgniteUI.Blazor.Lite / IgniteUI.Blazor.Templates, plus a repeatable security review record template intended to be copied per release.

Changes:

• Added docs/security/threat-model.md documenting scope, trust boundaries, identified threats, and residual/accepted risks.
• Added docs/security/review-template.md providing a structured review checklist and findings register to accompany the threat model during release reviews.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
docs/security/threat-model.md	New threat model document covering architecture, assumptions, threats, and accepted residual risks for Lite/Templates.
docs/security/review-template.md	New template for recording a security review outcome and tracking threat dispositions per package/version.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.