OSS

概要 HashiCorpの共同創業者であり、ターミナルエミュレータ「Ghostty」の作者としても知られるミッチェル・ハシモト氏が、新会社「Superlogical」を設立したことを2026年7月29日に発表した。同社のミッションは「We are building the multiplexer for all work（あらゆる仕事のためのマルチプレクサを開発する）」であり、人間の作業とAIエージェントを長時間セッションの中で統合する、サーバーサイドで動作する新しいターミナルマルチプレクサの開発に取り組むという。 マルチプレクサとは何か マルチプレクサとは、1つのターミナル画面上で複数のセッションや画面を同時に扱えるようにするソフトウェアを指す。既存の代表的な実装としては、長年開発者に使われてきたtmuxやGNU screenが挙げられる。ハシモト氏はHashiCorp在籍時からインフラ・開発者ツール分野で実績を積み、退社後はGhosttyの個人開発を進めてきた人物であり、今回のSuperlogicalはその延長線上にある新たな挑戦と位置づけられる。 目指す技術的特徴 Superlogicalが開発するマルチプレクサは、単に複数セッションを切り替えられるだけの既存ツールとは一線を画すことを目指しているという。具体的には、コンポーザブル(組み立て可能)な設計を採用し、安全性と本番環境での利用に耐える堅牢性を備えることを重視する。さらに、ローカル環境だけでなく、リモート、サンドボックス、クラウドといった分散した実行環境をシームレスに統合し、人間の対話的な作業とAIエージェントによる自動化された作業の両方を、単一の長時間セッションの中で扱えるようにすることを狙っている。 今後の展望 ハシモト氏は、マルチプレクサの開発をあくまで「第一歩」と位置づけており、その先には開発者、AIエージェント、各種ツール、インフラなどをまとめて接続する、より大きな基盤の構想があるとされる。AIエージェントが実務の中で人間と並走して作業を進める機会が増える中、そうしたエージェントと人間のセッションをどう統合的に扱うかは今後のツール開発における重要なテーマとなりつつあり、Superlogicalの動向は注目を集めそうだ。

概要 npmが新機能「ステージ公開（Staged Publishing）」を正式にリリースした。従来、開発者がパッケージの新バージョンをアップロードすると即座に公開されていたが、この機能を有効にすると、パッケージはいったん「ステージングキュー」に入り、npmjs.com上やCLIで内容を確認したうえでメンテナが明示的に承認するまでは一般に配信されない仕組みになる。承認にあたっては2要素認証（2FA）が必須となり、CI経由の乗っ取りなどによる不正な自動公開を防ぐ狙いがある。 技術的な仕組み ステージ公開は、npm CLIに新たに追加された一連のサブコマンドで操作する。npm stage publishでバージョンをステージングキューに送信し、npm stage listで承認待ちの一覧を確認、npm stage view <stage-id>でアップロードされたtarballの中身を検査できる。問題がなければnpm stage approve <stage-id>で本番レジストリに昇格させ、不審な場合はnpm stage reject <stage-id>で破棄する。 重要な設計上の工夫として、ステージングへのアップロード自体は2FA要件をバイパスできるため、非対話的なCIパイプラインからの公開フローは従来通り動作する。人間による確認はその後の承認ステップに移されており、CI環境が乗っ取られたとしても攻撃者が直接悪意あるバージョンを一般公開することはできない構造になっている。利用にはnpm CLI 11.15.0以降とNode.js 22.14.0以降が必要で、GitHubは2026年5月にこの機能を一般提供（GA）した。 導入の背景 この機能は、Shai-Huludワームによる攻撃をはじめとする一連の深刻なサプライチェーン侵害事件と、クラシックトークンからの移行に伴う混乱を受けて開発された。セキュリティ研究者のAdnan Khan氏は「npmに公開しているすべての人は今すぐこの機能を有効にすべきだ。OIDC経由でCIから公開し、一般公開される前にパッケージを承認するようにしよう」と述べ、早期の導入を強く推奨している。 他ツールの追随と今後の展望 同様の仕組みは他のパッケージマネージャーにも急速に広がっている。pnpm 11.3では同名のpnpm stageコマンド群が追加され、Yarnもyarn npm stage listなどの形で対応した。リリース自動化ツールのrelease-itも"stage": trueという設定オプションを追加している。さらにpnpmは、公開されたばかりの新しいバージョンのインストールをデフォルトで一定期間遅延させる補完的な防御も実装済みだ。 開発者コミュニティの反応は賛否が分かれている。あるReddit（r/programming）のコメントは、ステージ公開を万能の解決策ではなく「拡散速度を下げるもの」と位置づける一方、あるHacker Newsのコメントでは「CI乗っ取りによる公開攻撃という攻撃手法全体を無力化する重要な改善」と評価する声もあった。メンテナが実際にこの機能を継続的に利用するかどうかについては懐疑的な見方も出ている。GitHubは今後、粒度の細かいアクセストークンをデフォルトでステージ専用モードにすることや、npm v12でインストールスクリプトをデフォルトでオプトイン化するallowScriptsフィールドの導入も計画している。

