### Status summary As of 2023-08-14: * Our IDE integration for security features is in active development. * Our first workflow, covered by this epic, is that the developer: 1. Writes code. 1. Commits the code. 1. Pushes the code to a branch and opens an MR. 1. Can watch as the scans complete in the IDE, by viewing the pipelines and the associated job logs. 1. Sees a summary of scan results in the IDE. * We’re preparing to activate the feature in the next week, with additional improvements in future releases. See [standard disclaimer below](#disclaimer). For details, see below. ## Status update: Aug 11, 2023 - Feature work for Iteration 1 Complete :tada:, Many thanks to @djadmin, @minac for helping get this through - Need to clarify feature flag deployment strategy. Will discuss with @connorgilbert - @connorgilbert preference: Keep feature flag in place in the extension, but default it to "on". Remove the flag in a future extension release once the feature is stable. ### Release notes <!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " --> ### Problem to solve <!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." --> <!-- As a developer, I am unable to view any vulnerability results in the WebIDE and have to go out to GitLab to view the security findings for my code. --> As a software developer, I want to view new vulnerabilities introduced by my changes within my code authoring tool (IDE) so I can review and address them without having to switch between multiple tools. ### Intended users - [Sasha (Software Developer)](https://about.gitlab.com/handbook/product/personas/#sasha-software-developer) <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager) * [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) * [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager) * [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer) * [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test) * [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops) * [Ingrid (Infrastructure Operator)](https://about.gitlab.com/handbook/product/personas/#ingrid-infrastructure-operator) * [Dakota (Application Development Director)](https://about.gitlab.com/handbook/product/personas/#dakota-application-development-director) * [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst) * [Eddie (Content Editor)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#eddie-content-editor) --> ### User experience goal <!-- What is the single user experience workflow this problem addresses? For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>" https://about.gitlab.com/handbook/product/ux/ux-research-training/user-story-mapping/ --> ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> Users will be able to view vulnerability results for the latest completed pipeline within Visual Studio Code. - Design issue: https://gitlab.com/gitlab-org/gitlab/-/issues/384054+ (contains additional wireframes) - Wireframes: [Figma design file](https://www.figma.com/file/JbnyBQDXSegBRCst2Lecg0/%23384054---Show-Vuln-Results-in-VS-Code?node-id=1%3A8280&t=7Emh3lSo5uFrBbtK-1) | Empty state | Sec scanning in progress | Sec scanning complete | Policy details | | ------ | ------ | ------ | ------ | |  |  |  |  | **Recommendations:** <br> 1. Add a tree item for `Security scanning` under the `For current branch` section of the GitLab VS Code extension 1. The Security scanning tree item should use the GitLab [shield icon](https://gitlab.com/gitlab-org/gitlab-svgs/blob/main/sprite_icons/shield.svg) 1. When no security scans have run for the current branch, the security scanning tree item should not be expandable ([design](https://gitlab.com/gitlab-org/gitlab/-/issues/384054/designs/GitLab_Workflow_VS_Code_-_Branch_vulnerability_report_-_no_security_results.png)) 1. When security scanning is in progress, an “In progress” text indicator should be added to the right of the security scanning tree item and the item should be expandable ([design](https://gitlab.com/gitlab-org/gitlab/-/issues/384054/designs/GitLab_Workflow_VS_Code_-_Branch_vulnerability_report_-_scan_in_progress_-_no_results.png)) 1. When scanning is in progress, the tree items nested immediately under the security scanning node should also have a text indicating to users that the results are pending (this should update to a count of items under each node after scanning is complete). ([design 1,](https://gitlab.com/gitlab-org/gitlab/-/issues/384054/designs/GitLab_Workflow_VS_Code_-_Branch_vulnerability_report_-_scan_in_progress_-_no_results.png) [design 2](https://gitlab.com/gitlab-org/gitlab/-/issues/384054/designs/GitLab_Workflow_VS_Code_-_Branch_vulnerability_report_-_scan_in_progress_-_partial_results.png), [design 3](https://gitlab.com/gitlab-org/gitlab/-/issues/384054/designs/GitLab_Workflow_VS_Code_-_Branch_vulnerability_report_-_scan_complete.png)) 1. When security scans have been detected for the current branch (in progress or complete), the following tree items should be nested under the “Security scanning” tree item ([design 1,](https://gitlab.com/gitlab-org/gitlab/-/issues/384054/designs/GitLab_Workflow_VS_Code_-_Branch_vulnerability_report_-_scan_in_progress_-_no_results.png) [design 2](https://gitlab.com/gitlab-org/gitlab/-/issues/384054/designs/GitLab_Workflow_VS_Code_-_Branch_vulnerability_report_-_scan_in_progress_-_partial_results.png), [design 3](https://gitlab.com/gitlab-org/gitlab/-/issues/384054/designs/GitLab_Workflow_VS_Code_-_Branch_vulnerability_report_-_scan_complete.png)) 1. Policy violations - lists all security policies and impact the current branch 1. Security policy tree items should use the GitLab [text doc icon](https://gitlab.com/gitlab-org/gitlab-svgs/blob/main/sprite_icons/doc-text.svg) 1. Selecting the tree item for a security policy should display the details for that policy in VS Code ([design](https://gitlab.com/gitlab-org/gitlab/-/issues/384054/designs/GitLab_Workflow_VS_Code_-_Branch_vulnerability_report_-_Policy_violation_details.png)) 2. New findings - lists all security findings that are introduced in the current branch (diffed against existing findings) 1. Security findings tree items should use GitLab's [severity icons](https://gitlab-org.gitlab.io/gitlab-svgs/?q=severity) & colors 1. Note: Icons require a white (#fff) 1px border so ensure they are compatable across VS Code themes (ping @mfangman for assistance or questions) 1. Selecting the tree item for a security finding should display the details of that finding in VS Code ([design](https://gitlab.com/gitlab-org/gitlab/-/issues/384054/designs/GitLab_Workflow_VS_Code_-_Branch_vulnerability_report_-_scan_complete.png)) 3. Fixed findings - lists all security findings that are no longer detected in the current branch 1. If a security policy impacts an individual finding, this association should be communicated to users in 2 places: ([design](https://gitlab.com/gitlab-org/gitlab/-/issues/384054/designs/GitLab_Workflow_VS_Code_-_Branch_vulnerability_report_-_scan_complete.png)) 1. On the tree item for the finding - an [icon](https://gitlab-org.gitlab.io/gitlab-svgs/?q=~warning) should be added to the right side of the tree node. Hovering on a finding tree item with a policy violation should display a tooltip with the following format, “ [ Finding name ] • Violates security policy” ([design](https://gitlab.com/gitlab-org/gitlab/-/issues/384054/designs/GitLab_Workflow_VS_Code_-_Branch_vulnerability_report_-_scan_complete_-_item_hover.png)) 2. On the finding details panel - 1. An icon and text should be added to the top of the finding’s detail panel informing users of the policy violation. 2. When a finding violates a security policy, the security policy(s) being violated should also be displayed within the finding details panel as well. These policies should link to panel that contains policy details directly in VS code. 5. If one or more security jobs failed but some results are still available, the “Security scanning” tree item should communicate this state to users by displaying text to the right of the node title. This text should include the number of failed jobs, if possible ([design](https://gitlab.com/gitlab-org/gitlab/-/issues/384054/designs/GitLab_Workflow_VS_Code_-_Branch_vulnerability_report_-_job_failure.png)) 6. If the pipeline failed and no security results are available, the “Security scanning” tree item should communicate this state to users by displaying text to the right of the node title. This text should state that the “Pipeline failed” ([design](https://gitlab.com/gitlab-org/gitlab/-/issues/384054/designs/GitLab_Workflow_VS_Code_-_Branch_vulnerability_report_-_pipeline_failed_-_no_results.png)) 7. Security scanning results will not be displayed inline within the code files for the MVC 8. Vulnerability report should be diffed against the target branch so that only new and fixed findings associated with the source branch appear in VS Code. ### DRI | | | | ------ | ------ | | @fernando-c | ~frontend | | TBD | ~backend | ### Further details <!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. --> ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? Consider adding checkboxes and expectations of users with certain levels of membership https://docs.gitlab.com/ee/user/permissions.html * [ ] Add expected impact to members with no access (0) * [ ] Add expected impact to Guest (10) members * [ ] Add expected impact to Reporter (20) members * [ ] Add expected impact to Developer (30) members * [ ] Add expected impact to Maintainer (40) members * [ ] Add expected impact to Owner (50) members Please consider performing a threat model for the code changes that are introduced as part of this feature. To get started, refer to our Threat Modeling handbook page https://about.gitlab.com/handbook/security/threat_modeling/#threat-modeling. Don't hesitate to reach out to the Application Security Team (`@gitlab-com/gl-security/appsec`) to discuss any security concerns. --> ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change * Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/workflow.html * If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html --> ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the Quality Engineering quad planning and test planning processes and reach out to your counterpart Software Engineer in Test for assistance. Quad Planning: https://about.gitlab.com/handbook/engineering/quality/quality-engineering/quad-planning Test Planning: https://about.gitlab.com/handbook/engineering/quality/quality-engineering/test-engineering/#test-planning --> ### Available Tier <!-- This section should be used for setting the appropriate tier that this feature will belong to. Pricing can be found here: https://about.gitlab.com/pricing/ * Free * Premium/Silver * Ultimate/Gold --> ~"GitLab Ultimate" ### Feature Usage Metrics <!-- How are you going to track usage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it? Tracking metrics cannot be implemented at this time. ## Implementation Screenshot Here's a little sneak peek before we share the DEMO with y'all  ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. Create tracking issue using the Snowplow event tracking template. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Snowplow%20event%20tracking.md --> ### What is the type of buyer? <!-- What is the buyer persona for this feature? See https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/ In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#three-tiers --> ### Is this a cross-stage feature? <!-- Communicate if this change will affect multiple Stage Groups or product areas. We recommend always start with the assumption that a feature request will have an impact into another Group. Loop in the most relevant PM and Product Designer from that Group to provide strategic support to help align the Group's broader plan and vision, as well as to avoid UX and technical debt. https://about.gitlab.com/handbook/product/#cross-stage-features --> ### What is the competitive advantage or differentiation for this feature? ### Links / references <!-- Label reminders - you should have one of each of the following labels. Use the following resources to find the appropriate labels: - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ --> <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> #### Disclaimer *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 -->