## Executive Summary In https://gitlab.com/groups/gitlab-org/-/epics/18648+s ~"group::vulnerability research" has started curating malicious packages. This will enable ~"group::composition analysis" to begin showing malicious packages as a part of Composition Analysis scan results. Malicious packages are a popular method of executing a software supply chain attack. Users are often tricked into downloading them, as they originate from places that normally trustworthy (i.e., npm or rubygems). There are many attack vectors employed by malicious packages. Some notable methods include: stealing credentials, exfiltrating data, turning applications into botnets, or corrupting databases. It is important that we support malicious package identification due to the growing threat and immediate harm caused by ingesting a malicious package. Malicious packages can often be considered more dangerous than vulnerabilities (CVEs) - namely because a CVE can exist for months or years in an application without being exploited, whereas a malicious package largely causes an immediate risk. #### Engineering Assessment There are several parts involved in this epic including: * `PMDB`: ingesting malware advisories and exporting them in GCP public buckets * `GLAD`: the source of the malware advisories * `GitLab`: The rails app that will need to sync the data and then show them as vulnerabilities. We need to extend all of these components to handle malware advisories. ### Policies For Beta we can us the existing MR policy compliance feature to block malware packages since these will be marked as `CRITICAL`. For GA we want to allow users to define a policy specifically around Malicious packages. ### Proposal * Malicious dependencies are stored in GitLab Advisory Database * Malicious dependencies can be identified through a Dependency scan * Vulnerabilities are created for Malicious packages with a default Severity of `CRITICAL` * Users must opt-in to malicious packages being returned as part of their dependency scanning results. This should happen through the GitLab configuration file * Users will see malicious vulnerabilities as part of the vulnerability report * Users will see malicious packages identified on the dependency list * Users are able to filter the dependency list for malicious dependencies ### User experience goals Composition Analysis users, specifically the AppSec and Developer personas, should be able to easily identify malicious packages as a part of their Dependency scanning activities. Provided a dependency scan has been configured, a user will see malicious packages as a part of their scan results. The AppSec or Compliance personas should be able to define policies around malicious packages. #### Vulnerability report / vulnerability details * Post-scan a user will see a vulnerability created on the Vulnerability report with any malicious dependencies denoted with an identifier of “MAL-xxxx-xxxxx”, which designates malicious behavior. This will allow for filtering and require minimal changes to the existing user interface. * The vulnerability details page will surface similar information as compared to CVE vulnerability types. We will include data from GLAD that has been curated by the Vulnerability research team. #### Dependency list Dependency list changes will be required to flag the malicious packages so they are easily identifiable to the end user. There are three primary user experiences on the dependency list: 1. Update the “vulnerabilities detected” column to be able to include malware as a vulnerability. 2. Provide a badge to the user so they can quickly identify malicious packages 3. Allow for filtering to drill down the dependency list to only the dependencies that are malicious. ### Target Metric/s * Improved accuracy of threats detected by CA, which can result in an increased adoption of SCA or adoption of the new targeted add-on. * Known ARR impact \~$5.0mil * Add-on ARR impact TBD ### Metrics 1. Malicious packages marked as Resolved 1. Shows that a user has received the information we provided to them and actioned it, preventing a security incident. 2. Malicious packages marked as Dismissed 1. Tells us the user does not believe this package to be malicious. ### Dependencies * Team dependencies: * ~"group::security insights" | @nmccorrison * ~"group::composition analysis" * ~"group::vulnerability research" * Epic/issue dependencies: * ~"group::security insights" | https://gitlab.com/gitlab-org/gitlab/-/issues/551225 * ~"group::vulnerability research" https://gitlab.com/groups/gitlab-org/-/epics/18648 * External dependencies: continued access to GitHub Advisory Database ```glql display: table query: project = "gitlab-org/gitlab" AND id IN (551225, 545625) fields: title, state, milestone, assignee, health title: Epic Dependency Tracking ``` ### DRIs * Engineer: TBD * EM: @nilieskou * PM: @johncrowley | @mclausen35 * Engineering Owner: @twoodham #### 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 ### 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