このページの情報は古くなっている可能性があります。 最新の情報は 本家サイト でご確認ください。
Last Reviewed: 2020-02-07
Thanks for visiting the strategy page for Compliance Management in GitLab. If you'd like to provide feedback on this page or contribute to this vision, please feel free to open a merge request for this page or comment in the corresponding epic for this category.
Enterprises operating in regulated environments need to ensure the technology they use complies with their internal company policies and procedures, which are largely based on the requirements of a particular legal or regulatory framework (e.g. GDPR, SOC 2, ISO, PCI-DSS, SOX, COBIT, HIPAA, FISMA, NIST) governing their industry. Customers need features that enable them to comply with these frameworks beginning with defining the rules, or controls, for their GitLab environment.
Customers rely on organizations like GitLab to make the compliance process easier, often times by simply not making things more difficult or adding risk. Our goal is to provide "out-of-the-box" solutions where we can and customization where we can't. In order to do this, we must first establish the frameworks our customers adhere to so we can have a baseline to build upon.
When customers adhere to internal or external compliance frameworks, often times a need for customization arises. One organization's process for an activity can vary greatly from another's and this can create friction or usability issues. To facilitate better usability within GitLab towards compliance efforts, we'll be introducing features that enable customers to define specific policies or requirements their users and instance should abide by.
In almost all cases, Compliance Management for an organization focuses on reducing overall risk, enforcing separation of duties, and implementing remediation processes. Without features to support these efforts, administrators for these organizations are faced with few workarounds: they can tolerate higher risk, lock down an instance and manage additional administrative overhead at the price of velocity, or build and maintain layers of automation on their own. For enterprises to thrive, this is a problem that demands a high-quality, native solution in GitLab.
Organizations need control of all technology they use to mitigate risk and adhere to compliance frameworks. GitLab's Compliance Management category aims to address this need by introducing features and experiences that enable our customers to introduce better controls for their instances.
There will never be a perfect set of controls for every organization. For example, we've learned from user feedback that granular user roles and permissions are a very difficult, nuanced problem to solve. Organizations want customizable, deep control on a wide swath of settings and features. It's possible for us to iterate on "sensible defaults" to make setting up GitLab environments faster and easier; it's also feasible for us to introduce enforcement capabilities to make managing compliance with GitLab more credible and effective.
This category - Compliance Management - is designed to introduce better control at the project level with features like controls definition and compliance checks in merge requests. It also focuses on group-level considerations such as preventing project maintainers from changing critical settings like merge request approvals.
The first step on this journey is introducing a Minimal, viable version of Compliance Management - described further in our Maturity Plan below.
As we're still the conceptual stages of developing Compliance Management, your feedback is critical to successfully shaping this category so that it works for your organization's needs. If you're interested in this problem space, please comment on your needs and experiences with permissions in GitLab. We're especially interested in:
Compliance Management is currently in Minimal maturity. The next step for Compliance Management is Viable maturity.
To achieve a viable version of Compliance Management, we'll be working towards the features in this epic. Our primary focus is on empowering customers with more, better controls for their GitLab environments. Applying compliance controls to projects would enable certain settings, such as those found in MR approvals, to maintain separation of duties. We're also bringing more group-level settings to GitLab.com to support customers who aren't running a self-managed instance, but who require the same levels of control. Those features include: configuring push rules at the group-level, configure protected branches at the group-level, and extending PAT expiration setting to GitLab.com.
Once we've achieved a viable version of Compliance Management, achieving a Complete level of maturity will involve collecting customer feedback and reacting. Assuming we're on the right track, we'll likely scale the solution in two dimensions:
Finally, once we've achieved a ruleset that's sufficiently flexible and powerful for enterprises, it's not enough to be able to define these rules - we should be able to measure and confirm that they're being adhered to. Achieving Complete or Lovable maturity likely means further expansion of the two dimensions above, plus visualizing/reporting on the state of Compliance Management across the instance.