Skip to content

Security: caliperforge/cf-invariants

Security

SECURITY.md

Security Policy

cf-invariants is a tool for finding bugs in other people's contracts. We take security reports against the tool itself seriously and aim to acknowledge every credible report within seven days.

Reporting a vulnerability

Email: michael@caliperforge.com

Please do not open a public GitHub issue, pull request, discussion post, or social-media thread for a real vulnerability. Use the private email path above.

For a report, please include:

  • The cf-invariants version (cf-invariants version), the snforge / scarb / Cairo versions in use, and the host OS.
  • A short description of the issue and the impact you believe it has.
  • Steps to reproduce, or a minimal reproducer repo / Cargo project if you have one.
  • Whether you would like credit in the advisory; if so, the name or handle to credit.

What to expect after a report

Step SLA Notes
Acknowledgement of receipt 7 days If you do not hear back within seven days, please email a second time before assuming the report did not arrive
Triage and initial severity call 14 days Operator-of-record (Michael Moffett) triages; AI-agent review may be used in drafting the response, but the operator signs
Fix, advisory, or "not a vulnerability" response as fast as the fix safely allows Coordinated-disclosure timing negotiated with the reporter
Public advisory + patched release on the same day where feasible Released via GitHub Security Advisories on this repo

The project is operated by a single human under the CaliperForge banner (see GOVERNANCE.md). Response speed is honest-to-capacity; the seven-day acknowledgement window is the commitment, and we will not silently sit on a report.

Scope

In scope:

  • The cf-invariants CLI (cf-invariants run, cf-invariants suggest, cf-invariants version) and all six crates in the workspace.
  • The Cairo dev-dependency package under cairo/.
  • The packaged prompts under prompts/ (a prompt that causes the AI module to emit unsafe Cairo, exfiltrate secrets, or violate the cost budget is in scope).
  • The build, test, and CI configuration (including the paired clean / planted CI gates) where a vulnerability there would mask a real invariant violation.
  • The deployment scripts under scripts/ insofar as they handle signing keys, account state, or RPC endpoints.

Out of scope:

  • Bugs that we planted on purpose in the references/*/ trees. Every reference contract is paired clean / planted (see below). Reports of those bugs are not security issues — they are the product working as intended.
  • Vulnerabilities in snforge, scarb, sncast, Cairo, or other upstream tooling. Please report those to the relevant upstream project. We will be glad to coordinate if the vulnerability surface reaches cf-invariants.
  • Issues that depend on a contributor running a malicious local toolchain (a malicious snforge binary, a tampered scarb, a modified Anthropic SDK).

Planted-bug and invariant doctrine

cf-invariants ships its own "fixtures we know are broken" alongside its "fixtures we know are clean." This is a deliberate part of the project's testing posture, and it matters for security reporting.

Every reference contract under references/*/ compiles to two variants from a single source tree, gated by a clean scarb feature each Scarb.toml declares ([features] clean = []):

Variant Build / test command What it proves
planted (default) snforge test The accepted invariant suite detects the planted bug: INVARIANT VIOLATED marker on stdout, rc != 0
clean snforge test --features clean The fix removes the planted bug: zero markers on stdout, rc == 0

Both legs run in CI on every push to main and on every pull request, across all reference contracts; both legs must pass for the run to be green. This is the project's planted-bug-finds-real-bug evidence: the tool finds a known bug exactly where it was planted, and confirms its absence on the same tree with the fix applied.

The doctrine has three implications for this security policy:

  1. A reproducer that demonstrates INVARIANT VIOLATED on a reference contract under the default (planted) build is not a vulnerability report. That output is the product working correctly.
  2. A reproducer that demonstrates a missed detection (no marker where one should fire, or a marker on --features clean where none should fire) is in scope. That is a soundness issue and we want to know.
  3. An invariant suggester that proposes an unsafe pattern in accepted output is in scope. Every AI-suggested invariant carries the [AI-SUGGESTED, UNVERIFIED] label until the developer accepts it (see docs/ai-disclosure.md), but a prompt that causes the model to omit the label, exceed the per-call cost cap, or emit Cairo that compiles to an unsound check is a tool-level issue.

Disclosure and credit

Default posture is coordinated disclosure: we work with the reporter to fix the issue before public disclosure, then publish a GitHub Security Advisory crediting the reporter (unless the reporter prefers to remain anonymous). We do not offer cash bounties at this time; we do offer credit in the advisory and, where applicable, a public thank-you on the project's release notes.

What we will not do

  • We will not threaten legal action against good-faith reporters.
  • We will not silently downgrade a finding's severity to avoid an advisory.
  • We will not ship a fix without an advisory unless the reporter asks us to.

Apache-2.0 licensed. Built with AI assistance. Authored and reviewed by Michael Moffett, operator at CaliperForge. Full policy at caliperforge.com/ai-disclosure.

There aren't any published security advisories