llm-usage-exporter is pre-1.0 software. Security fixes are applied to main until stable release branches exist.

Pre-1.0, we do not maintain long-lived release branches; once v1.0.0 is cut, this table will be expanded to cover supported minor versions. We recommend always running the latest release and verifying its cosign signature before deploying.

Please report security vulnerabilities privately using GitHub's Private Vulnerability Advisories. This opens a confidential thread between you and the maintainers and does not disclose any details publicly until a fix is coordinated.

Do not open a public issue, pull request, or discussion containing reproducers, exploit details, or other sensitive findings — once published, that information is publicly indexed and cannot be retracted.

What to expect:

• Acknowledgement — within 5 business days.
• Initial assessment and triage — within 10 business days, including a severity rating and a target remediation window.
• Coordinated disclosure — once a fix is available and users have had a reasonable upgrade window, we publish a GitHub Security Advisory with CVE assignment where applicable and credit to the reporter unless anonymity is requested.

As a pre-1.0, solo-maintained project, response times are best-effort; we will keep you updated through the advisory thread.

Security-sensitive areas include:

• Provider credentials — OpenAI / Anthropic admin API keys and organization IDs, Azure AD service-principal client secrets, GCP service-account JSON keyfiles, AWS access keys and session tokens.
• Tenant credentials — per-tenant credential blocks in the Tenants.Items configuration array, including the Tenants.ApiKeys.<id> bearer tokens used to gate /metrics?tenant=<id> access.
• Scrape surfaces — anything exposed by /metrics, /focus.csv, /focus.json, and /health. Treat these as operational data and place them behind your normal internal network controls, mTLS, or an authenticating reverse proxy.
• Label cardinality — accidentally promoting user_id, api_key_id, or other high-cardinality identifiers into Prometheus labels is treated as a security-relevant defect because it can destabilize a shared Prometheus deployment.
• OTLP egress — OTEL_EXPORTER_OTLP_HEADERS may contain API keys for managed OTel backends; the exporter forwards them verbatim and they must never be logged.
• Provider API integrations — logging, retries, error handling, and pagination across all five provider clients. Credentials must never appear in logs, metrics, traces, or /health output.
• Container supply chain — Dockerfile base image, build provenance, SBOM contents, cosign signatures, and the release workflow at .github/workflows/release.yml.
• Deployment examples — Docker Compose, Prometheus scrape config, and the Helm chart at deploy/helm/llm-usage-exporter/.

We support safe harbor for security research conducted in good faith. If you:

• Make a good-faith effort to avoid privacy violations, data destruction, and service degradation;
• Test only against your own deployments of llm-usage-exporter — never against other people's /metrics endpoints, OTLP collectors, or scrape surfaces;
• Avoid exfiltrating data beyond the minimum needed to prove the vulnerability, and do not retain it longer than necessary;
• Give us a reasonable window to remediate before any public disclosure;

then we will not pursue or support any legal action against you, and we will treat your report as authorized testing for the purposes of applicable computer-misuse legislation in your jurisdiction.

This safe-harbor commitment does not extend to third-party services the exporter integrates with — provider APIs (OpenAI, Azure OpenAI, Anthropic, Gemini, Bedrock), OTLP backends, container registries, or Sigstore infrastructure. Their policies apply when testing against them.

Every released container image ships with:

• Cosign keyless signature at the immutable digest, issued via GitHub OIDC against the Sigstore Fulcio CA.
• SLSA v1.0 build provenance (in-toto attestation) co-located with the image digest, generated by slsa-framework/slsa-github-generator — meeting SLSA Build Level 3.
• SPDX SBOM attached as a cosign attestation (spdxjson predicate type) and also published as a release asset.
• CycloneDX SBOM of the .NET project graph published as a release asset.

Verify a published tag end-to-end:

# 1. Verify the signature
cosign verify ghcr.io/xops-labs/llm-usage-exporter:<tag> \
  --certificate-identity-regexp "https://github.com/xops-labs/llm-usage-exporter/.*" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

# 2. Verify the SLSA provenance
cosign verify-attestation ghcr.io/xops-labs/llm-usage-exporter:<tag> \
  --type slsaprovenance \
  --certificate-identity-regexp "https://github.com/slsa-framework/slsa-github-generator/.*" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

# 3. Pull the SPDX SBOM
cosign download attestation ghcr.io/xops-labs/llm-usage-exporter:<tag> \
  --predicate-type https://spdx.dev/Document

A PR that increases label cardinality, broadens scope of a credential's required permissions, or removes a signature step is treated as a security-relevant change. Open an issue or discussion before submitting it. See GOVERNANCE.md for the larger-changes process.

For operational guidance on least-privilege provider setup, Kubernetes Secrets, external secret managers, rotation, and redaction, see docs/security-secrets.md.