リリース認定
リリース認定プロセス
JiHu コントリビューションを含むすべてのリリースは、Federal Application Security チームのメンバーが認定する必要があります。 これは PubSec/FedRamp 要件を満たし、GitLab Inc リポジトリへの JiHu のマージリクエストコントリビューションを処理するために必要です。
このプロセスでは、リリースに含まれる各 JiHu コントリビューションがApplication Security チームメンバーによってレビューおよび承認されていることを確認し、リリースされるコードに新しい脆弱性が確認されていないことを関連リリースタスク Issue にコメントとして投稿することが含まれます。
リリースを認定できる担当者
PubSec/FedRamp 要件により、米国市民のみが米国領内でリリースを認定できます。 つまり、Federal AppSec チームのメンバーのみがリリースの認定を実施できます。 なお、Application Security チームのすべてのメンバーが JiHu コントリビューションをレビューおよび承認できますが、リリースを認定できるのは Federal AppSec チームのメンバーのみです。
Federal AppSec チームのメンバーは月次リリースの認定に責任を持ちます。担当は自動化によって管理されます。これらの割り当ては、AppSec リリース認定列の下にあるリリースマネージャーページにも反映される必要があります。
認定プロセス
認定プロセスは、新しい JiHu コントリビューションがリリースに含まれないことが完全に確実になってから開始できます。開始する推奨タイミングは、「新しいコードはリリースに追加できない」と指定されるリリースタスクの リリース前日 セクションです。
新しい JiHu コントリビューションが追加されないことが確実になったら、以下の手順に従ってください：
- 毎月のリリース日に、jh-upstream-report リポジトリがスケジュールされたパイプラインを実行し、リリース認定 Issue を自動的に作成します。これにより、次のリリースに関連する各 JiHu コントリビューションを含むチェックリストを持つ Issue が jh-upstream-report Issue トラッカーに作成されます。問題が発生した場合は、リリース認定ツールスクリプトを
README.mdの指示に従って手動で実行する必要がある場合があります - リリースに含まれるすべての JiHu コントリビューションがこのリストにあることを確認します。各リポジトリの
JiHu Contributionラベルを検索することに加え、ステータスレポートリポジトリ情報を確認することで実施できます（認定 Issue にリンクが用意されているはずです）。オープンとクローズ両方のマージリクエストを確認してください。MR がリリースに含まれているがチェックリストにない最も可能性の高い理由は、適切なマイルストーンが設定されていないことです - チェックリストの各 JiHu コントリビューションについて：
- マージリクエストを確認して、AppSec レビュアーがレビューを行い受け入れ可能であることを示しているか確認する
- マージリクエストが Application Security レビューを受けていない場合は、レビューを実施して適切なラベルを適用する
- マージリクエストが Application Security レビューを受けていない場合は、マージした担当者にマージ前に Application Security チームがレビューするべきであることを丁寧に伝えることを検討する
- レビューが行われたが実施されたことを示すラベルが適用されなかった場合がある——その場合はマージリクエストにラベルを追加する
- 一部のマージリクエストはまだ
Opened状態にあります。これはリリースの一部ではないが、そのリリースマイルストーンに関連付けられていることを意味します——この場合、チェックボックスにチェックを入れるだけで構いません - 時間が許せば、変更を簡単にレビューして受け入れ可能であることを再確認する
- リリース認定 Issue の対応するチェックボックスをオンにして、MR が受け入れ可能であることが確認されたことを示す
- 手動レビューが必要なリポジトリのセクションがあります。通常、自動化がプライベートリポジトリやマージリクエストセクションがプライベートに設定されているリポジトリを参照できないプロジェクトアクセストークンを使用しているため、これらのリポジトリを自動化に含めることができません。これらの各リポジトリについて：
- 各リポジトリのマージリクエストセクションを参照して、マージされた JiHu コントリビューションを探す
- これらのマージリクエストはマイルストーンや特定のリリースに関連付けられていない場合があるため、マージ済みのマージリクエストを「マージ日」で並び替えて、過去1か月の JiHu コントリビューションを探す必要がある場合があることに注意する
- リストされているリポジトリの一部には、レビューを実施する際に考慮すべき情報のメモが記載されている場合がある
- JiHu コントリビューションが見つかった場合は、デフォルトの
JiHu contribution merge requests were included しないチェックボックスを削除し、見つかった各 JiHu コントリビューションのチェックボックスを追加する - JiHu コントリビューションが見つからない場合は、
JiHu contribution merge requests were included しないチェックボックスにチェックを入れる - リポジトリの JiHu コントリビューションのレビューが完了したら、そのリポジトリのレビューが完了したことを示すために
このリポジトリは手動でレビューされましたチェックボックスにチェックを入れる
- リリース内のすべての JiHu コントリビューションが AppSec チームメンバーによってレビューされたことが完全に確実になったら：
- リリース認定 Issue の下部に生成された定型コメントをコピーしてリリースタスク Issue にコメントとして貼り付ける
- リリース認定 Issue にプロセスが完了したことを示すコメントをして、リリースタスク Issue に投稿した認定コメントへのリンクを記載する
- リリース認定 Issue をクローズする
脆弱性を導入するコントリビューション
コントリビューションのいずれかに S1 または S2 の潜在的な脆弱性が確認された場合：
- リリース認定 Issue に MR へのリンクと脆弱性の説明のコメントを投稿する
#security_helpSlack チャンネルにコメントへのリンクを含むメッセージを投稿する- デリバリーチームの適切なリリースマネージャーにピングして、MR をリリースから削除するよう協力する
- 脆弱性のあるコードが削除された場合は、認定プロセスを続行する
- 脆弱性のあるコードが削除できない場合は、以下の
リリースを認定できない場合の手順に従う
リリースを認定できない場合
まれな状況で、Federal AppSec チームのメンバーがリリースを認定しないことを選択する場合があります。これは、既知の脆弱性がリリースに含まれており削除できない場合、またはその他の状況（さらに例は TBD）が理由となる場合があります。
リリースを認定できないイベントが発生した場合：
- リリース認定 Issue に、リリースを認定しないことを選択した理由を簡潔に説明するコメントを書く
- リリース認定 Issue で上記コメントへの返信として、セキュリティリーダーシップ（
@juliedavilaと@jritchey）にピングする #security_helpSlack チャンネルでリリースを認定できないことを発表し、リリース認定 Issue へのリンクを投稿し、@appsec-leadershipを @-メンションする
