Customers who are using GitLab.com or GitLab self-managed would like the ability to secure their code base or prevent their intellectual property from being stolen and or would like to track/monitor user activity. There are available third-party tools that integrate with competing products (GitHub, etc.)
Assess the security risk associated with your users’ activities within GitLab
Prohibit risky activities from being performed by your users in GitLab
Prevent the upload of sensitive or regulated data to GitLab
Protect sensitive content within GitLab repositories from being shared with unauthorized users or exposed publicly
Detect malware going to or from GitLab
Proposal
Netskope helps manage risk associated with data loss by enabling you to monitor and control user activities (ideally within GitLab), while also protecting your development data from being exposed to unauthorized users. Be awesome to provide the same/better level of integration that is already available with GitHub
Links / references
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
Customer will be outsourcing development work and would like the ability to prevent outside developers from downloading/cloning code locally. They want the team to have the ability to view and modify code, just not fork, download/clone.
Current solution for this problem:
Customer reached out to a DLP (Data Loss Protection/Prevention) solution (Netskope). The integration is available for competing products, but not GitLab at this time.
How important to them:
Very serious and would like GitLab to have a provided solution, integration or workaround.
Jefferson I am not aware of any integrations in this space BUT we could also proactively reach out to Netscope as they may be planning to support and we just dont know. Feel free to reach out and ask them.
Category:Integrations, based on our limited resources, is focusing on a very small number of integrations at the time. While we would certainly consider adding this to our roadmap in the future, I don't think it'd be in 2020.
Considering this is a security thing, may be worth getting input from @david and/or @NicoleSchwartz ?
If anything, I'd probably run with this since it mentions risk and data loss. I originally yielded to you since it seemed directly in the Category:Integrations scope DLP (data loss prevention) is a big compliance requirement particularly in the financial space (PCI comes to mind), so it might make sense for groupcompliance to be the secondary. There's certainly a security implication though, so likely a collaborative effort for sure.
I don't see this overtaking the current priorities for groupcompliance immediately, so this would likely be a Q4 2020+ item for me in the current state of things.
@mattgonzales - DLP would be part of Defend as DLP is a security related functionality. It seems there are several items which overlap between the Compliance stage and Secure/Defend. I'll schedule a meeting so we can discuss how we don't step on each other's toes or have teams both doing the same thing.
I have regular communication with @NicoleSchwartz and @jmeshell to collaborate on some of this overlap with our respective groups. Happy to chat about how I can keep that line of communication open with Defend as well.
Typically I focus on features that help with defining, enacting, and reporting on compliance (e.g. "My policy says I need 2 approves on each MR (define), nobody should be able to modify the MR approval settings (enact with a GitLab feature), and there should be an evidence artifact I can obtain to prove this is true in GitLab (report)"
@david@matt_wilson After our discussion last week, should we move this to ~"devops::defend"?
There's a customer call in the process of being scheduled and I'd like to make sure the appropriate PM(s) are present since the core topic surrounds DLP as a core concern, which fits into Defend's purview as I understand it
@sam.white there's a customer call currently scheduled for Wednesday at 1:30pm CST.
@jeffersonj - would you mind helping with coordination to involve @sam.white? I'm happy to join the call for this initial kickoff, but I may not be relevant for future calls from the sounds of it
@sam.white I went ahead and invited you to the meeting. We had to move the call due to some conflicts, but no pressure to join Friday 1:30-2:00PM PST. I will be asking to record the call and happy to share if you are not able to attend.
Please let me know if there are any questions or topics that you would like me to bring up.
GitLab integration with DLP providers is a feature we are waiting for as well. We have Netskope as our security tool but does not have integrations with GitLab ... any help in prioritizing this would be appreciated.
@sam.white it looks like there was previously a meeting here to discuss a customer's use case and development. Do we have notes of the outcome at that time and current planning as it relates to this issue?
@ja-me-sk yes, I joined a 3-way meeting with GitLab, Netskope, and the customer referenced above. The short summary is that Netskope, like most CASB providers, can monitor and block activity in cloud applications (such as GitLab) via one of two methods. 1) they can use API calls provided by the cloud application, or 2) they can intercept the traffic to/from the cloud application by being deployed as either a forward proxy (for gitlab.com instances) or as a reverse proxy (for self-hosted instances) to sit inline with the application.
GitLab's APIs are not robust enough to address all the use cases that the customer wanted; however, a full integration is still possible today via the second method of deploying Netskope as a forward/reverse proxy in front of GitLab. We can probably close this issue out as there is no action item for GitLab to do here - the integration is technically possible and available today.
I'm happy to discuss more if you or the customer still has outstanding questions.