Skip to content
Internal

Aegis Security Program

N1 Healthcare — OSS-first, ≤2-operator autonomous XDR · Last updated June 2026

Phase Status at a Glance

Section titled “Phase Status at a Glance”
# Phase Status Key tools
1 Pre-commit + CI security gate In progress opengrep · gitleaks · trufflehog · grype · trivy · zizmor · harden-runner · safe-chain
2 Artifact signing + SBOM + provenance Not started Syft · cosign · docker/build-push-action (SLSA)
3 Cloud & cluster posture Not started Prowler · Kubescape
4 Telemetry pipeline Not started OTel Collector (existing) · Vector (security-event router into hot + cold)
5 Data store Not started SigNoz/ClickHouse (hot — already in cluster) · DuckDB + Iceberg/S3 (cold — to build)
6 Detection-as-code + runtime Not started Sigma · Falco (modern eBPF) · Tetragon (later)
7 Endpoint / host Not started Wazuh · Velociraptor
8 Threat intelligence Not started MISP · OpenCTI · STIX/TAXII
9 Case management + SOAR Not started DFIR-IRIS · Shuffle · LLM red-team loop

Architecture: Two-Repo Split

Section titled “Architecture: Two-Repo Split”
  • n1-security — owns detection rules, pre-commit definitions, calibration sweeps, and the opengrep ruleset. Single source of truth for what is checked.
  • bastion — owns CI enforcement: SHA-pinned composite-action wrappers and reusable workflows consumed by every repo as n1healthcare/bastion/...@develop. Calls out to n1-security for rules but never duplicates them.

Caller Pattern (Any Repo’s CI)

Section titled “Caller Pattern (Any Repo’s CI)”
security-gate:
```yaml
  uses: n1healthcare/bastion/.github/workflows/security-gate.yml@develop
  with:
    report_only: true  # drop once findings are triaged to zero
### Phase 1 — Pre-commit + CI Security Gate


#### SAST — opengrep (11 rules, 5 OWASP categories)


n1-security · report-only pilot


opengrep
n1-security/code-security/opengrep-rules/


- The fully-open fork of Semgrep — Semgrep's maintained rules went proprietary in Dec 2024. Runs against changed files on every PR.
- Rules live in `n1-security` and are fetched into the CI job via `SECURITY_HOOKS_REV`.
- **injection/** — SQL injection (`python-sqli.yml`), command injection (`python-command-injection.yml`)
- **supply-chain/** — eval/loader patterns, inline Node exec, env-as-URL, npm lifecycle hooks, create-require misuse, signature IOCs (`sig-ioc.yml`)
- **crypto/** — weak-cipher and broken-hash detection (`python-crypto.yml`)
- **data-integrity/** — unsafe deserialization (`python-deserialization.yml`)
- **web/** — JS XSS and injection patterns (`js-security.yml`)


CI job (security-gate.yml → sast)


```yaml
uses: n1healthcare/bastion/.github/actions/opengrep@develop
with:
  rev: ${{ env.SECURITY_HOOKS_REV }}  # pinned to develop branch of n1-security
  base_ref: ${{ github.base_ref }}
  report_only: ${{ inputs.report_only }}

Outstanding: full sweep across all repos in progress — findings triaged to zero before report_only is flipped to false (blocking).

Phase 1b

Section titled “Phase 1b”

Secret scanning — gitleaks + trufflehog

bastion · two-layer net

gitleaks v8.30.1 trufflehog v3.95.5

  • gitleaks — broad diff-level net; pattern-matches every changed line.
  • trufflehog — verifies entropy hits against live APIs; only fails the build on confirmed-live secrets (only_verified: true).
  • Both are standalone binaries, not GitHub Actions — the proprietary gitleaks-action was introduced at v2.0.0 and is not used.

trufflehog wrapper

uses: n1healthcare/bastion/.github/actions/trufflehog@develop
with:
  base_ref: ${{ github.base_ref }}
  only_verified: 'true'  # fails only on live credentials

Phase 1c

Section titled “Phase 1c”

Dependency CVE + IaC + malicious packages

bastion · grype / trivy / safe-chain

grype v0.112.0 trivy (IaC only) safe-chain (AikidoSec)

  • grype — owns CVE scanning, covering OSV, NVD, and GitHub Advisory databases. OSV-Scanner is not added — grype already covers the OSV database.
  • trivy — restricted to IaC/config misconfigurations only; its vulnerability scanner is disabled to avoid duplicate noise with grype.
  • safe-chain — the closest OSS approximation to behavioral malicious-package detection; age-gates newly published packages before they can be installed.

Phase 1d

