Run Security Analyzers in the IDE (VSCode)
## :star: Interested in Secure integration into VS Code? :star:
Please consult https://gitlab.com/groups/gitlab-org/-/epics/9679+, which includes status of our existing security-findings integration in VS Code as well as future plans.
---
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->
*This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->
As the push to move security tooling left continues, we are seeing an uptick in customer requests to have integration into developer IDEs to allow for security issues to be found and fixed prior to a commit. This EPIC describes what a minimum feature might look like for security analyzers and the VSCode IDE.
VSCode was selected as the IDE as it compliments GitLabs push to integrate VSCode, and VSCode is one of the most popular IDEs for developers and supports a wide range of software languages. Additionally, GitLab already has a VSCode plugin that we can extend.
## Priorities for implementation
| Priority | IDE | Reasoning |
|----------------|-----------------------------|-----------|
| ~"priority::1" | Visual Studio Code (VSCode) | Most requested. Popular for multiple languages, already has GitLab plugin |
| ~"priority::2" | JetBrains IDE ecosystem | Popular for multiple enterprise languages like Java and Go |
| TBD | Eclipse | Popular open source IDE for Java, C++ |
| Priority | Analyzer | Reasoning |
|----------------|-----------------------------|-----------|
| ~"priority::1" | Container Scanning | Most requested |
| ~"priority::1" | Dependency Scanning | Most requested |
| ~"priority::1" | SAST | Most requested |
| ~"priority::2" | Dynamic Analysis | |
| ~"priority::2" | API Security | |
## What does minimal look like?
A minimal feature would use the existing analyzer containers with no changes, combined with new capabilities in the GitLab VSCode plugin. The goal is to perform an initial feature release with minimal effort. With this plan 90% of the development effort is on the VSCode plugin with a small effort in the monolith itself to support improved display of the vulnerabilities.
Docker is very popular with developers and there is a good chance they will already have this installed and working. This makes it a reasonable requirement for minimal.
### Analyzers run in a docker container
In order to use the analyzers "off the shelf" so to speak, we will need to simulate the CI environment they are used to using, and have some meta data about what the analyzer needs in order to run.
#### Meta Data for Analyzers
Information about each analyzer will be needed.
1. Name
1. Description
1. Category
1. Typical runtimes
1. Can run in parallel with other analyzers (low resource usage)?
1. Docker registry to pull latest version
1. Need to consider offline environments for this
1. Location of report and report assets (best if this can be specified via variable)
1. Assets required:
1. Source code
1. Compiled code
1. Running code + URL
1. Container
#### Simulate CI environment
The analyzers expect to run in a GitLab runner with numerous predefined CI variables, and,
depending on the analyzer, a checked out repository.
In order to run the analyzers locally, the predefined CI variables will need to be set
such that the analyzers will run correctly.
The local checkout of the repository will be mounted as a volume, depending on the analyzer
requirements.
1. Set needed variables
1. TODO: to create table of general ci variables to support
1. Mount local repository as volume to simulate code checkout
#### Access to Report and Report Assets
1. Mount a local folder to contain report + assets after scan
### Monolith changes (Optional)
1. New API to assist with identifying which vulnerabilities are new for this branch and have not been dismissed.
1. Returning the current list of identifiers with dismissed field could be an easy way to handle this. It could be called while the analyzer is running and cached by the plugin.
1. @mikeeddington: We could make use of the existing GraphQL API around vulnerabilities instead of creating a new API. This would lower the effort needed.
1. New API to return a projects features (if we cannot get this from an existing API) to populate the CI variable
### GitLab VSCode Plugin changes
#### Configuration via json
It's common for plugins to have much of their configuration performed by editing json. This also lowers the amount of work needed for a minimal release.
1. For analyzers that test a target instance-
1. The hostname must resolve to non routable IP address.
1. 10.0. 0.0/8 ( Range: 10.0. 0.0 – 10.255. 255.255 ) – Available IPs: 16,777,214.
1. 172.16. 0.0/12 ( Range: 172.16. 0.0 – 172.31. 255.255 ) – Available IPs: 1,048,574.
1. 192.168. 0.0/16 ( Range: 192.168. 0.0 – 192.168. 255.255 ) – Available IPs: 65,534.
1. The hostname must not resolve to 127.0.0.1 (not accessible from docker)
1. Project must be build and started (target running)
#### New commands
1. Run all security scanners
1. Run security scan
1. Stop security scan
1. View results
#### UX
1. GitLab Security Panel
1. Buttons for
1. Start all
2. Start (just dropdown selected)
3. Stop
4. Update analyzers
1. docker pull for each of the analyzers
2. Dropdown for analyzer
3. Display scan running
1. Call monolith API to get current vulnerability list
4. Display scan results
1. Only show new issues by default
3. Group by severity
1. Group by finding type (SQLi)
1. Display vulnerabilities
1. Specific to DAST API/API Fuzzing:
1. Button to open Postman Collection in Postman
2. Button to open raw messages
5. Access to analyzer console output
1. Perhaps we can show the docker run output in a window.
2. Mask or not show all the variables we are setting (gives away licensing method)
```mermaid
sequenceDiagram
VSCode->>VSCode: Configure via Json
VSCode->>+VSCode: Start Scan
VSCode->>VSCode: Build Project
VSCode->>+Analyzer: Run Docker
Analyzer->>Analyzer: Do all the things
Analyzer->>Analyzer: Generate Report w/Assets
Analyzer->>-VSCode: Docker Exits
VSCode->>VSCode: Display Vulnerabilities
VSCode->>-VSCode: Scan Complete
```
## What does viable look like?
1. Analyzers packaged to run locally w/o docker
1. Support another IDE (JetBrains ecosystem?)
1. Configuration UX
1. Support cloud compute for heavy analyzers (~"group::dynamic analysis")
1. Can we use a similar mechanism to on-demand?
1. Target Container
1. User must configure a base container image
1. Local build artifacts are injected into target container (mounted volume?)
1. Avoids rebuilding the container every scan
1. Analyzer container runs and tests target
1. Possible issues with approach:
1. Time to launch containers could be a problem
1. Would be nice if we could have hot containers ready to go
epic