AWatch-rus/docs/hayabusa-source-packaging-2026-05-14.md

Hayabusa Source and Packaging Decision 2026-05-14

Decision

• upstream source of truth: Yamato-Security/hayabusa
• fork policy: do not use a fork unless a concrete required patch exists and is documented
• runtime role in this project: DFIR enrichment

Pinned release

• release tag: v3.9.0
• server target platform: x86_64, debian 13
• selected asset:
  • hayabusa-3.9.0-lin-x64-gnu.zip
• selected asset URL:
  • https://github.com/Yamato-Security/hayabusa/releases/download/v3.9.0/hayabusa-3.9.0-lin-x64-gnu.zip

Packaging model

• analysis host: <AW_SERVER_HOST>
• install root: /opt/hayabusa
• versioned release root: /opt/hayabusa/releases/v3.9.0
• active symlink target:
  • /opt/hayabusa/current
• suggested executable path:
  • /opt/hayabusa/current/hayabusa
• suggested wrapper path:
  • /usr/local/bin/aw-hayabusa

Artifact boundaries

• raw incoming EVTX:
  • /opt/hayabusa/inbox
• processed EVTX archive:
  • /opt/hayabusa/archive
• generated reports:
  • /opt/hayabusa/reports
• run logs / metadata:
  • /opt/hayabusa/state

These paths are intentionally outside normal ActivityWatch buckets and outside ordinary DLP artifact roots.

Integrity note

The official release currently does not publish a separate checksum asset in the GitHub release asset list.

Therefore the deployment model should:

1. download the pinned asset URL;
2. calculate sha256 locally during automation;
3. store the computed value in deployment logs or a local manifest;
4. fail deployment if the downloaded asset name or pinned tag does not match expectations.

Why this model

• no dependency on an unreviewed fork;
• reproducible server-side installation;
• no attempt to run Hayabusa as a real-time daemon;
• clean separation between AW-rus runtime data and forensic artifacts.