Security and SBOM
How AI CodeOps handles security findings, SBOMs per project (CycloneDX and SPDX), license checks in the release gate, sandboxed terminals and encrypted secrets.
AI CodeOps looks for security problems in every change it writes, keeps track of what each project ships through its software bill of materials (SBOM), and records who did what. This page covers the parts you work with as an administrator.
Security findings
Every session ends with an AI review of its diff. Findings in the security category, like any finding, carry a severity (critical, high, medium, low, info), the file and line, and a triage status. Open high and critical findings block the change until they are triaged; see Quality gates.
Workflows built for security work go further. Security-Sensitive Change runs a risk analysis before the change is written and audits the diff after. Threat Model produces a STRIDE analysis and records it as an architecture decision record. See Agents and workflows.
Secure → Security shows the workspace's security posture: a score, counts by severity, and a table of open security findings: severity, the file (under Package), description and the reviewer's recommended fix. The CVE column shows a dash, because there is no CVE scanner. Fix with AI starts a session to fix a finding. As with any session, you review and approve the change before a pull request is opened.
SBOMs per project
An SBOM lists the components a project ships, with their versions and licenses. AI CodeOps tracks SBOMs per project in CycloneDX or SPDX format.
Each SBOM record holds the format and version, the number of components and of vulnerable components, a license summary, the commit it describes, a SHA-256 hash, and a link to the SBOM file. AI CodeOps doesn't generate SBOMs: create yours with the tool you already use in your build.
Where you see them:
- Secure → Security, panel Software Bill of Materials: projects with SBOMs, distinct licenses, and a license roll-up across projects.
- A project's page: Recent SBOMs and Vulnerable components (latest SBOM).
In the open beta there is no upload form. A snapshot is recorded with a request to /api/sbom from a signed-in session; recording one from CI with an API key is not available yet. To look inside an SBOM file without signing in, try the SBOM viewer.
License checks
The release gate your CI calls can deny a change when the project's latest SBOM contains a license you've disallowed, such as GPL-3.0 or AGPL-3.0. A project with no SBOM can't be checked, so the gate denies it too when a license rule is set. The options are on the API page.
Sandboxed execution
Sessions run on the platform, not on your machine. When a session runs your tests, it runs them in an isolated environment for the project.
Develop → Terminal (beta) opens a shell at your project's root in its own isolated sandbox: a container on the platform, never the platform's own servers. Opening a terminal needs a role that can manage projects, and availability depends on your plan.
Secrets and keys
- Git tokens, model provider keys and workspace secrets are encrypted at rest with AES-256-GCM.
- API keys are stored only as a hash and shown once, when created.
- Workspace secrets are managed in Configure → Settings; the Secret Manager role can manage secrets without any other access.
Audit log
Measure → Audit Log records what changed in the workspace and who changed it: members and roles, keys, providers, policies, agents, schedules, budgets, secrets, approvals and generated code. Each entry has the time, account, target and IP address. Owners, admins and security admins can read it. How long entries are kept depends on your plan.
Next steps
Frequently asked questions
Does AI CodeOps generate SBOMs for me?
No. You generate the SBOM with your usual tool and record it against the project. AI CodeOps tracks it and uses it for license checks.
Where are security findings shown?
On the run page of the session that found them, and across the workspace under Secure → Security.