SpyBara
Go Premium

security/plugin/export-findings.md 2026-07-24 15:00 UTC to 2026-07-27 18:59 UTC

27 added, 21 removed.

2026
Mon 27 18:59 Fri 24 15:00 Thu 23 21:57 Wed 22 20:02 Tue 21 22:02 Mon 20 23:01 Fri 17 22:57 Thu 16 20:57 Wed 15 19:58 Tue 14 17:03 Wed 8 02:01 Mon 6 22:58

Export and track security findings

Use a completed Codex Security scan for either of these handoffs:

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

Neither workflow changes the sealed scan bundle.

Available export formats and workspace controls depend on your Codex surface and installed plugin version. Check the plugin changelog before you use a format in automation.

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, then use the returned artifact path. If another tool needs the complete scan context, keep the original scan-manifest.json, findings.json, and coverage.json together. The plugin generates SARIF locally. Exporting doesn't upload findings to a code-scanning service.

Export findings dialog with JSON, CSV, and SARIF format options
Export completed findings as JSON, CSV, or SARIF for downstream review and tooling.

Track selected findings

Run $codex-security:track-findings with one validated finding or an explicitly selected batch of up to 25 findings from the same sealed scan. Each run uses one provider and one destination. A private draft GitHub Security Advisory accepts only one finding.

To prepare a Linear issue, send:

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.

To prepare a GitHub issue, send:

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.

To prepare a Jira issue, send:

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.

To prepare a private draft GitHub Security Advisory, send:

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

  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.

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 you approve the proposed write, Codex rechecks the sealed source, destination, access, and duplicate state. For a batch, it processes findings one at a time and stops at the first uncertain result. Creation, 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 when the owner accepts the item for remediation.