1. Replay.fm
  2. #80 平穏を願いたい回
#80 平穏を願いたい回
2026-03-31 1:26:43

#80 平穏を願いたい回

下記の記事についてわいわい話しました。


https://sota1235.notion.site/80-32dbb64fc8cf80d9a527cb39253e7264?pvs=74


おたよりはこちらから

⁠⁠⁠https://forms.gle/ZuKfoj47B2Uc9ZuS7⁠


感想

まだ感想はありません。最初の1件を書きましょう!

サマリー

今回のエピソードでは、第80回を迎え、パーソナリティの近況報告から始まりました。第2子が誕生したばかりで、入院中の大変な状況ながらも収録を続けているという話がありました。AIの波がトピック供給に大きく貢献していることに触れつつ、AI技術の進化が「作る」ことのハードルを下げ、人生観を変えるほどのインパクトを与えているという感想が述べられました。記事紹介では、Trivyの脆弱性、Claude AIのプロンプトインジェクション、Open-LLMのセキュリティリスク、ソフトウェアサプライチェーンのリスク、フィッシング詐欺の減少、GitHub Dependabotのマルウェア検知機能、データセンターへの攻撃、そして国産のセキュリティツール「匠ガード」について議論されました。特に、AIの進化とセキュリティのあり方、そして国際情勢がサイバーセキュリティに与える影響について深く掘り下げられました。全体を通して、AI技術の進展とそれに伴うセキュリティ上の課題、そしてそれらにどう向き合っていくべきかというテーマが中心となりました。