概要 GitHubは2026年8月6日、企業向け管理設定においてMCP(Model Context Protocol)サーバーの許可/拒否リストを設定できる新機能を一般提供として発表した。企業の所有者はallowedMcpServersとdeniedMcpServersという2つのキーを用いて、組織内のCopilotクライアントがどのMCPサーバーを実行できるかを中央で管理できるようになる。信頼できるサーバーを承認する一方で、不適切またはコンプライアンス上問題のあるサーバーの利用をブロックでき、対象はGitHub Copilotアプリ、Copilot CLI、VS Codeの3クライアントとなっている。 MCPはAIエージェントが外部ツールやデータソースと連携するためのプロトコルとして急速に普及しているが、その裏返しとして、組織のメンバーが検証されていない、あるいは悪意のあるMCPサーバーを不用意に接続してしまうリスクも指摘されてきた。今回の機能は、こうしたシャドーMCPの利用を組織レベルで抑制し、承認されたサーバーのみを利用させるためのガバナンス手段として位置づけられている。 技術的な詳細 設定はcopilot/managed-settings.jsonというファイル内に記述する。サーバーを識別するためのマッチャーとして以下の3種類が用意されている。 serverUrl: HTTP/SSE経由で接続するリモートサーバーを識別するもので、ワイルドカードによる指定にも対応する。 serverCommand: ローカルで実行するサーバーをコマンドと引数の完全一致で検証する。 serverName: ユーザーが割り当てたラベルによる識別で、あくまで表示用途であり、セキュリティ制御としては機能しない点に注意が必要とされている。 ポリシーは「失敗時クローズド(fail-closed)」の方針で設計されており、設定内容が不正な場合は許可ではなくブロックされる挙動になる。また、組織や企業など複数階層でポリシーが設定されている場合は、いずれの層のチェックも通過しなければ実行が許可されない仕組みだ。 設定方法と今後の展望 管理者は、ソース組織の.github-privateリポジトリ内にあるcopilot/managed-settings.jsonに許可・拒否リストのキーを追加し、デフォルトブランチにコミットすることで設定を反映させる。中央集権的な設定ファイルによる管理のため、個々の開発者の設定変更に依存せず、組織全体に一貫したポリシーを適用できる点が特徴だ。 AIエージェントやMCPサーバーの利用が企業の開発ワークフローに急速に組み込まれつつある中、今回のような管理者向けガバナンス機能の整備は、セキュリティとコンプライアンスを担保しながらAI活用を推進したい企業にとって重要な一手になると見られる。今後、対応クライアントの拡大や、より詳細なポリシー制御機能の追加が続く可能性がある。

