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

# CICD-SEC-7 — Actions debug logging enabled in workflow

> ACTIONS_STEP_DEBUG / ACTIONS_RUNNER_DEBUG in env emit verbose logs that can leak secret values.

| Field    | Value                                                                                                                                            |
| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| Category | `CICD-SEC-7`                                                                                                                                     |
| Severity | **HIGH**                                                                                                                                         |
| OWASP    | [CICD-SEC-7: Insecure System Configuration](https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-07-Insecure-System-Configuration) |
| Auto-fix | ✓ ([what it does](#auto-fix))                                                                                                                    |

## What the check does

Flags any `env:` block (workflow, job, or step level) that sets either of:

* `ACTIONS_STEP_DEBUG`
* `ACTIONS_RUNNER_DEBUG`

…to a truthy value (`true`, `1`, `yes`, `on`, case-insensitive).

## Why it matters

These environment variables turn on the **debug-logging knobs** GitHub designed for interactive troubleshooting. When enabled:

* The runner prints the value of **every environment variable** at step boundaries.
* Internal action logs ordinarily filtered to "info" are emitted at "debug" — and many third-party actions log secret-derived values at debug level on the assumption no-one will see them.
* Secret masking sometimes fails on transformed values (e.g. a base64-encoded secret, or one passed through `jq`).

Anyone with **read** access to workflow logs (including PR-fork contributors, if the workflow runs on `pull_request`) can read those logs.

GitHub provides a "Re-run with debug logging" button for genuine troubleshooting — debug logging committed to a workflow file is almost always a forgotten `git commit -a` from a debugging session.

## Vulnerable example

```yaml theme={null}
env:
  ACTIONS_STEP_DEBUG: true        # ← exposes secret-derived values in logs

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: ./build.sh
```

## Safe alternative

Remove the env entry. When you need debug logs, re-run the workflow with debug enabled from the GitHub UI: **Actions** → failed run → **Re-run jobs** → check **Enable debug logging**. The toggle applies to that single re-run and isn't persisted.

For deeper instrumentation that you do want to keep, structure your scripts to emit explicit logs at `::notice::` / `::warning::` / `::error::` levels, which integrate cleanly with the run summary without dumping the entire environment.

## Auto-fix

`--fix` deletes the `ACTIONS_STEP_DEBUG` / `ACTIONS_RUNNER_DEBUG` entry from whichever `env:` block (workflow, job, or step) contains it. Sibling env entries in the same block are preserved. If the env block ends up empty, it's left in place — yaml.v3 emits `env: {}` which the runner accepts.