Sec セクション

Sec セクションは、GitLab DevOps プラットフォームの Secure および Software Supply Chain Security 機能に取り組む開発チームで構成されています。

チームとハンドブックページ

以下のチームがこのサブ部門を構成しています:

Software Supply Chain Security ステージ - ハンドブック
- Anti-abuse グループ - ハンドブック
- Authentication グループ - ハンドブック
- Authorization グループ - ハンドブック
- Compliance グループ - ハンドブック
Application Security Testing ステージ - ハンドブック
- Composition Analysis グループ - ハンドブック
- Dynamic Analysis グループ - ハンドブック
- Static Analysis グループ - ハンドブック
- Secret Detection グループ - ハンドブック
- Vulnerability Research グループ - ハンドブック
- API Security - ハンドブック
Security Risk Management
- Security Policies グループ - ハンドブック
- Security Platform Management グループ
- Security Insights グループ - ハンドブック
- Security Infrastructure グループ - ハンドブック

機能ごとに EM と PM の DRI を明確にすることが重要です。特に明らかでない場合はなおさらです。これは専用の境界定義ページに文書化されています。

AI プロンプト

プロダクト方向性

プロダクト方向性は Sec Section Product Direction ハンドブックページで確認できます。

Sec セクションリソース

以下のリソースは、Sec セクションのチーム全体で共通する開発パターンのガイダンスを提供しています:

オブザーバビリティ

チュートリアル: CI ベースのアナライザーにオブザーバビリティメトリクスを追加する - セキュリティアナライザーに分散イベントパターンを実装するためのステップバイステップガイド。
Secret Detection メトリクス - Secret Detection アナライザーと GitLab モノリスにメトリクスを追加するためのガイド。

プロジェクト設定

プロジェクトを整理しておくことは、生産性と保守性のために非常に重要です。

新しいプロジェクトのセットアップは会社全体のエンジニアリングガイドラインに従います。
Sec プロジェクトは以下のいずれかに整理してください:

一般的に、security-products に置くプロジェクト数はできるだけ少なくしたいと考えています。

security-products には以下のみを含めるべきです:

顧客インストールの一部として実行されるアプリケーションのソースコード
デモ
移動が難しい歴史的なプロジェクト

secure と software-supply-chain-security には以下のプロジェクトを置くべきです:

エンドツーエンドテスト
ベンチマーク / 統計
ツール類

技術的な理由により secure または software-supply-chain-security に置くべきだが security-products の方がずっと簡単なプロジェクトがある場合があります。そのような場合、secure または software-supply-chain-security への配置を合理的な努力で試みたが失敗した場合、security-products に置くことができます。

推奨設定

新しいプロジェクトを作成する際、以下の secure ステージ固有の設定を除き、すべての設定はデフォルトのままにしてください:

プロジェクトに CODEOWNERS ファイルを追加します。例:
```
[Maintainers]
* @gitlab-org/maintainers/container-scanning

^[Reviewers]
* @gitlab-org/secure/static-analysis
```
CODEOWNERS ファイルで使用するための専用メンテナーグループを作成することをお勧めします。
プロジェクトの Issue トラッカーを無効にします。
- Settings -> General -> Visibility, project features, permissions -> Issues
  - Disabled
Issue は代わりに groups/gitlab-org Issue トラッカーで作成してください。これを設定するには以下の手順 3. を参照してください。
プロジェクトごとの Issue トラッカーではなく、単一の集中型 Issue トラッカーを使用することには以下のメリットがあります:
- Issue の可視性が向上し、私たちの透明性の価値観と一致します。
  たとえば、コミュニティメンバーが groups/gitlab-org トラッカーの Issue をフィルタリングして、より広いコミュニティからの貢献を求める GitLab Issues を発見することが非常に簡単になります。