概要 GitHubは2026年8月6日（現地時間午前11時22分/UTC15時22分)、GitHub Actionsのパフォーマンス低下を検知し、これが約10時間半に及ぶ大規模障害へと発展した。原因は実行ランナーに対して無効なジョブが継続的かつ誤って割り当てられていたことで、ワークフローの失敗や遅延が世界中のCI/CDパイプラインを直撃した。障害はActions単体にとどまらず、GitHub Pagesの可用性低下、Copilotのコードレビューおよびコーディングエージェント機能の劣化、ホステッドランナーの不調、GitHub Enterprise Importerの移行ジョブ停止、ウェブフック配信の遅延（処理能力が通常の15%まで低下）へと波及した。一部のトリガーイベントは自動再実行の対象外となり、失われたままとなっている。GitHubは発生から約2時間後に原因を特定したとするも当初は技術的詳細を明らかにせず、その後複数の緩和策と修正を段階的に適用し、現地時間午後8時1分に復旧を宣言した。修正適用後、ワークフロー実行の成功率は99%まで回復したという。 背景にある信頼性の低下 今回の障害は単発の事故ではなく、GitHubのインフラが抱える構造的な問題の一端として位置づけられている。IncidentHubの集計によれば、過去12カ月間でGitHub全体は257件のインシデント（うち48件が「メジャー」）を記録し、累積ダウンタイムは112時間を超える。GitHub Actionsだけでも57件のインシデントが報告されており、月別でも2026年4月に26件、5月に23件、6月に23件、7月に26件、8月も6日時点で既に6件と、高止まりが続いている。GitHubは以前、AI関連ワークロードの急増をシステム負荷の一因として説明し、構造的改善を約束していたが、今回の障害はその効果が十分に表れていないことを示した。GitHubは現在Azureへのインフラ移行を進めているものの、今回の障害発生時点でトラフィックの移行率はわずか12.5%にとどまっており、完全移行までは同種の負荷問題が続く可能性がある。 開発者コミュニティの反応 相次ぐ障害に対し、開発者コミュニティの不満は深刻化している。ターミナルエミュレータGhosttyの開発者Mitchell Hashimotoは「ほぼ毎日のようにインシデントで作業がブロックされている」と述べ、プロジェクトのGitHubからの移行を発表した。Zig言語財団もすでにCodebergへの完全移行を完了させている。ある開発者は、現状のGitHubのプラットフォームは「本格的な業務利用には適さない」との評価も示しており、CI/CD基盤としての信頼性そのものが問われる状況となっている。

概要 Rustのコンパイラや標準ライブラリを管理する5つのチームは8月5日、rust-lang/rustモノレポへの貢献を対象としたLLM利用に関する公式ポリシーを採択したと発表した。基本方針は「質問への回答、分析、精緻化、チェックには良いが、コード生成はダメ」というもので、LLMとの対話を通じて自身の理解を深めたり、テキストの分析・要約、バグ発見の補助、翻訳支援に使ったりすることは歓迎する一方、LLMにコードを生成させてそのままPRとして投稿する行為には強い制限を課している。なお、このポリシーはあくまでrust-lang/rustリポジトリに限定されたものであり、Rustプロジェクト全体としての公式見解ではない点が明記されている。 ポリシー採択の背景 チームがこの方針を採択した背景には3つの課題があるという。第一に、これまで「磨き上げられたPR」は著者の努力や献身の指標として機能してきたが、LLMによって誰でも一見高品質なPRを作れるようになり、その指標が失われつつある。第二に、rust-lang/rustには現在1,281件ものオープンPRが存在し、レビュー体制はすでに逼迫している中で、LLMによる「弾幕」的なPR増加はレビュアーの精神的負担を急増させかねない。第三に、レビューでの指摘事項をそのままLLMに貼り付けて得た回答を投稿するといった機械的なやり取りは、時間の浪費であるだけでなく、著者とレビュアーの間の信頼関係を損なうと指摘されている。 具体的なルール 許可される利用としては、LLMとの非公開の対話による理解の補助、テキストの分析・要約、バグ発見の補助、そして開発者が母語で投稿しやすくするための翻訳支援が挙げられている。一方、LLMが生成したコードを投稿する場合は「事前に調整済みで、重要度が低く、高品質かつ十分にテストされている」ことが条件となり、テストの有無に関わらず必ずテストを添付する必要がある。コンパイラのソウンドネスに関わる変更については、既存の専門家を除いて禁止される。さらに、公開ドキュメントや診断メッセージの本文をLLMが生成することは全面的に禁止されており、診断ロジックの補助としての利用のみ条件付きで認められる。また、公開の場でLLMが生成したテキストを使う場合は、開示が必須とされ、隠すことは許されない。 コミュニティでの運用と今後の展望 運用面では、著者はLLM利用を自発的に申告することが求められ、今後PRテンプレートに使用有無を確認する項目が追加される見込みだ。レビュアーには、ポリシー違反が疑われるPRを理由を示さずに却下する権限が与えられる一方、疑いがある場合の報告は告発ではなく情報提供として扱われ、単なるスタイル上の違和感を証拠として扱わないよう配慮されている。Rustプロジェクトはコンセンサス(合意形成)によって運営されているため、今回のポリシーもトップダウンの一律禁止ではなく、コミュニティが共有する「深い専門知識の構築」「包摂的なコミュニティ」といった価値観に基づいて設計されたという。プロジェクト側は、LLM利用についてコミュニティ内で見解が一致しているわけではないと認めた上で、今後は利用実態のデータ収集やLLM関連ポリシーの承認を簡素化する専門サブチームの設立を検討するとしている。将来的には、チャットやフォーラム、他のリポジトリを含むプロジェクト全体へのポリシー拡大も視野に入れており、今回の方針は最終決定ではなく、経験を踏まえて進化させていく前提で設計されている。

