# **Threat Modeling Template for Libraries**

This template builds on the fundamentals of threat modeling, tailoring them for the unique context of an open-source library. Libraries are building blocks; their security impacts every application that uses them. Thinking like an attacker about your library is a critical step in providing a robust, trusted component to the ecosystem.

### **Key Differences for Libraries**

* Consumers are Developers: Your users are other developers integrating your code. They rely on your library's integrity and correct behavior.  
* Integration Points are APIs: The primary interface for attack and misuse is often your public API.  
* Supply Chain Risk: Your dependencies are your dependencies' dependencies, and so on.  
* Side Effects & Resource Usage: Unintended consequences or excessive resource consumption can impact host applications.

### **The STRIDE Threat Categorization**

We'll use STRIDE, a widely adopted framework, to help identify common types of threats:

* **S**poofing: Impersonating someone or something else (e.g., faking identity).  
* **T**ampering: Modifying data or code (e.g., altering a file, changing network packets).  
* **R**epudiation: Denying an action that occurred (e.g., a user denies making a transaction).  
* **I**nformation Disclosure: Revealing sensitive data to unauthorized individuals (e.g., leaking PII, credentials).  
* **D**enial of Service: Preventing legitimate users from accessing a service or resource (e.g., crashing a server, exhausting resources).  
* **E**levation of Privilege: Gaining unauthorized access to higher-level permissions (e.g., a regular user becoming an administrator).

## **Threat Model**

### **1. Library Overview**

* Library Name: **Two.js**
* Brief Description: Two.js is a lightweight, renderer-agnostic 2D drawing library that provides a scene graph abstraction over multiple rendering backends (SVG, Canvas2D, WebGL). It solves the problem of writing portable vector / shape animation code once while letting developers switch or optimize the underlying renderer with minimal changes. It emphasizes an intuitive API for creating, grouping, transforming, styling, and animating vector primitives.  
* Core Paradigm: Retained-mode scene graph (groups and shapes persist between frames) with an imperative mutation API and an explicit or automatic update loop.  
* Key Public APIs / Constructors / Namespaces:  
  - `new Two(options)` – Create a Two.js instance (specifying `type`, `width`, `height`, `domElement`, `autostart`, etc.).  
  - Factory / shape creation helpers: `two.makeRectangle`, `two.makeCircle`, `two.makeEllipse`, `two.makePolygon`, `two.makePath`, `two.makeLine`, `two.makeCurve`, `two.makeGroup`, `two.makeText`, `two.makeSprite`, `two.makeImageSequence`, `two.load` (for SVG / image imports where available).  
  - Scene mutation: `group.add(child)`, `group.remove(child)`, `two.add(shape)`, property assignments (`shape.fill`, `shape.stroke`, `shape.opacity`, `shape.linewidth`, `shape.visible`, `shape.translation`, `shape.rotation`, `shape.scale`).  
  - Animation / loop control: `two.play()`, `two.pause()`, `two.update()`, event listeners (`two.bind('update', fn)`, `two.bind('resize', fn)`).  
  - Utility / export: `two.renderer`, `two.scene`, `shape.clone()`, `shape.noFill()`, `shape.noStroke()`.  
  - Collections: `two.scene.children` (Collection wrapper), `group.children`.  
  - Vector / math primitives: `Two.Vector`, `Two.Anchor`, transformation matrix application via properties.  
* Typical Usage Flow: Instantiate -> Create shapes -> Group / style -> Start animation loop (autostart or manual `update`) -> Mutate properties per frame -> Renderer updates output surface.  
* Out of Scope (Current Model): Advanced plugin ecosystem, experimental renderers not in core distribution, server-side rendering scenarios (Node + headless GL), non-standard forks.  
* Maintainer Context: Sole maintainer; release / build / dependency decisions centralized—heightens importance of supply chain, CI integrity, and key management.  


### **2. Define Scope**

Scope Focus (Current Session):

1. Core Scene Graph & Mutation Layer (Groups, Shapes, Anchors, property setters, cloning).
2. Public Factory Methods (`make*` functions) and their parameter handling / validation.
3. Rendering Abstraction Dispatch (selection & invocation of SVG / Canvas2D / WebGL backends) – not deep-diving into internal renderer implementation specifics, but reviewing trust interfaces.
4. Update / Animation Loop Execution Path (`two.update()`, bound `update` events) including traversal, matrix computations, and draw command emission.
5. External Resource Ingestion: Basic SVG path / image / font references where passed through existing helper methods (no extended parsing plugin deep dive).
6. Build & Distribution Pipeline: Generation of `two.js`, `two.min.js`, `two.module.js` from `src/` and publishing steps (risk of supply chain tampering, artifact integrity).

