You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Initial proposal is limited to detection and alerting across plaform, with rejection only
38
+
during preceive Git interactions.
43
39
44
40
Secret revocation and rotation is also beyond the scope of this new capability.
45
41
46
42
Scanned object types beyond the scope of this MVC include:
47
43
48
-
- Media types (JPEGs, PDFs,...)
49
-
- Snippets
50
-
- Wikis
44
+
See [target types](#target-types) for scan target priorities.
51
45
52
46
#### Management UI
53
47
@@ -69,7 +63,13 @@ which remain focused on active detection.
69
63
70
64
## Proposal
71
65
72
-
To achieve scalable secret detection for a variety of domain objects a dedicated
66
+
The first iteration of the experimental capability will feature a blocking
67
+
pre-receive hook implemented within the Rails application. This iteration
68
+
will be released in an experimental state to select users and provide
69
+
opportunity for the team to profile the capability before considering extraction
70
+
into a dedicated service.
71
+
72
+
In the future state, to achieve scalable secret detection for a variety of domain objects a dedicated
73
73
scanning service must be created and deployed alongside the GitLab distribution.
74
74
This is referred to as the `SecretScanningService`.
75
75
@@ -94,10 +94,10 @@ as self-managed instances.
94
94
The critical paths as outlined under [goals above](#goals) cover two major object
95
95
types: Git blobs (corresponding to push events) and arbitrary text blobs.
96
96
97
-
The detection flow for push events relies on subscribing to the PostReceive hook
98
-
to enqueue Sidekiq requests to the `SecretScanningService`. The`SecretScanningService`
99
-
service fetches enqueued refs, queries Gitaly for the ref blob contents, scans
100
-
the commit contents, and notifies the Rails application when a secret is detected.
97
+
The detection flow for push events relies on subscribing to the PreReceive hook
98
+
to scan commit data using the [PushCheck interface](https://gitlab.com/gitlab-org/gitlab/blob/3f1653f5706cd0e7bbd60ed7155010c0a32c681d/lib/gitlab/checks/push_check.rb). This`SecretScanningService`
99
+
service fetches the specified blob contents from Gitaly, scans
100
+
the commit contents, and rejects the push when a secret is detected.
101
101
See [Push event detection flow](#push-event-detection-flow) for sequence.
102
102
103
103
The detection flow for arbitrary text blobs, such as issue comments, relies on
@@ -112,13 +112,33 @@ storage. See discussion [in this issue](https://gitlab.com/groups/gitlab-org/-/e
112
112
around scanning during streaming and the added complexity in buffering lookbacks
113
113
for arbitrary trace chunks.
114
114
115
-
In any case of detection, the Rails application manually creates a vulnerability
115
+
In the case of a push detection, the commit is rejected and error returned to the end user.
116
+
In any other case of detection, the Rails application manually creates a vulnerability
116
117
using the `Vulnerabilities::ManuallyCreateService` to surface the finding in the
117
118
existing Vulnerability Management UI.
118
119
119
120
See [technical discovery](https://gitlab.com/gitlab-org/gitlab/-/issues/376716)
120
121
for further background exploration.
121
122
123
+
### Target types
124
+
125
+
Target object types refer to the scanning targets prioritized for detection of leaked secrets.
126
+
127
+
In order of priority this includes:
128
+
129
+
1. non-binary Git blobs
130
+
1. job logs
131
+
1. issuable creation (issues, MRs, epics)
132
+
1. issuable updates (issues, MRs, epics)
133
+
1. issuable comments (issues, MRs, epics)
134
+
135
+
Targets out of scope for the initial phases include:
136
+
137
+
- Media types (JPEGs, PDFs,...)
138
+
- Snippets
139
+
- Wikis
140
+
- Container images
141
+
122
142
### Token types
123
143
124
144
The existing Secret Detection configuration covers ~100 rules across a variety
@@ -140,9 +160,10 @@ for all secret scanning in pipeline contexts. By using its `--no-git` configurat
140
160
we can scan arbitrary text blobs outside of a repository context and continue to
141
161
utilize it for non-pipeline scanning.
142
162
143
-
Given our existing familiarity with the tool and its extensibility, it should
144
-
remain our engine of choice. Changes to the detection engine are out of scope
145
-
unless benchmarking unveils performance concerns.
163
+
In the case of prereceive detection, we rely on a combination of keyword/substring matches
164
+
for prefiltering and `re2` for regex detections. See [spike issue](https://gitlab.com/gitlab-org/gitlab/-/issues/423832) for initial benchmarks
165
+
166
+
Changes to the detection engine are out of scope until benchmarking unveils performance concerns.
146
167
147
168
Notable alternatives include high-performance regex engines such as [hyperscan](https://github.com/intel/hyperscan) or it's portable fork [vectorscan](https://github.com/VectorCamp/vectorscan).
148
169
@@ -167,37 +188,42 @@ for past discussion around scaling approaches.
Copy file name to clipboardExpand all lines: doc/user/application_security/vulnerabilities/index.md
+7-1
Original file line number
Diff line number
Diff line change
@@ -104,7 +104,13 @@ When dismissing a vulnerability, one of the following reasons must be chosen to
104
104
-**Used in tests**: The finding is not a vulnerability because it is part of a test or is test data.
105
105
-**Not applicable**: The vulnerability is known, and has not been remediated or mitigated, but is considered to be in a part of the application that will not be updated.
106
106
107
-
## Change status of a vulnerability
107
+
## Change the status of a vulnerability
108
+
109
+
> In GitLab 16.4 the ability for `Developers` to change the status of a vulnerability (`admin_vulnerability`) was [deprecated](../../../update/deprecations.md#deprecate-change-vulnerability-status-from-the-developer-role). The `admin_vulnerability` permission will be removed, by default, from all `Developer` roles in GitLab 17.0.
110
+
111
+
Prerequisites:
112
+
113
+
- You must have at least the Developer role for the project.
108
114
109
115
To change a vulnerability's status from its Vulnerability Page:
@@ -249,6 +249,7 @@ The following table lists project permissions available for each role:
249
249
21. Authors of tasks can delete them even if they don't have the Owner role, but they have to have at least the Guest role for the project.
250
250
22. You must have permission to [view the epic](group/epics/manage_epics.md#who-can-view-an-epic).
251
251
23. In GitLab 15.9 and later, users with the Guest role and an Ultimate license can view private repository content if an administrator (on self-managed) or group owner (on GitLab.com) gives those users permission. The administrator or group owner can create a [custom role](custom_roles.md) through the API and assign that role to the users.
252
+
24. In GitLab 16.4 the ability for `Developers` to change the status of a vulnerability (`admin_vulnerability`) was [deprecated](../update/deprecations.md#deprecate-change-vulnerability-status-from-the-developer-role). The `admin_vulnerability` permission will be removed, by default, from all `Developer` roles in GitLab 17.0.
Copy file name to clipboardExpand all lines: locale/gitlab.pot
+3
Original file line number
Diff line number
Diff line change
@@ -56920,6 +56920,9 @@ msgstr ""
56920
56920
msgid "is not in the group enforcing Group Managed Account"
56921
56921
msgstr ""
56922
56922
56923
+
msgid "is not linked to a SAML account or has an inactive SCIM identity. For information on how to resolve this error, see the %{troubleshoot_link_start}troubleshooting SCIM documentation%{troubleshoot_link_end}."
0 commit comments