1. Replay.fm
  2. #52 サプライチェーン攻撃しん..
2025-09-19 1:40:25

#52 サプライチェーン攻撃しんどすぎるんよの回

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


https://sota1235.notion.site/52-26ebb64fc8cf80f2989dfc9b317c9d29?pvs=74



サマリー

このエピソードでは、ウェブフロントエンドに対する攻撃の種類や、Googleがデフォルト検索エンジンとしての契約に関する米連邦地裁の判決が議論されています。特に、データ共有や競争に関連する法律の影響が話題となり、フロントエンド開発の複雑さが強調されています。サプライチェーン攻撃に関する認証のアクセシビリティについて詳細が議論され、認知機能テストの必要性やパスキー認証の利点が紹介されています。また、スマートHRのデータプライバシーユニットの設立背景やプライバシーデザインの重要性についても触れています。サプライチェーン攻撃における最新の脆弱性とその影響について考察され、NXの脆弱性を通じて予想以上の被害が発生し、セキュリティ対策の重要性が強調されています。最近、セールスロフトのドリフトという製品がサプライチェーン攻撃を受け、セールスフォースのオーストークンが盗まれる事件が発生しました。この侵害によって300社以上が影響を受け、必要な対策について考察されています。サプライチェーン攻撃に関するエピソードでは、327人のGitHubユーザーから3325件のクレデンシャルが盗まれる事例が取り上げられ、特にPyPyトークンを狙った攻撃方法が詳細に解説されています。セキュリティの脆弱性やユーザーに対する危険性、今後の対策についても考察されています。サプライチェーン攻撃への懸念が高まっており、防御手段の不足が問題視されています。ポッドキャストでは、NPMやPyPyなどのプラットフォームの脆弱性や、米国と日本における著作権法の違いとその影響について議論されています。サプライチェーン攻撃についての議論が繰り広げられ、Mac OSやiOSアプリに関連した権限のミスやビルトインパスワードマネージャーのセキュリティ問題も取り上げられています。また、Immutable Releasesの導入によってセキュリティインシデントを防ぐ方法も詳述されています。サプライチェーン攻撃の現状と難しさについて検討され、攻撃者側の動向や環境への適応の必要性が議論されています。

