← Back to Blog
HailBytes SAT · Release Notes

HailBytes SAT May 2026 Release: Exemption Management, Cortex XSIAM & Security Hardening

June 8, 2026 • 7 min read

The May 2026 release of HailBytes SAT delivers the two most-requested program-governance features — a formal exemption workflow with dual-approval and a full audit trail, and native event forwarding to Palo Alto Cortex XSIAM — alongside a security maintenance release that upgrades the Go runtime to 1.25 and clears eleven-plus stdlib CVEs. CI/CD supply-chain hardening rounds out the release. This post covers what changed and why it matters for operators running awareness programs in regulated environments.

What's New in May 2026

  • Exemption management — request-and-approve workflow with dual-approval enforcement, three scope types (campaign / training module / time-bound period), five-state lifecycle, and a per-exemption audit trail accessible via API
  • Cortex XSIAM event forwarding — native HTTP Log Collector adapter joins the existing Splunk and Microsoft Sentinel connectors; configure via POST /api/integrations/xsiam with a test-connectivity endpoint
  • Go 1.25 runtime — resolves 11+ Go stdlib CVEs including a HIGH-severity html/template XSS (GO-2026-4603); govulncheck ./... now clean in CI
  • CI/CD hardening — tool-binary caching, Gitleaks SHA-256 pinning, Packer 1.11.2 version lock, race-condition fix in concurrent migration test, and ubuntu-24.04 runner pinning across all workflows

Exemption Management: Governed Exclusions with a Paper Trail

Every ongoing awareness program eventually faces the same operational question: how do you legitimately exclude someone from a campaign or a training assignment without quietly editing a recipient list and losing accountability? An employee on parental leave shouldn’t be auto-enrolled in mandatory training. An executive’s assistant may need scoping out of a specific simulation. A department mid-reorg might need a time-bounded pause. Handling these informally — removing users from lists, skipping them manually — works at small scale but becomes a liability once auditors ask why a given user has no completion record for a required module.

Exemption management turns that undocumented workaround into a governed, evidence-producing process. Instead of silently dropping users from scope, an admin records a formal exemption with a justification, a defined scope, and an approval from a second administrator. Every state transition is written to an audit log with the actor, timestamp, and reason. A missing completion record is no longer an anomaly to explain — it’s an approved, dated exception with a justification attached.

How the Workflow Operates

Exemptions pass through a five-state machine: requestedapproved or rejectedrevoked or expired. The system enforces that the person requesting an exemption cannot be the same person who approves it — self-approval is blocked at the model layer, not just the UI. Approved exemptions can be revoked at any point; time-bounded period exemptions expire automatically when their end date passes.

Each exemption is scoped as narrowly as the situation requires:

  • Campaign — exclude a user from a specific phishing simulation run.
  • Training module — exclude a user from a specific assigned training module.
  • Time-bounded period — exclude a user for a defined window (e.g., the duration of a leave), with automatic re-entry when the period ends.

The REST API exposes the full lifecycle: GET /api/exemptions with optional ?state= filter, POST /api/exemptions/{id}/approve, POST /api/exemptions/{id}/reject, POST /api/exemptions/{id}/revoke, and a dedicated GET /api/exemptions/{id}/audit endpoint that returns the timestamped state history for a single exemption. All endpoints enforce tenant scoping — exemptions are per-organization with no cross-tenant visibility.

For SOC 2 and ISO 27001 auditors

Security-awareness training controls require evidence of not just who completed training but why anyone didn’t. A governed exemption with a dual-approval trail answers the second question directly, converting a manual explanation into a queryable, durable record.

For a deeper look at the exemption workflow and the compliance rationale behind it, see the full feature post.

Cortex XSIAM: Third SIEM Connector

HailBytes SAT already forwards campaign and training events to Splunk and Microsoft Sentinel. This release adds a native adapter for Palo Alto Cortex XSIAM, posting events to the XSIAM HTTP Log Collector endpoint so simulation outcomes — phishing link clicks, credential submissions, email reports, training completions, and exemption state changes — land in the same analytics platform as the rest of your security telemetry.

