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

• Spike

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 in VulnerabilityFeedback::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 the PipelineSecurityReportFinding, which has an existing resolver.

Verification steps

MR 1 (Vulnerability Creation):

NOTE: This can only be verified locally until the whole issue is complete.

1. Create a new local project based off of https://gitlab.com/gitlab-examples/security/security-reports.
2. Run a pipeline off of a branch.
3. On master branch. Create an issue by clicking the "Create Issue" button in the Pipeline Security Findings list.
4. The issue should be created, but not the Vulnerability.
5. This can be verified by performing the following in a rails console:

Project.find(<project ID>).vulnerabilities #should be 0

6. Switch to the change branch. Create an issue by clicking the "Create Issue" button in the Pipeline Security Findings list.
7. The issue and vulnerability should both be created.
8. 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>
            }
          }
        }
      }
    }
  }
}