はじめに
皆様いかがお過ごしでしょうか。ACS事業部亀崎です。 （例年の10月と考えたらまだ少し暑いかもしれませんが）10月に入ってやっと過ごしやすい気候になってきたかと思います。
過ごしやすくなってきたところで、新しい取り組みをご紹介したいと思います。
今回取り組むのは「GitHub Advanced SecurityのAlertをBackstage Notificationsに通知しよう」というものです。
BackstageとBackstage Notifications
この記事をご覧の方々ならば、もう Backstageとはなにかということはご存知かとは思いますがあらためて。 Backstage はオープンソースの開発者ポータルフレームワークです。組織内にある様々な開発アセットをカタログ化し、その開発状況やドキュメントを集約・表示するものになります。
その他細かいことはこれまでにも本サイトで多数ご紹介させていただいていますので、ぜひそちらをご覧いただければと思います。
そんなBackstageの機能の１つがNotificationsです。こちらも2025年9月投稿の記事でご紹介させていただいております。 簡単にいってしまえば、さまざまな通知をBackstageのユーザー宛に通知し、表示するというものです。
GitHub Advanced Security
GitHub Advanced Securityについても、紹介するまでもないかもしれません。本ブログでもいくつか紹介させていただいています。
GitHub Advanced Securityの主要な機能を挙げるならば以下の３つになると思います。
- Dependabot Alert
- Code Scanning
- Secret Scanning
Alertの表示（いかにして検出されたことに気づくか）
これまでの気付きのタイミング
こうしたセキュリティチェックの機能ですが、それらのツールで検出した場合、皆さんはどのような形で認知していますでしょうか？ 電子メール？それともGitHubのUI上で確認していますか？
電子メールであれば検出後いづれかのタイミングでユーザーに通知がプッシュされてくるため比較的気が付きやすいかもしれません。 しかし、電子メールというのは他にも様々な通知が届くものです。一度既読にしたあと対応をしなかったりすると忘れされれてしまうということも発生します。
気づきを得るきっかけの１つとして Backstage の Catalog機能のGitHub 拡張機能もあげられます。たとえば、未解決の（クローズしていない）Dependabot Alertの件数などは以下のような表示が可能です。
こちらの情報は今の状態を示すものであり、もし対応漏れがあったとしたら画面を見た段階で気づきます。
しかしユーザーが能動的に情報をプルしない限り表示するきっかけにはなりません。ここが弱点です。
あたらしい気づきのタイミング
電子メールのようなプッシュ型の機能で、かつ多数の情報に埋もれないもの、または最新の情報を見せるもの、というのが一番求められると思います。こうした機能の形として、今回 Backstage Notificationsの利用を考えてみました。
Notify GitHub Advanced Security event to Backstage
実現イメージは以下のように考えました。
GitHubから Dependabot Alert、Code Scanning Alert、Secret Scanning AlertのイベントをWebhookでBackstageに通知します。
Backstageでこれを受信したら、発生しているリポジトリを特定し、Backstage内のカタログ情報から
リポジトリと関連付けられているComponentカタログを特定します。そしてそのカタログ宛にNotificationsを送信します。
Notificationsはカタログ情報のオーナー宛にその通知をディスパッチします。
これにより、Backstage上のリポジトリオーナー（ユーザー）にBackstage上で通知を表示することができるようになります。
もちろんこの通知はBackstageにサインインしなければ確認することはできません。しかしBackstageは開発者ポータルです。 開発者ポータルというのは開発・運用上の様々なシーンで日々アクセスするものです。したがって、Backstage上の通知に気づく機会は 多いと思います。
さらに、Backstageの通知機能は必要とされる情報のみが利用するもので、電子メールのように多数の情報に埋もれるリスクも少ないと思います。（表示されているものは何らかの対応・解決をしていかなければならないものなはずです）
実際の表示イメージ
では実際にどのようなイメージになるかご覧いただきましょう。
まず左下にNotificationsというメニューがあります。そして未解決の件数（ここでは「１５」）が表示されています。これにより、確認しなければならないレコードがあるということにすぐに気がつくと思います。
そしてNotificationsの内容です。
今回の実装は表示内容をGitHub上で表示される内容と類似のものとしています。もちろんどこのリポジトリで発生しているものかがわかるように、リポジトリ名称は表示するようにしています（ここのイメージではマスクしている部分です）。
タイトルの部分をクリックすると、GitHub側のAlert通知の詳細画面に遷移するようにしています。これによりすぐに内容を詳細に確認し、修正等に取り掛かることができます。
対応にどれくらいの時間がかかったか？
今回の機能を実装するのには、以下の手順で行いました。
- GitHub Webhookの内容（どのような情報を得ることができるか）
- Notificationsの通知方法の検討（Backstageのインターフェースの調査）
- Event受信部分の実装方法の検討
- 実装
まず前提として、私自身いくつかのBackstage Pluginの実装経験があります。このため、拡張Pluginを作るための基礎知識は持っていた状態です。このため、この部分の時間はほぼゼロです（Backstage Pluginの開発で一番最初に躓くのは実はこの部分でもあります）。
さらにWebhookを受信して何らかの処理を行うPluginというのは別のケースで実装したことがありました。このため、概ね「こんな感じで実装できるはず」というのは理解していました。なので「Event受信部分の実装方法の検討」はそれほど考えずにすぐに方式を決定することができていす。
そしてNotificationsの通知方法です。以前ご紹介したNotificationsの記事でも取り上げているScaffolderから通知する機能 というよい例があったので、こちらを参考にさせていただきました。とてもインターフェースもシンプルでわかりやすいため、戸惑うこともなく方式もすぐに決定できました。
一番時間をかけたのは実は最初のGitHub Webhookの内容の確認だったかもしれません。どういったイベントがあり、どういった内容が通知されるのか、 そしてその内容とBackstage Notificationsのマッピングをどうするか、こうしたところを検討した時間が一番長かったと思います。 このタスクだけに集中して取り組める状況でもなかったので細切れの時間の中で、１週間程度さまざまな情報を整理しながら決定していきました。
ここまで整理できればあとは実装だけです。いま話題のAIでやれば速かったのかもしれません。しかし、上記のような調査でほぼコードのイメージはできていましたし、
実装しながらコードの整理も同時に進めていたため概ね手動で実装しました（もちろん部分的にはGitHub Copilotのコード補完機能を活用しています）。
こちらも細切れの時間枠のなかで行ったのですがトータルで３−４時間程度だったかもしれません。
実際の実装作業などはAIの活用を工夫すればもっと早められるかもしれませんが、やはり一番時間がかかるのは構想の部分ですね。AIで情報を収集することはできても、それをどう活用するかは人間次第になると思います。
とうことで「GitHub Advanced SecurityのAlertをBackstage Notificationsに通知しよう」についてはいったん完了です。 情報を整理しBackstage上に表示することができれば、さまざまな気づきを与え作業を推進することができるようになることが確認できました。
最後に
さて、今回実装した機能ですが、もう少しだけ細かい機能を付け足したのち、弊社のBackstageのManaged Service「PlaTT」に組み込む予定です。 （申し訳ありませんが、このPluginをOSSとして公開する予定はありません）
もしこうしたPluginに興味を持たれた方がいらっしゃいましたら、ぜひご連絡をいただければと思います。
Backstageには他にも開発者の認知負荷を低減する様々な機能が存在します。その効果も使い方次第でより大きくなります。 ご興味のある方がいらっしゃいましたらぜひ弊社までご連絡ください。よろしくお願いします。