Section titled “Phase 1d”

GitHub Actions workflow integrity — zizmor

bastion · static audit of CI workflows

zizmor v1.25.2

  • Statically audits all GitHub Actions workflow files for injection patterns, over-broad permissions, and unsafe use of context variables.
  • Runs as a dedicated job in security-gate.yml alongside SAST and dependency scanning.

Phase 1e

Section titled “Phase 1e”

CI egress control — harden-runner

bastion · audit mode, block pending allowlist derivation

step-security/harden-runner v2.9.1

  • The first step of every job in all bastion reusable workflows.
  • Installs an eBPF probe that intercepts outbound connect() syscalls.
  • audit mode (current) — every external endpoint a CI job contacts is logged to the StepSecurity dashboard.
  • block mode (next) — unlisted endpoints are denied and the job fails. arm64 block mode confirmed supported on v2.9.1.

Per-job (first step, every reusable workflow)

uses: n1healthcare/bastion/.github/actions/harden-runner@develop
with:
  egress-policy: ${{ inputs.egress_policy }}  # default: audit

Outstanding: derive allowlist from audit logs across a few PR cycles → flip default to block.

Phase 1f

Section titled “Phase 1f”

SHA-pinning + action integrity

bastion · all third-party actions pinned to immutable commit SHAs

  • Every third-party GitHub Action is pinned to a full commit SHA — not a mutable tag like @v4.
  • All pins are registered in bastion/docs/action_pins.md, the single source of truth.
  • Binary tools are SHA256-verified at download time for both amd64 and arm64.
  • Real-world precedent: the Trivy action supply-chain attack (March 2026) re-pointed the master tag at an exfiltration payload. SHA-pinned repos were unaffected.

Phase 1g

Section titled “Phase 1g”

Pre-commit hooks (developer local)

n1-security · self-installing, no manual binary setup

opengrep trivy grype zizmor

  • Brings the same checks to the developer’s workstation before code reaches CI.
  • Hooks live in n1-security/code-security/hooks/ and are self-installing — the setup script downloads and verifies all binaries automatically.

Phase 2 — Artifact Signing, SBOM & Provenance (not started)

Phase 2

Section titled “Phase 2”

cosign + Syft SBOM + SLSA provenance

bastion deploy.yml · bind build → image → admission in one trust chain

Syft (CycloneDX SBOM) cosign (keyless/OIDC) docker/build-push-action provenance: mode=max

  • Syft SBOM — generates a CycloneDX-JSON bill of materials after build, before image push. Wired into deploy.yml. Must fail loud — no || true.
  • cosign keyless signing — signs the image digest (not the tag) using OIDC; also runs cosign attest --type cyclonedx to attach the SBOM. The id-token: write permission is already on the deploy job.
  • SLSA provenance — enabled via docker/build-push-action native provenance: mode=max. slsa-github-generator is deferred unless an external party requires SLSA Level 3.
  • Admission gate (follow-up in n1-helm-charts) — Kyverno / sigstore policy-controller ClusterImagePolicy rejecting unsigned images. Until that ships, signing is attestation-only, not an enforcement gate.

Phase 3 — Cloud & Cluster Posture (not started)

Phase 3

Section titled “Phase 3”

Prowler (cloud config) + Kubescape (cluster)

scheduled workflows · read-only credentials

Prowler (AWS + GCP, CIS / HIPAA) Kubescape (NSA / CIS k8s)

  • Prowler — scheduled scan of AWS and GCP with read-only credentials; emits findings against CIS and HIPAA benchmarks.
  • Kubescape — scans the live EKS cluster state against NSA/CISA and CIS Kubernetes benchmarks; findings feed the data store.
  • Checkov is not added — trivy already covers static IaC and adding Checkov would duplicate it.

Phase 4 — Telemetry Pipeline (not started)

Phase 4

Section titled “Phase 4”

Vector security-event router (OTel Collector already in place)

one collection path, no parallel collectors

OpenTelemetry Collector (existing) SigNoz / ClickHouse (existing) Vector (to add — security-event router only)

  • The OTel Collector is already running in the cluster feeding SigNoz/ClickHouse — nothing changes there.
  • The only new piece is Vector, which handles sources that don’t speak OTel: Falco syscall alerts, Wazuh host events, Sigma rule hits, and posture scan findings.
  • Vector normalises these into a common schema and routes them into both the hot store (ClickHouse) and the Phase 5 cold lake (Iceberg/S3).
  • Phase 4 ships the pipeline only — no detections are enabled yet. Events need to be landing in the store before Sigma rules are written, so rules can be tested against real data rather than fixtures.

