This document outlines the security practices, reporting procedures, and recommendations specific to Celero’s C++ codebase.

Celero maintains security support for the two most recent minor releases of the master branch. Releases outside this window may not receive timely security fixes.

If you discover a security vulnerability in Celero, please:

1. Email: send details to the maintainer.

2. Subject: prefix with SECURITY REPORT:.

3. Include:

   • Affected Celero version or commit SHA.
   • Description of the issue.
   • Minimal reproducible example or proof-of-concept.
   • Suggested mitigations or patches (if known).

Expect acknowledgement within 48 hours and a fix timeline based on severity.

1. Acknowledge within 48 hours.
2. Assess impact and severity.
3. Develop a fix in a dedicated branch (naming: security/<short-description>).
4. Review & Test: include regression and fuzz tests.
5. Merge fix into master and backport to supported releases.
6. Release: draft an advisory and update the release notes.

SPDX 2.3 SBOMs are committed under sbom/ and attached to every published release with a build provenance attestation. They are generated by tools/sbom/generate_sbom.py, and CI regenerates and diffs them on every push, so a dependency change cannot land without the SBOM being updated in the same commit:

For vulnerability triage, the per-triplet library document is the relevant one: Celero has no third-party runtime dependencies, so its exposure is limited to the compiler runtime and the operating system. Google Test is a test-only dependency behind CELERO_ENABLE_TESTS and is never linked into the installed library.

Two third-party headers are vendored under experiments/ and are recorded explicitly in the source SBOM because no scanner can detect them. Note that experiments/ExperimentCostSharedPtr/osg_ref_ptr.h is licensed under the OpenSceneGraph Public License rather than Celero's Apache-2.0, and that experiments/ExperimentParticles/Particles.h carries no license header. Neither ships in the installed library. See tools/sbom/README.md.

• Use Sanitizers: enable ASan, UBSan, and MSan in CI builds to catch memory errors.
• Static Analysis: run clang-tidy with security-focused checks (e.g. cppcoreguidelines-pro-type-union-access).
• Fuzz Testing: integrate libFuzzer or AFL targets for public APIs.
• Dependency Audits: regularly audit third-party libraries against the published SBOM; keep PORT_SCOPE and VENDORED_COMPONENTS in the SBOM generator current when dependencies change.
• Safe Patterns: prefer std::array/std::vector over raw arrays; use smart pointers (unique_ptr, shared_ptr).
• Bounds Checking: avoid out-of-bounds access; use at() when indexing if safety is critical.

• Code Reviews: include at least one security-aware reviewer for changes to public APIs or memory management code.
• CI Integration: plan to add security scans (e.g. CodeQL) via GitHub Actions.
• Secrets Management: do not commit API keys or credentials; use environment variables or CI secrets.

This policy draws on best practices from OWASP C++ Security Cheat Sheet and the GitHub security guidelines.