Cloud-Native Detection & Response Pipeline - Jirrix

The problem

Security teams fail in two predictable, documented ways. The first is upstream: misconfigured infrastructure reaches production because security checks happen manually, late, and inconsistently - after the code is already deployed. The second is downstream: when something does get through, analysts face alert queues where genuine threats are buried in noise. Both failures are well-known. Neither is adequately solved at scale.

For smaller organisations and individual practitioners, the problem is compounded. Enterprise SIEM and detection platforms cost money they do not have. The open-source alternatives exist, but no single reference implementation shows how to connect them - from hardened infrastructure provisioning, through log shipping, to detection rules mapped to MITRE ATT&CK, to AI-assisted triage - in one reproducible, auditable pipeline.

Jirrix is that reference implementation. One repository. Every layer. Reproducible from code.

What Jirrix does

Jirrix provisions a cloud workload as infrastructure-as-code, hardens it, ships its logs to a centralised pipeline, runs CI/CD security gates on every commit, simulates real-world attacks against it, detects those attacks using version-controlled Sigma rules mapped to MITRE ATT&CK, and uses an AI assistant to triage alerts and draft the incident report.

Every phase is reproducible. Every decision is documented. The entire pipeline - from a blank cloud account to a triaged incident report - can be rebuilt from this repository.

Architecture

The pipeline runs across three logical layers. The infrastructure layer provisions a hardened DigitalOcean droplet using OpenTofu - firewall rules, SSH hardening, and least-privilege access are defined in code, not applied manually after the fact. The workload layer runs a containerised Flask application whose logs are shipped in real time to Grafana Cloud Loki via the Alloy agent. The detection layer applies four Sigma rules against the log stream, covering SSH brute force (T1110.001), application brute force (T1110.001), cloud metadata access (T1552.005 - critical), and port scan detection (T1046).

A notable finding during attack simulation: the cloud metadata endpoint at 169.254.169.254 responded during testing and is documented as a real, unmitigated finding - not a simulated one. Real hostile traffic from external IPs was observed within hours of deployment. Both are treated as genuine portfolio evidence of a live threat environment.

Security decisions made

• Infrastructure-as-code, not manual configuration. Manual hardening is not auditable and does not survive a rebuild. Every firewall rule, SSH setting, and access control is in OpenTofu - reproducible, version-controlled, and reviewable in a pull request.
• Shift-left CI/CD gates. Checkov scans IaC for misconfigurations before deployment. Trivy scans container images for vulnerabilities before they run. Semgrep performs static analysis on application code. Gitleaks catches secrets before they reach the repository. The alternative - scanning after deployment - is how breaches happen.
• Detection-as-code with Sigma. Sigma rules are vendor-neutral and version-controlled. The alternative - GUI-configured detection rules in a proprietary SIEM - cannot be reviewed, diffed, or reproduced. Four rules cover the highest-probability attack paths against this environment.
• MITRE ATTCK mapping on every rule. Each detection is tagged to a specific technique. This is not cosmetic - it lets a triage analyst immediately understand adversary intent, not just the raw event.
• Cloud metadata endpoint documented, not silently remediated. When 169.254.169.254 responded during simulation, the finding was documented rather than quietly patched. The reasoning: remediating without documenting means the finding disappears from the record, and future analysts have no context for why a control exists.
• AI triage as an assist, not an authority. Gemini is used to draft the incident report and suggest triage priority - not to make final decisions. The output is reviewed by a human analyst. This is the correct use of AI in a security operations context in 2026.

Tech stack

Layer	Tool	Why this, not the alternative
Infrastructure-as-Code	OpenTofu	Open-source Terraform fork - no licence restrictions, identical HCL syntax
Cloud	DigitalOcean	Predictable hourly billing, simple API, no hidden egress costs at this scale
Containers	Docker / Compose	Industry standard; reproducible workload environment regardless of host
CI/CD	GitHub Actions	Native to the repository - no separate pipeline infrastructure to secure
Secret scanning	Gitleaks	Catches secrets before they enter git history - not after
IaC scanning	Checkov	Purpose-built for Terraform/OpenTofu; 1,000+ built-in policies
Image scanning	Trivy	Scans OS packages, libraries, and IaC in one tool
SAST	Semgrep	Language-aware, pattern-based; low false-positive rate versus regex scanning
CSPM	Prowler	Cloud-agnostic, maps findings to CIS benchmarks and ATT&CK automatically
Log pipeline	Grafana Alloy + Loki	Free tier covers this scale; Loki is purpose-built for log aggregation without indexing overhead
Detection	Sigma	Vendor-neutral, version-controllable, convertible to any SIEM query language
Attack simulation	Atomic Red Team	ATT&CK-mapped, reproducible, community-maintained test library
AI triage	Gemini API	Free tier adequate for this use case; used as an assist, not an authority

Real-world context and application

Jirrix is applicable to any organisation running cloud workloads that lacks the budget for enterprise SIEM but cannot afford to operate blind. Specific deployment scenarios:

• A fintech startup shipping its first cloud-hosted API - needs shift-left security gates and log visibility before it can afford a dedicated security team
• A security practitioner building a home lab environment to practice detection and response in a realistic cloud context
• A small security team that needs a reproducible, documented detection pipeline they can present to auditors or compliance reviewers

What I learned

The most significant lesson was not technical. It was that real hostile traffic arrives faster than expected - external IPs were probing the droplet within hours of deployment. This changed how I think about the window between "infrastructure deployed" and "detection active." That window is not theoretical. It is measured in minutes.

On the technical side: the cloud metadata endpoint responding during simulation was unexpected. It became the most important finding in the project - not because it was the most complex, but because it is the exact attack path used in real-world breaches. Documenting it rather than quietly patching it was the right call, and it sharpened my understanding of why detection rules need to exist even for "known" vulnerabilities.

The Gemini API triage integration hit a 429 quota error on first run. The lesson: AI integrations in security pipelines need rate-limit handling and fallback behaviour from day one - not as an afterthought. A triage tool that fails silently under load is worse than no triage tool, because analysts may assume alerts were reviewed when they were not.

Finally: building the full pipeline - from IaC provisioning through to AI-drafted incident report - as one engineer, in one repository, gave me a systems-level understanding of detection and response that no individual tool certification could have provided.