The following 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.
Continuous Integration (CI) is the foundation of the Verify stage within the Ops Section direction, are recognizing the top risks to our business ofSecurity and SaaS Reliability first. In early 2021, we witnessed the cryptomining CI co-evolution, where free SaaS continuous integration platforms are being seriously compromised by the cryptocurrency mining attacks. GitLab was no exeception to this Industry-wide experience and we instrumented a few practices to mitigate abuse for on GitLab.com, which definitely impacts the experience of free and trial users.
Going forward, we needed a more proactive approach for monitoring, detecting, evaluating, preventing, and reacting to pipeline abuse. Traditionally, product categories are single product group areas an with one engineering team. The Pipeline Abuse Prevention category rather, is more of a cross-cutting program involving several teams, product groups, and functions. We are considering funding a cross-cutting Abuse group, as outlined by our Insider Threat Category as part of our Applied ML investments. If we do fund that group we will likely fold this category into it.
Pipeline Abuse Prevention is focused on proactive mitigation of CI abuse to ensure acceptable tolerances of business impact and human cost are not exceeded.
A number of issues are intentionally confidential despite our value of transparency. This is because we don't want to make it obvious to abusers the exact details of our controls. We aren't relying on "security by obscurity"; however, we also don't want to make it easier for the abusers.
For specific information related to spam and abuse reduction intiatives, check out Trust and Safety. You may also be looking for one of the following related product direction pages: GitLab Runner, or take a look at the Verify stage .
We rely on several teams to make this program successful:
|DRI||EM||Trust & Safety||AppSec||Fulfillment PM||Engineering|
|Jackie Porter||Darby Frey||Charl de Wit||Dominic Couture||Justin Farris||Stan Hu|
Other Product Groups may be brought in depending on scope classification.
Fulfillment - Anything related to collection and validation of credit cards/debit cards Verify - Anything related to triggering of credit card/debit card validation
There are four areas of focus for Pipeline Abuse Prevention:
|Credit/Debit Card Validation for Free and Trial Users to block bad actors||Kibana Dashboard||Dashboard|
|Pipeline Validation Service which has rules that catch certain coding behaviors to stop bad actors before pipelines are run||Dashboard|
|CI Minute Quota enforcements and limits across various levels of GitLab.com||Dashboard|
|Cost controls two dimensions: human cost and Infrastructure cost||CI Runner Costs||Blocking Dashboard|
We have a few items planned for follow-up enhancements to the rapid action efforts and credit card validation work via this confidential issue. We are exploring usability of the credit card validation experience for legitimate users via this confidential epic.
We also are thinking about ways to make the validation more inclusive for legitimate users who don't have access to or don't want to provide a credit/debit card in this confidential issue.
Currently, the team is in open dialogue on ownership of PVS.
We are also looking at instrumenting methods of abuse control via this 1. Abuse tracking controls including confidential issue
As of 13.12, we have instrumented enforcement of limits in private projects where now pipelines fail when CI minute quotas are exceeded.
Up next, we are iterating toward enforcement across public project by introducing limits to new public projects. While also taking into account how this impacts our Open Source projects in gitlab#330888.
We have two issues to establish costs control mechanisms: