CVE Issuance Policy

Effective Date: August 11, 2026

This policy describes when Human Aspire publishes a CVE record for a vulnerability in software we produce, what each record contains, and how quickly we act. We publish it as part of our commitment under the CISA Secure by Design pledge.

Scope

This policy covers software authored by Human Aspire and operated as part of our services, and the products listed on our website.

Vulnerabilities in third-party components we depend on belong to those projects. Where we discover one, we report it to the maintainer and, if the maintainer is unresponsive and users are at risk, we will request an identifier ourselves.

When we issue a CVE

We request and publish a CVE record for any vulnerability in our own software that meets at least one of the following:

• It is rated critical or high severity and requires an action by a customer to remediate.
• There is evidence of active exploitation, at any severity.
• A reporter asks us to request a CVE for a confirmed finding, at any severity.

This applies whether the vulnerability was found by our own team or reported to us by someone else. The source of the finding never changes whether we publish.

Being a hosted service does not exempt us

Our software runs on infrastructure we operate. Customers install nothing, and a fix is live for everyone at once. That genuinely reduces how often a customer must act — but we will not treat it as a reason to stay silent.

Where we fix a server-side vulnerability that required no customer action and showed no evidence of exploitation, we do not open a CVE by default, because a CVE record describes something a customer can identify and act on. We do notify affected customers directly, and we will still request a CVE if the reporter wants one. We will not decline on the grounds that we patched it quickly.

What every record contains

Every CVE record we publish includes:

• An accurate CWE identifier describing the class of weakness.
• An accurate CPE identifier for the affected product and version range.
• A severity rating and CVSS vector.
• The affected versions, and the version or date at which the fix became available.
• Credit to the reporter, unless they prefer to remain anonymous.

We treat CWE and CPE as required fields rather than optional ones. Where we cannot determine an accurate value, we say so explicitly instead of guessing or leaving it blank — a wrong CWE is worse than an acknowledged gap, because it silently corrupts anyone analyzing vulnerability trends downstream.

Timeliness

• We request a CVE identifier within 5 business days of confirming that a vulnerability meets the criteria above.
• We publish the record once a fix is available, or within 90 days of confirmation, whichever comes first.
• Where there is evidence of active exploitation, we publish as soon as we can do so without increasing risk to users. We do not wait for the 90-day point.

How we obtain identifiers

Human Aspire is not currently a CVE Numbering Authority. We request identifiers through the CVE Program's published process, and we coordinate with the CNA responsible for an affected component where one exists.

Coordination with reporters

If you reported the issue, we will tell you when we request an identifier, share the draft record with you before publication where practical, and coordinate timing. Our Vulnerability Disclosure Policy describes our response commitments and the safe harbor that protects good-faith research.

Current status

We have not issued a CVE for our own software to date. No vulnerability has met the criteria above.

We state that plainly rather than leaving the absence unexplained. An empty record can mean a mature product or an inattentive one, and the difference matters to the schools and families who trust us. This page is how we make our standard checkable rather than assumed. We will update it when that changes.

Contact

Report a suspected vulnerability to support@human-aspire.org, or see our Vulnerability Disclosure Policy for the full process.