新年の挨拶とゴールデンウィークの話題
こんばんは、Replay.fm 第86回です。
こんばんは、86回。
はい。これでみくが明けましたけど。
明けましておめでとうございます。
明けましておめでとうございます。
今年は小読みが悪いらしいけど。
どうなんですか?
え?何の?年末年始のほうの話?
ゴールデンウィーク?
いや、うん。なんか誰かが言ってた。
悪かったの?
わかんないけど。
今年、来年じゃなくて?
今年はこうだったんじゃないの?
あ、そうなの。価値観によるのかな。
なんか知り合いが言ってて。
予備間隔が半分あって半分ないんで。
ああ、そうなんだってぼんやり思ってたけど。
そうか。なんか何も、何もせんでも、カレンダー通りでも5連休があったから。
そうだね。2日休めば9連休にできるって感じか。
2日。
だから昭和の日がまでもあれだから。
どっちで2日取るかにもよるからな。
31で取るんだったらなんか8だし、7、8で取るんだったら9か。
なるほどね。
両方取るんだったらさらに伸びるけど。
確かにね。憲法記念日も振替休日になってるから別に悪くなそう。
うん。
なんか悪くないかもしんない。
何を持って、何がご不満だったのかちょっとお便りでお知らせしてもらえると嬉しいですが。
誰から聞いたか覚えてないけどずっと聞いてないんだよな。
来年も悪くなさそうだけどね。来年もなんか別に何もせんでも5連休。
30日に休むと1,2,3,4の7連休って感じかな。
6,7も休むとさらに伸びるって感じかな。
僕30日がお誕生日なんで。
おめでとうございました。
ありがとうございました。
この休みがかぶってあまり人に祝われない人生を送ってきて。
お祝いのメッセージください。
いや、いらないですけど。
お便りで。
読み上げます。
何だろう。承認欲求なのかこれは。分かるんですけど。
別にお祝いのメッセージいらないからどうしよう欲しいわ。
4月誕生日あるあるなんだけどさ、
ことあれかな、学校とかのコミュニティにおいては学年変わって。
クラスがええ直後みたいな。
そうそうそうそう。
仲良くなってきた頃に誕生日いつって話になって、
あ、4月30ってなった。
あーみたいな。
N回経験してきた。
大体ね。
そうそうそう。来年クラス変わって。
おもろ。
やりましょう。どうでもいいですけど。
お便りお待ちしてます。
GoogleフォームのNextどちらでもお待ちしてます。
すごいな、ぐだぐだ話パート史上最もしょうもない話だった気がするな。
そうだね、身のない。身のない、身はあるよ。
きっとね、100人いれば1人ぐらいには刺さるでしょ。
バースデーパラドックスね。
そんな用語があるの?
なんかよくわかんない方向に広げないで。
何それ。
俺がなんかあるある。
え、あ、そうなんだ。
バースデーパラドックス。
何人集まればその中に誕生日同一に2人以上がいる確率が50%を超えるか。
これね、これ有名なやつやな。
こっちか、はい、バースデーパラドックス。
この理論で言うとお便りくれる確率は結構高いと。
そうだね。
23人、23人。
23歳生は毎回言ってそうだから。
そうですね、はい。
よいしょ。
今日はボチョボチョ多いんでね。
はい。
じゃあ1つ目お願いしようかしら。
フリー社におけるセキュリティチャンピオンズプログラム
フリーのアジャイルセキュリティを支えるセキュリティチャンピオンズ、
フリーデベロッパーズハブの記事ですね。
ちょっと斜め読みしかしてないんだけど、
まずセキュリティチャンピオンズの制度をやってたんですね、フリーさんは。
2022年から。
結構長いんですね。
はい、どこから拾っていけばいいのかな。
もともとその2022年にセキュリティチャンピオンズプログラムを開始して、
ブロンズランクっていうのを当時制定しましたよって話で、
その時点ではシルバーもゴールドも全然考えてなくて、
とりあえずブロンズだけで走り出したっていう感じだったらしいんだけど、
その後2024年にシルバーランクっていうのが制定されて、
基準を設けてこれを生み出したらシルバーランクだよっていうのを設けて、
制定したよっていうのと、制定したよっていう経緯があって、
2025年についにゴールドランクっていうのが制定されましたよっていう話ですね。
シルバーランクっていうのは、
有効なセキュリティデザインレビューを10件行ったセキュリティチャンピオンを
シルバーランクっていう形で認定するよっていう。
シルバーランクのセキュリティチャンピオンが行うレビューは
ピースアウトのレビューと同等のものとみなすみたいな感じで、
制度を制定しましたよっていう感じだったらしいです。
ゴールドっていうのが、どこだっけ、ゴールド。
どこ行っちゃった。
そうそう、要件を固めて事業部においてセキュリティ文化を調整できたチームの中で、
その功績に最も貢献した人っていう形で、
推薦文書いてもらって、1人任命しましたよっていう感じらしいです。
結構いい話だなっていう感じではあるんだけど。
これこの記事の中であったソフトウェアデザインの機構、
確かに4連続のやつなんですけど、
実は会社のヤギヤ所に入社前に林道会で読んでて。
そう、俺読んでないんだよね。
めっちゃお勧めですよ。
そこでもセキュリティチャンピオンの話は触れられてるんだけど。
実態としては結構ハンズアップで、
PサートとかCサートで、今はちょっと体制が違うのかな。
ガッチャンコした話があったけど、
当時Pサート、Cサートでいろいろ手庇録やっていかなきゃいけないって中で、
中枢権的にやるのは限界あるよねってところで、
ハンズアップ形式で自分が所属するチームに入れて、
セキュリティ周りの責務になったり、
あとはPサートと接続して、
いろんな課題からの共有とか、
知見の共有みたいなのをするみたいな。
めちゃくちゃざっくり言うと、そういう枠組みの取り組みを
やり始めました、やってますってぐらいだったのかな。
ソフトウェアデザインの時は。
2024年なんで、2年前か。
始まって2年後に連載総有化とかできたって。
そっか2年後の答え合わせみたいな記事なのかな。
いいね。なんか2年後に答え合わせしてくれるの普通にいいなって思ったわ。
めちゃくちゃいい。
あとこの、なんか手挙げてくれる人がいっぱいいるっていう時点で
結構いいなっていうふうに思いながら読んでて。
僕はあんまり制度設計に関わってないから言っちゃうんだけど、
メルカリは2020年になんか記事を出して以降、
なんの落とささもないけど、その後どうなったのかなっていうのが
すごく気になってしまった。
なんか雷も似たようなやつを多分、
フリーよりは高発でやってるのかなって気がするけど、
結構その、なんか人間に対しての制度になるじゃん。
解決したい課題はソフトなんだけど、
ハードか、ただなんかやりたいって、
なんか無理やりやらせるのは違うよねみたいな部分の思想がある。
とはいえ、でもなんか多分何もしなかったら別に
誰もハンズアップしないみたいなところあるから、
なんか文化情勢みたいなふわっとしたところから、
こういうインセンティブみたいなのも一つのハードだと思うし、
この記事で触れてね、いろんなこともやってるのかなみたいなことも考えると
結構尊い取り組みだし、
なんかワークする、一つワークして回ってるよっていう会社があるのは
励みになる話だなっていうのが結構普通に感じますよね。
なんかいい話だな。
このJITSMに目指した制度っていうのがめちゃくちゃいいなと思ってて、
実際にセキュリティデザインデビューをしてるよっていうのもそうだし、
セキュリティデザインデビューを一定数こなすとランクが上がって、
その人の要はある種の、
何て言ったらいいんだろう、一定の責務を負ったアーキテクトみたいな役割だよね。
どっちかっていうとソフトウェアエンジニアリングの方の話で言えば、
そういう感じでピーサーとかやってるのと同じものとして見出すよっていうような部分とかもそうだし、
JITSMの中でワークしてるっていうのが見えてくるのがめちゃくちゃいいなとは思うな。
制度作りましたまでは割と簡単ではあると思うんだけど。
そうだね。スタート地点だからね。
そうそう、ショットで終わっちゃうっていうのも、
別に要は何て言ったらいいんだろうな。
ショットで終わっちゃうって多分結構いろいろ課題があるというか、難しい側面があるからなのかなと思ってて、
見えてきてないだけでショットで終わってないところもいっぱいあるのかもしれないけど、実際には。
まず一発目の例えばだけど研修やりまわすみたいなのが、研修やる側にとって重すぎるとかもそうだし、
なんかその業務の中で意外とセキュリティっていう部分の割合がやっぱり低いみたいなのもあると思うし、
いろいろ課題はあると思うんだけど、ちゃんと実際の業務の中に根を張っていくような制度になってるっていうのがいい話だね。
間違いないね。
いやー、なんか尊い。励みになる。
僕がソフトエンジニアの立場だったら結構、いやー、なんかなんだろうな。
僕がソフトエンジニアの立場だったら結構やりたいと思える側の立場、中華人種なんで結構そのなんだろうな、
アイディア自体をあんま否定する人はいなさそうというか、
まあね。
セキュリティに興味ある人がいたときに、そこに対してスキッチジャンプっていうロールを作ってみたいな、
言い出すのは簡単だし、やり始めるのはめっちゃ簡単な気がする。
簡単というか誰でもできる気がするんだけど、それをワークさせるっていう部分にめちゃくちゃ壁はあるような気はしていて、
なんていうかね、
まあめっちゃ、例えばで言うと、実業務が忙しすぎてそういうのが隙間がないですみたいなのも全然あり得るだろうし、
あと名前つけただけじゃやっぱダメで、
じゃあその人たちは何を期待されてるの?とか何をしてほしいの?みたいな部分をある程度言語化するとか、
そういう意味でセキュリティデザインレビューみたいなのを、
たぶんOne of Sevenだと思うんだけど、これとこれをっていううちの一つで、
ここに対してこれぐらいやったら貢献してるよねみたいな定義付けをできてるっていうのは普通に一つ参考になる部分だなって気はします。
まあね。
ふんわりセキュリティに責任を持ってくださいだとあんまりそれってどういうこと?ってなるというか、
じゃあ具体的に何?っていうのを細かく決めすぎるのもたぶん違う気はするし、
そもそもソフトウェアセキュリティデザインレビューをするプロセスがなかったら、
その役割、名前がなかったらっていうのもあると思うし、
意外となんか、いや、先輩って感じがします。
先輩好きでしょ。
そうね、なんか、入り口はどう越えてもらってんのかな、このブロンズになって、
なんだろう、ブロンズになってそこからシルバーになってもらうみたいなところまでを入り口と捉えたときに、
こう、どうやって越えてもらってるのかね。
読んだくせに忘れたので今手元のソフトウェアデザイン好きっていう。
でもなんか一緒にレビュー中か、
人質反客でやるとか、課題持ち込んでもらってディスカッションするとかそういう話があった気がするんですけどね。
あ、これじゃねえか。
いやー、なんかさ、ソーターは特にそうだと思うんだけど、ずっとセキュリティ難しいわからんって言ってたじゃん。
うんうんうん。
結構その、
言ってた。
短期間でこう、そこの短期間かつある種片手間でそこの壁を越えてもらわなきゃいけないわけじゃん。
うん。
その10個のセキュリティデザインレビューをするまでの間に。
うん。
なんか、むずそうだなって思うわ。
まあでもそれで言うとなんか短期間とかじゃないんじゃないかなって気はするけどね。
なんかまあそこはグラデーションありそうというか、もともと興味があって自分で勉強してた人はまあいっぱいいるだろうし。
ああ、そうだね。
僕が個人的にいいなって思うのは多分、でもなんかそのミニマル理解やどな要件はないんだろうなって気はしてて。
そうだね。
セキュリティエンジニアの経験は当然いらないだろうし、っていうところは、だからなんかモチベーションだけあればきっといいんだよね。
うんうんうん。
まあそこはすごい。
確かにね。
一開発者としては嬉しい。
そういう形が会社にあるのはすごい嬉しいと思うけどね。
何がどう転んでもベースラインは上がるはずだよねっていう考え方に基づくと、なんかどう転んでもいい方向にはいくのかな、きっと。
そうだね。
まあ頑張って探してるけど。
P-SART、4つのうちのどれだろう。
でも今なんか目通しながら思い出してるけど、そもそもP-SARTもセキュリティデザインレビューをやったりとか、あとデザイン、セキュリティウィークリみたいな。
ウィークリで課題持ち寄って、なんか、何だろうな。
ディスカッションするみたいなのとかあるから。
だからそういうとこに参加してもらうとかなのかな。
うーん。
まあうちでいうと朝買いに出てもらうようになっちゃうんだよな。
あとあれだ。
ハーデニング、あれだね。新卒向けにハーデニングの研修とかをやってたりして、それをセキュリティチャンピオンズ向けにもたまにやってるよとか、
セキュリティに絞ったLT大会をやってたりとか、そういう結構いろいろ接点が多いんだね。
うーん。
あとはなんかこの、あれだね、新人、ちょっと若干中身読んじゃいますけど、
新人研修で今言ったハーデニングでボコボコにされて、
で、それを経て、なんかセキュリティチャンピオンズに、セキュリティに興味を持ってセキュリティチャンピオンズに、そこにで立候補する新児もいますっていうふうに書いてあるんですけど。
面白いですね。
そういうとこにも入り口があった。
やっぱ一度は自分が作ったものをボコボコにされる経験って必要なのかな。
うーん。
あるかないかで言ったらあったほうが絶対いいよね、普通に。
なんか4つの連戦のうち、多分今手が届かなかった、どっかにある1つにセキュリティチャンピオンズの話書いてる気がする。
まあまあ興味ある方はバックナンバーでぜひ買ってください。
あれか、4つ買うと6,000円くらいになっちゃいますけど、でも6,000円払う価値あるんじゃないかって個人的に思って。
いや、いいっすね。
いいっすね。
引き続き参考にさせてもらいますという気持ちです。
なんか、いやあ、いいなあ。
しみじみ。
いい話だなあ。
いやなんかさあ、うーん。
スタートアップにおけるセキュリティの課題とスケーラビリティ
なにを。
そうね。
いやなんかマネーできる面とマネーできない面が結構あるような気がしていて、その、なんて言ったらいいんだ。
なんかその、さあ、こう、その接点を増やそうみたいなのってなんか、まあ大事だし、やったほうがいいのは間違いないんだけど。
うん。
結構、結構エネルギーいるよなあって、割と思うところはあって。
なんか。
なんか。
ベルカリンの時にリンドク会とかもやったけどさ、なんかやっぱエネルギーがめちゃくちゃ持ってかれるんだよね。
なんかその域分岐点の話はある気がしてて、すごいドライに考えると、そのウリーさんだと結構な規模だと思うから、そうなった時にその中枢権的に分かる人が全部手を伸ばすっていうのはもう無理だよねみたいな。
うん。
だからその、接点を増やすとか、まあさっきのハーデニングの準備とかも多分死ぬほど大変だと思うんですよ。
そうなんだよ。
うん。
でもそういうのに対して、まあペーするみたいな、規模感というか。
だからペーするとこまで持っていったみたいな話でもあると思うし。
そうね。いやなんか、一方でさ、その組織の規模に対してはそうなんだろうなとは思いつつ、その組織の規模とは独立して事業の規模に対してどうなのみたいな話も多々あると思ってて、
その組織の規模は大きくならないけど、事業の規模は大きくなりますっていう状態になった時に、そのなんて言ったらいいんだろうな、なんかそもそも域分岐点がぶっ壊れるような気がしていて、なんか。
ぶっ壊れるっていうのは?
その、永遠にそこに至らない。
うーん、だそうね。
まあ、大枠で捉えちゃうと、その組織としてどれぐらいセキュリティ領域に対してアウトプットを出さなきゃいけないかみたいな話だよね。
で、それを実現する方法で、頭数が少ないパターンでどうするっていう話ね。
いやー、難しいね、なんか。
組織のサイズが小さいとさ、別にそもそも開発組織のサイズも小さいっていう話になるから、なんか。
アウトプットのケースがね。
事業自体は大きくなっていくよっていう中で、中央集権的にやるのはもう無理ですっていう。事業も複雑です、コードも大きいですっていう中で、でも開発組織も小さいし、セキュリティも小さいしっていう中で、
その域分岐点って何?みたいな感じになっちゃう気がするんだよな。
会社によると思うんだけど。
究極的にはもう会社主決になっちゃう気はするけどね。
出さなきゃいけないアウトプットに対してもう間に合えませんってなって、
例えば開発チームもパツパツでセキュリティチャンピオンみたいなのをやる協力がないですってなった時に、
起きることって事業の規模とか性質に対して必要なセキュリティ機能が満たされないっていう状態になるわけで、
それを許容するかどうかはもう何ていうか、それを定義付けするのはセキュリティチームの仕事だけど、
定義付けしたものを需要するかどうかは正直会社の意思決定次第になっちゃうかなっていう、
なんかめっちゃ残酷な考え方をするとそうなるのかなっていう。
まあでも一方で需要できないよな、現実的に。
そうだね、だから。
そうするとなんかそのスケーラビリティの捉え方そのものが結構、何て言ったら、変わってくるっていうか、
その何て言ったらいいんだろうな、中央集権的にできる部分をやらなきゃいけない部分をいかに圧縮するかみたいな話に多分なってきて、
まあまあ難しいね、なんか頭数が多いと結構その、なんか人の数が多いとさ、
まあある種その統制が聞きにくいみたいな話もあるから、
その一概に何て言ったらいいんだろう、なんかこう大きい小さいだけで語れるものでもないっていうのは確かにその通りなんだけど。
またその事業が大きかろうと小さかろうと、チームが小さければ目が届くよねというか、
口出しにいけるよねっていうので、あえて中央集権に留めるとかは考え方としてはありな気がしてて。
まあそうだね。
いずれにしてもその、まあなんかその、何だろう、事業大きいです、求められる要件高いです、でも間に合ってません、どうするみたいに何でに答えられたら、
まあ答えなきゃいけないのが僕らの立場なこともあると思うし。
そうだね、なんかスタートアップのインハウスのセキュリティチームっていう、なんか存在そのものが結構なんか変化が求められるような、なんか世の中になってきてるなあという気はしていて。
それは脅威が増してるっていう。
っていうのもあるし、そのいろんな要素が多分あって、その、まあなんていうか、こう、いろんな要素があるね、なんか。
必要なものが大きいところと別に変わらないよねみたいな話も当然あるし。
まあそれはそうだね。
っていうのもあるし。
なんか本質的には今までもそうだったと思うんだけど。
今、今人がまだあまりいないっていう状況において、なんかじゃあこの先人増やすの増やさないのみたいな話とかは多分組織によって様々あって、なんか。
めちゃくちゃ人増やしてるところもあるし、まあ割とそうでもないところもあるし。
でもなんか順番は逆な気はしてて、普通にその人を増やせない中でセキュリティどうするかじゃなくて、
その満たしたいセキュリティのラインを決めた上で、なんか人増やす必要があるかどうかが本当は正しい順番だと思うけどね。
で、会社として、まあどうするのっていう。
で、なんかそうなった時に、そのセキュリティ以外も同じことがあるはずで、まあ開発もここまで行きたくて、そのためにこれぐらい必要、QAもこれぐらい必要、デザインもこれぐらい必要って言って、
まあなんか基本的に多分足りるときはよほど事業は成功してないとこないと思うから、なんかいろんなバランス、会社全体でなんか何を、どの領域でそれぞれ何を成し遂げたいか見たときに、
じゃあちょっと、まあ例えばセキュリティはセキュリティよりちょっと開発優先しましょう、セキュリティはちょっともう間に合わないかもしれないけど頑張ってっていう風になるのか、まあそうじゃないよね。
で、まあ現実難しいのは、まあそこでじゃあセキュリティ3人取ろうとは、まあスタートアップではまあならんよねみたいな話は絶対あると思うから、
まあまあそこで苦しんでる同志がいっぱいいる、苦しんでって言い方ちょっと語弊があるんだけど、そのなんだろうな、まあやりくりすんならあかんよねみたいな部分は、
資本主義社会である以上は、あるっていうのはそうだねっていう感じなんだよね。
そうなんだよね。
なんかあまりにもやりくりが難しいよなっていう、なんか気持ちはありますね。
まあやっていくしかないですね。
AI時代のセキュリティ対策：CISベンチマークとCSPM
難しいとは、なんかもうちょっと、2、3年やってて思うけど、もうちょっとその、なんかスタートアップキットみたいなの欲しいなって思って、
なんかそのさ、こう、まあ専門性とか経験がないからっていうのは遠回りした部分はあるんですよ。
なんかその、とりあえずこれやっとこうみたいなやつが、なんかそんなになんかスタートアップ向けになんか体系立てられたものとかない気はしてて、
なんかそもそも体系立てられないものだと思いつつ、でもなんかもうちょっとやってもいいんじゃないって気はしていて、なんか難しいなというか、
例えばなんか脆弱性管理をするとか、エンドポイント管理をするとか、それぞれ強度があってみたいな。
で、それCISベンチマークじゃんとか言われたら、まあそうですねとしか言えないんだけど、
なんかその、なんだろうな、あれはじゃあスタートアップを考えて作られたかというと、なんかそうじゃないよなと思ってしまう自分がいる。
でもなんか別に理想形に対してどうしますかっていうのはその、各組織の判断でなされるべきであって、なんか。
まあね。
まあじゃあ何点取ればいいのっていうのはわかんないよね、正直ね。
そのCISベンチマークの各項目全部準拠しますっていうのを100点とした時に、じゃあうちは何点取ればいいんですかっていう、
なんかどうしても100点取らないといけないとしたら結構いろんなものを変えないといけなくて大変だけど、
なんかそこまでしてそこを100点に持っていく意味があるのみたいな判断とかは難しいよね。
その正解はないし、その。
そうなんだよね。
またなんかその2B、あれ、例えばベンチマークとかは2Bを示すだけであってさ、その。
うん。
Howは示さないとか、で、まあHowを示すようなガイドラインもあると思うけど、そのやっぱ抽象度をさ、高く留めざるを得ないというか、
うん。
なんか、じゃあそれ何でやるのみたいな、うちGitHub使ってます、Googleクラウド使ってます、どうやればいいですかみたいな部分に対する、
なんか回答って自分たちで探さなきゃいけないし。
うん。
まあね、なんかそういう部分にもうちょっとなんか補助性のある世界観でも嬉しいなという漠然とした思いがあるというか。
まあでもなんかあらゆるそのなんていうか、何かしらに対してもそのベストプラクティスみたいなのは、こう誰かしらが駆け起こして出してくれてるっていう気はするかな、なんか。
そうだな、範囲が広い。
まあ一個一個拾っていくしかないっていうのは多分あると思うけど。
例えばCSPMとかクラウドの設定ミスでいろいろ事故ってるぞ、まずいみたいな、でもちゃんとせなあかんみたいなCSPMっていうソリューションがあって、
まあここまでは分かるんだけどさ、じゃあCSPM何使うといいのってなった時にさ、まあ基本的にめっちゃいろいろ高いものがバーって並んでて、
で、蓋開けてみるとその中身はさ、根拠としてはCSベンチマークのこれでみたいな話があって、
で、その中にはその、いやこんないいわみたいなルールとかも正直企業によっては結構あったりするって中で、
だから100点のデフォルトのポリシーが来て、そこを回びくとこから始めちゃいけないとか、
まあでもなあ、なんか、いやスーパー札に言うともうちょっと楽させてよっていう気持ちと、
でもなんか知れば知るほど楽できる雰囲気でもないっていうなんか部分も今思ってるけど、
まあでもなんかそれを叶えてくれるのがなんかWeedsみたいなプロダクトなわけでしょ。
Weedsとかはそうだね、一つの回答になるかもね。
結局なんかお金がかかるよねっていうその、
そうだね。
中の人手がかかるのか、外に出した時にそのお金がかかるのかの多分二択でしかなくって、
そうだね。
そうするとじゃあ費用対効果で見た時にっていう話になってきちゃうんだけど、なんか。
あとあれだね、そのCSベンチマークとかも外出し多分できちゃうよね。
コンサルとかお願いしてとか。
だからなんか、いやー若干口に誰かにとって口に聞こえてしまったら申し訳ないんだけど、
例えばなんかそこに対してじゃあASMSやってたらまあスタートラインに立てんじゃねみたいな、
世界観だとすごいいいかなという気持ちも。
まあそれで言ったらなんかSOC2のType-2とかは結構それに近い世界観なんじゃない?
ああそうかもね。
ああいうなんか認証系で、
なんか今の忘れてくれって気持ちになってるけど、
まあまあまあまあその、はい。
まあそういうのも一つの回答かな。
なんか、いや難しい、難しいよな。
柔らかい。
なんかその費用対効果の測定みたいなのが多分一番難しいところでした。
どうしても訂正に寄っちゃうというか、
低流評価に寄せきれないっていう部分はなると思っていて、
結局じゃあなんていうか、
セキュリティ観点でこれが欲しいっていう、これが必要ですっていうものに対して、
会社として見た時に高く見えるのか安く見えるのかみたいな話になっちゃいがちな気もするんだよな。
なんかじゃあ、何て言ったらいいんだろう、
その、WiZ欲しいですって言って、
なんかそれぐらいなら出せるねっていう会社もあれば、
いや無理無理無理無理そんなの全然無理ですみたいな会社も当然あるわけじゃん。
また結局その議論に持ってくために人が必要っていうニヤ取り卵状態も全然ある。
訂正的な判断基準さえ生み出すことができないっていう状態も全然あると思うし、
じゃあ生み出すためにはセキュリティエンジニア、セキュリティ専任者が必要みたいな、
そこで堂々巡りしちゃうというか、必要性を認知できない。
専任者がいたとて、じゃあ手が回るのかっていうと、
どうなんだろうな、WiZあったとて、
それ見切れ、WiZの場合は思想がまた違うから、
それこそいろんなチームが自分たちで見てスキルさせるっていう方向にやってくれてるから、
手離れをするのかもしれないけど、
もうちょっと言いたいんじゃないかな、CSPMとかかな。
CSPMも難しいね、難しいわ。
手離れさせたとて、結局でもそれを各チームに対応してもらいましょうってなったときに、
各チーム側のコストはどうなるのみたいな話とかはやっぱり出てきちゃうのか。
僕の言いたかったこととしては、
そもそもなんかそのCSPMの議論にたどり着けない状態からスタートしてると結構むずいよなんていうか。
まあそうだね。
でもなんかそこはいつか誰かがぶつかるでしょ。
まあね。
その何かしらでいつか誰かがぶつかるよ。
まあまあ確かに。
いつか誰かがぶつかったときにどうするか次第ではあるけど、
別にほっといてもいつか誰かがぶつかるから、どんな組織であれね。
そうだね、それは確かに。
いや、セキュリティーは難しい.fmだな、完全に。
セキュリティーは難しいを言語化する回をお待ちしてます。
言語化を.fmのほうで。
こっちでやりたいな、さすがに。
別にこうやってもいいけど。
ちょっと漫画屋編で誰か呼んでやろう。
こっちで。
セキュリティーは難しい。言語化するサフィックス便利だな。
便利、めっちゃ便利。
ちょっとだいぶ悩ましい話になったけど、
フリーさんの背中を見てますというお気持ちだけ添えて、
次のページ行きますか。
行きましょうか。
はい。
AIエージェントとGoogleワークスペースの連携セキュリティ
これね、AIに会社のGoogleアカウントを渡していませんか。
Finatextのテックブログですね。
MCPathっていうのを別の記事で紹介してたんだよね。
これは多分このポッドキャストで紹介しなかったよね。
したっけ。
したかな。
したかな。
フワッとした。
なんかMCPGateみたいなやつ自体は割とあるあるなんだよな。
多分ね。
隠してるような気がするんだけど。
Finatextは内製したって感じかな。
AWSのソリューションを組み込んで内製したって感じかな。
今回はAIアジェントをGoogleワークスペースに接続するときに、
自分の権限をそのまま渡すんじゃなくて、
MCPathっていうMCPのゲートウェイ基盤にサービスアカウントのプールを持っておいて、
1ユーザー1SAでMCPごとにアジェントに渡すサービスアカウントを切り出して、
最小限のアクセススコープで渡すよみたいなことをやってるよっていう記事の紹介。
っていう取り組みの紹介の記事ですね。
細かいところは読んでくれっていう感じでいいのかな。
技術面で紹介しておきたいところとかある?
技術面は読んでくれだけど、仕様みたいなところで言うと、
アカウントを渡すだけじゃなくて、アカウントを渡すときにどれぐらいの権限を渡すかとか、
例えばGoogleドライブの権限を渡すときにGoogleドライブのこのファイルの権限だけ渡すみたいな、
結構細かいスコープを柔軟にできる仕様になってて、
ようやってるなというか、ここまでやれてるとかあんのかなってぐらい。
実際にはやってるっていうのはあるかもしれないけどね、もしかしたら。
結構ちゃんとやってるよなっていう。
実装しようと思うとちょっと頭痛くなる。
そんなことやってる?
なんかこの2のコンテキストの取り方みたいなところで、
これは選択肢の話でしょ?
そういうことか。
だから実態としてはそのサービスアカウントをドキュメントに、
ドキュメントのエディターとして招待すれば、
そのスプレッドシートの編集がそのエージェント経由でできるようになるよみたいなデザインとして。
だからこの範囲を明示的に渡すよっていうのを設定してるわけじゃなくて、
その都度そのサービスアカウントを招待する。
そのサービスアカウントに対してアクセス権を渡すっていう形で、
なんていうか、やってるっていう感じだよね。
大変失礼しました。
いやー、よく。
まあ、ようやってるっていう感じではあるけど、
なんか1ユーザー1SAっていうところはそのうち1ユーザーNSAになりそうだなっていう気はなんとなくしていて、
なんか結局そのやることが増えていくと、
その時間の経過とともにそのSAがアクセスできるスコープっていうのがどんどん広がっていかせたから、
なんか言おうとこってにSA立てたくねってなってくる気がするんだよな。
なんかユーザー側のちょっとリテラシーにも制御されちゃうよね。
そうだね。
結局自分のホームフォルダマルット渡すみたいなことやってたら意味ないもんね。
あとはそのなんかどういう時にSAを分けるべきかみたいな勘どころって結構難しそうな気がしてて。
権限もそうだね。
なんか例えばパッと思いつくとかと、そうだな。
クロードコードはこれぐらいの権限をここに渡したいけど、
まあでもローカルだとなんかもう1個でいいじゃんってか、
MCPだもんね。
MCPだしゲートウェア通してやってるから、
ローカルのそこには逆に言うと依存できないっていうか、
何で叩いているのであれ、MCPのゲートウェア通じてのアクセスになってるはずだから、
ゲートウェア側で何がアクセスしに来てるかっていうのを判別する手段があるんだったら。
まあそれで言うと意外となんか一日でずっと行けそうっちゃ行けそうな気がするな。
えー、本当かな。
左目してきそうな気がするけどな。
基本的にはさ、人間が何かを操作してMCPにアクセスするときを想定してるわけでしょ。
マシンユーザーとかじゃないから、
それともローカルから叩く以外あんまないんじゃないかなと思うけど。
で、ローカルから叩くときにローカルでわざわざ権限を分けたケースがあるかと言われるとどうだろうな。
権限を分けて、まさびさかんと分けたいって。あるかな。
うーん、なんか人によってはありそうだけどね。
その、なんか、こう、例えばだけど、まああんまりないような気がするけど、
例えばだけど、その採用とかさ、なんか。
あーくはないか。
採用ワークをしている人。
まあ、もっと言うと、じゃあ例えばだけど、
複数のポジションの採用の面倒を見ている。
それがメインの仕事ですっていう人が、
まあちょっと採用レーンとのごめんあんまりよくなかったな。
なんかちょっとなんとも言えないんだけど。
あ、でもなんかニュアンスはわかった。
そうそうそう。
そのコンテキストを完全に分離したいっていうさ、ユースケースは絶対あるはずで。
いやー、でも結構今時点だとやっぱ難しい気がするな。
例えばクロードで全部の業務をやっているときにさ、
クロードで接続するMCPの認証情報をいい感じに切り替えるとかそういうのを考えると、
なんか大抵の人はめんどくさくて、
ユーザー側が自分で複数欲しいって言い出すのは、
なんか相当意識高くないと。
うーん、しかもその切り替えが無理だよね。
そのこのMCPのゲートへの中でね。
そのうちでもユースケースとかニーズとしては、
1ユーザーで複数のSAを扱いたいっていうケースが絶対出てくるような気がしていて、
事実上そのユーザ権限を丸と渡しているのに近い状態になっちゃうみたいなのが、
状況としてそのうち発生しそうだなっていう気はするんだよね。
別にこれがダメっていう話じゃ全然ないんだけど、
今の時点で最適解なんだろうなと思いつつ、
なんかそのうちそういうのが出てきちゃいそうだなって思いながら読んでた。
なるほどね。
結局そのさ、ギターバップの、ギターバップがいっぱい生えてくる問題って一緒よ。
そうだね。
1個のクソデカいギターバップで色んなユースケースを満たそうとしてくると、
無理無理無理ってなってきて、
じゃあ複数のギターバップを生えそうとすると、
それも無理だわってなるっていうのって多分一緒で。
そうねー。
まあどこまでいっても人間よりは小さく済みそうな気はするけどね。
それはそうだね。
まあバランスとかが。
まあ2年後にどうなってますかって聞きに行きたい案件だね。
まあ1年後でもいいな。
これってなんかさっきのギターバップの例えをそのまま続けるとするならば、
そのOctoSTSでゆるゆるなルールが全リポジトリに設定されてるみたいな状態に近くって、
ちょっと違うな。
ちょっと違う。
まあでもそんな感じか。
まあでも割と近いような気はするな。
なんかこう難しいな。
なんかサービスアカウント分けても結局サービスアカウントにできる人間が変わんないから、
なんかやっぱ自分でオペミス防ぎたい以上のあんまニーズはない気がするよね。
確かにね。
OctoSTSとかさあくまでその人間を返さないところで最小権限を満たしましょうって話。
だからいい例えは思いつかないけど。
まあでもまあまああるはある気はするな。
いやあ何にせよあれですね。
まあ事業性質はあるにしても、
がっつりこういうのができるチームをちゃんと運用してるっていうのはなるほどなって感じですね。
こういうシステム作るのも面白そうだけど、
なんかメンテというか開発も大変そうだな。
うーん。
どんどんニーズが変わってくるというかさ、
そのなんかAI側の機能が変わっていくから。
まあしかもある日突然いらなくなる可能性あるしね。
そうだねそうだね。
なんかその技術としてこういろんなものが成熟していく中で自然といらなくなっていく可能性はあって、
でもじゃあいつそのコストを払いますかみたいな話でもあるし、
うーん難しいね。
しかもなんか結構なんか本当に難しいなって思うのは、
まあこれに関しては割と例えが良くて、
その使う側にとっても一定メリットがあるよねっていう話ではあるんだけど、
なんかうーん、
なんかぶっちゃけその使う側、大多数の使う側からしたら別に、
なんか知ったこっちゃねーよみたいな話でもあるような気はするんだよな。
まあこの辺は会社としてどうする、どうしてか。
しかも個人の感じ方にも結構依存しない。
自分の権限を全部渡すっていうこと自体に対してこう怖いなって思う人もいれば、
なんかまあ別にいいよねって思う人も多分いて。
それはそうだとは思うけど、
まあそこに対してなんかしわりをかけるかは結構、
だからそれこそセキュリティ文脈というか統制文脈でやるべき。
だからあれだよね、数あるセキュリティの有益の一つとしてどう取れるかみたいな。
やるやらで言ったら絶対やったほうがいいんだけどさ、
じゃあ誰がやるのってなった時に、
じゃあ使う側にこれ作ってくださいって、
なんか別に言えるけど、
言えるけどじゃあそれの重要度とか優先度ってどうなのってなった時に、
なんかぐぬぬってなっちゃうよね。
大半の企業ではあんまっていうのはあるかもね。
なんかそもそも結構でかい企業じゃないとペイしないみたいなのある気がしてて、
そのちっちゃいうちは気をつけましょうとか、
もう文面ノーションペライチでこのルールでやってねって、
まあ95%はいけるよねみたいな話もあると思うし、
わかんない、ちょっと想像だけど、
このfinitextの場合は事業性質上その100%は何かを満たさなきゃいけないっていう要件がある気がしてて、
その関差とか、
融資の際の消費とか。
間違いない、それはあるね。
そこはめちゃくちゃでかいんじゃないかなって気がする。
そういうのがあると、やんないって選択肢がないから、
何か起きた時に、ドライブにファイル盗まれましたって時に、
人間かAIか判断積みましたって、
済まされていい業界と済まされちゃいけない業界事業みたいな。
確かにね。
そういうとこもこう書けないのかな、書けないのかなって。
別の。
記事では紹介してるのかな。
続きものだから最初の方とかで、どっかでは元気あると思うけど。
あるかもね。
視差みたいなのがあって、その関差の観点とかでやっぱ組込みの、
毎回マネージドのやつだと足りないとか、
あと認可とかもやっぱやりきれないみたいなのがあったりする。
そういう部分はやっぱ。
確かに。
求める積極要件というか、統制の厳しさみたいなのがあるのかなって思って。
そうだね。
いやー厳しいよー。
なんかさっきも言ったけど、
なんて言ったらいいんだろう、
この課題を認識した時に取れる卓が今あまりに少ないと思っていて、
大きいところも小さいところも必要なものが別に変わらんって話をさっきしたと思うんだけど、
この課題に対して取り組みたいに何とかしたいって思った時に、
取れる卓があまりに少ない中で、
しんどいなっていう気持ちが出てきちゃうね。
できる範囲でやるしかないですよ。
これは結構やりきってるパターンだから、
前も全く同じこと言った気がするけど、
同じことをやるんだったら、
マネージャーのサービスポンって入れてスタートみたいな。
この領域だったら現実的かなって。
LLM領域はちょっと特殊だよね、正直。
そうだね。成熟度的にね。
まだ何かを判断する段階にないような気はしていて、
一方で一定リスクがあるっていう見方もしているので。
脳みそ破壊にしにきてる系。
パラダイムシフトとか。
頭抱えちゃう系ではあるよね。
もしくは内製主体、内製主体というか、
マネージャーの中をようやってるって感じですね。
一つのMプラレベルのMCP運用という文脈で、
参考にしてみてくださいって感じですね。
次行きますか。
行きましょう。
Claude Securityのパブリックベータ版とCodex Security
お願いします。
クロードセキュリティー イズナウインパブリックベータ。
クロードのアップデートのブログですかね。
皆さんもお目にしてるかもしれないですけど、
クロードセキュリティー、
多分プライベートベータだったのかな。
やつがパブリックベータになりましたよって話で、
これ何をしてくれるのかっていうと、
御社のセキュリティーコードをスキャンして脆弱性、
割と複雑なロジックの脆弱性とかも見つけてくれるよ
っていうものになってますって感じですね。
今はエンタープライズプランだけしか使えないんだけど、
コメントですけどね、
チームとかMaxでもいずれ使えるようにするよっていう。
書いてあったんだ。
うん、書いてあったはずですね。
来ましたねって感じですね。
さらっとですね。
前も話したのとあんまり別に内容は変わってなくて、
ただ前よりちょっとアップデートがあるとしたら、
プライベートベータで結局何千社とかでやってないっぽくて、
どっかに書いてあったかな。
数えられるぐらいですかね。
数えられるぐらいの会社でプライベートで試して、
結構いろいろフィードバックもらった上で、
良くしてるよっていう部分と、
その良くしたものに対して各企業の
割と有名な海外企業とかのコメントとかがあって、
ちゃんと業務に組み込めてワークしてるよみたいな話とか、
またこれの礎となってるモデル、
オーパス4.7ですか。
クロードセキュリティじゃなくて、
このモデル自体を各社のセキュリティ製品の裏側でも使っていて、
モデルも信頼できるものですよみたいな話が書いてあって、
割と説得力強めな感じで出してるっていうのが、
プライベートベートの発表との差分としてあるかなって感じですね。
とはいえ何せよ使えないんで、
僕はMaxplanに降りてきてないんで、
ちょっと使わせてくれっていうので待ちかなっていうことと、
あと値段かな。値段がよく分からんので。
別課金になるのかなこれ。
トークン課金になりそうだけど、
基本的には、
すごいゴリゴリにトークン削ってきそうやな。
YouTubeとかブログ読んだ感じだと、
多分このリポジトリでセキュリティスキャンしてみたいな感じでバーって使うから、
そういう使い方するとめちゃくちゃトークン食うと思うし、
またディレクトリー絞ってスキャンみたいなのできるっぽくて、
使い方次第っていう部分もあるかなと思うけど、
どうなんでしょうって感じですね。
あとあれだね、それぐらいかな。
なんでみなさん、
正座して待ちましょうって感じですね。
エンプラプランを仕事で使われてる方は是非、
感想世に出してくれって感じですけど。
Codex Securityは実はちょろっと見たんだけど、
レポートのフォーマットは良かった。
内容は?
内容は、それは分かってんだけどさって感じだったな。
それは分かってんだけどさ問題は、
突きついてもありそうだね。
Codex Securityは過去に検出したやつは、
コンテキスト残してメタ情報残しとけよ、
みたいなのあった気がするな。
その取り味済みのやつとか、
だからフィードバックで一発チェックしておしまいじゃなくて、
コンティニュアルにずっと回し続けたいみたいな部分に対して、
検出項目に対してこういう理由で却下みたいなのをできる機能とかがあって、
そういうのがあると、
別の人がスキャン回して同じ結果が出た時に、
その記録が見れるとか、
アプリケーションとしての機能なのかな、
あるっぽいからそこはぜひ触らせてくれって感じですね。
ちょっと使ってみないと本当にやばいな。
待ちましょうって感じですね。
Codex Securityも結構良かったけどな。
徐々に良くなっていくのが既定路線ではあるんだけどね。
Codex Securityの場合は、
このコミットでこれがもたらせましたよっていう出し方をしてくるんだよね。
それめっちゃいいね、助かるな。めちゃくちゃ嬉しいです。
開発に密に連携してくれるところを僕らは求めてるよね。
ショップのスキャンを回してレポートを出しますっていうスタイルではそもそもないから、
ずっとコードベースを見ててくれて、
このコミットでこういう問題がもたらされました、どうですかっていうのを出してくれるっていうのは普通にありがたい。
一方で、何て言ったらいいんだろうな、
意図通りの変更に対して文句をつけてくるみたいなのが結構目立ったので、
それ分かってたけど気持ちにちょっとあったっていう。
結構そういう部分の永続的なコンテキストというか、
そういう部分が大事になってくるっていうか、
そこで差別化とか機能改善が進むのかもしれない。
だけどその永続的なコンテキストが必要になるケースはでも割と稀なような気がするし、
ちょっと具体例を出せないのが非常に申し訳ないっていうか歯がゆいんだけど。
例えばだけど、使用上カスタムのHTTPヘッダーがあって、
それに結構10種類ぐらいの値を入れると何かの挙動が変わるみたいなのがあったときに、
これ危ないぞみたいなのとか、
そういうのはもう使用上今は許容してますとか、
あとはレガシーシステムから新しいシステムのマイグレーション中で、
その関係でレガシーシステム側で修正しないって決めた、
ちょっとミドルぐらいのものがあったときに、
それはこういう理由でもう直しませんっていう意思決定をしたときに、
それをどんな形でもいいんだけど残しておいて、
次回スキャン時にはアラートとしては上げないみたいなのがあるとうれしいかなっていう。
それがないとスナップショットで回して毎回取り味済みのやつを出されても、
それは間違いなくそうですね。
そういう実運用に寄り添った気の利いたものにみんな各社になっていってくれると、
嬉しいなって気はしますね。
1週間リシステムみたいな部分をどう組み合わせるかが結構疑問になると思うんだけど、
確かにね。
コーデクシティーはそこまではちょっとまだ見えてなかったかな。
大事だね、トロッキング。
1週間じゃ直せないものを、1週間に1回スキャンしたときに1週間じゃ直せないものが出てきたときに、
ずっと出続けるとかありそうだもんね。
それで言うと、このコミットでこういう問題がもたらされましたよっていうフォーマットで出してくれる分には、
その問題はそもそも生じないのよ。
確かに、コミットに紐付けちゃえば。
ある時点からこの問題がありますよっていう、ただそれだけなので。
確かにね。
クロードセキュリティがどういう感じなのかちょっと分かんないんだけど。
早くマックスまで下ろしてほしい。
お願いします。
お願いします。
じゃあ、次行きますか。
全然話変わるんだけどさ、
趣味のコーディングにおけるセキュリティレビュー
ごめん、話が戻るんだけど。
そこそこデカくなった、デカいコードベースを作らせたときの、
セキュリティレビューみたいなのどうしてる?
主に趣味のコーディングの、趣味のViveコーディングの話で。
全体のセキュリティレビューってこと?
どのタイミングでやらせてる?
マイプルディックセルフレビューさせてるかも。
品質レビューと、
プリリック立てるときにそういうスキルにしてる。
プリリック立てて、
そのプリリックに対してセルフで品質レビューとセキュリティレビューをさせて、
コメント投稿させて、
そのコメントを俺が人力で見て、
これとこれとこれは直してっていうので回してるかな。
なるほどね。
なんかそういう記事あったよな、今日。
ちょっと後で楽しみにしとく。
いやなんか、まだ記事にしてないんだけど、
オレオレオクトSTSみたいなの最近作って、
とりあえず一旦ローカルで動画化しておいて、
一旦そこからギターバップトークンを取ってきて、
使えるっていう状態にまずしたいなと思って、
超ゆるーく一旦ギターバップトークンが降ってくるっていう状態。
実装して、でそっから肉付けしていくっていう進め方をしたんだけど、
なんかまぁ大変だったのよ、後でレビューするのが。
なるほどね。
そう、パブリックにするまでに結構かかったし、
なんかなかなか難しいなーって思いながらやってたんだけど。
まだなんかあまりに趣味のものすぎて、
あんまりカッチリやれてないかどうか。
なんか普通にさパブリックリポジトリに置いてるから、
なんか私のギターバップがなんか、
まぁそこに脆弱性があって、
そのオレオレオクトSTSの権限が持ってかれると非常にまずいわけですよ。
マジで脆弱性あったら困るやつを作るって体験はしてないから。
そこそこ困るやつを作って後悔してるから。
なんか基本はもう前段で押さえちゃうのが一番理想論としては、
なんか前段で押さえないとあいつらその既存コードどんどん真似るから、
そういう意味でも負のふくりが効かないように、
まぁそういう記事があるんで。
コードのサイズとしてはそんなに大きくないんだよね。
そういう記事もあるのでお楽しみということで。
次行きましょう。
次行きましょう。
また後で話しましょうこの話は。
犯罪サービスにおけるクレジットカード情報漏洩事件
次は軽めの記事なんですけど、
スキャマーズバイブコードサーバーとベリファイストルーンクレジットカーズ、
リークディテールソフト345Kカーズ、
サイバーニュースっていう普段読んでないメディアなんですけど、
たまたま拾ってきた記事で、
なんかちょっと面白記事なんでシュッと終われる感じなんですけど、
何でしょう、話したか話してないか分かんないけど、
バイブコーディングとかエコーディングっていう概念が出てきたときに、
概念著書としてはあいつらは脆弱な行動を吐き出すので気をつけなあかんっていう話が散々あったけど、
それによってめちゃくちゃクレジットカード番号が漏えいしたぞっていう記事の見出しを見かけて、
とうとう来たかって思って読んだら、
漏えいしたのは、
犯罪者ですね、犯罪者が運営してる犯罪者向けのクレジットカードを、
クレカ番号の検証する犯罪サービスがあって、
何かというと裏側ではAmazonとかに対してクレカ登録して、
クレジットマスター攻撃だけちょっと、
なんかそんな感じのやつだよね。
番号が有効か調べるってやつを簡単にできるサービスを攻撃しか運営してたんだけど、
それをクロードコードで書いてて、
脆弱性があってクレジットカードがもうただ漏れになってたっていう事件がありましてって感じですね。
おもろい。
被害者はいるというか、
でももともと漏えいしたクレジットカード番号を犯罪者が保持してて、
それがさらに漏れちゃったって話で、
そっち側で先に起きるんだというか、
今思ったけどもしかしたら起きる武器をして起きたのかもね。
まともな事業者はこういうことが起きないように色々頑張ってるけど、
攻撃者側はもしかしたらノリで作ってるのかなと。
まあそうね。
何でクロードコードで作ったか分かったかっていうと、
そのコードベース見た時にそういう挙動というか特徴みたいなのがあって、
おもろいね。
それで漏えいしたっぽいね。
おもろって。
さらっと紹介した感じですね。
結構ね、そうそうたる情報が漏えいしちゃってる。
あれコードベース自体も脆弱性とかで漏れちゃったってこと?
なのかな。
JSとかクライアントサイドのコードを見てとかなのかな。
もしかしたらそれか。
なんかダッシュボードみたいなのがあったんだけど、
そのダッシュボードが典型的な人のダッシュボードも見れちゃうみたいなやつ。
ごめん、クロードコードじゃない、カーソルだ。
カーソルなんですね。
なんか分かんないけどカーソルのチャット履歴みたいなのがどっかに入ってたのかな。
何もかも漏れてるような感じ。
カーソルの方が、カーソルが人気なんですかね。
その手の、その筋の人たちには。
記事ではカーソルがそもそもこんなサービス作るのを支援してたのが事実なのかどうかみたいな、
カーソルに問い合わされてるみたいなことが記事中であって、
これはちょっと意地悪な言い方だなと思いつつ。
だって別にカーソルが支援してなかろうがどうだろうが、
別にどっかで漏れたAPIキー使えばいいだけでしょ。
そんなことないのか、カーソルの場合。
このサービス自体は違法性があるものだけど、それをなんか。
通せちゃったってことだよね。
モデル側の責任なのか、カーソル側の責任なのかちょっとなんとも言えんけど。
なんとも言えない。
まあね、そんないくらでもバイパスできちゃうからね、きっとね。
これはそう。
こっちが先かっていう気持ちと、
まあでも今なんか喋ってて自己解決したけど、
まともな企業では同じことは、
それこそクレーカー番号扱ってるような企業では起きないだろうなと思ったりしたけど。
うっかりさんだなって思って。
うっかりさんですね。
まあ漏れた側はたまっとるんじゃないですけどね、そのカードの持ち主とか。
まあでも別にここに入れられてる時点で漏れてはいるわけでしょ。
そうだね、それはそう。
なんか誰に漏れるかの違いでしかない感じだけど。
またなんかこういうサービスがあるんだなっていうのは知らなかったんで。
まあいろいろあるなって感じですね。
小額決済。
はい。
じゃあ、
次。あ、まあ次もさらっとで。
さらっと系が続きますが。
次はグローバルAIセキュリティスタンダードオーガニゼーションギャザルアンダーモザイクトゥリデュースフラグメンティションっていうこれは何の記事だ?
AIセキュリティ標準化団体「モザイク」の設立
グローバルニュースワイヤー。
まあなんか海外のメディアの記事ですね。
どういう記事かっていうと、
具体的には結構早々たるさまざまなセキュリティ団体が合同でモザイクっていう団体を立ち上げましたよって話ですね。
早々たるメンバーっていうのはWASPとかNISTとかCSA、CISあたりがよく聞く名前かなと思うんですけど、
その辺りで構成されてます。
団体が何かっていうと、セセアイ関連のセキュリティ方面のいろんな標準とかベストプラクティスを定めていく団体っていう感じですね。
なんでこれをわざわざ作ったかで言うと、今時点でもセセアイ関連で例えばモデルを作るときにこういうの気をつけましょうとか、
そのAIエージェントをシステムに組み込むときにこういうとこ気をつけましょうとか。
なんかWASP LLMトップ10とかWASPエージェンティックAIトップ10とかありますけど、
ああいうものがいろんな団体からサミナリにいろいろ出てますよとなったときに、
各団体でそれぞれ考えて頑張って作るの普通に無駄じゃねっていうので、
さっき言ったような団体のメンバー集めて一緒にやっていきましょうっていうために作られた団体っていう感じですね。
なんで課題意識がよく分かるなという気持ちと、ここからいろいろちゃんとワークして出てくれると、
僕らとしてはまずこのリファレンス見ましょうみたいなものができてくると嬉しいなという気持ちがあります。
なんかいいけど、別にAIに限った話はなくないってちょっと思っちゃってそんな。
まあそれは、まあそうね。でもなんかウェブ、まあそうか、それはそうかもね。
あとなんか全然関係ないんだけど、なんかOWASPってさ、オープンウェブアプリケーションセキュリティープロジェクトだったよなと思ってたんだけど、
名前変わったんだね、いつの間にかね。
あ、そうなんだ。
いつ変わったんだろう。あ、2023年なんだ。
ワールドワイドアプリケーションセキュリティープロジェクト。
知らなかった。全然そのウェブ以外もいっぱいやってるよなーってずっと密かに気になってたんだけど、今初めて知りました。
ウェブっていうのを知らなかった。
そうなんだよ。ウェブのイメージが強くて、個人的に。
最近全然ウェブに限った話じゃない分もやってるからさ。
何なら検索したら出てきたFortinetとかOpen Web App、古いままやな。
最近だね。
全部そうであるんだけど、AI関連はちょっとよく分かんないなと思ってたけど、結構スタンダードになってくれると嬉しいなって思うけど。
このFMでいろいろいろんなもんポンポン出てきて、いろいろ読んでどれも良さそうだなって感じだったけど、
いざ向き合わなきゃいけないときに何引っ張ろうってなったときに結構迷ってしまうというか、
全部メートスはめになりそうだなって思ってたから。
じゃあ次お願いしようかしら。
Money ForwardのGitHub不正アクセス事件と対応
GitHubへの不正アクセス発生及び銀行交差連携機能の一時停止に関するお知らせという、
わりと騒ぎになっているMoney Forwardのニュースリリース、サポートサイトの重要なお知らせなんだね。
そもそもニュースリリースも別であってというような感じなんだけど、
この事故についてという感じかな。
そんなに別に俺自体に関してどうこうはないんだけど、
GitHubに個人情報が載ってた云々観音でめっちゃ騒ぎになってて、
消せないよねみたいなことを言ってる人もいたんだけど、
実は消せるよっていう話をメルカリがブログ記事にしてくれていて大変ありがたいんですが、
何かの時に必要になるかもしれないんで知っておいてねっていうのでピックしておきたかったのと、
漏れちゃった内容はともかくとして、
いつもの何がやられちゃったんだろうねシリーズなんだけど、漏れちゃった内容はともかくとして影響範囲が割と小さいなって思っていて、
アクションズの侵害なのかなとか思ってたんだけど、
でも書きっぷりからするとよう分からんな、断定できないなと思いながら読んでいて、
立法のリードだけ付いたPATっていう可能性もありそうだけど、
でもそうすると例えばエンドポイントから漏れましたってなったら、
もうちょっと影響範囲広くなりそうだなと思うし、
アクションズでコンテンツリードが付いてたgithub.tokenが漏れましたとかのほうがまだすっきり腹落ちする気もするし、
よう分からんなっていう感じで読んでました。
確かにエンドポイントの話を思うとアクションズ侵害とか…
ぽいよね。
リードだけ取れて、ワークロードは全然ないからソースコードしか利害にはなかった。
チェックアウトしてるソースコードだけ漏れましたとか、
そうすると認証データが漏れましたっていうのもちょっと違和感ある。
認証情報が漏れましたっていうのにもちょっと違和感あるし、
言い回しはね、
でもなんかむずいよな、
2Cサービスだから結構そういう言い回しにしてるとか普通にありえそう。
厳密には認証情報と言ってもいい気がするしね。
例えばgithub.tokenとか漏れとか。
そうだね。
でもチェックアウトしてたソースコードを外に持ち出されましただったら別に認証情報じゃねえしなとは思うし、
まあちょっとなんとも言えない、どういう経緯で何が漏れてそうなったのかはわかんない。
だいたいコンテンツリーダー、チェックアウトしてる時点でコンテンツリーダーついてるから、
github.tokenが漏れたっていうところも含めてそういう書き方をしてるのかもしれないし、ちょっとわかんないけど。
こっちか、プレスリリース。
そうそう、プレスリリースの発送。
認証情報から漏れるし。
そうだね。
まあなんとも言えんですね。
認証情報の無効化及びアカウントの下段。
まあだからこういう表現だとやっぱ人にひも付くなんかっぽいなと思うんで。
まあアカウントって書いてるのか。
だからそうするとPATなのかな、やっぱり。
PATとか、あとオーストークンもあるんじゃないかな。
あるね、確かに。
誰かの。
まあないとは思うけど、オースアプリを管理者承認性にしてなくて、変なやつが増えちゃったとか。
それはあるかもね、確かに。
PATもですかね、そんなとこかな。
PATかオース連携、ミスか。
まああインフォスティーラーの線もなくはないんじゃないけど。
それだともうちょっと派手にやられそう。
そうなんだよ、そうそうそう。
オースにしてもさ、もうちょっと派手にやられそうな気はせんでもないんだけど。
どうなんだろうな。
新しく連携して侵害だったらコンテンツリードはしょっぱい気がするけど、
既存のやつでサードパーティーが侵害されてとか、
で、とりあえずそれに気づいて塞いで今必死に操作中とかだったら、
なくはないか。
なんかコンテンツリードはさ、もう結構どれでも渡しちゃうからさ。
一個侵害されたらアウトみたいなのは全然。
ありえはしそうな気がするな。
なんか結構セキュリティ周りちゃんと投資してる会社だとは思うし、
コストモーティブというか詳細な原因を。
ちょっと気になるよね、出てくれると嬉しいなって。
これ結局認証情報の洗い替えしてるって書いてあるから、
何してるんだろうね。
API連携してるところは全部クライアントシークレットとかを
再発行して回ってるっていう感じなのかな。
だから止めてんの。
なのかな。
でも概ね完了してますって書いてあるよね。
誰かがXで言ってたんだけど、
何らかの期間から送られが発生して再開できないんじゃないみたいなことを言ってる人がいて、
確かにその線もありそうだなと思いながら言ってたんだけど。
ありそうだね。
大丈夫だっていうことを証明するのってすごい難しいと思うから。
難しい。
だからそれに時間取られてとか普通にありえそうな気はするけどね。
いやー、なかなか扱ってるものがものだけに結構、
中の人はめちゃくちゃ大変な思いをしてるんだろうなと思いますけど。
なんか工学のためにいろいろ言える範囲に行ってもらえると嬉しいなっていう。
温かい目で見てます。
気になりますね。
なんか日本もこういうのなんかちらほら出てるって始めた感じがするね。
まあね。
そのなんかランサムとか、
その委託先のシステムを、
委託先を買いしてサプライチェーンで侵害とかはなんかあった気がするけど、
なんかアカウント本丸ポンって侵害されて社内まで入られちゃいましたみたいな。
少なくともこのFMやってからそんなにはなかった気はしてて。
国内はそんなにない気がするね、確かに。
立て続けたもんね、最近ね。
そうそうそうそう。
結構、
さっきのその脅威が増してるみたいな話じゃないけど。
なんていうか、机上の空論じゃねえぞみたいなところは、
肌で感じつつある恐怖のものって感じがしますね。
そうするものがさ、どこの会社でも一緒だから、
特性として、なんていうか、
別に規模関係なくみんなやられるっていう中で、
大きいところはちゃんとしてるけど、
ちょっと言い方語弊あるけど、
大きいところはちゃんとしてるけど小さいところはちゃんとしてないってなったときに、
結局小さいところがやっぱやられて目立つみたいなのは普通にありそうな気がするから、
むしろ余計にやばいみたいなのはあるのかもね、傾向としてはね。
わからんけど。
というか、マネーフォーがやられちゃったんなら他もやられるよみたいな考え方もできると思うんでしょ。
めっちゃ本当に申し訳ないけど、
ITを種の成り割としてない中小企業とかも日々無限に何ていうか、
記事が流れてくるというかさ、
でもそういうのって多分運用してるワードプレイストのプラグインの脆弱性があってとか、
そういうのはわかるじゃないけど、あってはならないけど、
でも別にマネーフォードはそういう会社じゃないと思うし、
キャンプファイヤーとかもそういう会社じゃないと思うし、
システム詳しいメンバーが集まってシステム運営してるみたいなところはやられてる結構。
違うよねっていう。
なんで?
そうだね、私。
ちっちゃかったら狙わないよとかではないのは間違いないので。
そうだね。
ちょっと中身が気になるな。
待ちましょう。めちゃくちゃ大変だと思うんで今。
ありがとうございます。
じゃあ次は私からさらっと紹介なんですけど、
ElasticのOSS「Abuse Detector」によるCI/CDセキュリティ
リンクはGitHubのリンクなんですけど、
エラスティックのCICでアビューズディテクターっていうOSSのご紹介ですね。
これを紹介している記事を後おいで見つけて、
そっちをぜひ興味のある方は読んでもらえればなって感じなんですけど、
どういうものかっていうと、
インターバクションズのワークフローファイルを加わせると、
脆弱な設定みたいなのをLLMを用いて結構動的に検出してくれるOSSっていう感じですね。
従来のJHLintとかActionLintとかJISMOで、
またGitHub Advanced Securityとかでも、
そのGitHub Actionsのリスキーな設定とか不備っていろいろ見つけられるんですけど、
一方で例えばオンプレリクエストターゲット使ってて、
保護されてないファイルをチェックアウトしてるみたいな、
直近めちゃくちゃやられてる、実は脆弱な設定みたいなのを今言ったツールで見抜けるかっていうと、
見抜くのが難しいっていうのが現状。
っていうのはそもそもロジックに落とし込みづらいというか、
ルールベースではなくなっているものなんですけど、
これはモデル、LLMを動かすことによって、
こういうふうにやったら刺さっちゃうよみたいなものも、
いい感じに検出してくれるものを作りましたよって話ですね。
直近シャイフラットとかNXとかいろいろやられまくったもので、
実際に脆弱だったワークフローみたいなのをテストケースとして使って、
そういうものも全部検出できてみたいなことを書いたっていうのは、
それは結構面白いなって個人的には思ったんでちょろっと紹介という感じですね。
技術的な詳細なことは結構いろいろ書いてあるんですけど、
なので興味ある方は読んでくださいって感じですけど、
こういうものとかこういうアプローチもアリなのかっていうので、
あとOSSにしてくれたり、
勉強になりそうだなっていうのをご紹介っていう感じなのと、
あとは良さそうと思った一方で、
これを脅威が移り変わっていく中で、
メンテし続けるの普通にしんどそうだなって気はしてて、
これはあくまでエラスティックでやってみたものをOSSにしてくれたみたいな感じだから、
正式なサービスではないし、
メンテするかと言われるとそんなしないかもなと思って、
もしこれを使いたいって方は自分でちょっと面倒見ていくコストはかかるのかなって思いつつって感じです。
なんか…
なんか概念実証としては個人的には面白いかなとは思うけどね。
LLMじゃないと検出できないみたいな部分、
まあできたよっていう部分があるから。
まあね。
まあこういうのが本格的に回りだすと多分イタチゴッカー始まっちゃう感じはするけど、
LLMである以上は。
まあね。
なになになに?
いやなんか分からんけど、価値の残り続けるソフトウェアなのかどうなのかっていうので、
どうなんだろうなーって思いながら見てた。
まあこれ今から使いましょうってものではないとは思うかな。
あくまでPOCとして捉えるぐらいがいいと思いつつ、
仮にこれを今必要ですっていうふうに判断したとして、
1年後もこれが必要かって言われるとどうかなって思っちゃうんだよな。
まあ分かんないね。
分かんないけど、でもじゃあ1年経ったら、
なんだろうな、
今GHLint、ActionLintみたいな、
従来のルールベースのツールで見つけられない脆弱性が見つけられるようになるかと言われるとそうじゃないと思うから、
まあ価値はあるとは思うけどね。
まあでもコパイロットとかが勝手に見つけてくれる世界もあるのかなと思って。
まあそういうのはありだとは思う。
ただこれは例えば、
OSSの場合とかだとプリリクエストを誰か立ててきたときに、
それに対して回して、
NCだったらブロックするみたいなことができるから、
ああ、そういうことか。そこまでやってくれるのか。
やってくれるというか、
そういうふうに、
これじゃあGitHub Actionsで動かせるから、
そういうような作りにするとかは多分。
なんかそんなことしてくれよみたいな。
そういうこともできるよみたいなことが記事には書いてあると。
でもプリリクエストターゲットってさ、
回ろうが回るまいが関係ないですみたいな世界もあるわけじゃんね。
まあもともと脆弱したパターンはあるか。
まあ一定、そうだよね。一定そのレベルを高めた後で。
例えばそのコパイロットとかやってくれればいいじゃんは真なんだけど、
例えば開発者が複数にいてOSSでコンティビューションがたくさんある中で、
みんながそういうものを使ってるわけじゃないとか、
みんながその手元でセキュリティレビューを回してるわけじゃないっていう前提において、
だからなんか品質保証のためのCIとしてこれを実行するっていう世界はあるんじゃないかな。
まあこれないしはこれみたいな。
いやあ、そうね。
なんか理解はするんだけど、
魅力はあんま感じないみたいな。
まあね。
でも、
そのなんかあくまでエコシステムの外から、
あんまりインテグレートされてない状態で回りますよっていう形であることには変わりがないから、
なんか現時点で一定価値はあるんだろうなとは思いつつ。
極力やってることはクラウドコードアクション回してセキュリティレビューしてるだけではあると思うから、
それのプロンプトとかロジックを結構作り込んでるっていうものであると思うから。
だからなんか、
でも精度上げていこうと思った時にこういう形になるって話ではあると思うけどな。
まあね、そりゃそうだね。
なんかペライチのプロンプト1枚でやりきれない部分を、
ちょっとちゃんと見てないけど結構ね、作り込まれてる感じはするんだよね。
まあちょっとこれも使ってみないとなんとも言えんか。
なんか使うんなら自分でメンテしなきゃいけないかなって思うのと、
できるよっていう部分の価値としてはありなんじゃないかって気がするって感じかな。
あとはこういうのいろいろ全般やってくれるやつが既にありそうだけど、
サービスとして売られるとか普通にありそうだけどね。
はい、まあ興味ある方はずっと見てみてください。
まあ使ってみてくださいっていう感じですかね。
コードも見れるんで。
確かにね、どっちかっていうとなんかコードのほうが、
プロンプトとかのほうが参考になるかもね。
まあそういう部分だけ真似するか全然ありかな。
はい。
GitHubプッシュパイプラインの脆弱性と修正
じゃあ次。
いきましょう。
GitHubのブログで、
Securing the Bigit Push Pipeline Responding to aCritical Remote Code Execution Prior to BT
というGitHubの記事ですね。
多分話題になってたのかわからない。
めっちゃなってたね。
なってた、まあさすがにそうか。
GitHubのプッシュ周りに脆弱性があって2コード実行ができちゃうバグがあって、
まあそれを修正しましょうって話ですね。
本期のGitHubはもう修正されてて攻撃の兆候もないんで心配いなくて、
エンタープレイスサーバー、
オンプレイサーバーの人たちは自分でアップデートしなきゃいけないんで、
まあ大丈夫だと思うけど万が一まだの方はやってくださいって感じなんですけど、
まあそのGitHubのブログと合わせてWizがこれ見つけて報告しちゃったんですけど、
Wiz側からも解説ブログが出て、
まあそっちの方が詳しく書いてあったんで色々読んで、
どういうことだったんだろうと思って読んだんですけど、
まあ割となんかありそうって感じの、
まあしさがある感じの議員だったんでふわっと紹介できるわって感じで、
どういう脆弱性だったかっていうのをめっちゃ超ざっくり、
本当に超ざっくりさまると、
GitHubでプッシュされた時に、
まあそのプッシュのエンドポイントも当然あるわけですけど、
プッシュされて、
まあ中で色んなGitHub内で色んなシステムが動いてて、
その分散システム的にプッシュしたペロードがポンポンポンって処理されていくんだけど、
その処理されていくインターナルなサービスの一部で、
特定のヘッダーを無条件に信頼していたっていうのが挙動としてあって、
で無条件信頼っていうのは具体的にどういうことかっていうと、
そのヘッダーの使用として、
緩膜切りでキーバリューを突っ込むっていう、
まあよくありそうなhttpヘッダーが想定されてたんですけど、
このキーバリュー自体が後勝ちの仕組みになっていて、
同じキーで複数の値があった場合は後勝ちになっていたっていう話と、
もう一つは、
この本来は多分内部でしか使用されないみたいな想定で、
無条件信頼されてた値を、
外部からGitプッシュするときに、
-オプションを付けると2位の値を突っ込めたかつ、
その値がそこにたどり着くまでのどの過程でも検証されないっていう状態になっていて、
なんでその内部システムの特定のヘッダーのキーバリューを、
まず外から分けできるっていう状態になっていて、
その上で、そこで指定できるキーバリューのうち、
3つの特定のオプションを組み合わせると、
リモートコードエグゾケーションが発出したっていうのが、
超ざっくり言うと起きてたことっていう感じですね。
これ、どうやって見つけたのかと思ったんですけど、
なるほどなって思ったんだけど、
GitHub Enterprise Serverで最初見つけたらしいんですよね。
っていうのも多分オンプレだから、
ある程度自分たちでいろいろ見れるから、
そこで試して見つけて、
その後GitHub側でも再現したら、
微妙に再現条件は違ったんだけど、
基本的な原理は同じで再現できましたよっていうのが、
分かって報告に至りましたっていう感じですと。
物としてはかなり危なくて、
GitHubとかそのテナント、
多分その内部システムが刺さっちゃった、
内部システムとかなのかな、
テナントが縦で区切られてなかったっていう部分があって、
テナントをまたげちゃうっていうものだったんで、
本当にかなり危険なものだったっていう感じっぽいっていうのと、
あとなんか示唆というか反省、
GitHubブログの反省みたいなところで言うと、
内部システム、内部でしか動かない、
外部に露出しないシステムが故に、
値の検証みたいなのをちゃんとやれてなかったものが、
そのままずっと放置されてたっていう部分に
刺さっちゃったみたいな部分があって、
なんでここはある種のゼロトラスト的な考えじゃないけど、
多層防御で、
どこで値を、内部システムだっても入ってくる値をきちんと検証するみたいなのを
ちゃんとやんないといけないし、
そういう修正をしましたよっていうことが
GitHubのブログではさらっと触れられていたっていう感じですね。
なんで蓋を開けると結構ありそうだなっていう気持ちで眺めたというか、
面白いね。
結構、なるほどなっていう気持ちになって読みましたって感じですね。
これVizのリンク貼ってないな、ありますわ。
ちなみにその3つの値みたいな部分は気になる方は読んでください。
もうあんまり中の話すぎてちょっとそんなにちゃんと読み込んでないんですけど、
だいぶこみ入った仕様というか、感じになってましたね。
あとGitのオプションでGitHubになってツッコミっていうのも結構あんまり直感的じゃないというか、
思った感じですけど、この辺はそんなに詳しくないです。
でもGitのリポジトリのホスティングっていう意味で言うと、
Gitの何かで2コード実行が刺さるっていうのはある意味、
口としてはよくある話かなとは思うな。
ありがちというかありそうっていう意味ではね。
確かにね。
そうだね、結構かなり詳しく。
いやー、そうだそうだ。
レール全部みたいな値とかをある値入れるとサンドボックスはバイパスできてとかいろいろ。
だから3つぐらい組み合わせてるんだよね。
パストラバーサルしてリダイレクトして。
面白い。
そう、面白い。よう見つけたなって感じ。
バウンティーいくらだったんだろうな。
いくらだったんだろう。
これさ、仕事中に見つけたのかな。
なんだろうね、ずっと探し続けてるチームとかあんのかな。
あるかもね、ウィズの前あるかもね、確かに。
各社めっちゃ、ようそんなん見つけたなって結構見つける。
大学的にたまに出てくるよね。
バウンティー出て誰がもらうんだろうね。
でも仕事で見つけたなら会社になっちゃうのかな。
ボーナス出るかもしれないけど。
インセンティブとかで還元されるのかもしれないけど。
まあすごいしょうもない話だけど。
昔から結構気になってて。
仕事中になんか見つけちゃったらどうなるんだろうなって。
ウィズの記事にはバイネームでチームメンバーのアカウント全部入ってあるから。
このメンバーで見つけましたってことなのかな。
リサーチチームってあるみたいですね。
張り付いて探してるのかな。
ディープシークかなんかのデータベースの質問見つけてたよね。
結構いろいろ見つけてるイメージがあるな。
ぜひご興味ある方は読んでみてください。
次は、さらっと紹介できるって感じなんですけど。
AIコーディングにおけるセキュリティリスクと対策
フラットセキュリティさんのブログで、
AIオータクのセキュリティエンジニアが使いたい
Viveコーディングのセキュリティリスクの話という記事ですね。
中身は、
タイトル通りViveコーディングするときに、
あるあるのセキュリティリスクみたいなのを紹介していて、
それに対する対策みたいなのをいくつかそれぞれ書いてくれたという感じですね。
結構このFMでは散々話してるものがいっぱいで、
悪意あるエージェントスキルとか、
悪意ある設定ファイルのOSSリポジトリを設定したとか、
そういうサプライチェーン的なものとか、
またAIがリマールFしようとしたときに、
ポチッと押したらアウトになっちゃうとか、
そういうものがいろいろあるって感じなんですけど、
なんで基本的に復習的な記事だなっていうのと、
またそういうのぶっちゃけ分かんないですっていう人は、
復習的な、復習じゃないか。
入門じゃないですけど、
この領域を知る記事としては、
とてもいい感じにまとまってるかなと思ったのと、
もう一つ知らないというか、
そういう発想あるんだなと思って、
ちょっとおもろかったのは、
開発の過程でデバッグとかで、
ダミーのURLとかを生成するときに、
本物のURL叩いていろいろ送信しちゃわないように、
cloud.mdとかで名前解決されないTLDを使うように、
指示しておくといいですよみたいな話とか、
またチームや組織単位では、
DNSレベルでのブロックも検討してください、
みたいなこと書いてあって、
例えばevil.comとかattacker.comとかは、
割とAIが勝手に生成してやっちゃいがち、
だからこういうのはブロックしておくといいかも、
みたいなこと書いてあって、
これは確かにやっちゃってもいいかもなと。
不便かな。
不便とかはないだろうけど、
結構キリなさそうだなって思ったのと、
キリなさそうだなって思ったのと、
その行動を実行する手前で止めたいよなとも、
思ったし、
ずっと終わるべきなのがむずいなとは思ったな。
そこはもうViveコーダーのリスクとしては、
もう避けられない気もするけどね。
モデルに依存してしまうというかさ。
そうだね。
Viveじゃなくてちゃんと、
Viveコーダーとそうじゃない境目なんだって感じだけど、
もはやね。
でもオートアクセプトしまくんない世界観だったら、
なんか別に起きない問題だと思うけど、
もうポチポチポチポチ押しちゃうときに、
起きるっていうのは普通にありそうな気はするけどね。
あと普通に人間もやりやすいんだよね、これね。
そもそもね。
それで言うとなんか、
やるときやっといてもいいんじゃないって気はするけどね。
一回設定すればおしまいだから。
これはなるほどなと思う。
いい感じかな。
あとこの名前解決したね、TLTがRFCですよ。
予約されて。
でもさ、これさやっぱダメじゃない?
ダメなの?
いいのかな。
例えばだけど、このyourdomain.comの持ち主が、
ローカルホストのコンテンツに、
SameOriginでアクセスできるじゃん、これ。
ebuild.comもそうだよね。
確かに。
だからなんか人が持っているドメインをローカルホストに向けるのはやっぱダメな気がするけどな。
確かに。
エトセホスト、あれだよね、
エトセホスト書き換える方式。
そうそうそうそう。
ブロックはね、また話があるからいいけど。
確かに。
それはそうかも。
ダメかもしんないっす。
分からんけど、なんか。
いいのか。
ダメじゃない?
いいのかな。
でも別にいいんだよ。
ちょっと待って。
エトセホストに書いてある限りは多分大丈夫で、
なぜかというと、
そもそも攻撃者が、
このドメインの持ち主がコントロールしているところにはアクセスが絶対飛ばないから、
だからめちゃくちゃ限定的なケースでしか問題は起きなくて、
ある種のDNSリバインディング的なことが起こらない限りは多分大丈夫で、
エトセホストに書き換える場合においては、
基本的には大丈夫なのかな。
大丈夫なはず。
ローカルホストに何か立ち上げてるときに、
このドメインをわざわざ踏みに行って、
このドメインに何か仕込まれてたらアウトくらいなのかな。
踏みに行ったときもローカルホストにしかアクセスしないから、
あーそっかそっかそっか。
確かに確かに。
本来の持ち主がコントロールしているところには多分アクセスしないから大丈夫なんだけど、
変にキャッシュ残っているとかぐらいじゃないかな、あるとしたら。
あとは、そこにアクセスしながらローカルでエトセホストを書き換えて、
もう一回戻すみたいなことをやったりとかすると、
もしかしたらダメなケースがあるかもしれないけど。
まあ、限定的ではあるか。
まあでも確かに、その観点は確かに。
うーんと、うーんと、うーんと、
えーちょっと待って、なんか自信なくなってきた。
なんかありそうな気がする。経路というかパターンが。
もうちょっと現実的なシナリオが。
なんかサブドメインとかまで考えたらもうちょっと話広がる気がするし。
えーっと、えーっと、
ワーカーは?
ワーカーのパターンは、
ワーカーのパターンは、
キャッシュのリフレッシュ入るのかな、このパターンの場合は。
わからんなあ。
あいつ複雑だよね。
うん、全然わからん。
うーん。
いやでもね、そういうのを考えた時に、
そのやっぱ案義に人が持ってるドメインをローカルホストに向けるのが、
個人的にはやっぱちょっとドキドキしちゃうなあ。
なるほど。
うーん。
なるほど、理解。
じゃあ、自己責任で。
せめてループバックアドレスじゃない、
そのローカルのIPアドレスに向けるとかじゃダメなのかなあ、これ。
いやーでも切りないなあ。
うーん。
わかんない。
なんかちょっと自信がない。
あのー、まあ、フラットセキュリティの記事なんで大丈夫なんでしょう、きっと。
あのー、はい。
いやー、面白いなあ。
勉強になるなあ、確かにね。
確かに。
きっと大丈夫なんでしょう、知らんけど。
まあ、自己責任で。
ブロックできる環境ならブロックが悪いかもね、本当にやりたかった。
そうだね。
まあ、この部分だけ自己責任で、他はまあいい感じにやってもらえるといい気がするんで。
本当にあれだったらサンドボックスカーとかなのかなあ、そもそもちょっと書いておける。
そうだね、サンドボックスが一番いい気がするね。
許可ドメインのリスト作れるから、
あのー、そのサンドボックスないにおいては大丈夫。
だけど、なんか、
そのサンドボックスないにおいては大丈夫だけどさ、
そのー、なんていうか、
例えばだけど、フロントエンドが絡むウェブアプリ書いてて、
なんかブラウザで開かないことあるとかちょっと思っちゃうし。
まあ、そうね。
いやー、うかうか。
安全なバイブコーディングの道は厳しいですなあ。
まあ本気でバイブコーディングしてる人はなかなかここまでたどり着けないだろうしなあ。
はい、ピックしてよかった。確かに。ありがとうございます。
いやー、わからん。ちょっとなんか詳しい人いたら教えてくださいって。
AIによるセキュアコード生成のためのスキル構築
なんか、お前が言うんかいっていう感じで。
教えてください。報道教えてください。
ちょっとなんか、あのー、いろいろ全部検討するには普通に時間が足りなかったです。すいません。
いやー、そういう嗅覚、いいっすね。
じゃあ、ちょっと歯芸が悪い気がするんでもないですけど、次最後の記事。
お楽しみって言うほどハードル上げる記事じゃないですけど、読みますかね。
セムグレップの記事で、
How to write skills that make your AI generatedcode more secureっていう記事ですね。
どういう記事かって言うと、タイトル通り、
AIがよりセキュアなコードを書くためのスキルをどういう風に作るかっていう話ですね。
結構なんか丁寧に書かれてるなっていう印象で、
AI、セキュアコーディングのスキルを作るにおいては、
結構参考にできる部分が多いんじゃないかなって思ったっていう感じで、
割と長いんで、印象深いところだけいくつかピックして話すと、
例えば、これ心理っぽいなって思ったところとしては、
例えば、さっきの話で言うと、そもそも書くコードをセキュアにしよう。
書くGitHub Actionsのワークフローをセキュアにしようと思ったときに、
あるあるプロンプトというか、Cloud.MDにセキュアにコードを書いてくださいとか、
OASPトップ10を参照してくださいとか、
そういうまた振る舞わせるだね。
あなたはセキュリティエンジニアのプロフェッショナルですみたいな。
どういう手法だっけ?
プロンプトエンジニアング手法でやるみたいなのが割とあるあるなんだけど、
そういうものはほとんど効果ないですよって話をしてて、
これってどういうことかっていうと、
ジュニア開発者に安全なコードを書けていってんのと同じ理由で効果ないよって話で、
安全なコードを書くってどういうことなんだっけっていう具体性がなかったり、
何をすればいいかが抽象的すぎるから、
ちゃんと安全なコードを書いて欲しいんだったら、
どういう文脈において、どういうコードが安全でどういうことが安全じゃないのかとか、
そういう部分をきちんと明示していかなきゃいけないよっていう部分が書いてあって、
真理だよねみたいな部分と、
じゃあそれを具体的にどうするのかみたいな部分で、
効果的なスキルを書くために4つのポイントみたいなのが書いてあって、
1つはスキルのスコープをきちんと厳密に定義するっていうのがあって、
例えばWebアプリを書くときにWASPトップ10を意識しろみたいな部分は、
スコープがあまりに広いので、
例えばログインフォームを実装するときに、
パスワードのぬわとか、
どれぐらい差し加減はともかく、
抽象度を高くしすぎるような、
きちんとここからこういうときにこういうことをするみたいな部分を定義するというのと、
あともう1つは、
フューショットプロンプティングみたいな名前だった気がするけど、
あるコンテキストにおいて、
正しいパターンと間違ったパターンの両方を具体的にきちんと定義するみたいな話。
確か記事中にサンプルがあったんですけど、
Pythonでファイルオープンを実装するときに、
パストラバーサル気をつけてねみたいな。
セキュアなコードだとこういう風だけど、
こっちの間違ったコードだとこういうパストラバーサルになるよみたいなのをきちんと書くみたいな感じ。
3つ目は、
意思決定のロジックみたいなのを言語化してきちんとスキンしましょうって話で、
意思決定のロジックっていうのは何かっていうと、
何か僕らがコーディングしてセキュアなコードを書こうとするときって、
一概に01で決められないこととかがあるじゃないですか。
例えば、ファイルアップロード機能で拡張子をチェックするかとか、
拡張子をチェックした上でファイルの中身までチェックするかみたいなところで、
チェックボックス形式にするとチェックしろみたいな話しかならないけど、
実際の場面においてはA案、B案があるとか、もしくはトレードオフがあるみたいな部分があって、
そういうときにどうするかみたいな部分で何かしらのロジックに基づいて僕らが判断してるはず。
それをきちんと言語化しましょうっていう話ですね。
あと4つ目は、どういうフレームワークとかライブラリにおいてそれをするのかっていうのをきちんとスキンにしましょうって話ですね。
例えばExpress.jsを使ってるんだったらこういう機能を作るときはこういうふうにやってねみたいな話とかを、
なるべく具体的に書きましょうって話が書いてあって、ふむふむ、なるほどという感じですね。
結構他にもいろいろなノウハウというか、こういう考え方でこういうふうにするというのも結構具体的に書いてあるんですけど、
これ見ると早いっていうのがあって、記事でバーって書いてあるいろんなものを実践して作ったスキルをGitHubで公開してるよっていうのがあるんで、
興味ある方はそれをちょっと眺めるだけでも結構勉強になるかもなっていうのは思ってて、
量が多いんでね、なかなか全部はさすがに読んではないんですけど、参考にできそうなのと、
記事読んだ感想としては、めちゃくちゃざっくり解釈すると、コーディングも一緒なんですけど、
ジュニアエンジニア、ミドルエンジニアに安全な行動を書かせようと思ったときに、
人間が相手だとしてその人間に対して再現性のある行動を取らせようと思ったときに、
必要な情報を全部インプットしろって話なのかなっていうふうに思ったというか、
そこはエレレンも人間もわかんないというか、安全に書けていったらその人の解釈、そのタイミングの解釈でやっちゃうし、
じゃあそうならないためには、結構具体的にこういうパターンでこういうときにはこうやらなきゃいけないねみたいな話を言わなきゃダメかなっていうのと、
あとは結構大変だなっていうのがちょっと…
まあね、裸のとはめちゃくちゃ一致してるんだけど、
裸のとは一致してるよね。
コンテキストの圧縮度合いとか色々考えたときに結構ギリなくねって思っちゃうので、
何を渡してレビューさせるべきかみたいな部分が結構悩ましいよね。
あるインプットに対して、
これはこれとこれとこれが絡むからこれに沿ってレビューしてっていうのを絞り込まないとキリがないっていう中で、
その絞り込みの部分を割と今まで人間がやってきたはずで、
そこにその嗅覚とか噛んどころが多分あったわけじゃん。
真に求められてるのって多分そこなんだけど。
その辺はなんか…
そう、というのを、だからそのスキルを実際に見た方がいいんだろうなと思うんだけど。
例えばコードセキュリティっていうスキルを見ると、
スキル.mdに色々列挙してあるんですよね。
スキルインジェクション、コマンドインジェクション色々あって、
あとは言語ごとにこういうのを気をつけてほしいみたいな。
プライオリティリゼルスチェックみたいなのがあって、
そのスキルインジェクションで具体的に何をしなきゃいけないかは、
別のマークダウンファイルになってるから、
多分スキル.mdは毎回読み込むんで、固定費というか固定費のトークンになるんだけど、
そこから先読みに行くかどうかは、
こいつがうまく動いてくれれば必要なだけピックするみたいな、
多分設計になってそうな気がするけど、
どこまでワークするかちょっとやってみるという感じかな。
そうだね。
でも基本こういうことになるよね。
もう絶対に読み込まないエントリーポイントで、
こういう基準でこれ読みに行けっていうのを書いて、
そっち側で読み込む量をいかに節約するかみたいな話と、
またそれの再現性をどう担保するかみたいなところになるかなっていう気がする。
まあなんか構造はこうなるんだろうなっていうのと、
まあ書き方みたいな部分はちょっといろいろ読んでみないとなんともだけど、
まあ自分で育てるんだとしたら、
まあこれでやってみてみたいな部分とか。
またなんか検証が結構大変だよな、正直。
だからこういうの作った後に。
まあそればっかりはもうタレだよね。
育てていくしかないから。
そうなんだよね。
感じはしますね。
ちょっと今試しに回してみてるわ、自分のコードに。
おお、いいですね。
なんかでも結構あんま向いてない系な気がするんだよな。
このGitHub AppTokenのセキュリティトークンサービスって、
なんかあんまり世の中にタレがないというか。
そうだね。CWEで切りづらいあれだよね。
そうなんだよね。
データベースとかあるな、
SQL Injectionチェックとかしそうだね。
データベースないね。
なんだろう、Unsaved Functions。
意外とね、だからこそ結構とちくるった実装してくるみたいなのがあったりして、
困るポイントもあったりするんだけど。
そういうのはなんか難しいね。
自前でやっていくしかないというか、難しいところだよね。
コードベストプラクティスとかあるわ。
ファイルエンコーディングを指定しろとか。
ネットワークリクエストタイムアウトしろとか。
まあまあまあまあ、確かにね。
テンプラリーファイルのクリエーションセキュリティにやりましょう。
面白い。
割とPythonかな、これ。
でもJSも書いたら面白いな。
でもちょっとサートメートをしてみて、
こういうの作り込みたいよって人を参考にするというか。
セミグリップ以外もちょこちょこ出してるから。
決定版欲しいなっていうわがままを持ってしまうから。
まあまあまあ、ちょっと試してって感じで。
でもなんかよくできてそうだけどね。
ただその、何て言ってるんだろう。
デラフォームの話とかも言ってるのか。
なんか、一個一個の中身はすごいちょうどいい、
あれな気がする。
あれっていうのはその、濃度というか長さというか。
そうね。なんかいい塩梅だね。
ちょっと参考にはできそうだけど、
まあでもやっぱり自分たちのタレを作るしかないのかな、結論。
別になんか全部の言語はいらねえじゃんとかあるし、普通に。
AzureとかAWSとかはうちはいらねえじゃんとかは多分あるし。
なんかパクれるもんパクって、
添削して必要なものをやってとか、
なのかなと思うけどね。
逆になんかワークロードアイデンティティフェデレーションの設定とか、
もうちょっと細かいもの欲しいよねとかは、
書いてあるんだっけ、書いてあるのかな。ないよね。
ワークロードアイデンティティフェデレーションの話。
書いてないね。デラフォームGCPの中に。
とかね。
このGCPをバラすとかもあると思うしね。
そうなんだよな。
もうちょっと幅が広いんだよな。
欲しいものの。
XSSとかももうちょっと細かくなんじゃないっていう気はするしな、正直。
あ、リタバークションズはあるんだ。
用できとるな。
なんかサンプルとしては十分な量っていうか。
ようわからんかったらとりあえずこれ回すぐらいの
いいクオリティには間違いなくなってるよね、きっとね。
これもさっきのエラスティックと一緒で
POC的なものではあると思うから、
本当に使うんだったらクローンして育っちゃうほうが
いいかもなって気はするけどね。
ベータって書いてあるね。
まあまあまあ、自己責任で使ってもらうって感じですね。
クローンじゃない、フォークか。
結構いい刺激を出してくれますね、割と。
あ、本当?
回してみたか。
なるほどね、面白い。
どのルール数に従ってこれを指摘してますっていうのを教えてほしいな、CTは。
それをskill.mdに自分で追記すればいい気がする。
面白い。
さっき何で、あれか。
そうそう、そこそこのコードベースを倍上で作ったときに
どうやってセキュリティを担保するのみたいな話をさっきしちゃったけど。
回答はセキュアなコードを書かせる。
いやー、これをいつ回すかだよね、あとは。
結構、これはだからできてるコードに対して回しちゃってるから
作り上げてる中でいつ回しますかみたいな問題はやっぱり解決しなくて。
でもそれはskill.mdで指示すればいいんじゃない?コミットのために。
コミットとかが一番良さそうけどな。
いやー、めんどくせえな。
めんどくせえなっていうのは、とりあえずいいんだよガバガバで今はっていうのがたぶんいっぱいあったので、今回に関しては。
なるほどね。
どうせ動いてるのローカルだし。
そこはまあ難しいね。
そのスタイルがこの時代においていいのかって話ある気がするけどな、もはや。
コスト度替えしてね、いくらでも。
いやでもな。
それか、to doコメントを残させて、to doコメントの部分はしかとさせるとかかな。
それぐらい何倍になりそうな気もする。
いやー、結構なー、なんか難しいね。
まあ割と見通しが立ってない状態で走り始めてたみたいなのも当然あるし。
ういっす。
まあ参考にしてみてください。
まあでもなんかまあ新しいのは出てないな。
面白い。
僕も後で試そう。
いやー、2時間みっちりやりましたね。
いやー、なんかこれでいいかだったけど別に記事は普通だったな。
ああでもなんか普通にフォールドスポジティブもやっぱ出てくるなー、なんか。
気になる方は夜下車のやつを、あれもうパブリックなんだっけ?
ああパブリックになってる。
ああ、じゃあみんなも手元で動かして答え合わせよう。
なるほど。
まとめと今後の展望
これのことかって。
まあまあまあ。
まあそのモデルだとフォールドスポジティブはどうしても。
まあそうだね。
まあコードベースによっても結構変わるしなー。
複雑性とかやってることの特殊さとか。
はい。
はい。
まあそんな感じですかー。
夏も暑くなってきますが皆さん体調にはお気を付けてください。
よし。
5月かー。
平和にいくといいですね。
ちなみになんか全然紹介しなかったけどサプライチェン攻撃は未だにえちらほちら起きてるんで皆さん秘訣的にお気を付けください。
もう多分これがデフォルトになっちゃいそうな感じするねー。
いやー。
毎週毎週もう次やこれあれや次やあれって感じなんでもうわざわざ紹介はしませんが。
うん。
ミニシャイフラットみたいな単語も出てきちゃってるんでね。
いやーあれしんどいよねー。
うーん。
ちょっと勘弁してほしいなー。
うん。
いやー。
来週分でねー。
うんうん。
あれはそのさーあのーあれよ。
アクセス先がダブでみたいな。
うんうん。
あったじゃんね。
あれ困るなー。
来週分ですけどPNPMとかはなんかもうデフォルトの挙動が結構セキュアになるみたいなアップデートがあったりしたのでちょっとそういうのも期待しつつって感じですね。
GAしつつ。
じゃあ、えんもん竹縄でございますが、また来週もよろしくお願いします。
はい。
うっすみなさん来週も楽しみにしててください。
おやすみなさい。
おやすみなさい。
