Add issueLinks field to PipelineSecurityReportFinding
Why are we doing this work
We want to add an issueLinks
field to the PipelineSecurityReportFinding
GraphQL type for use in the new security finding modals. This can also take an argument for the link type.
Example of new query:
query {
project(fullPath:"<project path>") {
pipeline(iid:"<pipeline iid>") {
securityReportFinding(uuid:"<uuid>") {
issueLinks
nodes {
id
issue {
<issue data>
}
linkType
}
}
}
}
}
}
Response data will be vulnerabilityType.issueLinks
and the issue data defined by the Issue
type
Note that this differs from the original discussion in the spike. While the spike requests the existing vulnerability feedback data, this will more closely align with the current GraphQL implementation.
This also require implementing the new vulnerability promotion implementation for issue creation from the REST API. Otherwise we will have a bug where issues get created but not linked through the vulnerabilities.
Relevant links
Non-functional requirements
-
Documentation: Update the GraphQL docs -
Testing: Add appropriate specs including query specs
Implementation plan
The original implementation plan was to link issues directly to the security findings while preventing N+1
queries. While this worked well with the FindingsFinder
, there were problems when implementing PipelineVulnerabilitiesFinder
. To prevent further delays and make this work align better with the vulnerability_feedback
deprecation, @Quintasan helped me rework the Implementation Plan based off of the conversation noted below:
-
MR 1: Create a Vulnerability from the Security::Finding in VulnerabilityFeedback::CreateService
-
backend Use Vulnerabilities::FindOrCreateFromSecurityFindingService
to create the Vulnerability inVulnerabilityFeedback::CreateService.create_issue
.
-
-
Blocker: Make sure Add vulnerability
in Add `vulnerability` in `PipelineSecurityReportF... (#340558 - closed) is complete.- It is currently being worked on by a wider community member, but may need to be worked by a GitLab team member to expedite the work.
- This can be worked in parallel to MR 1
-
MR 2: Use the existing Vulnerabilities::IssueLink
in thePipelineSecurityReportFinding
, which has an existing resolver.
Verification steps
MR 1 (Vulnerability Creation):
NOTE: This can only be verified locally until the whole issue is complete.
- Create a new local project based off of https://gitlab.com/gitlab-examples/security/security-reports.
- Run a pipeline off of a branch.
- On
master
branch. Create an issue by clicking the "Create Issue" button in the Pipeline Security Findings list. - The issue should be created, but not the Vulnerability.
- This can be verified by performing the following in a rails console:
Project.find(<project ID>).vulnerabilities #should be 0
- Switch to the change branch. Create an issue by clicking the "Create Issue" button in the Pipeline Security Findings list.
- The issue and vulnerability should both be created.
- This can be verified by performing the following in a rails console:
Project.find(<project ID>).vulnerabilities #should be > 0
Test query on security finding with a issueLinks:
query {
project(fullPath:"<project path>") {
pipeline(iid:"<pipeline iid>") {
securityReportFinding(uuid:"<uuid>") {
issueLinks(type:CREATED) {
nodes {
uuid
issue {
<issue data>
}
}
}
}
}
}
}