MathAssertions / MathAssertions.TUnit is a personal-name open-source project distributed under the MIT license. Although the package is intended for use only in test projects (see the scope blockquote on every README), security reports are still welcome and treated as a priority.

This document is the project's coordinated-vulnerability-disclosure (CVD) policy. The Cyber Resilience Act (Regulation (EU) 2024/2847) imposes vulnerability-handling and reporting obligations on Manufacturers of products with digital elements; personal-OSS distributed outside the course of commercial activity is excluded from CRA scope and the policy here is published anyway as a hygiene measure for downstream consumers.

Please do NOT open a public issue for security vulnerabilities. Use one of the private channels below.

1. Navigate to the repository's Security tab
2. Click Report a vulnerability
3. Fill in the form with reproduction steps, affected version(s), and any proof-of-concept code

Reports submitted this way are visible only to repository maintainers and are end-to-end encrypted by GitHub. The reporter is notified of progress through the same channel.

If GitHub's private reporting form is unavailable in your account (e.g. organisation-level restrictions), open a regular issue with the title Security: contact request and no exploit details in the body. Just enough to indicate you have a security report to file. The maintainer will move the conversation to a private channel from there.

(Drafting a GitHub Security Advisory directly is restricted to repository admins and security managers, so it is not a viable fallback for external reporters.)

A useful report typically includes:

• Affected version(s): exact NuGet package version where the issue is observed
• Severity assessment: your view of the impact (CVSS 3.1 or 4.0 vector if you have one, otherwise prose)
• Reproduction steps: the smallest test project / call sequence that triggers the issue
• Suggested fix or mitigation if you have one

Reports without these are still welcome; maintainers will work with you to fill the gaps.

Personal-OSS maintained outside working hours; the targets below are best-effort, not contractual:

A coordinated disclosure (public CVE filing + advisory + patched release) is the default outcome unless the reporter requests otherwise. Credit is given to the reporter in the published advisory and CHANGELOG entry; reporters who prefer to remain anonymous are accommodated.

This table is updated alongside each release that bumps the current line. Coverage of older lines for security-only fixes follows the .NET LTS / STS rotation: when the package's TFM changes at a major-version boundary, security fixes for the previous line continue to ship for one minor cycle.

In scope:

• The shipped MathAssertions and MathAssertions.TUnit NuGet packages
• The build pipeline (release workflows, signing, NuGet publishing chain) and supply-chain integrity of the packages
• The shipped SBOMs (SPDX 3.0 in nupkg, CycloneDX 1.6 sibling artifact)
• The SLSA build-provenance attestations and Sigstore-signed SBOM attestations
• Realistic in-product attack surface examples:
  • Unbounded memory or CPU consumption from a crafted assertion chain
  • Information disclosure through assertion failure messages that escapes intended scope

Out of scope (please report upstream instead):

• Vulnerabilities in direct dependencies (TUnit.*, etc.). Report to the relevant upstream maintainer; we will pull in their fix once released.
• Vulnerabilities in the .NET runtime / SDK itself. Report to Microsoft Security Response Center.
• Issues affecting production code that incorrectly references this package. See the "Test projects only" scope blockquote on the package README; production use is unsupported by design.

To set expectations correctly:

• No bug bounty. Reports are accepted gratefully but no monetary reward is offered.
• No SLA. Response targets above are best-effort.
• No commercial support contract. This is personal-OSS; for commercial-grade support, fork the package and add the support layer yourself, or sponsor an alternative testing library that ships with one.

Every release shipped to nuget.org and GitHub Releases carries cryptographic supply-chain attestations stored in GitHub's public transparency log. A security-conscious consumer can verify the chain end-to-end before adopting:

Replace <package> (one of MathAssertions or MathAssertions.TUnit) and <version> (e.g. 0.1.0) with the artifact you downloaded:

# Verify SLSA v1.0 build provenance: was this nupkg built from this audited source tree?
gh attestation verify ./<package>.<version>.nupkg --repo JohnVerheij/MathAssertions.TUnit

# Verify the CycloneDX SBOM: is this BOM the authentic SBOM for that nupkg?
gh attestation verify ./<package>.<version>.nupkg \
    --repo JohnVerheij/MathAssertions.TUnit --predicate-type https://cyclonedx.org/bom

Both attestations are signed via Sigstore keyless signing; there is no long-lived signing key for an attacker to compromise; verification proves the artifact came from this exact GitHub repo at the exact commit and workflow that built it.

This stack matches what most CRA-bound EU Manufacturers will be required to ship from December 2027. Personal-OSS distributed outside the course of commercial activity is excluded from CRA scope; shipping the stack anyway is a hygiene choice.

Thanks to all reporters who help keep the package family secure. Public credit is given on each advisory unless anonymity is requested.