# HoneyMesh security and procurement overview

**Evaluation draft · 29 October 2026**

This document gives reviewers a starting point. It is not a certification, service-level agreement, EULA, privacy notice, or statement that a paid AWS Marketplace listing is live. Request current contractual documents from Admin@Network-Decode.com.

## Architecture and trust boundary

HoneyMesh runs on selected Linux hosts. Configured traps and local policy can identify suspicious activity; an operator can also create a ban. On an attached interface, an eBPF/XDP program checks a local source-IP ban map and drops matching ingress traffic. Pro customers may opt in to a mutually authenticated mesh. A node sends a signed ban signal to approved peers; each receiver applies its own trust policy before taking local action. A central service is not in the local packet path. See the [technical proof of concept](/proof/HoneyMesh-Technical-Proof-of-Concept-2.3.6-rc2.pdf) for the tested behavior and limits.

**Selective-access result:** In the 2.3.6-rc2 three-node AMD64 lab, the banned test source received no reply on the five tested traffic cases, while the separate unbanned control source still reached the same listeners on all three hosts. This supports a specific service-reachability claim for that test. Production uptime and behavior for every legitimate client were not measured.

**Coverage boundary:** HoneyMesh applies to selected hosts and attached interfaces. It does not automatically cover every path in a network. Source-IP bans can affect legitimate users behind shared addresses, so allowlists, peer trust levels, review, and release procedures matter.

## Release and deployment review

- Identify the exact version and architecture. The linked evaluation packages and the federation PoC use prerelease 2.3.6-rc2 on AMD64; ARM64 was not rebuilt or tested for rc2.
- Verify package checksums and version-matched installation instructions. The 2.3.6-rc2 packaged service uses a dedicated `honeymesh` user, bounded Linux capabilities, and Linux kernel 5.8 or newer for its capability model.
- Review required ports, TLS certificate ownership, selected interfaces, log locations, update path, rollback, uninstall, and behavior when the license or peer connection is unavailable.
- Request a current compatibility matrix and software bill of materials before production approval. Do not assume an untested distribution, kernel, IPv6 path, or architecture is supported by the PoC.

## Security review questions

1. Which event fields, IP indicators, account data, and telemetry are collected, stored, shared, and retained? Obtain the current privacy and data-handling statement.
2. How are mesh certificates and license signing keys issued, rotated, revoked, and protected?
3. How are admin accounts authenticated and their actions logged? Who can issue or release a ban?
4. How are vulnerabilities reported, prioritized, patched, and communicated to customers? Request the current security contact and patch policy.
5. How are releases built, verified, and rolled back? Request checksums and a current dependency inventory.
6. What are the support hours, severity process, response targets, and incident notification process? Obtain the signed terms.

## Procurement and fulfillment

The planned paid path is AWS Marketplace purchase, followed by registration on network-decode.com, entitlement verification, and authorized Pro access. Confirm the final listing, node metric, price, term, EULA, refund/cancellation process, support contact, and delivery flow on the live Marketplace product before ordering. Do not rely on draft website pricing as a contract.

For evaluation, request the [pilot guide](/resources/HoneyMesh-Company-Pilot-Guide.md), [PoC](/proof-of-concept), and a meeting covering the current release, scope, and support model. Contact [Admin@Network-Decode.com](mailto:Admin@Network-Decode.com?subject=HoneyMesh%20security%20review).