ウェブフロントエンド攻撃の分析
こんばんは、Replay.fm 第52回です。
こんばんは。
はい。3連休真ん中の日に収録してるんで、すごい、個人的にはイマイチね、閉まってない。
そんな、そんな、なんか、そんなことある?
なんか、何だろうな、火曜日、いつも火曜日、儀式収録で、今回ずらしたけど、その、火曜日だと翌日も仕事だし、
日チェンも仕事してたし、なんかその、仕事の脳みそのアリとか。
あー、狭間だね、確かに。
そう、今完全にアイドリングしてるんで、今回3連休から明日も休みで。
うん。
なんか、寝かし、子供寝かしつけ終わる手前までは、なんか全く別のことに思い出させてたから、すごい不思議な感覚で、やってますけど。
まあ、じゃあ今日はね。
そんな気持ちとは裏腹に、記事は多いと。
そうなんだよね。
うん。
いやー、そうなんですよ。やりますか。
やりますか。
14、うん。1個減らしたから14。
あ、そうなんだ。
うん。
はい。
はい。
じゃあ1個目、お願いしようかな。
ブラウザはフロントエンドを何から守っているのか、というスライドですね。これどこで話したスライドなんだろうな。
どこで話したスライドなんだろうね。
なんかまあ、かなるんさんのスライドなんだけど。何なら誰が話してるかすら、そのスライドの中で言及されてなくてさなんだが。
40、あ、フロントエンドカンファレンスか。
あ、なるほどね。
9月6、あ、なるほどね。フロントエンドカンファレンスは北海道があったんですね。
はい。
まあ、そのスライドでございます。
で、中身をあえて1個ずつ紹介する必要はないかなと。
あ、かなるんさんの自己紹介あったね、スライド。だいぶ後ろだな。
すごいな。独特のスタイルだな。
そう、でも俺割とこのスタイル好きだけどね。
あ、そうなんだ。
個人的に。掴みというかね。
まあ、そりゃそうだよね。なんかね、自己紹介にしても。
まあ、よほどこういう人間が喋ってますよっていう前提が大事じゃない限りは別に。
こういう持ってき方のほうがいいかも、確かに。
うん。
まあ、そんな感じなんですけど、中身紹介する必要はないかなとは思っていて。
なんかウェブフロントエンドにおける攻撃の類型のいい整理になってるなというふうに思って。
いや、これフロントエンドカンファレンスで発表されてるっていうので推してすごい納得したわ。
結構さ、めっちゃ丁寧だなと思って、そのスライドが。
そうだね。
多分新卒でウェブアプリかける人でも理解できるぐらいまで結構ブレイクダウンしてくれていて。
ね、一個一個すごい復習、復習というには僕は自分が完璧に把握してるか自信が正直ないっちゃないんだけど。
うん。
ありがたいなと思ってたわ。
いいよね。
うーん、かなり丁寧。
スライド数、それを裏付けるかのようにスライド数は多分これ見れないけど相当な、あ、102枚か。
なんかエスケープとかしたら多分アレのモードになるんでしょうか。
あー、なるほどね。
なんで。
なんなかった。
いや、一回ね、一回左上から戻ってMy Driveに行くと閲覧した、あれなんていうの。
左、なんか普通にプレゼンテーションモードみたいな感じでしか見えない。
いや俺もね、プレゼンテーションモードから抜け出すのに、あの左上にさ、ちょっとリロードしてみよう。
なんで出てこないの。
なんで出てこないの。
いけるんだけど。
なんかあれかな、さっきのが悪さしてるのか。
俺なんか一番上にヘッダー行が、ヘッダーがあって、そっからMy Driveに戻ることができて。
My Drive開いてみるわ。My Drive開くとなんか閲覧したファイルもこうやってると思う。
なるほどね。
見えちゃいけないものがなければ。
うん。
あー、はいはいはい。
あー、そりゃそうだね。
なるほどね。
これそのまま、うん、あ、そうそうそうそう。
そうするとなんか全部見えるから、その非表示スライドとかも見える。
あー。
おもろい。
おもろい。
おもろい、マジでおもろい。EDFにしてなんか見直せばよかったのに。
ほんとだね。はい。
まあ。
よかったですね。
うん、よかった。
なんか、メモってないけど、なんか満遍なくよかったんだよな。
これがめっちゃ勉強になったっていうか。
そうそうそうそう。
ほんと全体的に勉強になったなっていうか。
まあなんか別に知ってるところは飛ばしていいかなと思うんだけど、なんか。
うんうんうん。
うん。
あ、ちょっとこれなんか、まあ自信ないなっていうところさ、全部。
うんうん。
あの、見かけたら見ていくぐらいで多分十分だと思うし。
うん。
うん。
あとはなんか、これ系の資料毎回読む度に思うけど、無理よな、こんななんか。
うん。
その、例えばじゃあフロントエンドカンファレンスに参加してるWebフロントエンドのガチ勢がこれを全部意識して開発しきれるかとかやっぱ難しいというか。
いやー、Webの面白さであり、カオス味があるなっていう気持ちもあります。
平たい感想です。
いつも思うんだよな。
うん。
うん。
だからもう持ち屋持ち屋じゃないと、持ち屋持ち屋でなんか分業しないとどうにもならん気がする。
でも、どうなんだろうね。
なんか。
まあでも確かになー、フロントエンドの開発者向けではあるよなー。
サイトアイソレーションの話とか出てないもんね。
覚えてないなー。
出てなかった気がするんだよ。
サイトアイソレーションの話は出てない。
全部説明しきれんよなー。
うーん。
まあでもなんかこういうの知ってくっていうのは大事だろうな、別に。
自分の口で覚えて説明できるレベルまで行けずと思う。
うんうんうん。
だからこういうの考えると、いやーどうなんだろうなー、まあ分かんないけどその、
まあバックエンドだとさ、そのオレオレフレイマークで、今の時代はさすがにないのかもしれないけど、
昔だったらオレオレフレイマーク使って、なんかしょうもない脆弱性めっちゃ作り込むみたいなやつとか、
ところに対し、反省に対して、まあきちんとユーザーが多いコミュニティーのデカいフレイマーク使ってればそんなおかしいこと起きないでしょみたいな話と同じように。
いやーでもフロントエンドどうなんだろうなー。
フロントエンドもある程度乗っかっとけば、この辺安全だよねみたいな。
いやー、ちょっとなんか喋ってて思ったけどそんなことないなって気持ちになってきたから、何でもないです。
そこに難しさあるよな。
はい。
Googleの判決と影響
次行きますか。
行きますか。
はい。
まあそんな感じで、みなさん読んでみてください。
お。
えーっと、GDNETの記事で、クロームアンドロイド売却は回避、米連邦地裁がGoogleに是正命令っていう記事ですね。
よかったねー。
よかったのこれ。
うーん、まあよかったの…。
まあ分かんない。僕ら目線で言われるか。
なんか出したんですよ、命令。
えーっと、あのー、あまり書いてないな。
えーっと、販売は、販売じゃない、売却はしなくていいよっていうところで、
まあ、かつその売却を要求するには行き過ぎだよねっていう判決になったんだけど、一方で何もしなくていいってわけじゃなくて、
えーっと、あれか、一つはGoogleをデフォルトの検索エンジンにするっていう契約を各ブラウザーとか端末メーカーと結んでいたっていうところに対して、
まあそれを禁止するっていう話かな。
なんで、えー、まあアップルとかそうなんか、サファリとかで開いたらGoogle検索ページのトップに行く、代わりにGoogleからめっちゃお金払うみたいなのは禁止するっていう風になったって感じかな。
で、なんかその契約内容が配達的契約はダメっていう感じだから、まあ非配達的な契約ならいいよっていう言い方してるけど、
うん、まあ非配達的な契約ってどういう感じなんだろう、なんか現状の契約ちょっと僕把握できてなかったから。
まあ例えばだけど、その初期設定時にさ、選べるとか。
あー、なるほどね。
選べる中に多分なんか、えーっと、例えばBing、Yahoo、Googleみたいな感じで並べられるようにするとかはありなんだろうね。
なるほどね。
で、それぞれがお金払うとか。
うんうんうん。一番上に表示するためにたくさんお金払うとかだったらまあいいのかなって感じですね。
あー、どうなんだろうね。なんかそこはちょっと分からんけど。
配達的な、これもなんかその、今後Googleがどう振る舞うかでどういう塩梅になるかって感じなのかな。
で、あともう一つが、あれだね、競合他社に一部の検索データを共有するっていうのを明示したって言ってて、
具体的にはユーザーの操作履歴や検索インデックスの一部が対象となる。
正しい広告関連のデータについて共有の義務は課されなかったっていう風な感じがあったって。
なんでユーザーの操作履歴をさ、Googleの操作に出すことをさ、そこに決められなきゃ。
それは本当にそうだし、Googleのユーザー目線はたまたまじゃないよね。
そうだよね。分からんけど、あえてGoogleを使ってる人間もいるわけでしょ。
まあそうかもね。Googleのプラポリと利用契約に同意してGoogleを操作していたら、なぜかそれは別の会社に。
だからどうなるんだろうね。
操作履歴って何だろうね。
うーん。
だとその、なんだろうな。
どれぐらいの抽象度というか、この人がこういう操作をしたまで取られるのか、
もしくは、何だろう、100万人ユーザーがいて、
何なんだろうな、ある種匿名化じゃないけど、全員がこういう動きをしたよみたいな話なのか。
まあでもこの記事にも書いてるけど、なんか実際にどうするかっていうのはまだ不透明っていう話をしてるんで、
だからどうなんでしょうっていう。
まあそうだね。
まあまあまあまあ、
市場的にはGoogleの勝利でGoogleの株価は8%給投したらしいです。
すごいな。
ポッドキャストの成長
だからまあまあ、売却せずに済んだっていうのは、世間はある程度はポジティブに捉えてるとか。
まあ行き過ぎだよねーっていうのは個人的にはそうだよね。
まあ1個目は妥当かなとは思うけどな。
間で契約。
まあまあまあ、これもなんか別に民間に介入するにはさ、っていう見方も多分あると思うんだけど、
まあいい落とし所なんじゃないかなとは。
データの共有は何を言ってるのかよくわかんないから。
そうだね。
その代わりにっていう記事中に書いてあるけど、どの代わりになんだ。
裁判所の役割は反競争的な行為によって独占を維持するケースと、
優れた裁判員やビジネスの才覚、あるいは偶然の歴史的要因によって成長したケースとを区別することにある。
まあその代わりがかかっているのは、たぶんそのさらに前段なんだろうね。
うーん。
だからクローンアンドル売却かあれだけど、
だからデータを独占していることで、ここで言うところの
反競争的な行為によって独占を維持することに当たるっていう。
この文面だけから読むと。
そう見えてしまうか。
まあちゃんと読むと思ったら判決文読んだ方がいいんだろうね。
まあはい、そういうニュースがありました。
データ共有の問題点
全然関係ないけど、なんかおすすめに出てきたやつがすげえなと。
マジで1ミリも関係ないんだけど。
どれ?どれがすごい?
ちょっと脳書のほうに、あと。
タイミングによる勤務実践やリアクションに、自身の勤勉さを証明及しにされた。
これ面白いね。知らなかった。
面白いけど、すごいね。
勤務回数や総勤務時間、勤務業種に加え事業者からの評価やレビューを取得バッチな。
スポットワークで蓄積した実績が逆感的に聞こえる。
なんか素晴らしい。脱線もいいとこなんだけどさ、なんかすごいな。
言っちゃおうか。
いいよいいよ。なんかここから貼っとくぐらいでいいよ。
いやーなんか、おもろいな。
2025、試験的には入れてるんだね。
すごいな。
まあ自己申告の履歴書よりよほど採用する目線も良さそうな気がするけど。
でもなんか、ある種のリファラルとして効くのかな、本当に。
効く、どこに対して?
ちゃんと機能するのかな、他の事業者からの評価に。
サプライチェーン攻撃とアクセシビリティ
まあそれはこれからなんじゃない、正直。
メルカリの評価とかもそうなんだけどさ、そこの権威づけって本当に機能するのかな、まともなのかなって思ってて。
いやなんかこういう使い方をし始めた瞬間に、なんか結構壊れ始める感じがしてて。
バランスが、パワーバランスがさ、なんかおかしくなるというか。
うんうんうんうん。
めっちゃ極端なこと言うと、例えばその評価を悪くするぞっていう事業者からの。
例えばね。
例とかだよね。
まあでもタイミーの場合は相互評価みたいなところはある気がするけどな。
まあそこの堅実性をどう保つかは、まあちょっと設計の見せどころというかそういうのが結構なんだよね。
まあまあ言わんとすることはわかったわ。
まあ用意あるわと思います。
気になる人はリンクから飛んで読んでください。
次行きますか。
アクセスボウガイドトゥダブルシーエイティースリーエイト
アーティンティケーションウィザードブラストレーション
というオーステロンですね。
とりあえずちょっと僕、なんかサマリーしか読んでないんだけど。
お願いしていいですか。
いいですよ。
まあ詰まるところ認証方法に関するアクセシビリティの話で
具体的にそのダブルシーエイティーっていう
ちょっとアクセシビリティの本読んだのに思い出せないんですけど
まあそのアクセシビリティを語るにおいて標準みたいなものがあって
それにその認証に関連するダブルシーエイティーっていうのが追加されたのかな。
まあ元かったのか追加されたのか忘れたんですけど
リンク貼ってあるんですけど、そこにはこういうふうにあるべき
これは避けるべきみたいな具体的な言及があるんですけど
その辺に基づいて、こういう認証方法はアクセシビリティ観点ではバッドパターンですよ。
じゃあどうすればいいのみたいなところを割と丁寧に解説してくれている記事です。
日本語訳の貼り付けなんですけど
リファレンスの方では認証プロセスのステップにおいて
いくつか条件があるんですけど、その条件のうち一つを満たしてない場合は
認知機能テストっていうのをする必要ないというか、しちゃいけないって感じなんじゃないかなという感じで書いてあって
認知機能テストっていうのが結構この記事で触れられてるんですけど
これ何かっていうと人間の
これどういう意味なんだろうな、例えば具体で話した方が意味付けやすいと思います。
IDパスワード認証みたいなのがあったときにそれをパスワードマネージャーの自動入力とかじゃなくて
自分で覚えているIDとパスワードを手打ちするパターンっていうのは
その人の記憶力をテストしていることになるので、ここで言うと認知テストに当たりますよとか
あとは覚えるケースじゃなくて、どっかに書いてあるものを書き写すっていう行為
例えば2FAのコードでスマートフォンのOTPで6桁の数字があって
それを見てパソコン上でポチポチ手打ちするっていうのも認知テストになりますっていうところとか
あとはこういうのをパスワードマネージャーで自動入力って場合は認知テストにならない
記憶する必要もないし、転記する必要もないんだけど
それが例えばたまにあるコピペをブロックしているようなサイトとかがあると
もう少なくとも転記が要求されちゃうんで、これはもう漏れなく認知テストになってしまいますよって話
またそのキャプチャー、画像のキャプチャーみたいな
キャプチャー認証の画像を選ぶ方式とかは、これは認知テストなんですよって話をしていて
まず写真のものを認識しなきゃいけないっていう部分があったりとか
ものによっては頭を使って解かなきゃいけないクイズみたいなのがある時点で
認知テストに含まれますっていう話が書いてあって
笑ったのは日にこを込めてキャプチャーの例を貼っていて
どっかのカンファレンスでこのキャプチャーがあったんだよねみたいな
シェアされたやつをつけてるんですけど
あと参考画像でキャベツの画像があって
このキャベツより小さいものの写真を選んでくださいみたいなキャプチャーの例があって
これとかまずキャベツを認識しなきゃいけないって話もあるし
そのキャベツより小さいかどうかっていうクイズを解かなきゃいけないっていう観点で
これアクセシビティガイドの観点においては
結構クリアすべき要求は満たせてないっていう話がありますっていうところですね
具体的にどうすればクリアできるのっていうところは
まずパスアドレス パスキー認証とかでポチポチって押したら認証できるっていうのは
認知テストがないのでOKだよとか
認知テストっていうのはさ 認知機能テストっていうのはまず何なんだ?ちゃんと理解できない?
認知機能テストそうだね 辛いツッコミを置いてありました
認知機能テストの重要性
最初読みながら何なの?っていうのがあるけど
記事中で振られてたのは
あれかな 認知周りの障害がある人にとってそれは衝撃になるよみたいな話があって
アクセシビティガイド 認知機能テスト
認知機能テストとは何でしょうか
実際にユーザーが次のいずれかを実行することを要求するテストです
まず情報を記憶するか情報を転記するかパズルを解くかの3つが例にある
さっきのまんまだに記憶するか転記するかパスアドレスにするはパスキーに限らず
マジックリンクのクリックとかも今の3つに引っかからないのかな
記憶する必要もないし転記する必要もないしパズルを解く必要もない
メールが来てクリックしてOKなのでアクセシビティ観点ではクリアだし
パスキーでポチポチって押したらログインできるというのもOK
また場合によってはMFAでそのキャプチャ認証を求めるとか
2FAの転記を求めるパターンとかはそこの部分をパスキーに置き換えて
認知機能テストを求めないようにするとかそういうのをやったほうがいいなとか
またキャプチャ認証を導入する場合はこの記憶する転記する
パズルを解くという観点に画像を選ぶ方式だと引っかかっちゃうんで
例えばGoogleキャプチャのV3とかだったらそのスコアリングで
パズルを解かせずに認証を導通するというのができるので
そういうものを使うことを検討しましょうみたいな話とか
あとは多分これをクリアしたらOKってわけじゃないけど
パスワードマネージャーによる自動入力っていうのを
許可しない設定というのはやめようねって書いてあって
これを許可しない設定にした途端に
記憶するもしくは転記するっていうのを求めることになっちゃうんで
これをちゃんとやりましょうっていうことを書いてあったという感じですね
書いてありましたね 記事の中に読み落としてたときに
なんか割とこの視点なかったしこのガイドラインも知らなかったので
ちょっと恥ずかしながら勉強になりましたっていう気持ちで
確かになっていう ブログとか書いてあるんですけど
Webアクセシビティの本を1ヶ月か2ヶ月前くらい読んだんですけど
例えば何かのタスクを解くときにすぐにパニック状態に落ちちゃうような
障害を持つ人にとってこういうUIとかこういうのってストレスだよねとか
あとは一つのタスクに集中できないみたいな
人にとってこういうのってダメやでみたいなところをすごい細かに書いてあって
何だろうな 視覚障害とか聴覚障害とか
あとは何だろうな 指がうまく動かなくてとか
そういうのはすごい知ってたし想像もできたしできてたんだけど
語体満足なんだけど認知機能に障害があるみたいなところのパターンを
正直あんまり勉強できてなかったのですごい学びがあったなと思ったんですけど
認証部分においても言われてみれば
これもなんかこの記事の1から10までそうだよねっていう気持ちでは
読んでいたし あとはその認証って多分避けらんないじゃないですか
大体手段がないというか何かサービスを使うときに通らざるを得ないっていう部分が
アクセシビティを担保できてないってなると
もうその時点でそのユーザーは落とさざるを得ないっていう部分を考えると
結構ちゃんと真面目に考えないといけない領域だなっていうのを思ったって感じですね
なるほど
なんか結構OSとかブラウザ側のUIに体験を統合できるって意味だとか
ASCIIは言われていいのかな一瞬思ったんだけど
なんか要はなんて言ったらいいんだろうな
コンテンツを作る側でめちゃくちゃアクセシビリティに配慮せんでも
そっち側に寄せてあげることでデフォルトでハンダリングしてくれるみたいな感じになるかなと思ったんだけど
でもサードパートのASCIIプロバイダーとかどうなのかな
鍵がどこに入ってるかわかんねえみたいな問題とかって
私なんか何とかなるのかな
そうだね
じゃあそこ
PASCII自体のアクセシビリティみたいなのって
どっかで当然論じられてそうな気はするけど
でも手前って感じなんだよな
普通の頭のいいユーザーというか
僕らレベルであってもたまになんかこれダメやんとかなってるから
ちょっと先は流そうかもね
でもその寄せるって観点は確かにな
各事業者が
そうだねそれできたらめっちゃいい
PASCIIに
フィッシングレジェンスな印象保護みたいな
もうこれに選択肢ないよねって寄せていって
PASCII側もPASCII側で
鍵のプロバイダーの人たちはこのアクセシビリティも加味しつつ
改善されてくってなると思う
ウィンウィンな世界になる
と思いました
スマートHRのデータプライバシーユニット
なんかここは正直なかなか
自分じゃ想像もつかない
こういうの脱出するのもいいです
すごくいい記事でしたぜひ読んでください
はい次でいいですか
あーこれね
なぜ今スマートHRにデータプライバシーユニットが誕生したのか
スマートHRデータプライバシーユニットのノートの記事です
すごいなデータプライバシーユニットでアカウント作ってるんだね
えっとなんだろうななんか
なんだろうもう覚えてねえなちゃんとメモを書いてる話なんだけど
スマートHRにデータプライバシーユニットができましたよという
タイトル通りの記事で
ただそれだけなんだけど
なんか結構そのお客様が自社のデータを安全に有効活用できる
っていうのがまあ必要不可欠になってくるからえっとプライバシーデザインの思想に基づいて
プライバシーカバランス体制の構築をしますよと
その一歩目としてデータプライバシーユニットを
コスクさせましたよというお話
なんかこういうこういう
なんていうかチームを設けてるところってどれぐらいあるのかな
なんか少なくともでかいところじゃないと
あんまり聞いたことはないよね
なんかでも結構この目的をはっきり自分たちが定義してやってるっていうのは
割といいなと思っていて
特に対外的にもこうやって出してるっていうのはいいなと思うんだけど
やっぱりプライバシーオフィスを出しちゃうから
あとあれだねその業務委託の立場業務委託メンバーだけど
いつか紹介しためちゃくちゃ素晴らしい
個人情報広報に関するスライドを セコさん?
セコさんがメンバーになってるっていう
これなんかこのユニットの
社内の立ち位置どこなんだろうな
何て言ったらいいんだろうな組織図上の
そうそうそうそうなんかどれぐらいパワーを持つかで結構やりきれるかどうか変わってくるというか
プライバシーバイデザインみたいなのすごい
いいよねって思うんだけど
例えばだけど開発にまで落とし込んでいきましょうっていうのをやろうとしたときに結構苦労しそうで
スマートHRさんぐらいでかいと
横から差しに行くんだと結構苦労しそうな気はしてて
プラットフォームチーム的に
いろんな仕組みとか運用を入れつつ
個別のものにも対応しつつみたいな感じなのかな
素晴らしいよね
このノートのアカウント気づかなかったけどこのアカウントわざわざ切ってるところにもちょっと意思を感じるかも
確かに
発信してくるつもりでやってくるので
RSS登録しておこうかノートってRSSあんの?
なさそうあるかな
そういう人のために貼っとこう
今後に行きたい
いいなノート
サプライチェーン攻撃の基礎
RSSいいなこれがあると今後に期待でキャッチアップできます
確かに
これ半年ぐらい落とさなかったんでしょう
それはそれで苦労してんのかなと思うし
結構いろいろ難しいことがあるんだろうな
それはそれで
メンバーがどういう構成なのか
ポジションは書いてある
セコさん以外は
リスクマネジメントユニット所属の人がサポート
一応一番下の
そのハイアリングのポジションはビジネスフォームになってるから
他2人はどうなんだろう
一応筆者の人はビジネスフォームなのかな
バックグラウンドは
斉藤さんだけ何者の中で
確かに気になる
なんか結構
ほぼ名ばかりだったけどメルカリのプライバシーオフィスは兼務で
一応ちょっと視界の端ぐらいで
見てたんだけど
セコさんの個人情報保護法の個情報のスライドにもあったと思うんだけど
データベースというものを理解してないRDBMSを例に例えて
データベースというものを理解してないと運営に関連みたいな話があったじゃん
別にそれ自体が
言い悪いのを話にしたくないんだけど
一つの事実として
ある程度ソフトエンジニアに近いところにいる人間と
ある種のビジネスフォームみたいなところにいる人間とで
やっぱり技術への理解の確実がある
なぁと思っていて
っていう中でプライバシーバイデザインっていうのを
開発の初期段階から入れていきましょうっていうのは結構言うはやすしだと思っていて
なかなか
やってらんねーよそんなのってなる可能性も普通にあるよなとは思ったよね
だからどういうメンバーでやってるのかなっていうのが
非常に気になった
確かにね 広報期待ですね
そういうのも含めていろいろ今後やっていく中で
見えてくるものもあるだろうし
いかんせんなバーチャル組織にするには
テーマとして重すぎるし
ソフトエンジニアがそこに振り込みにするにはあんまそういうのやる人いなそうだな
難しいね 確かに
そう思うと難しいね
NXの脆弱性と影響
だから明らかに私がイレギュラーっていう変わってる側の
関係だから
こういう世界にしたいみたいな固まったタイミングでやっぱり手を動かす人欲しいというか
まあでも難しいな でも最初から入ってて欲しいな
結局なんかその開発リソース
要はなんて言ったらいいんだろうな
プライバシーバイデザインはいいとして 例えばだけど
私がメルカリでやってたので言うと
PIA いらなくなったPIAを削除して回るような仕組みを作りましょう
みたいな話になった時に やっぱいるのよソフトエンジニアが
いるね
スマートHRが今どういう開発体制になってて どういうフェーズなのか全然分かんないけど
そこに関して その領域に関して
そこは一個苦労しそうだなと思って
今の段階で何か言えるわけではないんだけど
どこまでどうやって踏み込んでいくのか楽しみ
気持ちを待ちしてます
超楽しみになりました
こういう先行事例みたいなのいいな
この課題に取り組みますよ
ある程度そこを明文化して出してるっていうのはかなり好感度高いな
しかも大概的に
めっちゃいいなと楽しみにしてます
ありがとうございます
クッキーケイオス How to bypass host and secure cookie prefix
という記事でございますが
これ実は読んでない 長谷川さんの
ホストを見ただけなんだけど
これ以上のまとめは我々にはできないし そんなに長さもない
多分そういうことなんだけど
JSから生UTF-8を含むクッキーを設定すると サーバー側で本来のクッキーと区別がつかず
JSで生成された側が優先的に使われる
生UTF-8を含むクッキーを設定すると
サーバー側では本来のクッキーと区別がつかず JSで生成された側が優先的に使われる
ただそれだけ
ちょっと頭おかしくなっちゃうなと
一応読んだけど全く同じ感想
頭おかしくなる
むずいよ
バックエンドの実装は
djangoとasp.netが
特定のサーバーサイドフレームワークが
ガイドしそうって感じか
みんなdjangoは仕様ですみたいな感じで書いてる
脆弱性方向警戒に対して
ドキュメントでこういう風に書いてる
信頼できないサブドメインからのクッキーを許可すると 攻撃に対して脆弱性になるため警告してる
今回攻撃はその前提条件だから脆弱性とはしない
みんなしますよって
いやー脆いな
よう見つけられるような
今日の1個目の記事と結構同じ感想という それよりもって感じやな
これどうやって見つけたんだろうね ファッシングかな
あー確かにね その発想のこと
でもなんかキーのRFCから拾ってた感じっぽいな
わからんけど
解釈違い系
しんどいし あるんだろうな
同じポーツ映画のhttp1.1脆弱話も
似たような話があったじゃないですか リレーしていく過程で
解釈違いでする
リクエストスマグネがね
頭おかしくなっちゃいますね
そんな感じの面白記事でございました
サクサクいきましょう
いやーこれ重いな
NXの攻撃から学べること ジャックさんのブログです
いやーこれね
なんともなんともって感じなんですよ
先週確かちょっと話したけど NXっていうめっちゃ有名な
NPMパッケージが侵害されて 結構な被害が出たよって話で
ついでにもう一個Wizの
これなんかキャンペーンだったらしいんだけど 解説した記事
あるんでそっちも一緒に紹介しちゃいたいんだけど
あれか なんかの記事で
1700人とかだっけ 結構な規模に
被害が及んでるんだけど
詳しいレポートはWizのほうを多分読むとよくて
先週も話したけど脆弱性のあるワークフロー
具体的なシェルインジェクションで PRのタイトルを経由してシェルインジェクションできる
ワークフローがあって それ経由でNPMトークン盗まれて
これか
脆弱じゃない
マリシアスなコードを仕込んだNXをNPMパブリッシュして それを実行して
ユーザーから山ほどクレデンシャルを引っこ抜いて それを使ってさらに
いろんなGitHubの環境を侵害して
っていう感じで 文字通りサプライチェーンで繋がっていったみたいな
感じの攻撃で なんかJackさんの攻撃記事を見て
知らなかったんだけど この初手のPR
AIが作ったみたいな
AIが作ってたらしくて 結構それにみんな着目してるけど
そしたらそこじゃないよ みたいな感じのことを言ってて
他なんかその AI騒ぎがあったんだって
知らなかったんですけど 僕も全く同意というか
脆弱性自体は別に AI関係ない
AIだから攻撃ができたものでは全くないっていうのもその通りだし
一個一個Jackさんの記事は紐解いて言ってくれてるとか
入り口ここでこういう対策してばよかったよとか
盗んだものは何かみたいな話とか それで何ができちゃうのかみたいな話とか
あとはNPMトークン そうね だからすごい
丁寧に書いてくれてるんですよね
パッケージをホスティングする人たちはみんなこれ読むと 何をすべきかっていうのは結構
知名だし理解できるんじゃないかな あと被害者リストみたいなのがあって
これはちょっと知らなかったんですけど
NX使ってる人は見ておくと良さそう
あれかNPM NXマリシアスのコードを実行した環境から情報を引き抜く方法として
その情報を丸っとまとめてGitHub上にシンギュラリティリプションっていう名前で
パブリックリプションとして公開するみたいな手法を取ってるっぽくて
自分のアカウントにこの名前が入ってる人が万が一いたら早急にどうにかしてください
たぶんGitHubが対応してると思うんだけど
おそらく300 あでもぼちぼちか
セキュリティ対策の重要性
これ908個か そうですね
はいって感じですね まあしんどいですね
まあちょっとやってらんないよな
これも
いやーなんかもうちょっとさ
いやー
なんか
アクション いやーでもなんかGitHub
GitHubアクション自体がさ結構放置されてるけど
なんかその意外とさ
普通にしんどくないこれ
安全に実装するのもそうだし
ちょっとジャックさん記事をめっちゃちゃんと読めてないけど
CodeQLの話が出てたと思ってて
そうだね CodeQLがそのいわゆるアクションリントって出してくれて
アクションリントは機械的にシェルインジェクションのリントをかけてくれる
CodeQLもたぶん同じようなことできるはずで
たぶんこれサポートサイトの今年とかだと思うんだけど
なかなか
セキュアはデフォルトじゃないけど
今はオプトインしないと言っても使えない
だからパブリックリポジトリでパッケージホスティングしてる人は
CodeQL有効にしてやればいいと思うんだけど
それをしてないリポジトリでユーザーが多いリポジトリってのも全然あると思うから
そこは引き続きしんどいよねと思うし
しんどいね
どこで防ぐかだよな
垂れ場で言うと
いやでもな
例えばNPMは最近OIDC連携でトークンレスでパブリックできるようになったけど
でもワークフロー乗っ取られたらアウトだよねって言ってんのは
映像化はできずとも緩和にしかならないよねだし
ワークフローの脆弱性はCodeQLにしてなかったらアウトだよねだし
でもNPMまで行っちゃったら正直どうしようもないから
2つだよね防げても
ワークフロー
脆弱なワークフローを作らずに済むっていうところだよな
これシークレッツNPMトークン入ってたのかな
もしかしたらこのワークフローを乗っ取った時に
シークレッツは盗めるけどNPMのパブリッシュまではできないであれば
NPMパブリッシュをOIDC連携してれば防げたっていう話になるかもねもしかしたら
ちょっと見てないなこれか
これアクションリンと回してればさ防げたんだけど
実際のコード見てないか分かんないけど基本は防げるんじゃないかな大半のケースは
PRタイトルをエスケープせずに延分に突っ込ませていいっていうケースは防げるはず
全然振り込まないな
これVizのほう見ればあるかもね
Vizのほうにコードは書いてあるか
コードはないなマリシアさんコードの解説とかしてくれてるんだけど
気になるなめっちゃ気になる
プレイエクストターゲットそうだよね
ちょっと気になるねアクションリンと入れてたらよかった
アクションリンとの話は
スクリプトインジェクションというかコマンドインジェクション的なやつは多分刺さらんよね
刺さらんというか見つけてくれるよね
見つけてくる基本的に見つけてくる
だから多分セゲトンのほうが思ってる
面白いねジャックさんの最後の記事でこの対策すればいいよってやつ
箇条書きで書いてくるこれAIに出させたやつって言ってるから
AI使えば安全な対策は誰でも出せるしそれをやればいいんだよっていう感じで
まあ確かに
いやーTシェアアクションズに引き続き
あと今日は別の記事でもね多分
いやまあそうね別の記事
いやでもそうねなんかサプライチェーン関連とか
GitHubアクションズ経由のサプライチェーン関連って気がするな
なんで今まで狙われなかったんだろう
あれかな俺が知らないだけかな
いやーなんかでも別に今までないわけないと思うからさ
少なくともこの1年間でさ記事を追ってきて
もうなんかこの可能性としてはずっと語られてきたやつというか
そうだね
シークレット参照できてるとかシェルインジェクション
でその対策みたいなのやってるところとやってないところがあって
でも別に実際のインシートはないみたいなところが
今年Tシェアアクションズが来てこいつが来て
狙い目だと思われ始めたのか
なんか
なんか
わかんないね
なんか
いやー
サプライチェーン攻撃の概要
まあこればっかりはマジわかんねえな
まあパブリック中から
パッケージ出してる人はみんな読んでほしいね
そういう願いを感じるわ個人的にこのブログからは
なんかAIがプロジェクト立てて侵害したで終わらせるにはちょっと浅すぎるというか
もうちょっとだいぶ身近なトピックだよねっていう
認識してほしいなって気はしますね
自分も含め
次の記事がめっちゃ綺麗に繋がってる
そうだね
はい
読もうかな
NPM Trusted PublishingでOIDCを使ってトークンレスでCIからNPMパッケージを公開する
AZさんのブログの記事ですね
もう話したと言っても過言ではないですけど
タイトルのとおりのやつです
これなんかこのリリースを紹介したけど
週刊先生週刊忘れてた
そうだね
ただなぜその上でこの記事を紹介したかったかっていうと結構
確かにってなったのは僕持ってなかったんで
なるほどってなったんですけど
これ実際にやる時に
僕と違うなって思ったのは2つで
1つは管理してるパッケージの数がめっちゃ多い人とか
あとそのモノリポイをしてる人は
これこの記事読むといいんじゃないかなと思ってて
AZさんちょっと何個か数えてないですけど
途中でいろいろなんか自動化とかリリースフローの工夫とか
めちゃくちゃちゃんとまとめてくれてるんですけど
その中の工夫の一つに
OIDC連携をできてないリポジトリ一覧っていうのを
自動でGitHubの一周
プルリクエストかプルエクストにコメントで出すようにしてて
そいつらを一個一個作業しなきゃいけないわけじゃないですか
NPM側のOIDCの設定ってAPIとかないから
ブラウザ開いて正しい値を入れてってやらなきゃいけないんだけど
そこでミスると事故になるよねっていうので
その辺にこのリポジトリの設定にはこの値を入れるっていうのを
ワンパスアウトとかで事前にバーって入力して自動化して
ポチポチ押してったら機械的に設定できるようにするみたいな
自動化スクリプトみたいなのとかを書いてて
めちゃくちゃなるほどなというか
僕はせいぜい5個ぐらいなんですけど
こんだけ20個30個あるんだったら確かに
こういうのないとやらないよねとか
またそのモノリポ構成の時にはこういう風にやるとうまくいくみたいなことが書いてあって
これはかなりいい知見だなって思って
そうねモノリポでそうか
リリースする時に今までは一つのトークンで全部リリースできたけど
そのOIDCごとに分けるんだったらどうするんだって話とか
エンパイロメントぐらいじゃない?分けようと思ったら
NPM何設定すんだっけな
リポ単位だったらか
ワークフローの名前まではいけるのかな
そこ分けるのかどうかとかは
そうだねワークフローレフとかは入ってくるからワークフローの名前はいける
エンバイロメントも入ってくるからエンバイロメントもいける
ブランチもいけるねやろうと思う
そうだねただNPM側はどんぐらい自由度とか
フレームを何ていうか何を見てくれるか
エンバイロメントネームがいけるんだ
フレームとかはね
ワークフローレフと
ワークフローレフもさ
2つあるじゃん
なんでこんなクソっぽいトークをしてるのかわからない
詳しいが言えない
ワークフローレフって2つあって
ジョブワークフローレフとワークフローレフがある
ワークフローレフの方じゃないかな
ギター部から降ってくるジョットに入ってる
ペイロードの話だよね
どれだこれだ
ワークフローレフと
見つけたか
片方のプレイン
これが一番
ワークフローレフ
この辺多分NPMに関しては隠蔽されてるんじゃないかな
どっち見てるのかな
ワークフローからワークフロー
ワークフローからワークフローコールしてる
それぞれ3つのものが入る
どっちがどっちだかちょっと忘れちゃったんだけど
ワークフローレフ
どうなんでしょう
エンバイロメントでやるほうが確実
ワークフローはプッシュまでされちゃったら
エンバイロメントもそうだけど
エンバイロメントはブランチルール
ブランチプロテクションとかいろいろ突っ込めるから
個人的にエンバイロメントでやるほうが
でもワークフローファイルネーム必須だねNPMは
使わないって言ってはなさそうだね
まあまあまあ
なんですごい
とてもなんていうか
ある種のオットフォームにあるんですけど
これが必要な人っていうのは必ずいると思ったので
ぜひ読んでみてください
普通に勉強になるしね
リリース前とかは別にモネレポ数多いとかにかけ出す
なるほどねって言うとか
あずさん丁寧だなって見てました
ありがとうございます
これ記事じゃなくてページなんですけど
無理やり今日読む記事に
日付に設定して持ってきたんですけど
何を紹介したいかというと
セールスロフトトラストポータルっていう
どこだっけな
ごめんなさいこれは記事でした
これは記事というかアナウンスで
セールスロフトっていう
セールスロフトのアナウンスを引っ張ってます
これ何のアナウンスかっていう前段から
いろいろちょっと話させてほしいんですけど
セールスロフトのドリフトっていう製品があって
このドリフトっていう製品は何かっていうと
セールスフォースのインテグレーション的な
サービスになっていて
これは誰が使うかというと
セールスフォースを使ってる企業が
ドリフトと契約して
ドリフト側にセールスフォースの権限っていうのを
オース認証を通じて渡して使うっていうものになってるんですけど
このドリフト側が侵害されちゃって
セールスフォースのオーストークンがそこから盗まれて
さらにそこから
300企業ぐらいが
そのオーストークンの悪用で侵害
セールスフォースインスタンスに
インスタンスって表現は確かかないけど
セールスフォース環境に侵害されてるっていう
結構そういうインシデントが起きてます
この話題自体は多分2週間前ぐらいから
出てたんですけど
いろいろサミナルに情報出てたんで
まだ
侵害の詳細と影響
まだ話すほどじゃないかなと思ったんですけど
いろいろ情報をまとまってきたんで
紹介したいなと思ってて
そうだな 順番にいくと
1つはこれ原因が多分分かってなかったんですけど
原因が分かりましたよっていうのが
今回引っ張ってきたリンクの記事になっていて
原因は
セールソフトのGitHubアカウントが侵害されちゃったっていうのが
まず原因でしたと
そこから
多分ドリフトのソースコードとかなのかな
丸い足込まれたのかどっから
その具体的なところは書いてないんですけど
ドリフトに侵害されちゃって
そこからセールスフォースの連携部分のストークンを
接種されてたよっていう感じですと
攻撃は結構長期に渡っているんで
完全に狙い撃ちされてるかもって
2月ぐらいに侵害されて2ヶ月
どこだっけな
今年は2月ぐらいに侵害されの
3月か
3月から6月にかけて侵害されていろいろやられてて
実際に攻撃に及んだのが最近って感じか
各社にいろいろ
うちも被害に遭いましたっていうリストが
どんどん増えていってるっていう感じですと
これ被害者が早々たるメンツですごい
なかなか見ない感じだなと思って
リンク貼ってるんですけど
ナッチセキュリティっていう会社がまとめてて
インシデントの被害者リスト
ハッカーワンも追加されてるわ
ファストリ、コーリス、グーグルも入ってる
グーグル入ってるかな
グーグルも多分やられてるはずで
ペーシャルデュエティ、パラワルト、トート
なかなかじゃない?
攻撃者側も多分
エラスティックとかもやられてる
多分より好み明らかにしているというか
盗む価値が高いとこ狙ってるんだろうな
っていうのを思いつつ
これ時系列順になってるのか
8月順、8月8
8月が初順ぐらいから順々に
っていう感じっぽいですね
セールスフォースの使い方次第ではある
そうなんですよ
具体的に何できるかで言うと
セールスフォース環境に入れるだけで
オースのスコープとかちょっとわかんないんだけど
クラウドフレアが打ち侵害されてましたよ
っていうレポートを出してて
これがめっちゃわかりやすくて
基本的にはセールスフォース上のサポートケース
みたいなのを狙われましたよ
結果として被害としては
お客さんとのやり取りの中で
例えばこのAPIトークン
トークンがそのまま入ってたケースがあって
104件APIトークンが漏えいしちゃったよみたいな
のをクラウドフレアが書いてくれて
これをリボークしてお客様に連絡してっていう話をしてる
多分各社似たような感じで
セールスフォース上で何をやり取りしてたかによって
結構どういう被害があったかっていうのは
変わりそう
いわすらこの数の企業の
多分レポートリンクがあるんですけど全部読み切れてないんで
他の会社もクラウドフレアぐらいちゃんと調査できてるのか
もっとやばいケースがあるのかなと追い切れてないんですけど
いやー大変だな
でもこれ結構さ
学びとしてはやっぱ大きいなと思っていて
ある種の問い合わせ本文みたいな非構造化データの中に入っている
日々情報をどう取り扱うかっていうところに対して
大きな学びかなとは思って
そうだね
まさしくだね
あとは割と綺麗なサプライチェーン攻撃というか
これじゃあどう防げるのかって言われた時に
結構どうしようもないなって気がしてて
うちはセールスフォース弊社は使ってないんですけど
例えばジラーっていろんな会社使ってるけど
ジラーもインテグレーションめっちゃあるじゃないですか
お金払ってオース認証で渡してみたいな
そこで同じようなことが起きた時に
入られましたみたいな時に気づけるかみたいな話もあるし
そもそも前段で塞げるかみたいなところって
今回みたいな事故の起き方だと
使わないぐらいしかない気はしていて
でもじゃあ何でもかんでも使わないっていうのも
無理だよねっていうのも結構
インテグレーションの
なんだろうな
きついね
2ホップ3ホップ先で起きてる事象に
今後の対策と教訓
どうやって当事者が気づきますかっていうのは
そうなんですよ
結構悩ましいなっていう感じですね
構造的には
これはきついな
誰が気づくべきだったんだろうね
でもセールソフトの報告を見るに
3月から6月の偵察期間があったって言ってるから
ここで気づくべきだったんだろうなって気はするな
ただもうちょっと詳細が出ないと何とも言えないけど
信頼のされ方
どうだろうな
これはもう気づけないよねってぐらい巧妙な攻撃だったのか
GitHubのオーディットログ見てたら分かったでしょ
ってぐらいのレベルなのか
その辺はちょっと気になるかな
続報は追ってないというかニュースベースしか追ってないんですけど
昨日なんかアップデート出てるな
ドリフト側の全部認証連携止めたり
ローテしたりみたいなの
当然やってはいるんだけど
今はそれこそ復元を優先してるんだろうね
調査みたいなとこも多分並行してやってると思うんだろうな
GitHubに入り込んで
ゲストユーザーを突っ込んで連続化したのか
そういうことか
レポート読むと侵害してリポジトリから情報引っこ抜いて
ゲストユーザーを追加しワークフローを確立することができました
これがGitHubのゲストなのか
サプライチェーン攻撃の影響
開発環境とかのゲストなのかちょっと分かんないね
もうちょっと欲しいな
今後に行きたいとか
そうだね
AWS環境まで入られてるんだドリフトの
ドリフトを使う目線はすごい
どうしようって感じだな
クラウドフレアは割とその辺も書いてるっぽい
8月9日に偵察が来て
クラウドフレア側でそれを築けた?
いつ築いたんでしょうね
8月9日に多分初めてアクセスがあって
セールスフォースとセールスロフトの通知で築いたっぽいね
それまでクラウドフレアでも築けてなかったって話があるっぽいかもね
でもセールスフォースと
気づける人間気づけるタイミングっていうのが複数あるっていう前提において
本当だったら気づけたかもしれないポイントがいくつあるのかな
最初の申買認証書IPRですからセールスフォースとAPIエンドポイントにゲットリクエストさせる
クラウドフレアのレポート見ると初手はもう無理だろうな
ホストトークンでAPI叩いてるだけでしょ
分かんないよね正規のアクセスかどうかって
アクセス元IPが普段と違うかもぐらいで
そうやってアノマリーを見つけるしかないのかな
セールスフォースが使ったことないから分かんないんだけど
どういう感じなんだろう
ホストしてるのかな
クラウドサービスだったら監視のしようがないというか
クラウドフレア側でIPアドレスまで分かってるってことはセールスフォースとしてるのかな
3分でデータ持ち出し成功してるってきついよね
クラウドフレアがこれだったらって思うとやっぱもうどうしようもない
被害者リストの話で言うと
8月23日に通知が来てるでしょ
8月23日以降にやられてる人たちは防げたかもねもしかしたら
即対応されてきて
もうちょっと詳細な原因は続報が出ることを願いつつ
クレデンシャルの盗難
セールスフォース使ってる方がいたらさすがに把握済みだ
セールスフォースじゃないかドリフト使ってる人か
お急ぎで確認してくださいって感じですね
ちなみになんかこの活動の兆候があるよっていう警告ブログをGoogleが出してたんですけど
実は
おもろ
警告出した後にうちも実はやられてましたみたいな続報が出て
まじかって感じ
はい
考えさせられるなって思いました
これはきついな
ぶっ刺さってるもんな
ぶっ刺さってる
まずね
厳しいね
全然関係ないけどこのトラストポータルっていいね
名付けたと思って
確かにあんまり
いやーそうっすね
セキュリティーはめっちゃちゃんとしてる会社ではあるんだよな
セールスフォースとSOCK2とって認証一通りとって
一通りっていうのはSMSとSOCK2ぐらいかな
はい
次いきますか
次もサプライチェーン
こっちはさーらっとでいいかな
お祭り
お祭りっすよ
ゴーストアクションキャンペーン
3325シークレットストールンスルーコンプミスキットアブワークローズ
GitGuardianっていう会社のブログですね
タイトル通りでゴーストアクションっていうキャンペーン
攻撃キャンペーンがあって
それによって327人のGitHubユーザーから3325のクレデンシャルが盗まれました
ブログですね
ユーザーにどう侵害したのかみたいなところから言うと
多分オームネオンプレイクエストターゲットとかシルエインジェクションとか
理由は様々だと思うんですけど
PyPyトークンを多分最初は狙ってて
PyPyの認証トークンを攻撃者に送信するワークローっていうのを
プッシュして回っている
これはもう327人全員に全く同じの送ったか分からないけど
基本的には同じ送信先を示したワークローを各所で攻撃しまくって
マリーシャスな
違うかねPyPyトークンに限らずなのかな
327人に対して攻撃が成功して
結果として3325件のシークレットを盗めたよって話して
盗まれたものは本当に様々で
DockerHub GitHubトークン NPMトークンあたりが確認できましたって話ですね
直近先週ぐらい割と有名どころとか
毎週ありすぎても分かんないんだけど
コンプロミスとされたNPMライブラリがいっぱい出ましたみたいに
気持ち見かけるのが多かった気がしてて
なんかその辺これ絡んでるのかなっていうのをちょっと思いつつ
紹介させていただきましたという感じですね
327だからなんかちょっと警戒した方がいいのかな
なんかPGアクションズのあそこから結構落ち着いたかなと思ってたけど
なんかまたちょっと波がきてるのかなとは思う
ヒジの数で見てもままさにあると思うし
NXのあれもそうだし
そうだよね
この辺なんかできるのか分かんないけど
こっちはNXと比べると多分機械的にやってる気がしてて
セキュリティ対策と脆弱性
327人って数を思うと
効率的にやれちゃうならどんどんやるよなっていうのを今後も続くと思って
こうやっていかないといけないかもなって気はするな
そうだね1個目はパイパイ攻撃したやつ気づいて報告して収束したんだけど
もうちょっと調べると同じような攻撃のされ方をされて成功してるユーザーがめっちゃいるじゃんみたいになって
調査したら大規模でしたって話っぽいね
シンギラリティー攻撃NXのやつも触れないという
それは多分無関係っていう感じか
この3300漏れてるから多分今週来週やばいんじゃないかなって気がするんだよな
誰のが盗まれたかは大事だと思うんだけど
でもTGアクションズと一緒で2ホップ3ホップいって
どこまでいけるか正直予想がつかないから
皆さんも気を付けくださいパッケージを使うっていう意味でも気を付けてほしいし
パッケージをパブリッシュするというかワークフロー自体の脆弱性みたいなのもきちんと
パブリックはCodeQL使ってもらってプライベートはCodeQLが有用なんで
アクションリントJJリントを使って
あとはAIに聞いてどうかしましょうって感じですね
厳しいですね
直近仕事でこの辺向き合ってどうですか
向き合っておいてよかったなって気持ちですね
直近もそうだし2年前くらいからなんだかんだGitHub Actionsの改善を
なんだかんだずっとやってるけど
やる前めっちゃ危機感を持ってたかとか知識持ってたかというと
全くそうじゃないから
そこに難しさがあるなって個人的には思ってるな
CICDって僕らみたいに改善とか気を配って脅威をリサーチして
対策を重ねていくみたいな立場に立ってると結構詳しくなっていくし
一目でやばい奴わかるようになってくるんだけど
僕がソフトエンジニア中心生活だった時に
同じレベルでキャッチアップできたかというと全然そうじゃなくて
実態としてリポジトリ作って一番初期の設定で
初めて触るもの
でも触る時にめっちゃ詳しいわけじゃないから
やっぱ既存のやつ真似して
時にはちょっと部分的にピペして動いた
じゃあ開発しようみたいになることもあるし
それ以降って触るタイミングで壊れるタイミングぐらいしかなくて
全然詳しくなっていかないし
セキュリティ面もキャッチしてないとなかなか掴めないし
また不合理だなって思うのは
ギターバクションズの脆弱なワークフローを見ていった時に
その対策って普通にワークフローを書いてて
自然に満たされることってほとんどないと思ってて
どちらかというとかなりめんどくさいものが多い
シェルインジェクションとかは
変数埋め込みでハードコードしたほうが絶対楽だし
わざわざ演舞に通すなんて知識がないと絶対にやらないんだろうし
サードパーティーのハッシュ固定なんかもやんないじゃないですか
めんどくさすぎるし
あっとV1で済ますみたいなことだし
そこの不合理さもあるなと思うし
これが仕事じゃなくて趣味でNPMパッケージ書いてますみたいな
ところとかなってくると
ユーザーコミュニティがめっちゃでかければ
みんな指摘してくれるかもしれないけど
そうじゃないでもみんな使ってるみたいな
みたいなものとかが脆弱なものになってるっていうのは
なんかあんまり責められないというか
物によっては何年放置されてますみたいなのもおそらくあるわけで
それがなんか実はある分野においてみんな使ってて
有名ライブラリ5個ぐらいネストしていくとこそこれにたどり着いちゃうとか
全然あることだし
いやーなんかやってらんねぇよな
なんかもう開発者心の事情動力ではどうにもならんっていう前提で
いろいろ変えていくしかない気はしてて
そういう意味では先週話したイミュータブルリリースとか
またNPMのYDC連携とか
パイパイのフレイアカウントのメール未確認するとか
あれとかめっちゃいいなと思うし
あとピンニングラインフォースとかね
あれが真に働く世界になったら結構救えるものもある
そうだね
だからもう本当にここまで攻撃が流行ってきちゃうと
待ってらんねぇみたいな世界線も全然ある気はしてて
使ってるやつがピンしてくれれば待てないみたいな
そうなると自ずと淘汰されてくるみたいな世界線はあるかもね
何せなんか
そうだね
OSS開発者みんなに気をつけてくださいっていうのは結構厳しいものがあるよな
っていう気持ちですね
あとは
自分の会社のメンバーが被害を受けないようにって思うとやっぱもう
EDRとかになってくるのかなっていう
でも銀の段階じゃねぇしなみたいな気持ち
そんな気持ちですか
EDRって言ってんのかな
あれごめんちょっと待って
まぁ今回のケースは
企業が被害っていうよりは個々人のトークンが詰まったって話
だからこれが仕事の
ワークフローの改ざんなのか注入なのか
改ざんとかプッシュだから
会社でパブリックリポジトリを展開しててみたいなケースだったら
被害の範囲に入り得るけど
ほとんどそうじゃない気がするから
これがどう波及して僕らとか会社に影響を出得るかというと
普通に何かのパッケージが侵害されて
手元にあるビームインストールを叩いたら
そいつが落ちてきて
何かをフックにマリシアスのコードが走るとかかなって気がする
あとはどっかとかだったら悪意のあるイメージが
手元に落ちてきてとかもあると思うし
何かまずいものが本来信頼できるはずのパッケージに混ざってきて
降ってくるみたいなのが第一なんじゃないかなって気がする
ワークフロー侵害されないって意味だったら
それは守る手段があるし
僕らの場合は結構やれてると思うから
自分たちでコントロールの余地があるんだけど
どっちかというと自分たちが使ってるものが侵害を受けるっていう方に対しては
EDRって言葉を出したって感じかな
あとあれかサードパティアクションズとかは
EDRとかじゃなくてアクションズの環境の話だから
そっちはピンニングとかいろいろ合わせる
結局そこの管理者のアカウントが乗っ取られてみたいなところまで
もうどうしようもないもんな
あとあれかな
社員が個人で出してるOSSのワークフローに脆弱性があって
そこにめっちゃ強いパッドがあるとかはしんどいかもね
そのパッドになぜかうちのオルグの権限が付いたとか
最悪だね
まあそうね丁寧に考えると結構穴はあるかもね
パッドとかはオルグに関しては中央管理できるからとか
クラシックトークンじゃなければ大丈夫とか
大丈夫っていうかコントロールできるとかいろいろあるけど
まあまあまあそうですね
でも一番リアルにすぐ起きるだろうなって思うのは
脆弱なパッケージを手元に落とすパターンだと思うな
アタックベクターはいっぱいあるけど
サプライチェーン攻撃の脅威
狙いやすさで言うとそこだと思うな
サプライチェンジの日だなって僕は思いつつ
皆さんお気を付けくださいって何回気を付けろって言うんだって感じだけど
ここに引きくださいって感じかな
自衛の手段がないのほんと勘弁してほしい
そうねほんとに
そうだね
なんでこんなことにビクビクしないといけないの
まあなんかそのパッケージパブリッシュ
プラットフォームからNPMJSとかPyPyとかが答えを出さなきゃいけない時が
近づいてきてるのかなって勝手に思ってるけど
エコシステム自体に脆弱性があるというかさ
ある種の
ゼロにはできないにしてももうちょっとできることがないんだっけっていうのは
考えなきゃいけないんじゃないかな
なんかNPMとかPyPyとかが強くなって
相対的にGoのさ
めっちゃきっと偽造してるような
ダブルオーツとかもが弱くなってる
どうなんだろうね
どうなんだろうね
でもシェアのデカさみたいな
順々にいった時に何番目に来るかなんじゃないかな
普通にRubyとかもシェアデカいだろうし
なんでNPMとPyPyばっかり
NPM多すぎなんだよなパッケージが
的が多すぎるっていうのは
だからそれで言うとPythonもそうか
ちょっとさっきの発言は無意識で無責任だった
僕も頑張って考えますって気持ちですけど
1ユーザーとしてできることにやっぱり限界ある
まあそれはそう
はい
頑張っていきましょう
お願いします
Replay.fmを初めて1年がたった
ヤギ足静かなインターネットの記事ですね
はい
1年経ちました
お疲れ様です
おめでとうございます
僕も1年記事書いた
今週分じゃないけど持ってきたわ
どうですか
なんかまあ
なんだろうな
割となんかちょこちょここのポッドキャストの中で触れてきちゃったから
なんか今更感もあるんだけど
うん
なんかそうだね
あえて新しく触れるようなことないな
なんか全部このポッドキャストで触れてるから
先週ちょっと話してたもんね
聞いてくれれば
僕もそれと一緒っちゃ一緒だな
ああそう
先週話しかけて話せなかった人は
そうですね
さあ
1年間で2200再生ですか
素晴らしい
ありがとうございます
2200再生
オーディエンスサイズがね
多いのか少ないのか
まあでも少なくはないんじゃない
なんか全然
2000回か結構多いかも
全部2000回2200回の再生全部全部聞いてくれたわけじゃないけど
僕らが奪った総時間で言うと相当な時間を奪ってることになる
みんな時間を我々に見つけて
ありがとうございます
何もお返しはできないけどとかしょうもない話を聞くことしか
お返しはできない
ありがとうございます
Spotifyのフォロワーは36人で
なんかね全プラットフォームのオーディエンスサイズは分かんないんだよね
見れないのかな
難しそうだよな
仮にSpotifyの割合は見れるから
Spotify36で25%だから超単純計算120人ぐらいフォロワーがいるかもしれない
ブラウザで聞いてくる人多いな
でもなんかあれじゃないXに投稿したやつからそのまま聞いてる
そうなのかな
分かんないけど
30%ブラウザで聞いてくる
United States
分かんない
ロケーションランキングも出るんですけど
日本1位で2位アメリカで3%はブラジルから再生されてる
何なんだろうフローラーとか
分かんない確かにねそういうのあるかも
ちょっとアメリカから聞いてる人いたら
Spotifyは100%日本だね
デバイスの割合も出るんだ
iPhone少ないっす18%
Macは35.6%ですかね
まあちょっと母数が少ないから
一番再生されてるのはヤギ足転職します
面白いね
85回
みんな転職の話好きすぎる
タイトルがね
もっかいもっかいくらい転職したほうがいい
勘弁してよ
もうちょっと早いよ
ちょっと早い
ついで1回目が
コククマさんのやつがあれですね3位に来て
ゲスト会は結構稼げる
稼げるそうだね
早くクラインに全部かけてよの会が4位に来て
やっぱりタイトルちょっと
惹かれてるんだろうな
やっぱ頑張ったほうがいいよ
次からGPTに考えてみろ
逆に最下位は
頭がずっと締めあっさりとな会
第6回っすね
すげえ
すげえ再生数低いな
初期なのに
積み上げ
途中から聞き始めるからか
前も話したけど
1回から聞き始める
鮮度が大事
タイムリーな話題を紹介してるから
1回目だとね
今聞くと
懐かしトークになるよね
そこはあんま見せていいかな
もともと分析の機能とか使えなかったじゃん
そうだね
あれが出てくるようになっただけでも結構
確かにね
嬉しいね
皆さんダラダラ続けるんで
感想お待ちしてます
誰も聞いてないの推進で
誰も聞いてないの推進で
意外と意外な人が聞いてたりするから
結構
別にうかつなことは言わないんだけど
言えないな
偉いな
僕はうかつな言葉も
言うぞと言うわけじゃないけど
あんま意識せずに
まあそうね
まあパブリックであるからね
いつどこで何が掘り返されるか分かんない
そうそうそう
僕らどっちか炎上したときに
掘り返される
2024年にポッドキャストでこんな発言をしてました
やはりヤギ足は悪いやつだみたいな
悪い友なんだねって巻き込まれる
行こうな
ただでは転ばない
転ぶときは巻き込んで転ぶ
道連れ
正しいかその使い方
これが最後の記事かと思いきやね
あと3記事普通の記事が残ってるっていう
本当だ
これもちょっと先週の側編なんですけど
日米で裁判ラッシュ
性性愛と著作権巡る広告を広がる
福井検索弁護士が視点解説
弁護士.comのニュースですね
これねめっちゃたまたま流れてきて
是非と思ったんですけど
先週アンソロピックが訴訟されて
和解しましたって記事が
紹介したじゃないですか
フェアユース云々の話とかをしたんですけど
この記事はそれ含め
その裁判しかり
あと日本での
パープレキシティかなに対して
読売とかが訴訟したやつとかあるんですけど
その辺を弁護士が
弁護士の方
福井検索先生
ちょっと読み方間違ったと申し訳ないですけど
その方が丁寧に解説してくれてる記事です
先週僕がとにかく言ってた
これって何なんだろう
あれって何なんだろうって言ってたやつを
全て答えを出してくれていて
あとはその日米でちょっと視点
中華
差分みたいなのもあるみたいな話があって
これちょっとメモちゃんと残せばよかったな
その辺もすごい面白かったんで
紹介したかったという感じです
そうですね
例えばアメリカの同行みたいなところで言うと
30件か
創作権前の訴訟は30件ほど動いてるんだが
最大の争点は
AIによる学習がフェアユースに当たるかどうかみたいな話
2月にはフェアユースを否定したものもありつつ
5月にフェアユースを否定した時には
姿勢を示したものもありつつみたいな感じか
なるほどなって思ったのは
例えばフェアユースを否定してる背景みたいなところで言うと
軌跡論家みたいな話があって
なるほどね
AIが根鉄制する波外れたスピードと
波外れたスピードと規模の巨大さが
表現の類似性を問わず
学習された作品の市場を規範化させ
進行可能リクスクをもたらすという考え方です
だけどところが
6月の先週紹介したやつ
アンソロピックのやつでは
フェアユースを認める判定が出て
肯定したのかな
ただ海賊版の話では
著作権侵害を認定してて
トリッキーな判定ですよみたいな話とか
なので結構この1年間の間でも判定が
判決が揺れてるみたいな部分がありつつ
ややフェアユース否定の判断が目立つというような感じですと
日本のところは
そうですね
読売朝日日経さんが
パープリキシティを提訴みたいな部分があるが
これ知らなかったですけど
日本の著作権法では
日本の著作権法30章の4は
AI学習を一定範囲で許容してるんだが
表現された思想感情の
教授を目的とする場合や
著作権者の利益を不当に侵害させる場合は
学生を認めてませんというのがあって
論点としては
一つ目が記事の要約が
学習元の記事の創作的表現を再現してるかというところと
また著作権者なんで
読売朝日日経とかが利益を侵害されてるか
具体的にはパープリキシティを使うことで
元のクリック数が減ってないかとか
それによって不利益をこむってるかみたいな部分が
論点になるんじゃないかっていうのが
著作権法の比較
争点になりそう
予想とかありつつって感じですね
日米で判断が分かれるかみたいな部分の話は
米国のほうが
生性愛回りの開発を持っててあるから
本丸ではありつつ
日本が日本の法律で
侵害されるんじゃないかとか
そうですね
いろいろと動きが激しんで
今後もやっていきましょうって感じのところかな
すごい読みながらザザザッと雑にさまっちゃいましたけど
はい
ありがとうございます
またあれだねパープリキシティが
還元プランみたいなのを
発表したりしてるから
この辺もどうなるかみたいな話が絡んでくるし
またあれですね
大量かつ定期的な利用は個別の交渉が非現実的なので
利用規約的に確実的に復活処理が取られますみたいな感じで
ジャスラック型とYouTubeコンテンツID型っていうのを出して
なるほどか
なるほどな感じのところを思いつつって感じですね
パープリキシティのクリックされたら還元だよっていうのは
YouTubeコンテンツID型っていう表現なのかな
この記事だと
ジャスラック型は
全てを束ねる何かがいて
そこに許可を取ったら学習できるみたいな
世界観になるって感じかな
クラウドフレアみたいな
課金しないと弾くみたいなやつとかは
またちょっと別っちゃ別なのかな
感じですけど
どうなっていくんでしょうって思います
そうだね
あれはどっちかというと直接的に
アクセスに対して
あーまあ確かにね
アプローチは確かに別っていう
なんか整理
自己管理
自分でブロックしてって感じ
そのツールとしてクラウドフレアを扱っている
確かに
いやー
はい
ぜひ興味のある方はやってみてください
いや面白かったです
面白いよね
なんか弁護士特務の記事
なんかなぜか最近よく流れてくるんだけど
結構勉強になるから
サブスクライブしようかなって
サプライチェーン攻撃の影響
ちょっと流量多いなって気持ちで
そうだね
興味あるものないものの振れ幅がすごそう
そうそうそう
そうなんでね
ぜひやってみてください
じゃあ次
これね
エクネットセキュリティという
なんかXで流れてきたのを
拾ってきただけなんだけど
えーっと
もう忘れちゃったなこれ
ちゃんとサマリーを使っておけって感じなんだけど
確かなんか
Mac OSの中の
なんかのSDKかな
からに設定してた権限が
そうそうそう
結論ただの権限の
強すぎる権限が
あって
なんていうか強すぎる権限が
変なところについちゃって
結果的に
ビルトインのパスワードマネージャー
キーチェーンと
キーチェーンか
えーっと
キーチェーンとiOSアップ
デクリプションって書いてあるけどこれなんだ
iOSアップのデクリプションってなんだか
あんまり気にしてなかったけど
どっちかというとキーチェーンが割と個人的には
引かれたところで
3つ目の影響領域がフェアプレイで
暗号化されたiOSアプリで
これ自分で使ってない機能だから
全然どういうやつだ
まあいいや
えーっと
そういう感じで
キーチェーンの複合ができちゃったよ
って話です
AIサバリバーとか
ありがとうございます
Immutable Releasesの導入
はい
TCCフォークされたデータ暗号化されたiOSの
アプリのバイナリー
アプリのバイナリー暗号化されてんだ
へー
なるほど結構
なんか
うーん
別になんて言ったらいいんだろうな
これに関して何か学びがある
っていうわけでは正直ないんだけど
なんか
これインザワイルドで使われたのかな
多分悪用されてないんだよね
見つけて報告して直したっていう話だったから
うーん
悪用は
されてなさそうな気がするね
なんか結構その
OSにビルトインのさ
パスワードマネージャーって結構安心して
使えるかなって思ってたんだけど
意外とそうでもねえな
っていうのはちょっと思った
確かにね
とはいえなんかハードウェアまで
コントロールできてるmacOSが
他に比べて有利だよねっていうのを
言えるとは思っていて
そのうちこういうのが続く
もし続くとなんか激強パスワードマネージャー
みたいなのがアップルから
出てきたりするのかなとは
思うかも
あー
何の話かというと
セキュアインクレーブがさ
全てのデバイス
セキュアインクレーブって何ですか
セキュアインクレーブっていうのは
いわゆるなんか
トラステッドエクセキューションエンバイル
スペルがわからない
勉強物関係
セキュアインクレーブ
あーインクレーブはいはいはい
あーほー
はいはいはい
あーハードウェアレベルってそういうことか
なるほどね
確かにね
うーん
確かにね
激強パスワードマネージャー
アップルにして
完結できるのはこれで
めっちゃ安全だみたいなことは
言えるかもしれない
できるかもしれない
ただなんかデバイス間共有みたいなのがあると
やっぱり難しいのかな
うーん
なんかサーバーに暗号化されたものとはいえ
置いとかなきゃいけない
気はするのと
出口の特権取られたらとかは
サーバーには
置かないだろうけど
ローカルで
鍵も別にローカルで持っておけばいいから
うん
サーバーには暗号化したものしかないけれども
ただ結局複合してどっかに
アウトプットしないといけない
っていうのは難しいのかもね
うーん
ハードウェアレベルで担保されていると
こういう単純な権限ミスとかが
なければ端末に侵入されても
絶対に抜けないとか
物理的に抜かれても
ほぼ
めちゃくちゃ難易度を上げられる
権限レベルをたぶん
上げちゃえばいいんじゃないかな
上げちゃえばいいんじゃないかな
単純なその
特権だけだとアクセスできる
みたいな状態がたぶんできる
そのアップルの
セキュリティのホワイトペーパー読むと
結構その辺の話が書いてあるんだけど
レベルがいくつか
分かれてるんだよね
いやーでもむずいなー
結局その
作るのが人間である以上
分けてもそれをつけちゃうみたいなのは
否定はしきれない
なんかファイルボルト
レベルが書かれてるよね
ファイルボルトの暗号化の領域が
こういう状況だと
ここまで複合されているよ
みたいなのが分かれてる
うんうん
そんな感じで
そもそも
こういう話が
関わるような
領域の
事故に対して
影響を受けないような
管理ができればいいんじゃない
とは思うんだけど
全然専門領域じゃないので
なんとも言えないけど
たまにそういうのが出てきそうだな
なるほど
ホワイトペーパー
読んでみよう
これ一回紹介しちゃうよ
あーマジで
素振り不足案件だった
そんなに長くないんだけど
ノートブックLMに
組み合わせてワッと解説すると
結構綺麗に
効果ある
という
これがJASと共有
うんうん
じゃあ次最後かな
あーなんか
癒し箱に見えるなここまで
今日のラインナップに見ると
まあサクッとで
いかないかもしれないけど
鈴木俊介さんのGitHubのImmutable Releasesを有効にして
セキュリティーインシデントを防ごうという記事ですね
Immutable Releasesの
話は先週から先々週したんですけど
そうだね
気になってたところを
検証してくれてるんで
そこだけささっと紹介したいなと思って
一つは
Immutable Releasesを有効にした後に
無効にしたら
Immutable Releasesを
有効にしてた期間のタグとかどうなるのか
みたいなのは
ちゃんとImmutableのままになる
らしいです
なので
例えば極端な話
攻撃者がアドミにとって
Immutable Releasesを無効化して
過去のバージョンを
上書きするみたいなことはできない
守られてるっていう感じ
なのと
確かに言って思ったけど
ドラフトリリースはどうなるかというと
ドラフトリリースはミュータブルな状態になる
ので
これアズさんのブログかな
なるほどなって書いてあったんだけど
ドラフトリリース
それを利用して
リリース前の準備みたいなところは
工夫してワークフローを書く必要がある
みたいなことがあって
具体的には
リリースノートを
リリースノートとかもリリースしちゃうと
Immutableになっちゃうから
例えばリリース候補みたいな
プリンクを立ててた時に
リリースノートを
ドラフトで立てたリリースに対して
アップデート加えて
リリースする瞬間に
ドラフトからリリースにして
リリースするみたいな形になるから
その辺を加味して
いろいろ自動拡文だったらやったほうがよさそう
とか
あとはあれか
Immutableのやつはタグは削除できるんだけど
同じ名前のタグを再生するにはできないよ
とか
あとこれはなるほどねって感じ
リリースにひも付かないタグはImmutableじゃない
っていうのがある
これ地味にGitHubって
タグって別々の概念
リリースにタグをひも付けられる
タグはGitの概念かな
どっちかっていうと
実体としてはブランチみたいなものなんだけど
その辺は
ひも付けないとImmutableにならないよ
っていう感じですね
っていう気になるポイントを隅々まで
これが知りたかったら全部書いてくれてるんで
紹介しましたっていう感じ
今後のセキュリティの課題
です
ドラフトにしてリリースするのは
多分あずさんの記事と混同してるかもな
読み直さないと
書いてあったよ
ちょうど開いてる
ドラフトリリースの
まだしか書いてないけど
そうだそうだ
API周りでやろうと思うと
これだとできないみたいな癖があるから
そうだね
はいはいはい
この辺は一応書く
知っておくと良さそう
そんな感じです
活用していく過程で
皆さんぜひ読んでいってください
なるほど
タグがImmutableじゃないんだよ
良い塩梅というか
良い落としどころ良い目の付けどころ
なのかなこれ読むと
たぶんタグをImmutableにできないと思うんだよね
原理書
ギットの概念だからさ
そうだね
それで言うとリリースが参照して
タグを消すとどうなるんだ
Immutableのタグを削除できる
削除できるんだ
再作成できないのはもうたぶんGitHubのレイヤーで
防いでるんだろうな
全然その辺の仕様知らないな
タグ消すとリリースも消えるのかな
わかんねえな
まあいいや
あんまどっちでも
わかんない気もするから
リリースこと
削除することはできる
Immutableのタグも削除できる
リリースこと削除もできるし
それよりタグは削除することもできる
まあでも参照するときは
タグだもんな
おもしろい
自己解決しちゃったけど
そんな感じですか
14個
いやー
いいっすね
いろんな
サプライチェーン概念
インフォスティーラ概念になると
年賞
予言したか
サプライチェーン概念かもしれない
サプライチェーン概念って
思えばあの年からサプライチェーン攻撃が
当たり前になったねみたいな
サプライチェーン攻撃自体はさ
ずっと
まああるか
でもなんか
いやーそうね
サプライチェーン攻撃にもいろいろあるから
パッケージ経由の
まあでもあるか
ワークフロー
侵害概念かもしれない
言いたいことは
クリックフィックス概念
ワークフロー侵害概念
インフォスティーラ概念
次は何が来るのかな
何が来るんだろうね
なんか
これは危ない危ない言われてるけど
そんな目立ってない系
どう考えても生成AI
そうですね
どうなんだろう生成AIが直接狙われるのか
こういうなんか
従来の攻撃で
端末とかどっか環境に入った後に
足場とか横展開に
生成AIが使われるのか
どっちなんだろうね
気になるなぁ
どうなってくるんだろう
使われるその後
サプライチェーン攻撃の難しさ
後者は明確にどんどん増えていくと思うんだけど
前者は
意外とその
いたるところで刺さるっていう状況に
近いからもうちょっとかかるんじゃないかな
と思ってるのと
やっぱりその
効率よく見つけるっていうのが多分大変
環境環境に応じてその
テスト用のプロンプトがすごく書きにくい
大体どこでも刺さるみたいな
一旦一発目これでチェックすれば当たりが付けられる
みたいなプロンプトを多分
書きにくいので
確かに
探すの大変だろうし
要所要所で
使われることはあるかもしれないけど
なんかめっちゃ流行ります
みたいな状況には多分ならない
あとなんか
わかんないけど
有識者の意見聞きたいけど
攻撃者側が
本腰入れてないんじゃないかって気が
するんだよなぁどうなんだろう
今はまださ
LLMにめっちゃ詳しい研究者が
こんな方法で侵害できるよ
っていうのを見つけて
穴を塞ぐみたいな
ホワイトハッカーが
イタチごっこをしてるみたいな感じな気がしてて
言うてもやっぱ
あの
プロンプトインジェクションできるできると言いつつ
そこそこ知識ないとやっぱできない
みたいなことを思うと
攻撃者側の勉強が必要というか
生成合いがプロンプトインジェクションを
教えてくれたりするのかな
それもなんかない気はするなぁ
あと
いつその辺の均衡が崩れるかも
なんか
僕の中の仮説なんですけど
想像というか
まあ見守りつつ
便利でも扱いつつ
2年分もやりますか
できる範囲で
やっていきましょう
じゃあそんな感じで
皆さん次回もお楽しみにしてください
おやすみなさい
01:40:25

コメント

スクロール