Product Stage Direction - Secure

このページのコンテンツ

Proactively identify vulnerabilities and weaknesses to minimize risk

GitLab Secure enables accurate, automated, and continuous assessment of your applications and services enabling you to proactively identify vulnerabilities and weaknesses to minimize your security risk. Secure is not an additional step in your process nor an additional tool to introduce to your process. it is woven into your DevOps cycle thus allowing you to adapt your security testing and processes to your developers (and not the other way around).

Secure Overview

Stage Overview

The Secure Stage focuses on identifying security findings (e.g., vulnerabilities and weaknesses) within applications and services prior to moving them to operations. Furthermore, Secure can (and will) provide security visibility for applications and services already deployed to production. Secure’s goal is to proactively identify vulnerabilities and weaknesses before they are exploited. This is done by:

Groups

The Secure Stage is made up of one DevOps stage, Secure, and five groups supporting the major categories of DevSecOps including:

Resourcing and Investment

The existing team members for the Secure Stage can be found in the links below:

3 Year Stage Themes

Security Is A Team Effort

Everyone benefits when security is a team effort as testing happens regularly, issues are found earlier, and code shipped is more secure. To make this possible, security must be approachable, not overburden teams, and results must be easy to interpret. Security testing tools and processes must be adapted to your developers (and not the other way around). This means bringing security into the workflow of your developers such that they can stay within their context without having unnecessary steps added to their daily work. Furthermore, results provided as security findings must be presented in a way that they can be interpreted without needing a PhD in cybersecurity. This includes providing enough detail to begin identifying the root cause (including identifying the section of code causing the security finding) and suggesting remediation steps (including auto-remediation) as well as pointing to industry standards related to the security finding. By implementing an integrated DevSecOps lifecycle with actionable results, security becomes everyone’s responsibility.

As examples, GitLab will provide:

Shift Left. No, More Left Than That.

The “shift left” approach is not a new concept within software testing and DevOps best practices. It is commonly thought of when discussing the DevSecOps lifecycle. This usually includes security testing earlier in the software development lifecycle with the goal of identifying security vulnerabilities and weaknesses prior to shipping code to operations. Today’s techniques include static application security testing (SAST), dynamic application security testing (DAST), interactive application security testing (IAST), dependency scanning, and license compliance. The continuation of the “shift left” approach requires a harder shift left, bringing security testing as close as possible to the developer. This enables earlier detection of security vulnerabilities and weaknesses, thus lowering the cost of remediation (as well as reducing work for the entire team as security findings are addressed prior to reaching the QA and security teams).

As examples, GitLab will provide:

Shift Right. Yes, Right. Right Into Operations.

Security testing doesn’t stop once code is shipped. New vulnerabilities, security weaknesses and, attacker techniques are constantly discovered, leaving operations and their associated applications and services open to being compromised. Also, as organizations continue to shift to the cloud and employ cloud-native strategies, new attack surfaces are exposed that did not exist within the traditional data center. These include items like cloud storage permissions and unwanted network services. Applications, services, and their associated cloud-native infrastructure need to be assessed just as a user (or an attacker) would interact with them. This means performing the same tasks that an attacker would perform including reconnaissance, vulnerability assessment, and penetration testing. Implementing a continuous assessment strategy of operations is needed to provide full visibility into all potential risk.

As examples, GitLab will provide:

Provide Active Intelligence to Enable Data-Driven Decisions

Security findings, without context, can lead to making incorrect decisions on remediation, leaving applications and services vulnerable. With more data made available, better decisions can be made while prioritizing security findings, enabling users to best manage their security risk. Furthermore, this enables developers to write secure code, build operations to package dependencies free of vulnerabilities, and security team members to test deeper than previously achievable. Leveraging machine learning provides active intelligence, enabling users to make smart, data-driven decisions at the right time, lowering overall security risk. Machine learning, to be successful, relies on big data to build accurate models. The GitLab community includes developers, build operators, and security teams all working together within their organizations to code, build, deliver and secure application and services going into operations. As a global community, developers can learn from each other to identify and better secure code. Dependency vulnerabilities and weaknesses can be avoided, and security teams can test smarter, faster, and deeper. Machine learning, powered by anonymized data, provides active intelligence enabling data-driven decisions.