- triage-ops やその他のボットを追加設定なしで Issue に対して実行できるなど、既存のツールとインフラが活用されます。
- すべてのラベルと Issue テンプレートが同じになるため、より一貫した体験が提供されます。
- セキュリティトリアージ自動化ツールを使って脆弱性を作成/変更するなど、自動化スクリプトを書くのが簡単になります。
- 複数のプロジェクトに適用される Issue がいくつかあります。各プロジェクトが独自の Issue トラッカーを持っている場合、複数のプロジェクトに適用する Issue をどのトラッカーが「所有」すべきかを決める必要が出てきます。
ただし、単一の集中型 Issue トラッカーの使用に関しては現在いくつかの制限があります。たとえば新しい Issue でのスレッド解決が機能しないなどです。
この Issue が解決されるまで、新しいプロジェクトで Issue トラッカーを有効のままにすることを選択できます。
その場合は、放棄された Issue を避けるために以下を検討してください:
1. トラッカーを非公開にする。
2. 手順を記載した Issue テンプレートを追加する。
3. トリアージプロセスが整っていることを確認する。
カスタム Issue トラッカーを設定します
- Settings -> Integrations -> Custom issue tracker -> Configure
  - Enable integration
    - Active
  - Project URL
    - https://gitlab.com/gitlab-org/gitlab/issues
  - Issue URL
    - https://gitlab.com/gitlab-org/gitlab/issues/:id
  - New issue URL
    - https://gitlab.com/gitlab-org/gitlab/issues/new

以下のプロジェクト機能と権限設定を構成します:

Settings -> General -> Visibility, project features, permissions
- Project visibility
  - Public
- Additional options
  - Users can request access
    - Disabled
- Container Registry
  - Only Project Members
Settings -> Repository -> Protected branches
- Allowed to merge
  - Maintainers
- Allowed to push and merge
  - No one
- Allowed to force push
  - Disabled
- Code owner approval
  - Enabled
Settings -> Repository -> Protected tags
- Tag
  - v*
- Allowed to create
  - Maintainers
  - GitLab Dev Service - Secure Stage - Analyzers Automation

Settings -> Merge Requests

Squash commits when merging
- Require
Approval settings
- Prevent approval by author
- Prevent editing approval rules in merge requests
- Remove approvals by Code Owners if their files changed
Merge request approvals -> Approval rules
- Approvers
  - All eligible users
- Target branch
  - All branches
- Approvals required
  - 1
Merge checks
- All threads must be resolved
- Pipelines must succeed

Merge commit message template

Merge branch '%{source_branch}' into '%{target_branch}'

%{title}

%{issues}

See merge request %{url}

Merged-by: %{merged_by}
%{approved_by}
%{reviewed_by}
%{co_authored_by}

Default description template for merge requests

## What does this MR do?

<!--
Describe in detail what your merge request does, why it does that, etc.

Please also keep this description up-to-date with any discussion that takes
place so that reviewers can understand your intent. This is especially
important if they didn't participate in the discussion.

Make sure to remove this comment when you are done.
-->

## What are the relevant issue numbers?

## Does this MR meet the acceptance criteria?