The XSIAM connector configuration mirrors the Splunk and Sentinel pattern: navigate to the integrations settings, enable the XSIAM dispatcher, supply the tenant’s HTTP Log Collector URL, API key, and key ID. A POST /api/integrations/xsiam/test endpoint verifies connectivity before you commit the settings. The collector name defaults to hailbytes-sat and is configurable for operators running multiple SAT instances under a shared XSIAM tenant.

The connector runs alongside Splunk and Sentinel rather than replacing them, so teams mid-migration can forward to more than one destination simultaneously. If you already use Cortex XSIAM as your primary security analytics platform, SAT data now arrives there directly without an intermediate forwarder.

Go 1.25 Runtime: Security Maintenance

The Go toolchain has been updated from 1.24 to 1.25.10, the current stable release. This update was driven by a security audit that identified eleven-plus CVEs in the Go 1.24 standard library still present in the prior build:

  • GO-2026-4603 (HIGH) — Cross-site scripting in html/template: attacker-controlled template data could inject unescaped content into rendered HTML. This is relevant for any SAT deployment rendering campaign-related data through Go’s templating engine.
  • Ten additional stdlib CVEs of medium and low severity across net/http, crypto/tls, and related packages.

The 1.25 Docker build image is now the base for both the application binary and the build stage; go.mod pins the toolchain directive to 1.25.10. After the upgrade, govulncheck ./... runs clean in CI with zero findings.

This is a transparent upgrade: no API surface changes, no behavioral differences in application code, no action required on upgrade. SCA tooling (AWS Inspector, Azure Defender for Containers) will see the stdlib CVE findings clear after the updated image is deployed.

CI/CD Supply-Chain Hardening

Several CI/CD improvements reduce build flakiness and close supply-chain risk vectors. These don’t affect the running application but matter for organizations evaluating HailBytes SAT’s build and deployment security posture.

Gitleaks binary verification. The secret-scanning step in CI downloads the Gitleaks binary from GitHub Releases and runs it against every commit. Previously the binary was extracted immediately after download with no integrity check, leaving the pipeline vulnerable to a tampered binary if the upstream release URL were ever compromised. The step now verifies a SHA-256 hash against a pinned expected value before extraction; a mismatch fails the build before any code runs.

Packer version pinned to 1.11.2. The Packer VM image build step previously used latest, meaning a HashiCorp release could silently change validation behavior mid-cycle. The explicit version pin ensures builds are reproducible and prevents an upstream breaking change from hitting the release pipeline unannounced.

Tool-binary caching. Three Go tool binaries — gotestsum (1.13.0), govulncheck (1.1.4), and go-licenses (2.0.1) — are now cached by version key in CI, avoiding recompilation from the module proxy on every run. Combined with a conditional install check (skip if binary already cached), this reduces tool-installation latency and the window of exposure to a transient module proxy outage.

Concurrent migration test race fix. The migration concurrency test had used a time.Sleep(10ms) stagger to put two goroutines near the advisory lock simultaneously. On loaded CI runners the sleep was unreliable, producing intermittent failures. The stagger is replaced with a sync.WaitGroup barrier that guarantees both goroutines reach the lock boundary at the same instant, with atomic.Int32 counters asserting that the advisory lock actually serializes them. The test now passes deterministically regardless of runner load.

Runner pinning to ubuntu-24.04. All workflows that referenced ubuntu-latest are updated to the explicit ubuntu-24.04 tag, preventing silent behavior changes when GitHub updates the alias. This affects the Packer build, OpenAPI lint, demo smoke test, cleanup, and integration test workflows.

Upgrading

This release is available on the AWS Marketplace and Azure Marketplace. Existing deployments update by redeploying the VM image. No schema migration beyond the standard goose bootstrap is required; the exemptions table is created automatically on first boot after upgrade.

The exemption management endpoints are immediately available after upgrade; existing campaigns and training assignments are unaffected. To configure Cortex XSIAM forwarding, navigate to Settings → Integrations and enable the XSIAM connector. The Go 1.25 update is transparent — no configuration changes required.

Run a Phishing Program You Can Defend in an Audit

HailBytes SAT deploys in your own AWS or Azure account with governed exemptions, a full audit trail, and event forwarding to Splunk, Microsoft Sentinel, and Palo Alto Cortex XSIAM.