Carlos Matos
4822a9cbc4
* feat(imports): import CrowdStrike FCS IaC findings locally Add a crowdstrike file reader for saved FCS CLI 4.x IaC JSON reports (rule_detections). Each detection becomes one iac or secret finding with typed rule, configuration and remediation details. Like Tenable, the reader is local only and binds findings to --source-repository-url, which must match a fetch remote of the selected checkout. FCS writes detection paths relative to its working directory, so the guide asks users to scan from the checkout root. Paths that are absolute or leave the checkout are excluded. The source finding ID includes the line, because detections of one rule on one resource can differ only by line. * fix(imports): import CrowdStrike reports without a Git checkout An FCS IaC report describes files relative to the directory where the CLI ran and names no repository, so requiring a matching Git remote did not bind the report to anything. Import into any directory instead, and check that every detection's file exists there. A supplied --source-repository-url still records the repository, adds typed details and must match a fetch remote when the directory is a Git checkout. Detections in registry or Git modules name the calling file with a line from inside the module. Use the call line that FCS states in module_remediation, or no line, and include the module path in the finding ID. * docs(plugin): describe CrowdStrike FCS imports in the publish-findings skill Tell Codex when to use --provider crowdstrike, how to run an installed FCS CLI from the import directory, which report to import after a nonzero exit, and to ask for a report instead of installing FCS or passing Falcon credentials. * fix(imports): read the CrowdStrike module call line in linear time Search module_remediation for the detection file's exact call phrase instead of a lazy regex. A crafted report could make the regex quadratic: a 2 MB module_remediation took about two minutes to read. * fix(imports): stop CrowdStrike imports when a scanned file changed FCS records each scanned file's SHA-256 as file_sha256. Compare it with the file in the selected directory and stop, naming the file, when they differ. Before, a report of another commit imported without an error and could store lines that no longer point at the detected configuration. The check follows file symlinks, as FCS does, and reads only regular files. * docs(imports): add CrowdStrike scan examples and Codex validation steps Fix the FCS scan command: FCS needs an existing output directory whose name has no dot. Show a remote git:: scan pinned with ?ref= and a checkout of the same commit, and note that a //subdir URL gives paths from that subdirectory. Add a shortened sample report, and show how to pass imported findings to codex-security validate, for all findings or for one scan. * docs(imports): link CrowdStrike imports to the shared imported finding workflow Other provider pages do not describe validation or patching. Remove the CrowdStrike validation section and link the readback step to the shared section on working with imported findings. * fix(imports): keep CrowdStrike module lines in git:: reports In a git:: report, FCS writes the detection file, its module_source and the calling file in module_remediation with a leading slash. The reader removed the slash from the file before it compared the three, so every module detection lost its line. Compare them as FCS wrote them. In a git:: scan of a public Terraform repository, 102 of 396 findings had no line before this change and none after. * fix(imports): record and check the repository of CrowdStrike git:: reports A git:: report names the repository that FCS cloned, but the reader ignored it. A report of one repository could be saved under another one whose files were identical. For a git::https:// scan, record that repository without its //subdirectory and ?ref=, and keep the scan path in the report and in each finding's source data. When --source-repository-url is given, it must name the same repository, on import and on replay. Without it, the scanned repository gives typed details but does not bind the checkout to a fetch remote, so clones from self-hosted servers over SSH keep importing. Other git:: URL forms import as before. * fix(imports): import CrowdStrike git:: reports of URLs with a user name When the scanned URL has a user name, FCS writes each detection file, module source and calling file after the scanned URL instead of after a slash, and the reader excluded every detection. Remove that prefix. FCS removes the user name and token from the report's path and keeps them only in flags.path, which the reader does not read. * fix(imports): check replayed CrowdStrike locations against the native detection A replayed preview with cleared or edited locations skipped the file check, and saved findings without the scanned location. Rebuild the location from the retained FCS detection, require each finding to show exactly that location, and check that file and its hash.
Codex Security
Codex Security helps you find, investigate, and fix vulnerabilities in your code.
Use its security workflows in Codex, or automate them with the
@openai/codex-security CLI and TypeScript SDK.
- In Codex: choose a security workflow.
- In a terminal: install the CLI and scan your repository.
- In automation: use the TypeScript SDK or GitHub Action.
Features
- Scan repositories, selected paths, or Git changes. Deep scans repeat Standard scans and return their deduplicated findings.
- Validate candidate findings, generate patches, and verify existing fixes.
- Draft
SECURITY.mdpolicies and save threat models for later review. - Browse saved scans and findings, identify duplicates, assess severity against your own rubric, and suggest owners from source and Git history.
- Preview third-party scanner findings, save them locally, or publish supported reports to Codex Security Cloud. Scanner import guides.
- Track findings in Linear, Jira, or GitHub, publish completed scans, or export SARIF, JSON, and CSV. Integration workflows.
- Automate scans across repositories or project components, including in CI and containers.
Use in Codex
Open your repository in a Codex session with the Codex Security plugin enabled, then ask:
Run a Codex Security scan on this repository, focusing on authentication and authorization. Return the saved report, source evidence, and coverage limits.
A completed scan saves a report and findings. Read the report for source evidence and exclusions, then request a patch or ask Codex to verify an existing fix. See the agent workflow guide for setup, task selection, and recovery.
Quick start
Requires Node.js 22.13.0+ within 22.x, or Node.js 24.x or 26.x, and Python 3.10+.
Python 3.10 also requires tomli.
Install the CLI globally and sign in:
npm install --global @openai/codex-security
cs login
Run your first scan from the repository directory:
cs scan .
When the scan completes, open the Markdown file at the REPORT path in the
terminal. Run cs scans show from the same repository to find its latest
completed scan again. See scan scope and follow-up work
for how to interpret exclusions in the report.
cs and codex-security run the same CLI. If the short name conflicts with
another command, use codex-security. To skip the global install, or if npm
reports an EEXIST conflict, use npx @openai/codex-security in place of
cs for both login and scanning.
For CI, set OPENAI_API_KEY or CODEX_API_KEY in the scan process's environment.
For a headless machine, see device or SSH login.
Scan options
Choose a scope and scan mode:
# Scan selected paths.
cs scan . --path src --path tests
# Scan committed changes from a base revision to HEAD.
cs scan . --diff origin/main
# Run a deep scan of the repository.
cs scan . --mode deep
Use cs scan . --max-time 15 for an advisory 15-minute Standard investigation
allowance. See investigation time
for timing semantics and Deep Scan limits.
Use cs --help to browse commands, or cs scan --help
for scan options, cost limits, and patching after a scan.
For an application spread across repositories, see review one system across repositories. Use bulk scans for independent repository reviews in one resumable campaign.
Scans use existing root and component SECURITY.md guidance. To write or
revise it, see Generate SECURITY.md.
Some cybersecurity requests and protected findings require Trusted Access for Cyber. For accounts with Daybreak access, see Daybreak opt-in for the Codex toggle and Cyber access programs to select a program explicitly.
TypeScript SDK
Install the package locally in your TypeScript project:
npm install @openai/codex-security
Then import it:
import { CodexSecurity } from "@openai/codex-security";
const security = new CodexSecurity();
try {
const result = await security.run("/path/to/repository");
console.log(result.reportPath);
} finally {
await security.close();
}
The SDK guide includes deep-scan configuration, validation, severity classification, owner suggestions, and result handling.
Linked Git worktrees share scan history and saved findings when they use the same
Codex Security state directory. Keep CODEX_SECURITY_STATE_DIR stable to retain
that shared history and sign-in scope. See the scan history guide.
Read existing Cloud findings
When Codex Security Cloud is available to your account, the Security plugin's
$cloud-findings skill can read findings, reports, recorded assignment and
verification, and scan status in Codex desktop or the Codex CLI. Cloud is an
optional connection; local scans work without it.
See Cloud connection setup and CLI reads for authentication requirements and a read-only example.
Generate SECURITY.md
Use policy to draft a new SECURITY.md or update an existing one. Use --path
to select a component:
cs policy .
cs policy . --path services/api --knowledge-base architecture.md
The command saves its draft outside the repository and leaves existing files
unchanged. Review the diff and notes, edit the draft, then copy only SECURITY.md
to the displayed Policy target. Keep the saved architecture and threat-model
documents outside the repository.
Scans already use root and component SECURITY.md files. Keep your current policy
if it needs no changes. When updating it, preserve its vulnerability-reporting
instructions. If the command says the policy is already up to date, no copy is
needed.
Files at .github/SECURITY.md or docs/SECURITY.md often contain reporting
instructions. Preserve them when drafting a policy; those locations do not
automatically provide repository-wide scan guidance. See the
policy guide for policy
locations, unanswered questions, saved artifacts, and SDK usage.
Save and export threat models
Scans and policy generation save threat models with their results. Export a saved model without starting another analysis:
cs export --scan SCAN_ID --artifact threat-model --output threatmodel.md
Omit --scan to use the current repository's latest completed scan. The
export guide also covers findings,
SARIF output for CI, and the offline TypeScript API. For ServiceNow Application
Vulnerability Response, see Export findings for ServiceNow.
GitHub Actions
To run a weekly repository scan on GitHub-hosted Ubuntu:
- Add an OpenAI API key as the repository secret
CODEX_SECURITY_API_KEY. - Copy the weekly workflow to
.github/workflows/codex-security.yml. ReplaceREPLACE_WITH_REVIEWED_COMMITwith the reviewed distribution commit SHA from an Action release. - To try the workflow before the next scheduled run, open Actions → Codex Security repository → Run workflow.
The example uses an estimated $5 limit per scan and reports findings without failing the job. Requests in progress can exceed the limit. For a severity threshold, pull request checks, or runner requirements, see the Action guide. For eligible accounts, see Daybreak access.
Containerized bulk scans
Scan a list of repositories with the included Docker Compose configuration, which keeps results and authentication between runs. See the container quick start. The workflow runner runs individual CLI stages in containers and can connect to a separately deployed findings service.
Findings storage and deduplication
The findings guide covers local
storage, deduplication, and compatibility with independently operated endpoints
through publish scan --to custom and explicit --findings-url. The local
serve command and browser dashboard have been removed; existing databases and
scan artifacts remain available.
Other providers
Scans support OpenAI, Amazon Bedrock, OpenRouter, Fireworks AI, and Cheaper Inference. Bedrock uses AWS credentials and does not require a separate OpenAI login. See Bedrock setup for AWS profiles, regions, and model access.
For OpenRouter, Fireworks AI, and Cheaper Inference, set the provider's API key and choose a supported model. See provider configuration for examples.
Documentation
- Online documentation
- Agent workflows and recovery
- CLI reference
- Imported finding identity and evidence
- Project configuration
- Examples
To report a vulnerability privately, follow the security policy.