Garnet Docs — Runtime visibility for untrusted execution

Every monitored run is evaluated against a suite of runtime checks. Think of them like unit tests, but for execution behavior: each check defines an invariant that should hold for a healthy run. Expected behavior passes silently; a violation fails the check with exact evidence — the process, domain, ancestry chain, and timestamp. Results appear in your PR comment, Job Summary, the Garnet dashboard, and any configured webhooks. A single failed check marks the entire run as flagged.

How checks work

Profile

Jibril profiles every process spawn, network connection, and file access during the workflow run via eBPF.

Evaluate

The control plane evaluates the resulting profile against each enabled check.

Verdict

Each check returns pass, fail, or warn with structured evidence. Results are published to the Job Summary, PR comment, dashboard, and alerts.

Current checks

Known bad egress


ID	`no_known_bad_egress`
Category	Network
Invariant	No contacted domain appears on Garnet threat intelligence lists.
Pass	No contacted domains matched known threats.
Fail	A contacted domain was found in Garnet threat intel — used in past supply-chain attacks, C2 infrastructure, or cryptominer pools.
Evidence	Domain, remote IP, protocol, full process ancestry chain.

This is the foundational check. It catches supply-chain compromises like the Trivy TeamPCP incident, Checkmarx KICS compromise, and Shai-Hulud npm campaign — all of which involved exfiltration to attacker-controlled domains that Garnet’s threat feed matches. Example: what a failed check looks like

Check                          Result
─────────────────────────────  ──────────────
Known bad egress               FAIL

Evidence:
  Domain:    scan.aquasecurtiy[.]org
  Process:   curl
  Ancestry:  systemd → bash → entrypoint.sh → curl
  Protocol:  TCP

Code injection via /proc memory


ID	`no_code_injection_via_proc_memory`
Category	Defense evasion · Credential access
Invariant	No process reads or modifies another process’s memory via `/proc/<pid>/mem`.
Pass	No process initiated code injection via `/proc/<pid>/mem` access.
Fail	A process read or modified another process’s memory via `/proc/<pid>/mem`.
Evidence	Target PID, accessor process, full ancestry chain, accessed path.

Attackers use /proc/<pid>/mem reads to scrape CI runner secrets from memory, encrypt the haul, and exfiltrate it. This is invisible to static analysis and workflow logs — only the runtime lineage shows the access. Detection signals:

code_modification_through_procfs — process memory modified via procfs
environ_read_from_procfs — environment variables read via /proc/<pid>/environ

