# HaE: a submodule umbrella for the HaENet and HaEFile highlighters

> HaE is a framework-style data security project that tags and extracts values from HTTP, WebSocket and file messages. The repository you land on first is an umbrella: the two products live in their own repos and are mounted under src/ as Git submodules.

**overspace-labs/HaE** — HaE - Highlighter and Extractor, Empower ethical hacker for efficient operations. 赋能白帽，高效作战！

- Repository: https://github.com/overspace-labs/HaE
- Stars: 4,396 · Forks: 318
- Language: Unknown
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/overspace-labs-hae

## What HaE actually is, and who the README is talking to

The name stands for Highlighter and Extractor, and the README frames the whole project as a framework for data security work, aimed at what it calls ethical hackers running efficient operations. The concrete job is fine-grained tagging and extraction across two message families: File, and HTTP including WebSocket. That is narrower than a scanner and broader than a grep alias. A tester reading a proxy history wants every value matching a rule to stand out, and wants the matched value pulled out into a list without hand-copying it. HaE is built around that loop.

The audience is stated rather than implied. The topic list on the repository includes bughunter, burpsuite and vscode, so the intended entry points are a proxy extension and an editor extension, not a terminal. If your work is API review, secret hunting during an authorized engagement, or triaging a large capture for identifiers, the framing fits. If you need a scheduled scanner with reporting, nothing in the README describes one.

## One repository, two products, and a submodule boundary

The layout is the part most readers get wrong. This repository is the umbrella for the HaE project. The product directories under src/ are mounted as Git submodules, and the source code is maintained in dedicated repositories: HaE Network at overspace-labs/HaENet and HaE File at overspace-labs/HaEFile. The top level holds .gitmodules, a LICENSE, README.md and README_CN.md, a prek.toml, a resource/ directory with images, and src/. There is no product source at the root.

That split explains the release history. The three most recent releases are all HaEFile artifacts, HaEFile 1.0.1, 1.0.2 and 1.0.3, published between 2026-07-02 and 2026-08-21. The network product ships through its own repository and its own release channel, so a changelog skimmed from this page shows only half the project. The last push to the umbrella was on 2026-09-20, which is recent, but the activity that matters to a user is inside the two submodule repositories.

The README also names a third repository, overspace-labs/HaEValidator, described as the official HaE validator and marked AI+. That is where rule validation lives, which matters because a rule set is the real configuration surface of a tool like this.

## Installing HaE and getting a first clone that is not empty

The README gives one command for obtaining the umbrella with its product directories populated. A plain clone leaves src/ as empty submodule placeholders, so the recurse flag is the difference between a working checkout and a directory of stubs.

```bash
git clone --recurse-submodules https://github.com/overspace-labs/HaE.git
```

After the clone finishes, src/ contains the mounted product directories instead of empty folders. If you cloned without the flag, the submodule state can be repaired later with git submodule update --init --recursive from the repository root, though the README itself only documents the clone form above.

From there the README points you outward rather than inward. The network version is at overspace-labs/HaENet and the file version is at overspace-labs/HaEFile, and those repositories carry the installation instructions for the Burp Suite extension and the VS Code extension respectively. The umbrella README does not repeat them, and it does not document a command line interface, a server port, or an environment variable. If you came here looking for a binary to run, this page will not give you one.

## The rule set is the product, and the README does not specify it

Every highlighter and extractor of this shape lives or dies on its matching rules. The README describes the outcome, fine-grained tagging and extraction, and it names HaEValidator as the official validator, which strongly implies rules are authored and checked rather than hardcoded. What the README does not give is the rule file format, the syntax of a rule, where rules are stored, or how a custom rule is loaded into either product. None of that is documented on this page.

That is a real gap for evaluation. Before adopting HaE you cannot tell from the umbrella repository whether a rule is a regular expression with a name, a structured object with severity and tags, or something else. The honest position is that the rule format has to be read from HaENet, HaEFile or HaEValidator directly. Anyone who tells you the rule syntax from this README is guessing.

## Where HaE is the wrong tool

HaE is a tagging and extraction layer, not an analysis engine. It surfaces values that match patterns; it does not decide whether a match is exploitable, and nothing in the README claims it does. If your requirement is proof of a vulnerability with a reproducible request, or a report a client will accept, this is one step in a pipeline that still needs a human and other tooling.