概要 2026年8月4日、週間1億件を超えるダウンロード数を誇る人気npmパッケージ「keyv」をはじめとする一連のパッケージが、GitHubアカウント侵害を通じて汚染される大規模サプライチェーン攻撃が発生した。攻撃コードはpreinstallスクリプトとして仕込まれ、開発環境やCI環境でGitHub認証情報、npmレジストリアクセス権、クラウド認証情報、Vault・Kubernetes・データベースの認証材料などを窃取した。監視ツールによれば被害はSafeDepの検証で79パッケージ名・353バージョンに及び、Aikidoの報告ではさらに広く868パッケージ・1,381バージョンに達したとされる。攻撃は自動化されたワームとして機能し、2〜7分ごとに侵害した組織アカウントから次の組織へと移動し、約30分で横断的な公開バーストを完了させたと分析されている。 攻撃手法の技術的詳細 最初の悪意あるリリースであるkeyv@6.0.0は、インストール時に自動実行されるpreinstallスクリプトを通じて認証情報窃取バンドルを実行する設計だった。setup.mjsとMath_Symbol.jsという2つのファイルが仕込まれ、まずBunランタイムの有無を確認し、必要であればGitHubから1.3.13版のBunをダウンロードした上で、727,680バイトのコンパイル済みバンドルに制御を委譲する多段構成となっていた。攻撃者はGitHubアカウントの侵害によって取得した権限を悪用し、正規のGitHub Actionsリリースワークフローを通じてOIDC/SLSA証明付きの「正規リリース」として悪意あるパッケージを公開した。コミット自体もgithub-actions[bot]名義で検証済みバッジ付きだったが、専門家はこのバッジが署名パスの有効性を示すのみでソースコードの安全性までは保証しないと指摘している。同様にOIDC/SLSA証明もビルドプロセスの出所を特定できるに過ぎず、ソースの安全性を確立するものではないという限界が改めて浮き彫りになった。 IDE・エディタへの実行経路の仕込み 今回の攻撃で特に問題視されているのが、開発者のローカル環境で自動実行されるツール設定への侵入である。.claude/settings.jsonにはセッション開始時に自動実行されるSessionStartフックが仕込まれ、.vscode/setup.mjsを呼び出す構成になっていた。同様に.vscode/tasks.json内の「Environment Setup」タスクにはrunOn: folderOpenが設定され、フォルダを開いた際に.claude/setup.mjsを自動実行する仕掛けが組み込まれていた。ただしVS Codeは信頼されていないワークスペースでの自動タスク実行をブロックし、デフォルトでは実行前にユーザーへ確認プロンプトを表示するため、無条件で実行されるわけではない点は留意が必要である。とはいえ、開発ツールのワークスペース設定ファイルという開発者が見落としがちな場所に実行経路を仕込む手口は、今後同種の攻撃が広がる可能性を示唆している。 発見・対応状況とマルウェアファミリーとの関連 8月4日午後5時40分(IST)頃には、keyv@5.6.0やflat-cache@6.1.23、cache-manager@7.2.9など複数パッケージで、汚染前の以前のバージョンが「latest」タグに復元される対応が取られた。その後の続報では、keyvおよびCacheableの毒物化リリースは非公開化されたものの、それ以外のほぼすべての被害パッケージでは「latest」タグが依然として悪意あるバージョンを指したままであると報告されている。セキュリティ企業Aikidoはこの攻撃を既知のマルウェアファミリー「Shai-Hulud」に位置づけており、セキュリティ企業Semgrepは同一のClaude Code・VS Codeフック、setup.mjsというファイル名、Bun 1.3.13のダウンロード手口が、2026年4月に発生したPyPIのlightning(pytorch-lightning)パッケージ侵害でも確認されていたと報告している。報道時点では、メンテナー・npm・GitHubいずれからも公式声明は出されていない。 推奨される対策と今後の見通し 専門家はlockfileと実際に解決されたバージョンをパッケージ名単位で正確に照合すること、不要なインストールスクリプトを無効化すること、そして影響を受けたバージョンを実行した環境はすでに侵害されたものとして扱うことを推奨している。npm 12ではデフォルトで未承認のライフサイクルスクリプトがブロックされるようになっているが、旧バージョンのクライアントやライフサイクルスクリプトの実行を許可する設定を残した環境は依然として脆弱なままだ。正規のCI/CD証明やコミット署名だけでは供給元の安全性を保証できないことが改めて示された今回の事例は、開発ツールの自動実行設定を含めた多層的なサプライチェーン防御の必要性を浮き彫りにしている。

