debian-mirror-gitlab/doc/development/integrations/secure_partner_integration.md

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

123 lines
8.4 KiB
Markdown
Raw Normal View History

2021-01-29 00:20:46 +05:30
---
stage: Secure
group: Static Analysis
2022-11-25 23:54:43 +05:30
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
2021-01-29 00:20:46 +05:30
---
2020-04-08 14:13:33 +05:30
# Secure Partner Integration - Onboarding Process
2020-04-22 19:07:51 +05:30
If you want to integrate your product with the [Secure Stage](https://about.gitlab.com/direction/secure/),
2021-02-22 17:27:13 +05:30
this page describes the developer workflow GitLab intends for
2020-04-08 14:13:33 +05:30
our users to follow with regards to security results. These should be used as
guidelines so you can build an integration that fits with the workflow GitLab
users are already familiar with.
This page also provides resources for the technical work associated
2021-04-17 20:07:23 +05:30
with [onboarding as a partner](https://about.gitlab.com/partners/technology-partners/integrate/).
2020-04-08 14:13:33 +05:30
The steps below are a high-level view of what needs to be done to complete an
integration as well as linking to more detailed resources for how to do so.
2020-07-28 23:09:34 +05:30
## Integration Tiers
2021-03-11 19:13:27 +05:30
The security offerings in GitLab are designed for GitLab Ultimate users, and the
2020-07-28 23:09:34 +05:30
[DevSecOps](https://about.gitlab.com/handbook/use-cases/#4-devsecops-shift-left-security)
use case. All the features are in those tiers. This includes the APIs and standard reporting
framework needed to provide a consistent experience for users to easily bring their preferred
security tools into GitLab. We ask that our integration partners focus their work on those license
tiers so that we can provide the most value to our mutual customers.
2020-04-08 14:13:33 +05:30
## What is the GitLab Developer Workflow?
This workflow is how GitLab users interact with our product and expect it to
2021-02-22 17:27:13 +05:30
function. Understanding how users use GitLab today helps you choose the
2020-04-08 14:13:33 +05:30
best place to integrate your own product and its results into GitLab.
- Developers want to write code without using a new tool to consume results
or address feedback about the item they are working on. Staying inside a
single tool, GitLab, helps them to stay focused on finishing the code and
projects they are working on.
- Developers commit code to a Git branch. The developer creates a merge request (MR)
inside GitLab where these changes can be reviewed. The MR triggers a GitLab
pipeline to run associated jobs, including security checks, on the code.
- Pipeline jobs serve a variety of purposes. Jobs can do scanning for and have
implications for app security, corporate policy, or compliance. When complete,
the job reports back on its status and creates a
2023-06-20 00:43:36 +05:30
[job artifact](../../ci/jobs/job_artifacts.md) as a result.
2022-07-23 23:45:48 +05:30
- The [Merge Request Security Widget](../../ci/testing/index.md#security-reports)
2020-04-08 14:13:33 +05:30
displays the results of the pipeline's security checks and the developer can
review them. The developer can review both a summary and a detailed version
of the results.
2021-06-08 01:23:25 +05:30
- If certain policies (such as [merge request approvals](../../user/project/merge_requests/approvals/index.md))
2020-04-08 14:13:33 +05:30
are in place for a project, developers must resolve specific findings or get
an approval from a specific list of people.
2021-01-03 14:25:43 +05:30
- The [security dashboard](../../user/application_security/security_dashboard/index.md)
2020-04-08 14:13:33 +05:30
also shows results which can developers can use to quickly see all the
vulnerabilities that need to be addressed in the code.
- When the developer reads the details about a vulnerability, they are
presented with additional information and choices on next steps:
1. Create Issue (Confirm finding): Creates a new issue to be prioritized.
1. Add Comment and Dismiss Vulnerability: When dismissing a finding, users
can comment to note items that they
have mitigated, that they accept the vulnerability, or that the
vulnerability is a false positive.
1. Auto-Remediation / Create Merge Request: A fix for the vulnerability can
be offered, allowing an easy solution that does not require extra effort
from users. This should be offered whenever possible.
1. Links: Vulnerabilities can link out external sites or sources for users
to get more data around the vulnerability.
## How to onboard
This section describes the steps you need to complete to onboard as a partner
2020-06-23 00:09:42 +05:30
and complete an integration with the Secure stage.
2020-04-08 14:13:33 +05:30
2021-04-29 21:17:54 +05:30
1. Read about our [partnerships](https://about.gitlab.com/partners/technology-partners/integrate/).
2020-06-23 00:09:42 +05:30
1. [Create an issue](https://gitlab.com/gitlab-com/alliances/alliances/-/issues/new?issuable_template=new_partner)
2020-04-08 14:13:33 +05:30
using our new partner issue template to begin the discussion.
1. Get a test account to begin developing your integration. You can
2021-04-29 21:17:54 +05:30
request a [GitLab.com Subscription Sandbox](https://about.gitlab.com/partners/technology-partners/integrate/#gitlabcom-subscription-sandbox-request)
or an [EE Developer License](https://about.gitlab.com/partners/technology-partners/integrate/#requesting-ultimate-dev-license-for-rd).
2023-01-13 00:05:48 +05:30
1. Provide a [pipeline job](../../development/pipelines)
2020-04-08 14:13:33 +05:30
template that users could integrate into their own GitLab pipelines.
1. Create a report artifact with your pipeline jobs.
1. Ensure your pipeline jobs create a report artifact that GitLab can process
to successfully display your own product's results with the rest of GitLab.
- See detailed [technical directions](secure.md) for this step.
2021-09-30 23:02:18 +05:30
- Read more about [job report artifacts](../../ci/yaml/index.md#artifactsreports).
2023-06-20 00:43:36 +05:30
- Read about [job artifacts](../../ci/jobs/job_artifacts.md).
2020-04-08 14:13:33 +05:30
- Your report artifact must be in one of our currently supported formats.
For more information, see the [documentation on reports](secure.md#report).
2020-04-22 19:07:51 +05:30
- Documentation for [SAST reports](../../user/application_security/sast/index.md#reports-json-format).
- Documentation for [Dependency Scanning reports](../../user/application_security/dependency_scanning/index.md#reports-json-format).
- Documentation for [Container Scanning reports](../../user/application_security/container_scanning/index.md#reports-json-format).
2023-03-04 22:38:38 +05:30
- See this [example secure job definition that also defines the artifact created](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Container-Scanning.gitlab-ci.yml).
2020-06-23 00:09:42 +05:30
- If you need a new kind of scan or report, [create an issue](https://gitlab.com/gitlab-org/gitlab/-/issues/new#)
2020-04-22 19:07:51 +05:30
and add the label `devops::secure`.
2020-04-08 14:13:33 +05:30
- Once the job is completed, the data can be seen:
2022-07-23 23:45:48 +05:30
- In the [Merge Request Security Report](../../ci/testing/index.md#security-reports) ([MR Security Report data flow](https://gitlab.com/snippets/1910005#merge-request-view)).
2023-06-20 00:43:36 +05:30
- While [browsing a Job Artifact](../../ci/jobs/job_artifacts.md).
2020-04-08 14:13:33 +05:30
- In the [Security Dashboard](../../user/application_security/security_dashboard/index.md) ([Dashboard data flow](https://gitlab.com/snippets/1910005#project-and-group-dashboards)).
1. Optional: Provide a way to interact with results as Vulnerabilities:
- Users can interact with the findings from your artifact within their workflow. They can dismiss the findings or accept them and create a backlog issue.
2021-02-22 17:27:13 +05:30
- To automatically create issues without user interaction, use the [issue API](../../api/issues.md).
2020-04-08 14:13:33 +05:30
1. Optional: Provide auto-remediation steps:
2021-09-04 01:27:46 +05:30
- If you specified `remediations` in your artifact, it is proposed through our [remediation](../../user/application_security/vulnerabilities/index.md#resolve-a-vulnerability)
2020-04-22 19:07:51 +05:30
interface.
2020-04-08 14:13:33 +05:30
1. Demo the integration to GitLab:
- After you have tested and are ready to demo your integration please
2021-04-29 21:17:54 +05:30
[reach out](https://about.gitlab.com/partners/technology-partners/integrate/) to us. If you
skip this step you won't be able to do supported marketing.
2020-04-08 14:13:33 +05:30
1. Begin doing supported marketing of your GitLab integration.
2021-04-29 21:17:54 +05:30
- Work with our [partner team](https://about.gitlab.com/partners/technology-partners/integrate/)
2020-04-22 19:07:51 +05:30
to support your go-to-market as appropriate.
- Examples of supported marketing could include being listed on our [Security Partner page](https://about.gitlab.com/partners/#security),
doing an [Unfiltered blog post](https://about.gitlab.com/handbook/marketing/blog/unfiltered/),
2021-02-22 17:27:13 +05:30
doing a co-branded webinar, or producing a co-branded white paper.
2020-04-08 14:13:33 +05:30
2021-03-11 19:13:27 +05:30
We have a <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> [video playlist](https://www.youtube.com/playlist?list=PL05JrBw4t0KpMqYxJiOLz-uBIr5w-yP4A)
2020-06-23 00:09:42 +05:30
that may be helpful as part of this process. This covers various topics related to integrating your
tool.
2020-04-08 14:13:33 +05:30
If you have any issues while working through your integration or the steps
above, please create an issue to discuss with us further.