---
title: Aegis Security Program
---

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

## 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

- **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)

```yaml
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

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

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

#### 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

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

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)

```yaml
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

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

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

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

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

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

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

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

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

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

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