概要 GitHubは8月6日、オープンウェイトモデル「Kimi K3」をGitHub Copilotで一般提供開始したと発表した。Kimi K3はFireworks AI上でホストされており、エージェント型コーディングにおいてフロンティア級の性能を低コストで利用できる点が特徴となる。Copilot Pro、Pro+、Max、Business、Enterpriseの全プランで選択可能になったが、BusinessおよびEnterpriseプランではデフォルトで無効化されており、管理者が設定画面から有効化する必要がある。利用はVisual Studio Code、Visual Studio、Copilot CLI、GitHub.comなど複数のインターフェースに対応し、現在は段階的なロールアウトと品質・パフォーマンスの監視が進められている。 料金体系 Kimi K3は従量課金制のモデルとして提供される。公開されている価格は、入力トークンが100万トークンあたり3ドル、出力トークンが100万トークンあたり15ドル、キャッシュされた入力トークンが100万トークンあたり0.30ドルとなっている。既存のフロンティアモデルと比較して低コストな料金設定であり、コーディング支援を日常的に利用する開発者にとって選択肢の幅が広がる形だ。 Kimi K3とは Kimi K3は、北京を拠点とするMoonshot AIが開発したオープンウェイトの大規模言語モデルである。2026年7月中旬に発表され、7月27日にはモデルの重みが公開された。総パラメータ数は約2.8兆にのぼり、これまでに公開されたオープンウェイトモデルとしては最大級とされる。ただし実際には、Mixture-of-Experts(MoE)構造により1トークンあたり1040億パラメータのみが活性化される設計となっている。100万トークンのコンテキストウィンドウを持ち、テキストに加えて画像・動画も扱うネイティブなマルチモーダル入力に対応するほか、OpenAIおよびAnthropicのAPIと互換性のあるインターフェースを備える。重みは商用利用も可能な独自の「Kimi K3 License」の下で公開されているが、学習データや学習コード自体は公開されていないため、厳密には「オープンソース」ではなく「オープンウェイト」の位置づけとなる。 性能面では、総合的なベンチマークではAnthropicやOpenAIの最新フロンティアモデルにはわずかに及ばないものの、コーディングおよびエージェント関連の評価では両社の旧世代モデルを上回る結果を示している。公開直後からコミュニティの注目を集め、モデルリポジトリには短期間で数千件規模の「いいね」と多数のダウンロードが集まった。一方で、自前でホストする場合はNVIDIA H100またはB200 GPUを8サーバー・計64基程度必要とする規模感であり、実運用でのセルフホスティングは潤沢なリソースを持つ組織に限られるのが実情だ。今回のGitHub CopilotによるFireworks AI経由でのホスティング提供は、こうした大規模インフラを持たない一般の開発者にもKimi K3の性能を手軽に届ける狙いがあるとみられる。 今後の展望 GitHub Copilotへの主要オープンウェイトモデルの統合は、開発者がタスクに応じてクローズドソースモデルとオープンウェイトモデルを柔軟に使い分けられる流れを加速させるものだ。特にコストを抑えつつエージェント型コーディングを実行したい場合の有力な選択肢として、Kimi K3の存在感は今後さらに増していく可能性がある。GitHub側は段階的ロールアウトを継続しており、今後のパフォーマンス評価や提供範囲の拡大にも注目が集まる。

