Evidence-first GitHub repository audit and AI code audit for CI/CD, software assurance, security evidence and release readiness — bound to one exact revision when that binding can be verified.
The central question is not “does this repository look good?” It is: what can the available evidence actually prove about this exact subject, and what remains unverified?
Shipping a release or handing a project to a client? The existing $49 Full Audit can be scoped as a Release / Handoff Evidence Review →: one public repository, one exact revision, up to three agreed decision-relevant questions, explicit unknowns and next actions.
Request a Free Demo Audit — $0 →
No signup, domain, paid infrastructure, or private repository access is required for the free demo.
The current public automated path is intentionally narrower than the full expert audit service.
Automated / deterministic in the accepted Audit v2 path:
- exact GitHub repository + selected
HEADSHA + immutable Git-tree binding; - Git-tree content manifest identity;
- exact README claim text preservation without inferring truth from documentation;
- structured GitHub Actions trigger/job/step inspection;
- bounded workflow-security and false-green review signals;
- test-file/type discovery without silently truncating large test trees;
- bounded supply-chain, repository-local architecture and contract-drift evidence;
- standard JSON Schema validation plus fail-closed evidence rules for
VERIFIED; - optional caller-supplied exact workflow/test/release/runtime/provenance evidence with explicit trust boundaries;
- optional time-bound supplied branch/ruleset state kept distinct from commit-bound evidence;
- deterministic customer-facing Markdown rendering and golden adversarial end-to-end tests.
Still requires independently retrieved/provider-authenticated evidence or expert review for stronger conclusions:
- whether externally supplied CI/runtime/provenance/platform evidence is independently authentic and current;
- exploitability and absence of vulnerabilities;
- trusted-builder/signature/reproducible-build conclusions;
- successful deployment and production behavior;
- deep dependency/license/vulnerability conclusions beyond bounded repository evidence;
- final release/readiness judgment in the agreed business context.
Static configuration never becomes runtime proof merely because it was discovered. Caller-supplied evidence never becomes independently authenticated merely because it is well formed. Missing, stale, inaccessible or wrong-subject evidence stays bounded or UNVERIFIED.
- VERIFIED — the bounded claim is directly supported by current, accessible evidence bound to the exact subject.
- PARTIAL — relevant evidence exists, but material parts remain unproved.
- UNVERIFIED — evidence is insufficient to establish the claim.
- CONTRADICTED — current evidence shows the bounded claim is false for the reviewed subject.
- NOT_APPLICABLE — the claim is genuinely outside the applicable scope and the report states why.
There is no opaque global security score. A green CI badge is not a blanket PASS.
See the method on real public repositories before requesting your own audit.
- Flask — public demo audit
- Vite — public demo audit
- Terraform — public demo audit
- pyca/cryptography — public demo audit
- git-auto-commit-action — public demo audit
- GitHub Local Actions — public demo audit
- cargo-make — public demo audit
- flutter-action — public demo audit
Browse all public demo audits →
These are independent public demonstrations based only on public repository evidence. They are not customer engagements, partnerships, sponsorships, upstream approvals or endorsements. Existing demos are expert/manual or semi-automated evidence reviews and must not be treated as benchmark proof for a newer automated engine version unless explicitly rerun and labeled as such.
Submit one public GitHub repository. The demo returns:
- up to 3 high-leverage findings or observations;
- an exact-revision evidence check;
- prioritized next actions;
- a bounded view of relevant CI/test, architecture, authorization, reproducibility or release-readiness evidence.
Best fit: small teams and solo builders shipping quickly with GitHub and AI-assisted development tools.
Open the Free Demo Audit form →
Typical examples include:
- green CI whose important job was skipped, filtered or not required;
- evidence generated for a different repository or revision;
- tests that exist but have no exact-subject execution evidence;
- a privileged workflow context that needs trust-boundary review;
- OIDC permission being mistaken for proof that trusted publishing occurred;
- a release artifact whose source identity or verification is not established;
- documentation claims that are stronger than the available evidence;
- missing evidence silently being interpreted as “probably fine.”
The auditor must distinguish a potential review signal from a proven defect. Missing evidence is not automatically a vulnerability.
Branches move. A green result on yesterday's main is not evidence about today's code. The exact-bound automated path verifies repository identity, requested HEAD, and the selected Git tree before repository-file evidence receives exact freshness. Repository content for the exact automated path is materialized from Git objects belonging to that tree rather than from unrelated ignored/untracked working-tree files.
If that binding cannot be established, the audit fails closed rather than borrowing confidence from a caller-supplied SHA.
| Offer | Founding price | Scope |
|---|---|---|
| Free Demo Audit | $0 | One public repository at one reviewed revision, up to 3 high-leverage findings/observations and prioritized next actions. |
| Full AI Repository Audit | $49 | Deeper expert evidence review across the agreed repository scope. A concrete starting scope is the Release / Handoff Evidence Review. |
| Audit + bounded remediation | $149 | Full audit plus an explicitly agreed, bounded set of fixes or hardening changes for selected findings, followed by re-verification. |
| Setup / pilot | from $299 | Implementation/process enablement for a team or project: define scope, evidence workflow and repository controls needed to make the discipline repeatable. |
The free request creates no payment obligation. Paid work starts only after a separate scope is agreed.
- Submit a Free Demo Audit request with the decision or concern you need help with.
- Freeze and, where automation is used, verify the subject binding.
- Review repository-visible and available execution evidence within scope.
- Separate verified facts, partial evidence, unknowns and contradictions.
- Receive prioritized findings/observations and continue only if a deeper paid audit or remediation is useful.
See RELEASE_HANDOFF_REVIEW.md, HOW_IT_WORKS.md, SAMPLE_AUDIT.md, FAQ.md, and SECURITY.md.
The public repository and Free Demo Audit use only public-source evidence plus clearly synthetic fixtures/material created specifically for this public product. Private or internal evidence is not republished here even after anonymization, sanitization, aggregation, paraphrase, or generalization.
Do not submit secrets, credentials, private source, confidential customer data, private repository URLs, or sensitive vulnerability details in a public issue.
This service is not a penetration test, certification, compliance attestation, legal opinion, security guarantee, or guarantee that software is defect-free.
If you have a real release or handoff question, request a Free Demo Audit — $0 →