## Problem to solve The new Dependency Scanning analyzer requires users to provide lockfiles/graphfiles, which creates friction for projects that don't maintain these artifacts. Option 1 from the [build support spike](https://gitlab.com/gitlab-org/gitlab/-/issues/582607#note_2938325471) (internal only) proposes parsing dependency manifest files directly (e.g., `pom.xml`, `build.gradle`, `requirements.txt`) without performing a build step. ## Proposal Validate the feasibility and limitations of a multi-tiered product approach: - **Without configuration**: Limited coverage (direct dependencies only from manifest files) - **With configuration**: Full accuracy via user-provided lockfiles/graphfiles :warning: This solution is not meant to replace an auto-build functionality, but rather be complementary and an opportunity to offer a first experience with our Dependency Scanning feature with zero configuration. ### Scope #### 1. Parser Implementation Assessment 1. **Parsers:** Evaluate feasibility and effort to parse: - `pom.xml` - `requirements.txt` (non-lockfile format) - `build.gradle` - Other files to be confirmed: - build.gradle.kts - Pipfile - setup.py - build.sbt - settings.gradle - NB: there could be even more manifest files to support in the future, however we currently focus on existing coverage from the Gemnasium analyzer. 1. **Analyzer behavior:** Evaluate the impact of supporting both a manifest and a lockfile/graphfile for the same technology in existing logic: - parser selection - input file path tracking - configuration options - others? #### 2. **Completeness Analysis** 1. Measure what percentage of total dependencies are direct vs transitive (production data?) 1. Identify real world usages that could break this approach (e.g., using maven properties, parent POMs, external version catalogs, conditional constraints, etc.). If possible, document percentage of projects where manifest-only scanning would be viable. #### 3. **Accuracy Analysis** 1. Document version constraint patterns (e.g., `>=1.0`, `~=2.0`) and their impact on vulnerability matching 1. Quantify expected false positive rate from version range matching versus exact version matching #### 4. **User Feedback Mechanism** 1. Design how to communicate incomplete results to users beyond CI job log output 1. Propose UI for indicating "limited scan" status in MR widgets and security dashboards 1. Propose guard rails to prevent existing Gemnasium users from migrating to this solution inadvertently #### Known Limitations to Validate: 1. **Completeness**: Direct dependencies typically represent a small percentage of total dependency tree 1. **Accuracy**: Version constraints without resolution will likely produce significant false positives 1. **Migration risk**: Existing Gemnasium users may see vulnerabilities "auto-resolve" due to reduced detection #### Success Criteria 1. [x] Effort estimate for implementing manifest parsers - Scope: Limited to `pom.xml`, `requirements.txt`, and `build.gradle` based on usage data - Timeline: - `pom.xml` and `requirements.txt`: 18.9 - `build.gradle`: 18.10 2. [x] Quantified (or qualitative if not measurable) accuracy/completeness metrics for each supported ecosystem - Parsers should extract all direct dependencies. Transitive dependencies are not detected - When version is explicitly declared: accurate - When version uses a range with a lower bound: lower bound is used - When version cannot be resolved (for example - no lower bound, unpinned version, remote BOMs): package reported without version. Known limitations will be documented as part of https://gitlab.com/gitlab-org/gitlab/-/issues/588902+s 3. [x] Clear recommendation on whether this approach provides sufficient value as a "foot in the door" solution **Yes**, implement manifest-only parsing as a fallback mechanism. As it enables zero-configuration dependency scanning for new users and provides immediate value. (Gemnasium users should disable this as part of the migration so vulnerabilities wouldn't get auto resolved) 4. [x] UX direction to provide in-product user feedback about identified limitations - Approach: Embed information directly in existing UI (no banner notifications). - Implementation: - Add dependency file metadata to SBOM and Security Reports (see &20764+s) - (Future: Security Inventory to show which projects use manifest fallback) ----- This spike will help the team make an informed decision about the expected ETA to deliver manifest only parsers and their accuracy/completeness tradeoffs.