Explicitly Out of Scope (Deferred):
* Experimental / legacy examples under `junk/` or `extras/` beyond noting they may expand attack surface if shipped or copied by consumers.
* Non-browser environments (Node.js + headless GL) – different threat profile (file system, process-level concerns).
* Third-party downstream integrations (framework wrappers) not maintained in this repository.

Assumptions for This Model:
* Consumers integrate via standard bundlers or direct `<script>` tags; no privileged browser extensions.
* Browsers enforce origin policy and standard DOM / WebGL security constraints.
* No secrets handled by the library; sensitive data risk centers on inadvertent propagation of caller-provided data.


### **3. Conceptual System Diagram**

Visualize your library's interaction points (use [Mermaid](https://mermaid.live/) or a sketch on paper). This might include:

* Caller Application: The code integrating your library.  
* Your Library's Core Logic: The main processing unit.  
* External Dependencies: Other libraries your library uses.  
* Data Sources/Sinks: Where your library gets data from, or sends data to (even if indirectly, through the caller).  
* Trust Boundaries: Where does your library implicitly trust its caller? Where does it trust its dependencies? (e.g., does it trust all input from the caller? Does it assume its dependencies are always safe?).

*Self-reflection: How does your library receive input? What does it output? What assumptions does it make about its environment?*

#### Two.js Conceptual System Diagram

Two.js is a 2D scene graph + rendering abstraction that lets a caller (developer code) create and manipulate vector shapes and text, then render them through one of several renderer backends (SVG / Canvas2D / WebGL). The core security- and integrity-relevant elements are:

- Public API Surface (`new Two(options)`, `two.add(shape)`, `two.makeXXX()`, `two.update()`, shape mutation properties) – primary untrusted input channel.
- Scene Graph (Root Group -> Groups -> Shapes -> Anchors / Vertices) – internal state derived from caller input; integrity critical.
- Render Loop (`requestAnimationFrame` callback or manual `two.update()`) – transforms scene state into drawing commands.
- Renderer Abstractions: SVG DOM Manipulation, Canvas2D Context Commands, WebGL Program / Buffer Operations – interface with browser subsystems.
- External Resources: Images (HTMLImageElement), Fonts (via CSS / browser), JSON / SVG import data – indirect data sources potentially attacker-controlled if caller passes them.
- Environment APIs: Browser DOM, WebGL context, Timing (`performance`, `requestAnimationFrame`), possibly OffscreenCanvas – assumed trustworthy but may be leveraged for DoS (performance abuse) or info disclosure (timing side channels) if misused.
- Output Surfaces: DOM Nodes (SVG), `<canvas>` pixel buffer, WebGL framebuffer – observed by end user; side effects limited to rendering but may leak internal structure via generated SVG markup or error messages.
- Optional Extensions / Plugins (`extras/arc.js`, `extras/zui.js`) – broaden attack surface if they parse additional input or attach event listeners.

Trust Boundary Highlights:
1. Caller Code -> Two.js Public API (All arguments are untrusted; must validate types / ranges to prevent resource exhaustion).
2. Two.js Internal Scene State -> Renderer Backend (Assumes sanitized numeric geometry; malformed values could cause performance degradation or exceptions).
3. External Resource Loading (Images / Imported SVG / JSON) -> Parsing / Texture Upload (Potential for large memory usage or maliciously crafted SVG path strings if importer exists).
4. Build / Distribution Pipeline -> Published Artifacts (Integrity of distributed `two.js` / `two.min.js`).

Primary Data Flows (Simplified):
Caller Input -> API Methods -> Scene Graph Mutation -> Frame Update Traversal -> Backend Draw Calls -> Output Surface.

##### Mermaid: Structural Flow & Trust Boundaries