- [ ] Changelog entry added
- [ ] [Documentation created/updated for GitLab EE](https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html), if necessary
- [ ] Documentation created/updated for this project, if necessary
- [ ] Documentation reviewed by technical writer *or* follow-up review issue [created](https://gitlab.com/gitlab-org/gitlab-ee/issues/new?issuable_template=Doc%20Review)
- [ ] [Tests added for this feature/bug](https://docs.gitlab.com/ee/development/testing_guide/index.html)
- [ ] Job definition updated, if necessary
  - [ ] [Auto-DevOps template](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/lib/gitlab/ci/templates)
  - [ ] [Job definition example](https://docs.gitlab.com/ee/ci/examples/sast.html)
  - [ ] [CI Templates](https://gitlab.com/gitlab-org/security-products/ci-templates/tree/master/includes)
- [ ] Ensure the report version [matches the equivalent schema version](https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/blob/master/CHANGELOG.md)
- [ ] Conforms to the [code review guidelines](https://docs.gitlab.com/ee/development/code_review.html)
- [ ] Conforms to the [Go guidelines](https://docs.gitlab.com/ee/development/go_guide/index.html)
- [ ] Security reports checked/validated by reviewer

/label ~"devops::secure" ~"Category:" ~"group::" ~"backend"

secure ステージ以外のプロジェクトを設定する場合は、GitLab Projects ベースライン要件を参照してください。

パフォーマンスインジケーター

Sec サブ部門パフォーマンスインジケーター
エラーバジェット（ステージグループのパフォーマンスインジケーターとして）

Slack チャンネル

#sec-section - Software Supply Chain Security と Secure ステージにまたがる Sec セクションの議論。
#sec-growth-datascience-people-leaders - Sec、Growth、ModelOps のエンジニアリングピープルリーダー向け。
🔒sec-growth-datascience-leadership-confidential - Sec、Growth、ModelOps のエンジニアリングピープルリーダー向けプライベートチャンネル。

カレンダー

私たちにはステージレベルのカレンダーが 3 つあります。AST Stage Calendar、SRM Stage Calendar、SCSS Stage Calendar では、以下のようなクロスグループイベントを開催しています:

月次レトロスペクティブ
コーヒーチャット
スタッフ同期

各グループにも、週次グループ同期などのチームベースの議論のためのカレンダーがあります。

可能な限り、個人を参加者として追加する代わりに、利用可能な Google グループを活用することをお勧めします。イベントが個人のカレンダーに表示されるようにするとともに、新チームメンバーはイベントに自動的に追加され（チームを離れた場合は自動的に削除）されます。

Google グループ

Google グループは [section]-[stage]-[group] という命名規則に従い、複数単語の名前は _ で区切ります:

sec-section
sec-software_supply_chain_security
sec-security_risk_management
sec-application_security_testing
sec-security_risk_management-security_insights
sec-security_risk_management-security_policies
sec-security_risk_management-security_platform_management
sec-security_risk_management-security_infrastructure
sec-application_security_testing-static_analysis
sec-application_security_testing-secret_detection
sec-application_security_testing-dynamic_analysis
sec-application_security_testing-composition_analysis
sec-software_supply_chain_security-authentication
sec-software_supply_chain_security-authorization
sec-software_supply_chain_security-compliance
sec-software_supply_chain_security-pipeline_security
vulnerability-research

各 Google グループのメンバーは、安定したカウンターパートと適切な eng-dev-[stage]-[group] エンジニアグループで構成されます。安定したカウンターパートが変わったり、チームメンバーが入退社した場合は、それぞれのグループの EM が適切なグループを更新してください。

情報収集とチームメンバーへの情報共有

Sec Week In Review Google ドキュメント - Sec で起きている注目すべきことを非同期でまとめた週次ドキュメントです。Engineering Week In Review にヒントを得ています。
Slack チャンネル #s_secure と #s_software-supply-chain-security は Sec セクション全体の一部であり、有益な情報源です。

セクション内の計画

大多数の場合、作業はセクション内の個別グループにスコープされています。ただし、セクションとして協調して設計・実行しなければ、質の低い一貫性のないユーザー体験を生み出してしまうリスクがある場合があります。

これらのイニシアチブは、エピックと Issue を通じて調整されます。以下のラベルが付いたイニシアチブは、この種の作業に該当すると判断されます。

~section::sec と ~group::not owned; または
all Sec groups

セクション全体のイニシアチブの計画プロセス

少なくとも 1 マイルストーンにつき 1 回、セクションのシニアエンジニアリングマネージャーは以下を行います:

プロダクトマネジメントと連携して、6 ヶ月以上経過したイニシアチブの関連性を評価します。
新しいイニシアチブをトリアージし、要件の理解可能性と完全性を確認します。さらに、最も影響を受けるグループを特定します。
- 最も影響を受けるグループが明確でない状況では、#sec-section のテクニカルリーダーシップに協力を求め、どのグループかを判断します。
最も影響を受けるグループがそのイニシアチブの DRI として宣言され、以下が期待されます:
- 問題全体にスケールする高レベルの実装計画を作成する。
- 機能カテゴリ別に分解した実装 Issue を作成する。
  - 元の高レベル実装計画は、作成された Issue に含めるか、少なくとも直接リンクする。
  - 実装計画が議論・作成された元の Issue も生成された Issue にリンクする。
- 実装 Issue を関連グループに配布する。

生成された Issue は、個別グループに配布された時点で通常の優先順位付けプロセスを通じて処理されます。

ページパフォーマンス

私たちのチームは LCP（Largest Contentful Paint）を監視して、パフォーマンスが目標（現在 2500ms）を下回ることを確認しています。

Secure が所有するページの LCP ダッシュボード

プロダクトデザインとの連携

エンジニアリングとプロダクトデザインチームの間のワークフローを効率化し、効果的なコラボレーションを確保するために、マージリクエスト（MR）レビューにおける UX 関与について以下のガイドラインを確立しています:

マージリクエスト UX レビュー要件:

UX レビューは、プロダクトデザイナーが明示的に設計した作業に対してのみ必要であり、そのプロダクトデザイナーによってレビューされるべきです。
プロダクトデザイナーが明示的に設計した作業を含まない MR は UX Tech Debt としてラベル付けし、UX レビューなしでマージできます。

優先度の高い UX レビューの対応:

マイルストーン計画プロセスで計画されていなかった高優先度のタスクが発生し、UX レビューが必要な場合は、Sec のプロダクトデザインマネージャーと相談してください。
この予期しない作業に対応するため、元のマイルストーン計画から別のタスクの優先度を下げるか削除する必要があります。

例外:

これらの新しいガイドラインは、Authentication、Authorization、Pipeline Security グループには適用されず、これらのグループは現在のプロセスで引き続き運用します。

カスタマーサポートとの連携

Sec エンジニアリングチームは顧客に直接サポートを提供しません。代わりに、エンジニアは Sec サブ部門サポートプロジェクトのプロセスを通じてカスタマーサポートエンジニアと協力します。

セキュリティツールリクエストへの対応

GitLab が成長するにつれ、Sec チームは最大規模の顧客のユーザー管理をより安全に行うツールを構築し続けています。その過程で、GitLab.com 上でのチームメンバー管理は、ユーザーに展開する前に機能を内部でドッグフーディングできる優れたユースケースです。Security チームと CorpSec チームは、security tooling、section::sec、および優先度 priority::1/2/3 ラベルを追加して、GitLab チームメンバーの管理に役立つ項目をバックログに追加する必要があることを示すことができます。機能ページは、特定の機能がどこに属するかを特定するのに便利で、グループの正しい EM/PM を Issue でタグ付けできます。

これらの Issue のバックログは、個別の Issue については Sec Security Tooling - issue で確認できます。毎月、プロダクトとセキュリティのカウンターパートがこれらのリクエストをレビューし、優先度の高い項目がロードマップに組み込まれるようにします。

品質チームとの連携方法

フロントエンドの責任

どのコード変更が E2E またはシステムレベルのテストを壊す可能性があるかを識別し、品質チームに通知すること。
E2E テストを書くことではなく、潜在的な失敗をキャッチし、マスターにマージされる前のカバレッジのギャップをコミュニケーションすること。

潜在的な破損の識別

作業している Issue に既存のテストカバレッジがあるか確認します。これらが失敗する可能性があるテストです。
data-qa-selector="<name>" のようなセレクターを含むコードの周辺で作業している場合、既存の E2E テストが存在する可能性があります。テストは Secure の E2E テストを検索することで見つけられます。

テストを壊す可能性がある変更のコミュニケーション

Secure に割り当てられた品質 DRI に ping してください。その人はチームページで確認できます。対応できない場合は、重大度に応じて Slack の #s_developer_experience またはトリアージ DRI に連絡してください。

セクションレトロスペクティブ

グループレトロスペクティブに加えて、毎月非同期で Sec セクションレベルのレトロスペクティブを行っています。セクション全体のレトロスペクティブの目的は、グループ/チームのレトロスペクティブから浮かび上がったトピックをレビューすることです。さらに、同期的に議論できるテーマを特定します。セクションレトロスペクティブを行うために、このドキュメントとこのテンプレートで作成した Issue を使用しています。

主要な日程

月次リリースの翌月曜日 - グループの非同期レトロスペクティブ Issue が生成されます。グループはトピックの追加を始めるべきです。
マイルストーンが終わる週 - グループがレトロスペクティブを開催します。チームメンバーは特定されたトピックとフォローアップ項目（成果）をセクションレトロスペクティブドキュメントに集約します。
リリースの週 - セクション全体のレトロスペクティブの非同期レビューが #sec-section Slack チャンネルで共有されます。

DRI の責務

セクション全体のレトロスペクティブの DRI はシニアエンジニアリングマネージャーです。SEM は特定のマイルストーンで必要な場合にボランティアを募ります。各マイルストーンで以下のタスクが実行されます:

非同期セクションレトロスペクティブの前に、集約されたトピックをレビューし、非同期議論のテーマを 2〜3 個特定します。
#sec-section の Slack でセクション全体にセクションレトロスペクティブドキュメントをレビューしてコメントを追加するよう呼びかけます。
Slack の #sec-section で非同期議論のサマリーを共有します。
特定された改善点についてグループにフォローアップします。
積極的に宣伝・促進します！

ページのソースコードを見る - ページの編集 - please contribute.