BloodHound

Graphify is a tool designed to streamline working with graph data through the following workflow:

1. Ingestion: Ingests user-specified JSON files into a PostgreSQL database.
2. Analysis: Performs graph analysis on the ingested data.
3. Output: Produces two graph-ready files:
   • A file representing the raw ingested graph.
   • A file containing the analyzed graph.

DoodleUi is the component library implementing the SpecterOps design system. It provides a unified set of components, patterns, and guidelines designed to ensure consistency, accessibility (WCAG), and brand alignment across SpecterOps products.

Key features include:

• Pre-built Components: Includes Buttons, checkboxes, inputs, tables, and more.
• Accessibility: Components are designed to meet WCAG standards out of the box.
• Development Approach: Components are generated using shadcn to avoid reinventing common UI patterns.

The schemagen tool is organized into two primary components:

1. generator: The core library responsible for language-specific code generation for all supported languages.
2. tsgen: A TypeScript code-generation framework written in Go. It implements a subset of TypeScript syntax specifically designed to produce schema types and helper functions. Note that tsgen is not a general-purpose TypeScript generator and does not aim for full TypeScript compatibility.

bh-playwright-testing provides shared Playwright testing utilities for BloodHound UI workspaces. It centralizes common building blocks to ensure consistency across different BloodHound UI test suites.

Key features include:

• axe-core fixture and reporting for accessibility testing.
• Authentication bootstrap helpers.
• API route stubs (Cypher queries, MFA, Password Reset, API Tokens).
• Theme matrix helpers.

Note: This package does not manage Playwright configurations (browsers, reporters), specific application pages/routes, or application-specific environment variables. Consumers are expected to compose these concerns on top of the provided modules.

BloodHound uses Goose to manage database schema changes via versioned SQL files. Migrations are tracked in the goose_db_version table. Each migration file follows a timestamp-based naming convention (YYYYMMDDHHMMSS_description.sql) and contains two mandatory sections: -- +goose Up for applying changes and -- +goose Down for rolling them back.

On application startup, the system automatically compares the goose_db_version table against available migration files and applies any pending migrations in the correct order.

The bhce/server repository is organized into a shared core and vertical feature slices. Each feature is a self-contained unit that owns its layers from HTTP to SQL.

Directory Structure:

• modules/: Contains the shared dependency container and the module registry.
• responses/: Shared HTTP response helpers (envelopes, error wrappers).
• <feature>/: A vertical feature slice containing:
  • <feature>.go: The entry point for registering the feature.
  • appdb/: The persistence layer (SQL via go-sqlbuilder + pgx).
  • handlers/: The HTTP layer (routes, handlers, JSON views).
  • services/: The business-logic layer (domain types and interfaces).

The Audit Logging Middleware proposal (RFC 7) shifts audit logging from the database layer to the HTTP middleware layer. This change ensures that audit coverage is the default behavior for all registered routes, rather than being an opt-in process requiring manual instrumentation at each call site.

Key objectives include:

• Coverage by default: Automatically auditing every registered route.
• Separation of concerns: Moving auditing logic from the database layer to the HTTP layer.
• Consistent attribution: Centralizing the derivation of Actor, source IP, request ID, and timing using bhctx and IdentityResolver.
• Bounded table growth: Implementing monthly created_at partitioning for audit_logs to allow for controlled retention via DROP PARTITION.