オープニングと近況報告
こんばんは、Replay.fm 第80回です。 こんばんは、80。
80です。 80。 80ですね。なんで、4週間の20、20ヶ月ですか。
1年8ヶ月。 8ヶ月。1年8ヶ月。しかも、1回私の編集ミス以外は解禁症というか、だから収録は1回も休まずにやってるっていうね。
はいはいはいはい。 80回、よくやってますよ。
なんか、よくやってるよ。
しみしみ。あの、あれなんですよ。あの、そういえばなんですけど、ツイッターでツイートしたんで、知り合いの方はご存知だと思うんですけど。
第2子が生まれまして、5日前か。5日前に生まれまして。
で、ただいま1人目がいるんで。
で、ご経験の方はご存知だと思うんですけど、その、出産後って1週間ぐらい入院しなきゃいけないんで。
病院で産む場合は入院しなきゃいけないんで。絶賛1オペ5日目ぐらいなんですけど。それでも収録は休まずに頑張りますという。
無理してないですけどね。無理してないんですけど、はい。 よくやってるよ。よくやってます。
なかなか、その仕事以外でさ、毎週必ずやることって、なんか、この、マジで必ずやることってそんなにないよね。ないと思うな。
なんか、ないし、その、作ら、もうめっちゃ意識的にやらないと、なんか、昨日にのっちゃえばいい気がする。
それ言うと僕、いやだから、毎週必ずではないな。パーソナルジムはね、3年ぐらい続いてるんですけど、
さすがに今は一時的にお休みしてるから、ちょっと必ずではなかった。マジで、マジでこの収録だけかもな。マジで毎週やってる。
いやー、あと20回で、100回。うん。 20週間だから5ヶ月。
そう、うん、そうだね。 4、5、6、7、8、8、夏にはだから、100回か。 うんうん。
いやー、なんか、なんか、まあそうですね、しくしくとやるんだろうけど。
要は喋ることなくなんないよな。
いやー、このAIの波がなかったらどうだったんだろうね。その、AIトピックがもう、無限に供給されてくるから、
なんだかんだそのラベル付けしてると半、いやーでも3、4割ぐらいなのかな、AI系トピック。
うん。 でもAIが流行ってなかったら流行ってなかったら、なんか流行ってたのかな、ちょっとわかんないですけど。
まあでも、なんかしみじみいろんなことが起き続けてる感じはするね。
まあそうだね、なんか言うて別にそのさ、なんかAIでこんなことができるようになりました、みたいな話をめっちゃしてるわけでもないじゃん、正直。
そうだね、全然。 うん。
もうAI以外もそうだったね。 なんか、そうだ別になんかAI周りのその話題に超乗っかってるっていう自覚は正直あんまなくって、
なんか割とこう、なんて言ったらいいんだろう、こう、どっちかというと多分実践派じゃん、我々は。
そうだね、そうだね。 その、なんていうか、動かして使ってを多分やってる側で、なんか、
使える使えないは結構シビアに判断してて、なんかビジネスロジック周りの脆弱性とかはなかなか、まあパッと渡すだけだと無理だなとか、
簡単なCTFの問題はもう問題文とファイル渡したら、よし、何やっておいて、解いてくれるなーとか、なんか、
何ができて何ができないのかっていうのは結構厳しく見てる側だと思うから、
お祭りに乗っかってるみたいな自覚は正直なくて、まあ事実そうだと思うし、
まあそういう意味でなんか、まあいくつかある波のうちの一つって感じかもね、AIとか。
まあただなんかその、なんて言ったらいいんだろうな、なんか、あの、なんだろうな、なんかブログにも実は書いたんだけどその、
なんかこうやり方わかるし、作れるのもわかるけど、個人的になんか別にその、めちゃくちゃ手が早く動く人ではないので、僕はなんか、
その、なんて言ったらいいんだろうな、なんか、結構その作るというハードルがめっちゃ高かったんだけど、
それが変わったことによって、なんかハードルがめっちゃ下がったことによって、なんか、人生観が変わるみたいな感覚が明確にあって、
なんか、まあいい時代だなっていう感じですかね。
そうだねー、なんか、欲しいけど作ったら1週間かかるかなーみたいな。
作ることじゃねーな。
うーん、そういうのはマジでもうほぼなくなっちゃう感じがするねー。
ことなんかインフラの知識があればもうほぼないって言って過言じゃないかもね、なんか、
マジのガチのその未経験の人が、本番デプロイまでいけるかで言うと、まあいけちゃうんだろうけど、まあいいや、はい、まあそんな感じに粛々とやっていきますかね。
Trivyの脆弱性と対応
えー、というわけで記事を読んでいければと思うんですけど、まあお便り、引き続きGoogleフォーム、ツイッター、ハッシュタグ、ツイッターじゃない、Xハッシュタグ、お待ちしてます。
いつまでたってもツイッター。
まあ、もうおっさんだからね。
いやー、そうだよな、おっさん判定だな、はい、気を付けてこう。
なんかアニメを漫画と呼ぶ、呼ぶ大人をなんかバカにできなくなってくるよね。
そんな、そんなあるんだ、知らんかったすね。
えー、気を付けてこう。
はい、じゃあ、1個目からいきますか、お願いしようかな。
えー、2026年3月19日のトリビー最新外の概要と対応指針。えーと、ツバメのブログっすね。
えーと、これ実はちょっとサラッとしか読めてないんだけど、なんか、あの、最初さ、その、なんていうか、もうトリビーっていうキーワードだけ見えたから、その、なんか、なんか追加でまとめが出たのかなと思ってたんだけど、全然そんなことなくって、またやられたんですね。
またやられましたね。
またっていうのは、1回目はリポジトリが消えて、
そうだね。
消したのかな。
で、2回目が、で、たぶん事件は繋がってて、その1個目のリポジトリ消えたときにパッド取られてて、で、そのパッドのローテーションはしたはずだったんだ、したっていうかしてるんだけど、
そのパッドを元にちょっと技術的詳細はわかんないんですけど、あの、なんか別のトークンを払い出されちゃってて、
で、それ使ってまた侵害されちゃって話っぽいので、ちょっと繋がっているって感じで。
そこだけ見たいな。パッドを元にの部分が気になるな。
えっとね、侵害の起点がこれですね。2月28日にプレリクエストターゲットで、
で、この時はアカボットっていうそのボットアカウントがいて、まあいろんなオートメーションするためのやつがいて、そいつに紐づいてるパッドがあって、
で、このパッドがリポジトリシークルに入ってたのかな。
で、これがプレリクエストターゲットを使ってるワークフローの脆弱性、
脆弱性というかまあ、まあ脆弱性かな。脆弱性を発揮されて盗まれたっていう。
で、最新外の3月19の部分がこの取り消し線で書かれてるけど、
ローテーションしたっていう風に公式ディスカッションで言ってるんだけど、
この表現がちょっとよくわかんなくて、そのプロセスがアトミックでなかったため、
攻撃者からローテーション後のトークンも取得した可能性があるとのことですっていう。
ここはめちゃくちゃ何だろうな。
なんかアトミックじゃないって言ってるってことは何だ。
部分的に何らかその権限が残っててっていう話なのかな。
もしかしたらローテーションして同じシークレットに突っ込んじゃったとかなのかもね、もしかしたら。
でも穴は残っちゃっててとかなのかな。
でもさすがに直した後でしょ、そのローテーションって。
そうだね。これ公式ディスカッションみたいなのがわかるのかな。
わかるのかな。
3月19、なるほどね。公式のレポートがあるんだね。
シークレットレポートのプロセスは攻撃者がアクセスできた可能性がある。
全ての児童アクションとトークンをロックダウンする。
まあでもだから初回の、まあめちゃくちゃ、
あれだね、公式情報も全く同じ表現だから。
わかんないね。ただまあ不完全だったってことかな。
そう解釈するしかないかなって気もする。
なんかいろんなもののオートメーション使ってるんだろうね。
なんだろうね。だってPAT、PATってだってそんなローテとかないよね。
リフレッシュの仕組みって別にないよね。
いや、ある。あります。
PATがPAT自身でリフレッシュできるの?
それは知らないな。
新しいPATを発行できるじゃん。
同じファイングレインドトークンをUI経由でリフレッシュすることができるから、
もしかしたらそれをやられたって話なのかな。
でもそれをPAT経由ではできないと思うんだよね。できるのかな。
UIであるってことはAPIが提供されててもおかしくない気がするけどね。
いやー、見てみましょう。
ファイングレインドトークンはあるんですよ。
トークン取得とかもあるから、ワンチャンあるんじゃないかな。
もうあいつMiniはできないって言ってるけど。
そのファイントークンが持ってるアクセススコープを広げるようなAPIはあるから、
202になるのか。
え、もう一回言って。PATでPATのスコープを広げるってこと?
うん。
アップデートアクセスとオーガニゼーションリソーシスビアファイングレインドパーソナルアクセストークンっていう。
でもそれPAT自身でできるの?
うん。このエンドポイントはPATで使える。アクセスできる。
わー、そうなんだ。
で、そのUIで同じことするとどうなるかっていうと、
リフレッシュ強制されたと思うんだよな。
多分だけど。
あ、でもリジェネレートか。
トークンはもしかしたら別にリフレッシュされないかもな。
ごめん。リフレッシュはされずに、でも権限は拡大できるって話っぽいな。
一回言ってたのがこのリジェネレートの話でした。
うーん。
まあ、なんでしょうね。結局ちょっと。
わかんないね。
わかんないね。
なんか、うーん。
パッと考えられるのは、ワークロを直してリポジトシークレットの中身、リボークした形に作って入れるっていうのをやったのか。
うーん。
でもさ、その手順ミスるとさ、怪しいよね。
ワークロ直してリボークする前に新しいの設定しちゃったら、新しいの抜けるのかなどうだろう。
まあいいや。
もやっとしますけど。
まあでもこの記事自体はTrivyの最新規が何があったかっていうと、
Trivyのリリースかな、リリースされたコードに改ざんされた悪意のあるコードが混ざっちゃってて、
それがワークフロファイルに入っちゃってたって話なのかな。
TLDRって言うんですけど。
Trivyの0.69.4、バージョンの0.69.4はリソムですよと。
あとはGitHub Actionsの2つ、セットアップTrivyとTrivy Actionは悪意のあるものが入ってきたっていう感じですね。
Trivy自体はこの偽バージョンにはコード自体には悪意のあるものが入ってないっぽいんだけど、
ワークフロフの部分に悪意のあるものが入ってたって感じかな。
今さ、リジネレートして古いPATでアクセスしてみたっていうか、実はさせてみたんだけど、アクセスできるね。
じゃあちょっとラグがあるのか。
普通にだからラグがあるのか、死なないかのどっちかじゃない。
リボーカーされないんだと思うよ。
えー、困るねそれは。
リジネレートってあれか、そういうことか。
多分そういうことだと思うな。
少なくとも即座に古いのが消えるってことはないっぽいね。
ちょっとミスリードな機能ですね。
まあちょっとあれなのかもね。時間が空くのかもね。
はい、まあまあ試してみましたという話でした。
めちゃくちゃあれですね。日本語でここまで詳しく書いてる記事あんのかな。
僕ちょっとこのソード実はあんまりリアルタイムでキャッチできてなかったんですけど、
基本的にはこのポッドキャスター何回も紹介してきたワークロー侵害系の基本的な攻撃をやられちゃいましたよって話かなと思えば。
めちゃくちゃ高度なことをやってるわけではないとは思ったかな、全体見たときに。
対策も対策及び対応も基本的なことをやってくださいっていう。
まあいかない詳しく書いてあるんで。
これなんかあれだね、技術的な詳細の部分はあんまり知らなかったから普通に勉強になったわ。
インポスターコミットとかなんかちゃんと理解してなかった。
この辺の用語かな、僕あんま紐ついてないんだよな。概念は知ってんだけど。
これできるの知ってた?
うん、これは知ってたよ。
あ、そうなんだ。知らんかったな普通に。
これはね、そうなんですよ。
なんかこういう攻撃手法をまとめたどっかのページがあったと思うんだけど忘れてた。
いくつかね。
このGitHub Events APIでいろいろ取れるのは知らんかったな。
外部からいろんなコードロゴのに。
Events API何かっていうとこのリポジションこの人がここで何をしたかみたいなのを
API経由でパブリックであれば多分取れるって話で
それでその攻撃者の後しどりを追うってこと。
なるほどね。
実中でやってて。
これはなるほどねって。
なんか自己調査の手法としてはかなり使えそうだなっていう感じがしますね。
これもうトリビーがやられるんでもう全然、やっぱまあ再三言ってるけどもう起きるものだと思って活動していくしかないなって気持ち。
なりますなって感じですね。
インポスター、なんかさ、サインドコミットの話が出てたと思うんだけど
インポスターコミット今回のケースでは攻撃者がコミットのオーサーコミッターフィールドを正規のメンテナーに偽装していましたが
GitHub UIで正規にマージされたコミットに付与されるGPG署名
GPG自動署名を再現できずVerification Verifiedがフォルスを返していましたって言ってたんだけど
サインドコミットってPATだと全く再現できないのかな?
できるはず。APIがある。
やってないだけだよね多分これね。APIがあんの?APIはなくね。
あんのか。
なんかGitHubでサインドコミットすること、GitHub Appでサインドコミットすることはできるの知ってんだけど
結構複雑なことやってたはずで。
パッドじゃないのか。
パッドでも多分同じAPI叩けると思うから
API経由っちゃAPI経由だと思うんだけど
GitHub Actionsとかで俺がやらせてるのはあれだね。GHCLI経由でやらせるやつだね。
っていうかなんかちょっとハックな感じのやり方で。
コミットに対して何かのAPIを叩くと署名ができるみたいな感じだった気がする。
あ、そんなのあるのかな。
そう、だからそのAPIをパッドで叩けるんだったらいけるんじゃないかな。
それこそ鈴木俊介さんが書いてた気がするんだよな。
なんかね、Creator TreeっていうのがGitHub相当でそれを元にベリファイされるみたいな。
サインドコミットじゃなくてベリファイドなんだよな。
あーなるほど。
ちょっとなんかノーションの方に貼っちゃうけど。
GHCPか。
GHCPってツールがあるけどこれの実装を見ればわかりそうだな。
あとなんだっけ、結構有名どころのGitHub Actionsの
コミットしてプルリクエスト作るみたいなやつがあったと思うんだけど。
それも確か対応してたっす。
あーそうね、パッチ、そうパッチでなんか叩くんだよな。
これは多分PATでも叩けるよね、きっと。
そうだねー。
うーん、ちょっとちゃんと見ないとわかんないけど。
だから今回、今回これが再現
難しいな、ベリファイ、えっと
ベリファイドでないのがヒントになってるけど
ベリファイドでないのは多分たまたまなんだよね、きっとね。
まあそうかもしんないね。
だからその検知ポイントとして書かれてるけど
だからそのコミットサインをベリファイド
なんかサイン、サインドコミットをリクライドにしてたら
防げたのかな、もしかしたら。
いやでもなー違うんだよな、コントリビューターがいるから
OSSむずいなー。いやOSSしんどいなー。
サインドコミットを
強制してても
無理だとも言ったけど
強制してたら
いや無理だな、だからタグ
あれってタグにも適用されるのかな
タグは別にコミットではないから
そうだよね、だからサインドコミット関係ないよね、あいつね。
だからサインドコミットだけだって意味なくて
別に
いや例えば
コントリビューターがホワイトリストで定義できるんだったら
このメールアドレスのサインドコミットだけを
プッシュさせるっていうプッシュルリセットを書くとかができるんだけど
だからその社内に閉じたプロジェクトとかだと
その会社のアドレスで
のサインドコミットしかプッシュできないっていう風にすると
第三者は
パッド取られたらダメかな、でも
パッド取られたらダメか、言ってみたけどダメっぽい
でもパッド取るだけだとどうなんだろう
アクアボットがコミットするユースケースがあるかどうか次第
今回のケースで、それがないんだったら
別にこいつのパッド取られても大丈夫なはずで
その設定ってどこにあんだっけ
プッシュルリセットかな
書くよ手元でって感じなんですけど
プッシュルリセットの
ブランチルリセットだっかな
ブランチじゃないかな、ブランチの気がする
リクアイはサインドコミットはあるけどさ
別にこのメールアドレスのみたいなのないよね
オーガニゼーションかな
コミットメタデータじゃない
リストリクションズのコミットメタデータで
オーサーEメールとかコミットEメールっていうのがあって
これはメール
これは独立じゃない
前も何かで話したけど
このメールアドレスの人が署名しましたよっていうのを
コミット署名は担保してくれないじゃん
はいはいはいはい
そのGitHubのアカウントとメールアドレスは
基本的にそんなに結合してないはずで
署名鍵があくまでアカウントに紐づくものであって
別にこのアカウントの持ち主が署名した用は
はっきりするんだけど、その鍵の所有者であるっていうことによって
このメールでっていうのは多分ないはずなんだよね
リクエアサインドコミットを有効にしただけだと
何かしらの有効な署名がついてれば
OKっていう
メタデータリストリクションの方は確かにオーサーEメールとかは制限かけられるんだけど
別にこれ自体はGit Configの話だから
多分何でもいいはず
これちょっと検証してくるわ
そうなるとリクエアサインドコミットの意味があまりないよな
リクエアサインドコミットは
誰がコミットしましたよを
はっきりさせるっていう効果はあって
少なくとも、だから例えばGitHub Appが
署名をしましたよみたいな話であれば、このGitHub Appによって
コミットされましたよっていうのははっきりするし、人がコミットしたのであれば
このGitHubアカウントの持ち主が署名しましたよっていうのははっきりする
でもサインドコミットじゃなくてもカンサログとかで
結局プッシュするためには必ず何かしらの認証をしてるはずで
認証をした上でプッシュしてるからカンサログで
誰がプッシュしたかっていうのは見れるんだよね
それはあくまでGitの世界の話とGitHubの世界の話だから
全然違うレイヤーの話なんじゃない
プッシュしたのが誰であれそこのコミットに誰のコミットが
入ってるかっていうのはまた別の話じゃん
そう、まあなるほどね
確かにそれはそうかと だからそこはまた別軸の話
なるほど、理解
いやー、むずいな
トレーサビリティの観点では全然役に立つと思うけど
じゃあ私のなんかふんわり
考えてた妄想をちょっと打ち砕かないや
検証してみよう
だから裏でその
いやでもそういう挙動にはなんないと思うんだよな
多分わからんけど
検証記事お待ちしてます
この機会に
調査しますわ
じゃあ次いきますか
はい
Claude AIのプロンプトインジェクション
クロスAIプロンプトインジェクションバレナビリティ
オアシスセキュリティっていうところ
記事ですね
うーんと
ネタ系の話であるんだけどクロードAIっていう
チャットGPTみたいな感じなのかな多分
オープンAIでいうとこのチャットGPTみたいな感じで
僕らが普段触っているクロードコードとは別に
クロードとチャットができるみたいなサービスが普通にあって
コワークとかが最近はちょっと出てたりするんですけど
なんかそういうのがあるんですけどそこにプロンプトインジェクションの
脆弱性がありましたよっていう話ですね
結構カジュアルにさせてよっていう話で
面白かったので持ってきていて
ツイートするボタンを押すと
投稿する内容が入力済みの状態で
Xの画面ツイートするとか言っちゃったまた
Xのシェアボタンを押すと
投稿する内容が先に入力された状態でXの画面が開く
みたいな機能をよく見かけると思うんですけど
あれと同じ感じでボタンを押すと
特定のURLパラメータに文字列を入れると
それがあらかじめプロンプトとして入力された状態でクロードAIの画面が開く
っていう機能があるらしくてそこに
散々多分このポッドキャストでも紹介してた
ふかしの文字でプロンプト入れると
LLMはそれも解釈しちゃうよって話があったと思うんですけど
それを仕込んでおくことによってプロンプトインジェクションが成立してしまうよって
結構自動的な大体自動的かプロンプトインジェクション
かなり自動的なプロンプトインジェクションの中でもかなり
自動よりの攻撃だなと思ったんだけどそういう感じで成立するよって
話ですねなかなかふかし文字のやつとか
実際そもそもどうやって刺すんだよみたいなちょっと思ってたけど
なるほどそういう刺し方もあるのねって割と面白かった
ふかし文字は最近別のやつで
記事引っ張ってこいと見たけどプルリクにふかし文字を混ぜて
悪いなるコードを混ぜるとかもあるね最近とか
それをLLMに解釈させようとしてんのかそもそもLLM関係なくかもしんない
プルリクはいいけど一周とかのほうが早そうだよな
一周とかでもいいかもね
プラスこれは任意のプロンプトを
ユーザー側の認証されたクロードの環境で実行させて
それをその後に
ファイルズAPIだっけちょっと名前忘れたけど
クロードの何かの内容を
ファイルズAPIか何かに書き出す機能があるんだけど
これを他の人のアカウントのファイルズAPIに対して
なんか吐き出せるみたいな仕様がある仕様なのかバグなのか
わかんないけどあるらしくて
オープンAIとかも一緒ですけどメモリー機能
直近多分トークンの許す限り
直近の会話内容とか全部クロードとか
ちゃんとGPTが記録してるんでそこに対してあなたが覚えることを全部教えてって言って
欲しい情報を抜き出すプロンプトを混ぜた
リンクを踏ませて作らせた有用なデータを
じゃあここのファイルズAPIに吐き出しておいてねっていう風にして
データを持ち出すっていうことをしてた
流れとしては攻撃者がコントロールしてる
API機能を渡して自分のアカウントに対して書き込みさせるっていう流れだよね
あとはオープンリダイレクト
そうだオープンリダイレクトもあるから
クロード.comに仕上げにオープンリダイレクトを使って
Google広告にクロード.comドメインで広告を仕込んで
でも中身としてはクロード.AIに
リダイレクトするしかもアクリナルプロンプト付きでっていう
ものをやって広げるっていうこともできたようなっていう
おもろいねオープンリダイレクトの使い方としては結構いい
言い方があれだけどいい使い方っすね
割としょぼい脆弱性だと思いがちだけどこんな刺さり方するのちょっと
バカにできないね
これはなんかおもろいなと思ったな
なんかAIじゃない別に
クラシックな脆弱性の話もあるし
AI要素としてはアクセスできた後に
データを持ち出すデータを整形する
自由度の高さはちょっと面白いなと思ってしまった
そうだねクロードは設定画面見られる人は
わかると思うんだけどファイルを
生成するみたいな部分は設定でそもそも切れたり
するんだよね
そうなんだよ
チャットのクロード全然使ってないから
コード実行とファイル作成っていうのが
禁止できるようになってて多分禁止すると
これは刺さらないんじゃないかなちょっとわからんけどどうなんだろうね
多分プロジェクトじゃなくてアーティファクトかな
アーティファクトに多分書き出させたんじゃないかなと思うんだけど
ちょっとわかんねえな
確かオープンAIもこんな3つのやつじゃないけど
パーマネントリンクでプロンプトしてできるやつ悪用してなんかやられましたみたいなやつが
4ヶ月前ぐらいにあった気がしてて
それも最終的にGoogle広告に仕込んでたんだよね
チャットGPっていうのを正規のURLで広告で
プロンプト仕込んでそれ何ができたかちょっと思い出せないんだけど
プロンプト指定するのやめればいいんじゃないと思っちゃったんだけど
どうなんだろうね
URLでプロンプト指定できる仕様をやめられないのかなって普通に
結構これ残ってるうちは何ていうか
いたちごっこじゃない?
今回どういう修正をするのかわかんないけど少なくともファイルズAPI
ファイルズAPI塞ぎましたじゃあ持ち出しできなくなったからOKだよねって言われると
言えるかというとじゃあまた新しいAPI作って
とかAIの自由度が上がって色んなAPIを
立ててくれるようになったようになっちゃうと
一つはでもファイルズAPIと
アーティファクトが一致してるのかわからんけど
ファイルズAPIの書き込み先をサンドボックスの中に持ってくるぐらいじゃない?やるとしたら
サンドボックス外の他人のアカウントに書き込みが
できるっていうのが多分小悪の根源で
そもそもプロキシ経由じゃないと外に出らんないようになってんのよクロードのウェブ
の環境って あーごめんでも嘘ついたわ
クロードコードのウェブだから普通のクロードはわからんわそれで言うと
どうなってんだろうね
その経路が残ってる限りプロンプトインジェクションの本質的な問題って
誰が発行したプロンプト
っていうのをAIは正しく判断できないわけじゃないですか
あるとしたら例えばこのプロンプトは
URL経由で来たやつだから気をつけてねみたいな判定をさせるとかできる
かもしれないけどでもプロンプトとして入ってしまう
以上は本質的に立ちごっこになる
プロンプトインジェクション対策
に対して刺さるか刺さらないかのゲームになっちゃって刺さった時に
今回はファイルズAPI使いましただけど
このペースでAIにいろんな機能を乗せていくとファイルズAPIを塞いだけど
全く別のこの便利な機能みたいなのが出てきた時に
それを使うと実は外との通信ができるとか
APIを叩けるみたいになると
リスクとしてはずっと残り続けるというか
対処するのしんどい
このリスクを塞ぎ続けるのが結構しんどいんじゃないかなって
思ってるって感じかな
なんかちょっと外から
プロンプト渡せるっていうのがどういうユースケースを想定して作られてるものなのか
分かんないから何とも言えないけど
確かにやめちゃった方が早いよねっていうのは
その通りだと思うけど
なんか並々ならぬ思いがあって
やってるかもしんないし それはちょっと分からんな
はい
この機能使ってるよって人が言ったら教えてください
あんまな僕は
気軽にシェアしたいのかな難しいな
画像生成とかはもしかしたら結構シェアしたいとかあるのかもな
このプロンプト投げるとこんな画像が見たいとかあるのかもしんない
はい まあちょっと面白かったですね
おわしすぎてさ じゃあ次いきますか
Open-LLMのセキュリティリスクと運用
私から GMOサイバーセキュリティのブログで
オープンクローを取り巻く脅威を踏まえた安全な運用はあり得るのかっていう記事ですね
で 内容としては
ちょっと落ち着いたのかな ちょっと落ち着いたけど出たばっかで
名前がコロコロ変わったり
インターネット上に脆弱なインスタンスが
うんぜんだいあるぞみたいな感じで セキュリティリスクがあるとか
いろいろ騒がれてたオープンクローなんですけど これは安全に運用できるんですか
っていうところに対してかなり中立的に真摯に解説してくれてる
記事っていう感じです なのですごい読みごたえがあって面白かったんですけど
そもそもオープンクローってなんだっけみたいな ある種
紹介 復習みたいなところから じゃあこれ自体がどういうセキュリティリスクを
はらんでるのかっていうのを結構 そのオープンクローの
そもそものアーキテクチャとか技術スタックから紐解いていって
こういう部分は本質的に防げないとか ここはこういうガードレールがあるけど
みたいなのを解説してくれてるっていう記事ですね なので漠然と
オープンクロー危ないっていうのは 多分みんななんとなくソフトエンジニアに近い人だったら
思ってるし知ってることだと思うんだけど それをきちんと言語化してるとてもいい記事だな
と軽く紹介したいですという感じです
そうだな 印象深かったところが
何かみたいなのは結構難しいんですけど
一つ単純に知らなかったなと思ったのは
ローカルホストから
ローカルホストの
Webソケットに対して接続しに行くっていう部分で
穴が開いちゃうっていう部分が結構僕は知らなくて
何かっていうと オープンクローって基本的にパソコンとか
サーバー上で動くものになっていて
軽くオープンクローは何をするかっていうと 与えた手足に対して
もう完全に自律的に定期的にどんどんどんどん
いろんなことを勝手にやっていくし 何ら自分のスキルとか
自分の設定も書き換えていって かなり自律的に動くっていうものになってるんですけど
その中でブラウジングもするし
何ならお買い物とかも決済情報渡せばできちゃうしみたいな感じ
かなり自由度の高いものなんですけど そのオープンクロー自体に例えば
アクイのあるサイトにアクセスしたときに プロンプトインジェクションみたいな話もあるんですけど
アクイのあるサイトに
ローカルホストにアクセスするJavaScriptが例えば動いていたときに
ローカルホストに対してHTTPリクエストを送るっていうのは
ブラウザ側の制約で あんまりできることはない
ですけど 一方でWebSocketだと
許可してしまうケースっていうのがあるし
その許可されちゃうとレートリミット的なものがWebSocketは外れてるんで
かつオープンクローではWebSocketサーバーが動いてるので
何でもかんでもし放題 具体的には接続ができるよう
みたいなのとか レートリミットがないんで 認証突破みたいなので
そのブルートフォースが毎秒数百円別でできますよみたいな話とか
あとは脆弱性含まれてるバージョンだと もう採掘されたリンクをクリックさせるだけで
トークン取れますよとか 一回取れちゃうと
オープンクローの制御取れちゃうので
もう罪というかゲームエンドみたいになってしまうよみたいな部分とか
あとは結構きついなって思ったのは
オープンクローがいろんなことをできるってことは いろんなことに対するクレデンシャルを持ってるわけですけど
このクレデンシャルっていうのは基本的に このパスに平文で全部保存されてますよとか
その設定もこのパスに全部平文で保存されてますよみたいなのが
そういう仕組みになっちゃってるので 一回
例えば今のWebSocketのやつでトークン取ると じゃあクレデンシャル全部
何の認証もなしに読み出して それを前に進め出して
どんどんいろんなことをするとか あとはチャットCPTとか
クロードコードとかですかね と違って
オープンクロードってもう自律的に 永続的に動く前提になってるんで
ハートビートっていう仕組みが名前 確かそうですね
ハートビート機構っていうのがあるんですけど デフォルトだと30分ごとに自分で
エージェント立ち上げて ハートビート.mtっていうファイルがあるらしいんですけど
そこに書かれたことをバーって一通りやって
することなければ眠るし することあればそこでバーって動き出すみたいなことをするんですけど
これがあるせいで 一回
何かしらで侵入して 例えばもうハートビートって
mdの中にこのC2Cサーバーと通信して みたいなのか
多分もう何でもござれ LLMが何でも解釈できるように何でもござれ
で仕込んじゃえば映像化もかなり 安易にできてしまうよ
みたいな部分が アーキテクチャの本質的な
本質的というか構造上の問題としてあるよ みたいな部分が
今言ったのもかいつまんでいった感じなんですけど
かなりいろいろ丁寧にまとめられてるという感じですね
個人的に印象深いなって思ったのは
いろんな解説記事の一番最後に
一つはそもそもOpenGLの開発者が言ってることとしては
OpenGLはもうコビープロジェクター Cβ版だし
セキュリティは自分で責任取って寝てるし
セキュリティというのをめちゃくちゃ丁寧に書いてる これはもうある種
誠実な対応とも言える 別に嘘がついてないというか
セキュリティ的に使い方によっては一種があることを隠さずにやってるんだけど
一方でじゃあこれを このアーキテクチャのこの仕組みのものを
真にセキュリティを担保して動かすのに
必要なスキルがどれぐらいかっていうと 今のOpenGLの多分
99%のユーザーそうである
なんかいい感じに動くやつがあるらしいっていう人たちが
できるかというとほぼ不可能でしょうっていう部分が めちゃくちゃギャップがあるよねっていう部分と
あとなんかそもそもそのOpenGLの
思想とセキュリティのベストプラクティスってめちゃくちゃ矛盾してるよねっていう部分があって
それは確かにあって 例えばそのセキュリティで言うと
最小権限の原則ってすごいよく聞くやつがありますけど
必要な権限だけ
必要なときに与えましょうっていう
原理原則がありますけど ここに対してOpenGLって
オープンクローが提供した価値っていろんな手足を渡していろんな権限を渡して
渡してもう自律的にいろんなことをさせましょうっていう思想のものになってるんで
その最小の権限が
基本的にはもう使いたいユースケースに対して爆発的に膨らんでいってしまう
構造になっていて そこはなんかもう両立し得ないというか
オープンクローの言う最小権限って
あまりにスコープが広いよねみたいな部分とか
また信頼境界みたいな部分も
あまりにいろんなツール間の
境界とかWebとの境界みたいな部分も
性質上どうしても解き合ってしまうみたいな部分があって
そもそももうセキュアに運用できるような
シロモンではないよねっていう部分が最後にチラッと語られているし
最後に各種セキュリティベンダーとかマイクロソフトとか
セムクレープとか何か言ってるかで言うと
これがなんか僕は面白いなと思ったんですけど
すごく遠回しに皮肉だなと思ったんですけど 各社言ってることは超ざっくり予約すると
めちゃくちゃ安全なサンドボックスとかで
きちんと運用する必要があるよっていうのを
大体超予約すると言ってて それしちゃうとオープンクロー
使う意味って何なんだっけみたいな部分が結局あるから
そこは矛盾があるし
この記事の結論としてはセキュアに運用するのは
ほぼ無理というか一定リスクを飲まないと使えるものじゃないよねみたいな部分があるし
またセキュアに使おうと思っていけばいくほど結局
オープンクローの価値と明確にトレードオフになってしまうから
じゃあオープンクロー使う意味って何なんだっけみたいな部分になるよねみたいな部分を
書いてくれてるっていう感じですね
なんで結構丁寧に解説してくれてるし あとすごい良かったのが
オープンクロー危ねえぞって記事 バカって一時期海外メディアとかで出てたんですけど
多分意識してんのかわかんないですけど この記事ではかなり中立的に
オープンクローっていうものがあって どういうものかっていうのを見たときに
ここはフラットに見て危ない ここはこういうガードリルあるねっていうのを丁寧に紐解いて
そこがすごい効果を持てるなっていうのを思いましたという感じですね
オープンクロー運用してる方は
運用しててどうなんだろうって気になってる人とかは
読んでみると実像をつかむっていう意味ではすごい良いんじゃないかなと思います
僕はこれ見て
やっぱ使わんでいいやって思ったけど
なんか
どう
その
あえてこれをホビープロジェクトとして出してくれてるっていうのも結構面白いなと思ってて
最終的に世界が向かっていく先って
でも多分これの世界観じゃん
目指したいのはこっかもね そうだよね
ってなったときに新しいセキュリティのモデルがきっと必要なんだよね
最小権限の原則みたいなものとは
なんか違う何かがきっと必要になるはずで
だがそこめちゃくちゃ各社模索してる感じは
あるんだよね
全然紹介してないけど色んな概念を色んなベンダーが出してる気はしてて
一箇所ゲートへ設けて
そこで人間が判定するだろう
クロードコードとか最近あれだよね
オートアプローブと全部アプローブの中間みたいに出そうと
オートみたいな使えるようになってる気がする
そういうのも回答になり得ると思うし
でもなんか前段のアーキテクチャが変わんないと
結構ブレックスルー起きない気は個人的にはするけどね
やっぱりこの記事にも書いてあったけど結局プロンプトが入ってきたときに
ペイロードとシステムプロンプトの区別というのは
本質的につかないからそこのリスクというのはどうしようもない
という部分はオープンクローン開発誌も認めてるし
今のところどのLLMでもそこは統一というか
共通だと思うから
そこがどうにかならないと結構厳しいんじゃないかなという気はするんですけどね
ちなみにこの記事を見ながら
紹介記事には持ってきてないけどちょっとおもろって思った
話があるんですけど今中国でオープンクローン
めちゃくちゃ流行ってるらしくて
どういう流行り方をしてるかというとエンジニアとかじゃなくて
ありとあらゆる職種とか年齢の人がオープンクローンを欲しくて
Mac miniを買うみたいなことをしていて
僕が読んだ記事だと会社員の人が
何か起業したいなと思ってたソフトエンジニアの人が
オープンクローンの流行に夢をつけて
Exactoのサービスがパッと思いつかないけど
いくらでオープンクローンセットアップオンラインでするよみたいなやつがあったら
めちゃくちゃ依頼殺到したからこれいけるって確信して会社辞めて
起業して今100人ぐらいの会社でオープンクローンセットアップする会社をやってるみたいな
それが事業として成り立つくらいめちゃくちゃ流行ってるらしくて
で、それでちょっとおもろいのが
中国政府からその状況に対してオープンクローン危ねえからちょっと
使うなよみたいなのが政府から注意として出てるらしいんだけど
それはつゆ知らずめっちゃ流行ってるらしいっていう
なんかおもろーって思いながら見てました
なんかすげーなぁ
でも夢はちょっとあるよな
日本でもオープンクローンセットアップ屋さんやったら儲かるのかな
日本はなんかどうなんでしょうね
エンジニア以外はあんまり見ないですけどね
なんか笑ったのがそのオープンクローンってなんだっけ
ザリガニ飼育だそうザリガニだからなんかザリガニを飼ってるみたいな表現
ミームがあるらしくて
そうそうなんか高齢者の間でもとかそうだね
中国ではお前まだザリガニ飼ってないの
みたいなやりとりがあるらしい
すごい流行り方だなっていうか面白いなーって思いました
だから中国政府は頭痛いよね普通に
いろんな
まあ皆さん使ってる方はお気をつけてください
ソフトウェアサプライチェーンのリスクとAI
じゃあ次いきますか
次はこれ私か
2026年もソフトウェアサプライチェーンのリスクに立ち向かうために
プロダクトセキュリティスクエアナンバー3の
ツバメのGMOフラットセキュリティの米内さんの
スライドというか発表のスライドですね
なんか別にそんなに
ここっていうのはないんだけどまあ勉強になるなーっていう話ではあって
なんか結構印象に残ってるところで言うと
なんだっけどこだっけ
2025年の話を多分冒頭でしてて
2025年のソフトウェア産業は
なんか責任能力を持たないが水準の高い知的労働力が
調達可能な時代になったよってまつまるところそのAIとか
を指してこういうふうに言ってると思うんだけどそれが調達可能な時代になりましたよと
で直近はCTFすらPay to Win的話題を伴う
みたいな話があったりとかしてでだから欠点は唯一
責任能力がないことで収益する人間がまた責任を有してはいるよ
っていうのがなんか欠点だよっていうことを言っていて
一方で
例えばハーネスエンジニアリングっていうのが2026年に入ってから
アフレーズとして出てきてるもっと前からあったのかもしれないけど出てきてて
みんながそういう話を知らしてるんだけど
匠の場合こういうことやってるよっていう話で
ある機能のここを見るに問いを分割してからノンLLMで定義した
状況を満たすまで走らせるみたいなことをやってるよって言ってて
なるほどそんなことやってるのかって思いながらみたいなんだけど結構
セキュリティベンダーっていう立場で言うと
ある程度その責任能力を持たないといけない立場であるわけで
っていう中でその責任能力を持たない存在を活用してビジネスをやるの
しんどそうだなって普通に思ったという話がしたかっただけなんだけど
なるほどね
どこまで何を話せばいいのかわからんけど
匠はちょろっと触ったことはあって今がどうなのかわからないけど
結構個人的な期待からはかなり遠かったんですよね
でなんかこういうその責任の持ち方をしようとしてるんだなっていうのが
若干このスライダーの中で垣間見えたのでそれはなんか大変だなっていう風に思ったんだけど
責任ね
なんかでもこの間にさセキュリティベンダーがこう1枚挟まることによって
いろんなものが難しくなっちゃうんだったら
ベストの選択ってやっぱり自分たちで使うになってくるんじゃないかなって思ったりもするし
なんかこのビジネス難しそうだなっていう風にめちゃくちゃ思った
なんか責任
今自分の中でどう装飾したもんかって言ったんだけど
責任能力っていうのはだからAI単体を僕らがAI単体を捉えたときの表現だよね
なんかユーザー目線では別になんか責任を取るのは常にそのサービス提供企業であるから
なんかその中身がAIだろうと人間だろうとなんていうか
そのレスポンシビティみたいなのがどうなんだろうなっていうのも言ったり
あとなんかそうだなセキュリティベンダーに関しては1個僕の中でめっちゃ
ちょっとあんままとまんないまま話しちゃうけどなんか2つ思ったことがあって
1つはセキュリティベンダーが挟まる責任を取らなきゃいけないっていう
セキュリティベンダーの立場が挟まるっていう話があったけど
なんだろうな文脈によるのかな
診断
なんかさ例えば児童診断とかちょっと使ったことないけどさ
そのご顕著みたいなのがあるサースって多分あるじゃん
あるね
AIがなくてもじゃあそのご顕著って責任取ってないじゃんみたいな話かっていうと
多分利用者側がある程度慣れてるっていう部分があると思う
そうなんだよね
よくも悪くも
それはなんかなんで許されるかっていうと
なんて言ったらいいんだろう
なんて言ったらいいんだろうな
なんかわからんな
どうしても匠の話をしないとこの話ができないので
本当に匠というプロダクト自体はめっちゃ応援してるんだけど
ディスリタイートは全くなくて
あくまで個人的な期待からはどうかっていう
ただそれだけで触れるんだけど
遅いのよ
数時間待って出てくるレポートが
ここかこういう感じかっていう
俺が触った時にはめっちゃあったのね
でなんかでも確かにこういうそのなんていうかこう
もうらせるできるだけ担保しようみたいな
そのアプローチをもし仮に試してるんだとしたら
そこに時間がかかるっていうのめっちゃ納得するし
そのなんていうか
こうまるっとコードベース渡して
全部見てっていうのをやり切る
そのやり切らせるみたいな
AIにやり切らせるみたいなところはめちゃくちゃよくできてたんだよね
全部見るっていうところは確かにできてて
で一方でなんかめちゃくちゃ時間がかかるし
そのなんていうかなんとなくループに入ってるっぽい挙動とかも
たまに見受けられたりしたし
数時間待たされるっていうのがザラだったので
なんて言ったらいいんだろうな
その要はさ10分で出てきたものが
まだ荒くても別にいいんだけど
4時間かけて出てきたものがすげえ荒かった時にめっちゃ失望するのよ
別に求めてるのってそういうもうらせようがんばって担保しようとかじゃなくて
なんかこう今の段階で求めてるのって
こうなんていうか
なんか80点だけど10分で出てくるよ
多分求めていて個人的には
なんか
だからそこはなんかシンプルに責任云々っていうよりかは
そのサービスに対する期待値と
なんかニーズのズレみたいな話かなって気はするよね
だからそれは多分極論は中身がAIでもAIじゃなくても
なんか
まあそうね
同じ話かなって気はしてて
そうね
でなんかもう一つちょっと思ったのは
そのセキュリティベンダーが
はさまず自分でやるみたいな話で
なんか
何ならブログちょっと書こうかなと思ってたんだけど
だからちょっと思ってることがあって
その脆弱性診断がその
AIで置き換わって
AIが違うな脆弱性診断が今後どうなっていくかみたいなと
考えた時にその
前回かな
前回の収録をね今日編集
ちょうど編集してて
また思いはずってたんですけどその
何か脆弱性探すビジネスロジックの脆弱性探すとか
風になっていった時に今は
内製で診断するか
その外注して診断してもらうかみたいな分で
頑張って見つけようみたいな話
もしかしたらシフトレフトで内部で見つけようみたいな話が主流だと思うけど
そこにAIが入ってきた時にどうなるかみたいな部分で
今の論調だと
複雑なビジネスロジックが見つけられないんじゃないかみたいな
XSSとかSQL Injectionは見つかるけど
認可のロジックとか仕様に基づくものは見つからないんじゃないかみたいな部分に対して
前回僕たちは今はそうかもしれないけど
時間解決するんじゃないかプラス
それを判断するのに必要な
ドキュメントを自分
用意するっていうのがセットで
解決していくんじゃないかみたいなことを前回話してたんだけど
なんかこれが僕が言って
芯に近いかなと思ってて
これが芯だとすると
脆弱性診断のあり方が2極化するんじゃないかと
気はしてて1極は
結局さ
AIに脆弱性診断やらせようってなった時に
必要なコンテキストを用意しなきゃいけないのってどこまで言っても自分たちだから
自分たちで
それを模索してもしくは一般的なプラクティスが出てきて
それに習って自分たちでやれる企業と
それがやれないんで
外注し続ける企業と
あとはもしかしたら中間もあるかもしれないくて
SaaSなのかShotなのか分かんないけど
あなたたちの仕様書とか全部ください
コードくださいってそしたらうちのAIがいい感じに
複雑なビジネスロジックも加味して解決するよみたいな
ソリューション出してくる企業みたいな
そんな感じで分かれていくのかなっていう妄想をしてるんですよね
っていうのにさっきのベンダー挟まる意味みたいな
やけしのコメントを聞くと思ったりしてたんですね
だから
AWSの診断のやつとかは多分
ドキュメント食わせるとみたいな
名前忘れちゃったけど話とかあった気がしてて
今扱い物になるのかちょっと分からんですけど
なら結構
そこが分かれていくんじゃないかなって気はするんだよね
まあね
あとはAIパワードな診断をしますよみたいなサービスを
もっと売りにしていくとかもあるのかもね
そうだねそれはもうじゅっちゃく出てくるよね
それこそだから匠を中で回しますよみたいな
サービスをやってくれてもいいよね人がセットでね
そうだねそれは確かに
いやーそうですねどうなってくるんでしょうね
いやー
いずれにしても多分AI活用
セキュリティベンドに限らず全社そうなるかもしんないけど
競争する上では必須になってきちゃうんだろうね
従来の診断だけど内部的に効率化して利益を上げる
早くするとか
AIパワードを押し出すのもそうだし
もちろんあり方自体を変えていくみたいな
匠は一つかなと思うけど
メンダー未経験者が偉そうに語ってますけど
またアズレだったら申し訳ないが
でもなんかそうなる気はするんだよな
はい
まあねどっちの方向に転ぶかは正直わからんな
なんかどういう感じになるんだろうね
そもそもがその案件方だったとは思う
でもなんかその
診断というもの自体のフレキシビリティが欲しいっていう会社は
もう昔から内製化してたと思うんだよね
なんか細胞図しかりDNAとかも多分そうだったよねきっと
そもそもか
そうそうそう
なんかそれで言うとAIが出てきたことによって
内製化のハードルが下がるかどうかが一つ
そのマイルストンとしては
チェックポイントとしてあるのかな
あるかもしれないね
その辺は各社主にモデル作ってる側だけど
その辺のセキュリティレビューとかが
どこまでいいものになるかに結構依存するかもな
でもなんか
やってみて
試行錯誤していくうちに
みんなできるようになると思うんだよな
誰がそのAIの面倒見るのっていう問題だけは
常に残るんだけど
でもそのケイパビリティっていう壁は
割と取っ払われたと思っていて
あるんだけど人にしか見つけられないものは当然あるし
なんかの時にも話したけど
SSRFに弱いよねみたいな話とかしたと思うんだけど
あるんですよ
絶対あるし残ってるんだけど
そういう時はあるんだけど
ケイパビリティ自体は結構
ハードルがめっちゃ下がったっていうのは間違いなくあると思うから
回してみてこういうワークフローでガンガン回してこぜっていうのを
やりやすい環境には絶対になったと思っていて
どうなるんだろうなとは思いますね
逆に言うとだから人にしか見つけられない部分っていうのを定義して
そこを売りにしていかないと
いわゆるセキュリティ診断みたいな
授業自体が
オワコンかとまでは言わないけど
ある種の
JTC的な揶揄のされ方をするような
領域になっていくかもしれないね
もしかしてもしかするとね
僕らはなかなか意識する機会は少ないかもしれないですけど
JTC向けに必然的に残る部分は
あるかもね
AIに情報を渡せないとか
これ以上はちょっとやめとこう
どうなるんでしょうって感じですけど
でもコストも馬鹿にならないから
内製化のハードルが下がったことによって
人はいっぱいいる
お金も結構あるみたいな
JTCこそやりそうだけどね
内製化
いやでもその診断バッジが欲しいってパターンも
現実にある気がして
それはあるね
そこは残るとかはありそうな気がするけど
その辺の変化はゆるやかだろうね
2,3年とかで起きなそう
匠応援してます引き続き
応援してます
ちょっとまた
使いたいなそのうち
個人で使ってみようかなと思ってるんだけど
あんまり高くないし
国産であの領域で戦ってるプロダクターめちゃくちゃ少ないんでね
応援していきたいですね
匠をひたすら回しまくってたら
バグバウンティーで元が取れるぐらいの感じになってたらいいな
そうなったらFlatSecurityMessenger
売る理由はなくなっちゃう気がするけど
売らずに内製で回して儲けた方が
事業として成り立っちゃう
そうかもしれないね
バグバウンティー稼ぎカンパニーになる
夢があるな
ありがとうございます
ということを思いました
ちょっとごめんなさい重ね重ね言うんですけど
今の匠がどうだかわかんない
触ってたのもだいぶ前なんで今めっちゃ良くなってるかもしんないから
それはわかんないですけど
応援してます
じゃあ次いきましょう
私の方からでさらったんですけど
突然フィッシング詐欺の報告が3分の1以下に何が起きた
原因は旧正月と…
フィッシング詐欺の減少とBotnet
何とも言えないタイトルだな
推移向けっていうか
一般メディアっぽい
ちょうどフィッシング詐欺の
フィッシング協会のレポートを毎月読んでるんですけど
そろそろ読むモチベが落ちてきた頃に
この記事が流れてきてそんなことになってんの
読んだらなるほどねってさらっと紹介なんですけど
タイトルの通りフィッシング件数が
報告が3分の1以下に
日本でなってますと
この報告っていうのは今言ったフィッシング協会に
通報窓口みたいなのがあってそれを集計して
毎月レポートを出してくれてるんですけど
その報告件数が爆減してますよという話ですね
減っている要因として
そもそも毎年2月は減るんですよ
なぜかというと
中国で旧正月が2月になっていて
かつフィッシングメールを送ってくるアクターが
大半がおそらく日本に関しては中国にいるだろうというので
毎年減少傾向にはあるんですけど
とはいえ3分の1になるというのは異常値で
具体的には確か2024年だったかな
2024年2月以来に
2年ぶりに5万件台まで減ったんですけど
5万件になりましたと
ちなみに1月は202,350なんで
それが5万7千6万弱になってますよという感じですと
何かという部分で
何が原因かというと
旧正月もあるんだけど
Botnetのテイクダウンが直近めちゃくちゃあって
いろいろ多分複数件あるんですよね
複数件起きてたっぽくて記事に雇い上げたんですけど
やりました
Botnetというのは何かというと
超ざっくり言うとDDoSとか
フィッシングウェイの送信とか
いろんな悪さに使うときに足のつきづらい
一般家庭のIPを貸し出してる人とか
一般家庭のルーターとかに
いわゆるBotですね
Bot完成してるものを全部束ねてサービスとして売る
というのがBotnetサービス
それがいくつかが国際機関によって
テイクダウン
サービス停止まで追い込みましたと
運営者逮捕しましたみたいなのが
また手続きに起きていて
割とデカいのかな
世界Botの台数10万200万みたいな
Botnetいくつかテイクダウンしたみたいなのがあるんで
それが影響してフィッシングウェイの送る基盤自体が
そもそも弱体化して
こんだけ減ったんじゃないかみたいなのが
仮説としては挙げられているという感じです
という記事ですね
どうなんですかね
個人的には来月も
ちょっと気にしとこうかなというのと
影響したんだったらすごいいい話かな
という気はしつつ
ランサムもそうですけどBotnetもテイクダウンしたとしても
ゴキブリのように
基本的には
湧き上がってくるというか
前回前々回話しましたけど
Botnet間で脆弱な端末を取り入れになっているという
Botnetがテイクダウンされても結局その脆弱な端末が
セキュアになったわけでは全然ないから
どうなんでしょうねという復活しちゃうのかな
と思いつつ
さらっと
ご共有という感じでした
はい
定点観測意外とおもろいというか大事だなという気持ちで
見ましたけど
おもろいけど
おもろいけど
まあええわ
復活するのかな今喋ってしまったけど復活するんだろうな
切ないな
犯罪者を抑える側と追う側と追われる側の
非対称性が常にある感じがしますけど
かといってやらないわけにもいかないし
皆さんができることは自宅のルーターを
ファーメイアアップデートすることとサポート切れたやつは買い替えるの
2つですかね
頑張りましょう
次もさらっと行ければ
Dependabotによるマルウェア検知
おもろいですけどGitHubのチェンジログで
dependabot now detects malware in npm dependencies
という記事です
タイトル通りでdependabotで
CV 脆弱性のアラートっていうのは
元々検知してたんですけど
その中にこのパッケージのこのバージョンは
マルウェアが入ってますよっていうものを
検知してくれるようになったっていう話ですね
今のところnpm限定っぽいかな
これはめっちゃ助かりますね
一応オプトインで有効化しなきゃいけないっぽいんで
使いたい方は有効にしてみてくださいって感じで
僕はまだ手元で試してないし
アラート上がってきたら真っ青って感じなんですけど
ほんとそれよな
勘弁してくれよって
直近のサプライチェーン攻撃の煽りを受けてのタブアップデート
と思うんですけど
ぜひ使ってみましょうっていう感じですね
これ元になっているGitHub Advisory Databaseでは
実はマルウェアが入ってるかっていうのを絞り込むことができて
確かタイプこれをマルウェアだったかな
って検索すると出るんで
内部実装的にはそれをアラートとして出すようにしましたよ
って話かなと思うんですけど
脆弱性かと言われると
どうなんだって感じではあったんで
でもやっぱ検出したいよねって部分で出たのかな
っていう感じで仕様です
マルウェアを見れるリンクも貼っておきます
これね、痺れるよね
なんか有名どころあんの?
いやちょっとこのパッと見た感じは
数が多すぎて、でも数多いよ
だって1時間前とかに何個
でもそんなか小さしい
この1時間の間に15個ぐらい出てるんですか
これ多分その
既存のが侵害されたやつじゃなくて
新しいマルウェアを見ると
ガンガンプッシュしてるってパターンもあるから
でもこれとかはなんか怪しい
でもなんかもうそこまで分かってるんだったら
リポジトリごと落とせよって思うけどな
NPMはリポジトリがないパターンがあるから
あ、そうか失礼しました
それはそうよ
リポジトリを確定的に落とせるのは多分
OIDCでプッシュしてるパターンだけど
複数リポジトリからプッシュされてたら
どっちを落とせばいいんだとか意外と難しいと思う
NPMが落とすっていうのは基本的にめちゃくちゃ早くやってるはずだから
ただ手元に落ちてきちゃったやつとか
ノードモジュールさんキャッシュに入ってるやつは消せないから
やっぱ自己防衛するしかないっていうのはあるかな
なんかさNPMのレジストリ作ってくれればいいのにな
Githubが
NPMをGithubが持ってるから
そういうことなんだ
NPMJSは今Githubの持ち物になって
むずいよねNPMJS
Githubの持ち物になったんだって結局さ
収益化できないというか
NPMJSって元々会社としてあったんだけど
儲かんないっていう部分があって
買収されたっていう背景もあるから
これ以上のノード的防御を望むんだったら
JFログとかスニークはあんのかな
レジストリを提供してるSaaSがあるから
それに課金するのがいいんじゃないかなって気がしますね
ちょっと使ったことないから
あとソケットセキュリティとか
そうなんだね全然知らんかったわ
NPMJSいつからそれ
結構前からじゃないかな
OIDCの記事とかGithubチェンジログの記事で読んだじゃん
あれはなぜかというとGithubが運営してるからGithubから
そういうことか
そう考えると結構今までの話も見る目が変わってくるな
そうでしょ
遅くねってなるな
そのコンテキストが完全に頭の中になかったわ
2020年ですかね
買収完了のニュースは
普通に遅いなと思ったな
思ってしまうな
まあ難しいよね
でも既存のエコシステムをいかに壊さずにみたいなところもあるから
そうなんだよね
そもそも別に収益性のある事業じゃないし
難しいんだろうね
JSRだと思うな
流行ってないのかな
別のレシストで言うとJSRっていうやつとかは
セキュリティ面とかESMしか
パブリッシュできないとかで結構尖ったやつであったりするんですけど
パブリッシュとかも
デフォルトで証明付きじゃないと絶対プッシュできない
あんま流行ってないよね
セキュリティの難しさはここだよな
絶対こっちの方がセキュアなんだけど
まあね
それこそオープンクローが流行っちゃうみたいなのって必要やな
一回ワッて出て
使うレジストというわざわざ例えばJSRに書き換えるとか
JSRにパブリッシュし直すみたいな
そこまでやるモチベーションがあるって相当意識の高い
上位5%もいるかみたいな感じだから
セキュリティだけで
何かを流行らせるのはやっぱ難しいんだろうし
厳しいところですね
NPMはGitHubの持ち物です
勉強になりました
じゃあ最後
データセンターへの攻撃と地政学リスク
最後もさらっと行けばですけど
パブリッキーさんの記事で
データセンターが武力紛争時の攻撃目標になる事態
中東の武力紛争で両陣へともにデータセンターを狙った攻撃を実行
という記事ですね
イラン戦争の話に絡んだものですね
何か紹介したいなと思ったのが
記事としてはワンテンポ遅れてるし
これ読んだ時から1週間経って
イラン戦争時代の情勢が目まぐるしく変わってて
なんともなんですけど
何でしょうね
一つはAWSのデータセンターが
攻撃されて落ちたみたいな話がありましたけど
それを含めてある以外にもいくつかあったみたいで
僕知らなかったんですけど
それを結構丁寧に綺麗にまとめてくれてるんで
とてもいい記事だなっていうところと
あとは実際に多分まだ
今本日3月24日ですけど
3月24日時点ではそういうニュースは流れてきてないですけど
イラン側からの報復攻撃として
米国のハイテク企業なざしで攻撃するぞっていう風に
言ってるみたいな話も
記事中で言及されてて
これとかは知らなかったんで
きついですねというか
Amazon Google Microsoft含めその辺の記事なんですけど
中東にはデータセンターがいくつかあるみたいなんで
ちょっと想像できない世界だなというか
もし自分がGoogleに勤めてたら自分の会社が戦争に巻き込まれて
攻撃される世界線っていうのは結構
適応している価値がでかいからこそあれですけど
なかなかそういう部分もありそうですよっていうところと
また僕らに繋がるリスクはどうなんでしょうねという部分は
引き続きですけど
知性学リスクを肌身に感じる
あまり嬉しくない貴重な機会だなと
個人的には思っている
読める紹介記事でした
今までもこういうのって
もっとあってもよかったと思うんだけど
不思議だね
ウクライナとかは発電所とか狙われてたんだっけ
例えば直近のウクライナ戦争とかだと
ロシアがアメリカの企業を
攻撃するわけにはいかないっていうのはあるよね
でも今回アメリカ攻撃したから
アメリカに対する攻撃の
生徒防衛が成り立つっていう話とか
いろんな記事で三発金読んでるから
めっちゃ全体像はつかめてないけど
イスラエルとアメリカ合同で
イスラエルってサイバー責任強い国だと思うんだけど
トリビもイスラエルですけど
サイバー方面でもイランに対する攻撃を仕掛けて
結構成功してるっていうのを
公表というかパブリックに言ってたりするから
だからそこに対する
報復なのかそこに対する弱点を狙ってるのか
そこの区別はつかないけど
そういう部分の狙いとか
あと中東 この記事でも書いてあるんだけど
中東にやっぱ広い土地と資源があるから
結構各社データセンターを建ててるっていうのがあって
物理的にも近いし
アメリカに対して打撃を与えやすいっていう部分で
対象となってるっていう部分が
あったりはするのかなって
感じかな
確かに今まで
なかったというか
僕も知ってる範囲ではあんまなかったし
アメリカ前回の戦争
なんだっけ忘れちゃった
何とか言えんすね
戦争であれ直近
ウクライナじゃなくて21世紀で
イスラエルと
シリアか2014年が
2014年だとちょっとまた
クラウド流行り始めたぐらいいたもんね
2014年って
まだ多分そういう時代ではなかったんだな
今後はもしかしたらデータセンター
データセンターだよな基本的には
収束をお願いましょう
ガソリン安くなってほしいな
切実だね
最近あんま車乗ってないから
影響ないんだけど正直
なんかその
ある意味なんか全国民に関わる
話ではあるというか
分かりやすくリスキーな状態
平和にいきたいな
何しても令和ですよ
はいちょっと
何でもいいんですけど
平和におらせてください本当にお願いします
トリビーも侵害しないでください
頼みます本当に
サイバーセキュリティねどんぐらいになったんでしょうか
今日紹介しなかったけどなんか
よく読むディスキバレティンっていうメディアでも
その戦争にサイバーセキュリティを
使うっていうのが
戦車とかを買うより
圧倒的にコスパがいいからやっぱ
イランもやってそうみたいな話とか
お金なくてもめちゃくちゃ成果を出せちゃうっていうのを
北朝鮮がもう証明しちゃったから
戦場としては区別にあるよねみたいな話を書いてあって
そうだねーって気持ちになりましたね
生きてる間
願わくば半永久的に他人事でありたいものですが
世界は繋がってるんでね
今日はそんな感じですか
何とも言えん回だったな
そうだねー
こうやって眺めるとちょっと物騒なやつばっかりだね
厳しいなサプライチェーンも厳しいし
サプライチェーンが厳しいねこうやって見ると
戦争も厳しいですけどもちろん
基本的なことをやっていきましょう
国産セキュリティツール「匠ガード」
あとあれだな
つばめのスライドの
これもさらっと売れとこうと思ってたけど
忘れてたんだけど
匠ガード
匠ガードの
さらに先の匠ランナーだ
国産でこういうのが出てきたの嬉しい
これいいね
なんかステップセキュリティとかが多分先行
サービスなのかな
そうだね海外のちょっと名前忘れたけどあるね
TJファイルスのTJアクションズのあれ見つけて
っていう話を今日社内でしてたんだけど
なんかEBPFベースでやると
確かにこれできるなと思って
それをランナーで提供してくれるのは結構ありがたいなと
思いましたよという話ですね
なんか大変ですね
これでも結構さ
なんか起きたときにうちは影響があったんですか
なかったんですかっていうところに対して
なかなか明確な解を得るのって
難しかったと思うんだけど
こういうのあれとシンプルに助かるよね
そうだね確かにそれは間違いないね
一方でなんかさ多分
俺あんま仮想化とかOSとか詳しくなくってあれなんだけど
多分Ubuntu Slim相当のものは作れないんだよね
これの上では
いや
やってる処理次第かな
Ubuntu Slimって結局OSは変わってなくてスペック落としてるだけだから
違うでしょ
違うよ
VMベースかコンテナベースかで全然違うよ
Ubuntu Slimでどっか動かないじゃん
確かにそうだった
仮想化のレイヤー的に多分動かないんじゃないかな
EBPFで見たいところよりも多分
上で動いてんじゃねえかな
ちょっといまいちよく分かってないんだけどちゃんと説明ができない
全然素人なので申し訳ないけど
Ubuntu Latestと同じ価格ですよって言われても
もはや高いなって思ってしまうぐらい
Ubuntu Slimを使ってるから
そこだけ難しいなって思ったのと
使い分け
使い分けがやってられんじゃん
何が侵害されるか分からんし
これを匠ランナーじゃないところでは
センシティブなものが動かないようにしましょうみたいな
正直やってらんないから
難しいなって思った
前回の回でも話したけど
そもそもCICDが侵害されたときのリスクを
まず最小化したいなって個人的に思うな
限界はあるのは理解してるんだけど
でもやっぱり
やり玉にあげて申し訳ないけど
リポジトリシークレーツにパッと突っ込むとか
やめられると思うし今なら
リポジトリシークレーツやめる
キーレスにするとか
そうなんだよね
キーレスにしたいよね
キーレスにしたいんだよね
キーレスにしたいけど
キーレスにできないものが多すぎて
発狂しそうになるんだけど
そうだね
何だっけ
Devinとか
Devinは俺あんま触ってないからかなけど
Cloud CodeのWebとかもそうだけど
VMベースでコーディングエージェントが動くよみたいなやつとかも
全部ワークロードアイデンティティフェデレーションで
Google Cloudにアクセスできるようにしてくれれば
一タブのトークンとかもそれ使って入ってくるとかできるから
とりあえずそこなんだよな
AWSか 俺だったらGoogle Cloudをめっちゃ使ってるから
Google Cloudにワークロードアイデンティティで繋げられるようにしてくれれば
それでだいたいなんとかするのに
それをやってくれないから結構しんどいなと思ってて
そうだね
なんか結構ね
侵害されまくらないと進まないのかな
そういうのは
なんかGoogle CloudとかAWSとかそういうのやってきたのって
やっぱそのキーの漏えい
他の企業たちは規模がでかすぎて
やっぱ対応しなきゃいけない漏えいの規模感もでかすぎて
やっぱだから
あと漏えいしましたのを漏えいして
めっちゃ使われましたみたいなのに対してさ
補填してたよね 彼らは
そうだね 確かに
彼ら自身の
自分たちの財布が痛むっていうのが明確にあったから
モチベーションもあったと思うし
大半の殺戦者は同じモチベーションがあることを言うと結構ないのが
現実な部分ってあるよね
っていうのもあるしぶっちゃけデビューからシークレット漏れましたって言っても
別にそこに置いてたあなたが悪いですって言っちゃっていいわけだからさ
そうだね
たぶんね
そもそも別にさ
デビューの請求がめっちゃ増えるってわけじゃないじゃん
誰が補填するかっていうと
やってくれるとしたら例えばグーグルクラウドのサービス
SAキーが漏れちゃいましたってなったら
グーグルクラウドが保証するしないの話をたぶんするわけじゃん
そこにデビューが登場してこないだったらさ
デビューとしては全然そこに対してモチベーションないじゃん
なんかそうだね
いろんなコーディングやSaaSが侵害されまくって
この経営レッセンはあかんってぐらいにならないと
動かないかもね
今のタイミングだとな
セキュリティの機能はあんま
共通優先にならない感じがするんだよな
切なくも
でも結構さシークレットの扱いがいまいちっていうだけで
俺の中では使わないっていう選択肢が
めっちゃ出てきちゃうから
結構しんどいなと思ってて
またワンパスみたいなところに頑張ってもらうとかかな
頑張ってそうな雰囲気はすごいあるけど
限界あるんじゃないかな
真の意味のキーレスにできないかな
難しいよね
両面あって
何て言ったらいいんだろう
そこにキーを置かないっていうのと
単名なトークンを
都度発行するっていう仕組みを
アクセスする先かサポートするかっていう
2つあるから
それが結構難しいよね
頑張っていきましょうって感じですね
確かにこれは紹介しておくべきだったね
国産サービスを応援していくぞ
国産サービスというか
いいサービスを応援していけばいいと思うんですけど
じゃあ今日はそんな感じですか
エンディング
はいそんな感じでございます
じゃあ皆さん次回もお楽しみにしててください
おやすみなさーい
01:26:43

コメント

スクロール