Skip to content

Security

Jump to bottom
Joshua Shinavier edited this page Jun 5, 2026 · 1 revision

Security

This page describes Hydra's security posture, dependency surface, and vulnerability-reporting expectations. It is part of the Apache Incubator readiness work tracked by #441.

Hydra is primarily a language kernel, code-generation system, and set of data-integration libraries. Its security model should distinguish the core host implementations from bindings, demos, generated packages, and future command-line tooling.

Reporting vulnerabilities

If GitHub shows a Report a vulnerability link for the Hydra repository, use that private reporting path. If private vulnerability reporting is not available, contact the project maintainer privately before opening a public issue.

Do not disclose exploitable vulnerabilities in public issues, pull requests, or discussion threads until the project has had a chance to triage and coordinate a fix.

Useful reports include:

  • affected package, host, binding, or demo
  • affected version or commit
  • steps to reproduce
  • expected and actual behavior
  • impact and any known workaround

The reporting process is still being formalized. Future Apache-readiness work should add explicit maintainer contacts, response expectations, and disclosure timing.

Dependency surface

Hydra's core hosts are intentionally lightweight in external dependencies. Most host implementations depend primarily on their language runtime and build framework:

  • Haskell host under GHC / Stack
  • Java host under a JDK / Gradle
  • Python host under Python / uv
  • Scala host under Scala / sbt
  • Lisp dialect hosts under their corresponding language runtimes

Generated distribution packages inherit the dependency surface declared by their own generated build/config files. Those files live under dist/<lang>/<package>/. Security review should inspect those package descriptors rather than infer dependencies from source-tree layout.

The overlay/ tree contains Hydra-authored runtime source copied into generated distribution packages. It does not declare or introduce third-party dependencies. Overlay files are part of Hydra; they make a generated distribution complete, but they do not add an external dependency surface by themselves.

The larger third-party dependency surface lives in:

  • bindings/ — hand-written integrations with external systems such as RDF, parser, graph, or database libraries.
  • demos/ — runnable examples that may pull in external libraries or services for illustration.

Bindings and demos should be reviewed separately from the kernel and heads. A vulnerability in a binding may affect users of that integration without implying a vulnerability in the Hydra kernel itself.

Generated code and external input

Hydra translates modules and schemas across host languages and data formats. Users should treat external schemas, modules, and data as untrusted input unless they control the source.

Security review should pay special attention to:

  • parsers and decoders for external formats such as JSON, RDF, GraphQL, Avro, Protobuf, Cypher, and GQL
  • file-writing paths in build, sync, and code-generation scripts
  • generated-code emission paths
  • demos or bindings that connect to external services
  • future CLI paths tracked by #440

Hydra generation should not silently execute arbitrary generated artifacts as part of ordinary translation. Running generated code, demos, tests, or host-specific build tools is a separate action and should be treated with the same care as running any other source from the repository.

AI-assisted development provenance

Hydra uses AI-assisted development, but AI assistance does not reduce the review bar. Contributors and maintainers remain responsible for correctness, licensing, originality, and testing.

AI-assisted changes should:

  • be reviewed by a human contributor before merge
  • avoid copying incompatible licensed material
  • cite external sources when documentation relies on them
  • follow the same generated-file, testing, and style rules as any other change

The practical contribution rules live in Contributing.

Release and supply-chain follow-up

Security overlaps with release trust and supply-chain hygiene. Future #441 work should add or verify:

  • source-release buildability checks
  • checksums and signatures for release artifacts
  • dependency and license audit workflow
  • vulnerability scanning expectations for bindings and demos
  • software bill of materials (SBOM) or dependency-manifest recommendations
  • use of GitHub Security Advisories or an Apache-aligned private reporting process once the project enters incubation

Clone this wiki locally