概要 セキュリティ企業Manifold Securityは、VS Code系エディタ向けのオープンな拡張機能マーケットプレイス「Open VSX」上で、正規の開発者ツールになりすました「evil twin(双子)」型の悪意ある拡張機能77個を発見した。これらは2026年7月26日から8月1日にかけて、本来の所有者ではないアカウントから公開されたもので、いずれも本物の拡張機能の名前・説明文・名前空間をそのままコピーし、バージョン番号を「0.0.1」などの低い値に設定することで検出を逃れようとしていた。実装面では、バンドルされているextension.jsファイルが、情報収集と外部送信を目的としたコードに差し替えられていた。Open VSXは8月3日までに該当パッケージをすべて削除したが、既にインストール済みの環境からは手動でのアンインストールが必要とされている。 収集されたデータと攻撃の階層構造 窃取された情報の範囲は拡張機能によって異なり、大きく2つの階層に分かれていた。77個のうち58個は「軽量型」で、主にマシンのホスト名や、場合によってはワークスペースのフォルダ名・エディタのバージョンといった最小限の情報のみを送信していた。残る19個(全体の約4分の1)は「偵察型」と呼ばれるより高度な変種で、ホスト名やOSのユーザー名、マシンID、エディタの仕様、プラットフォームのアーキテクチャ、ロケールやタイムゾーンに加え、Gitのリモートホストや組織情報、GitHub/GitLabのプロジェクト情報、コミットのメールドメイン、ブランチ情報、CI/CD環境の変数やマーカーなど、開発環境やプライベートリポジトリに関するかなり詳細な情報まで収集していた。一方でManifold Securityは、これらの拡張機能がソースコード本体や認証情報、アクセストークン、SSH鍵、ブラウザデータには一切アクセスしていなかった点も明らかにしている。なお、拡張機能の説明ページには「テレメトリ」の項目として「ソースコードや認証情報、トークンは収集しない」と明記されていたケースもあったが、少なくとも1つの拡張機能ではCIマーカー値を送信しないと述べながら実際には送信しており、利用者を欺く記述だったことも判明している。 インフラと技術的な巧妙さ 77個の拡張機能はすべて、単一のドメイン「mangorbit[.]com」へデータを送信していた。このドメインはキャンペーン開始の11日前にあたる2026年7月15日に登録されており、あらかじめ準備されたインフラが使われていたことがうかがえる。さらに攻撃者はこのドメインを3年間分登録するなど、長期的な運用を見据えた設計を施していた。持続性の面でも工夫が見られ、偵察型の変種では初回インストールからおよそ15分後、50分後、3.5時間後に送信を試み、その後は7~8時間ごとに定期送信を繰り返す仕組みが確認された。また、通信が遮断された場合に備えてDNS TXTレコードを用いた代替の送信先ドメインを問い合わせる機能や、自動インストールとユーザーによる手動インストールを区別するロジックも組み込まれており、単純な自動化ボットではなく人間の開発者を明確に標的にしていたことを示している。 背景と今後の対応 今回の事案は、npmエコシステムで450個のパッケージが影響を受けたとされる大規模なサプライチェーン侵害「ChainDrop」とほぼ同時期に発覚しており、オープンソースのパッケージレジストリ全般を狙った脅威が拡大している状況を浮き彫りにしている。Manifold Securityは、攻撃者の目的や身元について現時点では推測を避けているが、防御策として、パブリッシャーとバージョンをピン留めすること、未検証のパブリッシャーによる拡張機能の自動インストールを警告・ブロックすること、新規登録されたドメインへの通信を検知することなどを推奨している。開発者や組織は、公開されている悪意ある拡張機能IDの一覧と自環境を照合し、該当するものがあれば速やかに削除するとともに、mangorbit[.]com宛ての通信をブロックする対応が求められる。

