📌

Catch-up! 週刊 GitHub updates（2024年3月18日-24日）

2024/03/25に公開

GitHub

tech

GitHub Changelog for Mar 18 - 24, 2024

こんにちは、@dz_ こと、岩永かづみです。

先週のGitHub Changelogの週刊キャッチアップをお届けします。

Dependabot security updatesにおいて、対象のブランチが特定される場合においてもプライベートレジストリに対して動作するように

以前は、dependabot.ymlファイルで所有しているプライベートレジストリの構成を指定し、target-branchキーを使ってそのエコシステムの構成ブロックも併用している場合、Dependabot security updatesはプライベートレジストリの情報を期待したように利用できませんでした。今日（2024年3月18日）より、Dependabotはdependabot.ymlで指定したプライベートレジストリの構成を期待通りに利用できるようになりました。target-branchを利用した構成であってもです。これにより、あなたのリポジトリの構成設定に関係なく、security updatesが正しく適用されます。ただし、security updatesはまだtarget-branch構成をサポートしていないことにご注意ください。

プライベートレジストリに対するDependabotの構成については、Dependabotのドキュメンテーションをご参照ください。

監査ログイベントにおいてSAML SSOとSCIMの識別データがGA🎉

本日（2024年3月19日）より、GitHub Enterprise CloudとGitHub Enterprise Server 3.13において、エンタープライズおよびOrganizationの監査ログイベントにはユーザーに紐づいた利用可能なSAMLやSCIMの識別データが含まれるようになります。このデータは追加分の可視性をユーザーの識別情報に追加するので、共通の強調した識別情報を利用し複数のシステムからのログが素早く簡単にリンクされるようにします。監査ログのペイロードにおいて、SAMLの識別情報はexternal_identity_nameidフィールドに表示され、SCIMの識別データはexternal_identity_usernameフィールドに表示されます。

GitHub Enterprise Cloud Classicでは、SAML SSOはOrganizationやエンタープライズの所有者にリポジトリやイッシュー、プルリクエストのようなリソースへのアクセスに対してセキュリティを保ち制御する方法を提供します。Organizationの所有者はGitHubユーザーをSAML SSOによって構成されるOrganizationに招待でき、ユーザーに対して、GitHub上に存在する識別情報やコントリビューションを維持したまま、Organizationのメンバーになることを許可できます。

もしあなたのEnteprise Cloud Classic OrganizationがSAML SSOを利用している場合、あなたはOrganizationメンバーのOrganizationに対するアクセスを追加、管理、削除するためにSCIMを利用できます。例えば、管理者はSCIMを利用してOrganizationメンバーを割り当てられ、Organizationからメンバーを自動的に削除することがでます。

詳しくは、組織の Audit log をレビューする - GitHub Enterprise Cloud Docsをご参照ください。

セキュリティ製品向けのEnablement trends（public beta）

GitHub Organization内のすべてのセキュリティ製品に対するenablement trendsをモニターできるようになりました。この機能は、あなたのOrganizationでセキュリティ製品のカバレッジがどのように実装されているかについて詳細な概要を得られるように設計されています。

Enablement trendsでは、GitHubセキュリティ機能のアクティブ化の状態について時系列の分析情報を確認できます。

Dependabot alerts
Dependabot security updates
Code scanning
Secret scanning alerts
Secret scanning push protection

時系列のデータは一部を除き2024年1月1日から利用可能で、Dependabot security updatesに関するデータについては2024年1月17日から利用可能です。

Enablement trendsページにアクセスするには、OrganizationのSecurity overviewを開いてください。"Security"タブを選択することでSecurity overviewを開けます。

この機能はGitHub Enterprise CloudとGitHub Enterprise Server 3.13でpublic betaとして利用可能です。

Security overviewに関しては、セキュリティの概要についてをご参照ください。ディスカッションはGitHub Communityよりご参加ください。

Code scanningにおける、プルリクエストのCodeQLアラートに対するAIによる自動修正の提案（beta）