```mermaid
flowchart LR
  subgraph A[Caller Application Code]
    UI[User Events / App Logic]
    API_Calls[Two.js API Calls: makeShape, add, set properties]
  end

  subgraph B[Two.js Core]
    SG[Scene Graph: Groups, Shapes, Elements, etc.]
    Loop[Update / Animation Loop]
    Utils[Math / Utils]
  end

  subgraph C[Renderer Backends]
    SVG[SVG Renderer]
    CAN[Canvas2D Renderer]
    GL[WebGL Renderer]
  end

  subgraph D[Browser / External]
    DOM[DOM APIs]
    GPU[WebGL / GPU]
    IMG[Images / Fonts / Imported Data]
    Time[requestAnimationFrame]
  end

  UI --> API_Calls
  API_Calls --> SG
  IMG -->|resource refs| API_Calls
  SG --> Loop
  Time --> Loop
  Loop -->|traverse| SG
  Loop -->|draw commands| SVG
  Loop -->|draw commands| CAN
  Loop -->|buffers & shaders| GL
  SVG --> DOM
  CAN --> DOM
  GL --> GPU
  GPU --> CAN

  classDef boundary stroke:#d33,stroke-width:2,stroke-dasharray:4 4;
  class A,B,C,D boundary;
```

Notes:
- Dashed red boxes represent high-level trust zones; most validation must occur at the A->B interface.
- The `IMG` / external resource node is untrusted even though it sits within Browser; treat resource-derived geometry / pixel data as hostile until validated (dimensions, type, size caps).

##### Mermaid: Typical Frame Update Sequence

```mermaid
sequenceDiagram
  participant Caller
  participant Two as Two Instance
  participant SG as Scene Graph
  participant R as Renderer
  participant Browser as Browser APIs

  Caller->>Two: mutate shapes / set properties
  Two->>SG: apply changes
  Caller->>Two: two.update()
  Two->>SG: traverse & compute matrices
  Two->>R: issue draw instructions
  R->>Browser: DOM / Canvas / WebGL ops
  Browser-->>R: success / errors
  R-->>Two: completion
  Two-->>Caller: frame rendered
```

Security / Integrity Considerations (Anchored in Diagram):
- Input Validation: Constrain numeric values (e.g., stroke widths, vertex counts) to avoid pathological loops or memory spikes.
- Resource Limits: Cap imported image / SVG size & complexity (vertex count) before insertion into SG.
- Error Hygiene: Avoid leaking internal stack traces through thrown errors during traversal / rendering.
- Renderer Choice: Selecting WebGL exposes GPU memory & shader compilation errors—wrap and sanitize messages.
- Mutation Control: Provide immutable export serialization paths to prevent caller tampering with internal references after freeze (if implementing hardening).
- Timing: Avoid using high-resolution timing differences to conditionally branch in ways that could leak geometry structure (low risk but noted).

Assumptions:
- Browser environment is not intentionally malicious but can be a vector for performance constraints.
- Caller code may pass arbitrary data; no implicit trust in provided geometry, strings, or resource handles.
- Distribution artifacts served over a trusted channel (e.g., integrity attributes or package registry checks) to prevent supply chain tampering.


### **4. Identify Assets**

Asset Inventory (Two.js Specific):

1. API Integrity & Semantics: Deterministic, documented behavior of shape construction, mutation, and rendering order.
2. Scene Graph Consistency: Internal data structures (hierarchies, vertex arrays, transformation matrices) free from corruption or unintended shared references.
3. Rendering Stability & Performance: Predictable frame times; avoidance of unbounded loops, runaway allocations, GPU state thrash, or layout trashing (SVG DOM bloat / Canvas overdraw).
4. Distribution Artifacts: Authentic `two.js`, `two.min.js`, `two.module.js` files (no injected malicious code) – includes minified integrity.
5. Build / Release Credentials: Access tokens / signing keys (if introduced) and CI configuration controlling publication.
6. Dependency Baseline: Integrity and security posture of direct dependencies (if any) and build tooling (bundler, minifier, transpiler) to prevent supply chain compromise.
7. Error Channel Hygiene: Console / thrown error content not leaking internal structure or repository paths enabling targeted exploitation.
8. Resource Handling Boundaries: Limits around imported SVG path complexity, image dimensions, or vertex counts to prevent memory / CPU exhaustion.
9. Maintainer Reputation: Trust relationship with downstream ecosystem—core to adoption and risk management.
10. Downstream Consumer Safety: Ensuring Two.js is not a vector enabling XSS (via unsafe SVG injection) or WebGL-based fingerprinting escalation beyond normal browser constraints.

Non-Assets / Low Sensitivity (Still Monitored):
* Transient numerical calculations (intermediate matrices) – important for correctness, low direct attacker value.
* Non-secret configuration values (renderer type, width/height) – can be tampered with for DoS but not confidentiality.


### **5. Identify Threats**

Approach: Enumerate critical components & flows. For each STRIDE category, phrase a concrete potential issue. (Blank cells = not materially applicable in this context.)

