License scanning support for Dart/Flutter projects using pub package manager
## Executive Summary
Dependency scanning is able to scan for Dart/Flutter dependencies and surface vulnerabilities. Currently we do not fully support license scanning for Dart/Flutter projects. Our users will view Dart/Flutter licenses as `UNKNOWN`.
### Problem to solve
Users are unable to get accurate license information for Dart/Flutter dependencies. With our current capabilities they must use external data sources to gather license information, reducing their usage of the platform and also creating workarounds that delay security and compliance activities. This also has an impact on policies, where the dependency they are using may have an impermissible license.
#### Engineering Assessment
In gitlab#342468 (closed) Dependency Scanning support was added for Dart. To carry this forward and round out our support for Dart (pub package manager) we should support license scanning.
For Dart and Flutter based projects, pub package manager is used to handle dependencies. The pubspec file could be used for detecting dependencies.
In this epic we need to extend PMDB with exporting license data for `pub` PURL type. This will involve a couple of activities including:
**PMDB**
* Investigate how to fetch license data for `pub` packages. We can use [pub.dev](https://pub.dev/help/api#package-names-for-archiving-and-mirrors).
* Update license-feeder to ingest data with licenses
* License-interfacer can just propagate data to the license processor
* License processor should store the data in the DB
* Update schema to store pub data
* Update deployment and exporter to export the data
* Update documents
**Rails side**
* Make sure semver_dialect gem supports `pub` . If not update and update the gem version on Gitlab
* Update DB with `pub` PURL type if that is missing
* Test that license data appear on the Gitlab instance
### References
https://dart.dev/tools/pub/pubspec
https://dart.dev/tools/pub/package-layout
https://pub.dev/help/api#package-names-for-archiving-and-mirrors
### Dependencies
* Team dependencies: none
* Epic/issue dependencies: none
* External dependencies: sourcing license data from pub.dev
### DRIs
* Engineer: TBD
* EM: @nilieskou
* PM: @joelpatterson
* Engineering Owner: @rvider
#### Initiative Driver - Product or Engineering?
* [x] **Product-driven initiatives (P1/P2/P3)** - Customer-facing features or improvements driven by Product teams that require engineering resources and commitment
* [ ] **Engineering-driven initiatives (E1/E2/E3)** - Internal technical improvements that may not have customer-facing components
#### Sizing and Funding (Optional)
* **Size**:
* **Funding Status**: TBD, based on interlock feedback
### Target Metric/s
* Improved detection of licenses for Dart/Flutter, which can lead to an increase in adoption of SCA.
* Known impacted ARR \~$1.5mil
### Hygiene Guidelines
:bulb: \_See additional details about this process at https://handbook.gitlab.com/handbook/product-development/r-and-d-interlock/
##### :one: Pre-Interlock
* [x] Update epic description with all relevant information
* [x] Ensure all dependencies are identified
* [x] Apply appropriate labels (see below)
* [ ] Apply target delivery Milestone
* [ ] Update interlock status as discussions progress (via label)
##### :two: Post-Interlock: once quarter begins
* Update health status weekly (via label)
* Document any newly identified risks or dependencies
* Link to implementation epics/issues as work begins
* Flag any scope or timeline changes immediately
epic