Phase 5 — Data Store (not started)

Phase 5

Section titled “Phase 5”

Iceberg/S3 cold lake — hot store already exists

SigNoz/ClickHouse is the hot store · only cold tier is new build

SigNoz / ClickHouse (hot — already in cluster) Apache Iceberg + S3 (cold — to build) DuckDB (query engine for cold)

  • Why this layer exists — Sigma correlation rules need a queryable store to run against. Phase 5 is the direct prerequisite for Phase 6; detections cannot be enabled until there is somewhere to query.
  • Hot store: already done — N1 runs SigNoz on ClickHouse in the cluster, fed by OTel. No new hot-store tooling is needed. VictoriaLogs is not introduced.
  • Cold tier: Iceberg/S3 + DuckDB — SigNoz is typically configured for short retention (days to weeks) to keep ClickHouse costs manageable. Security events need months to years for HIPAA audit trails and forensic investigation. Parquet/Iceberg files on S3 cover this: cheap at rest, queried ad-hoc with DuckDB, standard SQL, no proprietary engine.
  • Why not Quickwit — Quickwit was the previously recommended OSS security data store. It was acquired by Datadog on January 9, 2025 and is effectively stalled. Aegis explicitly flags it as a tool to avoid. DuckDB + Iceberg/S3 is the direct replacement.

Phase 6 — Detection-as-Code + In-Cluster Runtime (not started)

Phase 6

Section titled “Phase 6”

Sigma rules + Falco (modern eBPF) + Tetragon

n1-security/detection-and-response/ · Bottlerocket/arm64 EKS

Sigma (detection rules) Falco (modern eBPF / CO-RE) Tetragon (kprobes / BPF-LSM enforcement)

  • Sigma — detection rules version-controlled in n1-security/detection-and-response/. Each rule ships with a positive fixture (must fire) and a benign fixture (must not). Rules are compiled to the backend query format and rolled shadow → live.
  • Falco — syscall-level detection on EKS. The cluster is 100% EC2 / Bottlerocket / arm64 (no Fargate), so DaemonSets are fully viable. Must use the modern eBPF (CO-RE) driver — not the kernel-module driver — because Bottlerocket has an immutable root filesystem. BTF is present on all nodes so CO-RE is supported.
  • Tetragon — added after Falco for in-kernel enforcement via BPF-LSM. Detection-only works via kprobes with no node changes. BPF-LSM enforcement requires a Bottlerocket kernel boot flag, injectable via the existing Karpenter userData field.

Phase 7 — Endpoint / Host (not started)

Phase 7

Section titled “Phase 7”

Wazuh (HIDS) + Velociraptor (DFIR)

always-on monitoring vs on-demand hunt

Wazuh (FIM / log / HIDS) Velociraptor (live-response / hunt)

  • Wazuh — always-on host intrusion detection, file-integrity monitoring, and log collection.
  • Velociraptor — called on-demand for live forensic investigation and endpoint hunting.
  • Wazuh’s built-in vulnerability detector module is disabled — CVE scanning is owned by grype/trivy and duplicating it in Wazuh adds noise without signal.
  • Known limitation: OSS EDR depth on macOS/Windows trails commercial tools like CrowdStrike/SentinelOne.

Phase 8 — Threat Intelligence (not started)

Phase 8

Section titled “Phase 8”

MISP + OpenCTI

IOC aggregation → knowledge-graph analysis

MISP (IOC feed aggregation) OpenCTI (structured analysis / graph) STIX / TAXII (interchange format)

  • MISP — aggregates and shares threat indicators across external feeds.
  • OpenCTI — ingests MISP via STIX/TAXII and provides a knowledge-graph analysis layer over the raw indicators.
  • Indicators from this layer enrich detections and correlation queries in Phase 6.

Phase 9 — Case Management + SOAR + LLM Red-Team (not started)

Phase 9

Section titled “Phase 9”

DFIR-IRIS + Shuffle + LLM red-team loop

replaces commercial TheHive · self-defense for the AI pipeline

DFIR-IRIS (case management) Shuffle (SOAR playbooks) LLM red-team eval loop

  • DFIR-IRIS — replaces TheHive, which went commercial freemium.
  • Shuffle — SOAR playbooks: enrich findings via OpenCTI, isolate a host via Velociraptor, notify Slack.
  • LLM red-team loop — recurring prompt-injection, tool-abuse, and exfiltration evaluations against N1’s AI pipeline. A standing eval cadence, not a one-off — LLM runtime detection is the weakest OSS layer and needs continuous adversarial pressure.

Aegis program · N1 Healthcare · Last updated June 2026