References and Evidence

Last reviewed: 2026-05-10.

Audience: Procurement reviewers, enterprise security architects, and contract administrators asking “what evidence do you have of existing customer use?”

Purpose: Frame HailBytes’ reference posture honestly. HailBytes is at the stage where the first wave of enterprise customers will be the first marquee references. Until those land, the substitutes below are concrete evidence procurement teams accept when an enterprise vendor relationship is the next-stage rather than the steady-state.

1. The honest framing

HailBytes does not yet have publicly nameable enterprise references. Named enterprise engagements across financial services, public-sector academic networking, and global healthcare are in flight and will, once contracted and reference-permission granted, be the first such references. Until then, this section describes the evidence types HailBytes can offer in their place and how each maps to a procurement-question category.

The point of this document is not to argue that what HailBytes has is equivalent to a five-Fortune-500-reference customer list. It isn’t. The point is to make the evidence that does exist legible, and to offer concrete substitutes that experienced procurement reviewers accept when evaluating a next-stage vendor.

2. Marketplace install metrics

HailBytes ASM and SAT are listed on AWS Marketplace and Azure Marketplace. Both listings carry public install counts and customer reviews where reviewers have left them.

As of 2026-05-11:

Specific tenant counts and named customer rosters are available under NDA via references@hailbytes.com. Marketplace install counts are imperfect proxies — they don’t distinguish between separate departments inside one organization and they don’t reveal organization names — but billable-hour figures are harder evidence of production use than star counts or download counts because the customer is paying compute fees to run the software.

3. Open-source heritage and community presence

Heritage. HailBytes ASM and HailBytes SAT are built on widely-deployed open-source security projects. This is important context for any procurement reviewer evaluating “is this a credible engineering effort?”:

  • HailBytes ASM is built on rengine (upstream repository, approximately 8,600 GitHub stars as of 2026-05-11). rengine is a long-established attack-surface-management and reconnaissance framework with substantial community adoption.
  • HailBytes SAT is built on gophish (upstream repository, approximately 13,800 GitHub stars as of 2026-05-11). gophish is the most widely-deployed open-source phishing-simulation framework in the industry.

The star counts above are for the upstream projects, not for HailBytes’ own forks; HailBytes does not present those numbers as its own. The point is that HailBytes is layering enterprise hardening, cloud-marketplace packaging, BYOC delivery, audit logging, PII scrubbing, RBAC, and the trust-package framing on top of mature, battle-tested upstream code — not building greenfield from a zero-adoption starting point.

HailBytes’ own public surfaces:

These signals are not customer references. They are evidence that the products are non-vaporware, actively maintained, and used by security practitioners who have voluntarily engaged with them.

4. User community characterization

The user community for HailBytes ASM and SAT, characterized without identifying individual users (HailBytes does not collect telemetry, so this is reconstructed from voluntary user signals — Marketplace reviews, GitHub issues, community Slack profiles, and conference talk attendance):

  • Security teams at mid-market and growth-stage technology companies.
  • Managed Security Service Providers (MSSPs) running the products for end-customer engagements.
  • Penetration testing firms using ASM as part of client engagement tooling. for-pentest-firms.html on the marketing site speaks to this audience specifically.
  • Academic and research institutions (anticipated to be a growing segment with HEANet-class engagements).
  • Internal security functions at organizations whose procurement does not require third-party-vendor SOC 2 (smaller enterprises, government departments at certain authority levels, organizations whose primary requirement is data-residency-by-deployment rather than vendor-controls attestation).

This characterization is general by intent — HailBytes does not name individual users without permission.

5. Technical reference offers

HailBytes can offer the following technical references on request, all of whom can speak to the product’s technical behavior under sustained use (not to a commercial-relationship reference):

  • Penetration testers who have used HailBytes ASM during paid engagements. Contact: arranged through references@hailbytes.com.
  • Security researchers who have engaged with HailBytes through coordinated disclosure (a small number of researchers have disclosed bugs and can speak to HailBytes’ responsiveness and disclosure handling under the 90-day window documented in SECURITY.md).
  • Open-source contributors who have engaged with HailBytes engineering.

These references speak to engineering quality and operational responsiveness. They do not substitute for a customer-procurement reference; HailBytes is direct about this when arranging the call.

6. Live-deployment walkthrough offer

Under NDA, HailBytes can offer:

  • A walkthrough of a real running deployment (subject to deploying-customer’s permission and HailBytes acting as the demonstration coordinator — HailBytes does not have remote access to customer deployments and is not the operator).
  • A walkthrough of HailBytes’ own internal deployments of ASM and SAT (HailBytes operates both products internally for HailBytes’ own security operations and security-awareness training — a useful demonstration of “the vendor uses their own product”).

The internal-deployment walkthrough is offered without coordination cost and is typically the most efficient evaluation path during a procurement cycle.

7. Verification-of-claims offer

For customers whose procurement teams want to verify the structural claims in byoc-architecture.md and security-evidence-package.md rather than take them on trust, HailBytes offers:

  • A guided deployment to a customer-provided sandbox account, with the customer’s security team observing all egress traffic during a representative workload. The goal is to confirm that the only outbound connections are container-registry pulls and customer-elected integrations. Typically a half-day engagement; offered as part of pre-sale evaluation at no charge.
  • A guided walkthrough of the Trust Pack archive for the candidate release, including a live cosign verify of the published image signatures.

Both offers are made under NDA on request and routinely accepted by enterprise security teams during evaluation.

8. What HailBytes will not do

A short list to make the framing of this document complete:

  • HailBytes does not provide reference-customer names without explicit written permission from the customer.
  • HailBytes does not provide fabricated case studies or composite reference profiles.
  • HailBytes does not provide testimonial-style quotes attributed to individuals without their explicit written authorization.

This list exists because some procurement reviewers ask explicitly whether the vendor will do these things.

9. As enterprise references land

The first enterprise references will, with the customer’s permission, be added to this document as named references with:

  • Engagement summary (one or two sentences).
  • Deployment scope (which product, which region).
  • Reference-call contact at the customer.

The pattern of named-reference appearance will follow customer-permission timing, not HailBytes’ marketing schedule.

Cross-references: byoc-architecture.md §7 (verifying the claims, which the §7 offer here operationalizes); security-evidence-package.md (the artifacts that the Trust Pack walkthrough covers); marketplace-hub-content.md (the public-marketplace surface area that §2 install counts come from).