|
1 | 1 | # Security Policy |
2 | 2 |
|
| 3 | +This document describes how to report security vulnerabilities in Ignite UI for Angular and which versions receive security updates. |
| 4 | + |
3 | 5 | ## Supported Versions |
4 | 6 |
|
| 7 | +Ignite UI for Angular releases track the Angular release cadence. We provide security fixes for the latest release and for the long-term supported versions listed below: |
| 8 | + |
5 | 9 | | Version | Supported | |
6 | 10 | | --------- | ------------------ | |
7 | | -| 22.0.x | :white_check_mark: | |
| 11 | +| 22.1.x | :white_check_mark: | |
| 12 | +| 22.0.x | :x: | |
8 | 13 | | 21.2.x | :white_check_mark: | |
9 | 14 | | 21.1.x | :x: | |
10 | 15 | | 21.0.x | :x: | |
|
15 | 20 |
|
16 | 21 | ## Reporting a Vulnerability |
17 | 22 |
|
18 | | -Please report any suspected vulnerability through the [issues](../../issues) section. |
| 23 | +Please **do not** open a public GitHub issue for security vulnerabilities. |
| 24 | + |
| 25 | +Instead, report privately using one of the following methods (preferred first): |
| 26 | + |
| 27 | +1. **GitHub Private Vulnerability Reporting (recommended)** |
| 28 | + - Go to the repository's **Security** tab and use **Report a vulnerability**. |
| 29 | + |
| 30 | +2. **Email** |
| 31 | + - Send details to: **igniteui@infragistics.com** |
| 32 | + |
| 33 | +3. **Support Case** |
| 34 | + - If you are a registered Infragistics user, you can report the vulnerability through a support case at (https://account.infragistics.com/support-cases) |
| 35 | + |
| 36 | +If none of these options is available, contact the maintainers privately. Only use the public issue tracker for **non-security** bugs. |
| 37 | + |
| 38 | +### What to include |
| 39 | + |
| 40 | +To help us triage quickly, include: |
| 41 | + |
| 42 | +- A clear description of the vulnerability and its impact |
| 43 | +- Steps to reproduce (proof-of-concept if possible) |
| 44 | +- Affected versions and/or commit hash |
| 45 | +- The affected package (`igniteui-angular`, `igniteui-angular-i18n`, `igniteui-angular-elements`, etc.) and the component or directive involved |
| 46 | +- Your Angular version and browser, where relevant |
| 47 | +- Any relevant logs or stack traces (sanitize secrets) |
| 48 | +- Your assessment of severity (optional) |
| 49 | +- Suggested fix or mitigation (optional) |
| 50 | + |
| 51 | +### Sensitive information |
| 52 | + |
| 53 | +- Do **not** include secrets, tokens, private keys, or real customer data. |
| 54 | +- If sensitive data is required to demonstrate the issue, redact it and describe the expected format. |
| 55 | + |
| 56 | +## Disclosure Process |
| 57 | + |
| 58 | +After receiving a report, we aim to follow this process: |
| 59 | + |
| 60 | +1. **Acknowledgement**: within **3 business days** |
| 61 | +2. **Triage** (severity assessment + scope): within **7 business days** |
| 62 | +3. **Fix development**: timeline depends on severity and complexity |
| 63 | +4. **Release**: we will publish a patch release and/or mitigation guidance |
| 64 | +5. **Advisory**: we may publish a GitHub Security Advisory (crediting reporters who want it) |
| 65 | + |
| 66 | +We may request additional information during triage. |
| 67 | + |
| 68 | +## Severity and Prioritization |
| 69 | + |
| 70 | +We prioritize issues using impact and exploitability, informed by CVSS where appropriate: |
| 71 | + |
| 72 | +- **Critical**: remote code execution, authentication bypass, significant data exposure |
| 73 | +- **High**: privilege escalation, cross-site scripting that bypasses Angular's sanitization, major denial of service, sensitive information leaks |
| 74 | +- **Medium/Low**: limited impact, edge cases, or hard-to-exploit issues |
| 75 | + |
| 76 | +## Scope |
| 77 | + |
| 78 | +In scope: the packages published from this repository and the code that builds them. |
| 79 | + |
| 80 | +Out of scope, and better reported elsewhere: |
| 81 | + |
| 82 | +- Vulnerabilities in Angular itself — report to the [Angular project](https://github.com/angular/angular/security/policy) |
| 83 | +- Vulnerabilities in third-party dependencies — report to the upstream project; tell us as well if Ignite UI for Angular exposes the issue to consumers |
| 84 | +- Findings that require an application to bypass Angular's built-in sanitization (for example, passing untrusted markup through `bypassSecurityTrustHtml`), unless our components do so on the application's behalf |
| 85 | +- Issues in our sample applications, documentation sites, or infrastructure that do not affect the shipped packages |
| 86 | + |
| 87 | +## Coordinated Vulnerability Disclosure |
| 88 | + |
| 89 | +We support coordinated disclosure and ask that you: |
| 90 | + |
| 91 | +- Give us a reasonable window to fix before public disclosure |
| 92 | +- Avoid exploiting the vulnerability beyond what is necessary to prove it exists |
| 93 | +- Avoid actions that degrade service availability or compromise user data |
| 94 | + |
| 95 | +## Security Updates |
| 96 | + |
| 97 | +Security fixes may be communicated via one or more of: |
| 98 | + |
| 99 | +- GitHub Security Advisories |
| 100 | +- Release notes / [changelog](CHANGELOG.md) |
| 101 | +- npm advisories for the affected packages |
| 102 | + |
| 103 | +## Acknowledgements |
| 104 | + |
| 105 | +We appreciate responsible disclosures. If you'd like public credit, tell us how you want to be acknowledged. |
0 commit comments