> ## Documentation Index
> Fetch the complete documentation index at: https://docs.garnet.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Checks

> Runtime checks that evaluate what your workflow actually did — like unit tests for execution behavior.

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](https://app.garnet.ai), and any configured [webhooks](/using-platform/alerts). A single failed check marks the entire run as **flagged**.

***

## How checks work

<Steps>
  <Step title="Profile" icon="eye">
    [Jibril](/architecture) profiles every process spawn, network connection, and file access during the workflow run via eBPF.
  </Step>

  <Step title="Evaluate" icon="list-check">
    The control plane evaluates the resulting profile against each enabled check.
  </Step>

  <Step title="Verdict" icon="gavel">
    Each check returns **pass**, **fail**, or **warn** with structured evidence. Results are published to the Job Summary, PR comment, dashboard, and alerts.
  </Step>
</Steps>

***

## 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](https://www.garnet.ai/resources/garnet-saw-trivy-teampcp), [Checkmarx KICS compromise](https://www.garnet.ai/resources/garnet-saw-checkmarx-kics), and [Shai-Hulud npm campaign](https://www.garnet.ai/resources/garnet-saw-shai-hulud) — 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](https://socket.dev/blog/tanstack-npm-packages-compromised-mini-shai-hulud-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](https://attack.mitre.org/) category.

<AccordionGroup>
  <Accordion title="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                         |
  </Accordion>

  <Accordion title="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 |
  </Accordion>

  <Accordion title="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                |
  </Accordion>

  <Accordion title="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                      |
  </Accordion>

  <Accordion title="Privilege escalation">
    | Detection                   | What it means                                      |
    | :-------------------------- | :------------------------------------------------- |
    | `sudoers_modification`      | Sudoers configuration modified                     |
    | `capabilities_modification` | Linux capabilities modified (privilege escalation) |
  </Accordion>

  <Accordion title="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)  |
  </Accordion>

  <Accordion title="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 |
  </Accordion>
</AccordionGroup>

Full detection documentation with examples: [jibril.garnet.ai/detections](https://jibril.garnet.ai/detections/)

***

## Using check results

### In workflows

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

```yaml theme={null}
- 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](https://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](/using-platform/alerts).