Bringing AI Code Security into Qualys ETM

A first-class data model for the next generation of findings

AI-driven code security is becoming a real category. Anthropic’s Claude Code Security and OpenAI’s Codex Security are the leading examples, and more will follow. These tools reason about source code at a depth that traditional SAST cannot reach, surfacing logic flaws, broken authentication patterns, hardcoded secrets, and complex injection paths that pattern-based scanners routinely miss.

Discovery at this depth is genuinely useful. It is also not, by itself, a security outcome. A finding sitting in a code-scanning tool is one more silo. The work that reduces risk happens after discovery, when the finding is attributed to a real asset with a real owner, deduplicated against what the platform already knows, and driven to closure.

That work is what Qualys Enterprise TruRisk Management (ETM) is built to do, for every asset class, from every source. The platform was designed to be multi-vendor and multi-source from the start. CrowdStrike, Wiz, Microsoft, ServiceNow, AWS, and dozens of others already feed it. Anthropic and OpenAI are the next category of vendors that the data model is ready to absorb. The reason it absorbs them cleanly is structural: ETM is built around typed asset classes and typed finding types, with unified TruRisk scoring across all of them.

Run the scan in Claude Code Security

Claude Code Security operates on a code repository. Point it at a repo, pick a branch, pick a model, and an effort level. The scan produces a structured set of findings with severity, location, weakness type, description, and, where applicable, a CWE mapping. The export is a CSV.

Discovery is the easy part. The harder questions start now. Which findings actually matter? Which asset do they belong to? Who owns that asset?

Application SAST is a first-class data type

In the Qualys platform, SAST findings are not flattened into a generic vulnerability bucket. The data model treats Application SAST as its own type, distinct from Host Asset, Application, and Application SCA.

This matters more than it seems. A code-level finding is not the same kind of object as a host vulnerability. The asset is a repository, not a server. The finding is a weakness pattern in a file at a line number, not a CVE on a package version. Modeling SAST as its own type preserves that semantic shape end-to-end. As more AI code security tools enter the market, they arrive in this same Application SAST type and inherit TruRisk scoring, Finding Rules, Risk Workbench, and the MITRE ATT&CK matrix from the moment ingestion completes.

The repository becomes a typed asset in ETM

Once the connector runs, the repository shows up in the Qualys ETM inventory as a typed asset, not a tag.

That single line in the inventory inherits everything ETM does for every other asset class: criticality and TruRisk scoring on the same model used for hosts, cloud workloads, and identities; lifecycle tracking; business entity mapping so risk rolls up to the right place; and multi-source attribution so a repo observed by three different tools remains one asset with three sources.

A tag describes a finding. A typed asset has identity, lifecycle, ownership, and score.

The asset model is what closes the loop. A code repository observed by Claude Code Security today, by Codex Security tomorrow, and by an internal SAST tool is one asset with three sources, not three separate findings. The repository has an owner, a business entity, a TruRisk score, and a place in the dashboard that the CISO already looks at every morning.

Findings land in Risk Management with full attribution

Findings flow into the same Risk Management surface that already houses host vulnerabilities, cloud misconfigurations, identity exposures, and container findings.

Vendor Name, Source, Type, and Status are all queryable. The same surface answers the same questions for any other source: Wiz, CrowdStrike, ServiceNow, and Codex Security as it lands. Every source, every vendor, every product attribution sits in the same model and reports through the same lens.

Each finding lives inside the same risk operations engine the analyst already uses. Risk Workbench, MITRE ATT&CK matrix, Finding Rules, and Risk Customization read these findings as native objects. From the moment ingestion completes, a Claude Code Security finding behaves the same as any other finding in the platform: scored, prioritized, queryable, and ready for action.

Why the data model is the differentiator

More AI code security tools are coming. Claude Code Security and Codex Security are the leading examples today, and more vendors will follow. The question is not whether to ingest these tools. It is what happens to their findings once ingested.

Three architectural decisions in Qualys ETM determine the answer:

Typed data model. Application SAST is its own first-class type, alongside Host, Application, Application SCA, Cloud, Container, and Identity. The semantic shape of a code-level finding is preserved end-to-end, never flattened to fit a host-shaped schema.

Typed asset model. A code repository is a real asset with its own class and lifecycle, not a tag on a finding. It carries criticality, ownership, business entity mapping, and TruRisk score the same way every other asset does.

Multi-vendor by design. The connector framework, the vendor and source attribution model, and the unified TruRisk scoring are the operating model that has been running across more than 100 production sources for years. Anthropic, OpenAI, and the next wave of AI code security vendors plug into the same framework.

An AI code security finding looks like a finding, typed correctly, attributed correctly, scored on the same model as everything else, sitting on a real asset with a real owner. The analyst does not learn a new workflow. The CISO does not look at a new dashboard. The risk operations loop runs the same way it does for every other source.

Discovery is good. Operating on what was discovered is what reduces risk. Qualys ETM does that on a typed data model, a typed asset model, and a multi-vendor framework that was always built for this.

A note on what comes next

The connector framework supports automated ingestion through API and webhook alongside file-based imports. The same deduplication, scoring, and workflow apply regardless of how the finding arrived, and the platform stays current as scans complete.

That currency matters because the platform is a reasoning surface. ROCky is the Qualys Cyber Risk Assistant built for the ROC analyst and the CISO. It runs on the same surface this piece describes, answering questions in plain language: which exposures matter most this week, what changed since yesterday, and which assets are unique to a given source. The same platform that brings Claude Code Security and Codex Security findings into a unified surface is the one ROCky reasons over, and acts on.

Schedule a demo of Qualys ETM today to see what it can do.