Real-world example — TanStack compromise (May 2026): The TanStack supply-chain attack injected obfuscated code into 84 @tanstack/* npm packages via a compromised CI release pipeline. When consumed in CI, the malicious router_init.js spawned a daemonized child process that scraped runner secrets from /proc/<pid>/mem — the same /proc technique used in the TeamPCP and tj-actions attacks. The access is invisible in workflow logs but Garnet’s eBPF-level profiling captures the /proc read in the process lineage.

systemd
 └─ Runner.Worker
     └─ bash
         └─ node (npm install)
             └─ sh -c node router_init.js
                 └─ node router_init.js
                     └─ node (daemonized, detached stdio)
                         └─ cat /proc/<runner_worker_pid>/mem

The install completed normally. The /proc memory scrape ran in a detached child of the same tree. Only the runtime lineage shows both.

Binary execution and deletion


ID	`no_binary_execution_and_deletion`
Category	Execution · Defense evasion
Invariant	No process executes a binary and then deletes it from disk.
Pass	No program was executed and then deleted.
Fail	A program was executed, and then its file was deleted.
Evidence	Binary path, executor process, deletion timestamp, full ancestry chain.

Drop-and-delete is a standard evasion technique: the attacker downloads a binary, runs it, then removes it to avoid forensic detection. Garnet sees both the execution and the deletion in the eBPF trace. Detection signals:

binary_self_deletion — executable deleted itself after running
hidden_elf_exec — execution of a hidden (dot-prefixed) ELF binary
exec_from_unusual_dir — process executed from a non-standard directory (e.g. /tmp, /dev/shm)

Example:

Check                          Result
─────────────────────────────  ──────────────
Binary execution and deletion  FAIL

Evidence:
  Binary:    /tmp/.payload
  Executor:  bash
  Ancestry:  systemd → Runner.Worker → bash → /tmp/.payload
  Deleted:   2.3s after execution

Upcoming checks

The check suite is expanding. Checks below are in development and will roll out progressively — your runs will start receiving results as each ships, with no workflow changes required.

Credential file access


ID	`no_credential_access`
Category	Credential access
What it checks	Whether processes accessed files containing stored credentials, SSH keys, SSL certificates, or authentication tokens outside of expected patterns.
Detections	`credentials_files_access` — process accessed credential files. `ssl_certificate_access` — process accessed SSL/TLS certificate or key files. `passwd_usage` — process accessed the system password file. `auth_logs_tamper` — authentication logs modified (covering tracks).

Hidden binary execution


ID	`no_hidden_binary_execution`
Category	Execution
What it checks	Whether a hidden or dot-prefixed ELF binary was executed — a common evasion technique for dropping and running malicious tooling without appearing in standard directory listings.
Detections	`hidden_elf_exec` — execution of a hidden (dot-prefixed) ELF binary. `exec_from_unusual_dir` — process executed from a non-standard directory (e.g. `/tmp`, `/dev/shm`).

Detection signals

Checks are built on top of Jibril’s detection engine, which identifies individual signals during a run. A single check may combine multiple detection signals into one pass/fail verdict. Below is the full detection taxonomy grouped by MITRE ATT&CK category.

Network peers

Detection	What it means
`flow`	Outbound network flow observed
`dropip` / `dropdomain`	Connection matched threat intelligence (domain or IP)
`threat_domain_access`	Connection to a domain flagged as a known threat
`plaintext_communication`	Sensitive data transmitted over an unencrypted channel
`dyndns_domain_access`	Connection to a dynamic DNS domain (often used by attackers)
`vpnlike_domain_access`	Connection to a VPN or proxy service

Execution

Detection	What it means
`hidden_elf_exec`	Hidden or dot-prefixed ELF binary executed
`exec_from_unusual_dir`	Process executed from `/tmp`, `/dev/shm`, or similar
`interpreter_shell_spawn`	Interpreter process launched an interactive shell
`binary_executed_by_loader`	Binary executed via dynamic loader (indirect execution)
`code_on_the_fly`	Dynamic code generation and execution
`crypto_miner_execution`	Process matching known cryptocurrency mining software
`data_encoder_exec`	Encoding tool executed (potential exfiltration staging)
`runc_suspicious_exec`	Unexpected process execution within the container runtime

Defense evasion

Detection	What it means
`code_modification_through_procfs`	Process memory modified through the `/proc` filesystem
`environ_read_from_procfs`	Environment variables read via `/proc/<pid>/environ`
`binary_self_deletion`	Executable deleted itself after running

Credential access

Detection	What it means
`credentials_files_access`	Process accessed stored credential files
`ssl_certificate_access`	Process accessed SSL/TLS certificate or key files
`passwd_usage`	Process accessed the system password file
`auth_logs_tamper`	Authentication logs modified

Privilege escalation

Detection	What it means
`sudoers_modification`	Sudoers configuration modified
`capabilities_modification`	Linux capabilities modified (privilege escalation)

Persistence

Detection	What it means
`shell_config_modification`	Shell startup files modified
`package_repo_config_modification`	Package manager config altered (malicious sources)
`pam_config_modification`	Pluggable authentication module config altered
`global_shlib_modification`	Globally shared library modified (code injection)

Network tools

Detection	What it means
`net_filecopy_tool_exec`	File transfer utility executed
`net_scan_tool_exec`	Network or port scanner executed
`net_sniff_tool_exec`	Packet capture tool executed
`net_mitm_tool_exec`	Traffic interception tool executed
`net_suspicious_tool_exec`	Suspicious network reconnaissance tool executed

Full detection documentation with examples: jibril.garnet.ai/detections

Using check results

In workflows

The action outputs profile_result (pass or fail), which you can use in subsequent steps:

- uses: garnet-org/action@9e819143e63d6dda04bca2e90ac85e3cf0e5289d # v2
  id: garnet
  with:
    api_token: ${{ secrets.GARNET_API_TOKEN }}

# ... your build/test steps ...

- name: Fail on flagged run
  if: steps.garnet.outputs.profile_result == 'fail'
  run: |
    echo "Runtime check failed — see ${{ steps.garnet.outputs.report_url }}"
    exit 1

In the dashboard

Navigate to any run at app.garnet.ai to see:

Check results — pass/fail per check with evidence
Process tree — full lineage from init to leaf, with flagged connections highlighted
Egress summary — every outbound domain with protocol, IP, and process attribution

Via webhooks

Configure Slack or HTTP webhooks under Settings → Alerting to receive notifications on failed checks. See Alerting & Outputs.

​How checks work

​Current checks

​Known bad egress

​Code injection via /proc memory

​Binary execution and deletion

​Upcoming checks

​Credential file access

​Hidden binary execution

​Detection signals

​Using check results

​In workflows

​In the dashboard

​Via webhooks