Code scanning autofixが、すべてのGitHub Advanced Security利用者に対してpublic betaとして利用可能になりました。GitHub Copilotにより強化され、code scanningはCodeQLによって検出されたJavaScript、TypeScript、Java、Pythonに対するアラートに対して修正を提案します。
この機能は、プルリクエストで見つかったアラートを対処するために費やす時間や労力を減らすために開発者を強力にサポートし、あなたのコードベースに新たな脆弱性を混入させてしまうことを防ぐ手助けをします。

この機能は、GitHub Advanced Securityを利用するすべてのプライベートリポジトリで自動的に有効になります。プルリクエストでcode scanningの解析が実行されるとき、autofixはアラートを支援するために生成されます。これらには、コードの提案のプレビューと共に提案された修正に対する自然言語による解説も含まれており、開発者はそれを受け入れたり、編集したり、却下したりできます。そのファイルへの変更に加え、それらのコードの提案は複数のファイルにたいする　変更も含むことがあります。必要に応じて、autofixは依存関係を追加したり変更したりもします。

オープンまたはクローズされているプルリクエストにおけるCodeQLアラートに対して提供されたautofixによる提案の総数を、security overviewで確認できます。

code scanning autofixは、リポジトリまたはOrganizationで構成できます。エンタープライズにおいて、CodeQL code scanningに対するautofixを許可するには、Policies for Code security and analysisをご確認ください。

Code scanning autofixは、平均して、Default code scanningスイートのクエリから発生したJavaScript、TypeScript、Java、Pythonに対するCodeQLのアラートの90%をサポートします。与えられたアラートに対する修正の生成は、アラートのコンテキストと場所に基づいています。いくつかのケースでは、もし提案されるコードの変更がシンタックステストや安全のためのフィルタに失敗する場合、code scanningは修正候補を表示しません。

この変更は、GitHub.comにおいてGitHub Advanced Securityのすべての利用者が利用可能です。詳しくは、CodeQL コードスキャンの自動修正についてをご参照ください。

Code scanning autofixに関するフィードバックは、こちらにお寄せください。

OpenSSFのスコアカード情報がDependency Reviewアクションで利用可能に

Dependency reviewは、依存関係の変更やすべてのプルリクエストにおけるそれらの変更のセキュリティ的な影響を理解するのを助けます。利用している依存関係のセキュリティに対する方針を理解するのを助けるために、dependency reviewアクションをOpenSSFのスコアカードプロジェクトからの情報をレビューに含むよう更新しました。

NuGetに対するDependabot updatesのエラーハンドリングの改善

Dependabotは、サポートしていないNuGetプロジェクトの型に遭遇した場合、有用なエラーメッセージと共に穏やかに失敗するようになります。もし以前にサポートしていないプロジェクト型を利用していた場合、Dependabotは更新を生成することなく静かに失敗していました。Dependabotは、.csprojや.vbproj、.fsprojなどのフォーマットによるNuGetプロジェクトのファイルに対して更新を処理できるようになりました。

新しいSSH CAで有効期限が近い証明書に署名が必要

3月27日以降にGitHub.comまたはGitHub Enterprise Server(GHES) 3.13以上にアプロードされるSSH CAは、有効期限が設定された証明書にのみ署名できます。それは、作成されてから366日以内の期限である必要があります。
証明書の期限はssh-keygenなどの署名ツールでは要求されませんが、SSHの証明書がユーザーに紐づけする方法の弱点から保護するために、このベストプラクティスを強制します。

カットオフの日またはリリースより前にアップロードされたCAは、期限が設定されていない証明書への署名が許可されていると、UI上で強調されます。

CAの"upgrade"オプションにより、署名された証明書の有効期限を適用できます。証明書で有効期間を実際に使用していると確認したら、CAのアップグレードをお勧めします。この更新の手順は不可逆で、期限のない証明書を許可しようとして新しい証明書をダウングレードできません。
もし証明書に期限を指定せず、もしくはとても長い期間で署名している場合、SSH接続においてThe SSH certificate used was issued for a longer period than allowedというエラーとともに拒否されます。

この変更は、証明書がユーザー名のために発行された後、さらにユーザー名が変更されたことをGitHubが検知するために、証明書に記述されたvalid_after保障タイムスタンプを要求します。これは、以前のユーザー名の以前の持ち主が発行された証明書を試用して、そのユーザー名の新しい持ち主として署名できてしまう再利用攻撃ベクトルを防ぎます。

