# Export and track security findings

Use a completed Codex Security scan as the source for two different handoffs:

- **Export** creates a portable JSON, CSV, or SARIF file.
- **Track findings** prepares selected findings as Linear, GitHub, or Jira issues
  or one private draft GitHub Security Advisory, checks for duplicates, and
  waits for your approval before writing.

These workflows don't change the sealed scan bundle.

## Export a portable artifact

Open the completed findings workspace, select **Export**, and choose a format:

| Format | Use it for                                                        |
| ------ | ----------------------------------------------------------------- |
| JSON   | Preserve the sealed structured findings for tools and scripts.    |
| CSV    | Review findings and current local triage state in a spreadsheet.  |
| SARIF  | Send findings to tools that support the SARIF interchange format. |

Select **Export findings** and use the returned artifact path. Keep the
original `scan-manifest.json`, `findings.json`, and `coverage.json` together
when another tool needs the complete scan context rather than a findings-only
projection.

<figure className="not-prose my-8">
  <div className="overflow-hidden rounded-xl border border-subtle bg-surface">
    <img
      src={exportFindingsFormats.src}
      alt="Export findings dialog with JSON, CSV, and SARIF format options"
      className="block h-auto w-full"
    />
  </div>
  <figcaption className="mt-3 text-sm text-secondary">
    Export completed findings as JSON, CSV, or SARIF for downstream review and
    tooling.
  </figcaption>
</figure>

## Track selected findings

The `$codex-security:track-findings` workflow accepts one validated finding or
an explicitly selected batch of up to 25 findings from one sealed scan for
issue tracking. Draft GitHub Security Advisories accept one finding only. One
run uses one provider and one destination.

For Linear, send a prompt like:

```text
Use $codex-security:track-findings to prepare finding [finding ID] from
[completed scan directory] for the Linear team [team] and project [project, if
any]. Check for duplicates and show me the exact issue title, body, metadata,
and destination. Do not create or update anything until I approve that payload.
```

For GitHub issues, send:

```text
Use $codex-security:track-findings to prepare finding [finding ID] from
[completed scan directory] for GitHub repository [owner/repository]. Check open
and closed issues for duplicates and show me the exact issue title, body,
metadata, repository visibility, and authenticated transport. Do not create or
update anything until I approve that payload.
```

For Jira, send:

```text
Use $codex-security:track-findings to prepare finding [finding ID] from
[completed scan directory] for Jira project [project key] as [issue type].
Check for duplicates and show me the exact issue summary, description,
metadata, and destination. Do not create or update anything until I approve
that payload.
```

Jira tracking requires the Atlassian Rovo plugin in Codex. Reusing an issue
requires read access; creating or updating one requires read and write access.

For a private draft GitHub Security Advisory, send:

```text
Use $codex-security:track-findings to prepare finding [finding ID] from
[completed scan directory] as a private draft GitHub Security Advisory in
[owner/repository]. Verify the sealed source revision, repository, affected
paths, package metadata, and duplicate state. Show me the exact advisory
payload, authenticated GitHub CLI identity, and disclosure warnings. Do not
create anything until I approve that payload.
```

Draft advisories require one finding from a sealed `git_revision` scan, the
  verified public canonical source repository, and administrator access. The
  workflow doesn't batch, update, publish, or close advisories. Use an approved
  private issue destination when the source doesn't meet those requirements.

## Review the proposed write

<WorkflowSteps>

1. Confirm the finding ID and fingerprint came from the intended sealed scan.
2. Confirm the provider, exact Linear team, GitHub repository, Jira project, or
   advisory repository, and the live destination visibility.
3. Review the duplicate outcome: `create`, `reuse`, `update`, or `blocked`.
4. Read the complete proposed title, body, source locations, and provider
   metadata. Remove exploit detail or internal evidence that the destination
   shouldn't expose.
5. Approve only that exact payload. A changed destination, visibility, finding
   set, or body requires a new preview.

</WorkflowSteps>

Sensitive findings should go to a private destination. Creating an issue in an
internal or public GitHub repository requires an explicit visibility warning
and approval of the complete content. Treat a draft advisory description as
eventually public and remove credentials, private evidence, and unnecessary
exploit details before approval.

<VideoPlayer
  src="/videos/codex/security/issue-preview-before-approval.mp4"
  poster="/videos/codex/security/issue-preview-before-approval-poster.webp"
/>

## Verify the tracked item

After approval, Codex revalidates the sealed source, destination, access, and
duplicate state. It processes a batch serially and stops on the first uncertain
result. A create, update, or reuse is complete only after Codex reads the exact
issue back and verifies its binding identifiers and content.

Keep the returned canonical issue or advisory URL with your triage record.
Continue with [Fix and verify a finding](https://learn.chatgpt.com/docs/security/plugin/fix-findings)
when the owner accepts the item for remediation.