概要 GitHubは8月3日、GitLabからGitHub Enterprise Cloudへのリポジトリ移行を支援する「GitHub Enterprise Importer」のGitLab対応機能を一般提供(GA)に移行したと発表した。これまでプレビュー段階だった機能が正式版となり、gh gl2ghというコマンドラインツールの拡張機能を通じて、GitLab.comおよびGitLab Self-Managed環境からGitHubへの移行を自動化できるようになった。エンタープライズ規模での開発基盤の統合や、複数のバージョン管理サービスを利用している組織の一本化ニーズに応える機能といえる。 技術的な詳細 GitHub Enterprise Importerは、単一リポジトリの移行だけでなく、スクリプトを用いた複数リポジトリの一括移行にも対応する。移行時のデータアーカイブの保存先は柔軟に選択でき、GitHub所有のBlobストレージのほか、AWS S3やAzure Blob Storageといった外部ストレージを利用することも可能だ。これにより、組織のセキュリティポリシーやデータ管理方針に応じた移行運用がしやすくなっている。 なお、移行先はGitHub Enterprise Cloud上のgithub.comまたはghe.comに限定されており、オンプレミス版であるGitHub Enterprise Serverへの直接移行には対応していない点は留意が必要だ。移行元についても、gitlab.comおよび現行でサポートされているバージョンのGitLab Self-Managedが対象となる。 導入方法 詳細な移行手順は、GitHubが公開している公式ドキュメント「Migrating from GitLab to GitHub」で案内されている。大規模な移行や複雑な要件を抱える組織向けには、GitHubの「Expert Services」チームによる専門的な支援も用意されており、移行計画の策定から実行までのサポートを受けられる。

概要 セルフホスト型の監視ツールとして人気の高い「Uptime Kuma」の開発チームは8月2日（日本時間）、バージョン2.5.0をリリースした。今回の目玉は監視機能の拡充だけでなく、開発リポジトリ自体のnpm依存関係管理にサプライチェーン攻撃対策を組み込んだことだ。具体的には、.npmrcにmin-release-age=14という設定を追加し、npmパッケージが公開されてから14日間が経過するまで、依存関係の更新に取り込まないようにした。これはnpm CLI自体が備える比較的新しい機能で、悪意あるバージョンが公開直後に自動更新で取り込まれてしまうリスクを下げる狙いがある。 技術的な詳細 min-release-ageはnpmのインストール・更新処理に対して、指定した日数（今回は14日）より新しく公開されたパッケージバージョンの採用を保留させるオプションだ。Uptime Kuma開発チームはこれを44名以上のコントリビューターによる今回のリリースの一部として、依存関係更新のPR（#7508）でリポジトリ全体に適用した。近年、npmエコシステムでは公開直後の正規パッケージのメンテナーアカウントが乗っ取られ、悪意あるコードが混入したバージョンが数時間から数日で拡散する事件が相次いでいる。多くの場合、問題のあるバージョンは発見後すぐに取り下げられるため、一定期間の「クールダウン」を設けるだけで被害を回避できるケースが多い。今回の変更は、Uptime Kuma自体の開発・ビルドプロセスを対象にしたものであり、エンドユーザーが監視対象に対して使う機能ではない点に注意が必要だ。 監視機能の新機能 セキュリティ対策以外にも、監視機能そのものへの追加が多数行われた。ネットワークタイムプロトコル（NTP）の同期状態を監視できる新しい監視タイプが加わったほか、これまで24日が上限だったチェック間隔の制限が撤廃され、より長い間隔でのポーリングが可能になった。Dockerイメージ面では、非rootユーザーで実行できるnext-rootlessタグが新たに提供され、コンテナ運用時のセキュリティ強化に寄与する。このほか、Plivo・Ooredoo（モルディブ）・WxPusherといった新しい通知プロバイダーの追加、SMTP通知への追加ヘッダーオプション、MQTT監視でのmqtts://対応など、細かな機能拡張やバグ修正も多数含まれている。 今後の展望 min-release-ageのような公開後クールダウンの仕組みは、npmパッケージを大量に扱うOSSプロジェクトにとって、比較的低コストで導入できるサプライチェーン対策として注目されている。Uptime Kumaのような広く使われるセルフホストツールが具体的な設定例を公開したことで、同様の対策を検討する他のプロジェクトにとっても参考になりそうだ。一方で、この仕組みはあくまで開発側のビルド・依存関係管理を守るものであり、エンドユーザーが自身の環境にUptime Kumaをデプロイする際のセキュリティは、引き続き利用者自身によるアップデート適用やアクセス管理に委ねられている。