業務で使う場合は、GitHubのPersonal Access Tokenをどう扱うかは気を付ける必要があります。Libraryに保存しちゃうと意図しないPipelineで使われてしまうリスクがあるので、どうすると良いですかね？
という疑問が末尾に書かれていたので、どうするのがいいか考えてみましょう。まず、大前提として、GitHubのPATをLibraryに格納する場合、GitHubのPATにアクセスできる人だけをAdministratorにしておきます。
PAT単位にセキュリティを設定する場合はPATを作ったユーザーのみadministratorにします。デフォルトはLibraryからの継承なので、都合が悪い場合は継承を切ってください。ただし、Build Serviceアカウントを削除してしまうとビルドエージェントがLibraryを参照できなくなるので気を付けてください。
Libraryのセキュリティでも設定できます。通常はLibraryを管理するユーザーを決めておきましょう。Build AdministratorかProject Administratorのみ管理者なので大体大丈夫のはずです。
記事内で心配されていた「知らないpipelineに使われる」というのはservice connectionの権限で防ぎます。https://dev.azure.com/{organization}/{project}/_settings/adminservices画面でGitHubのへの接続を作っています。
Approvers and ChecksはEnvironmentと同じ設定ができます。典型的にはBusiness Hourだけ使えるようにするとかそういった制御ができます。
下のSecurityをクリックすると、画面の真ん中にPipeline permissionがあるので、そこでGitHubへの接続を使えるパイプラインを明示的に指定します。
これで仮にLibraryの値を意図しないパイプラインで参照されたとしても、GitHubへのアクセスができなくなります。
いちいちプロジェクトごとにそんな設定するのめんどいなぁ、という場合、その下にあるProject Permissionからこのservice connectionが使用可能なプロジェクトを指定します。
ここで指定されたプロジェクトはこのGitHubへの接続が使用可能になります。大きなプロジェクトではチームプロジェクト単位でservice connectionを作るのではなく、特定のプロジェクトに集中させて、ほかではこういった外部接続を使わないようにすれば集中管理が可能になります。