As examples, GitLab will provide:

BYOT - Bring Your Own (Security) Tools

At GitLab, we believe everyone can contribute and security is everyone’s responsibility. We empower GitLab users by providing security tools which include Static Analysis, Dynamic Analysis, Container Scanning, Dependency Scanning, and License Scanning. However, we recognize our users may have existing security tools and may want to continue to use them. As such, we strive to play well with others. Security tool vendors will be provided standardized components (e.g., APIs) within the GitLab complete DevOps platform enabling easy integration into our Security Dashboard and Merge Request controls including security approvals. This allows our users to have alternate security tools that either replace, or augment, our Secure tools.

As examples, GitLab will provide:

If you are interested in contributing such an integration, please create an issue so we can collaborate on questions and adding any enabling functionality.

3 Year Strategy

In three years the Secure Stage market will:

As a result, in three years, Gitlab will:

1 Year Plan

What's Next for Secure

To meet our audacious goals, the Secure Stage will focus on the following over the next 12 months:

What We're Not Doing

The following will NOT be a focus over the next 12 months:

Please explore the individual Category Direction pages for more information on 12 month plans.

Target audience

GitLab identifies who our DevSecOps application is built for utilizing the following categorization. We list our view of who we will support when in priority order.

Today

To capitalize on the opportunities listed above, the Secure Stage has features that make it useful to the following personas today.

  1. 🟩 Developers / Development Teams
  2. 🟩 Security Teams
  3. 🟨 SecOps Teams
  4. 🟨 QA engineers / QA Teams
  5. ⬜️ Security Consultants

Medium Term (1-2 years)

As we execute our 3 year strategy, our medium term (1-2 year) goal is to provide a single DevSecOps application that enables collaboration between developers, security teams, SecOps teams, and QA Teams.

  1. 🟩 Developers / Development Teams
  2. 🟩 Security Teams
  3. 🟩 SecOps Teams
  4. 🟩 QA engineers / QA Teams
  5. 🟨️ Security Consultants

Developers

Nonetheless, we want to support developers and provide feedback during the application development. Security Reports in merge request widgets and pipelines allow early access to security information that can be used to fix problems even before they are merged into the stable branch or released to the public, embracing the idea of shift left testing.

This approach is valuable to highlight how specific changes could affect the security of the application.

Personas

Security teams

We want to support security teams as first class citizens. GitLab should be their primary tool to manage monitoring and remediation of security issues. Using the Security Dashboard security specialists know exactly which is the most important thing they need to take care of, while Directors of Security can manage workflows and analyze historical data to figure out how to improve the response time.

This is a vulnerability-centric approach where items are grouped and ordered to suggest what's most important in a group, or in the entire instance.

Personas

Categories

There are a few product categories that are critical for success here; each one is intended to represent what you might find as an entire product out in the market. We want our single application to solve the important problems solved by other tools in this space - if you see an opportunity where we can deliver a specific solution that would be enough for you to switch over to GitLab, please reach out to the PM for this stage and let us know.

Each of these categories has a designated level of maturity; you can read more about our category maturity model to help you decide which categories you want to start using and when.

SAST

静的アプリケーションセキュリティテストでは、GitLabの一部としてインストールされているオープンソースツールを使用して、デプロイ前にアプリケーションのソースコードやバイナリをスキャンして潜在的な脆弱性を発見します。脆弱性はマージリクエストごとに表示され、結果は収集されて単一のレポートとして表示されます。 This category is at the "viable" level of maturity.

Priority: high • DocumentationDirection

DAST

動的アプリケーションセキュリティテストでは、実行中のウェブアプリケーションの脆弱性を分析します。 GitLab CI/CDの一部として、マージリクエストごとに作成された レビューアプリ に対して実際に攻撃を実行します。 ユーザーは、HTTP認証情報を提供してプライベート領域をテストすることができます。 脆弱性は、マージリクエストごとにインラインで表示されます。 This category is at the "viable" level of maturity.

Priority: high • DocumentationDirection

IAST

