<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=607109) </details> <!--IssueSummary end--> ## Summary While investigating https://gitlab.com/gitlab-org/gitlab/-/work_items/604648 (an MR approval policy bypass), we found that when Dependency Scanning's Maven dependency resolution fails — partially or totally — the `dependency-scanning` job still exits successfully and uploads a report marked `"status": "success"`, with no report-level or job-level signal that anything degraded. This makes a silently-incomplete scan indistinguishable from a legitimately clean one to any downstream consumer, including MR approval policies (`fail: closed` scan-result rules cannot detect the gap and end up mergeable when they shouldn't be). This is filed against Dependency Scanning specifically because we've confirmed the gap is architectural, not something fixable from GitLab's ingestion/policy-enforcement side — see "Why this can't be fixed downstream" below. ## What we found (confirmed via analyzer source + multiple real GDK repros) **The analyzer never reports failure.** In `dependency-scanning@f55c7bd9`, `reporter/report.go:31-38` is the only site that sets `Scan.Status`, and it's hardcoded: ```go rpt.Scan = report.Scan{ Analyzer: ..., Type: report.CategoryDependencyScanning, StartTime: &scanStartTime, EndTime: &scanEndTime, Status: report.StatusSuccess, // unconditional, no other assignment exists } ``` The shared `report/v7` package does define `StatusFailure`, and the *shared* `analyzers/command` module (used by SAST-family analyzers) does reference it — but DS v2 has its own reporter and never uses it. **Most real resolution failures don't even fail the job.** A single unresolvable Maven dependency doesn't fail `dependency-scanning:maven-resolution` at all: Maven logs `[WARNING] The POM for ... is missing, no dependency information available` and still exits `BUILD SUCCESS` (confirmed with and without `-o` offline mode), silently producing an incomplete `maven.graph.json`. Only *structural* resolution errors (e.g. a non-resolvable parent POM) fail the resolution job red. **Even when resolution does fail, the analyzer job downstream still succeeds "empty."** Real GDK repro: `dependency-scanning:maven-resolution` fails (bad parent POM, genuine `mvn` error), while the separate `dependency-scanning` job (which owns `artifacts:reports:dependency_scanning`) still exits 0. In one run it uploaded no report file at all (`WARNING: gl-dependency-scanning-report.json: no matching files`); in another it uploaded a report with `"status": "success"` and 0 findings for the affected module. Either way, from GitLab's side this looks identical to "this project has no dependency issues" or "this project has no manifest files at all" — a very common, entirely legitimate state. **A real, already-parsed report field exists for degradation (`scan.observability.events`, e.g. `collect_ds_analyzer_scan_manifest_fallback_metrics_from_pipeline`), but it's not usable as a failure signal** — manifest fallback is a normal, intentional degraded-but-valid scanning mode for any project without a lockfile (there's a template input `enable_manifest_fallback`, default `true`, precisely because this is expected/common). Treating it as a failure signal would produce false positives at large scale. ## Why this can't be fixed downstream (GitLab Rails / policy enforcement) We looked hard for a way to detect this from GitLab's side (job status, `Security::Scan` row presence, target-branch baseline diffing, the report's own `scan.status`) and every option is either already disproven (per above) or structurally ambiguous: **a silently-degraded scan and a legitimately-clean scan produce the exact same observable shape** — succeeded job, succeeded `Security::Scan` row, few-or-zero findings — whether or not a healthy baseline exists on the target branch. Only the analyzer, at scan time, actually knows whether resolution succeeded, partially succeeded, or found nothing to do. No signal available today lets GitLab distinguish "nothing to scan" from "tried and failed." ## The ask Give downstream consumers (GitLab core, but also anyone else parsing DS reports) a way to distinguish these cases explicitly, for example: - Set `scan.status: "failure"` (the field/value your own `report/v7` package already defines but DS v2 never uses) when resolution genuinely fails on a manifest that was found — while still reporting `"success"` for the legitimate "no manifests found" case. - And/or fail the resolution job itself (non-`allow_failure`) on structural resolution errors rather than only logging a warning, for cases where that's a cleaner signal than the report content. Happy to pair on repro steps or test a fix against the MR approval policy consumer once something's available — the repro assets and exact analyzer source citations above came from a real, unmodified GDK setup this session, not synthetic overrides. ## References - https://gitlab.com/gitlab-org/gitlab/-/work_items/604648 — the original bug this was discovered while investigating - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/243540 — fixes 604648's core "missing baseline" case; documents this gap as an explicit known limitation - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/244051 — an earlier attempt assuming `scan.status` was already usable; closing it, since its premise is disproven by the finding above cc @nilieskou @imam_h — looping you in since you've both been involved in the DS v2 configurability discussion on #604648.