ゴールデンウィークの終わり
こんばんは、Replay.fm第34回です。
こんばんは。
こんばんは。
こんにちは。
ゴールデンウィーク。
こんにちは。
おはようございます。
おはようございます。
おはようございまーす。
おやすみなさーい。
ゴールデンウィーク、ゴールデンウィークでしたね。
でしたね。
でしたね。
もう、あと2時間でゴールデンウィークは終わり。
いやー、俺の連休が死んでいく。
超、4連休どころかの。
あと何、24連休ぐらい。
もう、もうねーなって気持ちになってるよ、すでに。
なんか、ちょっと悲しい気持ちになってる。
平日にやりたいこと
もういくつ寝たら社会人ですかね。
いやー、俺の夏休み。
俺の夏休み。
なんか、その、ほん、いやー、そうね。
なんか、平日に行っとかないと、みたいなタスクとかはもう消化できてるの?
ないね、それで言うと、別に。
別にないんだよなー。
万博とかは、万博とかは絶対平日行ったほうがいい。
いやー、まじ、ねー。
あんま興味ないなー。
あー、そうなんだ。
うーん。
なるほどね。
あんま興味ないなー。
まあ、まあ、有給取ればいいしなー。
そうねー、平日、平日やっときたいタスクかー。
別に、それで言うとね、年中あるっちゃあるんだよな。
そのー、サーキット行くのに、なんか平日なんかついてるから。
そのー。
そうでしたね。
で、あと、キャンプ行こうと思ってたんだけど。
あー、キャンプいいじゃん。
行かず姉妹になりそうな雰囲気があるなー。
なるほどね。
ワンチャンどっかで、いやー。
うーん。
どうしよっかな。
うーん。
キャンプは平日のほうがいいよねー。
そうなんだよね。
暑くなる前のほうがいいよねー。
そうそうそう。
ちょうどいい時期だから、どっか一泊ぐらい行こうかなーと思ってたんだけど。
うーん。
ワンチャンどっか行けるな、ちょっと考えよう、ちゃんと。
うーん。
検討してください、時は限られてる。
なんかでも結構一人でねー、キャンプ行っても最近、あんま面白くないんだよなー。
あ、そうなんだ。
うーん。
飽きた?一人は。
いや、なんか、うーん、別に飽きるとかはないんだけど、
うーん。
なんか、いっかなっていう。
なんか、そのー。
なるほどね。
なんか、こう、うーん、別に他でも、なんか、満たせるなっていう。
うーん。
まあ、その感じならわざわざ無理に、確かにね、行かずと、っていう。
記事の読書と広告の影響
なるほど。
じゃあ、頑張って平日にいっぱい記事を読んでください。
いや、ほんとそれなんだよね。
逆に、さっきも話したけど、その、逆に時間ありすぎて読まないっていう。
うふふふ。
そう。
いや、全然起きる。
隙間の時間にパーって読むみたいなのが全くないから、
結構意思を持って読みに行かないと、読めなくて。
そうだね。
うーん。
なかなか、ちっぽけ、ちっぽけから離れて記事を読みに行くというのが非常に難しい日常。
なんか、広告減ったらしいじゃん。
あ、そうなんだ。
その、広告見てる間に読めばいいんじゃない?
いや、もうね、広告出ない課金はしちゃったからね。
あー、そう。
課金しちゃった。
うん、まあ、あきるまでは。
広告多すぎて、なんか、苦情を受けて減らしたみたいなニュースを見て。
いや、あきるまではちょっと、まあ、いっか。
必要経費だなって思う。
なるほどね。
諦めて、そこは課金しちゃった。
まあ、やっていこう。
うん。
じゃあ、ぬるっと読みますか。
はい、お願いします。
じゃあ、ほい。
あ、まあでも俺、後半全然読んでないから、序盤読もうかな。
うん、じゃあお願いします。
名字またはハンドルネームを宛名に記載。
不審メール判別を容易に。
密い隅ともカードの試み。
っていう、スキャンネットセキュリティの記事ですね。
また短い記事やな、なんか。
すごいな。
そうだね、うん。
スキャンネットセキュリティ大体こんな感じ。
なんか、メールに記載している顧客の宛名をカード名称から名字に変更し、不審メールとの見分けが付くように改善しましたよという記事ですね。
うん。
本当に?
あとは一応ハンドルネームを設定してる場合はハンドルネーム。
ああ、そうね、うん。
うん。
イエスエンジニティ刑、ハンドルネーム、名字。
うんうんうん。
まあ多分不審メールって書いてあるけど、多分フィッシングだよね。
多分ね。
うん。
いつから?
いつからだろう?
でも確かにそうだね。
5月2日に届いてるメールは名前が載ってない。
それ以降まだ来てないから、私は確認できてない。
4月21日のあれだね。
確かに俺もいついつもだから見てみよう。
いついつも。
4月22日のメールがあるな。
うん。
ああ、でも4月22日のメールはまだなんかカード名だね。
うん。
何たら何たらカード会員様。
あれなんか。
うん。
知らないけど、今見たらなんかに当選してたわ。
やったな。
おめでとうございます。
ありがとうございます。
まあそれはいいんだけど、ちょっと待ってもうちょっと新しいメールないかな。
5月5日のメールはある。
5月5日のメールならワンチャンあるかもね。
5月5日まだあれだな、カード会員様って書いてある。
大体でもこれ4月21日にって書いてあるのか、この記事上は。
しかもなんなら、あれ?
いつの記事?
2024年10月以降順次、弊社からのメールの後ろには苗字が表示されます。
じゃあ順次なんだ、まだ来てない。
だいぶ遅くない?でも。
100%開放までどんだけ時間かけてんの。
しかもこの10月以降っていうのを、今年の4月に発表してるね。
だから6ヶ月差で発表してるって感じかな。
これさ、なんかABテストみたいなのやってんのかな。
そうね、なんかなんだろうね。
でもさ、このABテストって普通にちょっとイービルじゃない?
というのは。
だって苗字またハンドルネームでアテナを書いてメールを送ってる人たちと、そうでない人たちで、
例えばフィッシングに引っかかってる確率に差分があるかとか見てるわけでしょ?
もしやってるとしたら。
もしやってると、そうだね。
完全にイービルだよね。
それはイービルだね、確かに。
わかんないけど、確かに仮説検証は必要なプロセスかもしんなくて、
ただ、別にそこにさ、やらないほうが多分コスト的には低く進むじゃん。
差分があるはずですと。
要はさ、仮に差分があったとしたら結構イービルだよね。
そうだね、確かに。
なんかさすがにでも、どうなんだろうね。
わかんないけど、偏見だけど、時間かかってたり、システム的にめちゃくちゃで大変とか。
でも半年以上かかってるよね。
まあ、なんかあんま何も言いたくないけど、半年経ってもできないこともあるよねっていう。
なんかメールのテンプレがなんか3億ぐらいあるのかな。
いや、なんかメールシステムがバラバラとか全然あるよね。
その、内部的にこのメール送ってるのはこのメールシステムで、このメールシステムはこのベンダーが担当してるとかなんか全然あるんじゃねえかなっていう。
その、密にせめてもぐらい大きい会社になると。
なんか全部内製ってことは考えづらいからっていう、わかんない。
別にカバーわけじゃないけど。
だからそういう意味では、まあこのスピード感は、だからどっちか判断しづらいね。
AVテストの可能性も全然あると思う。
あーでも、どっちかっていうとなんかいろいろ事情があって難しいっていう感じなのかもしれんな。
4月の23のメールで苗字になってるやつが1個あったわ。
あーほんと?
うん。
あーじゃあマゼコゼというか。
いや、ガチマゼコゼだね、なんか。
うーん。
結構脈絡なくなんか、クレジット会議員様になってるやつとヤギ足様になってるやつがある。
あーほんと。
うん。
じゃあ確かに。
だから順次っていうのもあれかもね、そのメールの種別ごとに頑張って今。
うん、たぶんそういう感じなのかもしれんな。
うん。
あー。
3Dセキュアのやつとかはどうなんだろうか。
3Dセキュアの。
あーもうメールアーカイブしすぎて見つけらんないな。
3Dセキュアはあれだな、私たぶん消えちゃってるなほとんど。
消してんの?
いや、なんだっけ、iOSが消しちゃうからさ。
へー、消しちゃうんだ。
うん。
消すっていうのはどういうこと?
えーと。
あー、でも。
えーと、これ、これ。
あのー、あれに貼るわ。
えーと、納書に貼りますね。
納書。
うん。
あー、なるほどね。
うん。
あー、自動入力のやつか。
そうそうそう。
はいはい、あー便利だね。
そう。
えー、削除するんだね、アーカイブとか。
そうなんだよー。
いや、わかんない。
あの、どっかゴミ箱とかに入ってるのかもしれんけど。
うん。
見たことがないなー。
ちょっとゴミ箱ねー、もう。
うーん。
なんか、あのー、アンサブスクライブするのがめんどくさすぎるやつを全部ゴミ箱に突っ込むようにしてるから。
自動で。
うん。
わかるよね。
ゴミ箱がすごいことになってて、もう見つけらんないわ。
へへへ。
なるほど。
うん。
でも今、手元で見つけたけど、なんも書いてない。
宛名自体がもう書いてない。
うん。
なんかもっと機械的ななんか中身だったよね、確かに。
うん。
うん。
なるほどね。
いやー、これどうなんでしょうね、なんか。
いやーでも、農士に書いてくれてる書簡に完全合意だなー。
うーん。
効くかどうかどうなんでしょうっていうのと。
言うほど効くかなーっていうのはあるのと、なんか、たとえば佐藤様とかにしたらさ、そこそこの件数ヒットするわけでしょ。
そうだね、そうだね。
確かに。
これが書いてあるから安心とはならんよなー。
うーん。
だからこの、公式の昨日リリースのやつに、なんか、密一寸とも名乗るメールが来たらまず宛名を確認するようにしましょう。確実に見分けることができますって書いてある。
本当かよっていう。
ちょっと言い過ぎだよね。
うーん、言い過ぎかなー。
親しみやすいハンドルネームを設定することで弊社のメールを確実に見分ける。
まあねー、なんか。
これでもさー。
容易に漏れうるよね、なんか普通に。
漏れうるし、なんかツイッターのIDと一緒にしようとなんかなったら、ね、取れる情報、取り得る情報とか。
なんか何にしたらいいの、UUIDV4とかでなんかやられるのかな。
逆に怪しいな。めちゃくちゃ面白いね、確かに。
だってなんかソーターとかさ、ユーとかやってみたらさ、なんか。
めっちゃおもろい。
よくいる名前とかさ、なんかそういうのでワッとひらがなでさ、投げまくったら、それだけでやっぱそこそこの件数当たるだろうし。
そうだね。
まあまあまあ、でもその、なんて言ったらいいんだろうな。
論理的には確かに、ちょっと難易度が上がるよねっていうのは、まあ推測し、推測しうるというかその、推定できる結果ではあって。
理屈上別におかしくないんだけど、なんか他にやることないのかなってちょっと思っちゃうんだけど。
うーん、そうねー。
マイクロソフトのパスキー認証
VPassはまだ確かパスキーは使えないんだよな。
うーん。
てかさ、結構さあんまなんかやってるとこないんだけど、その自分のとこのサービスで送ったメールの一覧をさ、そのアプリとかから表示できるようにさ、してるところが全然ないんだよね。
VPassはどうなんだろうね。
言われてみれば、なんていうか、その機能の存在さえ知らんな。なんか見たことない。
うーん。
自分が知らないだけで。
パッとなんか、ここにあるんだよっていうのを今出せないんだけど、1個か2個ぐらいどっかで見かけたことあるんだよな。
で、要はさ、ここに載ってなければ偽物ですって。
そうだね。
いやー、でもむずいな。なんか費用対効果で考えると、なんかそこまでちゃんと見るようなやつは引っかかんないし、引っかかる人は見ないでしょっていう理論はあるじゃん。
うーん。
まあなんか責任協会的になんていうか。
でもなんかハンドルネームをさ、設定してもらってみたいなのよりなんか全然。
まあ。
やり方としてはまっとうだと思ってるんだよな。
うん。
なんかね、なかなか意味がないとは言わないがっていう、ちょっとどうなんでしょうねっていう。
まあ結構打つ手がない感じなんだろうね。
そうだね、これできることはもうちょっとでもしてかないとなかなか。
まあガンガン狙われてるしな、規模もでかいし。
まあオーってなったのでピックしてみたって感じですね。
はい。
うん。
はいじゃあ次、くしくもちょっと見てあとピックいきます。
はい、えーと、マイクロソフト、マイクロソフトセーツプラスキーイズデフォートフォーニュアカウント、15ビリオンユーザースキャインプラスアドレスサポートっていう、パッカーニュースの文字ですね。
はい。
えーと、これちょっとほぼタイトルしか、なんかノーションAIが作ったサマリーしか読んでないんだけど。
まあほぼタイトル通りなわけだよね。
うん、タイトル通りです。新規アカウントに限ってパスキー認証デフォート。
うん。
多分サマリーに書いたとこが要点かな。
うん。
今言った1個目と、あとはそのパスワード認証をもう削除できるようになった。
うんうん。
既存のアカウント。
あーなるほどね。
うん。
そう。一応なんか記事には細かい、こうしたことでパスキーの割合が増えた云々とか、あと細かいケースだとその2FA、パスワード2FAのケースで、結構タイミングによってパスキーに誘導するパターンとかもあるみたいで。
うん。
基本的にはパスキーに寄せていくっていう。
うん。
割と強いし。
まあやっぱこうなるよね。その。
そうだね。
こうなるのがさ、やっぱ目に見えてるわけで、なんか。
うん。
うーん。
それこそさっきの話しちゃうんやけどその、マイクロソフトもう死ぬほど狙われてもう。
そうだね。
どう足掻いてもどん、なんかあの手この手で被害が出てるわけだから。
うん。
まあエイヤーでちゃんと投資して、ガッと。
うん。
これはだからどちらかというとさっき言ったようなその、真っ当なやり方だよね。
うん。
そうだね。
だし、結構ええ段だなっていう気がするな。
なんかマイクロソフト、言うてもめちゃくちゃシェアでかいしさ。
まあシェアがでかいからこそなのかもしれんけどね。
その要はさ、なんかこの、ね、なんかこれがわからんならもう使わんでもいいけど、
でも別に他になんていうか大体可能なものないでしょって言える側のシェアを持ってるから。
あー、確かにね。
うん。
確かに確かに。
あー、それは確かにそうかもね。
確かに。
まあそういう側面もなくはないとは思うけどね。
うんうんうん。
確かにね、エクセルの代わりはないからね。
うん。
まあスプリットシートはあるけど、なんていうかやっぱオフィス365にしかない。
うん。
オフィス365じゃないと回んない現場みたいなのもめちゃくちゃ欲しい。
うん。
なるほどね、確かに。
まあなんかこれがそうなんだよね。
うん。
まあだから、世の中全体に対して見たときに関係するべきことでは多分あるよね。
そうだね、全然。
またWindowsのパスキーのプロバイダーの互換性を頑張ってもらったりとか、
その辺になってくる感じかな、残りとしては。
うん。
またMSに追従して他の。
そうだね。
うん。
デカいとこもどんどんやってくれるとって感じだね。
いやー。
これは良いニュース。
良いニュースでした。
なんか思ったより早く来たなっていう感じは。
いやーでも。
まあまあまあ。
順当っちゃ順当かな。
そうだね、なんか感覚的には結構順当かなとは思うけどな。
いや、てかそのー、なんか、なんて言ったらいいんだろうな。
要はフィッシング、なんかもう極論どうしようもないよねみたいなところを現場で見てた身としては、
要は他に手がないわけで、遅から早かれ、こうなるしかないっていうのがもう多分、
そういう対策をなんていうか、何やかんややってる側視点ではもう、
もうそういう未来が見えてるわけで、
じゃあ早い方がいいよねっていうふうにはなるはずで、
だからマイクロソフトという立場でそれをやるっていうのは、
まあ確かに英談ではあって、
うん。
なんかまあ難しい仕切ってもあったのかなとは思うんだけど、
まあ本当にありがたいなとは思いますね。
経産省のセキュリティ対策
うん。
なるほどね、確かに。
早いか遅いかぐらいしか。
現状だと、なんでこっちか。
いやー、3ヶ月後、半年後、1ヶ月後、何、いつかわかんないけど、その後の世界を。
まあレポ使ってニュースとか出るんじゃないかなと思いますから、楽しみにしたいですね。
うん。
はい。
じゃあ次いきますか。
はい。
次が、経産省のサプライチェーン強化に向けたセキュリティ対策評価制度対応ガイド、
2026年度の運用開始に向けて実施すべき事項とタイミング、っていうエナーライセキュアさんの記事でございます。
これちょっとね、ちゃんと全部読んでないんだけど、
一問一答っぽい感じでわーっと並べてるパートが結構良かったなと思っていて。
あーそうだね。
後ろの方だね。
結局うちは影響受けんの?みたいな話とかね。
前段の部分もそうなんだけど、前段の部分ってなんか別の記事でもちらっと見たよね、確か。
気のせいだっけ。
あーどうだろう。なんか。
紹介はしなかったのかな、ここで。
これは見てないかな。
なんかあった気がする。
あー確かにね。
なんかすごくざっと話すと、まあでもタイトル通りやるのか、サプライチェーンの、
このポッドキャストでもちょこちょこ話してる、その委託先のIPAの重大競技にも入ってるけど、
委託先からのサプライチェーンの被害みたいなところで、
じゃあそれの対策で委託先の会社がちゃんとやってんのっていうのを、
実地検査でチェックしましょうとか、責任チェックシート配りましょうみたいなのが、
現状の、現実の回答になってしまってるけど、そんな回らないよねみたいな話があって、
それがまあ、その連鎖して、
発注者と受注者がいて、その発注先にもまた発注先がいてっていう感じで連鎖していくっていうのが、
その辺を全然拾えてないよねっていう部分に対して、
回答となる制度っていう話かな、めちゃくちゃざっくり言うと、
っていう感じだね。
多分スコープとしてはIT基盤だからOTシステムとか入ってなくて、
業務外中でソフトウェアを作ってもらってとか、多分そういう部分がスコープに入ってるし、
なんか今セキュリティアクションっていう、IPAからIPAが設定してる、
こういう対策をしてますって自己宣言するみたいな仕組みがあって、
これがあることは知ってたんだけど、それにレベルがあることは僕知らなくて、
それも紹介されてるんだけど、セキュリティアクションっていうのがレベル1、レベル2みたいなのがあって、
これに繋がる形でレベル3、3、4、5を決めて、この3、4、5っていうのを、
さっきのサプライチェーンに向けたものとして使うっていう想定をしてて、
なんで多分目指してる世界としては、発注受注するときに、
うちはこのレベル4でやってますみたいなのを示すことで、
発注先は発注内容に合わせて、レベル4ならじゃあ発注できるねみたいな判断をできる世界を作ろうとしてる、
プロトコルにしようとしてるって感じかな。
3、4、5の詳しい内容は読んでくれって感じだけど、3とかは自己評価だし、
4は第三者評価、5も第三者評価みたいな感じで、レベルが上がってくると取得が難しくなったり、
要項も厳しくなるって感じっぽいですね。
そうだね。
なんでまあ、目指してる世界観としては良さそうというか、
こうなってほしいよねっていう気持ちにはすごくなるね、個人的には。
どうなんだろうね。なんか、チラッとノーションの方にも書いたんだけど、
制度自体が動けないっていう展開を多分見越していて、
海外の類似制度との互換性みたいなところが今後どうなっていくかわからないんだけど、
じゃあ例えばなんだけど、
Googleクラウドに対して、これの5を満たしてますかって、
日本の企業が聞きに行けるかってなった時に、
どうなのかなってちょっと思っちゃうんだよな。
そうね。互換性って具体的にどうするんだろうね。
即屈タイプ2取ってたら星5としましょうみたいな、そんなのになっちゃうのかな。
わかんないけど。
でも結構、到達点とし、目指すべきセキュリティ対策、星5って結構レベル高いけどね、なんか。
星5の内容自体はまだ検討中なんだよね、具体的な項目とかは。
でも、さっき言ったすごいシンプルな互換性なんであれば、
グローバルスタンダードでいいじゃんみたいな話にはなっちゃいそうな気がするけどな。
そうなんだよね。だいたいわさわさ5段階に分けてる意味もわかんないしさ。
一応5段階の意図としては、あれか、なんだっけな。
例えばだけど、預けるデータとか、いわゆる納品するソフトウェアがどういうコンポーネントの中で、
求める要件自体を変えるみたいな想定をしてるっぽいかな。
だから例としては、データは機密性がなくて、事業中断の影響もなくて、
ナビシステムに到達されるわけじゃなければ、星3、レベル3を求めればいいんじゃないみたいなことが例として書いてある。
機能する?それで。だって、なんか。
わかんないけど、例えば、グローバルスタンダードっていうか、グローバルのその認証系全然把握してないからわかんないけど、
この、なんだろうな。
まあ、例えばその、まあ。
だってさ、ここの、これは星3だから社内ではこの用途でしか使っちゃいけませんって、なんか振れ回って。
逆じゃないかな。逆で、こういうのを発注するんだったら、
レベル4以上のカバン、レベル、
認証なのか、これを満たしてるところじゃないと発注できないよねっていう、たぶん順番なんじゃないかな。
いや、だとしてさ、例えば発注するなり、作ってもらうなり、そこの提供してるサービスを使うなりしたとして、
その、組織内でのそれらの用途がさ、
その特定の用途に限定されるわけじゃん。
使い始めた後に。
そうだね。
うん。
そこのなんか実行性の担保みたいなのって、たぶんめちゃくちゃ大変で、
何が星3で何が星4でっていうのを管理しないといけないわけでしょ。
そうだね。
で、じゃあさ、星3、今星3で星4相当の使い方をしたいですって社内でニーズが出てきたときに、
どうすればいいの。
まあ。
GW後のストレスと課題
委託先にじゃあ星4取り直してくださいって言って、できるかって言うと、
たぶん必ずしもそうじゃないだろうし、
その、あまりにもアンコントローラブルだよなって。
じゃあなんか違うとこ探すのかとかさ、
そうするとちょっと遅すぎませんって話になっちゃうと思うし、
その、そこのなんかレベル分けのさ、なんかこう、
まあ、うんうん。
まあ要はあんまり動きの激しくないところで使うことを想定してるのかな。
いろんな物事の。
まあそれで言うと別に、なんか今この時点でもその課題はある認識で。
まあそうね、それはそうね。
そう、ただそれを、
たぶんうまく取り扱うフレームワークが、
として提示されてるって感じなんじゃないかなって気がする。
うん。
だから、たぶん現実はもう、
たぶん9割のユースケースはめちゃくちゃナーナーでやってるんじゃないかなと、
個人的に思っていて。
なるほどね。
まあ要はどっち、
問わがいても社内でこういうの作らざるを得ないよねっていうところに対して、
乗っかれるものを提供しようっていう話なのか。
そうだね。
それならまあなんとかはあるな。
うん。
まあわかんないけど、
ね、なんかSMS取ってたらOKとかさ、
なんかその01ぐらいの。
で、なんかさっきちょっと思ったのはグローバルスタンダードと互換性あるのはそっちでいいじゃんと思ったけど、
一方でこのじゃあグラデーションちょっとつけ、3段階つけたいってなった時に、
そのなんだろうな、
なんか実業でもちょっとあるんだけど、
その、
まあこのユースケス、
この使い方でこのSaaSを契約するなら、
まあ正直、
もちろんなんか安全に越したことはないけど、
そのSock2、Type2とか全然いらないっすみたいな。
うん。
温度感って確かにあって。
そうだね。
でもなんかそこに、
じゃあなんかその、
レベル3に相当する認証とかって別に、
ないというか別に認証取るほどでもないみたいなところを、
なんかどう言語化して意思決定するかみたいな、
ちょっとなんか若干めんどくさいというか、
だからそこで社内の基準を作り込んだりするんだけど、
まあそこに割とふわっとはまるんであれば、
まあ価値はなくはないかなっていうところはあるし、
まあレベル3とかは自己評価でいいってなってるから、
まあグローバルで互換性とかも多分概念としてない気がしてて。
まああるかないかで言うと、
PCI DSSのSAQとかはそれに近いはずで。
あ、そうなんだ。
セルフアセスメイクでしょ。
ああ、はいはいはい。
なるほどね。
はいはいはい、確かに近そう。
まあ要はこのレベルだったら、
このレベルだったら、この範囲だったら別にSAQで済ませていいよっていうのがある。
で、ただ結構偉い人のサインが必要なんですよ、最後に。
端的に言うとね。
私が責任を持ってここに書いてあることが正しいと言い切りますよっていう署名を最後にする偉い人が。
ああ、そういうところ。
ほしさんに書いてあるのも似たような感じなのかな。
自己評価括弧、資格者による評価ありって書いてある。
資格者による評価ありだから、多分そういう資格を出すの作るのかなって言ってね。
だから社内でそういう人、そういう資格持ってる人を置いてやってもらうのかなって言ってね。
なんかちょっとちょっと利権っぽい香りがしてくるな、そうなると。
そうだね。
この資格者の内容次第。
セキスペこの。
支援者なのかもしれないね、確かに。
ありそう。
なんかはなさそうだよね。
なるほどね。
課題はあるけど、でもこれをうまく使いこなせるかどうかは全く別の話だし。
そうね、その脅威と現状のギャップを埋める一端にはなってほしいなという気持ちと、
まあこれだけで埋まりきると思わないから、まあまあ頑張っていく必要があるんじゃないかなって。
このFAQで入ってたけど、なんだっけ。
それこそ、どれだっけな。
どれかに、あ、強制力か、強制力の話とかだけど。
なんか業界なんで標準化されることが見込まれ、事実上の必須基準となる可能性がありますって書いてあって、
まあそうなったらいいっすねってちょっと思うわ。
なんかそうなるのかどうなるんだろうなとか思うけど。
結構その、ね、一部しか使ってないっていうのは多分全然ワークしないというか。
別にこれ、ある種なんかSMSも特定界隈でそういうなんか側面あるんじゃないかと思うけど、
取ってないなら、検討にはもう入れないですっていう。
ぐらいになってきたらまあまあ、いいんじゃないかなっていう気はしつつ。
まあどうなんでしょう。2026年度なんで、あと1年後ですか、目指してるのは。
これは何、もう業界問わず使うことをやっぱ想定してんのかな。
多分スコープとしてはその、IT基盤システムと書いてるから、
そうだね、これを扱う会社は業界問わず使うから。
なるほどね。
例えば病院が発注するときとか、ベンダーに。
とかに、星5を取ってないと無理ですとかそういう風に言うっていう。
なんか下の方に自公開・無公開のガイドラインとの互換性みたいな話があって。
自公開・無公開。
結構なんかそんなボリュームがあるのか。
あー、なるほどね、結構ボリュームがあるね。
50ページ、なるほどね。
いや、こういうの互換性ないと多分きついよな。
ASMSとかもね、そうだよね。
どうなんのかな。
3つ、4つマネジメント系運用ってなると大変だよね。
結局ワークシャインってなるだろうから。
星5の内容も揉んでるし結構、
26年度目指すって感じだから、
目指すとは書いてないか。
でも向けてって感じだから、なんていうか。
もう少し回数度が上がってきたら。
まあでもこれ星3が求められるところは、
この資格者による評価っていうところが気になる感じですね。
そうだね。
支援士になるのかな。
ここで支援士の資格は生きるか。
でもあれか、登録積スペじゃないともしかしたらダメか。
ダメじゃない、多分。
えー、そうなったらちょっと利けんのか。
利けんっていうか、高ぇよ。
登録じゃないとダメなんじゃないかな。
いや、私も切っちゃったんだよね。
全然意味なくて。
登録してたんだ、えらい。
あれはね、取ったタイミングでしか登録できないから。
取ったタイミングっていうか、
違う、私の場合はあれだから、
せいだの開始のタイミングで積スペの過去の合格の記録を使って登録しちゃうので。
あー、なるほどね。
その一発目は会社が出してくれるタイミングだったので、
NRSギャーは出してくれたんだけど、
メルカリは資格に他に出してくれないので。
登録積スペ使い道ないだろうなと思って登録しちゃったかな。
いや、ないよ。
取り直さないといけなくなるのかな。
そうなるね、登録積スペになるんだったら。
アプリケーションセキュリティの現状
まあ、全くわからんけどね、蓋開けてみないと。
はい、まあちょっと今後も気になりますねという記事でございました。
そうですね。
はい、ちょっとなんかこなし感がさすがに強いな。
まあ、いっか。
そう?
そんなでもないかな。
いっか。
そんなでもないんじゃない?
わかんない?なんか、え、わかんない?
これ以上語るべきことがあればって感じだけど。
まあ、ないからいいや。
そうそう。
話し足りなかったらそりゃ妥協せずに。
了解です。次いきますか。
次が、New Research Reveals 95% of AppSec Fixes Don't Reduce Riskという記事でございます。
これがまたハッカニュースですね。
これは何?どこの研究?Ox Securityでいいのかな、きっとね。
アプリケーションセキュリティの95%のアラートでいいのかな、きっとね。
が、まあ、なんて言ったらいいんだろうな。
実際にはリスクを軽減しないっていう研究結果が出てるらしくて。
詰まるところ、95から98%のアラートが実際に行動が必要ないもの。
で、57万件のものをなんか実際に見たのかな、たぶんね。
で、そのうち202件しか実際に真に重要な問題っていうのが含まれてなかったよっていう話が書かれてる感じでございます。
まあ、興味深いですね。
興味深い。
でもなんか体感とも合ってる気がせんでもない。
なんかむずいよな。
結構ちょっと思いやるじゃないけど。
この記事では特にこうするといいねみたいな、あんまり思いつかない範囲のことは書いてなくて。
放り投げないでよってすごい思ったんだけど。
大まかに言うとそのベースラインアプローチからリスクベースアプローチに移行しましょうねっていう話でしかないんじゃないですかね、結局。
そうだね。
なんか理屈はわかるんだけど、結構本当にちゃんとやろうと思うとさ、
もうなんかちゃんとがっつり1チーム貼り付けて開発しないと無理なんだろうなって気がするんだよな。
パッチ、パッチ当て屋さんが必要ってこと?
パッチ当て屋さんとかルールの最適化とか取り味の自動化とか。
まあね。
いやなんか、例えばリスクベースアプローチで考えたときにさ、
リスクを評価するときの変数としてそのシステムって何に使われてるんですかとか、
そういう会社固有のコンテキストがすごくたくさん入ってくるはずで。
いやでもさ、パッチがさ出てるんだったらさ、
なんかその調査をしてる間にパッチを当てた方が早くないっていう話は当然にあると思っていて、
その調査をするよりもパッチを当てるコストの方が高くなっちゃうような状態にしちゃいけないよねっていう話だと思うんだよな、
どっちかというと。
まあそんな簡単な話でもないなわかりつつ、なんかでも。
なんか、お、それはもう基本そうしたいなって100%同意なんだけど、
なんか最近ちょっと思うのはその一定規模超えるとそうも言ってらんないんじゃないかっていう気はしていて、
っていうのもそのなんだろうな。
いやなんか実際ちょっと直面してるのが仕事でも若干直面してるんだけど、
なんかね、どうにもならん、そのパッチをすんなり当てられないものっていうのはどうしても出てくるんですよね、
いろんな制約を元に。
で、当てらん、すぐに当てらんないってなった時に、じゃあリスク評価きちんとしてその。
でもそれってその時点で初めて必要になるわけで、じゃあそれがその何割ありますかって言われた時に何割ぐらいなんですかね。
で言うとまあ、割合は難しいけど、なんかね、ボディブ、なんか割合はわかんない。
いやまあじわじわ聞くのはわかるし、そこそこその手間もかかるのはわかるんだけど、
そのさ、なんか、じゃあそれを週に100件処理しないといけないですっていう話なのか、なんか、
まあ月に2件ぐらいですねみたいな話なのかで、多分だいぶ変わってくると思っていて。
週に100件だったらさ、なんかその根本的に何か解決しないといけないよねっていう話になると思うけど、
その月に2件ですだったらさ、なんか別にそういうリスク評価をその都度するでも、
まあ最悪回らんでもないよねと思うし。
まあ波はあるかもな。
なんかある週に30件ぐらい飛んでくる時とかがあるんだよな。
3週間何も起きないみたいな時があったりとか。
資格者による評価の重要性
で、そうなった時になんか30件バッてきた時に別のもので、そんなに運用側にその、
オンデマンドに手を裂けないってなった時に、
まあバックログがたまって、じわじわとたまって。
あとだからすぐに当てられないっていうところの理由だよね。
うーん、そうね。
その忙しいですっていうのはさ、なんか。
それはその、まあそれも一つの課題であるのは事実なんだけどさ、なんか。
セキュリティっていう文脈においては、
まあセキュリティに限らずなんだろうけど、
有力を持ちましょう以上のことが多分言えなくて、なんか。
そうだね。
じゃあシステムの複雑性のせいですって話だったら、
それってでも別にセキュリティ以外でもたぶん聞いてるはずで、その問題って。
うんうん。
いや、なんかちょっと思うのは、
今僕が直面してる課題とかは、
まあやりゃいいとは思っていて、
これがじゃあその、
会社成長していって開発メンバーの数が3倍になってリポジトリの数が5倍になった時に、
同じことが言えるかっていうよりだと結構、
あんまりどうだろうな。
それはなんかどっちかっていうと、
そのセキュリティの体制の話に踏み込まないといけない部分だと思っていて、
その、
なんていうか、
そこの仕組みのスケーラビリティみたいな部分の話はまたちょっと違うとこだよね、きっとね。
そっかそっか。
だからね、まあ。
要はセキュリティチームみたいなものがどこまで踏み込みますかって話になった時に、
まあそういう規模感になった時にじゃあ踏み込めるかっていうと、
まあそれは踏み込めないよねと思っていて、
だから逆に言うとそこの、
今抱えてる課題っていうのはそういう規模になった時には、
たぶん自分自身ではもう考えなくなるポイントだと思うんだよね。
システムとセキュリティの課題
その個別具体の話は。
どっちかっていうとその、
なんていうか各チームがどうやったらそこに対してコミットしやすくなるんだっけっていうところをたぶん考えないといけない話で。
このパッチ当てるの難しいねをセキュリティチーム自身で考えるっていうのは、
そのフェーズに至った時にはたぶんもうない。
そうね。
いやーまあ確かに。
いやでもわかるよ。
全部言ってることはそう思う。
まあまあまあ言うはやすしの典型例だと思うんだけど、
その、ただなんていうか、
例えばだけどアクション不要なアナウンスみたいなところがなんか記事の中で言及されてるけど、
そういうのってなんか、
アプリケーション監視とかの、
なんていうか文脈においては明確にアンチパターンじゃないですか。
そうだね。
アラートは出る、発砲するけどアクションは不要みたいなのって、
なんかもう明らかにアンチパターンなんだけど、
セキュリティだとどうしてそうなっちゃうのかなっていうのはなんかちょっと話してみたいなと思ったところで、
その、
まあアクションがいるかどうかをどうしてもその人に判断を委ねないといけないからなのかな。
うんうん。
うーん、なんだろうね。
なんかそこは最適化に取り組んだことがないからわかんないけど、
まあ例えばパッと思いつく、
まあわかりやすくアクション不要な例とかで言うと、
使ってない機能のハイレベルの脆弱性が出るとかはまあ、
いやでも難しいんだよな、
それも今使ってないんだけどいつか使うかもしれないみたいな。
それ聞こうと思ったら開発チームにヒアリングしに行くのみたいな。
だからそれぐらいするんだったらじゃあパッチ当てるよみたいな。
でもパッチ当てるのが実はなんかその依存関係の話で、
今すぐ耳かきが取れなくてみたいな、
なんかそういう、例えばそういう、
違うな、なんか全然別の話が発生してしまったな。
まあもう多分なんか想定してるのはもうちょっと、
ここの記事で言われてるのはもうちょっとシンプルなやつで、
スキャナーとか、
依存管理ファイルとかをベースにして、
なんかこのバージョンのこれにはこういう脆弱性があるよみたいな通知が来るやつを、
多分意図してると思うんだけど。
アクション不要、そうね、アクション不要。
まあでも複雑性ゆえなのかな。
結局そのコードを書いた人でも、
例えばNPMとかだと、
なんか脆弱性が含まれてる階層にも寄り切りというか、
結構、ノードJSの脆弱性あるあるで言うと、
なんだろうな、
文字列の、REG XPとかめちゃくちゃ多いかな。
REG XPというか正規表現のDOS、
サービス拒否攻撃とかはめちゃくちゃ多くて、
大体そういうのが出るのって、
かなりNPMの階層のレイヤーが低いところのパッケージで出ることが多い。
すごい文字列処理のutilityとか、
XMLのutilityみたいなそういうもので出ることが多くて、
それを使ってるのがじゃあ何なのって、
本気で辿っていくとめちゃくちゃ多いというか、
有名どころ、世の中の有名どころNPMはみんなどっかで依存してるみたいな。
だったときに、なんだろうな、
どっか1個ほけると開けられなくなっちゃうってことだよね。
だし、でも機械的にじゃあそれを、
アクション不要かどうか判定しようと思うと、
それは無理だよね。
そう、それをどう呼び出すかってコンテキストを全部、
機械的に読むことはできるけど、
原理上は参照してます。
外部入力から、
例えばリドスの話で言えば外部入力からそもそも正規表現を生成してない。
違う、外部入力に対して正規表現を当ててないみたいな状態だったら、
基本的には安全だよねみたいなこと言えると思うし、
みたいな話だよね。
そうだね、でももっと、
そういうのを蓋開けてみると、例えばビルドツールで使ってるだけですみたいなパターンとかがあって、
じゃあビルドツールに外部からの値が入るかどうかは、
もう人間しか判断できない。
でも、人間目線、
このリポジトリ、このビルドツールはどう考えても大丈夫でしょみたいなパターンはやっぱり結構まあまああるというか、
アクション不要なアラートの例として。
そういうのはすごい一例としてあるって感じかな。
いやー、なんか、うーん。
あとはなんか、その、
運用の効率性向上
例えばもうhttpでサーバーでこのヘッダーつけたらもう、
なんかめちゃくちゃアウトですみたいなものがあって、
あるけど、それが動いてるシステムは、
なんか、なんだろうな、
POCでめちゃくちゃインターナルなとこしかないですとか、
そもそももうこれデプロイ実は終わってますみたいなパターンとか、
そういうのもあったりするのかな。
まあなんか、うーん。
なんか結構こまごま、
必要なのは話しながら思うけど、
こまごま手入れをしていくような仕組みは多分あった方が良くて、
その、なんだろうな。
逆じゃん、なんかその、
ヤバいものはすぐ当てないといけません。
それ以外はなんか周一でバッタ当ててくれればいいですよって。
なんかもう当てるか当てないか考えるのもダリいからとりあえず当てようぜっていう、
世界にどうやって持っていくかっていう話なんじゃないかなと思うんだけどな。
まあね。
いやあまりにも不毛なんだよな。
なんかそこをさ、なんか頑張って調べて、
検討してみたいな。
なんかもういいじゃん、上げちゃおうよって。
なんかその、上げてダメだった時に、
なんか何にも影響なくソフトランディングできるような、
なんかやり方を、
なんかこう作っていきましょうよっていう話をしたいなできれば。
そうね、それは。
あまりにもなんか生産性がない、
そこの、何ていうか、このパッチ当てて大丈夫なんだっけ、
なんかめちゃくちゃ時間を割くことに。
うん。
それ以外でも結局さ、なんかいろんなトラブルが起きたりするわけで、
なんかその別にパッチ関係なくさ、バージョン、
セキュリティーイシュー関係なく、
そのバージョン上げたらなんか壊れましたみたいな話も起こり得るわけじゃん、結局。
っていう中でさ、
なんかバージョン上げてリリースしたら壊れましたに対して、
そのいかにソフトランディングするかみたいなところを構築するっていう方がなんか、
効く範囲も大きいし、
なんかレバル中がよく効くというかさ、
なんか仕組みとしては全然そっちのほうが望ましいわ、
思うんだけどね。
そうね。
うーん。
あとはなんかその保険としての和風みたいなものとかさ、
なんか。
うんうん。
そういうものであとはカバーしましょうねっていう方が、
なんか世界観としてはなんか、
まあ望ましい気がするんだよなあ。
うーん。
そうしたいっす。
うーん。
まあちょっとね、
まあとはいえ言うはやすしな話なのも理解はしていて、
その、
でもなんかなぜそうできないのか、なぜそうならないのかっていうところはさ、
なんか正直僕自身そこまで解像度が高くないっていうか、
なんかまあ自分でも開発とかはしてたけれども、
それでもやっぱりそこまで解像度は高くないっていうか、
その、
なんか安直に上げると普通にビルドがこけるみたいなのはなんかちょこちょこあったりするわけだから、
なんかそういうのはわかるってこと。
うんうん。
うんうん。
なんか。
なんか、
まあでも、
まあ難しいね、
なんか。
うーん。
いやまあパッチに関しては本質的な問題は何だろうね、
なんかリターンがないことなのかなあ、
開発者目線。
いや、めんどくさいし、
その今言ったビルドがこけるみたいなのって、
その開発で、
なんか、
その、
何だろうなあ、
結構ボディーブローみたいに効いてくる部分があるというか。
まあわかるよ、
わかる、
なんかそのさ、
なんかわかるよ、
それはわかる。
うん、
でなんか、
そうね、
まあでもケースバイケースかなあ。
うん。
いやノードとかは結構カジュアルに、
いやなんかね、
いや本当、
でもケースバイケース。
いやまあでも。
うん。
やり続けてる、
なんかね、
一番最初から、
そのパッチを、
まあパッチないしは別にセキュリティパッチだけじゃなくて、
バージョンアップをずっと、
例えばリノベート運用をガンガン回してるようなところは、
すごく、
多分あんまね、
何も考えなくていい、
理想の世界線になってます。
うんうんうん。
なんだけど、
やっぱその途中から始めたものとか、
その、
基礎技術がネガシーになっちゃってるやつとかは、
めちゃくちゃ足を引っ張るんだよね。
そのネガシーだとその、
なんかメジャー、
なんかめちゃくちゃでかいコンポーネントのメジャーアップデートをしないとどうにもならないけど、
そのメジャーアップデートには、
なんか下手したら半年、
1年かかりますみたいな話とか。
じゃあこのアラートの山はどうしましょうみたいな話になったりとか、
まああとその途中から始めたものとかも、
そのなんだろうな、
やっぱある種不再編成だよね。
不再編成みたいなものに投資をしなきゃいけなくて、
それをどこにどうねじ込みましょうみたいなところは、
まあ、
あれかな、
でも会社としてセキュリティとどう向き合うかっていうレイヤーの話には落ちてくるんで、
まあそれでもやればいいんだけどと思うんだけど。
デベロッパーエクスペリエンスの重要性
セキュリティ関係ないと思うんだよな。
なんかその、
ある種のデベロッパーエクスペリエンスの話でもあると思っていて、
なんかその。
いやー、
だってさ。
例えばさ。
だってやらない選択肢がないわけじゃん。
どっかで、
いつかどっかでやらなきゃいけないっていう選択肢が絶対ある中で、
なんていうか。
でもそのデベロッパーエクスペリエンスもさ、
例えばその、
みんながよく、
例えばある開発チームがいて、
その開発チームがもう毎日毎週、
毎月されるようなポジションは多分いいんですよ。
うん。
でも、
なんかその微妙に、
誰もオーナーシップを持ってない、
なんか3ヶ月に1回、
昨日会社があるみたいな。
でもそこまでいったらもう、
そこまでいったらそれこそセキュリティの話じゃないじゃん。
そんなものをさ、
そのまま放置しとくのよっていう話しかなくて。
いや、でも現実はそれでも必要ってものがあるんですよ。
例えば。
オーナーシップをさ、
じゃあ誰も持っててませんっていうのはさ、
その保診に必要ならオーナーシップを誰も持ててないって状態は良くないよね。
でも、
その、
いや、そのきれいにそんなオーナーシップを、
いや、アサインすることはできるよ。
でも、
アサインされた側も、
いや知らんけど、
じゃあまあやりますみたいになるわけですよね。
それはなんかオーナーシップを、
オーナーシップっていうさ、
その概念がもう崩壊してるじゃん。
いやー。
そのオーナーシップがあるというのはつまりどういうことですかっていうところに対してさ、
なんかその状態がじゃあオーナーシップがあると言えるんですか、
本当にそれでっていうところはちょっと突き詰めて言わないといけない部分だと思うんだけどね。
いやーわかるよ、
その、
なんかそうは言ってもさっていうのはその、
現実世の中そういうふうに回ってねえんだよっていうのもさ、
わっからんでもないんだけど、
アプリセキュリティへの投資
その、
なんか、
わからんでもないんだけどさ、
いやまあそうだよねーっていうのも思うんだけど、
なんかでもその、
なんか鋼の意思を持ってそこをきれいにしていかないと、
なんか、
別にセキュリティに限らずありとあらゆる問題がそこに散席していくわけで、
その、
うーん。
なんていうか、
じゃああなたは片付けなくて済むからいいかもしれないけど、
でもそれってなんか、
会社なり組織にとって、
その、
なんていうかそれでいいんですかって話になったときに、
なんか、
うーん、
どうなんだろうね。
いやー。
でもそれがさ、
実現できてたらさ、
極端な言い方すると、
その技術不採というような、
いやわかるよ。
生まれないわけじゃないですか。
わかるわかるわかる。
いやだからなんかすごい、
今ものすごくきれいごとをこう喋っていて、
自分でもなんか、
あのー、
後ろから刺されそうだなーって思いながら今時々するんだけど、
その、
まあ俺もいろんなものを残してきちゃってるわけだから、
その、
うん。
なんか、
まあそうは言ってもねってこともわかるんだけどね。
なんか、
うん。
会社に行ってくることは全部その通りだと思うし、
全然否定も全くできないか、
むしろそうあるべきであると思ってて、
うん。
ゆえの、
なんか、
一番最初の発言に寄り戻すけど、
なんか、
なんだろうな、
さ、
ここでいうアプリセキュリティの部分をちゃんとやろうと思うと、
なんかちゃんと投資というか、
うん。
エネルギーが必要だよねっていうのは思う。
うんうん。
まあね。
どのタイミングでどういう形で、
どうエネルギーを投資するかっていうところは結構、
うん。
いろんなバリエーションがあると思うんだけど。
まあでも、
これってなんか、
なんかね。
その、
ボディーブローっていう話が出てたけど、
その、
逆ボディーブローっていうかさ、
逆ボディーブローって何?
何の逆なのかわからないけど。
笑
笑
いやでも、
いいよ。
じわじわ積み上げで効いてくる投資の典型だと思っていて、
あの、
そうだね。
それはそうだね。
ここにそう、
セキュリティに限らず、
こういうとこに投資をしておくことで、
将来的なそのアジリティを確保できますよっていう話だと思うんだよね。
うんうんうん。
なんか3年後、
5年後、
もっと長い目で見たときに10年後、
えー、
まあ身動きが取れなくなっている可能性を、
まあ減らすことができますよねっていう話だと思っていて。
技術的負債と今後の戦略
うん。
いつかはだってやらなきゃいけないことなんだからこれ。
夏休みの宿題と一緒ですよ。
笑
夏休み。
終わる。
終わる。
全然だって焦らせないために。
まあまあそうだね。
そうそう。
そう思うよ。
今これ、
この動きができないと会社が死ぬっていうタイミングで動けるかどうかに
かかってくるものですよね。
うん。
それを、
それを、
その可能性を、
そのリスクを取ってでも今これをやらないっていう選択をしますかどうですか。
今会社ってそういう状況ですかっていうところに対して、
そうですそういう状況ですって言えるんだったら、
じゃあ今はやらなくていいんじゃないですかって言っていいと思うけど。
いやあ、
まあ難しいね。
うん。
その意思決定をなあ。
まあまあまあまあ。
でもなんか問いとしてはそういう話だと思っていて、
その。
そうだね。
それを、
その問いに対して正しく、
それぞれの開発チームが意思決定を下すようなフレームが必要だなと思う。
その、
やっぱりなんか状況によってその問いへの答えって簡単に変わってしまうっていうか。
しらかっていうときはもうちょっとトップダウンの話のような気がするけどね。
ああ、
そうね。
まあそこはちょっと。
まあまあまあちょっとなんかいろいろそのあると思うんだけど、
誰が言い出すかっていう部分で言うとボトムアップ的な部分は当然あると思うんだけど、
そのっていうか、
組織としてどうしたいですかっていうところに対してはトップダウンの意思決定が必要な部分だと思っていて。
うん。
なぜかというとそのビジネス上の優先順位の話とものすごく絡んでくるので。
そうだね。
いやー、
まあちょっと、
入社してもらって、
うちのアラートを見て、
もっかい同じ話したいな。
いやなんかね。
いやだから夏休みの宿題の、
今何月何日の状態なんですけど。
何月何日?
いやまあでも、
何月何日で何割終わってる状態なんですか?
あー、
夏休みって言ってたっけ?
8月1日から。
まあ我々は7月の下旬から8月末とかまでかな、たぶん。
あー、まあ8月上旬でどうだろう。
いや難しいなその、
いやペースは悪くないよ、なんか。
うん。
ようやってる方だと思うけど、
なんていうか、
うーん、ボディーブローって感じがするなー。
なんかその、いや詳しい、ちょっとね、
地上波にはあんまのせい。
なるほどね。
まあちょっと夏休みの宿題とさ、
単純に比較できないのはさ、
夏休みの宿題増えていくわけだからさ。
うーん、そうだね。
要は8月31日に、
8月31日の終わりに、
夏休みの宿題が残ってる状態にならないようにするっていう、
その、要は恩助かどうかっていうのを常に見ないといけないわけで、
なんかちょっと考え方が違う部分ではあるんだけど。
うーん、
まあそれで言うとたぶんこのままだとやりきれないけど、
先生には怒られずに済むっていうレベル。
あー、なるほどね。
そう、廊下には立たされないかな。
うーん。
リスクは顕在化しない範囲でコントロールはできてると思うけど、
ゼロにはたぶん今のペースだとできない。
みたいなさ、なんかことを語りたいよね。
その、このままだとどこかで崩壊しますよねっていう話をたぶんしないといけなくて、
崩壊するのを避けるためにはもうちょっとペースを上げて、
恩助の宿題を昇華していかないといけないですよねっていう。
うーん、またみんなが漢字ドリルを、
誰でも漢字ドリルをできるような仕組みを作るとかね。
うん。
セキュリティチームだけじゃなくてとか。
まあその辺別に全くやってないわけではないんだが。
うんうん。
うーん。
いやだからその誰でも漢字ドリル、
うーん、難しいな。
で曲の漢字ドリルをやらなくてすぐ世界にしたほうが良くって、
それがだからさっき言ったその、
何て言うか、そのパッチが何なのかは知らんけどとりあえず当てるっていう状態にできれば、
それの要は漢字ドリルを開く必要はないわけですよ。
そうだね。
そうね。
いやー。
でもぽこぽこ出てきたもの全部当ててたら、
なんか最新バージョンには実は変なものが仕込まれててみたいなのが、
それはまた別の問題だから、
まあちょっと考えないといけない。
そうだね。
でもそこはそれこそなんかセキュリティチームが多分本当は動くべき部分で、
そのー、何て言うか。
さあ、なんか。
うーん。
まあまあそうね、別のイシューだと。
そうそうそうそう。
うん。
別のイシューだし、別のアプローチだし。
うんうん。
漢字ドリルやりたくないでしょって別に開かないと済むんだから、
その方がいいじゃんっていう話のような気もするんだよなー。
でもわかるよ、なんかほっとくと溜まってっちゃうのもわかるし、なんか。
うーん。
いや、ほっとくなくても溜まるのが多分むずいんだよなー。
まあまあまあそうね。
うん。
割とイトするんだけど、次の記事が。
そんな大変かなー。
え、でもなんかチーム単位で見ると普通になんかDefender Bot Alertとか普通に消化できてたんだよなー。
うーん。
なんかアーキテクチャーもあるかもね。
うんうん。
マイクロサービスはめちゃくちゃいいと思うよ。
そうだね。
まああとは言語のエコシステムとかも多分関わってくる部分で。
あーまあ、言語、そうね。
まあでも、うちの場合はアーキテクチャーがしんどいかなー。
うんうん。
いやその、モノレポだと誰が判断するのとか、なんなら誰も判断できないのとかもあったりするから。
オーナーシップと当事者意識
逆じゃん、誰が判断してもいいよっていう。
いやだからやっぱそう、うーん。
まあねー。
パッチャ、まあそうね。
まあ開発の、うーん。
いや。
いやまあでも、だからこそその、うーん、いやまあいいや。
あのー、また仕事で話しましょう。
そうだよ、もう無限ループできるから。
無限ループできるから、いや何が言いたかったかっていうと別に誰が判断してもいいよ、誰がどんな判断をしても失敗したらソフトランディングできるからねっていう、なんかそのバックアップがあるかどうかなんじゃないのって思ったんだけど、
だからこそね、誰が判断すればいいかわかんないっていうところに対して、いや別に誰が判断してもいいんだよっていう。
誰に判断してもらえばいいんですかって言ってる今あなたが別に判断してもいいんだよっていう状態にしてあげる方が健全なんじゃないのって思ってるね。
うーん。
なんか。
そうね。
うん。
オーナーシップってなんかすごい哲学的な話だけど、なんかそういうことなんじゃないかなって思っちゃうんだけどな、なんか。
ある種の当事者意識というかさ、なんか。
うーん、まあでもむずいよ、なんか誰かが3年前にポッと入れたユーティリティライブラリーのパッチバージョンにオーナーシップを持ってって結構厳しくない?なんか。
オーナーシップをさ。
オーナーシップっていうか、当事者意識。
うーん。
で、なんかそのリポジトリは。
でもそこに問題があるのは確かで、その問題は自分のところのサービスに、まあ多かれ少なかれ影響はしているわけで、自分のところのサービスは自分の会社に影響しているわけで、自分の会社は自分のお給料に影響しているわけでっていう。
うーん、まあそうね。
じゃああなたが当事者じゃないんですかって聞かれたときに、なんかいや当事者じゃないですってなっちゃうんだったら、なんかそれはそれでどうなのと思っちゃうんだけどな。
そこは演出が必要だね、なんか。
なんか関わりのさ、そのなんか浅い深いはあれども、なんか当事者であるってことからはもう逃げられないと思うし。
まあまあ本質的にはそれは正しいと思うんだけど、なんかそれを認識させるような演出は絶対に必要だと。
演出。
普段の開発をしてて、いやわかんないけど、じゃあ例えばわかんないけど、それをまずその、じゃあそのすみっこのUTTライブラリにセキュリティパッチを当てなきゃいけないっていうのが発生してるってことを気づく必要があるじゃないですか。
それはそう。
そこはまず繋げなきゃいけないよね、だし。
確かにね。
気づいたところでその、僕例えば言ってる映画。
確かにね、だから確かにそれは確かにアーキテクチャの問題があって、マイクロサービスアーキテクチャにおいては自分のとこで見るものっていうのがもうスコープとして最初から決まってるのでっていうのは確かにある。
そこは明らかにアドバンテージがある部分だ。
そう。
だからうちとかでもエンジニア全員が必要なときに触るWebアプリケーションのすみっこのパッチを見るってなるともう多分、
自主的にやってくださいになると絶対偏っちゃうから、
毎回この人が見てるってなるから、それがいいか悪いかの話は置いといて、
それが目指してる形なんだっけっていうのは多分考えなきゃいけないし、
拾ってくれる人がいたらいいけど、いなかったときにじゃあ誰にやってもらうのとか、
どういう風にデザインしようかっていうのは毎回突きつける。
クソ安直にいくんだったら別に当番制だよね。
クソ安直にいくなら当番制。
まあね、でも結局対応にグラデーションが出ちゃうというか、
めっちゃきっちり細かくやる人もいればそうじゃない人もいてっていう状況になるわけだから、
それが必ずしも正解ではないし。
ここで取り上げたけど、じゃあもうデビンにやらせようとか、
今だったら何かいくつか、多分いろんな飛び道具あるはずだから、
それ組み合わせたり、
まだ全然揃いう意図で並べた、並び順じゃないけど、
次の記事がね、ある一つね。
じゃあ、まあいい機会だから、次行きますか。
それね、若干あれなんで。
まあまあまあ、なんか結構ね、
課題としては地味に解決が難しい系の問題であるのは理解はしているつもりで、
きれいごと言ってはいるけれども、
じゃあお前どんだけできてたのって言われると、
まあ確かに難しい部分はあるよなと思っていて。
やりがいはある、間違いなく。
まあちょっときれいごと並べ立てましたが、
1ヶ月後僕が何を言っているか楽しみにしています。
楽しみにしています。
次の記事はそんな話題のDependabotの記事なんですけど、
Githubのブログの記事ですね。
もうまさにという話なんですけど、
タイトル通りでDependabot Alertの優先順位付けをして、
そういうことに対応しなくていいアラートを決めるとか、
グラデーション付けるっていうのをやる方法っていうのを話している記事ですね。
これはなんかノウハウみたいな感じで、
こういうふうに機能の説明っていうよりかは、
Dependabot Alertをこういうふうに使うと、
ある種課題であるアラートが溜まっていって、
その優先順位付けられないとか、
どれが大事なものか分からないっていうところに対する課題の緩和、
内緒は解決になりますよって話をしてるって感じですね。
具体的にはいくつか書いてあって、
ピックしてるんですけど、
GithubのアラートはEPSSとCBSS両方出てるんで、
それを加味して判断しましょうみたいな話とか、
あとはこれ結構面白いしやりたいなと思ったんですけど、
リポジトリプロパティ、リポジトリカスタムプロパティを使ってフィルターしましょうみたいなのがあって、
これ何かっていうと、
Githubの機能としてリポジトリにカスタムプロパティっていうのを付けることができて、
これは何というか文字通りカスタムプロパティで、
数字とかブーリアンとか文字列とかセレクト形式で、
オルグワイドでそのプロパティみたいなのを定義して、
そのプロパティをリポジトリごとに設定できるんですよ。
いいね。
なので、例えばプロダクションに乗ってるかどうかみたいなフラグのプロパティを付けて、
プロダクションのやつは優先度高く見ましょうみたいなのをやるとかっていう話ですね。
リベンドボットアラートの検索画面でリポジトリプロパティによるフィルターがサポートされているので、
使えますって話ですと。
あとはリスクのマトリックスみたいなのを定義して優先順位を決めましょうみたいな話もあって、
例えばで言うとEPSSとCBSSでロー、ミディアム、ハイで決めて、
そのマトリックスで例で書いてあるところで言うと、
両方ハイならフィックスファーストまっすぐ、即座に直しましょう。
どっちかがハイなんだけど、もう片方はミディアムなんであればなるべくフィックス、なるべく早く直しましょうみたいな感じで、
グラデーション付けるといいんじゃないかみたいなのが例として書いてあるって感じですね。
あとはこれはAdvanced Securityを契約している場合のみなんですけど、
リベンドボットアラートの自動取り味機能みたいなのがあるらしくて、
ここで定義したマトリックスとかプロパティとかEPSS、CBSSの値を元について自動取り味をするみたいなものを仕込んでおけば、
手動で対応するアラートの数は減らせるよっていう話が書いてあったって感じですね。
前段に言ったまさにもうちょっと人手を減らすみたいなところの話だし、
個人的にはリポジトリプロパティ使うのマジでいいなと思ってて、
リポジトリプロパティは弊社はまだ使ってないんですけど、
このリベンドボットアラート以外の文脈でも結構セキュリティ文脈では活用の可能性があるなと思っていて、
例えば取り扱う情報のレベルみたいなのを選択形式で必ず必須にするとか、
このリベンドボットアラートのために環境の話、プロダクションなのかデベロップメントなのかとかもそうだし、
内部向けツールなのか外部向けツールなのかとか、
あと弊社とかたまにあるのはApp Scriptのやつとかをコード管理のために置いたりしていて、
そういうのって別にある種、脆弱性アラートは出ないのかな、出ないけど、
いろんなものから除外してもいいよねとか、そういうものはステータス分けできるかもとか、
なのでめっちゃいい活用例だなと思いつつ、
自動取り味めっちゃやりたいと思ったら課金必要で、
まあそうですよねって気持ちにはなりつつ、なんかOSS書くかみたいな気持ちになりつつって感じですね。
Dependabotの活用法
APIは全部叩けるから自前で作っちゃえばいいだけではあって。
なるほどね。これリポプロパティはさ、リポプロパティをAPI経由で設定とかできるのかな。
要は何て言ったらいいんだろう。
ありそうですね。
これがGitHubのリポジトリ単位でプロパティが設定されているのも一つ魅力ではある一方で、
たぶん上位概念として、たとえば、いやでもそっか、モノレポか。
たとえばだけど、マイクロサービスアクティクサにおいて、
そのサービスのメタデータを管理している仕組みが別にあって、
そのサービスのメタデータが自動でリポジトリのプロパティに設定されてくる、
みたいな形とかの使い方もできるのかなってちょっと思って。
確かにね、それはできると思う、作れば。
たぶん実運用はその方がいいかなって思うね。
そもそもリポジトリの管理自体をさ、なんかもうちょっと上位概念の何かで管理した方が良い気もしていて、
これは要はツールしか入ってない、インターナルのツールしか入ってないよ、みたいな話とかさ。
そうだね、うちの場合はテラフォーム管理に全部しようとしてるから。
リポジトリそのものをね。
そうそうそう、定義してもらっちゃう。
それがいいよね。
そう、テラフォームとかにできればコンフテストとかもかませられるし。
ダッシュボードとかもさ、そういうのあった方が作りやすいと思うし。
別にでもリポプロパティ自体API経由で取ってくれてもいいんだけど。
まあでも結構使い手はありそうというか。
ベータで出たときは何に使うんだろうってめっちゃ思ってたんだけど、なるほどなって感じ。
もっと早く欲しかった感はあるよな、なんか。
カスタムプロパティ自体はだいぶ前からあって。
そうなんだ。
GAになったのかな。
多分2年前くらいから存在をしてた。
ただ活用例みたいな、俺が多分ちゃんとキャッチアップしてなかったっていうのもあるけど、
あんまりうまいチュピントきてなかったけど、この例もそうだし、
別の記事で読んだのも、別の記事で読んだやつにセキュリティーのやつ書いてあったってやつかな。
セキュリティレベル多分4何回くらいつけて、レベル高いやつはこういうふうに何かを適用するみたいな話とか。
あとあれか、オルグワイドワークフローみたいな概念があって、
オーガニゼーション全部のリポジトリでリクワイアドステータスに含めるGitHub Actionsの定義ができるんだけど、
それの対象を絞るのにカスタムプロパティが使えるようになったみたいな話もあったかな、確か。
あとルールセットだ、ルールセットの適用とかにもカスタムプロパティが使えるとか、
プロダクションのやつはデフォルトブランチ、直ブッシュ禁止にするみたいなことができたりする。
Dependabotについての考察
ちょこちょこインテグレーションじゃないけど、つながってきてる感があるって感じかな。
やりてー、やるつもりではあるんですけど、まだうちはできてないですね。
はい。
これはまあある種、さばききれない前提での記事っちゃ記事かなって感じだけど。
なんかね、でも個人的にはDependabotアラートもうちょっと頑張ってほしいんだ。
なんかラベル付けとかコメント残させてほしいんだよな。こういうのも嬉しいんだけど。
今はそれができないんで。そう、それができないのもなー、しんどいんだよな。
はい。
まあね、そうね。Dependabotもそうなんだけどさ、Dependabotってさ、
これ自動取り味多分ね、自分で作ったほうがいいと思うな。
なぜそう思ったかというと、Dependabotって今新しいバージョンが出ましたの通知しか投げてくれないじゃん。
新しいバージョンというか、今使っているバージョンにセキュリティーアラートが出た通知。
セキュリティーアラートに限らず出してくれなかったっけ。設定によるか。
アラートに出るのはセキュリティーアラート。
ああ、そういうことか。
DependabotのアップデートPRは設定している。
なるほどね。
プリリックだけで。
確かに確かに。そこは、いかに俺がそこを区別してないかな。
俺全然区別して生活してなかったわ。
全然区別して生活してなかったんだけど、何が言いたいかというと、
さっきの記事で言うと、このセキュリティースキャナーみたいなものの、
静的解析をした結果これが問題だよみたいなやつとかも、
多分アラートで投げてくれるようなものがあると思うんだよね。製品としていろいろ。
アドバンスとセキュリティーだったらギターでもあるね。
そっか。
自前で組むとかもあるよね。
そうだよね、あるよね。
なったときに、どうなんだ、アドバンスとセキュリティーの自動取り合わせ機能なのかな。
ここで言う自動取り合わせって。
新しいAPIの導入
これは自動、そう、アドバンスとセキュリティー。
そっか、じゃあ全部まとめてってくれるのか。そっか、じゃあ気にしなくていいんだな。
要は自前で組んだものとかも含めてみたときに、
自動取り合わせってGitHubから切り出しておいたほうが楽そうだなと思ったんだけど。
でも確かにアドバンスとセキュリティーで全部まとめてやりますだったら問題ないかな。
そうだね。
あと、課金しないと触れないから物は見てないんだけど、
自動取り合わせの自由としないでもあるよね。
GitHubが提供する。
何にせよそうね、自前で。
自前で組むとしても多分GitHubから依存を剥がすっていうものにはなんないんじゃないかな。
なるほど。
何か、どこをソースにするか次第だと思うんだけど。
Dependabotじゃない手段で検出しようってなると、
結局何かのソリューションを使うことになると思うんだよね、おそらくは。
で、あったらそっちに乗っかっちゃった方がいいよねってなると思うし。
SneakなりYammerlyなり、その辺だから。
その辺です。
カスタムプロパティ使っていきたい。
使っていきましょう。
あれだな、GitHubの記事が3連続なんですけど。
めっちゃあるなと思って。
面白かったんだよ。
なるほど。いい話。
次のやつはこれもサクッとだけどちょっと面白くて、何かっていうと、
Credential Revocation API to Revoke Exposed APIs is now generally availableっていうGitHubのチェンジログン。
タイトル通りでGitHubのパッドを無効化するAPIがGAになりました。
なんで元からあったらしいんだけど、僕は知らなかった。
これ何に使うかっていうと、漏洩したパッドを見つけたときに、
本人じゃなくても漏れちゃってるからリボークするねってリボークできるっていうものですね。
そのAPI叩くときには認証してない状態で叩かなきゃいけないらしくて、
一応悪用できないために1日50回とかに制限されてるらしいんですけど、
まぁまぁあるって感じで、
なんかこの発想なかったなって思って結構おもろいなと思ったのと、
なんか悪用できないんだっけと思ったけど、
意外と確かに悪用できないのかなと思って。
これそもそも待って、認証はどうやってやってんの?
漏洩したPATを使ってリボークするPATを指定する形にしたら悪用しようがないじゃん。
内部不正とかじゃなければ。
これを漏洩してんのを見つけたよっていうそのPATそのものを投げないとリボークできないようにしておけば。
そうだよね、そういうことだよね。
悪用できないよね。
このAPI自体を使っては確かになんもできないっぽいなっていう。
せいぜい内部で使ったやつをいたずらでリボークするくらいかな。
あとはなんかやる価値があるかどうかわかんないというか、
これやりたかったらGitHubに課金した方がいいかなと思ってるけど、
自分のリポに対してスキャンかけて見つけたらリボークまで自動でやるみたいなのは自動化できるようになったんだなっていうのもちょっとふと思いつつって感じかな。
間違えてプッシュしたときにリボークまでセットでっていうのはやってもいいかもな。
これはなんか課金が必要なの?そんなことないよね。
これは必要ない。
無料で誰でもってことだよね。
パブリックAPIだから。
いい話だな。
これなんかわかんない、自分が知らないだけなのかもしれないけど、みんなやればいいのにってめっちゃ思ってる。
めっちゃそう思う。
そうしたら割とエコシステムっていうかね、各クレデンシャルスキャナーが見つけたらリボークみたいなオプションつけたらリボークして回ってくれるみたいになるとめちゃくちゃいいよね。
結構そのクレデンシャルスキャナーの信頼性が試されるけどね。
俺だったらそこクソ狙うけどね。
だってあらゆるクレデンシャルがそこに集まってきて、リボークしましたよって思ってて言ってるんだけど、裏ではただ悪用してるみたいな。リボークしに行かずに。
まあそれで言うと今も状況は変わんないっちゃ変わんない。
まあそれはそうだね。純粋なスキャナーとかそうだね。でも確かにな。
スキャンしてる時点。だからそこにまるで仕込まれた人。
でもスキャンしたものを自分でリボークするっていうふうなワークフローを自分たちで組んでればリボークはどっかで必ずされるわけだけど、
何らかそこに変なものが仕込まれていて、使ってる側リボークしたと思い込んでる。リボークされたと思い込んでるんだけど実際にはリボークされずにただ悪用されてるっていうのは少数量ね。
まあね。リボーク部分だけいじれるなら。
なんかもし結構自由にいじれるならもうスキャン結果自体隠して盗んじゃえばいいなって。
確かにね。それもそうだね。
気づかれないのが一番いいから。
確かに確かに。そうするとだから今の状況変わらんな。
確かにね。
いや失礼しました。
いやいやいや。
ジャストアイディアでしたから。
いやーおもろいよね。みんなやったし。
まあGoogleのSEキーとかは特定の条件でリボークするみたいなリリースがあった気がするけど、
第三者がリボークできるわけではなかったはずだから。
はい。ちょっと面白かったです。
次もね。
GitHubのユニコード警告機能
おおっと思ったんですけど、
GitHubの、
チェンジログですねこれも。
GitHub now provides a warning about hidden Unicode text っていう経緯ですね。
これももう本当タイトル通りで、
正性や悪用文明でポッドキャストで何回か取り上げてますけど、
隠れたユニコードの文字、画面上に表示されないけど実はあるっていう文字が含まれてるときに、
GitHubが警告を出してくれるようになりましたっていうチェンジですね。
キャプチャー見るとわかりやすいんだけど、
多分ね、多分ファイルかな?
ファイルを開くとき、
ファイルを見るときに表示してくれるっぽくて、
文脈としては何の対策かとか書いてないんだけど、
おそらく直近の正性や異回りとかも意識してるのかもしれないし、
めちゃくちゃいいじゃんって思ったのと、
前話した隠れたプロンプトをコピペしてChatGPに貼り付けられたときにどうなるの?
どうすればいいのか?みたいな話のときとかも、
全部こういう仕様にしちゃえばいいじゃんって普通に思ったっていう感じかな。
こうやったらね、意図してたらまあやるだろうし、意図してなかったらあれってなるだろうし、
いいじゃんって思いましたって感じでしたね。
そうだね、それでいいのかな?うん、そうだね。
モデルに加わせる前に警告を出すって、まあいいのかな?
穴がないか。
いろいろ考えてんだけど、人間が触るUIにおいてはこれでいいだろうなと思いつつ、
でもAPIだとこれやれないよなって。
じゃあみんながその事前にチェックしてっていうのを実装しなきゃいけないよねっていうのもあるし、
一方でとりあえず食わせたものそのまんま一旦解除してほしいよなっていう気もするし、
まあUIが伴う部分は確かにこれでいいよねとは思うんだけど、
みたいなことを今思ってました。
なんか分かんないけど、次の記事がちょっと繋がるかもしれないね。
繋げていくスタイルで。
はい、繋げていきましょうか。
発火ニュースで、
これは何かのリサーチの記事なのかな?
話としては、MCPのプロンプトインジェクション、
MCPサーバーの脆弱性とか攻撃の話はここでもしてますけど、
攻撃の話と防御にも使えますよっていうのを、
研究者がリサーチを出したのかなっていう話ですね。
で、ちょっとコマゴマはぜひ興味あるんだれば読んでほしいんですけど、
何かっていうと超ざっくり言うと、
MCPサーバーをJSONでバーっていろいろ皆さんインストールして日々使われてると思うんですけど、
そこに防御用に実装したMCPサーバーを入れとくことで、
いろんな脅威に対する防御機構としてそのMCPサーバーを動作させられるっていう話ですね。
具体的には例として書いてあったのは、
例えばその防御用のMCPサーバーをインストールした環境で、
呼び出されるMCPのログみたいなのを全部とあるファイルに記録するみたいなことを、
そのMCPサーバーを入れることで実現できたりとか、
特定の悪意のあるプロンプトとか挙動したときにそれをブロックするような仕組みとかも、
ある程度はMCPサーバーを入れることでできたらしいっていう。
実証実験というか、PoCの例みたいなのもちょっと記事中では書いてあって、
他に具体的に何かあったかな。何個かあるって感じなんですけど。
ツール管汚染とかツール管シャドウイングみたいなのも妨害することができるって。
なるほどっていう感じですね。
面白い。
思ったのは可能性としては良さそうな気はしつつ、
逆にここまで他のMCPサーバーに干渉できるってことは、
悪意側も同じ話は完全にあるからっていうのと、
あと記事についても多分触れられてたんだけど、
挙動自体はロジックではなくて生成AIの挙動に依存する以上は、
ゴールデンウィーク後の心境
再現性みたいなところはどこまで担保できるのかみたいな部分はあるし、
面白いんだけど、別のレイヤーは必要だろうなと思いつつ。
MCPのクライアントなのかな。
クライアントですかね。
クライアントの挙動をちゃんと勉強しないとなーって気持ちも。
いやーちょっとあんまなんか全然日常生活で使えてなくてMCPって。
まだMCP見た一見なんですよね。
使わんとなー。
とりあえずローカル肉労働としてちょこちょこ使うようにしてるところまでしかやれてなくて。
使わんとだよねー。
そうなんだよねー。
使わんなら、それ言うと俺もなんかちょっと出直してこういうレベルで終わるんだけど。
面白いね。
うん。
いやーなんか面白いけど、もうなんか大変だよ。
ここ1ヶ月はもうこんな記事がポコポコポコポコ出たり入ったりして。
なんかさー、いやーしんど。
もうAIで吉野にやっていてくれような気持ちになる。
これがその例だよねまさに。
AIが吉野に守ってくれようでいる。
ね。いい感じに安全にしといてって言ったらいい感じに安全になっておいてほしい。
もはや。
クビになって。
俺がやられて嫌だと思うことやらないで。
言っといたらやらないで。
そうだね、それはほんとにそう。
でもなるほどねって思いましたこれは。
面白いな。
今日取り上げ、ちょっと制徳できなくて取り上げなかったんだけど、別のやつとかもね、なんかその
マイクロソフトのコパイロットに食わせるプロンプトを
生成AIで危なくないか評価するっていうサービスの紹介とかがあって、
なんていうか、ぐるぐるもう脳みそバグりそうになる世界になってきたなっていう。
いやー、なんか、うーん、
あー、ちょっと言語化できないんだけど、この
LLMのためのセキュリティモデルみたいなものが多分整理されていくんだろうな。
で、プロンプトとペイロードみたいなものを多分明確にプロトコルとして分離するようなものが出てくるんじゃないかな。
mcpとかってもしかしてそうなったりする?
ペイロードっていうのは何を指してるんだ?
要はこれはペイロードです。解釈してはいけません。
あー。
プロンプトではないです。
そうね、どうなんだろうね。
今んとこそこも生成AIが解釈できちゃってるからな。
あんまなんかプロンプトとして渡すみたいな世界観だよね、今んとこ。
そうだね、基本。
確かに、でもそっちの方が精度とかが上がってくるんだったら全然そっちの方向に流れてくることはあるだろうね。
だから精度、今んとこなんか精度ドリブンだよな。
そうだ、フリーフォーマットで渡して、どこがプロンプトでどこがペイロードなのかっていうのもLLM自身で解釈させるっていう方が、
まあ、今どころ言いにかなってたぶんそういうのが主流なのかなと思うんだけど、
ただ、散々言ってるけど、ゆるめのサンドボックスみたいなのが必要だよねっていうのを散々言ってると思うんだけど、
そういう話をたぶん2回やっていて、これはプロンプトなのであなたが解釈して、これに従って動いていいけれども、
ここから先はペイロードだから、ここに関しては安全じゃないものが入っている可能性があるよっていう、
信頼協会LLM側に作ってもらうっていうことをするために何らかたぶん、
そこを区別して渡すような手段がおそらく必要になるんじゃないかなとは思うんだよな。
そうね、確かに。
ただ、それが利にかなってるかどうか、LLMのあれとして利にかなってるかみたいな話は確かにあって、難しいね。
難しいね。あとはこの記事中で触れられてるけど、
いや、でもあんま関係ねえか。SAプロところみたいな話も出てきて。
というか、いいっすね、毎月毎月。
ぽんぽんぽんぽん新しいネタが。
でもちょっと荒波に揉まれてる感が強すぎて。
あるね、あるね。
そうだね、最近一周回ってちょっと考えすぎない気持ちで、
目の前の仕事で遭遇するものを一個一個潰していこうという気持ちになってる。
なんていうか。
でもなんか、このLLM時代のセキュリティモデルみたいなものに思いを馳せておくみたいなのが多分大事な営みで、
なんて言ったらいいんだろうな。
その営みの中でいろんな物事の一般化ができるというか、ちょっと上手い表現が見つからないんだけど。
ある種の試行実験じゃないけど、トレーニング的な。
そこがなんか割と純粋なセキュリティの部分というか領域なんじゃないかなと個人的には思っていて。
確かに、分かるかも言いたいこと。
誰も耕してないからこそ、試行実験。
もっと言うと、結局は原理原則に従って考えていくと、そうだよねみたいなところに行き着くし、
そういう形である程度未来を予見できる部分があると思っていて。
確かにね。
でもそうはならなかった、例えばだけどこういう未来になるんじゃないかって思ってたものに対して、
そうはならなかったっていう結果が出てきたときに、それはなぜなのかっていうのがまた一つ学びになるというか、
例えば今俺がプロンプトとペイロードっていうのを多分分けた方がいいんじゃないか、
そういうモデルになっていくんじゃないかみたいなことを言ったけれども、
仮にそうならなかったとして、じゃあ何か原因なのかなっていう風に考えたときに、
さっき話したような全部プロンプトで渡した方が効率がいいとか、より良い結果が得られるみたいな話が実は裏にあって、
なるほど、じゃあそこのトレードオフでそこは明確に信頼境界を分けないっていう考えに落ち着いたんだなとか話なのかな、
紹介してないけどって言ってたコパイロットのプロンプトが安全かどうかを先に評価するみたいな、
生成AIで評価するみたいなのも結局多分モデルとしてはそうなってると思うんだよ、
あなたはこういう判断軸に従って渡されたプロンプトが安全かどうかを判断してください、
そのプロンプトはあくまで安全じゃない可能性があるので解釈しちゃいけませんよ、解釈しちゃいけません、それに従ってはいけませんよみたいな、
何らか多分そこの信頼境界を分けるために何かっていうのはやってるはずで、
なんかモデルとしてはそっちに行くんじゃないかなって気はするんだよな、
なるほどね、確かに。
MCPとかもそういうモデルが入っていくんじゃないかなと思うし、分かんないけどね。
確かに、1枚かまして、またサーバー側の話はサプライチェーンに落ちるしな。
そうなのよね、意外となんかそんなによくある話ではないっていうところに意外と落ち着くかもしれなくて。
確かにね、でもなんか1ヶ月後にまたMCPを拡張する新しい概念が盛り上がってるにごせんぺりかかな。
まあでもMCP自体は結構シンプルなあれだからなんか長生きしそうな感じがするけどね。
そうね、なんか根底はそんなに分かんない気はする。
またA2Aがどんな感じになるかな。
いやでもなんかアンコントローラブルすぎるよな。
そうね。
A2A、A2A。
Googleのブログしか言ってない。
いやなんかさ、キルスイッチ的なものをさ、どうやって作ればいいんだろうね、この世界観において。
キルスイッチとは。
いやボタンポチで全てが止まる。
ああ、AIたちが止まる。
うんうん。
うーん、確かにね。
今の世界観だともうAIがよしなにって感じになるよね。
そっか手元でPOCやってる人とかいるね。
いやーなんていうか。
なんていうかっていうのは。
うん、まあいいや。
腹身に揉まれてこう。
うーん、A2Aも。
なんか。
MCPもそうなんだけど、そのエージェント間のタスク処理の。
うん。
むずいな。タスク処理のその順序制御というかモデルみたいなのってどういう感じになるのかな。
うーん、ちょっとA2Aプロトコル仕様を読んでみたっていう前を書こう。
なんか、いや動機的に行われるのか非動機に行われるのかとかさ、なんかどうなってるのかな。
エージェントがエージェントを呼び、そのエージェントがまたエージェントを呼び、そのエージェントがさらにエージェントを呼びみたいなものが入れ子に連なっていくモデルだとしんどそうだから。
非動機にやるのかなって。
そうするとじゃあコールバック関数みたいなのを渡すような感じになるのかな、イメージ的には。
うーん、謎っすね。ちょっと予習が必要な気がする。
うーん、解説記事とかちょっと読んでみるな。
そうするとタスクの給とか設けることになるのかな。
でも割り込みタスクが発生して優先順位を変えて積みたいですみたいな。
どうすんだろうとか。なんか、ちょっと共有回だ。
勉強しよう。夏休みでしょ。勉強してきて。
いっぱいあるんだよ、他にも。勉強したこといっぱいあって、なんか。
ちょっと読んでみよう、いろいろ。
2ヶ月はなんか短いね。30年くらい欲しかった、この休みって。
攻めるね、30年か。
キリがないね。まあだからなんかいかに普段の生活の中でなんかいろんなことをやれるかっていう話なんだなと思いました。
そうね。いい気づきだな、それは。
一周回って、この先こういう夏休みみたいな期間があるのかないのかわかんないけど、
そういう期間があったら、なんかそんな真面目なこと考えずに遊ぼうって思った。
うーん、そうね、確かに。
思いました。
それは確かに心理かも。
どうせなんもできない。
そうそうそう。なんかまとまった時間があるからちょっと勉強しようみたいな。
なんかもういいよ、どうせなんか普段の生活でやれてないことをどれだけやれるかみたいな話にならうわけで。
なんか60日あるなら10日ぐらい山梨泊まってみるかとか、たぶんそんぐらいのノリで生きやすい。
旅行癖みたいなのもあんまないかな、それで言うと。しょうがないね。
次回に。
いや、次回にっていう、まだ頑張ろう、まだ間に合う。
まだ間に合う、まだ間に合いますか、今からでも間に合いますか、夏休みの宿題。
今からでも入れる夏休みがあります。
ちょっとね、ゴールデンウィークも終わったしね。
世の中はゴールデンウィークが終わったらしいので。
そうそうそう、自分だけのゴールデンウィークスタートしてくださいね。
スタートするか。
じゃあ今日はそんな感じですか。
そんな感じでございます。
じゃあ、いやー、来週はまたどんなニュースがあるかわかんないけど、皆さんお楽しみにしていてください。
おやすみなさーい。
AIとLLMの進化
おやすみなさい。