SSH CAの管理について、詳細は"OrganizationのSSH認証局を管理する"や"Enterprise の SSH 証明機関を管理する"をご参照ください。SSH CAを利用するには、"SSH認証局について"をご覧ください。

Security overviewダッシュボード: Ageの傾向アラート、リポジトリや重要度によるフィルタリング、日付ピッカー

本日（2024年3月20日）より、ユーザーの分析プロセスやセキュリティ管理を改善するために、アラートの傾向グラフに対して新しく"age"によるグルーピングができるようになり、Security overviewダッシュボードで拡張されたフィルタオプションを利用できるようになりました。

Security alert age trends

新しいアラートのグルーピング設定であるageを用いて、アラート傾向のグラフからセキュリティアラートの動向を閲覧できるようになりました。この新しい機能は、セキュリティアラートのライフサイクルが詳細に表示され、対応の戦略の適時性と有効性をより適切に評価できます。

新しいフィルタオプション

overviewダッシュボードでセキュリティのインサイトをうまく調整するために使える拡張されたフィルタが利用できるようになりました。

リポジトリのカスタムプロパティによるフィルタ: リポジトリのカスタムプロパティを利用して、記述可能なメタデータによってリポジトリをタグ付けでき、security overviewを横断して効果的な編成や分析を支援できます。
重要度によるフィルタ: 重要度に基づくフィルタにより、もっとも重要な脆弱性に集中でき、セキュリティリスクのアセスメントや優先順位付けの工程を合理化できます。
日付ピッカーコントロールの改善: 使いやすくなった新しい日付ピッカーオプションを利用して時系列をナビゲーションでき、"直近14日間"、"直近30日間"、"直近90日間"のようなまとまった期間を素早く選択できるようになりました。好みの時間ウィンドウをブックマークしておくこともでき、開くたびに分析を最新の状態に保てます。

Organizationレベルの"Security"タブを開くことで、security overviewのこれらの新しい機能にアクセスできます。

これらの機能は現在GitHub Enterprise Cloudにおいてpublic betaで利用可能であり、GitHub Enterprise Server 3.13にも導入されます。

詳しくは、security overviewの詳細をご参照ください。フィードバックはこちらからお寄せください。

Code scanningのdefault setupの利用時に、Javaプロジェクトのビルドが不要に

GitHub code scanningを強化する静的解析エンジンであるCodeQLは、ビルドする必要とすることなくJavaプロジェクトを解析できるようになりました。これにより、Organizationはより簡単にCodeQLの導入を進めることができます。このJavaのコードベースの新しい分析方法は、GitHub.comの利用者がcode scanningのdefault setupを利用した新しいリポジトリを作成する際に、デフォルトで利用可能になります。

以前は、CodeQLはJavaプロジェクトの分析をするためにビルドが必要でした。これは自動的に検出される場合も手動で指定する場合も同様です。GitHubでの大規模な試験の結果、この要件をなくすことで、手動の介在を必要とすることなく、90%以上のJavaリポジトリでCodeQLが正常に利用できることが示されました。

この機能は現在public betaで、GitHub.com上でcode scanningのdefault setupを利用してJavaコードをスキャンする据えてのユーザーが利用可能です。

code scanningのdefault setupを利用してリポジトリをセットアップした利用者は皆、自動的にこの新しい分析のアプローチの恩恵を受けられます。
KotlinとJavaのコードが混在するリポジトリにおいては、まだCodeQLの分析においてビルドが必要です。CodeQLはデフォルトでautobuildビルドモードを選択し、自動的に試行し正しいビルドコマンドを検出します。
_既存の_code scanningのセットアップを行ったリポジトリについては、影響はありません。もしcode scanningが本日も動作している場合、これまで通り動作します。構成を変更する必要はありません。

code scanningのadvanced setupを利用してるGitHub.comの利用者やCodeQL CLIを利用している方は、CodeQL CLIのバージョン2.16.5の一部としてビルドを必要としないJavaプロジェクトの分析を利用できるようになります。public betaの間は、この機能はGitHub Enterprise Serverでは利用できません。ビルドなしにJavaプロジェクトのスキャンが動作できるよう引き続き対応を続けます。フィードバックはこちらにお寄せください。