対話型アプリケーションセキュリティテストでは、コードを計測してエラー状態をチェックすることで、アプリケーションの実行時の動作をチェックします。 これは、アプリケーション環境内に常駐するエージェントと、対話型の処理で意図しない結果を引き起こすことができる、DASTのような外部コンポーネントで構成されています。

Priority: low • Direction

ファズテスト

ファズテストでは、一般的なペイロード以外の、任意のペイロードを使用することで様々な結果を取得できます。 This category is at the "minimal" level of maturity.

Priority: high • DocumentationDirection

依存関係スキャニング

GitLab CI/CDを使用して、(Ruby gemsなどのライブラリのような)外部依存関係を分析し、コードコミットごとに既知の脆弱性が存在しないか確認します。このスキャンは、オープンソースツールや(現在はGitLabの一部の)Gemnasiumとのインテグレーションに依存しており、マージリクエストごとに脆弱性が存在し更新が必要な依存関係を表示します。結果は集約され、単一のレポートとして提供されます。 This category is at the "viable" level of maturity.

Priority: high • DocumentationDirection

コンテナスキャニング

Dockerイメージにアプリケーション環境の既知の脆弱性が存在ないかチェックします。あらゆる種類のDockerイメージをスキャンできるオープンソースツールのClairを使用して、公開されている脆弱性データベースとイメージの内容を分析します。脆弱性はマージリクエストごとにインラインで表示されます。 This category is at the "viable" level of maturity.

Priority: medium • DocumentationDirection

ライセンスコンプライアンス

コードがコミットされると、プロジェクトの依存関係が検索され、プロジェクトごとのカスタムポリシーで定義された承認済みのライセンスとブラックリストに登録されたライセンスが検索されます。 使用されているソフトウェアライセンスがポリシーの範囲内にない場合は、そのライセンスが特定されます。 このスキャンは、オープン ソースツールのLicenseFinderを使用しており、ライセンス分析結果は、マージリクエストごとにインラインで表示され、ライセンスの問題を迅速に解決できます。 This category is at the "viable" level of maturity.

Priority: medium • DocumentationDirection

シークレット検出

コミットに認証情報やシークレットが含まれていないかをチェックします。 This category is at the "viable" level of maturity.

Priority: medium • DocumentationDirection

脆弱性データベース

GitLabは、プロプライエタリなアプリケーションとオープンソースのセキュリティスキャンツールをインテグレーションしています。これらのスキャンの有効性を維持するために、それらの脆弱性データベースを最新の状態に保つように努めています。

Priority: high • Direction

セキュリティベンチマーク

セキュリティの有効性を測定するためのGitLab Secureステージベンチマークでセキュリティの問題を検出できます。

Direction

アタックエミュレーション

攻撃対象の弱点を特定するための実世界をエミュレートした自動化シナリオを用いて、アプリケーションやサービスがセキュリティの脅威に対して脆弱ではないことを継続的に評価します。

Priority: low

マルウェアスキャニング

マルウェアなどの悪意のあるコードからプロジェクトを保護します。

Priority: low

PKI管理

Priority: medium • Direction

脆弱性管理

アプリケーションで検出された脆弱性を表示、トリアージ、トレンドを分析、追跡、解決できます。 This category is at the "minimal" level of maturity.

Priority: high • DocumentationDirection

Other top-level features

In the Secure stage there are features that are cross-category. They allow Security Teams and Developers to manage security with a holistic approach. The prioritization of a security issue doesn't fully depend on the type of vulnerability, but on its severity and so which is the impact on the application.

That's why we want to create features where vulnerabilities are in one single place, no matter if they are coming from SAST, Dependency Scanning, Container Scanning, etc.

Auto Remediation

When a vulnerability is automatically detected by GitLab, users can be aware of that using the Security Dashboard or looking at security reports. But this still requires manual intervention to create a fix and push it to production, and during this time there is a vulnerable window where attackers can leverage the vulnerability.

Auto Remediation aims to automate vulnerability solution flow, and automatically create a fix. The fix is then tested, and if it passes all the tests already defined for the application, it is deployed to production.

GitLab can then monitor performances of the deployed app, and revert all the changes in case performances are decreasing dramatically, warning the user about the entire process and reducing the need for manual actions.

Read more in this epic.

Slides are available here.

セキュリティダッシュボード