| Component / Interaction | Spoofing (S) | Tampering (T) | Repudiation (R) | Info Disclosure (I) | DoS (D) | Elev. Priv. (E) |
| :-- | :-- | :-- | :-- | :-- | :-- | :-- |
| Instance Initialization (`new Two(options)`) | Faked `domElement` reference causing unexpected attachment | Malformed options override internal defaults (e.g., negative dimensions) | Caller denies altering options later | Logging of internal fallback decisions | Huge width/height triggers large buffer allocations | (N/A) |
| Shape Factories (`makePolygon`, `makePath`, etc.) | (N/A) | Excessive / malformed vertices mutate global arrays or cause numerical instability | Caller denies adding shape causing downstream state | Error text reveals internal vertex processing | Extremely large vertex counts or recursion in curves consume CPU | (N/A) |
| Scene Graph Mutation (`add/remove`, property sets) | (N/A) | Reassigning references causing unintended shared state; injection of rogue objects posing as shapes | Lack of audit trail for who mutated state in multi-plugin context | Exposed internal structure via serialization / debug output | Tight mutation loop each frame causing GC churn | (N/A) |
| Update Loop (`two.update()`) | (N/A) | Insertion of user-supplied callback altering traversal order | Caller denies having hooked an update callback that caused issue | Stack traces leak path to internal modules | Infinite loop / heavy per-frame computation blocks UI | (N/A) |
| Renderer Selection (SVG/Canvas/WebGL) | Spoofed type constant triggers unexpected code path | Overwriting renderer instance state pre-draw | (N/A) | WebGL error logs reveal driver / extension info | Forcing WebGL fallback thrash leads to performance collapse | Potential abuse of WebGL context to access extended capabilities (low) |
| SVG Output (DOM nodes) | (N/A) | Mutation of generated SVG DOM externally breaks invariants | (N/A) | Reading raw SVG reveals scene graph structure | Very deep/grouped SVG leads to layout thrash | (N/A) |
| WebGL Path (buffers, shaders) | (N/A) | Crafted data feeds large buffer uploads repeatedly | (N/A) | Timing of shader compile errors leaks complexity | Large textures / buffers exhaust GPU memory | (Browser sandbox restricts elevated privileges) |
| External Resource Loading (images/SVG import) | Spoofed resource URL masquerading as trusted path (caller-supplied) | Malicious SVG path data alters internal anchor arrays | Caller denies having loaded large asset | Metadata (dimensions) exposes assumptions; error reveals loader internals | Oversized images / recursive SVG cause memory/CPU spike | (N/A) |
| Dependency / Build Tooling | Typosquatting package name introduced | Modified build script injects code into bundle | Maintainer denies publishing compromised version | Build logs expose environment variables | Build system loop blocked by malicious test script | Compromise of CI runner leads to full pipeline control |
| Distribution (npm / CDN) | Spoofed package using similar name | Repacked `two.min.js` with hidden payload | (N/A) | Minified source map leaks path structure if published inadvertently | Flood of fake versions confuses consumers | (If signing introduced, stolen key misuse) |
| Error Handling / Logging | (N/A) | User overrides `console` to alter perceived errors | Caller denies seeing a thrown error | Detailed error surfaces internal code lines | Excess logging volume degrades performance | (N/A) |
| Extensions / Plugins (`extras/*`) | Malicious plugin claims to be official | Plugin mutates core prototypes | (N/A) | Plugin leaks scene data externally | Heavy plugin loop stalls frame | Plugin executes privileged APIs if environment misconfigured |

Observations:
* Repudiation mostly low concern in single-tenant, in-process library usage but noted where debugging disputes may arise.
* Elevation of Privilege is constrained by browser sandbox; primary risk is expanded surface via WebGL extensions or plugin misuse rather than privilege escalation in classic sense.
* DoS vectors dominate (unbounded geometry, large resources, per-frame heavy callbacks).


### **6. Mitigation/Countermeasures**