GitHubCopilot in the CLIがGA🎉

Copilot Individual, Business, Enterpriseの利用者において、Copilot in the CLIが一般公開されました。

Copilot in the CLIにより、ユーザーはターミナルから移動せずにGitHub Copilotの力にアクセスでき、コマンドの提案や説明を得られます。また、今日（2024年3月21日）より、public betaの間に共有されたフィードバックに基づき、開発者は提案されたコマンドを実行できるようにもなります。

また、GitHub Copilot in the CLIは、BashやPowerShell、Zshに関するヘルパーエイリアスを提示してくれます。この新しいgh copilot aliasコマンドは、ghcsやghceなどのエイリアスに対するshell指定の構成を生成します。これらのエイリアスは少ないキー操作でgh copilotの体験に飛び込めます。加えて、新しいghcsエイリアスは、後に再利用できるように提案されたコマンドを実行する工程を合理化します。

どうやって使い始める？

すでにPublic betaを利用していた場合

gh extension upgrade gh-copilotを実行して拡張機能をv1.0.0に更新してください。

もしまだCopilot in the CLIを有効化していない、またはGitHub Nextのテクニカルプレビューから利用していた場合

Copilot Individualのユーザー: 自動的にCopilot in the CLIを利用できるようになります。
Copilot BusinessとEnterpriseのユーザー: Organizationの管理者がユーザーにCopilot in the CLIの利用権限を与える必要があります。

Copilot in the CLIのアクセス権が与えられれば、ガイドに従ってツールをインストールしご利用ください。

フィードバックをお寄せ下さる方へ

引き続き改善と改良を続けていきます。あなたからのフィードバックは開発の工程において非常に重要な部分で、あなたのGitHub COpilot in the CLIの利用経験を聞かせていただけることはとても光栄です。製品をどう改善すればよいのかのフィードバックやアイディアなどは、こちらのパブリックリポジトリにてお寄せください。

Security overviewのインサイトやsecret scanningメトリクスの改善

本日（2024年3月21日）、Security overviewダッシュボードに新しいインサイトのホストをリリースし、secret scanningメトリクスページを拡張しました。

新しいダッシュボードインサイト

サードパーティのアラートの統合: GitHubが持つCodeQLやsecret scanning、Dependabotのセキュリティツールに加え、サードパーティーツールに対するアラートメトリクスをoverviewダッシュボードで直接閲覧できるようになりました。特定のサードパーティーのセキュリティツールのメトリクスを閲覧するにはtool:[third-party-tool name]を、すべてのサードパーティーのセキュリティアラートのメトリクスを閲覧するにはtool:third-partyを指定します。
再オープンされたアラートの追跡: 新しいreopenedアラートメトリクスタイルによって、繰り返し発生する脆弱性を掘り起こし、以前解決したにもかかわらず再度浮上した脆弱性を特定します。このデータポイントは、修復作業の長期的な有効性を評価するのに役立ちます。
トレンド指標: アラートの生存期間や修正までのmeanタイム、ネット解決率、アラートの総数などのキーメトリクスのトレンド指標を用いて時系列の変化をレビューできます。
アドバイザリタブ: Organizationに影響する上位10件のアラートに対するアドバイザリの詳細が提供される新しいアドバイザリテーブルによって情報を得続けることができ、それにはアドバイザリのCVE IDsやエコシステム、オープンされているアラートの数や重要度などが含まれます。

Secret scanningメトリクスページの強化

secret scanningメトリクスページにおいて、日付やリポジトリのカスタムプロパティ、チームなどのフィルタを用いて、インサイトを深めることができます。これらの新しいフィルタにより、特定のリポジトリを抽出し、時系列の変化を閲覧でき、より対象を絞った分析ができるようになります。Organizationメンバーの場合は、あくっす県のあるリポジトリに対してメトリクスを閲覧できます。

これらの機能はGitHub Enterprise Cloudでpublic betaとして利用可能で、GitHub Enterprise Server 3.13にも導入される予定です。

詳しくは、security overviewについてご確認ください。また、フィードバックはこちらにお送りください。