Skip to main content

​
Events & Issues

Garnet collects Events (raw telemetry) and surfaces Issues (unknown egress detections).

​
Events

Events are raw telemetry captured by Jibril agents via eBPF.

​
Event Types

TypeWhat It CapturesExample
DNSDomain name queriesregistry.npmjs.org
ConnectOutbound TCP/UDP connections104.16.132.229:443
ProcessProcess start/exit with ancestrynode → npm → curl
FileFile read/write correlated with network/tmp/malware.sh

​
Event Schema

{
  "type": "dns",
  "timestamp": "2024-03-15T14:32:15Z",
  "query": "registry.npmjs.org",
  "response": ["104.16.132.229"],
  "process": {
    "pid": 1234,
    "command": "/usr/bin/npm",
    "args": ["install", "express"],
    "parent_chain": ["bash", "npm", "node"]
  },
  "context": {
    "workflow": "CI",
    "job": "build",
    "step": "Install dependencies"
  }
}
Events are not alerts. Most events are normal—Garnet collects everything to build baselines.

​
Issues

Issues are created when Garnet detects unknown egress: an outbound connection not seen in the baseline for that micro-context.

​
Issue Lifecycle

Event → Baseline Check → Unknown? → Issue Created → Alert/Block

​
Issue Fields

FieldDescription
Titlee.g., “Unknown egress to malicious-domain.com”
SeverityCritical, High, Medium, Low
Micro-ContextWorkflow step (GHA) or Node (K8s)
ProcessFull command line and ancestry
Domain/IPTarget of outbound connection
VerdictDetected (logged) or Blocked (if Enforce enabled)
TimestampWhen the connection was attempted

​
Example Issue

Example Issue showing unknown egress detection
Title: Unknown egress to crypto-pool.example.com Details:
  • Process: /usr/bin/xmrig --url=crypto-pool.example.com:443
  • Parent: sh → curl → xmrig
  • Context: Kubernetes node gke-prod-node-123
  • Verdict: Blocked (Enforce mode enabled)

​
How Baselines Work

Garnet learns “normal” behavior per micro-context over time.

​
Micro-Context

A micro-context is a specific scope in which Garnet learns behavior:
  • GitHub Actions
  • Kubernetes
Micro-context = Workflow + Job + StepExample:
  • Workflow: CI
  • Job: build
  • Step: Install dependencies
If this step connects to registry.npmjs.org once, future runs of this exact step expect it.But if step Run tests connects to registry.npmjs.org, that’s unknown egress (different micro-context).

​
Baseline Learning Period

Garnet builds baselines automatically:
  1. First run: All egress is new, but flagged as “establishing baseline”
  2. Next 7 days: Normal connections are learned
  3. After 7 days: Baseline is “stable”; unknown egress triggers Issues
You can adjust this. In Settings, configure baseline period from 1 to 30 days.

​
False Positives

​
What Causes Them?

  • Dynamic infrastructure: CDNs with rotating IPs
  • Vendor API changes: New endpoints added to third-party services
  • Legitimate new dependencies: You added a new package

​
How to Handle

1

Review the Issue

Check if the domain/IP is expected for your workload.
2

Mark as Known Good

Dashboard → Issue → Mark as Known (adds to allowlist)
3

Add to Policy

For permanent allow, create a policy rule:
policies:
  - name: "Allow npm registry mirrors"
    allow:
      - "*.npmjs.org"
      - "registry.yarnpkg.com"
See Policy Examples.

​
Viewing Events & Issues

​
Dashboard

​
Filters

Filter by:
  • Severity: Critical, High, Medium, Low
  • Verdict: Detected, Blocked
  • Time range: Last hour, day, week, custom
  • Context: Specific workflow, node, or cluster
Events table with filters

​
Event Retention

PlanRetention
Free7 days
Team30 days
Enterprise90 days (configurable)
Issues are retained forever, even if raw events expire.

​
Next Steps

Baselining & Node Scope

Deep dive into how baselines work

Modes: Detect vs Enforce

Learn when to enable blocking