The modular, Lego brick framing cuts both ways. Fine-grained tagging means you get exactly the tags you configure, and nothing you did not think to write a rule for. A pattern-based extractor will also produce false positives on any corpus that contains lookalike strings, and the README documents no scoring, confidence level or suppression mechanism. A team expecting a curated, low-noise feed of findings will be disappointed by a tool whose output quality tracks its own rule set.

There is also a coverage boundary in the architecture itself. Network messages and file messages are separate products in separate repositories, so a workflow that needs both has to integrate two things rather than one.

## Compared with grep, Semgrep and the proxy's built-in search

The obvious alternative for pulling values out of captured traffic is the search box already inside your proxy, or a grep over an exported file. Those are one-shot queries: you type a pattern, you read the hits, and the pattern is gone unless you save it somewhere. HaE's difference is persistence and structure. Rules are reusable, matches are tagged rather than merely listed, and the same rule set can be applied to a stream of messages as they arrive instead of to a file after the fact.

Against a static analysis tool such as Semgrep, the difference is the input. Semgrep reads source code and reasons about syntax; HaE reads messages in flight and in files, including WebSocket frames, which are a runtime artifact with no source representation. The two do not substitute for each other. A team doing source review gets little from a message highlighter, and a team testing a deployed API gets nothing from a source scanner if they do not have the source.

The closest comparison is other Burp extensions that highlight or extract. HaE's distinguishing claim is breadth of message type plus the shared rule concept across the network and file products, and the README supports that only at the level of intent. It gives no comparison table, no feature matrix, and no performance figures.

## Maintenance, upgrade cost and the Apache-2.0 terms

The umbrella repository was last pushed on 2026-09-20 and is not archived. The release cadence visible here is HaEFile's: 1.0.1 on 2026-07-02, 1.0.2 on 2026-07-31, and 1.0.3 on 2026-08-21, roughly monthly patch releases. Nothing on this page shows the HaENet release cadence, so upgrade planning for the network extension has to be done against that repository.

The upgrade cost is concentrated in the submodule pointer. Because src/ entries are submodules, updating the umbrella does not necessarily update the products, and updating a product does not update the parent pointer. A team that pins the umbrella and forgets the submodules will silently run old product code. The practical discipline is to check the submodule commit alongside the umbrella commit at every upgrade.

Licensing is Apache-2.0, per the LICENSE file at the root. That is a permissive licence with an explicit patent grant and a requirement to preserve notices, and it is the same licence the umbrella carries, though the README does not state whether the submodule repositories use identical terms. If you redistribute HaE inside a commercial product, or ship your own rule packs alongside it, confirm the licence of each submodule repository and of HaEValidator separately. This is a description of the stated licence, not legal advice.

## Conclusion

Adopt HaE if you already work in Burp Suite or VS Code and want regex-driven tagging of secrets and identifiers rather than a full scanner; the network side is the mature half, given the 2026 Burp Extension Awards nomination and the 2022 KCon Arsenal selection. Do not adopt it as a standalone CLI scanner, because the README documents no such interface, and do not clone the umbrella expecting working code, since src/ holds submodules. Before committing, verify that the HaENet and HaEFile repositories still match the interfaces you need, that the HaEValidator repository covers your rule format, and that Apache-2.0 terms fit how you plan to redistribute any rules you write.

## FAQ

### What is HaE and what does it do?

HaE, short for Highlighter and Extractor, is a framework-style data security project that performs fine-grained tagging and extraction of File and HTTP messages, including WebSocket. The README describes it as aimed at ethical hackers running efficient operations, with the Burp Suite and VS Code extensions as the intended entry points.

### How do I install HaE with its submodules?

The README gives one command for the umbrella repository: git clone --recurse-submodules https://github.com/overspace-labs/HaE.git. Without the recurse flag, the product directories under src/ are empty submodule placeholders. Installation instructions for the extensions themselves are in the HaENet and HaEFile repositories.

### What is the difference between HaE, HaENet and HaEFile?

HaE is the umbrella repository. HaENet handles the network side, covering HTTP and WebSocket messages, and HaEFile handles file messages. Both are mounted under src/ as Git submodules and are maintained in their own repositories, so the recent HaEFile 1.0.1 to 1.0.3 releases do not reflect the network product's release history.

## Sources

- [Issues](https://github.com/overspace-labs/HaE/issues)
- [License: Apache-2.0](https://github.com/overspace-labs/HaE/blob/main/LICENSE)
- [overspace-labs/HaE on GitHub](https://github.com/overspace-labs/HaE)
- [README](https://github.com/overspace-labs/HaE/blob/main/README.md)
- [Releases](https://github.com/overspace-labs/HaE/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/overspace-labs-hae