### Summary The `list_security_findings` GitLab Duo Agent Platform (DAP) tool has two defects that together make it unable to return usable dependency-scanning results, plus a confirmed data point establishing that both are query/projection bugs rather than data-availability problems: 1. **`report_type` filter returns nothing.** Calling the tool with `report_type: ["DEPENDENCY_SCANNING"]` returns `total: 0` and `by_report_type: {}`, even though an unfiltered call on the same pipeline returns 35 findings aggregated under the exact key `DEPENDENCY_SCANNING`. 2. **Package name and version are dropped.** For dependency-scanning findings the tool returns `location.file` but never `location.dependency.package.name` or `location.dependency.version`, because the tool's GraphQL query selects only `file` under the `VulnerabilityLocationDependencyScanning` fragment. 3. **The data exists.** The ephemeral `security_findings` store persists the full location object (including `dependency.package`), and the pipeline Security tab renders it — so both issues above are query/projection bugs, not missing data. **Impact:** a pipeline-triggered custom flow cannot use the native `report_type` filter to isolate dependency findings, and cannot report which package/version each finding affects — the two pieces of information most needed to act on a dependency vulnerability pre-merge. ### Steps to reproduce 1. On a project running v2 SBOM Dependency Scanning (`Jobs/Dependency-Scanning.latest`), run a merge-request pipeline that produces dependency-scanning findings. 2. From a DAP custom flow (`ai_catalog_agent`) triggered on the passed MR pipeline, call `list_security_findings` **without** a `report_type` filter (Call A below). 3. Call `list_security_findings` again with an identical payload plus `report_type: ["DEPENDENCY_SCANNING"]` (Call B below). 4. Compare `summary.total` / `summary.by_report_type` between the two responses. 5. Inspect any dependency-scanning finding's `location` object for package name/version. ### Example Project Reproduced on a GitLab.com project (instance version 19.3.0) during a Duo Agent Platform evaluation. Concrete project path, pipeline ID, and MR number are omitted here for confidentiality and can be shared privately with the assigned engineer. ### What is the current _bug_ behavior? **Finding 1 — `report_type` filter returns zero results.** Call A — no `report_type` filter: `{ "project_full_path": "<group>/<project>", "ref": "<mr-source-branch>", "per_page": 100, "fetch_all_pages": true }` json Response A (abridged) — matches the pipeline Security tab exactly: `{ "summary": { "total": 47, "by_report_type": { "DEPENDENCY_SCANNING": 35, "SAST": 12 }, "by_severity": { "CRITICAL": 1, "HIGH": 25, "MEDIUM": 16, "LOW": 4, "UNKNOWN": 1 }, "by_state": { "DETECTED": 47 } }, "pipeline": { "id": "gid://gitlab/Ci::Pipeline/<id>", "ref": "refs/merge-requests/<n>/head", "status": "SUCCESS" } }` json Each `findings[]` entry carries `report_type` values `["DEPENDENCY_SCANNING", "SAST"]` verbatim. Call B — identical, plus `report_type: ["DEPENDENCY_SCANNING"]`: `{ "project_full_path": "<group>/<project>", "ref": "<mr-source-branch>", "report_type": ["DEPENDENCY_SCANNING"], "per_page": 100, "fetch_all_pages": true }` json Response B (abridged): `{ "summary": { "total": 0, "by_report_type": {}, "by_severity": {}, "by_state": {} }, "metadata": { "filters_applied": { "report_type": ["DEPENDENCY_SCANNING"], "severity": null, "state": null, "scanner": null } } }` json `metadata.filters_applied` confirms the tool received `report_type: ["DEPENDENCY_SCANNING"]` — the value round-trips but matches nothing. The filter fails to match its own aggregation key. **Finding 2 — dependency package name and version are dropped.** Every dependency-scanning finding the tool returns exposes `title`, `severity`, `reportType`, `location.file` (e.g. `requirements.txt`), and `identifiers[].name` / `identifiers[].externalType` (CVE available when `externalType == "cve"`), but **not** package name or version. `location.dependency` is absent from every finding, so package/version render as `n/a`. ### What is the expected _correct_ behavior? 1. Call B should return the same 35 dependency-scanning findings that Call A aggregates under `DEPENDENCY_SCANNING`. 2. Dependency-scanning findings returned by the tool should include package name and version (via `location.dependency.package.name` and `location.dependency.version`). 3. The tool's output for a given pipeline should match the counts and package details shown in that pipeline's Security tab. ### Relevant logs and/or screenshots **Finding 2 root cause (code).** The tool loads a fixed GraphQL query, `list_pipeline_security_findings.graphql`, whose `location` selection requests only `file` under the dependency-scanning fragment: `location { ... on VulnerabilityLocationSast { file startLine endLine } ... on VulnerabilityLocationSecretDetection { file startLine } ... on VulnerabilityLocationDependencyScanning { file } ... on VulnerabilityLocationContainerScanning { image operatingSystem } }` graphql The `VulnerabilityLocationDependencyScanning` GraphQL type already exposes a `dependency { version package { name } }` sub-selection. The query never requests it, so the fields are dropped before the response reaches the agent. This is a projection gap in the query — not a resolver, schema, or permissions issue. **Finding 3 — the ephemeral store already holds the location/package data**, confirming both defects are query/projection bugs rather than data-availability limitations: * The `security_findings` store persists the entire location object as reported by the analyzer: the store service assigns `location: report_finding.location_data` (the full location block, not a subset). * The `finding_data` JSON schema defines `location` as a free-form object (`"location": { "type": "object" }`) with no field stripping, so `dependency.package.name` and `dependency.version` are stored as-is. * The `Security::Finding` model exposes `location` directly from `finding_data` — the same data the pipeline Security tab renders. Because the pipeline Security tab and the unfiltered tool call both reflect the store correctly, the missing data in the filtered/dependency cases is attributable entirely to the tool's query and filter handling. ### Possible fixes **Finding 1 (`report_type` filter).** The value the tool aggregates on (`DEPENDENCY_SCANNING`, surfaced in `summary.by_report_type` and on each finding's `report_type`) is not the value the filter compares against when narrowing the result set. Investigate the enum casing/format normalization applied to the `report_type` argument before it reaches the finding query/filter, versus the value used when building `by_report_type`. **Finding 2 (dropped package/version).** Add the dependency sub-selection to the fragment in `list_pipeline_security_findings.graphql`: `... on VulnerabilityLocationDependencyScanning { file dependency { version package { name } } }` graphql Self-contained change in a single `.graphql` file; the fields already exist on the type and are rendered in the pipeline Security tab. ### Acceptance criteria * Calling `list_security_findings` with `report_type: ["DEPENDENCY_SCANNING"]` returns the same findings that appear under `DEPENDENCY_SCANNING` in an unfiltered call. * Dependency-scanning findings returned by the tool include package name and version (`location.dependency.package.name`, `location.dependency.version`). * The tool's output for a given pipeline matches the counts and package details shown in that pipeline's Security tab. ### Environment * GitLab.com, instance version 19.3.0 * Dependency Scanning: v2 SBOM analyzer (`gitlab-sbom-vulnerability-scanner`), `Jobs/Dependency-Scanning.latest` template * Caller: DAP custom flow, `ai_catalog_agent`, pipeline-triggered (`event_type: pipeline_hooks`), running as a composite-identity service account * Tool: `list_security_findings` ### Context Surfaced during a Duo Agent Platform evaluation while building a pipeline-triggered custom flow that summarizes dependency findings on the merge request pre-merge. The flow works around both defects today (fetch unfiltered, filter findings client-side, and parse the package name from the finding title because version is unavailable), but these workarounds should not be necessary for a native findings tool. ---