CVE Policy and Vulnerability Management

Smile CDR takes security vulnerabilities seriously. This page describes our approach to Common Vulnerabilities and Exposures (CVEs): the guarantees we make per release type, how we continuously monitor for vulnerabilities, and what you can expect when you report a CVE.

CVE Guarantees by Release Type

Smile CDR produces three categories of releases, each carrying different CVE guarantees.

See A Primer on Smile CDR Versioning for a full description of these release types.

How Dependency Vulnerabilities Accumulate Over Time

Like most modern software, Smile CDR is built on top of a large set of open-source libraries — frameworks, parsers, HTTP clients, cryptography providers, database drivers, and so on. Each of these dependencies is its own piece of software, maintained by its own community, and each carries its own potential for security flaws.

A CVE (Common Vulnerability and Exposure) is a publicly disclosed security flaw in a specific version (or range of versions) of a piece of software. CVEs are not discovered all at once when a library is released — they are discovered continuously over the lifetime of that library. A version of a library that has zero known CVEs today may have several known CVEs a year from now, not because the library changed, but because researchers have had more time to find and disclose flaws in it.

This has an important consequence: the older the version of software you run, the more CVEs are likely to apply to it. A release that shipped two years ago was scanned and certified clean against the vulnerability databases that existed at that time. Since then:

• New CVEs have been disclosed against the dependency versions that release pinned.
• Upstream library maintainers have published newer versions that fix those CVEs — but those fixes only reach you when Smile CDR upgrades the dependency, which happens in newer Smile CDR releases.
• Some older dependency versions reach end-of-life and stop receiving security fixes entirely, meaning a CVE against them may never be patched at the source.

In other words, a release does not "rot" because its code changed — it accumulates vulnerabilities because the world's knowledge of flaws in its dependencies grew while the release stood still. Staying on a current Smile CDR release is the most effective way to minimize your exposure, because each new release incorporates the latest vetted versions of its dependencies and is scanned against the latest vulnerability databases before shipping.

Vulnerability Scanning

Smile CDR runs automated vulnerability scans every night against the current build. Multiple vulnerability scanners are used, including:

Any Medium, High, or Critical severity findings are investigated immediately to determine whether a fix is required before the next official release.

Reports from these nightly scans are published on the Smile CDR releases website. The OWASP Dependency-Check report includes a Report Generated On: timestamp and lists the Smile CDR version at the top of the document, so you can confirm the report's currency and the exact version it covers.

Suppressed Vulnerabilities

Some vulnerabilities exist in libraries we depend on but are used in a way that does not expose Smile CDR to any actual risk. After investigation, these vulnerabilities are suppressed — they are excluded from the active findings but remain visible for transparency.

To review suppressed vulnerabilities in the OWASP Dependency-Check report:

1. Open the OWASP Dependency-Check report for your release.
2. Scroll to the bottom of the page.
3. Locate the Suppressed Vulnerabilities heading and click the grey [+] button to expand it.

Each suppressed entry includes a Notes field that explains the rationale: why the vulnerability was investigated, and why it was determined not to be a risk in the context of Smile CDR's usage.

Reporting a CVE

If you identify a CVE that you believe affects your Smile CDR deployment, please report it through your standard support channel. We are likely already aware of the vulnerability, and intend to address it in the next official Quarterly Release.

When a CVE is reported, it is triaged based on the following factors:

• Whether you are on the latest Smile CDR release.
• Whether the CVE appears in the published CVE or OWASP report for your release.
• Whether the CVE has been suppressed (with a documented rationale).
• The severity of the CVE as rated on the NIST National Vulnerability Database.

If the CVE is rated Critical, it is escalated to the engineering team for immediate investigation. CVEs rated Low, Medium, or High are acknowledged and addressed in the normal quarterly release cycle. For CVEs reported against older releases, upgrading to the latest Generally Available release is the recommended course of action — Smile CDR does not backport fixes for non-critical CVEs to older versions.