How a CamelHive attestation works
For whoever is trusting a codebase they didn't build and can't audit themselves — a client trusting the agency, freelancer, or no-code builder who made it for them. Three questions, answered.
What an attestation is — and isn't
A CamelHive attestation is a dated record of which rules in our public, versioned standard a specific commit passed, failed, or left undetermined, with a stated scope and coverage — never a hidden one.
It is not a certification, and it is not a legal compliance conformity statement. It is an input to your own diligence process, never the artifact that replaces it — automatic, without a human sign-off, and it says so.
How to require one
Ask the company for a current CamelHive attestation, and name specific rules by ID so the ask is concrete instead of a vague reference to "a security audit." A minimal example, using two rules that our own benchmark corpus can measure detection for, not just claim:
"Provide a current CamelHive attestation covering, at minimum, CH-SEC-001 and CH-ARCH-001, each shown as pass or as an explained gap, with its verification link."
How to verify one you receive
Every attestation carries its own verification link — printed in the document itself, in the form camelhive.com/v/{id} — pointing to a public page that confirms the document hasn't been altered and shows the scope and results in aggregate. If that page says the attestation was revoked, treat the document as void, whatever it claims.
That public page shows scope and aggregates, not per-finding evidence — a specific file and line for a security gap isn't published without the founder's consent, for the same reason you wouldn't publish an open vulnerability.
Looking to get your own MVP audited instead? This page is for the other side of the table — see the plans and how it works.