|
| 1 | +# wolfSSL Security Policy |
| 2 | + |
| 3 | +## About This Policy |
| 4 | + |
| 5 | +This document defines how wolfSSL Inc. handles security vulnerabilities in its products: how to report them, how we evaluate them, and how we coordinate disclosure. |
| 6 | + |
| 7 | +## Reporting a Vulnerability |
| 8 | + |
| 9 | +**Use of the wolfSSL Vulnerability Report Template is mandatory.** All security reports must be submitted using [`SECURITY-REPORT-TEMPLATE.md`](SECURITY-REPORT-TEMPLATE.md), with every required field completed. Reports that do not use the template, or that leave required fields incomplete, will not receive CVE consideration. |
| 10 | + |
| 11 | +Submit the completed template to **support@wolfssl.com**. |
| 12 | + |
| 13 | +Non-template submissions may still be reviewed on the merits and, where appropriate, addressed as hardening fixes in a future release. CVE assignment requires a complete template. |
| 14 | + |
| 15 | +We aim to acknowledge reports as they come in and engage with reporters throughout triage. Investigations proceed at the pace the material requires. |
| 16 | + |
| 17 | +## What wolfSSL Treats as a Vulnerability |
| 18 | + |
| 19 | +wolfSSL files a CVE advisory for defects with meaningful security impact on realistic wolfSSL deployments, where exploitability is demonstrated or clearly analyzable. wolfSSL determines whether a finding meets this bar. |
| 20 | + |
| 21 | +We classify confirmed vulnerabilities across four severity tiers: |
| 22 | + |
| 23 | +- **Critical** — Remote, practically exploitable defects in default configurations |
| 24 | +- **High** — Serious defects with realistic exploitability |
| 25 | +- **Medium** — Defects with meaningful impact under favorable conditions |
| 26 | +- **Low** — Defects requiring specialized configurations or narrow deployment scenarios |
| 27 | + |
| 28 | +Reporter-proposed severity is input to the process, not its conclusion. |
| 29 | + |
| 30 | +## What Is Not Considered a Vulnerability |
| 31 | + |
| 32 | +Some defects are typically addressed as bug fixes rather than CVE-eligible vulnerabilities. These include: |
| 33 | + |
| 34 | +- Issues requiring physical access, physical-level side channels, or fault injection |
| 35 | +- Issues the attacker can reach only with capabilities that already grant the outcome |
| 36 | +- Issues reachable only through unsupported or undocumented API use |
| 37 | +- Issues without a working reproducer |
| 38 | +- Availability impact outside narrow protocol-facing cases |
| 39 | + |
| 40 | +wolfSSL determines whether a finding meets the CVE threshold. Findings below the threshold are addressed through normal release channels where appropriate; dispositions may be revisited when new information warrants. |
| 41 | + |
| 42 | +## Out of Scope |
| 43 | + |
| 44 | +- Third-party libraries bundled by customers |
| 45 | +- Non-library code (example programs, test harnesses, developer tools) |
| 46 | +- Documentation errors |
| 47 | +- Performance issues without security implications |
| 48 | + |
| 49 | +## Supported Versions |
| 50 | + |
| 51 | +Security fixes are released for the current stable release and the immediately prior stable release. Older releases receive security fixes only under active commercial support agreements. |
| 52 | + |
| 53 | +## Coordinated Disclosure |
| 54 | + |
| 55 | +We investigate and fix confirmed vulnerabilities privately, coordinate disclosure timing with the reporter, and release the fix and security advisory together. Embargo extensions for ecosystem coordination — downstream integrators, certification bodies, or equivalent — are considered case-by-case. CVE records are published consistent with CVE Program rules. |
| 56 | + |
| 57 | +## Credit |
| 58 | + |
| 59 | +Reporters are credited in the advisory and release notes unless anonymity is requested. Reports are welcome from independent security researchers, academic researchers, and organizations conducting authorized security testing. |
| 60 | + |
| 61 | +Credit text is coordinated with the reporter before publication. |
| 62 | + |
| 63 | +## Contact |
| 64 | + |
| 65 | +- **support@wolfssl.com** — security vulnerability reports and general support |
| 66 | +- **info@wolfssl.com** — general inquiries |
| 67 | + |
| 68 | +Published CVE advisories: https://www.wolfssl.com/docs/security-vulnerabilities/ |
| 69 | + |
| 70 | +## Policy Changes |
| 71 | + |
| 72 | +Material changes to this policy are announced via the wolfSSL blog. The canonical version of this policy is maintained in the wolfSSL GitHub repository. |
| 73 | + |
| 74 | +*Last updated: 2026-04-22* |
0 commit comments