Catch-up! 週刊 GitHub updates（2024年8月19日-25日）
GitHub Changelog for August 19 - 25, 2024
こんにちは、@dz_ こと、大平かづみです。
GitHub Changelogの週刊キャッチアップをお届けします。
コンテンツの除外（beta）でGit管理外のファイルもサポート
Git管理対象のファイルに加え、Git管理外のファイルへのCopilotからのアクセスを除外できるようになりました。この更新により、Copilotがアクセスできるコンテンツをより制御できるようになり、Organizationの所有者が除外と印をつけたファイルは、そのファイルがGitリポジトリの一部かそうでないかに関わらず、アクセスされません。
Git管理外のファイルを除外するには
Git管理外のファイルの除外がサポートされ、ワイルドカードによるスコープがGitリポジトリの内部または外部の両方を含むよう拡張されました。
以前
ワイルドカード ルールはGitリポジトリ内のファイルに限定的に適用されていました。たとえば:
"*":
- /test1 # => Blocks from the root of all git repositories: `/test1`
現在
ワイルドカード ルールはGitリポジトリ内とファイルシステムのファイルに適用されます。たとえば:
"*":
- /test1 # => Blocks from the root of all git repositories AND the filesystem root: `/test1`, `/test1`
注釈: コンテンツの除外（beta）に対するこれらの変更は、VS CodeとJetBrains Copilot拡張機能の両方において最新バージョンで適用され、コード補完とチャット機能にそれぞれ反映されます。
CodeQLプルリクエスト アラートに対する防御と自動修正のインサイト
新しいCodeQLプルリクエスト アラートのレポートでCodeQLプルリクエスト アラートの防御したメトリクスを追跡できるようになり、OrganizationとEnterpriseレベルの両方で利用可能です。これらのインサイトは、セキュリティ リスクがデフォルト ブランチに到達する前に能動的に識別して軽減するのを強力に支援します。
このレポートにより、フューチャー ブランチからデフォルトブランチにコードを移植するときのCodeQLプルリクエスト アラートに対するメトリクスを時系列で追跡できます。次の項目に対する洞察を高めましょう:
- 解決されていないマージされたアラート: どんなセキュリティ脆弱性がデフォルト ブランチに混入したか理解する
- 修正（自動修正および手動）: どのアラートがマージする前に解決されたか追跡する
- 取り消されたアラート: どのアラートが誤検出かリスクを受け入れると判断されたかを確認する
加えて、CodeQLルール、自動修正の状態やリポジトリによるメトリクスを解析します。
時系列のデータは2024年5月1日から利用できます。
これらのレポートにアクセスするには、GitHub.comの右上角にあるプロフィール写真をクリックし、閲覧したいOrganizationまたはEnterpriseを選択します。Organizationの場合、Securityタブを開き、サイドバーにあるCodeQL pull request alertsを探してください。Enterpriseの場合は、サイドバーにあるCode Securityをクリックし、CodeQL pull request alertsを選択してください。
これらのレポートはGitHub Enterprise Cloudで一般公開されており、GitHub Enterprise Server 3.15で利用可能になる予定です。
詳しくは、セキュリティの概要をご参照ください。ぜひGitHub Communityに参加してディスカッションしましょう。
GitHub Actionsランナーの廃止予定と破壊的な変更についてのお知らせ
GitHub Actionsでは、今後6ヶ月の間にに渡りランナーとサービスにおいて次の廃止と破壊的変更が行われる予定です。
Upload Artifactアクションが通常隠しファイルを除外するように
2024年9月2日より、upload-artifactアクションのv3、v4における通常のアップロードで隠しファイルやフォルダを含まなくなります。これにより、クレデンシャルが意図せずアーティファクトにアップロードされるリスクを軽減します。これらのファイルをアップロードする必要がある場合は、新しいオプションinclude-hidden-filesで引き続き利用可能です。
Ubuntu 20とUbuntu 22 arm64イメージ
2024年9月3日、arm64のホステッドランナーにおいて、Ubuntu 22/20ベースのイメージは広い範囲で使われておらずArmが提供する新しいイメージの利用が好ましいため、廃止されます。その時点から、arm64のUbuntu 22または20ベースのイメージを使用するすべてのワークフローは、失敗します。ランナーが使用するイメージを変更するには、失敗を避けるために、そのランナーを削除し、同じ名前でランナーを再作成してください。Armによって提供されるパートナー イメージを使用することをお勧めします:
- Ubuntu 24.04 by Arm Limited
- Ubuntu 22.04 by Arm Limited
ランナー内の.NET6の廃止
2024年10月、ActionsランナーをNode20へ移行すると同時に、Actionsランナー内のNET6を廃止し、。NET8に移行します。.NET6は2024年11月にサポートを終了するためです。サポートされないバイナリに依存しているオペレーティングシステムをまだ使用している顧客は、この変更の前にアップグレードする必要があります。.NET6のサポートの削除は、次のオペレーティングシステムがこの時点からサポートされなくなることを意味しています:
- Debian 10
- macOS 11.0
- macOS 10.15
Node16の削除に関する更新履歴でサポートされないとすでにマークされているものも含みます。
macOS12のランナー イメージ
来るmacOS 15の公開に向けて、フリートの収容能力のバランスをとるために、macOS 12のランナー イメージの廃止工程を開始しました。このイメージは2024年12月3日に完全に打ち切られます。ワークフローでmacos-14やmacos-13、macos-latestを使用するよう更新することをお勧めします。
サポートを終了するmacOSラベル
2024年12月3日、少数のワークフローで使用されている古くてあまり使われていないラベルのいくつかを廃止します。次のランナー ラベルはこの時点で使用できなくなります:
- macos-11.0
- macos-12-xl
- macos-13-xl
- macos-13-xl-arm64
- macos-latest-xl
- Macos-latest-xl-arm64
AnthropicがGitHubシークレット スキャンのパートナーに参加
[Anthropic]ユーザーに向けて、GitHubシークレット スキャンでAnthropicトークンがスキャンされるようになり、パブリック リポジトリをセキュアに保つのに役立ちます。Anthropicトークンは、Anthropic APIを介してClaudeにアクセスできるようにするものです。GitHubはパブリック リポジトリで見つかった漏洩したトークンをAnthropicに連携し、Anthropicでは損なわれたトークンを停止し影響のある利用者に通知します。詳しくは、Anthropicトークンに関する情報をご参照ください。
GitHubシークレット スキャンは、トークンやプライベート キーのような既知のシークレットの型をリポジトリから探し出し、利用者を保護します。それらのシークレットを識別し目印をつけることにより、スキャンはデータ漏洩や詐欺を防ぐのに役立ちます。
GitHub Advanced Securityの利用者は、プライベート リポジトリでもAnthropicトークンをスキャンしブロックできます。
詳しくは次をご参照ください。
シークレット スキャンのプロバイダー以外のパターンがセキュリティ構成に含まれるように
プロバイダー以外のパターン（一般的なパターン）がOrganizationレベルのセキュリティ構成を通じて有効化できるようになります。
また、プロバイダー以外のパターンは、2024年8月23日にGitHub で推奨されるセキュリティ構成にも含まれるようになります。この時点から、プロバイダー以外のパターンは、推奨される構成が適用されたリポジトリで自動的に有効化されます。
詳しくは、シークレット スキャンによるリポジトリの保護をご参照ください。
GitHub communityディスカッションにご参加いただき、または60分のフィードバックセッションにご登録いただき、ご意見を共有ください。
シークレット スキャンでプロバイダー以外のパターンの重複排除
より効果的にシークレットの漏洩を選別したり修正したりするのを支援するために、GitHubシークレット スキャンはプロバイダーパターンに対してプロバイダー以外のパターン（一般的なパターン）の重複を排除するようになります。
シークレット スキャンのプロバイダー以外のパターンは、HTTP認証ヘッダ―や接続文字列、秘密鍵のような特定のトークン発行者に紐づくパターン以外のシークレットを発見する汎用的な検出器です。
注釈: カスタム パターンを削除するとそれらにアラートも削除してしまうため、カスタム パターンの重複は排除されません。GitHubが定義する検出器と被らないようにカスタム パターンを調整することをお勧めします。
詳細は
詳しくは、シークレット スキャンでリポジトリをセキュアに保つをご参照ください。GitHub communityディスカッションにご参加いただくか、60分のフィードバック セッションにご登録いただき、ぜひご意見をお聞かせください。
シークレット スキャンのプロバイダー以外のパターンが推奨されるセキュリティ構成に含まれるように
これより、シークレット スキャンのプロバイダー以外のパターンが「GitHub-recommended security configuration」に含まれるようになりました。また、プロバイダー以外のパターンは、recommended configurationを以前に適用したリポジトリにおいて、自動的に有効化されます。
シークレット スキャンのプロバイダー以外のパターンは、HTTP認証ヘッダ―や接続文字列、秘密鍵のような特定のトークン発行者に紐づくパターン以外のシークレットを発見する汎用的な検出器です。
詳細は
詳しくは、シークレット スキャンでリポジトリをセキュアに保つをご参照ください。GitHub communityディスカッションにご参加いただくか、60分のフィードバック セッションにご登録いただき、ぜひご意見をお聞かせください。
App APIのレスポンスにクライアントIDが含まれるように
GitHub Appを示すすべてのAPIレスポンスにclient_idフィールドが含まれるようになります。クライアントIDが全世界で一意であることに対し、アプリケーションIDや名前はそうでないため、クライアントIDをアプリの第一の識別子として使用するよう移行します。
これまでの経緯として、GitHubはAPIでapp_name（すなわちスラグ）やapp_id（データベースID）をアプリケーションを識別するために使っていました。しかし、アプリ名は不変でなく、アプリIDは全世界で一意であることが満たされていません。GitHubでは、名前やデータベースIDの代わりにclient_idをアプリケーションの第一識別子として使用するよう、アプリケーションに関連するAPIを段階的に更新します - この最初の対応はJWTの生成においてインストレーション トークンのためにクライアントIDの利用を対応したことでした。
この変更は、Enterpriseにおいてアプリケーションをプログラマブルに管理できる公開予定の機能のために準備しています。この追加のデータは、関心のあるアプリケーションのクライアントIDを見つけやすくなります。
アプリケーションの情報を取得する方法について、詳しくはREST APIドキュメントをご参照ください。
Discussion