Security Dashboards, available at group and project level, are the primary tool for Security Teams and Directors of Security. They can use those dashboards to access the current security status of their applications, and to start a remediation process from here.

The dashboard is also giving stats and charts to figure out how the team is performing to keep the security level to a proper level.

Bill of materials

Software is often based on many components that are reused. Every modern programming language makes it easy to pull and use external libraries via package managers. There is a growing need to know exactly what is included in the final app, and the relevant information about those third-party components, like the version number, the license, and the security status.

The bill of materials (BOM) makes this information available and accessible, so compliance can perform validation that the app can be released and deployed.

Read more in this epic.

Offline environment deployments

Users of GitLab Self-Managed may have installations with limited or no internet connectivity. These environments might be in their lab, their datacenter, or even in their preferred cloud provider. GitLab refers to these deployments as offline environment deployments however other common names include air-gapped environments, limited connectivity environments, local area network (LAN) environments, or intranet environments. These environments have physical barriers preventing internet access or potentially have security policies (e.g., firewalls) which limit access.

We are actively working to allow users to run all of our Secure categories in physically disconnected networks with access to internal registries. This will enable users within the other environment types like limited connectivity to be successful using Secure categories by following the same documentation and use cases.

Learn more about this in GitLab Docs as well as in the epic for Secure's current status supporting these types of environments.

Auto DevOps

Auto DevOps provides pre-defined CI/CD configuration for your applications. To do so, Auto DevOps includes security testing templates including SAST, Dependency Scanning, License Compliance, Container Scanning, and DAST to enable quick setup of security jobs within CI/CD. The relevant Secure stage groups maintain the pre-defined Auto DevOps jobs for those tests.

料金

Secure is focused on providing enterprise-grade application security testing (AST) capabilities to minimize overall risk. The intent is to provide enough value in paid features so as to allow Secure to contribute in a significant way over the next 3 years toward GitLab's company-level financial goals.

Although paid features are the primary focus, there are several reasons why features for unpaid tiers might be prioritized above paid features:

  1. The Secure stage has a powerful potential to help improve the security of projects everywhere. Features with the potential to significantly improve the security posture of all projects will be highly prioritized and made available in an unpaid tier.
  2. To continue to be good stewards in the open source community, any basic integration with open source projects will be available in an unpaid tier by default, along with the "table stakes" set of functionality required to allow that feature to be usable with GitLab. Any open source project integrations that currently exist in paid tiers will have a discussion opened about moving the integration to an unpaid tier.

Core/Free

This tier is the primary way to increase broad adoption of the Secure stage, as well as encouraging community contributions and improving security across the entire GitLab user base.

As a general rule of thumb, features will fall in the Core/Free tier when they meet one or more of the following criteria:

Some examples include:

Starter/Bronze

This tier is not a significant part of Secure's pricing strategy.

Premium/Silver

This tier is not a significant part of Secure's pricing strategy.

Ultimate/Gold

This tier is the primary focus for the Secure stage as the security posture of an organization is typically a primary concern of the executive team and even the board of directors. Just as a major security incident has far reaching consequences that impact the entirety of an organization, the features and capabilities that enable organizations to assess their overall security risk tend to be valued with equal weight. The types of capabilities that fall in the Ultimate/Gold tier vs an unpaid tier should be those that are necessary for an organization, rather than an individual, to properly secure their code before pushing it into a production environment.

As a general rule of thumb, features will fall in the Ultimate/Gold tier when they meet one or more of the following criteria:

Some examples include:

Upcoming Releases

13.7 (2020-12-22)

13.8 (2021-01-22)

13.9 (2021-02-22)

13.10 (2021-03-22)

Other Interesting Items

There are a number of other issues that we've identified as being interesting that we are potentially thinking about, but do not currently have planned by setting a milestone for delivery. Some are good ideas we want to do, but don't yet know when; some we may never get around to, some may be replaced by another idea, and some are just waiting for that right spark of inspiration to turn them into something special.

Remember that at GitLab, everyone can contribute! This is one of our fundamental values and something we truly believe in, so if you have feedback on any of these items you're more than welcome to jump into the discussion. Our vision and product are truly something we build together!


Last Reviewed: 2020-03-17
Last Updated: 2020-03-17