| Threat (Summary) | Proposed Mitigation / Control |
| :-- | :-- |
| Oversized canvas / dimensions (Init) -> Memory strain | Enforce sane max width/height defaults; clamp dimensions; document limits. |
| Malformed options overriding internal defaults | Validate option types; fallback silently with minimal info leakage; unit tests for boundary values. |
| Excessive vertices in shape factories | Add soft cap (warn) and hard cap (truncate or reject) on vertex count; iterative subdivision control. |
| Rogue object passed to `add()` (shape impersonation) | Duck-type minimal shape interface & freeze trusted prototypes; optionally symbol-tag internal classes. |
| Shared mutable references (clone pitfalls) | Deep clone vertices/anchors; document immutability expectations in cloning API; add tests. |
| User callback tampering traversal order | Isolate internal traversal from external callbacks; run user callbacks after internal state commit. |
| Infinite loop in user `update` handler | Provide watchdog (frame time threshold warning); recommend dev tooling snippet; doc guidance. |
| Renderer type spoof -> unexpected code path | Enum-check renderer types; fallback to safe default; log single concise warning. |
| SVG DOM mutated externally causing corruption | On each update, recompute critical attributes rather than trusting existing DOM; avoid relying on outer structure. |
| Large buffer / texture uploads (WebGL) | Enforce maximum texture size (query context caps); early reject oversize images; reuse buffers. |
| Malicious / huge SVG import (path explosion) | Pre-parse to count segments; reject if above threshold; limit recursion depth; timebox parsing. |
| Image resource exhaustion | Inspect `naturalWidth/Height`; reject > configured maximum; allow user override via option. |
| Typosquatted dependency injected during build | Pin exact versions; use lockfile; periodically audit with `npm audit` & manual diff review. |
| Build script tampering | Require code review / signed commit for release branch; keep build script minimal & monitored (checksum). |
| Distribution artifact alteration pre-publish | Generate SHA256 checksums; optionally provide Subresource Integrity (SRI) hashes in README. |
| Stolen publish token | Rotate tokens regularly; move to scoped automation token with least privilege; enable 2FA. |
| Error messages leak internals | Centralize error formatting; strip stack traces in production build; map internal names -> generic labels. |
| WebGL driver / extension info leakage | Avoid logging full extension lists; only expose minimal capability flags. |
| Plugin prototype pollution (`extras/*`) | Avoid modifying native / core prototypes; isolate plugin namespaces; add lint rule forbidding prototype writes. |
| High CPU from deep scene graph | Offer `maxDepth` traversal guard (warn); encourage flattening via docs; provide profiling helper. |
| Large SVG group causing layout thrash | Batch DOM writes (fragment or requestAnimationFrame batching); minimize attribute churn. |
| Unbounded logging DoS | Throttle repetitive warnings; single aggregated warning for repeated invalid inputs. |
| CI compromise leads to malicious release | Principle of least privilege CI; artifact build in ephemeral environment; verify checksum post-build before publish. |
| Source map leaking internal structure | Exclude source maps from production CDN by default; offer opt-in debug build. |
| GPU memory exhaustion via repeated shape->buffer churn | Implement geometry caching & eviction policy; reuse buffers where possible. |
| Timing side channel (low risk) | Avoid conditional branching on secret (none present); keep operations uniform per vertex batch. |
| Lack of audit for published bundle | Automated diff (size & AST-level) from previous release; fail build on unexpected large diffs. |
| Maintainer key single point of failure | Store recovery codes offline; document emergency revocation workflow; consider secondary maintainer onboarding plan. |

Future / Optional Hardening (Not Yet Implemented):
* WASM Offloading Guard: If adding WASM modules, sandbox inputs & impose execution time budget.
* Freeze Core Prototypes in Production: `Object.freeze(Two.Shape.prototype)` etc., after initialization for tamper resistance.
* Integrity Metadata: Publish a signed manifest listing artifact hashes.


### **7. Risk Ranking (Optional, but Recommended)**

Risk Levels (Qualitative Matrix):
* High: Readily triggerable by typical consumer misuse or modest attacker effort AND materially degrades consumer app (crash, unresponsive UI) or compromises supply chain trust.
* Medium: Requires atypical usage pattern OR yields moderate performance / reliability impact.
* Low: Improbable, low impact, or already substantially mitigated by platform sandbox.

