機密レベル

デフォルトで公開

GitLab ではデフォルトで公開していますが、一部の情報は内部または限定アクセスに分類されます。このページでは機密レベルの詳細を説明します。

非公開

透明性が私たちのバリューの 1 つであるため、私たちはデフォルトで物事を公開しています。 一部のものは公開できず、会社にとって内部であるか、会社内でも限定アクセスが設定されています。 以下のセクションに記載されていない場合は、追加のガイダンスについてセキュリティのデータ分類基準と法務のSAFE フレームワークをハンドブックで参照してください。

内部

一部のものは GitLab チームメンバー限定の内部向け情報です。チームメンバーのみがアクセスできるが、そうでなければ公開ハンドブックに含まれるトピックについては、この情報を GitLab の内部ハンドブックに追加する必要があります。内部ハンドブックの背景は公開ハンドブックで確認できます。公開ハンドブックまたは内部と公開のハンドブックをまとめて「ハンドブック」と呼んでも問題ありません。内部ハンドブックは常に「内部ハンドブック」と呼ぶ必要があります。

以下の項目は内部向けです：

1. セキュリティや悪用の脆弱性は、攻撃者が GitLab インストールを侵害することができるため公開されません。脆弱性を修正した後に公開します。意図したとおりに機能している実装のセキュリティ体制の改善方法を議論する Issue は公開でき、多くの場合、機能提案としてラベル付けされます。悪意ある活動を検出するセキュリティや悪用の実装は、公開することで業務が損なわれるため公開できません。
2. 収益やコストを含む財務情報は機密です。GitLab は上場企業であり、投資家が GitLab 株を取引する際に財務情報を使用・依拠するため、財務情報のタイミングと内容の両方を制限する必要があります。利益の算出の最初のステップとなるものは機密に保つ必要があります。例：
   • 案件の特定の IACV
   • GitLab.com の月次総現金流入/流出
   • 10% 以上の支出
   • 部門のコスト
   • チームメンバー定着率（アナリストがビジネス上の仮定をする可能性がある）
   • セールスパイプライン
   • ネットおよびグロス定着率 KPI。実際の数値のみが非公開です。目標や計算方法などその他の詳細は公開できます。
3. 財務情報に関するすべての外部コミュニケーションは、会社のSAFE ガイドラインとソーシャルメディアポリシーに沿っている必要があります。ご質問があれば、Slack の#Safe チャンネルからお問い合わせください。
4. 契約や請求書の承認・支払いなどの外部当事者との取引。
5. プライバシー規約で定義された GitLab チームメンバー、顧客、またはユーザーの個人データを侵害するコンテンツ。侵害するコンテンツの例：個人（GitLab 付与でない）の連絡先情報、位置データ、オンライン識別子、雇用情報、政府 ID、財務情報、または健康、宗教、人種/民族、政治的地位、または性的指向に関連する機密データ要素。
6. 法的議論は弁護士・依頼人特権の目的から公開されません。
7. 競合他社が対応できる時間を最小化したいため、競合相手の販売やマーケティングキャンペーン計画は機密です。
8. 居住地に関する決定が含まれる議論は、プライバシーおよび雇用上の考慮から公開されません。そのような決定の結果（国別採用ガイドラインなど）は公開されます。
9. 公開情報が 1 人以上のチームメンバーの身体的安全を損なう場合、チームメンバーにとって安全でインクルーシブな環境を作ることが重要なため、非公開となります。
10. 報道規制に関連する情報、または外部コミュニケーションチームが対応を管理する予定の出版物に関連する情報。
11. 他者の著作権 IP に依存する情報。
12. 情報の早期共有が購入を遅らせる可能性がある初期的な探索イニシアチブに関連する情報。
13. 非常に高い需要が見込まれる製品オファリングが開発中の場合、チームが適切なソリューションを作成する時間を確保するために内部に留める必要があります。
14. GitLab.com の無料ティアの制限（ストレージ、データ転送、ユーザー制限、コンピュート時間など）の変更は公開されません。下記の限定アクセスで説明する価格・パッケージと類似しているためです。
15. スコアリングルーブリックや基準などの採用プロセスに関する具体的な詳細は公開されません。候補者が基準に合わせて回答を誇張しないよう確保したいためです。高レベルの面接計画は公開されており、各職務記述書に文書化されています。
16. GitLab の戦略は内部向けです。GitLab の目標設定は意図的に野心的です。コンテキストのない外部の人々が会社の財務健全性と戦略計画について誤解する可能性があるため、この情報を共有することで意図せず望ましくない影響が生じる場合があります。
17. 特許出願の発見段階の対象となる議論、設計、コード。出願前の製品とプロトタイプ開発はすべて公開リポジトリ外で行う必要があります。

限定アクセス

以下の項目はすべてのチームメンバーと共有されません。限定アクセスは内部向けよりも厳しい制限です。

