> ## 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-3 — Known-vulnerable action version

> A pinned action whose version falls in a published GitHub Security Advisory range.

| Field    | Value                                                                                                                              |
| -------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| Category | `CICD-SEC-3`                                                                                                                       |
| Severity | **HIGH**                                                                                                                           |
| OWASP    | [CICD-SEC-3: Dependency Chain Abuse](https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-03-Dependency-Chain-Abuse) |
| Pass     | Online — requires [`--audit-pins`](/cli/flags)                                                                                     |
| Auto-fix | ✗                                                                                                                                  |

## What the check does

For each referenced action, Pipefort queries the [GitHub Advisory Database](https://github.com/advisories?query=type%3Areviewed+ecosystem%3Aactions)
(`actions` ecosystem) and flags the reference when its version falls inside a
published advisory's vulnerable range. Runs only in the opt-in online pass.

The version compared is:

* the tag, when the action is pinned by tag (`@v1.2.3`), or
* the version named in the `# vX` comment, when pinned by SHA.

A SHA pin **without** a version comment can't be matched to a version, so it is
not checked by this audit — keep a version comment on SHA pins so this audit can
protect them.

## Why it matters

Actions are dependencies. When a vulnerability is disclosed for an action (token
exfiltration, command injection, cache poisoning), every workflow still pinned to
an affected version inherits the risk. This audit surfaces those before they're
exploited, the same way Dependabot does for package dependencies.

## Vulnerable example

```yaml theme={null}
# a version inside a published GHSA vulnerable range
- uses: some-org/some-action@1.0.0
```

## Safe alternative

Upgrade to a patched version (and re-pin to its commit SHA):

```yaml theme={null}
- uses: some-org/some-action@<sha-of-1.2.3> # v1.2.3
```

See the GHSA advisory linked in the finding for the affected ranges and the first
patched version.