| Threat (Condensed) | Likelihood | Impact | Risk | Rationale |
| :-- | :-- | :-- | :-- | :-- |
| Unbounded vertex count | High | High | High | Easy to supply huge arrays, leads to CPU & memory pressure. |
| Oversized images / SVG import | High | High | High | Common asset pipeline; large dimensions exhaust memory / layout. |
| Infinite loop in user update callback | Medium | High | High | Not default path but frequent custom animation code pattern. |
| Supply chain: compromised release token | Medium | High | High | Single maintainer; credential theft yields malicious distribution. |
| Build script tampering | Medium | High | High | Script executes during release; moderate barrier. |
| Rogue object injection into scene | Medium | Medium | Medium | Needs shape interface mimic; can corrupt traversal. |
| Renderer type spoof / fallback churn | Medium | Medium | Medium | Causes performance degradation; moderate ease. |
| SVG DOM external mutation | Medium | Medium | Medium | Downstream code often manipulates DOM; may desync state. |
| Large buffer / texture churn (WebGL) | Medium | Medium | Medium | Requires WebGL mode; performance/resource impact. |
| Excessive logging DoS | Medium | Low | Medium | Flooded console harms performance; trivial to trigger. |
| Typosquatted dependency | Low | High | Medium | Impact severe if occurs; likelihood reduced with pinning. |
| Error leaks internal structure | Medium | Low | Medium | Minor info disclosure; debugging paths. |
| GPU memory exhaustion | Low | High | Medium | Needs intentional heavy data; some users could inadvertently hit. |
| Timing side channel | Low | Low | Low | No secrets processed; minimal leverage. |
| Prototype pollution via plugin | Low | Medium | Low | Extras not always loaded; requires malicious plugin adoption. |
| Source map unintended exposure | Low | Low | Low | Sensitive only for structural hints; low exploit value. |
| WebGL driver info leak | Low | Low | Low | Browser already restricts; adds little attacker advantage. |
| Maintainer key single point of failure | Low | High | Medium | Catastrophic if lost; less likely with good hygiene. |

Priorities (Action Order): 1) Geometry / resource bounding, 2) Release credential hardening, 3) Build script minimalism & auditing, 4) Scene graph integrity guards, 5) Logging throttling & error hygiene, 6) Optional hardening (prototype freeze, signed manifest).


### **8. Next Steps & Review**

Immediate Action Plan (0–2 Weeks):
1. Implement geometry / vertex / image bounding (hard + soft caps) with warnings & docs.
2. Add centralized input validation utilities for factory methods; integrate in all `make*` APIs.
3. Harden release pipeline: rotate publish token, enable 2FA enforcement, document checksum generation + publish hashes.
4. Add logging throttle & single-warning aggregator for repetitive invalid inputs.
5. Create automated size & diff check in build (fail on anomalous delta > threshold %). 

Short Term (1–2 Months):
1. Prototype scene graph traversal guard (max depth detection + warning).
2. Introduce optional production hardening flag to freeze core prototypes post-init.
3. Add fuzz tests (lightweight) for path / polygon creation with random vertex sets.
4. Provide resource limit configuration surface (`two.config.limits`).

Medium Term (Quarterly):
1. Evaluate adding signed manifest + SRI hash publishing script.
2. Assess feasibility of adding secondary maintainer or emergency recovery process.
3. Benchmark performance baseline & document guidance for large scenes.

Ongoing Maintenance Cadence:
* Threat Model Review: Every major / minor release or quarterly (whichever sooner).
* Dependency & Tooling Audit: Monthly (`npm audit`, manual diff of lockfile, check typosquats).
* Release Checklist: Validate checksums, run diff size gate, ensure validation tests pass, rotate token annually.
* Incident Response Drill: Simulate compromised artifact scenario annually—validate revocation & notification workflow.

Monitoring / Telemetry (Non-invasive):
* Provide optional hook to collect (opt-in) anonymized stats: scene object counts, average vertex counts—inform future caps (ensure no PII / URLs).

Documentation Enhancements:
* Add SECURITY.md guidance on reporting issues & current hardening status.
* Update README with performance & limit recommendations once caps implemented.

Exit Criteria for This Iteration:
* All High-risk items have at least one implemented mitigation or a clearly documented deferral rationale.
* Build pipeline emits artifact hashes reproducibly.

Review Trigger Conditions:
* Introduction of new renderer backend.
* Addition of parsing-heavy feature (e.g., full SVG importer expansion, WASM module).
* Significant architectural refactor (scene graph storage, batching system).

Deferral Rationale Log (Track in Repo Issue):
* Signed release manifest (cost: setup complexity) – deferred until stable hash automation baseline exists.
* Prototype freeze default (developer ergonomics concern) – gated behind prod flag initially.


**Tips for Your First Threat Model:**

* Start Small: Don't try to model your entire project at once. Pick a critical feature or a new component.  
* Keep it Simple: A simple sketch is better than no diagram. A few identified threats are better than none.  
* Collaborate: Talk to your co-maintainers or a trusted peer. Different perspectives reveal different threats.  
* Don't Aim for Perfection: You won't catch everything the first time. The process itself builds your security mindset.

**Remember:** Your library is a trust anchor for many projects. By dedicating time to threat modeling, you enhance not just your own project's security, but the security of the entire open-source ecosystem.