ゾロ目に関するオープニング
こんばんは、Replay.fm 第66回です。
こんばんは、ゾロ目ですね。
ゾロ目、6回目のゾロ目。
6回、そうね、6回目のゾロ目だね、はい。
そうですね、はい、6回目のゾロ目ですね。
それ以上の感想が。
そうだな。
ゾロ目出してこう、もっとコツコツ続けて。
100回目のゾロ目、100回目のゾロ目はいくつ?
100、やばいな。
急に強プロみたいな問題出すね。
100、パッと。
1から数えて、100回目のゾロ目。
出たよ、AIだよ。
でもAI、数学苦手だから正しい答え出さないかもしれない。
いや、わからないよ、最近のChatGPTはわからんって。
意外といけるかもしれない。
すげえ考えてるもん、たぶんいけるよ。
エンジェルナンバー、ゾロ目。
N桁のゾロ目は必ず9個あります。
そうだね。
それはそうだね。
うん。
確かに。
答えは、13桁ゾロ目の最初だって。
だから1が13個並んだ数が100回目のゾロ目だって。
ジェミナイは5だと主張してるね、それで言うと。
早速掴み合ってないから。
いや、おもろいな。
なんか、まあ、はい。
正解言ってやめてくださいみたいな。
はい、正解わかったらちょっとこっそり教えてくださいね。
お前でも見抜けたらそうだね。
気になってて、気になって夜しか眠れない系のやつ。
終わったわ。
夜眠れたら十分。
ランサムウェア対策の考察
いやー、ちょっと私ことですが、喉が死んでるので、
ヤゲシ君がいっぱいしゃべります。
俺、今回あんまり読んでないよ。
じゃあいっぱいコメントしてください。
はい、いっぱいコメントします、はい。
頑張りましょう。
でもね、今週記事多かったっすね、めちゃくちゃ多かった。
多かったね。
すごい多かった。
なんかタイムライン流れてくんのをさ、バカスが放り込んでたからさ、なんかすごいことになってたし。
でもなんか半分ぐらいリアクトツーシェルじゃない?
まあ、いやでもね、先週ほど多くない。
多分5記事ぐらいじゃないかな、リアクトツーシェルは。
まあ、多分7記事ぐらいあるから。
全部で43個、お互い合わせて持ち込んでるからね、その中から。
選んでずっと読みますけど、今日は11件ですか。
いやいや、久々に、久々に間に合わないかもって思ったわ、なんか。
読み応えのある記事が多かった、すごい。
そうだね、まあ結構もう諦めてるけどな。
割と諦めてる。
よし、じゃあサクサクいきますか。
じゃあ1個目は、
クラウド関係におけるランサメア対策の考え方。
サクサ日経。
これ何、日経のテックブログなのかな、きっとね。
そうだね、日経テクノロジー&キャリアっていうサブタイトル。
あ、藤田さん、はいはいはい。
あ、ご存知。
なんか、こないだあった。
あ、ほんと。
こないだあった藤田さんだと思う。
じわったらすいません。
日経で過ぎてしまう藤田さんだったらきっとそうなんだろうね。
日経じゃないって余地がないことだけ祈ってるけど。
日経だったと思うけどな。
まあ記事の内容を紹介すると、
NWSってタイトルにはクラウドって書いてあるんですけど、
具体的に言うとNWSにおいてランサメア対策ができてるのかとか、
ランサメア攻撃撃っちゃ大丈夫なのかとか、
攻撃受けたときにシステム止まんないんだみたいな、
問いがしばしば、特に警総からありますよみたいなところに対して、
今日から実践できる対策ベースで紹介するよっていうイントロダクションから始まる記事なんですけど、
結構中身はボリューミーというか、濃厚な記事になってるかなと思っていて、
全然読めてない。
結構ね、目とお尻、たぶんヤギ足はそんな新しい処方はないんだけど、
でもこの記事いいなと思ったのは、結構その、
ランサメアってぶっちゃけなんすかみたいなところからスタートしてもたぶん、
今言った問いに答えるベースの慣れちゃ整う構成になってるかなと思ってて、
目地がすごい、目地を見るとたぶんわかりやすいんですけど、
ランサメアってそもそもなんなのかみたいな部分で、
なんでランサメア流行ってんのとか、ランサメアなんで防げないのとか、
あとは攻撃の、なんて言うんでしたっけ、
攻撃ライフサイクルか、イニシャルアクセスから映像化してみたいな、
その部分もちょっと触れていてとか、
そこに対してどういう対策をしましょうみたいな部分で、
ここもランサメアとかの話もあるし、
そもそもサイバーセキュリティにおいてっていう部分をフレームワークとか引用しながら紹介していて、
多層防御で言うと復旧検知防御、これたぶんミスト、
サイバーフレームワークとかなのかな、引用とは、
まあいいや、たぶんその辺でよく見るような基本的な考え方とか、
まあそれぞれセクションで具体的なこととか、
またランサメア特化で言うとバックアップ設計とか、
あと個人的に1個、なるほどねと思ったのはどれだっけ、
復旧手段の破壊か、アタック攻撃チェーンのやつで、
どこだ、復旧手段の破壊、そうだね、
ランサメア攻撃でよくやるのは暗号化より先に復旧する術を潰しにくるぞみたいな、
いうのが書いてあって、この観点は意外となんか、
意外となんかバックアップ大事みたいなのよく見るけど、
これ考えてるかみたいな問いは見たことなかったんで、
ほんとにしたんですけど。
このクラウド環境におけるランサメア対策の考え方ってさ、
結構ある程度触ってる、やってる側の人間としても、
どうなんだろうねって、何を暗号化されるんだろうねみたいなのって、
結構わからん部分があるじゃん。
このタイトルでそこを整理してくれてるの結構いいなって、
思ってピックしちゃうんだけど、ちょっと読む時間がなかったです。
確かに、そりゃそうだね、結構AWSの具体で、
今僕が引用した復旧手段の破壊みたいなとこだと、
この辺のAPI叩くよみたいな具体的なやつが書いてあったりして、
なるほどねみたいな、結構解像度上げやすいっていうのはあるかもね。
クラウド環境のリスク
この辺は実例があんのかな、観測してる。
AWSどうなんだろうな、クラウドでランサムで被害に遭った系は、
僕はS3暗号化しかまだ知らないんだよな。
どうなんだろうね。
やっぱなんだかんだよ。
そうそう、世の中でその溢れてるやつもさ、かどかVMだったっけ。
で、他は多分割とオンプレ系じゃん、大体。
そうだね、オンプレのやつがやられてるね、大体。
社内システムに入り込まれて検知できずにみたいな、テンプレというか。
なんかそうなんだよね。
別にオンプレのサービス持ってません。
なんかほぼGoogleカラウトですみたいな、なんかケースにおいて。
別になんかカスタマイズすればさ、何でもやりようはあるんだけど、
でも極論その、なんていうか、ローカルの端末を乗っ取っても別に何もできんみたいな、
なんか状況にしとけばさ。
あとはなんか端末に閉じるじゃん、結構。
なんかその先のその横展開とかまで含めても。
そうだね。
まあ理論、理屈上はね。
入り口が端末のケースはそうだね。
端末じゃないケースの場合はじゃあどうなのって言われると、
なんかそもそもそんな入り口あるかって言われると。
まあめっちゃ鉄板はAPIキーから侵害だよね。
ああ、そうだね。
どこだっけ、結構、なんかそれはね、
なんかみんなが知ってるような企業のやつとかでもやらかしてね、よく見かけるし、
なんか、例えば業務委託先に吐き出したやつがリボークされてなくて3年後にやられるとか、
だからあんま珍しくないかなって。
だからそれと、
でもなんかそれがその、なんて言ったらいいんだろうな、
ランサムウェアのでっかいキャンペーンとかでさ、それを狙われるかっていうと、
なんかあんまり想像つかなくて。
ああ、そうだね。
なんか、いやわかんねえな、わかんないけど、
なんかAPTのそのシナリオの一つとしては全然あれだろうなって思うんだけど、
なんか、どうなんだろうね。
そのクレデンシャルを多分かき集めて売ってる人が多分犯罪者側にはいるはずで。
うんうんうん。
なんか、
確かにね、自分でやんないっていうのがあったね、確かに。
そうそう。
だからなんかそこが、
まだうまみがないというか、そこよりうまいところがあると思われて、
ライトランサムをやる側が思ってるのか、
まあ狙ってもあんまり単ないよねと思われてるのかな、
その辺はちょっとわかんないな。
うーん、どうなんだろうね。
なんかGoogleクラウドのサービスアカウントのキーのリストみたいなのが、
こうまとまった数で売られるようになったら、
なんかそれに特化した、そのマルウェアみたいなのが流行るのかな。
でもそれもはやマルウェアじゃないよね。
だって外から直で侵入されるじゃん、なんか。
まあその先か。
そう。
それで中に何を配置するかだけど。
うーん。
うん。
なんか、まあイシツじゃないか、
Googleクラウドだったらコンピュータエンジンのインスタンスに、
まあこれ仕込むとかは全然あり得るんじゃないかな。
まあGKEにシレッドポット立てるとか。
うーん。
なんか暗号通貨掘られてたとかはまあ、なんかなくはないのかな。
うーん。
ランサムと違うものでGoogleクラウド侵入みたいなもので言うと。
うーん。
まあだからアクセスの継続化をして、
うーん。
みたいなパターンも多分あるし、
暗号通貨のマイニングに使われるみたいなパターンも多分あると思うし、
でも何にせよなんか、うーん、なんか結構その状況状況で、
いやー分かるな、なんか8割方このやり方で通るみたいなやり方があるんだったら、
なんかワンチャンあるのかなと思うけど、
うーん。
例えばサービスアカウントのキーとかだったらさ、
うん。
ぶっちゃけそのサービスアカウントについてるロール次第ってなんかできることめっちゃ変わるから、
なんか。
でもさ、それはオンプレも一緒じゃん。
取ったIDの権限次第で、
そのまあ、そこで終わりになるのか横展開になるのかは。
それで言うとなんかオンプレは多分もっとその分かりやすいんじゃない?
そのなんて言うか、ADにリーチできない環境ってまずないから、
うんうん。
うーん。
そうか。
その辺解像度低くてあんま差分がわからんかも。
うーん。
なんかもうちょっとパターン化しやすいんじゃないかなとは思うな。
そうか。
そのなんて言ったらいいんだろうな。
なんかそのこう、
よくあるパターンのそのレベルが何段階かあって、
そのレベル分けが結構荒い感じ、イメージとしては。
ちょっとわからん。
俺も別にそこまで詳しくないから何とも言えないけど、
なんか、
Googleクラウドほど細かくないというか、
うん。
もうちょっと荒いこうレベル分けがあるようなイメージ。
うんうん。
うーん。
なるほどね。
あとはなんかクラウドプロバイダーは結構、
クラウドプロバイダー側で僕らも見えないとこで結構やってくれてる説もなくはない気はする。
うーん。
まあ責任協会も当然あるんだけど、
そのサービスアカウントキーとかは、
AWSがあるかわかんないけど、
Googleクラウドとかはその組織ポリシーで設定すれば、
まあ侵害されてるっぽいと検知したら勝手にブロックするみたいなのがあったりもするし、
まあアクセス元がどうなんだろうなどこまで、
まあでもあんまどうだろうわかんねえなその辺は。
まあでもやられるときはやれるって思っとくのが多分いいだろうな基本的には。
うーん。
まあなんかバックアップに尽きるんだよな結局。
まあそうだね。
うーん。
じゃあAWSでどうやんのっていうところを割と書いてくれてるんだよなこの設計の考え方でなんか。
そうだね。
うーん。
ランスマイヤー対策の重要性
あとはなんかその技術的じゃなくて組織文化としてランスマイヤー対策みたいな話も書いてあって。
うーん。
ランスマイヤーとは何か具体的にAWSにケースはどうすればいいか、
そもそもランスマイヤー対策大事だよっていう、
まあフードとか経営課題に持ち込むにはみたいなところの。
うーん。
あとまあ社内教育みたいな話もあるのかな。
うん。
もう全部まるっと触れてるとても分厚い記事って感じですね。
いや、いい記事でした。
なんかアドベントカレンダーの中にポッて出てくるにはなんか惜しいぐらいの記事。
うーん。
普通に、普通になんか、
なんか勉強会とかやってほしいぐらいの感じの記事でしたね。
うんうん。
そうだね。
いやー。
そうだね、間違いない。相当なボリュームだね。
うーん。
なんか今さらーっと読んでたんだけど、なんか話しながら。
うんうん。
いやー。
まあ何せなんか結構こういう試行実験っていうかなんかある種の脅威分析的なアプローチで、
なんか今どうなんだっけみたいな部分はやっぱやんないとダメなんだよね。
うーん。
でもなんか結構なー、その思考を深めるのがなんかなかなか難しい領域というか。
うーん。
まあでもなんか個人的には実像つかみやすい気はするけどね。
なんか調べりゃどうにかなるというか。
うーん。
まあ。
なんかもうちょっとそのもっとジェネリックにリサスターリカバリーってどうなってんのっていう方からなんかアプローチした方が、
なんか本当はいいのかもね、その。
何がどこまで壊れても復旧できますよっていうのが多分そのまま生きてくるはずで、なんか。
そうだね。
まあ漏れちゃいましたはまた話が変わってくるんだけど、なんかでも漏れちゃいましたの部分はなんかこう、
まあある種切り離して考えればいいっていうか別にこれじゃない経路でも漏れる可能性は、
ランサムウェアじゃない経路でも漏れる可能性はあるわけだから、なんか切り離して考えられるというか。
うんうんうん。
うーん。
そうだね、確かに。
はい。
はい。
そんな感じですね。
リアクトのデシリアライズの問題
いや良かったです。良い記事でした。
ありがとうございます。
じゃあ次お願いしようかな。
レッスンズフロムリアクトツーシェルっていう記事ですね。
これ何の記事?
Dev.
Dev.2の。
個人かな。
個人の記事だね。
うん。
えーっとなんか長ぇなーって思ってさらーっと流し読みしちゃったんだけど、
なんか話としてはそのリアクトツーシェルのなんていうかこう学びというか、学びっていうよりはどっちかっていうとなんかこう、
まあ良くねーよなっていう話なのかなと思っていて、そのなんかものすごく大雑把に言うと、
そのーなんていうかある種のそのやきな、ある種の脆弱性の焼き直しだよねこれっていう主張というか話なのかなっていうふうに理解していて、
なんかまあ今までその安全でないデシリアライズみたいなものってなんか別にこれに限らず起きてきていて、
なんかなんでそれをこうあれできなかったんだろうねって参考にできなかったんだろうねみたいな話を、
なんかこう提起してくれてる記事っていう感じかな。
うんそうだね。
すーげー大雑把に言うとそんな感じかな。
安全でないデシリアライズみたいな部分って言うとその、あれかな、
心霊的な値をデシリアライズに入れるアーキテクチャにして失敗した例みたいなのを結構具体的に何個か挙げてて、
なるほどね、ジャバのこの関数で何年、何年も直せてねーとかPHPでこれーとか、
パイソンでこの部分は安全じゃないからそういう不良体使うなとか。
ジャバはなんか実際に名前ついてるのあったよね、なんか。
この記事で紹介されてたの何だったかなー。
なんだっけなー、えーっと、
ジャバのー、忘れちゃったー、忘れちゃったー、
えーっと、なんか名前がついてたやつがあるんだよな。
うーん。
まあ、その辺、歴史繰り返しちゃってるよねみたいな話と、
なんかね、結構まあ、丁寧にRSEをディスってるなって僕はちょっと捉えちゃったんだけど、
リアクトJSって今まではクライアントで動くものでしかなくて、そういうものだったけど、
まあ、リアクトサーバーコンプレンツのコンセプトであり実態でもあるけど、
サーバーコンプレンツはその書き味としてはリアクトを書いてるようで、
ただ、UseServerっていうディレクティブをファイルボートに足すと、
ある不思議クライアントから呼び出せると。
呼び出すと、まあコンパイルって言っていいのか、コンパイルというか、バンドル時に、
えーっと、にょろっと内部的なAPIが入る。
で、まあそのAPIの仕様とかそのコントロール権は、
まあ実装時には全くないし、まあその部分で脆弱性が出たよねっていう話で、
なんかその利便性っていうのを優先して、
まあそのクライアントとサーバーの境界を曖昧にしちゃったよねとか、
またなんか、これは完全に言いたいだけだと思ったけど、
サーバー側のJSベストじゃないのにこのアーキテクチャどうなのみたいな、
それは別についでに言いすりすぎるなと思って、
僕はまあそこはそれをしていいかなって個人的にちょっと思うというか。
なんかでも結構同じことがリアクトルーターのV7とかにも言えそうだなと思ったけど、
どうなんだろうね、なんか。
V7は。
結構あいつもなんかその謎のAPIコールしてて、
なんかあんまコントロールできないやつがあるなーって思いながら触ってるんだけど。
まあ抽象化されてるよね。
まあでもあれはその多分リアクトサーバーコンポーネントとは別であるとは考えてない。
そうだよね。
うんうん。
なんか13APIの統一構文でしか多分ないというか、
そのあくまでリアクト、フロントエンドで動くリアクトコンポーネントを元に動いてる、
まあバーチャル、まあバーチャルドームじゃないのか今。
あの、ガチャガチャ動くドームと、
それが叩くようなAPIが勝手に入るっていう話だったんだけど。
そうだね。
リアクトサーバーに関しては結局サーバー側でリアクトが動くっていうことだし、
それするためにシリアライゼーションしないといけないっていう部分だから。
うん。
そうだね。
リアクトルーターに関してはちょっと別で考えていいかなとは思うけど。
うん。
なんか思ったけど、そもそもJSONってそんな安全じゃない説ない?
なんか。
うーん。
わからんけどPHPのシリアライズに当たるものがJSONっていう考え方も多分できるわけじゃん。
なぜかというとJavascript Object Notationなわけだからなんか。
そうだね。
JSONだと安全って話があるんだっけこれ。
JSONだと安全っていう話があるかないかで言うと一定あって、
この辺の中にはなかったかな多分。
はいはい。
でも一応言及ある。
そういう話は書いてあるよね。
結局でも別にJSONをパースするだけだと、本来問題ないわけじゃん。
例えばだけどPHPとかでJSONをパースしても別にオブジェクトにマッピングされないわけじゃん。
うん。
だけどCode.jsにおいては結構オブジェクトに時間マッピングしやすいみたいななんか構造があるような気がせんでもないなとふと思った。
なあね。
がわからん。
PHPのシリアライズ、アンシリアライズが結構そういう感じじゃん。
なんかそれに当たるのがJSONにおいてはJSONっていう捉え方もできなかねえのかなとちょっと思って。
ごめんなさい。
切っちゃったけど。
いやいやいや。
リアクトサーバーコンポーネンツにおいてはなんかデータフォーマットあんま関係ない気がするんだよな。
そもそもどうなんだろうね。
どうなんだろうね。
なんかそのランタイムで動くものをクライアントから受け取ってるっていう部分が多分ダメで、
だからその中身がJSONだろうと独自のシリアライゼーションだろうと処理ミスったアウトっていう。
信頼できないものをデシリアライズするなっていう話だから。
そうだね。
まあそれはそうだね。
でそれを何か解釈して実際にプロセスとして動かすっていう部分が多分リアクトがやりたかったことであり、でもそれが危ねえじゃんっていう話な気がしてて、
でそれを安全にやる方法があるのかっていうところに対して、
まあこの記事の論調としてはなんか人類にはむずくねっていうまあ威厄というかしさというか、
僕の解釈ですけどそういう話なのかなっていう。
まあ完全にクライアント側でそのコントロールされてるデータを安全にデシリアライズするっていうのはまあ無理だよね。
無理だと思う。
そのバックエンドで署名してクライアントに返してそれをまた送ってもらえば大丈夫なんだけどね、なんか。
ああそうね。
まあやんないだろうなそんなことパフォーマンス的に。
いやってかそもそも無理じゃん。
だってクライアント操作に応じてそのバックエンド側で何らかのアクションを出すっていうものでしょ。
ああまあ確かにね。
うん。
まあ確かに。
いやあそうなんだよな。
ちょっとフロントエンド界隈の人のツイッター後で見に行こう。
なんかそのリアクター界隈がどういう論中になるか結構やっぱ気になるな先週も思ったけど。
なんかこの件を受けてまあ出したもん引っ込めらんないと思うけど、
まあせめてさリアクトサーバーコンポジェクトどうなんだろうな。
フロントエンドの脆弱性の考察
なんかNext.jsとかはデフォルトだとオンになってるからさ。
例えばそういうのを使う人だけオプトインにしようよとかそういう流れとかは生まれ得るのかな。
わかんないけど。
結構とばっちりなんだよね。
リアクトサーバーコンポジェクトを使ってない人からしたら正直。
まあね。
複雑だから様子見してる人も多分めっちゃいるし、そもそもめちゃくちゃステーブルなものではあんまない気はするから。
いやどうなんだろうちょっとその辺は僕のフロントエンドキャッチアップが遅れてて何ともなんですけど。
なんか結構バーセルガーみたいなこと言ってる人もいるけど、その辺はどうなんだろうね。
バーセルガーの後次第だな。
いろいろ言われてて、バーセルの脆弱性のハンドリングがいまいちいけてないみたいな話とかもあるし、
ネクストとかリアクト乗っ取り気味にいろいろやってるから、
実質的にOSSだけどバーセルの思惑でいろんなものが入っていて、
体制としてあんまり事情作用って言い方ちょっと微妙かもしれないけど、
RCの多分安全に作ろうみたいな力学が働きにくいみたいな的な主張とか。
でも個人的にはちょっと飛躍してるかなって気がするのかな。
今回のやつってリアクト本体の脆弱性だから、ネクストJSは究極的には関係なくて。
バーセルガーだからリアクトのほうにもコントリビューターめっちゃ送り込んでてっていう話。
でも別にバーセルガー支配的なわけじゃないから、
もちろんめちゃくちゃでかいコントリビューターではあるけど、
どうなんだろうね。
リアクトサーバーコンポイントに関してはそもそもバーセルじゃなくてショッピファイの人だった。
ショッピファイガーの人だったと思うんだよな。
僕が知ってる範囲だと。
だから別にバーセル、
僕が知ってる範囲だとバーセルにする理由はあんまりない気がしてて、
ただ彼らも稼がなきゃいけないから、
Next.jsの開発に関してはバーセルとのインテグレーションを強くするとか、
あとは直近なんかあったんだけど、
別のプラットフォームにデプロイしづらくなってる仕組みうんぬんみたいなちょっと燃えて、
じゃあ対応するよみたいなうんぬんとか、
そういう部分があるのは否定できないけど、
どうなんだろう。
個人的にはそう思うなら使わないっていうのが一番いいんじゃないと思っちゃうか。
とはいえなんか事実上のデファクトだよねとは思うからな。
それはそうなんだけど、
リアクトサーバーコンポーネントの課題
今だったらリアクトルだとあるし、
別にコントリビューションできないわけじゃないからさ、Next.jsは。
そこは、
ネクストはそうだね。リアクト使わない結構難しいなと思って。
それはそうだね。リアクトサーバーコンポイント使わないとかできるからさ。
そうだね。とはいえなんかでもそこを使う側がめっちゃ気を付けなきゃいけないってやっぱしんどいなと思っちゃうな。
今時点でそもそもリアクトサーバーコンポイントうんぬんじゃなく、
リアクトを例えばSSRアーキテクチャ組むとかを自前でやるのってほぼ多分、
結構上級者じゃないと無理だから。
そこのレイヤーはもう、
もうリアクトサーバーコンポイント危ねえわと思って使いたくないっていう意思決定をしたいんだったら、
僕だったらリアクトサーバーコンポイントをオプトにしないという効果しない、
なるべくいいSSRフレームワークを探すんじゃないかなって気がするな個人的には。
そんなものがあるかは分かんないけどね。
なんか、フリーライドしてる以上は、
フリーライドというか、ある程度巨人の肩に乗っかる以上は、
向き合いたくなくても向き合わなきゃいけない気はするね個人的には。
いやーちょっと有識者ヒロッピーとか呼びたいな、
なんかその風邪うんぬんは僕は、
僕が知ってた最後の情報、最新情報だとなんかそういう認識できるかな。
ウェブクロートの間に挟まるウェブ素人。
何にも分からない顔で、何にも分からない顔で俺が挟まっとるわ、きっと。
いやいや僕もだいぶ分かんないんで。
フロントエンド界隈はマジ分かんないからな正直。
流れが早いね。
多分俺とタイムラインが多分違うじゃん、まずその。
そうだね。
見てるから。
うんきっとね。
知らんからそのなんかショピーファイガーみたいな話とかも別に。
知らんし別に興味もないという問題があって。
その辺はでもあれですよ。
モザイクFMにいろいろ聞いてお世話になった感じ。
偉いね。
まあでも悩ましいですね、今回のゲームとか結構。
まあもう起きないよねとは言えないよなっていうのが今んとこの歯から出た情報だと。
歴史は繰り返すし。
まあリアクターってかRSCが今後どうなるのかは分かんないけど。
うーん。
なんかでも確かにこの諸々の議論を踏まえてみると、
2025年になっても人類は愚かだなっていう感想になっちゃうのはなんか結構興味深いな。
そうだね。
結果だけ見るとね。
今時点の経過だけ見るとそんな気がする。
説明可能なプロダクトセキュリティ
いやー、
まあそのセキュリティに携わり始めたのがそんなに、
携わってからそんなに年数経ってないんで、
このPHPではこれがあってこれがあってっていうのを見て、
うーん、これは確かになんか批判的になる気持ちも分かるなって思ったわ。
うーん。
まあそうね。
はい、そんな感じですか。
はい、そんな感じです。
はい、じゃあ次は。
あー、これね。
はい、説明が可能なプロダクトセキュリティについての一考察。
えーと、なんだ。
GMOインターネットグループアドベントカレンダー2025の10日目の記事ですね。
フラットセキュリティの斉藤さん。
まあ、名乗ってないから斉藤さんとしておくか。
斉藤さんの記事でございます。
はい。
うーん。
これはなんかぜひ読んでほしいなーとしか言いようがないんだけど、
てかまあ読んでほしいなって何で言ってるかというと長いんですよ、例によって。
そうだね。
うーん。
で、なんかその、どういうその趣旨なのかというと、
あの、プロダクトセキュリティという軸でその、
なんて言ったらいいんだろうな、なんか、
そのプロダクトを提供する、まあ冒頭の部分をそのまま読んじゃうと、
プロダクトを提供する組織が向き合うべきセキュリティとは何かについて、
なぜあるのかという観点をもとに、
説明可能なプロダクトセキュリティの在り方について、
一考察を書いていきますという趣旨でやっていて。
うーん。
なんか、まあステイクホルダーってそもそも誰なんだっけっていう部分の前提の整理とか、
なんか損失、避けたい損失って何なんだっけみたいな部分の前提の整理とかをしつつ、
目的って損失を出さないっていうところになるけれども、
それってつまりこういうことだよねっていう話を書いてくれたりしてるような感じかな。
で、その上でなんか手段としてリスクベースのセキュリティ対策をしなきゃいけないよねっていう話を書いてくれていて、
リスクベースのセキュリティ対策っていうのはつまり資産を特定する、
その守りたい資産って何ですかっていう問いに答えられるようにするっていう話だったりとか、
ステイクホルダーと損失、リスクの構造を理解するプロダクトにおいて、
なんていうか、ある種のリスク評価の話なのかな、きっとね。
OWASP SAMとかを例として挙げてくれてるんだけど。
で、あとはどこまでの損失なら許容できるかを決める。
要はこれはどっちかというと言い換えると、多分どのレベルだったら何らかの対応をしないといけないのかっていう、
ある種の線引きの話なのかな、きっとね。
なんか別に全部やる、何もかもやるっていうのは無理だから、
そのどこかで線引きをしないといけないよねっていう話と解釈してるんだけど。
なんかっていう話とか。
で、じゃあ何かをしなきゃいけないってなったときに、
何をして何をしなきゃいけないのかっていうのを決めてやっていくっていうのが必要だねみたいなことを書いてくれてるような感じですね。
これは何かどうでした?
何かどうでしたって話をしたくて持ってきてるんだけど、実は。
なるほどね。
そうですね。
なんか自分がセキュリティやってく中で、
セキュリティってこう向き合っていくべきだよなみたいな部分と概ね一致する感じで、
かつ何か綺麗に言語化されてるなって印象があって、
とてもいい記事だなっていうのと、
またただ何かこれ感想って感じなんですけど、
結構そのセキュリティのサイバーセキュリティ対策の本質というか、
何かやるべきこととか、また立つべきスタートライン、
何かみたいなものをかっちり言語化すると何かこうなるよなっていう気持ちでも読んだ部分があって、
何かこうなるよなっていうのは結構何かセキュリティフレームワーク的な硬さがあるという。
そうね。
そう。
多分。
何かそうだね。
何か僕がソフトエンジニアの時代にこれ見せられたらちょっとアレルギー反応。
いや微妙だな。
ちょっと読むの大変そうだなって第一印象を持ってたっていうか。
そうだね。
何かある種の柔軟性に、ちょっとあえて何かこういう言葉を使うんだけど、
何かある種の柔軟性に欠けるというか、
何て言ったらいいんだろうな。
何かこんなにかっちりじゃあ実際の開発でやれんのかって言われた時に、
何かうってなっちゃうような部分っていうのがあるのかなとは。
同じような印象を持ってて、
何かめっちゃいいまとめ、いい言語だなとは思いつつちょっと重いかなっていうふうには思った部分もあった。
例えば何か資産の特定の部分の話とかさ、
何かこれをやらないとじゃあ先進めないかというと何かどうなんだろうなと思っていて、
その何て言ったらいいんだろうな。
何か網羅性を担保しようと思うとこの根っこからやっていかないといけないんだけど、
何て言うか根っこから網羅性を担保していこうとすると、
その途端に何か結構壮大な絵を描かなきゃいけなくなっちゃうみたいなジレンマが多分あって。
インハウスのセキュリティチームにおいて、
体制を確かなものにしていくために必要なのってどっちかっていうと、
社内絵の信頼資産の構築みたいなところが多分あるはずで、
何かいきなり壮大な絵を描いて動かし始めても、
なかなか要はこれこれこういう、
要はこの言語化がまず前提としてあって、
分からんでもまあ組織によると思うんだけど、会社によると思うんだけど、
要はこれがフィットする会社ももしかしたらあるかもしれないし、
私が言いたいのはこれがフィットしない会社も多分あるはずだよねっていう話で、
要はセキュリティのなんていうか体制を組んで実際回してるけど、
それって本当に意味あんのみたいな問いを常に投げかけられるわけですよ。
そういう状況においてその壮大な絵を描いて、
できるだけ網羅性高くやっていきましょうみたいなのを、
いきなりやり始めるのって結構難しいと思っていて、
なんかそういう中でそのいろんなものが特定できてない、分からんっていう中でも、
走り出さないといけないっていう場面が絶対あるはずなんだよね、なんか。
なんかそのいやスタート地点なのかな、
なんかそういう今やかしが言ってくれたような、
なんか現実ここからスタートせなあかんみたいな、
いろんなスタート地点があるんだけど、
多分なんかどの距離とか時間軸はすごい幅があれど、
ちゃんとセキュリティをやりこんでいくと、ここを通る気はするんだよね。
だからここに通り着くというか。
それはそう。
だからなんかそこがなんか悩ましさというか難しさというか。
だからなんか登り方、これ登り方みたいな部分は、
別にこの記事のスコープ外だからあるけど、
これ何にせよおおむねこうありたいよねみたいな部分の言語化としては多分めちゃくちゃ素晴らしくて、
セキュリティの実践と課題
ここへの登り方は企業の現状のセキュリティレベル、
サイバーセキュリティの成熟度みたいな変数もあるし、
事業って変数もあるし、経営の考え方みたいな変数も出てくるだろう。
そうだね、セキュリティっていうところに対してのその捉え方、考え方、
リスクの一部として見たときのセキュリティがどういう見え方をしてるかみたいなところがめちゃくちゃ関わってくるかなとは思うので。
その登り方が結構やっぱ難しかったなとも思うし、
悩ましいというか、
改めて今話聞いたり話ながら思うけど、
そこは結構そこの時点が、時点じゃないか。
うちはこう登りましたみたいなやつが。
結構いろんな会社が出るといいのかなって気持ちになってした。
これがなんかある種のベンダーであるフラットセキュリティの人っていう立場から出てきてるっていうのは、
別に悪いことじゃないかなとは思っていて。
そうだね。
ドキュメントのところにアザラさんの名前が書いてあるね。
アザラさんですね。
アザラさんこと斎藤さんです。
でもこれいいよな。
いいまとめだしいい言語化っていうのは最初に言った通りで、
ぜひこれを持ってユーザー側に入ってきて、
やってみてほしいなって。
別に変に煽りたい人は全くなくって、
これを言語化できる人間がユーザー側に入って、
どこまでやれるのかっていうのを普通に楽しみにしてる側面も、
楽しみにしたい側面もあるし、
これが言語化できる人がユーザー側にいるっていうのはすごく、
少なくとも業界にとってはいいことだなと思うし。
そうだね。
ありがとうございます。めちゃくちゃいい気持ちだった。
ポケットに入れておきたいなって気持ち。
そうだね。
結構この基本に立ち返るみたいなのって、
結構大事かなと思っていて、
ポケットに入れておきたいって割といい表現だなと思ったな。
割となんかセキュリティマネジメントどうしたらいいんすかねみたいなのを、
外の人と話すことがあったりするんだけど、
ちょっと迷ったらISMSに立ち返ってみるとかはよくやるかなって言われて、
おーなるほどーって思って。
そういう立場だと多分ポケットに入れておきたいのがきっとISMSなんだよね。
なるほどね、確かに。
いやー大事だよな、
ブレないというか、
目的に立ち返るというか、
ハウの、だから登り方が無限にあるからこそやっぱ、
アンカーとしてはめちゃくちゃ1個持っておくと、
遠回りせずに済むっていうのはある気がするね。
ありがとうございます。
はい。
次いきますか。
AWS脅威モデリングの概要
AWSのReinvent 2025の共有記事で、
スレッドフォレストを使用した脅威モデリング概要編
紙無しエンジニアブログの記事です。
これもなんかさらっと流し読みしかしてないんだけど、
これなんか多分あれだよね、
AWSの中でやってる脅威モデリングの話を紹介してくれてたのかな、
多分、講演の内容、セッションの内容としては。
結構、割と難しいな、
なんかさらっと見た感じ、今時の脅威モデリング、
要は、今時のって言い方もおかしいな、難しいけど、
いわゆるストライドガーみたいな話ではなくて、
どっちかというとAWSの中でこういうふうにやってきたよっていう、
ある種進化した脅威モデリングの話をしてくれてたのかなっていうふうに、
勝手に解釈していって、
そんな感じかな、もうそれしか言うことがないんだけど、
割と4つの質問とか結構良かったな。
これなんか、今時中から一応古くからのメンタルモデルとして使われてきたらしい。
らしいね、これはね。
でもめちゃくちゃ普通にこれ良いじゃんと思ったから、
これなんで、昔脅威モデリングめっちゃ検索したときにこれたどり着けなかったんだけど、
俺もあんまり見たことない気がするんだ。
あんまりっていうか、ちょっと記憶に残ってないだけかもしれない。
そうだよね。
データフローダイアグラムを書きましょうとかは全然あるんだけど。
うん。
脅威モデリング自体の実態をつかむ上で、
普通にめっちゃ実在基準にもなっていいし、
なんか壁に貼っておきたいね。
壁に貼っておきたいね。ポッケに入れるものと壁に貼るものと。
あとあれだな、ステイクホルダー巻き込んで脅威モデリングしようみたいな話は、
脅威モデリングちゃんとやられてる会社はやっぱどこもやってるよなっていう部分と、
ビジネス側の担当者も巻き込むっていうのは意外だったみたいな記述があって、
とかあったりとか、脅威ステートメントは知らなかったんですよね。
これはもう明日真似しようと思ったんだけど、
脅威のリスト的なものを作るときに、
テンプレ、それを一つの文章で表現するための文章テンプレみたいなのを脅威ステートメントって呼んでて、
脅威ソースはなんで、ある脅威ソースがある前提状況を満たした上である脅威行動を行い、
それによってある影響は生じっていう、今僕が言ったある何たらっていう部分がテンプレになるんですけど、
そういうふうに表現で全部統一することでコミュニケーションしやすくなるよみたいな話とか、
結構個人的に学びでした。
脅威ステートメントの重要性
これはでも、なんかやれてるけどね、
やれてるけどなんの話やねんって思うかもしんないけど聞いてる人、
社内でも話しちゃうんだけど、
我々は結構カジュアルに脅威分析っぽいことを常にやっていて、
バーって常に書き起こして、ああでもないこうでもないっていう話をよくしてるんだけど、
割とこの脅威ステートメントのものの考え方自体はできてるなとは思うな。
これ見る限り。
感覚的にはね。
必要な性質ぐらいじゃないかな、多分。
あんまり取り込めてない部分って。
あと記事を見ながらちょっと思ったのは、
自分が仕事でどうかって思ったときに、
意外とやれてなくはないなって気持ちと、
ただこれがスケールさせていきたいってなると、
多分緩めの型みたいなのがあったほうがいいんだなって気はして、
そういうときのリファレンスとしてはめちゃくちゃ良さそうっていうのもちょっと思ったな。
結構ね、でも汎用性の高い型みたいなのを作って型化しようとすると、
なかなか重くなりがちな気もしていて、難しいね。
まあそうね。
なんか結構肌で理解するみたいなのが大事な領域のような気もするから。
なんか超今思いついたというか、
無意識に多分思っていた仮説だけど、
ツールキットとして手段を整理しておくみたいな付け方がいいのかな、こういうものは。
何かっていうと、
なんか開発者としてデザインドックを書くときも似たような感覚があるんだけど、
なんか扱う主題の幅が広かったり、その抽象度がバラバラだったりするから、
デザインドックこう書けばいいですよとか、
なんかこういうツール、こういう作図ツール使えば大体分かりやすくなるみたいなのってないと思ってて、
ないね。
ただ一方でなんか分岐はしてるというか、
分散システムだったらアーキテクチャ図があった方がいいよねとか、
データ中心で考えるんだったらデータフローダイアグラムを書くと分かりやすくなるとか、
そういうこれだったらこのツールがいいみたいなのがあったりするし、
その部分のは多分みんなそんなに脳内で思考してないというか、
このケースはこうだからこれ使おうっていうよりかは裸んで、
これだったらこれ使うと分かりやすくできるなみたいなのを書き始めるっていうことをやってると思うんだけど、
なんか教育分析も割とそういう感じで付き合うのと似てるかもなって今、
そうだね。
何ならだって我々が使ってるのって別にデータフローダイアグラムじゃないもんね、
大体のケースにおいてね。
そうだね。
そもそも。
アーキテクチャ図だったり、
これアタックツリーやると分かりやすくなったみたいな感じで、
裸も掴んで掴めた経験もあったりするから、
確かにね、型というよりかは、
そうだね。
なんか手段なのかな。
我々がやってるのもどっかで障害したいんだけどね、
言語化が難しいよな、なかなか。
年内1個ブログ書きたいから書こうかな、
頑張って書けたら。
スレッドフォレストっていうツールをAWSは作ったよっていう話らしいんだけど、
これは何だろうね。
これね、なんかOSSじゃない気がするんですよね。
なぜかというと調べても出てこないから。
なんだけど、図かな、図。
いや、そうだね。
でもね、実戦編提記事が来週収録に出てるんですよ、神田さんから。
だからそこでディープダイブするのがいいかもしれない。
スレッドコンポーザーっていうのは一応公開されてるけど、
これは多分なんかパーツなのかな、きっと。
一応なんかね、成果物っぽい図はリードミーにキャプチャーがあるから、
こんなんなのかなとか思いながら、
チラッとだけ見たけど、どうなんでしょうって感じですね。
ね。
スレッドコンポーザーね。
はい。
まあそっかですか。
ちょっと来週もお楽しみに、ケーキですね。
記事の要点としてはさっきのこの脅威ステートメントに
起こしていくのが大事だよっていう話なのかな、多分。
そうだね。
すごく大雑把な解釈をすると。
いいですね。
リインベントいいな。
なんかセキュリティ系のセッションもすごい面白そう、普通に。
面白いね。
雷の方毎年言ってる気がする。
毎年って言っても、記事追い始めて2回目か。
去年も言ってた気がする。
面白いね。
なんか各社の脅威モデリングの、
なんかこう、よもやま話を紹介するイベントとかやりたいね。
やりたいね。
ちょっとイベントアイディア入れときましょう。
オフライン、リプレイオフラインイベント。
あの、オープンイベントじゃないけどなんか、
ゲストに呼びたいような人たち集めて飲み会しようぜって話1回した記憶が。
うちのなんかこう、脅威分析はこれですみたいな、なんか。
各社のこう、秘伝の、秘蔵のレシピを紹介していくような。
聞きたいね。
いやー、俺、うちでやってるの結構好きなんだけどな。
なんか、めっちゃ好きなんだよな。
何にも貸し込まってない、なんか。
15分でできるし。
結構好きなんだけどな。
なんか、これが脅威分析なんですかって言われると困っちゃうんだけど、なんか、でも。
でも、悪くない気はしてるな。
なんか、でも、脅威分析そのものだよねって勝手に思ってて。
ちょっと、なんか世の中に知ってもらいたい。
ブログ書きましょう。書きます。宣言して。
お願いします。
はい。じゃあ、次は私か。
はい。
Dynatraceの脆弱性管理
SREかけるDynatrace AI活用による脆弱性対応の効率化。
DNAのインフラSRE部門が書いたDNAエンジニアリングブログですかね。
はい。
さらっと紹介できるわけかなって感じですけど、Dynatraceっていうこれは多分SaaSなんですかね。
SaaSを使ってるよっていう話で。
脆弱性対応は結構、読んでみるとワンノブゼムでなんですけど、結構面白いなと思ったのは、
このDynatraceが何かっていうと、AI系のオブザーバリティープラットフォームですよっていう感じになっていて、
多分各所でいくつかエージェントをインストールしてデータ集めてくれて、脆弱性管理含めていろいろやってくれるっていうサービスっぽい。
で、インストールするエージェントがデータ収集をするエージェントと、収集された膨大なデータをもとに問題の根本原理を特定してくれる。
これはAIエージェントというよりかはAIなのかなっていう感じの2つあります。
収集みたいなのは多分実環境に入れると思うんですよね。
ログとか実際動いてるOSのバージョンとか、アプリの構成とかも多分見るっぽい記事を読んでる感じだと。
そういうものをバーって集めて、解析用のAIが動いてるシステムのCV、パッチがあるかどうかないかみたいなのをバーって分析して、
そのうちパッチの特性とかも見てくれるんですよね。
そのパッチが外部から入力あるとヤバそうみたいなときに、
そのシステムの外部から入力あるかないか、ないんだったらスコアを低くつけるみたいなことを自動でやってくれるソリューションになっているらしいです。
キャプチャーみたいなのが結構思想としては面白いし、それを実現しているサービスがあるんだと思って紹介したんですけど、
ダイナトレスを活用した脆弱性対応プロセスというセクションの見出しのところとかと、
みんな大好きCVSSとかいろんな指標をベースにして、このダイナトレスのAIが判定したDSSという独自のスコアがあって、
このスコアで実環境のいろんなコンテキストを加わせた上で再評価してくれるという感じですね。
4つぐらい指標があって、外部からアクセス経路に存在するかとか、脆弱性を含んだプロセスがデータにアクセス可能かとか、
これもいいですね。脆弱性を含むライブラリがロードされているだけでなく、実際にその脆弱な関数が実行されているかとか、
またエクスプロイトが公開されているかという部分を見て点数付けしてくれるという感じっぽいです。
おもろいね。
そうなんですよ。これ実現できたらめっちゃいいよね。
ある程度多分価値が出てるからブログ書いてると思うんですけど。
これアプローチは全然違うけど、目指してる世界観はWiZとほぼ一緒なのかな。
WiZと一緒っちゃ一緒かな。
対応するべきものだけを対応できるようにするみたいな世界観ではあるよね、きっとね。
そうだね。WiZの方が多分スコープが広いんだろうね。
そうだね。
なんかおもろいな。エージェントレスが割と流行りじゃん、感覚的に。
そうなのか。
わからんけどそんな感じですね。
割とクラシックのやつの方がエージェント形式のやつ多いような気がしてて。
NESASとかさ、NESASのエージェントあるから。
で、WiZはエージェントレスじゃん。
エージェントレスだね。
確かに。
おもしろい。
結構おもしろい。
割と、何だろうな。
全社活動はとりあえずみんな苦しんでるし、やれCVSS、KVSS、ディブディペンデンシーかどうかとかいろいろあるけど、
実環境見て、アクセス経路あるかどうか見てくれるなら結構楽だよなっていうか。
これぐらいでいいよなっていう気は普通にしたんですよね。
ダイナトレスっていくらぐらいするのかな。
そこが気になるよね、結局ね。
でもDNAさん、他にあると思うんで。
すごいな、課金体系が結構複雑。
deserializeの課題
複雑じゃないんだけど、パッと想像つかねえな。
これはパッと計算できないね。
オブザーバリティがメインだと思うから、そもそも多分。
競合としてはデータブックと競合しちゃうのかな、普通に。
アプリケーションセキュリティは安いんだね、他より。
1時間8行ホストタイム。
ホストね、ホストだったな。
GKEとかだとすげえスケールしちゃうから。
高いですよね。
難しいね。
同じ構成だったら1個だけ見るとか、
多分しないといけないんだけど。
できるのかどうかわからないし。
結構多いと思ったんで紹介しました。
今後流行るのかどうなのかって感じですけど。
知らんかった、面白い。
はい。
はい。
じゃあ次は。
ああ。
ライブコンタクトツールにおける機微情報の取扱い。
クラウドDLPを使ったマスキングっていう記事ですね。
俺これなんでピックしたんだっけな。
まず俺たちのゴミ箱さんの記事ですよっていう。
これゴミ箱さんの記事か。
これゴミ箱さんですね。
俺たちのゴミ箱さん。
本当だ。
まずクラウドDLPっていうのがありまして。
という話なんですけど。
ありまして。
画像いけるの知らなかったんだけど。
昔なかった気がするんだけどな。
このクラウドDLPって多分GoogleのDLP自体は仕組みは
多分ワークスペースのDLPとかも同じような感じかなと思うんだけど。
結構フォルスポジティブ多いかなと思うので。
満足に動くところまで仕上げるの大変だっただろうなという風に思って。
考え深い気持ちで見てるんだけど。
このチャットに限らずなんだけど
お問い合わせ本文にいろんなものが入ってくるみたいなのって
私も全職で少なからず微妙に関わってた部分があって
考え深くて実は持ってきてるっていうような感じなんですけど。
記事の中でも
例えばだけど
マイナンバーが前後10文字以内にあることのような
ホットワードを設定できるとか書いてあって
これがまさにそうで
マイナンバーって結構扱いがめんどくさいじゃん。
その辺にポンと置いとけないものなんだけど
勝手に送られてきちゃうみたいなのが
ユーザー数が増えれば増えるほど起こるわけですよ。
割合で言うと大したことなくっても
無視できない件数になってくるみたいなのが普通にあったりして
あとは色んな画像とかもそうだよね。
まさに結構あって
最終的に何が入ってるか分からんものはまとめて
最大級の機密性の区分で扱わなきゃいけない
みたいな状況が生じるわけですよ。
結構そこはしんどいよねっていうのが前提としてあって
多分マスクするよっていうのをやってたと思うんだけどきっと
ようやっとるなっていう、ただそれだけ。
なんか結構印象深かったのは
単純にチャットの
機微な情報自動検知してマスクしましたって話っていうよりかは
どのタイミングでは誰が見えてなきゃいけなくてみたいなのを整理してて
このフローズがもう全てだなと思って
なるほどって思って読んでたんだけど
多分チャットやりとりしてるときはオペレーター見えなきゃいけないよねみたいな話だけど
終了した後はマスクしておいてとか
履歴を読むときは一部復元してみたいなこととかをやってて
結構
綺麗に書いてあるけどここまでたどり着かないと大変だったんだろうなっていう
そうだね、これはちょっと具体例とかがあるんだけど
微妙に私費義務に触れそうな気がするので
やめておきましょう
実際あるんですよね、機微情報をどうしても
オペレーターがやりとりしないといけない、受け取らないといけないっていうのがやっぱりあって
今このチャットがどこまで
使われてるかがわからないから、今言ったような具体例、思い浮かんでるような具体例とかが実際
使われてるかとかわからん、そこでチャットが使われてるかとか
まだわからないんだけど正直、結構大変な感じ
受け取らざるを得ないっていうケースがどうしても出てくるから
その時点でマスクされてちゃいけないっていうのがあるみたいな
でも割と多分要件自体は序盤から整理されてたんじゃないかなきっと
実現とか実装みたいな部分は大変だったかもしれない
大変だったかもしれない、多分
結構しんどい系だと思うわ、開発目線
やりゃいいんだけど気遣うんだろうし
膨らんでいくしね、どんどんコースも
クラウドDLPの取り組み
ゴミ箱さんっていうのを知ってなんかすごい繋がったわ
ゴミ箱さんのデリバリー力の高さというか
なるほどって感じ
お疲れ様でしたという感じでございます
おはようございます
じゃあ次いきますか
WASP Gen AI Security Project Releases Top 10 Risks and Mitigations for Agentic AI Security
というこれ何PRニュースワイヤーっていう見たことないとこの記事なんですか
見たことないね
概要としてはWASPのGen AI、生成AIセキュリティプロジェクトが
WASP Top 10 for Agentic Applicationかな
なんか分からんけど、WASP Top 10の生成AI向けのやつ
生成AIアプリケーション向けのやつを出したよっていう記事
で、ぶっちゃけ特に触れたいことはそんなにないんだけど
中身も読んでないし実は
なんかその2026年に向けたWASP Top 10だよっていう出し方をしてるけど
これなんかそもそも中身見たときに
なんかあんまりトレンドとして移ろうものなのかなどうなのかなって思って
ちょっと雑談したかった
なるほどね
そのIPAのさ、IPAの重大脅威とか
本家のそのWASP Top 10とかはある程度その何ていうか世相を反映するものかなと思っていて
トレンドを踏まえて上がり下がりしました
インアウトがありましたみたいな話がよくあるかなと思うんだけど
これらを眺めたときにその生成AI活用したアプリケーションにおいて
これらがその今後移り変わっていくことがあるのかないのかどうなのか
なんかなさそうっていう気持ちがあるんだけど
どうなったろうね
今気になってWASP Top 10 for LLM Applicationsを見たら
最初に出たから変わってないね
まあその1年でぽんぽん変えないんだろうけど
これが2025でしょって最初に出たら
でもね2024年の11月とかになってる
あ、そうなんだ
いやー言われてみればねあんまぶっちゃけ変わらん気がする
変わんのかな
これが変わるって相当なパラデイムシフトだと思うんだけどね
まあでもそのいやーわかんねえわ
わかんねえって感じ
なんか変わっても驚かないかなって気もする
そのパラデイムシフトかもしれないけど
エージェントAIのあり方というかさ
1年でぼちぼち変わった
LLMのあり方が1年でぼちぼち変わったわけで
その根本はあんま変わらなくても
使い方とか溶け込む場所とかは変わる気はするから
なんか順位の変動はあるかもしれないね
あとさわかんないけどこれ
今日別の記事でたぶん
あれ、今日消化記事入れた気が
まあいいやちょっと後で書きますけど
プロンプトインジェクションとか地味に入ってないんじゃないかな
まあなんか厳密には全部入るんだけど
関節プロンプトインジェクションみたいな
Googleのね
そうそうそうそういうのとかは入ってない気がするから
あったねその記事がね
ブラウザAIが
もうAIブラウザがめっちゃ流行って
それをバカスカ狙われて
その辺が急上昇とか
そういうのはまあなくはないかも
どっちかというとでもプロンプトインジェクションは
なんか手段なんだろうなきっと
いやーちょっと難しいな
このWASPトップ10のフォーマットにした時に
なんかプロンプトインジェクションはどっちかというと
手段としてまんべんなくマッピングされていそうな気がするな
難しいね
結果でもあり手段でもありみたいなものが
結構ありそうな気がするが
まあそういうのもあってたぶん入れにくいんじゃないきっと
わからんけど
なんかプロンプトインジェクションっていう表現というよりかは
入り口の部分なんだろうな表現するとしたら
でも例えばだけどこのメモリとコンテキストの汚染みたいなやつ
その結果としてプロンプトに変なものが入るみたいな形で関わってきたりするし
予期せぬコード実行みたいなものは
これにつながるプロンプトインジェクションがあるよねみたいな話とかだと思うし
なんかそのアプリケーションのそのなんか全体で見た時に
なんかプロンプトインジェクションっていうのが難しいな
なんかここに入れるべきかというとちょっと難しい気がするね
並びだけ見るとね
どういう議論がされてたかとかはわからんけど
これむずいななんか使い方むずいな普通に
うーん
そうだからなんかぶっちゃけさ
トレンドを知る以外のなんかその使い方がないような気がしていて
これ系のやつって
ってなった時にトレンドとしてこれ移ろうのかって
なんかどうなんだ
確かに
誰のために何なんだろうなってちょっと思った
まあ今後アーカイブされるのか更新されるのかに着注目って感じかもね
確かに言われてみて確かにと思った
うーん
これでWASPトップ10の方にさ
なんかエージェントに対するプロンプトインジェクションみたいなのが
もう入ってたりするのかな
まだ入ってないよね多分ね
うーん入ってないと思うな
うーん
コンセプトプロンプトインジェクションの話は
収録で読まない
読まないというかピックしてなかったから
うんリンクだけ貼っておきます
ああそうだね入ってないね
WASPトップ10の方に入ってないから
そのうちなんか本家のWASPトップ10の方になんか
エージェントに対するプロンプトインジェクションみたいなのが
入ってきたりしたらなんかごちゃごちゃになるなと思うし
そうだね
うーんちょっと個人的にはその
なんか今の時点でのそのスナップショットとしてのまとめ
としてのなんかその
良し悪しみたいなのはまああるかもしれないけど
なんかなんとかトップ10みたいな感じで出す意義を
個人的にあんまり感じられませんでしたよという
エージェントAIの安全性
記事でございます
ありがとうございます
まあなんかエージェント何が危ないのっていうのは
わかんない人はまあ1回読むぐらいはいいかもね
その項目としてはまあこんなもんだよねって思って
その紹介にピックしなかったから
なんかまあまあその変なリストではないとか思うけど
まあ変わるかと言われると今のとこはわからんって感じだよね
うんはいありがとうございます
あーこれこれかなんかちょっと自分で読むのもピックするのも忘れてた
あらえっとじゃあ次の記事ですけど
ランサムエアの攻撃の影響を調査結果
および安全性強化に向けた取り組みにご報告
ランサムエア攻撃によるシステム障害関連第13法
アスクル株式会社さんのPRプレスリリースですね
はい皆さんご存知かと思いますけど
今年の10月にランサムエア攻撃の被害にあって
それから依然として復旧作業してるところですけど
それの障害法の13法っていうところですね
で僕もちょっとめちゃくちゃ精度化できてないんですけど
まあまあその原因みたいな部分が明らかになってきてるなっていう部分で
読むと良さそうって感じですね
で結構うーん
まあちょっと全部読むと大変なんですけど
ランサムエア攻撃の影響
個人的に印象に残った部分だけ話すと
原因ですね入り口
ランサムエア攻撃の足掛かりになった部分の入り口が
業務委託先用のアカウントに侵入されたっていう部分が
入り口になってるっぽい
具体の言及で言うと
どこだ
流出が影響入ってる
これか初期侵入は
図に書いてあるのか
攻撃処分の詳細分析って言うと図に書いてあるんですけど
社外寄りする侵入って言うんで
個人的には結構
まあなんか稀によくある系というか
割と侵入経路としては鉄板だよなっていう部分で
頭が痛いなっていう
印象深いなっていうのと
直近なんか直近じゃないかな
貫通だっけな
今年とか去年起きた日本のランサムエア事件
大体もう同じなんですけど
真の原因というか
何が本当に起きてたかは
ログ消されちゃったら分かりませんみたいな部分の
言及も確かどっかであって
ログ
一部の通信ログアクセスログが失われていたことから
攻撃者が閲覧した可能性のある情報の範囲を完全に特定することは困難であると判断しておりますみたいな言及があって
ログ結構消されるなというか
ログちゃんと残ってて原因特定できました
全部明らかにできましたっていうの
僕はあんま見たことないんで
特権取られてたらもうそれ消すよねとしか言いようがないから
まあまあまあそりゃそうだねとしか
言いようがないんだけど
バックアップと一緒でさ今回バックアップファイルも削除されてたっぽいんだけど
理想論やるのは
めちゃくちゃ難しいと分かってながら言うけど
バックアップファイルと同様にログも
メインシステムが乗っ取られても
そっちは手を出せないような場所に置いておければ
いいよねって話はある気がしてて
壊れたらシステムに影響が出るデータをバックアップするみたいな部分は
多分ファーストオプションとしてみんな意識すると思うんだけど
ログもこういうの見ると結構強めに意識しないと
何気なく取ってるだけのログだけのバックアップはないみたいなものが
失われてみたいなのが全然あり得るなっていうのが結構身が引き締まる思いだな
まあね ログのバックアップって確かにちょっと
意識から外れがちな気がするね
なんかアーカイブはみんな多分してると思う 生存期間決めてとかあると思うけど
それがなんかどういう権限まで行かれたら
まるっと消されちゃうのかみたいな部分は
結構ちゃんと意識的に思いはせないと意外と抜けやすい気がする
あと気になったのは初期侵入が6月5日で
ランサムエリアの起動までが
起動が10月19日からか
まだ4ヶ月ぐらいあるんだよね その期間
そうだね
7月9日にEDRを無効化
7月9日からEDRを無効化された上で
なんかランサムエリアを配置しまくってたっぽくって
で10月19日に一気に暗号化されるみたいな
シナリオだったのかなきっと
これ嫌だね
嫌だね
いやまあ結構高度だよね攻撃としては
EDR無効化ってさらっと書いてるけど
どうやってやったんだろうね
全然詳しくないからなんともだけど
EDR回避の多分ツールキットとかいくつか
ニュースでは見てるけどそれが現実的にどうなんかとか
あとその例えばEDRの管理画面に入っちゃって
無効化するっていうやり口もあるはずで
その辺はちょっとわかんないな
そうだね
あとこれエンドポイントの話なのか
まあでもサーバーの話なのかな
内容の文明的な
複数のサーバー間を移動しみたいなこと言ってるから
いやだね
そうだね
まあでも再発防止策のとこ見ると
侵害を発生したデータセンターではサーバーにEDRが未導入であり
24時間回避も行われていなかったためみたいなこと書いてるから
これが再発防止になるのかはちょっとわからんけど
動いてるシステムにはこれ系全部入れましょうわ結構
スタートラインみたいなとこあるのかな
全部わからんけど
クラウドストライクとかってサーバーにも行けんの
わかんないな
あんまイメージないんだけど
クラウドストライク
各拠点の
いけそうな
Amazon Linuxをサポートしてますみたいなの書いてあるから
いけそうだね
クラウドのインスタンスも行ってみると
まあまあそうだよね
ちょっと腰重いよね
オンプレでサーバー何個もあって
全部漏れなくEDR導入してその運用もしなきゃいけないわけじゃん
結構大変だよね普通に
運用はでも外注してたんじゃないの
違ったっけ
そこまで読み込めてないな
監視
どこに書いてあるんだろう
わからんね
これちゃんと読みたいな
過去の12本も含めて
まあでも腰は重いけど
オンプレで
長いライフサイクルで
動いてるサーバーがあるんだったら
入れようよっていう話は自分だったらするかな
Kubernetesの環境で全部入れようぜみたいな話は
できないなと思うんだけど
前提が違うからね
ECS超使ってまーすみたいな
GCEめっちゃ使ってまーすみたいな
環境だったら
ちょっと違うかなと思うし
それ言うと実際はGCEだからな
そうなんだよね
でもコントロールできるレイヤーがちょっと違うし
動いてるもののライフサイクルが全然違うじゃん
確かにね
それは言えない理由になるのかっていうと
必ずしもならないし
入れられるんだったら入れればと思うんだけど
どっちかっていうと前段のアクセスの方を締めれば
割と綺麗に収まるような
気がしている
リターンのでかいレバーがちょっと違うよね
従来のサーバーとか
それはそうだね
引き続き応援しておりますって感じだな
頑張ってください
着々と頑張って2ヶ月ですか2ヶ月でここまで特定して
頑張ってますね
中で働かれてる方は
睡眠時間を確保して3食食べれてることを
EDRの無効化と攻撃手法
切に祈っておりますわ
はい
睡眠大事ですからね
じゃあ次いきますか
サクッとケースね
脆弱性診断の取り組み
ストアーズプロダクトブログの記事でございます
ほんとさらっとでいいかなと思うんだけど
ストアーズのセキュリティ本部の方の記事で
内製でセキュリティ脆弱性診断やってるよっていう話
やってる取り組みの一部を紹介しますよっていう趣旨で
こんな感じで
やってるんですけど
内製して実際こういうことやってるよっていう記事
外に出てくる情報って意外と少ないような気がしていて
ちょっと印象的だったので
持ってきました
一通り全部見てるよみたいな話なんだよね
きっと
一通り全部見てるよみたいな話なんだよね
一通り全部見てるよみたいな話なんだよね
一通り全部見てるよみたいな話なんだよね
その診断計画の策定とか見てるとさ
大小数のこの数が何なのかわからんけど
2000以上あるため年初に年間計画を策定して
各サービスの診断時期を決めてますっていう風に書いてあって
1年中張りついてやってるのかなこれ
よくわからんけど
でも年次診断って書いてあるから1年に1回やってるんじゃない?
1年に1回やってるのかな
1年に1回やってるのかな
診断って書いてあるから1年に1回やってるんじゃない?
診断時期をさ年間計画を策定して
診断時期を決めてますって書いてあるから
だからじゅんぐりにやってってるはずなんだよね
そういうことか確かに確かに
STARSってどれぐらいなんだ今
会社規模っていうか
コンプレートされると
そんなに大きくない気が勝手にしてるけど
勝手に僕もそんな気がしてる
社員数書いてないなカルチャーデックとか
これかスピーカーデック
社員数にたどり着けない
プロダクトの話が
結構厚めだね手厚めだね
来たね
社員数出してないパティーな気がするな
346名か
エンジニア30%だから
100人ぐらい
結構多いね
どこまでこれでやれてんのかとか
それで足りてんのかとかちょっと分かんないけど
内省してんのすごいなっていう
好み感
もしこの声が
ご本人内省はSTARSに届くなら
これに対しての成果というか
そういう部分も聞けるとめっちゃ嬉しいですね
すごいわがままに聞けるんですけど
診断回せてるのは素直にすごいなという印象で
一方で
リスクを抑えたいというか
見つけて対応したいというのが
目的としてあるはずだから
そこに対しての成果とか診断書を出してから
チームはどういうふうに対応してくれてて
そうだよね
これを取り巻くエコシステムというか
全体像をもうちょっと知りたいよね
診断の対象の選定の部分とか
業務時間の何割ぐらい
これに割いてるのかとか
何人体制でやってますとか
気になる
気になるよね
あとはこの観点とかも
ここではXSSを例として挙げてるけど
バープスイートポンって渡して
じゃあこれで随着性探してって言われて
できます?
できないっす
全然できない
もともと診断やってた人がいて
その人がやってるからバープスイートだけ渡すときは
あと大丈夫なんだよって話なのか
ある程度誰でもできるように
手順化したりとか
観点リスト作ったりとか
してるんですよみたいな話とか
そういうのもあれば知りたいなって思うし
確かにね
ありがとうございます
こんな感じですか
続報勝手にお待ちしております
続編
ありがとうございます
じゃあ次
脆弱性診断の取り組み
AI検索の回答に偽情報を仕込んでユーザーを騙す
詐欺の手口が登場
これもさらっと系かな
LLMが見てるソースの方の電話番号を汚染した
シナリオがあるよみたいな話かな
手口が登場したよって話で
エージェントとか
LLMモデルベースのシステム
っていうふうに基準の中で呼ばれてるのかな
そいつらが
誤った電話番号を
要は偽装された別の偽の電話番号を
公式の信頼できるお問い合わせ先として
紹介しちゃうみたいな
手口が出てきたようという話ですね
ただそれだけなんだけど
地味に刺さるなと思っていて
そう来るかっていう気持ちで
読んでたんだけど
これどうなんだろうな
今年の多分2月ぐらいから
同じ構造の攻撃はずっと
話題としては
要するに学習データとか
参照データに偽物混ぜ込むって話だと思うんだけど
理屈はそうなんだけど
実際どんぐらい刺さってるのか
個人的には気になっていて
どうなんでしょうねっていう気がする
これ攻撃者の溝知るって感じなのかな
なんか結構心理的には
引っかかりやすいよなって思ってて
全然違う番号が出てきて
かけたら
普通にそれっぽい横帯が始まるみたいなのって
結構引っかかりそうじゃない
引っかかりそうだけど
どんぐらい踏み抜いてる人がどんぐらい
AIと偽情報の問題
いるのかなっていう気は
観測の仕様がないな
キャンペーンがやってて
成功してるかどうかはまだ分かんないって感じかな
これさ
いつも評価むずいのが
セキュリティベンダーの近況は正しいんだけど
エンドユーザーも同じ目に合ってますかっていう問いには答えられないじゃん
再現性ないからね
結構むずいよな
AIブラウザーが結構一個ファクターというか
重要な
今年の年始めとの差分にはなりそうな気はするから
ポイズニングの例は
チャットベースでパブリックシティにエミュレーツ公式サポート
エミュレーツ航空の公式予約番号を問い合わせると
捏造したものが返ってきたよ
なんかでも結構
使い方の問題のような気はするけどな
100個目のゾロ目が何なのかでも回答はれちゃうぐらい
むずいな
これあとさ
AIが挟まることによってどのくらい差分になってんだろうね
自分で調べて
ググってニセサイトが出てきて
そこに騙されている
SEOの方で汚染されているというパターンもあるし
割とそれが通っているからこそこっちが汚染できている
というのもあると思うから
それはワンチャンあるかもしれないけど
分からないね
どうなんだろうね
AIに嘘をつかせる難易度だよな
物量で押しちゃえば騙しちゃうのか
ブラックボックスだね
電話番号は汚染しやすいとか
何々は汚染しやすいみたいな傾向とかが
もしあるんだったらこれは気をつけないとね
そういう学びにつながるかなと思うんだけど
どうなんだろうね
これ
でもやっぱあれだね
GAOスパムに
裏刈りやってるな多分
栄養線に近しいことなんだろうな
結局ソースのスコアリングみたいなところで
勝手に減っていくのかな
そうかもね
それはそうかも
そっちで改善してくれよみたいなのが
一つあるかもね普通に
GAO最適化という言葉が出てきてる
生成エンジン最適化
ふーんって感じだね
AIが解釈しやすい
偽情報って話だろうね
信頼度高いドメインとか
複数回繰り返す
物量で押してとかはあるだろうね
学習のアーキテクチャはよくわかんないんだよな
物量で
この偽情報も結局生成AIに
アホみたいに作らせてやってるから
だろうから
この辺いたちごっこになるかもね
YouTubeのキャプチャーおもろすぎるな
これひどいね
いやーやってんなー
これぜひみんな見てほしいな
ひどいわ
これ難しいのがコンテンツ単体では
悪質性というか悪意の有無を
判定するのむずくねこれ
むずいね
この偽の電話番号みたいなのは
過労死で悪意があるよね
みたいな判断できるかもしれないけど
物によっては
純粋に勘違いかもしれない
みたいなものも普通にありそうだし
ユーザーの行動はさ
どうなってくるんだろうね
結構個人的には気になってて
いやーでも関連か
誰かさんの名言なのかわかんないですけど
嘘嘘と見抜けない人に
ウェーブ使うのは難しいみたいな話があるけど
AIも嘘つくじゃんっていうのは
僕らは結構当たり前に知ってるけど
一般ユーザーはそう思って使ってるのか
丸っきり信じて使ってるのか
今時点でどうかって話もあるし
今後どういう風に向き合うことになるのか
みたいな部分はちょっと気になるなというか
みんなどう思ってるんだろうね
信じてる人のほうが
今ちょっと話しながら思ったけど
信じてる人のほうが実は多いんだろうな
結構
もしくは
でも言うて嘘つくから
嘘つくよねって前提でみんな使う
偽サイトを見抜く必要はなくなったのかもしれないけど
よくわからん回答を
見抜く力みたいなのが必要なのかな
もしかしたらこういうの含め
ハルシネーションでさえ
ハルシネーションとはまた別軸のものだけど
微妙な深刻なディスク
なんか忘れたけど
いつ頃か忘れたけど今年のどこかで
これほど直接的じゃないけど
思想の偏った
本物っぽいメディアサイトを立ち上げて
毎日数千件の記事投稿して
それをクロールしに来る
AIモデルの思考をねじ曲げようとする
みたいなキャンペーンとかも見た気がしますね
ロシア支持系とか
その辺だったと思うんだけど
このアプローチは多分
当分はされるしどこまでいくかって感じ
これ元ソース読めばよかったな
元ソース読んだら結構おもろいな
あとあれね
なるほどなって思ったし
収録でも一回紹介したけど
放置されたワードプレスサイトを大量に手元に持っていて
こういうキャンペーンに使うみたいな
のとかは結構恥ずかしいなって思った
そういうことされちゃうと多分SEOランク
スコア付けがちょっと難しくなってしまうというか
生存期間長くてちゃんとしたものを
ホスティングしてたサイトがある日突然
ダメなデータをめっちゃホスティングするみたいな
これも多分この悪用された
貢献サイトみたいなんでWPコンテンツっていうのが
目に入ったから思い出したんだけど
そういうところは
SEOポイズニングとちょっと似てるっちゃ似てるかもね
この記事を送り付けられた
各生成会社は
勘弁してくれよって思ってるだろうな
でも対応しないわけにもいかないのかもしれない
はい
SEOポイズニングの影響
ありがとうございます
という記事でございました
次ラスト
そうですね本日ラスト
たどり着きましたね最後まで
これもサラッド系ですね
Graphs for Goっていう
GitHubの
チェンジログかな
中身
記事の本筋は
Goって
動的に依存関係を決定していくから
依存関係のグラフ化が
結構だるいよって話で
もっといじった時に
あれこれするようになったよみたいな記事なんだけど
Goの話は割とどうでもよくて
依存関係の管理API
Dependency Submission APIっていうのがあるのね
ただそれだけ知ってたのこれ
知らないこれ何これ
依存関係
違和感しかないんだけど
過労死で読める日本語ではあるんだけど
依存関係にはロックファイルしか
なるほどですね
ロックファイルとかで自動で
検出される依存以外の依存も
自分で追加できると
何に使うんだ
何に使うのかわからないけど
面白いなと思って
何に使うのかなっていうのはまさに
その通りなんだけど
何かに使えないかなっていうのと
何に使うのかなっていうのと
何か知ってるかなっていう
どのタイミング使うんだろうな
このGoをビルドしたものの
あれかな
SBoom絡みで使えるような感じなのかな
よくわからないんだよね
GoModPathで
パッとわかんないな
SBoomの話も出てるね
SBoomはGitHubにメタデータとして
登録されるわけではないから
GitHub上にも同じものを表示してあげたい
みたいな感じなのかなもしかしたら
知らなかったですこれは
これやると
どうなんだろうね
わからんな
Dependabotとかはここ参照しに行くんじゃない
そんな気はするね
でもDependabotはサポートしてる
あれはロックファイルとか見て動くだけだから
サポートしてるものが
種類あるでしょ
ちょっとGPTに聞いてみてるけど
Dependabotアラートは見てるよって言っとるな
見ても何もできなくない
でもDependabotアラート出てくんじゃない
このリポジトリではこのプロダクトの
このバージョンを使ってますっていうのを
Dependency Submission APIに送っておくと
このリポジトリではこのプロダクトの
このバージョンを使ってるからそれに対する脆弱性が出たら
このリポジトリのDependabotアラートが出るみたいな
確かにデータベースと称号を一致すれば
いけるのかな
分かんないけどめっちゃ例えば
Goの中で実はSSHコマンドのこのバージョン叩きたいみたいなのがあって
それを
Dependency Graphが対応してなそうなやつで言うと
だいぶ前に紹介した鈴木すんすけさんが作った
Aquaってやつがあるとあったんですけど
ああいうのをトルシックしておくと
自動修正にしてるSSHのバージョンに脆弱性があったら
Dependabotアラートが上がって便利みたいなのがあるかもね
でも自動修正は多分できないからアラートとして上がるだけ
そうそうアラート上がるだけ
でも確かにそれはユースケースとしてはありそうだな
ちょっとパッと出てこねえけど
なんかありそうな気はするが
何で何か仕事してる中で
何でこれDependabotアラート上がってこないんだろうね
みたいな話をしたようなしてないような記憶が
若干あるんだけど
なんかあったよな
何で上がってくるんだろうねはよくあるんだけど
何で上がってこないんだろうね1回くらいあったような気がするんだよな
本当
なかったっけ気のせいかな気のせいかもしれない
Dependabotアラートはなかった気がするな僕の記憶ではね
僕はいないとこで話したかもしれないけど
なんか上がってくるようにできるとかはあんのかもね
もしかしたらわからんけどね
チャットGPTの言ってることだから微妙に信用ならんけど
でも仕組みとしては結構納得感のあるというか
なるほどおもろいっすね
知らなかった
今言ったけどAquaとかは多分
これする仕組み作っとけば楽だろうな
はいありがとうございます
あとは
なんかあるかな
Kubernetesの
まあいいや
サポートされてないフォーマットって結構あるような気がしていて
でもこの中にバージョンあるんだよねみたいなのって
意外となかねえような気がしてきたな
なかねえような気はするけど
Dependabotで統一したいかみたいな部分
なんか結構ちゃんと乗っかれてるところとかはいいのかもね
アドバイザーセキュリティに課金してて
とりあえずがっつりそこの
有料機能に依存しててとかだったら
寄せたいみたいなのがあるかもね
はい
そんな感じでございます
ありがとうございます
いっぱい読んだなあ
1時間40分2時間近く
最近軽く聞けてたなあって人が
なんか急に今日
ふと割れに聞いてる途中
あれまだ終わってねえみたいになる回かもしれない
かもしれない間違いない
いやあ来週まあ来週は今んとこそんななんだよな
今週ほど量
今日読んだ分ほど量はなかった気がするけど
まああれですか
アドベントカレンダーも
過剰ですか皆さん
そうだねだいぶ
もう今の時点でなんかあんまできてないようだと結構
結構きついかもね
デシリアライズの悩み
知らんけど
いやあ喉直そう後は
はい直してください
はちみつ飴今机の上に
一袋開けてるんでガブなめして
ガブなめして寝ます
じゃあそんな感じですか
そんな感じですね
言い残したことない大丈夫
うっすはい
皆さん来週もお楽しみにしててください
おやすみなさい