1. 契約や請求書の承認・支払いなどの外部当事者との取引。
2. GitLab チームメンバー、顧客、またはユーザーの機密性を侵害するコンテンツ。
3. 顧客情報は一般的に機密保護義務と競合他社によるそのような情報の問題のある使用のため公開されません。Issue に顧客について、社名、従業員名、ユーザー数などのいずれかの特定の情報が含まれる必要がある場合、その Issue は機密にする必要があります。
4. 組織再編の計画。組織再編は混乱を引き起こす可能性があり、組織再編計画は最終確定前に大幅に変更される傾向があります。可能な限り関連するチームメンバーに通知します。
5. 計画された価格変更。組織再編と同様に、価格変更に関する計画は最終確定前に変更される可能性があります。したがって、価格変更は開発中は限定アクセスです。
6. 会社のポリシーやプロセスの変更に関連する特定の議論。組織ポリシーの中にはセンシティブな性質を持ち、コミュニケーションがなされる前に慎重な検討が必要なものがあります。
7. 法的議論は弁護士・依頼人特権の目的で制限されており、一部は内部向けではなく限定アクセスの場合があります。
8. 一部の情報は、チームメンバーや申請者のプライバシー・安全・セキュリティを保護するために People グループが機密に保ちます。求人応募、バックグラウンドチェックレポート、推薦状確認、報酬、退職の詳細、人口統計情報（年齢と生年月日、家族または婚姻状況、パスポート詳細や税 ID などの国民識別、必要な便宜）、自宅住所などが含まれます。内部告発者の身元も機密です。業績改善計画、懲戒処分、個別フィードバックは制限されており、ネガティブなフィードバックは 1 対 1 でマネージャーとの間で行うためです。ただし、People グループのポリシーとプロセスは公開されています。
9. GitLab によるまたは GitLab への買収オファー。
10. 報酬変更：GitLab はトータルリワード（報酬、株式、福利厚生）へのイテレーションの結果をチームメンバーに伝達・研修しますが、チームメンバーは報酬変更のインプットと意思決定プロセスには関与できません。
11. セキュリティインシデント調査：MNPI へのチームメンバーの露出を避けるため、セキュリティインシデント対応チーム（SIRT）はインシデントの重要性を評価するために必要な人だけへのアクセスを制限します。インシデントが MNPI を持たないと判断されたら、アクセスは内部向けに変更される場合があります。

プロジェクト名

一部のプロジェクトは、上記のリストに含まれる項目に関連するプロジェクトを含むがこれに限定されない、プロジェクトの機密または敏感な性質から内部でも限定アクセスが必要です。多くの場合、これらのタイプのイニシアチブの必要な機密性を維持するために、プロジェクトのコードネームを割り当てます。一貫性を保ち、これらのプロジェクトの起源と組織の所属を特定しやすくするために、以下の命名規則を確立しました。

プロジェクトコードネームは過剰に使用される可能性があります。コードネームは、プロジェクト名の漏洩（関連コンテンツへのアクセスなしでも）が問題となるプロジェクトにのみ使用すべきです。プロジェクトを明確に説明する名前の代わりにコードネームを使用すべき 2 つのケースがあります：

1. プロジェクトの存在が重要な非公開情報（MNPI）である場合。例：「Gotham」は IPO のプロジェクト名でした。GitLab が IPO の差し迫りを早期にシグナルすることで制裁を受けることになるからです。
2. プロジェクトや取り組みの認識が MNPI ではないが、チームメンバー、顧客、またはより広いコミュニティに情報を早期に共有することを避けるために限定アクセスに留めるべき場合。例：「Tiering」は End of Availability のプロジェクト名、「Hamster」は中国への参入探索のプロジェクト名でした。

多くの場合、主要なプロジェクトやイニシアチブのコンテンツは MNPI または限定アクセスですが、コードネームは使用しません。これらの場合、誰が何に取り組んでいるかの感覚を持つことは許容されますが、正確な詳細はセンシティブです。例：

1. Q3 決算：資料は正式に共有されるまで MNPI ですが、これに取り組むチームメンバーは既知であり期待されており、センシティブな情報ではありません。
2. 価格・パッケージ：一例として、正確な計画が限定アクセスに保たれていても、P&P の変更を検討するグループがあると言うことは問題ありません。

プロジェクトの存在が限定アクセスまたは MNPI の理由でアクセスを制限する必要がなくなったら、プロジェクトのコードネームを廃止すべきです。プロジェクトが公開されたとみなされる（つまり機密でない）ためにプロモーション（ブログ記事の公開など）は必要ありません。GitLab の外部ハンドブックに情報を公開すれば十分です。コードネームがまだ必要かどうか不明な場合は、プロジェクトの DRI または Legal チームに #safe Slack チャンネル経由でお問い合わせください。

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