ワールドカップとPNPMの環境変数展開
こんばんは、Replay.fm第93回です。 こんばんは。
こんばんは。 はい、こんばんは。 はい。
フェーブルが塞がれて久しいですが、みなさん元気ですか? 久しいってことでもねえだろ。
もう1週間ぐらい経ちましたか。 いやー、
あの、もう鬱陶しいと思うんで、さらっと答え合わせるんですけど、 あの、ワールドカップ日本戦はボロ勝ちしました。
第2戦。 おめでとうございます。 もう最高でしたね。 いいっすよね。
いいっすよね。 あの、最終試合が金曜日かな。
金曜日の朝8時からあるんで、みなさん応援しましょう。
結構間開くんだね。 うん、なんか暑いみたいだね。暑いのと、 あー、なるほどね。消耗すんだ。
そうそう。 あとアメリカ、メキシコ、両方その複数国開催だから、その上下に
移動しなきゃいけなかった。 あー、なるほどね。
あと、なんかね、今回、 その、今回の大会から
何カ国増えたんだろう。めっちゃ増えたんですよ、参加国数が。拡充して。 だからトーナメントの試合も1個増えてて、今まではベスト16スタートだったんだけど、
今回がベスト32から頑張って勝っちゃいかなきゃいけない。 なるほどね。
そう、なんでいろいろあいまって多分。 そうか。
総試合数が増えてんじゃないかな。 予選リーグもさ、昔って上位2カ国増えたじゃなかった?多分。
あ、そうそうそうそう。ずっとそうで、で、今回その32にするために、
3位でも全体の、3位の国全部集めた中の上位8グループかな、8国が出る。 なるほどね。
出場、出場国数、前回、えーと、40、この大会48か。で、今までは32だったのか。だから12カ国増えたんですよね。
まあまあ、なんで、ただね、ちょっと微妙に悪いニュースは、その、1位で勝ち上がっても2位で勝ち上がっても、
その、ブラジルか、まあモロッコと当たるかもっていうのがあって、で、どちらもめちゃくちゃ強いらしい。
モロッコも強いんだ。 モロッコはね、なんか去年の、前回のワールドカップでめちゃくちゃ暴れてて、それ以来強いらしくて。
それまでは多分ね、そんな、そんなにって感じちゃったと思うんだけど、
ないんだっけな、前回。そう、4位なん、前回4位なんだよね。 そうそうだね。
アフリカ勢として初の開業みたいな感じだったのか。 そうそう。
で、今大会もなんかめちゃくちゃ強いらしいんで。 だからブラジル余裕で1位で来るとは言えないぐらい強い。
まあまあ、なんともって感じですけど。 はい。
まあその感じで今日は記事が多いんで、金曜日の承認をいないつつやっていければなと思います。
よし。 あ、あと思い出した。前回のプチ宿題で、PNPMで環境変数展開しなくなったよってやつ、NPMどうなんだっけってやつ調べたんですけど、
NPMは展開するみたいですね。なんか回答するドキュメント見つけて、Notionの方にリンク貼ったんですけど。
それは脆弱性扱いにはならないってことかな。
なんかね、GitHubのデータベースとか探したけどそんな時間なくて、本腰入れて探してないけど、パッとは見つからんかったね。
まだそこはなんか互換性のあれもあるから、なんか一旦様子見なのかな。
ごめん、でも今見たけどこれ参照してるあれが古いな。
でもそうだね、最新バージョンでも変数展開するっぽいんで、直すかもしんない。
なんか僕困んないでしょって思ってたけど、別のPodcastでフロントエンドガチ勢の人がこれめっちゃ困るって言ってて、困るとこは困るんだって思ったから。
私のタイムラインでもなんでこれパッチで出してるの?みたいなこと言ってみていて。
それは確かにね。
もう、まあでも、ブレイキングチェンジポンポン入ってるしもう、せめてマイナーでもいいかもね、パッチで渡したら。
そうか、まあバグ扱いにしたんだろうな、縦付きとして。解釈の不一致って感じがするけど。
はい、まあそんな感じで気になることはキャッチアップしてもらって、じゃあ上から順に今日もいきますか。
Cloudflareの記事「Build Your Own Branded BT Harness」の解説
1個目からね、今日個人的に一番カロリー高い説もある気がするんですけど、
Build Your Own Branded BT Harnessっていうクラウドフレアの記事ですね。
で、結構な対策となっているので、ぜひ興味ある方は自分ご自身読んでいただければって感じなんですけど。
長いな。
長いんよ、結構長い。
途中で長いことに気づいて、ああこれちゃんと読もうと思って丁寧に読んだんですけど。
すごいですね。
ざっくりどういう記事かっていうと、前回、だいぶ前に取り上げたFirefoxのMITOSでバグ大量に見つけてバグフィックスいっぱい出たような裏側の話をしたと思うんですけど。
その時に話したのが、MITOS適当に走らせたらバグいっぱい見つけたよってわけじゃなくて、
MITOSは何だろうと、そのLLMモデルを組み込んだ、今風で言うとハーネス的な仕組み。
まず探索して検証して、記表済みのイシューと重複してないか見て、POCを書いてみたいな、そういうシステムを組んでたからFirefoxがいっぱい見つけられたんだよねみたいな話をしたんですけど。
それのまさにクラウドフレア版という感じで。
クラウドフレア内部でMITOSを使って、彼らも相当数のバグを見つけてるんですけど、
そのバグを効率よく精度高く見つけるために組んでるシステムの解説というような感じです。
結構、全部読んじゃうと時間がかかるんで、気になったところを思い出しながら、かいつまみながら話そうかなと思うんですけど、
一つ、Firefoxも共通してて、なるほどというかそうだよねと思ったところとしては、
モデルに依存しないものをまず作るのが大事だよっていうのが前提としてあって、
理由としては、いいモデルがあったときに簡単に差し替えられるようにしたいっていうのはもちろんなんだけど、
なるほどなと思ったのは、1個のモデルに対して依存して最適化しちゃうと、
コードパスっていう表現をしてたんだけど、おそらく探索する範囲とか傾向とか偏りみたいなのがそのモデルに引っ張られちゃうっていう部分があるので、
結果として調査のカバレッジっていうのが下がってしまうっていうのがあって、
これ、記事中で実際にそうしてますって書いてあるんだけど、
例えば脆弱性を発見してそれを検証するっていう部分をステップで分けたときに、
そのステップごとでモデルを分けることで視点を増やしてカバレッジを下がってしまうとか、
何かに引っ張られるのを避けるっていうのがいいんじゃないかみたいな話が書いてありますと。
あとはハーネスっていうからには結構体操のシステムを組んでるよって話なんだけど、
体操のシステムじゃなくて、これだったらダメなんだっけっていう部分の問いが2つあって、
1つはサブエージェントにいろいろタスクを入れ込みして調査させるんじゃダメなのかみたいな部分に関しては、
サブエージェントを聞ければ確かにコンテキストを逼迫するとか、分岐探索みたいなのを効率的にやるっていうのはおそらく可能。
一方で、探索する過程で必要なメタデータとか結果を映像化して溜め込んで横断的に参照するっていう部分がどうしても必要になってくる。
まだいろいろ細かい部分で再適化していこうとなったときに、サブエージェントに区切ってそれぞれのプロンプトをめちゃくちゃ頑張ってチューニングすれば解決って問題には全然なさそうだし、
結構いい表現だなと思った。
オーケストレーションの問題であって、プロンプトってどうにかなる問題ではないっていうふうに表現されていますよと。
一番最初は取り組み始めとしてはスキルを素朴に作って、それで始めてみましたよっていう部分から始まってたんだけど、
課題は3つあって、1つはコンテキストがどうしても不足しますよっていう部分と、また持続性っていうのがなるほどなったんだけど、
スキル実際にこれOSSになってるんですけど、7ステップあってそれぞれは結構時間かかりそうな内容になってる。
一方で、どっかのステップで何かの理由でクラッシュすると全部やり直しにしなきゃいけないっていう部分で、トークンもめっちゃ無駄だし時間も無駄になるっていう部分がある。
あともう1つがリポジトリ間の推論で、当然ですけど、クラウドフレアぐらいのアプリケーション、大抵の会社のアプリケーションはそうなってると思うんですけど、
システム全体を見たときにそれが1つのリポジトリに収まってるわけじゃなくて、クラウドフレアの場合は126のリポジトリがお互いいろんな依存しあったりとか通信しあって組み上げられてるシステムなんだけど、
それを丸っと考慮して評価するっていうのがスキルだと結構難しいと。
例えば、あるアプリケーション、ある単一のリポジトリで、あるシステムとの内部システムの通信部分に怪しい脆弱性っぽいものが見つかりましたってなったときに、
じゃあその通信先で何が起きるのかとか、どういう認証が求められてるのかとか、そういう部分ってどうしてもリポジトリの方に行かないと情報がつかめないし、
そもそもその通信先が本番で動いてるんだっけみたいな話とか、そういうのを丸っと含めていかないとやっぱり精度も上がっていかないし、
語源値みたいなのも増えていくっていう部分があって、その部分の課題が大きかったですよと。
なんでこの3つの課題を解決するために徐々に組んでいったらハーネスっぽいものというか、今回記事で紹介してるシステムになりましたっていう話ですね。
詳しく全体像を超ざっくり話すと、大きく分けて2つのステップに分かれていて、1つが脆弱性発見、なんかVDHか、何の略か忘れたけどVDH、脆弱性を見つけるところと、
ディレクションハーネスじゃないの、きっと。
でもHがハーネスだと次がなんかあれかな、ちょっと待って。
記事を読めば多分すぐ出てくるんですけど、Vulnerability Discovery Harness、でもハーネスだったね。
見つける部分と、見つけたものを検証するVulnerability Validation Systemっていう2ステップに分けてデザインされてるっていう感じですね。
で、そうだな、割と直感的に全然理解できるというか、シンプルな2ステップになってるんですけど、それぞれのステップの中でそれなりに複雑なことをしていて、
例えば印象深かったものを話すと、脆弱性を発見するフェーズでは、やみくもにコードを読み始めて脆弱性を探すんじゃなくて、
脅威モデリングみたいなものも行うように、ELEMに指示を出してますよみたいな話。
その脅威モデリングみたいなのは、結構スタンダードな攻撃クラス、例えばメモリリークとか、DDoSとか何かいくつか記事中であったんだけど、
そういうものに加えてモデル自身が判断して、こういう攻撃がありそうみたいな独自の攻撃クラスと表現してるんだけど、
その攻撃クラスを自分で決めて その脅威モデリングを組んで検証
するっていうのも いろいろさせる っていうのをやってますと その
上で実際に脅威モデリングした 上で 実際にアプリケーションを
動かして 本当に刺さるんだっけ っていうのを検証したりっていう
のをやりますよ みたいな話とか あとは重複排除みたいな話が結構
ちっちゃくこういうの回すんだ ったら 多分 あんまり 人間が手動
で対応でいいんだけど 126リポジトリ でガンガン回すってなったときに
どうしても課題になるのが 調査 結果の重複みたいなのがあって
これ自体もこの重複をいい感じ に排除するエージェントを専用
で立てて それをステップとして 組み込まなきゃいけないぐらい
結構大事な要素ですよっていう のが書いてあって この重複要素
をLLMにやらせてる理由としては やっぱり文字列判定とか あとは
このファイルパス このファイル メタデータから機械的に判定する
っていうのはどうしても限界がある から ここにLLMを加わせることによって
結構効率的に重複の排除ができる ようになってますよ みたいな話
があったりとか あとはウィッシュリスト かな ウィッシュリストの仕組み
がすごい面白くて さっき言った ように 実際にアプリケーション
動作させてガチャガチャするっていうことを するんで ハーネス自体がある程度
の権限とか環境をいじる権限を 持ってたりするんだけど その過程
でこのバグを検証するのにこの ツールが足りないみたいなのが
あったときに それを欲しいです っていうふうに書き込む ファイル
なのかJSONなのか分からないですけど そういうウィッシュリストって呼ばれる
ものがあって このウィッシュリスト を運用することによって AIアジェント
がこれがないと困るっていうもの を溜め込んでいって クラウドフライヤー
の人間がそのウィッシュリスト を見て ハーネス側に改善を加えて
っていうループをどんどん回す っていうことをやってるらしい
面白いね ウィッシュリスト
そう どこだっけな 128のリポジトリ に対して この記事を書いた時点
で25472回の書き込みがあったって ことなんで どんどんどんどんこれ
これあれこれって言ってくる みたいな感じで この記事を書いて
る間にも このPoCをエンドツーエンド で検証するためにはFreeBSDのVM
が必要ですっていうのを書き込 まれていたりみたいな感じで 結構
面白いなというか これは脆弱性 探索以外にも結構効きそうなアイデア
だなって思ったりしたなっていう 感じですね
あとは何でなんだろうって分かん なかったんで 誰か教えてくれって
感じなのが 静的解析のツールを 最初から使えるようにしてたん
だけど 脆弱性探し出すエージェント ハンターエージェントって表現
をしてるんだけど このハンター エージェントがそれを全然1ヶ月
間1回も使わなかったっていうの があって なんで あんま早くに
渡しても意味ないよってことが 書いてあって 具体的にはセミグレット
を使えるようにしてたんだけど エージェント 1回も手を出さなかった
らしくて これは何でなんだろう っていうのが理由が書いてなかった
ので ちょっと気になるんですけど よく分かるけど これ使うでしょ
って思ったのが意外と使われない みたいな話なのかなっていう感じ
ですね
おもろいね
セミグレップを使おうとすると ルールとか書かないといけないんだよね あれね
自分で使ってないんだよなセミグレップ
プリセットはある認識だけどね カスタマーももちろん書けるけど
そうだよね だから多分プリセット で足りなくて なんか
多分普通にグレップしたほうが早いんだろうな 早めでグレップしたほうが早いんだろうな
そうかもね
エージェントしてるね
語源地とかも多いっていう噂は聞く から 推定解析なゆえに
あとは結構面白くて 調べて探し出して 見つけたものに対して批判的な
検証を別のエージェントにやらせて 最終的にこれは良さそうっていう
調査結果ができたら それを特定の フォーマットを強制して かつ POCとかも
全部書かせて 最後の最後の検証で POCが動作しなかったら その結果
信頼性が低いっていうマークをつけて 最終結果を出すっていうふうに
結構 正式性を発見するフェーズでも 語源地がなるべく少なくなるように
いろんなところにこまごまと工夫が 凝らされてるなという感じですね
この見つけた結果たちを検証するのが Validity Validation System VBSで
ここでは三つだけやっていて 一つは重複解除 ここではJiraチケットに
起票されてないかとかも見に行くらしいんで この時点で起票済みだったら
多分恥いて プラス判定評価ですね それが本当に正しいレポートなのか
って評価するけど このときに本番環境 そのシステムが本番環境で
動くものなのかみたいな部分とか そういういろんなコンテキストを
加味した上で評価したりとか あと面白いというか 確かになったのは
最新のブランチをちゃんと見に行って 同じバグがまだ残ってるかっていうのも
見に行くっていう なんで 後述 最後に書いてあるんですけど
これオンデマンドに回すんじゃなくて 定期的に多分週1ぐらいで回してるんで
回すタイミングとのズレによっては 確かにズレるようになってくるんで
運用してる概要への決め細やかさを 感じるなっていう部分と また修正ですね
最終的に重複してない評価して これは確かにまずいって思ったものは
自動で修正コミットを積むっていうのを やっていて その際にリグレッションテストも
作る なんでTDD的に まずPOC再現するテストを書いて
レッドになるのを判定して その後バッチを当てて グリーンになったら
コミット積むっていうような挙動をする このプロセスがうまくいかなかった場合は
人間が対応が必要ですよっていうフラグを立てて コミットを勝手に積まないようにするとか
またこれで多分プレリクラー立つのか分かんないですけど このコミットが
自動でリリースすることは決してないようにしていて 基本的には最後の取り出として
人間が絶対にレビューする これは理由としては プロダクション行動に対する責任を
持つというガバナンス的な側面とかを 加味してそういうふうにしてみたいですね
なので検証のほうは割とシンプルではあるものの コマゴマと運用がかかりまみえる
工夫が凝らされてるなっていう感じですね
あとは気になるお値段なんですけど 具体的な言及はなくて書けないみたいな
表現書いてあったけど 基本的に安くはないんだけど コストの傾向としては
基本的にハント 反対人と言って 前着性探すところにめちゃくちゃお金がかかる
だけど メタデータの映像化とかをしていくと 例えば同じリポジトリで
2回目にハントするときは1回目のハント ちゃんといろいろ情報が溜まってれば
約半分のコストで済むっていうような表現が書いてあって
今言った理由は実は僕の推測で こういう理由で済むみたいなっていうか
具体的なところは透けて見えないけど そういうことなのかなって解釈したんですけど
そういう部分とか またリポジトリごとに お金がトークン破産しないように
予算をリポジトリ単位で組んで タスク上限を設けてみたいな制限を設けたりとか
またさっき言ったようにPRごとにチェックするんじゃなくて 定期実行にしていて
でかいリポジトリとかでこれ回すと 実行に14時間とかかかることもあるらしくて
それなりに重い処理をしてるという感じですね
あとはこれが本当に正しいのかっていうのを どう検証してるのみたいな話で
データを可視化して それぞれのファーネル分析みたいな感じで
最初に100個これが脆弱性テストですって出してきて それを批判的なエジェントにやらせたら
10個しか正しくないみたいなのをコンテキスト注入して 40パーセントまで引き上げたみたいな
そういう感じでフェーズフェーズの数字を取って 改善をしてるっていうことをやってるみたいです
いやー面白いな
面白いよね かなり面白い
で これめちゃくちゃ アサスって感じなんだけど
このハーネス指令はオープンソースにする予定らしいんで 正座待機って感じですね
いやーちょっと マジで頼ますって感じだな
見てる感じはこれをベースに自社に最適化とか 全然できるベースになりそうだし
最初に言ったまずスキルでやってみたってやつは もうすでにOSSになってるんで見れるんですけど
そっからもう一歩踏み込んだシステムって感じだと思う
なんかリチャルカセキュリティのホワイトペーパーも 合わせて読むと多分もっと面白くって
これはなんか二役エージェントがいるけど 三役いる 三役作るって話をしてるんだよね
リチャルカセキュリティのホワイトペーパーだと
ハント側と これで言うとハント側と それに対して批判的に検証するエージェントがいて
仲裁役のエージェントもいるっていうのを リチャルカのホワイトペーパーだと書いてて
なるほどね 面白いね
仲裁役の言及はなかったな
これは多分ないんだよね だから
で 多分見てる感じ ちょっとごめん なんかサマリーを読んでしか今話してないからわかんないんだけど
なんか割とエージェント依存が結構強めの なんていうかアプローチだなという印象があって
リチャルカの場合は もっとエージェントの外に出すっていうのを
割とアプローチとして紹介してた感じがするな イメージ的には
再現性みたいな部分なのかな
再現性っていうよりは プロンプトの改善だとどうしようもない部分があるよっていうところを
読んでくれって話なんですよ
これよりも全然ボリューム少ないから 読んでもらった方が早いんだけど
プロンプトの改善だとどうしようもないっていうところが言ってあるから
できるだけ決定的な仕組みのほうに持ってくる 倒しくるっていうのをやらないとダメだよっていうのを紹介してたね
その辺がどんぐらい組み込まれてるかはちょっと
わかんないね
コードがオープンになったら見てみたいな
とはいえ決定論的じゃない部分に 委ねなきゃいけないみたいな言及は確かどっかであって
やっぱこういうシステムを組むってことは LLMの不確実性と向き合わなきゃいけないっていう部分だから
そこに対してまだまだ道の中だけど ここまでの成果が出てますっていう感じのところが
書いてあった気がするな どこだっけな
ちょっと見つけたら
結構ね 結構細々 なるべく再現性を持つように工夫されてる気がするんだよな
なんかその脆弱性 ハンターエージェントの実行時間が不自然に短くなったりしたら
それをお前おかしいだろって言って再開させる仕組みが入ってたりとか
結構細々 多分あるんだよね
ちょっと改めて全部読みたいなこれ
おすすめこれは なかなか まずセキュリティ
まあAIを使って脆弱性を探すっていう文明かもそうだけど
なんていうか みんながハーネスって言ってるのはこれかみたいな気持ちで
なんかちょうどこの山の登り方を考えてて めっちゃ助かるなって感じですね
ていうか この 何て言ったらいいんだろう
リチウム化のホワイトペーパー周り 実案件で使ってて
そのコーデしちゃうっていう部分が 微妙に言及があったりするんだけど
割とそのベンチマークとして使われてるのが OSS ばっかりで
何て言ってるんだろう 授業に使われてるコードベースに対して
こういうことやってますよっていう話って まだあんまり出てないと思うんだよね
そうなんだよな このハーネスの話に今 世の中がシフトしてきたから
だからこそハーネスの話に着目して こういうのが出せるようになってきてるっていうのがあると思ってて
例えばだけど このモデルをうちのコードに回したらこうでしたみたいな話って 出せないじゃん
そうだね
ハーネスの話にシフトしたからこそ こういう事例が出てくるようになったんだと思っていて
まあ助かります
助かるね
ちょっと楽しみ待ちつつ これ読んで自分で不完全に靴に組んでみたいなって気持ちがあったな
たぶんね めちゃくちゃ大変だと思うんだよね
どこをどうピックアップするのかっていうのもそうだし
何て言ったらいいんだろう エージェントの作り方みたいな部分が正直まだ未知数すぎて
今すごくユーザーに寄っちゃってるから 自分の立ち位置が
そこをちゃんと学ばんとなっていう感じはあるね正直
そうね
なんか裏側がクロードコードかどうかさえ想像できないもん
クロードコードなのかなさすがに わかんないけど
まあ普通にAPI使って アンスロピックのAPI使ってんじゃないの違うのかな
アンスロピックなりオープンAIなり
そうな気もしつつ
でもそのクロードコードとかって色々システムプロンプトが入ってるから
コード読んでって言った時にシュッと始められるわけで
確かにね
APIとか名前叩くとその辺からやるのがどんぐらい大変なんだろうみたいな
確かにね
想像が全然できていない感じやな
それはあるかもしんない
クロード-Pでプロセスとしてポコポコ立ち上げるのが
でもどうなんだろうみたいなね
ちょっと作ってみたいよね
はいぜひおすすめです
じゃあ次行きますか
次行きましょう
GitHub Actionsのセキュリティアップデート
読むだけ読むか
Safer Pull Request Target Defaults for GitHub Actions Checkout
GitHubのリリースバックチェンジログの記事ですね
プルリクエストターゲットの挙動が変わってないんだっけ
これアクションズチェックアウト
違うなプルリクエストターゲットの挙動が変わる話かこっちは
プルリクエストターゲットの中のアクションズチェックアウトの挙動が変わる
そうだそうだ
ややこしすぎ
そうだそうだ
プルリクエストターゲットが平たく言えば安全になりますよっていう話ですね
ものすごくね大雑把に言うと
でアクションズチェックアウトがフォークからのプルリクエストの行動取得を
デフォルトでブロックするようになったよっていう感じですね
で過去のメジャーバージョンに対してもバックポートされるらしいので
順々安全になっていきますよっていう
まあアップデートさえしてくれれば
そうだね
でもプルリクエストターゲット放置してるリポジトリで
アクションズチェックアウトのアップデートしてくれなそうだけどねどうなんだろうね
まあなんかその意識低いとかピンハッシュさえしてなそうだから
逆に通るのか
そうそうそうそう
意外と浸透はするんじゃないかって聞いてる
面白すぎる確かに一理は面白い
なんかその仕組みに感謝する日が来るとは思わない
そうだね
セキュリティバッチ爆速で勝ったよ
確かに素晴らしいね
アクションズチェックアウトだけはなんかその
こう普通にピンしないみたいなのもありかもしれないね
もう大体ここは大丈夫でしょみたいなところだけピンしないとかは
なんか一層ありなのかもしれないねそれで言うと
なんか一応GitHubの設定でアクションズすらだけ
すらはハッシュ強制しないっていうオプションがあるね
なるほどね
違うか違うホワイトリストか
ホワイトリストでアクションズは信頼するってやつか
ごめんハッシュは嘘だ
ただこれあれなんですよね
防ぎる範囲を限定的でアクションズチェックアウト以外の方法で
コード取得するときのRefsに対しては
今までと同じ挙動するんで
onprexターゲットでアクションズチェックアウトしか使ってない場合は安全なんだけど
なんか他のリポジションスクリプトを参照してるとか
記事中に書いてあるのはghコマンドでコードを取得するとかは
引き続きアウトって感じなんで
だからこれまでの事例見ると
どうなんだろうなっていう
3割ぐらいは防げるけど7割ぐらいはまだ
対応追加が必要かなって気がするって感じかな
どういう仕組みなんだろうな
アクションズチェックアウト内で分岐してんのかな
onprexターゲットイベントは取れるもんね
イベント取ってonprexターゲットだったらRefsを
これ実装見たいな見れるもんね
ちょっと面白いな
マークフローランイベントみたいになるね多分ね
面白いねちょっと後で見てみよう
徐々にギター部もやる気を見せてるというか
舞台前からやる気は見せてるけど
onprexターゲットもとうとうメスが入ってきたって感じ
面白いねこのアプローチがあったのかっていうのは
面白いねアクションズチェックアウトの方に
手を入れれば大体大丈夫になるっていうのは
盲点だったわ
確かにアクションズ自体の挙動は全く変わってないから
めっちゃ手っ取り早く手入れられる部分なんだよ実は
ほかのチェックアウトしないわけのないもんだまして
基本的にはね
何かしらチェックアウトするよね
何かしらチェックアウトする
はい
そこを待ちましょう
次もGitHub Actionsのやつですかね
Control who and what triggers GitHub Actionsworkflows
これも同じですね
これは斜め読みしかできないんだけど
GitHub Actionsのワークフローのプロテクションルールセットみたいなのが
入るよっていう話なのかな多分
そうだね
今まではGitHub Actionsって
例えばワークフローディスパッチみたいなものがあったり
あった時に
すげえ声出る
オーガニゼーション
例えばオーガニゼーションであれば
オーガニゼーションでリード権限ある人だったら
誰でもそのワークフローディスパッチできたし
それを防ぐ方法は一切ないって感じだったんですけど
そこに対して
ブラックリストという
ホワイトリストか
メンテナー権限の人しか実行できないみたいな
指定ができるようになったって感じかな
アクターとイベントがあって
メンテナーとか個人
この人とかこのGitHubしか実行できない
っていうのと
どういうイベントに対して
プッシュイベントに対して
ブラックリストに対して
制御ができるようになったって感じ
これチームを指定できたら嬉しいな
できんじゃないかな
画面見ないとわかんない
俺のチームにはまだ来てないから
会社のやつが来てたかどうかまだ見てないんだけど
だいたい会社のやつから降ってくるイメージがあるけど
これ結構嬉しいね
使いどころとしては
会社とかだと
プライベートリポジトリとかだと
ワークフローディスパッチで何かのオペレーション
GitHub Actionsでやってるんだけど
実はそれが結構大事な操作みたいになったときに
会社のGitHub Actions持ってる人だったら
誰でも実行できちゃうみたいな
防げないみたいなのを
この開発チームだけしかできないようにするとか
OSSだとどうなんだろうな
使いどころあるのかな
OSSでもあるかもね
メンテナーいっぱいいるみたいなときに
リリース権限を持つ人はこの人だけみたいな
でもその場合は普通にリリースPR立てて
タグを打つときに
特定の人のレビュー必須とかにしたほうが
リリースのものに気にするし
でも例えばアドミンゴールの人しか
でも難しいな
オンプッシュ禁止
オンプッシュは禁止してもいいけど
オンプリリクエスト禁止しちゃうと
プリク立てたときに
CIA動かなくなっちゃうんだよね
だから
プリリクエストターゲットも基本的には
未知の知らん人が
プリク送ってきただけのものだから
オンプリリクエストとかプリリクエストターゲットは
結構使いどころない気がするな
どうなんだろう
使ってみないと
使った感じとかも正直わからんから
でも例えば直近のマストラの
大規模侵害があったけど
あれってなんか
だいぶ昔にコントリビューションしてきた
メンテナーの人が残ったままで
そのメンテナーアカウントが取られて
侵害されたパターンだったんだけど
実際見てないんで実体違ったらあれだけど
例えばメインにマージして
そこでオンプッシュのワークログ走って
そいつがNPMリリースを自動でやるみたいな
仕組みになってた場合は
オンプッシュの権限を
特定の強いメンテナーだけ絞るとかやってたら
防げたかもしれないよね
プリリク立ててCIA回すだったら
オンプリリクエストで全部できると思うから
意外とそういう細かい使いどころがあるかもしれない
何にせよ何かあって嬉しい機能な気がしますね
なんか来てたわ
俺のチームにも来てたので
本当
ドキュメントもあるから
ちゃんと読めばいろいろ見れるだろうな
まずあれだね
リポジトリが選べて
フィルターで指定したりとかもできるし
面白いランゲージで指定できるのおもろ
ランゲージ?どういうこと?
ランゲージは見せてあげるよ
納書のほうに貼っとくわ
お願いします
来てないの?手元でまだ
でも
それそれそれ
来てるわ
無料で個人の
すごい
個人でも来てた
個人のやつにも来てた
いいね
AI
ノーAIアクターサービス
コパイロットとか
それめっちゃいいなと思ってて
なんて言ったらいいんだろう
デビンとかさ
ワークロを実行できないようにするとか
結構ありがたいなと思ってて
そうだね
ギターパップがいけると思うから
デビンとか
外部のAI系は全部それで
チームを作ってないから
でもTeamsあるね
これいいな
超助かるな
これさ
リポジトリ単位では設定できるのかな
リポジトリ単位
ポリシーがさ
わかんないけど
少なくともポリシー側でリポジトリを
1個だけ選ぶとかできるから
なんていうか
最悪それでリポジトリごとにはできるよね
リポジトリごとにはできるね
その上でリポジトリ側にあるかというと
あるんだね
実運用だとさ
リポアドミンに決めてもらってみたいな
まあそうだね
オーガイゼーションってなると
誰でも触らせることができるから
いいね
これでも特定のワークフロー
特定のワークフローを触らせないとかできないね
それで言うと
あくまでアクターとイベントだけだから
まあでも
よく考えたら
ワークフローネームとかだとさ
変えりゃいいじゃんってなっちゃうから
まあ理にかなってるというか
まあ確かにね
1個のリポジトリに役割が多すぎて
ワークフローが多すぎるとかだと
ちょっと使いづらいかもね
結局結構緩めなきゃいけないみたいな
確かに
イベントとアクターの組み合わせだけだから
意外と使いどころない気がしてきたな
まあまあでもそれこそ
AIとかGitHub Appの
特定のワークフローを
実行させるのを
弾きたい防ぎたいみたいな
使いどころあるかもね
それぐらいじゃない
あとチーム
チームはよっぽどリポジトリの用途が
はっきりしてない限りは
無理な気がするな
少なくともリードオンリーの人が
ワークフロー触れる必要はないから
そこは
一律禁止にしちゃってもいい気がするな
だからその
それいくとさ
アラウドアクターに
追加していかないといけないから
これを禁止はできないんだよね
でもロールでさ
ライトメンテンリポジトリアドミンだけ
これ全部チェック入れて
確かにね
これでリードの人は
イベント全員
許可しておけばこれでリードの人が
確かにできなくなるのか
これはなんか
やんない理由ない気がするな
わからないけどコード欠かせたくないけど
ワークフローディスパッチさせたいみたいな
運用がもしあるんだったら
そこはちょっと調整が必要だけど
でもそんな運用で
GitHub Actionsはもうこの
2026年に使ったらだめでしょ
っていう時代になってる気がするから
まあでもそうそうでも
リードの人が
リード
まあね
でかいキーワードと
そうだねでかいとこだと
あるなと思ったから
黙ったけど
あとはその割と
当然聞かせなきゃいけないキー
でもそのコードの
総合参照はしたいとか
あると思うんだよね
確かに
うん
いいんじゃないですか
これはみんな使いこなしていきましょう
って感じですね
キャプチャー刺す
いいっすね
じゃあ次いきますか
読みますかね
1Password Credential Brokerの紹介
Introducing
1Password Credential Broker
1パスワードのブログ
なんだこれ
1パスワードのブログだね
斜め読みしかしてないんだけど
一言で言うと
ワークロードアイデンティティ
ワークロードアイデンティティフェデレーション
Google Cloudで言うとこのワークロードアイデンティティ
フェデレーションプラスシークレットマネージャー
みたいなのを1パスワードでやるよって話かな
多分
ざっくりと
結構その多分
まだなんだろうな
クローズドベータなんで
具体の画面とか設定書いてないから
想像でしゃべるしかない部分はあるんだけど
今んとこギタバアクションズで使えて
ギタバアクションズから
APIトークンとか無しに
ワンパスの2のボルトの2のアイテムに
失礼
アクセス可能なタメトークンを
吐き出してくるっていう感じですね
いろいろ関数ラグも全部残りますよ
みたいな感じ
何でもかんでもシークレットマネージャーに
置くわけには正直いかなくてさ
そうなんだよね
かといってそのワンパスワードと二重管理になると
別に数少ないからいい
数少ないっていうかそんなに
乱立するわけじゃないから
まあいいかっていうところであったんだけど
例えばワンパスワードに全部
一箇所に置いておきますっていうのは
結構楽な気がするし
IDトークンに対してルールをどれくらい
柔軟に書けるか次第なのかな
そうだね
記事読んだ感じは
それなりに硬い
多分エンタープライズ向けを想定してるようには
見えるんだよね
柔軟性がどのくらいあるかだよね
サブジェクトまで
ワークロレフとかも多分
いくつか例が
上がってたよね
多分忘れてたけどまあいいや
これなぁ
個人で使いたいんだよな
個人的には
めっちゃわかる
いろんな
トークンをさ
個人だから
ワンパスに突っ込んでおいてさ
アクションシークレット
置きたく
めんどくさいじゃん
めんどくさいって言っちゃだめなんだけど
アクションシークレットに置いといて
これはワンパスもこれと一緒でとか
頑張って管理してるんだけど
全部ワンパスに寄せてこれで管理できたらね
ぶっ壊さないと思うし
個人だったら
これは
欲しいっすね
あとはそのオーガニゼーション
オルグワイルドシークレッツ
よりは
もうちょっと統制効かせたいみたいな
ニーズに答えてくれるものが
今GitHubにないんだよね
なんていうか
このレポの
このサブジェクトの時だけ
渡したいとかこのレポのこのエンバイルメント
の時だけこのレポとこのレポの
このエンバイルメントの時だけ渡したい
みたいなやつとかは
複数のレポにアクションシークレット
設定するしかなくて
もしかしたらシークレットマネージャー1個
設定してワークドライブキューフェデレーション
を複数書くみたいな
AWSでもGCPでもいいけど
そっちに持ってこないといけないから
ワンパスにする
デメリットをあげるとしたら
ワンパス側でちょっとどういう挙動に
なるのか分かんないけど参照されてるよ
って見え方しないと思うんだよね
参照されてるかどうか参照された瞬間しか
分かんないから
アクション図でつかれてることを知らずに
リネームして壊れるとかは全然
あり得るかなと思うんだけど
運用でカバー
でもアイテムIDみたいなの変わんないんじゃないの
リネームだったら
アイテムID変わんないけど
ワンパスアウトのCLでとか触ってると結構
アイテム名書かされることがあって
これ一瞬で壊れそうと思いながら
手元で運用してるんだけど
また
ボルト移動するとか
されちゃうと
ダメだよねとか
あとその中のフィールド
フィールドの名前をちょっと分かりづれて
タイプを直したら壊れたとか
そういう部分は
運用でカバーしなきゃいけないかなと思いつつ
クレデンシャーの中にも
緩めに扱っていいものと
ぶっ壊れたら困るものって分けられると思うから
緩めに扱っていいやつは
ワンパスに寄せて
固めに扱うものはシェイクトマネージャーに
やりましょうとか全然あるような気がする
ただボルトの権限って
削除の権限を落とすとか
確かできたやつだから
削除は落とせるね
移動とかはちょっとどうだったか分からんけど
エディットも落とせる
クリエイトは?
クリエイトも落としたんじゃないかな
クリエイトとエディットが独立してれば
最初に作って
移行は編集できないって形にしたけば
壊しにくいボルトみたいなの
多分作れるから
クリエイトとエディット分かれてるかな
分かれてない気がするな
ちょっと忘れてたけど
悩ましいね
固くしすぎるとな
音者の運用に合わせて
デザインしましょうって感じ
これ何すよ
これ個人で使いたい
ベータレジスタフォーム見たら
会社名入れろって書いてあったから
ダメっぽいな
それ前提っぽい
会社1個立ち上げればいいんじゃない
それ用の会社欲しいよな
実験用
プレイグラウンド会社が欲しい
別に悪いことしてないと思うから
言っちゃうけど
個人事業主開業してるから
それで資料請求したことある
ワンパスこれはちょっと
明らかにターゲットじゃない
欲しいよな
プレイグラウンド会社
株式会社プレイグラウンド
合同会社作るみんな入ろうぜ
超愚痴だけど
セキュリティレポート全部会社名入れさせるから
分かるけど
良くないよあれ
ただより高いものはないって話だと思うけど
株式会社プレイグラウンドは結構あるな
株式会社サンドボックス
ありそう
いやー株式会社資料請求にしようぜ
正面切って
プレイグラウンド普通に欲しいな
自己資本でやるか
ペーパーカンパニー
普通に欲しい
いやー
はい
じゃあ来年の目標は
法人なりということで
いやー頑張るか
めちゃくちゃめんどくせえな
頑張ります
後悟期待
はい後悟期待
じゃあ次
いきますか
だんだんふさらさらっとしてくる気がする
か
インフォスティラー.コム
っていうサイトですね
この記事で見つけたの
インフォスティラーのレポートいっぱい
出してそうな
何でもあるねインターネット
ね
Fortinetファイアウォールの侵害「FortiBleed」
オープンソースマルウェア.コムっていうのも最近見つけたし
いろいろある
多分
まあまあいいや
何者かを見てみる
記事は
フォルティブリード
もう英語が出てこないな
7万5千
7万5千フォルティネットファイアウォール
コンプリマイズ
グローバルエンタープライズエキスポーズ
クレームヨーエリカーディスクロージャー
っていう記事ですね
で
まあなんかさらっとなんですけど
フォルティブリードっていう
キャンペーンの名前を誰かがつけたのかな
でフォルティネットのファイアウォールが
大規模侵害されてますよ
という話ですね
で正直このエッジデバイスが
やられる攻撃の話は
もうなんていうか
日常的に起きててわざわざ取り上げないんですけど
そんなことしてるんだ
っていうのが面白かったのでちょっと話したくて
まず規模感みたいなところでいうと
結構規模がでかくて
インターネットに露出してる
フォルティネットのデバイスのうち
約半数がターゲット
になっちゃってますよ
っていう感じ
なので結構範囲が広い
例えばの被害企業名
みたいなところでも
名前聞いたことあるようなキーはちらほら
僕が覚えてないサムズンとかが
入ってたりしたんですけど
そういう部分の端末が侵害の脅威に
さらされてる状態ですと
CSAからも注意喚起みたいなのが
出ていて
フォルティネットのやつ
使ってるやつはちゃんと見ろよ
っていうお達しが出ていますと
で じゃあこれなんで50%
インターネットに露出してるうち
50% 約7万3000件の
やつが
脅威にさらされちゃったかっていうと
パスワードがバレちゃいましたって話ですね
この半数の
デバイスの管理用パスワードが
全部漏洩しちゃいましたって話で
で じゃあなんでそんなに漏洩しちゃったのかっていうと
インフォスティアラー.comって書いてあるから
ミスリーディングなんだけど
インフォスティアラーとかに盗まれたわけじゃなくて
このファイアウォール フォルティネットの
通信ログ
SSLとかで暗号化された
VPNとかで暗号化された通信ログを
ひたすらかき集めて
ひたすらマシンパワーで
ぶん回してブルートフォース攻撃
を仕掛けて
ローカルでパスワードを
複合視するっていう攻撃をした
ほぼ
APTレベルのアクターが
ロシアで
ロシアのアクターがいたらしくて
で それを使って
パスワードが
バレちゃって
で それが漏洩しちゃいましたっていう話
らしい
です なんで結構
そんなこと
できちゃうんだな
っていう部分が結構びっくり
というか
待って
待って
何が
ちょっと待って
頭がついていってない
ブルートフォースで
何を明らかにしたの
多分
オグリンパスワードなのかな
でもね
ハッシュだけじゃなくて
単純に
あれか マシンに対しても
ブルートフォース攻撃 アタック
だからオンラインアタックもしてるし
オフラインアタックもしてるって感じなのかな
オフラインアタックってさ
意味あるのだって
パスワードの
どっかからハッシュが取れたのかな
で あれか
ハッシュの形式が
SH-256で
今は
もっと強いやつになってるんだけど
2025年以前のやつで
アップデートしてるやつは古いやつのまま
だからそこが
脆弱になったんじゃないかみたいな
推測がされてるって感じ
あー なるほどね
で その
パスワードハッシュは
どっからどう取ってきたの
通信の
今のなんかその地面というか
聞いた話の地面だけ聞くと
何かしらが期待化してない限りは
成立しなそうな
気がしたんだけど
いまいちちょっとわからなかった
めっちゃ厳密な
あー SSLVPNの
認証ハッシュ
あー なるほど
SSLVPNって
いまいちなんかわかってないんだよな
プロトコルの中で
せやねえ
せやねえとか言って
僕はわかってません
さっとググったらダメな子扱いされてるな
SSLVPN
普通ダメってことは
あんまなんかネスペとかでもさ出てこなかったよね
SSLVPNって
覚えてないよ
IPSECとかよくさ
取り扱われる気は
四択の中には入ってそう
四択さ
SSLVPNの
防御
わかんないな
確かにプロトコル自体もいくつかあるんだね
だからその中のなんかがたぶん
なんかをあれするんだろうねきっとね
わかんないけど
ネットワーク上に何かが流れて
それに対してオフラインアタックができるような
何かがあるんだろうね
そのハンドシェイクっていうか
なんかあるんだろうなと思うけど
ちょっとわかんない
オフラインアタックごめん
嘘ついたかもな
ごっちゃになったかな
でもSSLVPNの
でもそうだね
自前のマシンで
オーセンティケーションハッシュを
頑張って
クラックしたよってことは言ってるね
いまいちめっちゃ正確な原因みたいなのは
全部はわかってない
なんか要領を得ない感じはするけど
確実なのは
オンラインにさせて
うちの半数のパスワーダーも
漏れちゃってますよって話
ではあるから
使ってる方はお気を付けくださいって話だし
アクセンチャーオラクル
日本の企業も被害にあったっていうの
別の記事書いてあるな
どこの企業だろう
なんでこんなことが起きてしまうんやな
っていうのちょっと
感じないけど
SSLVPNがキーなのかな
このマシンパワーで
ぶん回してる感じは
なんていうか
理論上はやれるのはわかるけど
なかなかっていうと
あとは
素朴ではあるものの
2FAとか設定しようね
って話とかも
対策としては書いてあるって感じ
ですね
パスワード複雑にしてもクラックされたら意味ないんで
っていう
結構このEdgeデバイスって
初期パスワードのままとか
静寂なパスワードでとか
そういうイメージがあったけど
夜も眠れない
夜しか眠れないんだけど
中身が
気になるんだけど
よかったら
何か進展があれば次回教えてください
進展というか
あまりにも仕事と
絡みがなさすぎて
もう忘れてる
明日には忘れてると思うけど
収録終わったら忘れてるかもしれない
はい
ちょっと有識者の
まさかりんも待ってます
そうだね
そんな話でいいと思うんですけど
はい
Edgeデバイス
詳しい
でもなんか結構
これよりももうちょっと
詳しそうなやつ
見つけたので
一緒に貼っとくけど
確かにFortiBleedで
調べればいいのか
うーん
いやーちょっと分かんないなそれでも
詳しいけど
でもなんか基本的にSSHと
SSLVPNのポータルに対しての
クレジェンシャルスタッフィングって書いてあるから
なんか
ポータル
要はだから普通にログイン画面とかに対しての
その
クレジェンシャルスタッフィングっぽい感じは
するけどね
込入した後にいろいろなんか
認証トラフィックをキャプチャーしてるよ
っていうことを
書いている気がするが
ちょっと分かんないな
でも侵入しないと
ん?
侵入するにはパスワードが必要だよね
そう侵入はだからクレジェンシャルスタッフィング
やってるよって話でしょ
おー
侵入した後に
もうなんか一気に分かんなくなったな
ね
Fortinet経由で入って
アクティブディレクトリー漁ってみたいな
記述はちょこちょこ見るけど
んー
あーまあでも管理インタフェースか
管理インタフェース
でも管理インタフェース掌握できたら
もう入れちゃいそうだけどな
そのハッシュの複合は
どうやってるんだって感じ
ハッシュの話はなんか要は分からんね
なんかそれで言うと
どこで登場するのかもよく分からないし
なんかカスタムする
またネットワークのトラフィックを
その
えーと
ネットワークのトラフィックを
えーと
40ゲートのこのファイアウォールで
えーと全部キャプチャーできるから
でそこを流れてるやつを解析する
あーそういうこと
うん
一回入った後になんかいろんなものが
どんどん追加で漏れていくよっていう
話なんじゃない?
確かに40OS診断コマンドは
悪用し
悪用は一切展開することなく
ほんとだいろんな
あーなるほどね
あーそうだねいや指定しましたなるほど
確かに
侵害されたすべてのデバイスから
いろんなプロトコル認証トラフィックを
キャプチャーして
でGPUで複合してってことか
複合というか
解析して
なるほどね
はい理解しました
なるほどね
で?
元の記事の話でいうと
だからあれか半分以上の
管理コンソールがむき出しになっていて
あー
ファイアウォール
言われるとドメインが漏え
全デバイスの50%
あーだから別に半数が侵害されたよ
って話じゃないのか
だいぶ読み違えたな
だいぶ読み違えた
半数の企業がこの攻撃に
晒されてるよって話なんじゃないかな
うん
これだいぶミスリードじゃないか
まあ結論よくわかんねえな
なんか
自動化
なるほどね
ホウティゲットに対して認証情報
攻撃を
うーん
なんかその解釈でいい
気がするな
えーだいぶ
ミスリード
コンプロマイズドファイアウォール言われるわ
でもなぜ13000って書いてんだよな
だからなん
まあいいやちょっと
可能なら復習して
出直しますわ
でもなんか難しいね
難しい
うーん
金銭目的ですと
いろいろあるな
はい
はげ悪い感じになっちゃったんですけど
ちょっと余裕があれば復習しておきます
えー
次行きますか
行きましょう
はい
こちらもスタートですけど
Socket SecurityによるVS Code拡張機能のマルウェア対策
Socket firewall now blocks malicious VS Code andOpenVSX extensions
っていう
ソケットセキュリティのブログですね
で
まあ何かっていうと
日本だと
匠ガードですね
匠ガードをNPMとかPyPyの
レジストリの
手前に立ってくる
マルウェアをブロックしてくれるみたいな
無料で出てくるツールがあるんですけど
あれのVS Codeおよび
OpenVSX版が
出しましたっていう話ですね
で
ソケットセキュリティも
匠ガードソフトのものを
前と変わってなければ無料で実は使えるんですけど
このVS Codeのやつは
有料版のみの利用ということで
とても残念なんですが
これめちゃくちゃ欲しいなと思って
さらっと紹介という感じです
OpenVSXってこれは
VS Codeベースの
やつ用の
僕の認識だと
VS Codeのマーケットって
審査とか
開発者登録とかそういうの必要なんだけど
OpenVSXは誰でも多分自由に
ポンポン
パブリッシュできるっていう認識
だけどめっちゃ怖い
あってるかな
そうだよね
多分そうだよね
あとあれか
VS Codeをフォークしたやつから
VS Codeの公式マーケットプレイスにアクセスできないケースがあるから
そういうものは
OpenVSXです
そっちかどっちかっていう
そうだね
Windows Serveとかはそうだね
なるほどね
記事にも書いてあるけど
クールダウンとか入ったけど
クールダウンめちゃくちゃ短いんだよね確か
VS Codeが
入ったんだけど
1時間とかじゃなかったかな
2時間か
2時間
これ設定で変えられるのかな
そうだね
そうなんだよね
2時間だし変更できないから
クールダウン効かなかったら
もうおしまいっていう状態
だからこういう
中間に立つやつがいて
ブロックしてくれるのはそれが一番
シンプルなんじゃないかっていう風に
個人的には
思ってますが
皆さんはどう対応してるんでしょうね
なんかでも
このためだけに
なんかしんど
お金を払う
何かとしては
結構不毛だよね
まあそうね
そうだね
キリがないよな
かといって無視できないじゃん
こういうのがさ
腐るほど増えていくわけじゃんこんな
エコシステム自体はさ
じゃあ例えばだけどVS Codeを
例えば社員がさ
1000人でさ
50人ぐらいVS Code
使っててみたいな
残りはまたVS Codeじゃない
何かに移行して
新しい何かに移行してみたいな
どんどんどんどん積み重なっていって
こうなんか
そういうのが10個20個ありますみたいなときにさ
全部に対してこういうのを入れるのか
ってなったらやったらねえよってなるよね
そうだね
直近だとなんかJetBrainsの
プラグインにもめっちゃ
まれが混ざってるみたいな
Socket.Y.Worldのページ何気なく見たけど
結構あれだね
Chrome ExtensionとかHugging Faceとか
アクションズでも
アクションズ使えるかスキルズだって
思想で言うとSocketを入れとけば
Socketなら全部いけるよ
っていう状態にするのかな最終的に
それを目指すんだろうね
それやったら
まだ分かるけど
でもさ得手して高いよね
これ系のサービスって
まあその
しょうがないと思うんだけど
どうしてもその
運用コストもバカにならないと思うから
うーん
いやー難しいよなー
なんか
プラットフォームにやってほしいという気持ちもあるけど
プラットフォームも別になんか
僕らお金払ってるわけじゃないし限界がある
印象はやっぱ
こういうビジネスになっちゃうよね
そうね
難しいなー
なんかきついね
うーん
いやー
結局大きかろうが
大きくなかろうが
なんか必要なものはどこも一緒だから
そうだね
かかるお金が一緒って考えると
普通にきつい時代っすね
うーん
いやー
なんかこういうさ
全人類必要なやつをさ
まあでもそうか
いや何を言おうとしたかって全人類必要なものをさ
みんなでお金出し合って作ろうよ
みたいなこと言おうとしたけど
それをやってるのが俺らだよって話だと思う
うーん
いやなんかそういう来週ね多分
読むのに入れた気がするんですけど
チェーンガードがそういう風にOSS用意しようよって
言ってる記事があって
うーん
なんか理屈は正しいと思いつつ
うーん
例として挙げてたのがその
あーどうせした
SSL証明書のレッツエンクリプトか
レッツエンクリプト
みんなで企業が支援して
全員が必要なものみたいな
ことを言ってて
うーんなんか
いやなんかOSSのな
フリーライドの限界を感じるな
しみじみと
はい
結局そこをさOSS化したとしてさ
うん
今度やっぱそこが狙われるだけな気がするんだよな
なんか
あーだからなんかOSS化するっていうよりかは
もうその
それを
まあOSSっていうか
なんかそのオープンある種オープンな
コミュニティで運用しましょう運営しましょう
ってなった時に多分今度はそこに
悪い人が入り込んでくるような気がしてて
まあSPOFにはなるよね
うん
だからそこは絶対やられちゃいけないっていうものには
なるよねどうしても
なんかそれをこう
めっちゃ綺麗に防ぐ
だけの仕組みというか
なんか
そういうコミュニティ運営みたいな
結構規模がでかくなると
難しいと思うし
なんか
まあむずいっすね
お金が必要になりますね
まあね
いやー
難しいゲームしてるよな
マジで
そのお金がないとこういうのに
広く
通していけないけどそのお金を
いやなんだろうな
そのさ売上がもうめちゃくちゃ
でかくなる間の間さ
この無理ゲーを
強いられてるよなみたいな
うん
別にでかくなったから
なんかその
余力が出てくるってわけじゃなくて
まあね
でかくなったものを守るモチベーションが高くなるから
そこにお金をかけてもいいよ
っていう風に思えるようになるみたいなのが
なんか近いような気がするし
まあね
今だとさ
小さかったら狙われづらいっていうのが
もう完全に成り立たなくなっちゃうから
そこがきついんだよね
きついね
向こうとしては
引っかかったら釣り上げますよっていう
うちなんて狙ってもしょうがないよね
みたいな
いやそもそも狙ってないけど勝手に引っかかるから
なんか別にっていう
現金化できるなら別に
絞られるな絞られるな
まあソケット
ユーザーのみなさま
ぜひ使ってご感想お待ちします
ベータ抜けたら個人でも使えるようにならないかな
ちょっとぬるく期待してもらって
そうだろうね
はい
じゃあ次は
次もサービスリリースの話ですけど
Introducing AWS Continuum
Security at Machine Speed
AWSの記事ですね
IWS Continuum
AWS Continuumの紹介と導入の難しさ
読み方ちょっとあっておかないですけど
そういう製品が出ましたよって話で
ざっくり言うと
行動の脆弱性を探して
検出して
くれるんですね
ちょうど
一番最初に話した
クレードフレアのやつみたいに
ただ単に探して提示するだけじゃなくて
探したものを
ちゃんと検証してPOCも書いて
修正パッチも書いて
重複してないか見て
精度の高いレポートを
出してくれるっていう製品になっていますと
これ系いろいろあるけど
個人的に気になったのが
あれかなもともとセキュリティエージェント
ペンテストのやつがあったと思うんですけど
これはもうこっちにマージされて
多分コンティニアムの一機能として
ペンテスト機能があるっていう位置づけになってる
のでこれが本流というか
本腰入れてるやつになりそうっていうのと
あと解析対象に
非構造データもいろいろ
含めることができるらしくて
例えばプロダクトの仕様書とか
開発とかも
全部組み込める
コンテキストを
きちんと突っ込めるよっていう話とか
あとちょっと面白いなと思ったのが
学習モードと強制モードの
2段階があるらしくて
最初は学習モードから
使い始めてくださいって書いてあって
この学習モードが何かっていうと
Human in the loop
とか
人間からのフィードバックを受け付ける
専用のモードになってて
検証して回してみたいな
途中で
人間が
答え合わせをする
これは間違ってるよとかこれは正しいよ
みたいな評価をしてあげて
このコンティニアムの設定なのかな
ちょっと具体的にはわかんないですけど
設定とかいろいろ教わってた上で
いい感じに回るようになったら
この強制モードにして
ぐるぐる勝手に回るようにしてね
っていう2段構えの構成になってて
これは結構面白いというか
試行錯誤して
こうなったんだろうなっていうのが
見えるなっていう部分
面白いですね
気になってたんだよね
仕様を読み込ませないと
結局ビジネスロジックに対して
どうなのかっていうところは
検知の仕様がないよなと思ってて
いくら何でも
そうだね
検知はできたとしても
過検知がめっちゃやってたりとか
失われる気がしてたし
優先度とかも
判断しづらいよね
その機能とかが
プロダクトにとって何なのか
コンテキストとしてあると思うし
普通のメンバーがアドミン相当の機能を
触れてるやんけみたいな
ダメじゃねえみたいなのはね
それがどれぐらいのレベルなのかとか
正直そういうのないと判断できないだろうから
なんかセキュリティエジェントのときもそうだったけど
結構メタデータ加わせてっていうのは
機能として提供してくれてるから
これも
使いたいけど
そうなんだよね
ちなみにまだあれかな
リリースサイト
クローズドベータなのかな
リクエストアクセスしてって書いてるから
アリアクセス
会社が必要ですね
会社が必要もそうなんだけど
その
そもそも
安くないじゃんこれ
セキュリティエジェント
安くなかったね
ちょっとなんか
検証してみましょう
みたいなアクションにも
それなりに気合がいる
というか
もうちょっと小さいとこから始めたいんだよね
その
でもなんかこの
語源値の
少ない
もうなんか
まるっとシステム意識はやっぱどうしても
今時点だと
なんか
クラウドフレイヤーの記事ぐらいになっちゃうんじゃないかなって
気がするな
このコンティニアムはそれを売ってるんだろうなって
思って
トークもどうしても
たくさん使うと思うし
システム運用とかを
原価と仕上げした上で
付加価値に乗せて売ってるから
どうしても安くはならんよな
みたいな
これを誰が運用して
開発の中のどこにどう
組み込みますかみたいなところ
まで含めて考えないといけないから
そうだね
パッと動かしてみて良さそうだね
全然進まないみたいな話があって
開発の中に組み込んで
開発プロセスの中に組み込んでいきましょう
みたいな話を考えたときに
もう少し一歩ずつ
登っていくようなアプローチが
欲しいよね
そうすると内施したいよな
って話になってくるし
かといってそれ自体は結構重いから
できてるもの使いたいよね
みたいなのもあるし
でも真に価値を発揮するのは
綺麗に組み込まれた状態
だろうから
結構
ニワトリ卵の部分が
これまではあった気がしてて
作らんと
そもそもどこまでできるのか
分かんないけど
どこまでできるか分かんないと
踏み出すにはちょっと
コストが重い
普通に3ヶ月とか半年プロジェクトになる
みたいな状態だったと思うけど
直近はちょっと見通すじゃなかったら
どうなのっていう部分が不明瞭
ではあるんだけど
GPT5.5とかあるし
そういう構成のモデルを組んで
ハーネス作れば結構
使い物になるものができるっていうのは
Firefoxしかり
Cloudflareしかり
なんかちょこちょこ証明されてる気が
しているから
なんかその時間はかけるけど
投資すればそれなりのものはできるっていう
部分の見積もりは
なんかできる
気はする
それはもう間違いなくそうなんだろうなと思ってて
あとはその上り方の問題でさ
そのどこから始めますか
みたいな話とか
よくできてるものをじゃあいきなり全部
なんていうか綺麗に組み込めますかってなった時に
その
まあ
規模の大きいところだったらもう正直
このやり方で全部やってください
っていう風にやっちゃう方が
多分早いんだろうけど
なんて言ったらいいんだろう
正直それが
ワークする規模って
相当なものな気がするし
なんか
めっちゃやりやすいんじゃないかって
思ってるのは
脆弱性診断外注してるんだったら
それをまずは置き換えちゃうとかが一番
やりやすいんじゃないかって個人的には
思ってるけどどうなんだろう
うーん
まるっと回します
コードベースで
単一でバーって回します
で項目が出てきます
それを従来の
脆弱性診断もさ
回した時に検出項目が出て
それを開発チームに渡したり
セキュリティチームが修正したりするのかもしれないけど
そういうプロセスがあるから
その裏側を外注なのか
エージェントなのかっていう部分は
置き換えられる気はしていて
でそれが
仮に成功した
角度が高いってなった時に
次に変えられるのって
原価次第だけど
ヒントになるわけじゃないですか
外注だったら
毎月毎週はできないけど
動くシステムがあるんだったら毎週できるかもしれない
じゃあ
毎週のように同じプロセスを回さないか
じゃあどうしようみたいな
そんな感じで進めるとかできないのかな
っていう妄想はちょっと
個人的にしたりしてるけどね
トライとしては
悪くないのかなと思うけど
その
どうなんだろうな
ブラックボックス寄りのテストを
どこまで持続してくれるのか次第じゃない
ブラックボックス寄りのテストを
ソースコード渡して
ここでデブの環境が動いてるので
ここで
刺さるかどうかの検証を
してくれて構いませんっていうのを
パッと渡したら
後吉野にやってくれるっていうのが
人間がやるテストじゃん
アカウントは発行しておきました
IDとパスワードだけポンと渡しておいたら
後勝手にやってくれるっていうのが
人間がやるテストだと思ってて
なんか
その辺をどこまで吉野に
やってくれるか次第なんじゃないかなと思っていて
あれが動かないこれが動かない
みたいなものが
こういう出来合いのものを買ってきたときに
どれぐらい発生するか
次第な気がしていて
そこが結局
中で作っていろいろハーネスを作っていかないと
綺麗に回らんよねっていう風に
言われてる部分だと個人的に思っていて
うん
そりゃそうね
それはもうやり込む前提な気がするわ
そう
なんか
そこに対するもうリソースの投資は
必要なんじゃないかなって思うけど
それで言うとだから作り込まれすぎてる
ものを買ってくるっていうのが果たして
本当にいいのかっていうのはなんか正直
まだよくわかんないなと思ってて
だからなんかその辺の安倍は
もうちょっと物によってって感じではない
そうそうそうそう
使ってみないとわかんないなっていう
ある種のニワトリ卵みたいなのがそこにあって
とりあえず回して満足みたいな感じになっちゃうと
それはそれでなんか費用対効果として
微妙な気が
せんでもないし
うん
だからそれでクラウドフレアのまずスキルから始めました
はなんか個人的にはかなりしっくりくる
登り方をしてるなと思ってて
うん
そうね
まあでも
うーんまあそうね
LLMを活用したセキュリティ対策の導入戦略
どうなんだろうね
遠いな
全部自前で組むのがやっぱしんどいとは思うんだよな
うん
環境の用意からそのプロンプトチューニングまで
うん
それで言うとだからその
なんて言ったらいいんだろう
モデルをプラガブリにするみたいな話ももちろんある一方で
ハーネスのそのパーツパーツをプラガブリにする
みたいな話も多分あると思うんだよね
で
まあ
理屈はそうだけど
うーん
なんか現実はそんな綺麗にならない気がすんだよな
どうなんだろう
うーん
なんかもっと多分コンポーネントが細分化されていくんだろうなと思っていて
そのクラウドフレアのあの話とかもそうだし
その
うーん
いろいろ出てるじゃんそのバーセルのさディープセックとかもそうだったと思うけど
あれはどっちかというとその
攻撃面とかその要はコードパスのメタデータを先に生成して
それに対してスキャンをかけるよみたいな
アプローチだったと思うんだけど
なんかあれってどっちかというと
ハーネスの一部のコンポーネントを担う
ような機能をやっていると思っていて
うーん
いやーなんかそれ待ってたら
結構
だいぶ先になっちゃう気はするけどね
なんかスポット成熟しないと
そこがそこがだからその
なんて言ったらいいんだろう
どういう風になっていくかをある程度見越して
なんかこう要は
部分部分で入れ替え売るっていう
前提で多分ワークフロー組んでいく
っていうのをやった方が良くって
うーん
そうね何ステップかあるよね
みたいな部分の分解とかもそうだし
例えばだけどその
アタックサーフェイスを先に
列挙してあげて
そのうちの重要度を
相当してあげた上で
上から順に見ていくんだよみたいなステップとかが
あるよねみたいな部分を
なんていうかじゃあどうやって
そこをプラグラムにしておくんですかコンポーネント化しておくんですか
みたいな話とか考えないといけないような気がしていて
多分裏で
そのやってるのは多分そういうことなんだと思うんだよね
AWSにしても
なんか
クラウドフレアのあれにしても
そうね
まあまあそうね
そう電話が出てきたら置き換えていく
っていうのが多分必要で
まあでも結構なんか上り切った後の
話な気はするけどな
なんか上る前に考えることじゃない
気はする
いやでも違う
でも上り方はやっぱ考えとかないと
厳しいような気がしてて
多分ミニマムでこう絶対あるよねみたいな話は
そのイシュートラッカーとの連携の部分とかもあるよね
その重複の話とかさ
クラウドフレアだったけど
イシュートラッカーを
見るっていうのもそうだし
イシュートラッカーでそのレポートされたものに対して
検証するその仕組みが
裏にあるみたいなのとかも
多分あると思うしきっとね
検証もそうだし
修正もそうか
修正と検証は多分
なんかまず分けられそうだな
とかあるじゃん
何をもってその検証ができた
という風にゴール設定をするのか
みたいな部分と
そのゴール設定に対して動くエージェントっていうのは
多分分けられそうだなとか
修正をするっていうのも
何をもって問題がある
っていう状態と判断するかっていう
そのピヨシポックが渡されていて
それが通らなくなったら
修正ができたんだなっていう風に
判断するっていうそのゴール設定に対して
動くエージェントは分けられそうだなとか
何の話してるんだっけ
分かんなくなっちゃった
登り方の話ですね
あとこれを
ポンと入れるのって結構
気合がいるから大変だよねっていう話をしてた
気がするな
まあそうだね
なんか
難しいな
入れて解決するよっていうプロダクトが
そのうち出てくるのかもしれなくて
ビズみたいなね
なんか
入れて学習しないといけないって感覚が
強いのかもなもしかしたら
僕は
いろんな懸念はあるけど
触んないと何も始まんないんじゃないか
それはそうだね
あるんだよな
触ってみればやれるならやったほうがいいなと思うし
なんかその
ハーネス
LLMを使ってどこまで
今時点でどこまでいけるのかとか
どこに限界値が出るのかとか
製品とかを使ったら
結構
それも
一理あるなとは思いつつ
でもその流れって
クロードコードとコーデックスの間で
反復横飛びしてる人みたいな
感じになりそうな気もするから
難しい
いいとこな気がするね
そう
でも
内製を見せるなら
どっちにしろいつか
難しいな
じゃあいつやるのって感じ
そうそう
でもAWSの
要はその
ユーザーに寄りすぎないみたいな話があると思っていて
さっきも話したけど
ユーザーに寄りすぎてると
AWSのこれを使ってみて
なんか
これを使うことしかできないっていう状態に
多分なっちゃうから
それこそそのクロードコードがいいのか
コーデックスがいいのかみたいな
割と不毛な比較に
なんていうか
それは
難しいね
じゃあ内製が正しいかっていうと
別にそんなことはないと思うから
必ずしもね
どっちがいいのか悪いのかわからんけど
どっちかっていうとプロセスにどうやって組み込みますか
っていうのを考えないといけなくて
これがそれを叶えてくれるのかみたいな話は
多分見ないといけない
これ見て検知能力がどうですかみたいな話とか
その
これの中のワークフローがどうですかみたいな話じゃなくて
なんか
実際の業務にどうやってこれを
組み込みますかっていう話を多分
しないといけないんだけど
ただそれも含めて
使ってみないとわからないっていうのは正しいので
使ってみたいんだけど
ちょっと気合がいるよねっていう
冒頭の話に戻ってくる
気合を入れて使うしかない
そうね
限界を知らないと
組み込むプロセス像が
見えてこないみたいな話もある気がするし
結構
難しいね
限界を知らないっていう話をするには
あまりにもブラックボックスだし
プロダクトとしてデカすぎるみたいな話が多分あって
そう
スキルから始めて
スキルの限界はこんなもんなんだなとか
プロンプトのチューニングを
してもこの程度なんだなみたいなステップ
ステップでやっていくっていうのは
それはそれでいいアプローチだなと思っていて
個人的にはさっきも話したけど
クラウドフレアのやり方のほうが
結構しっくりくる部分はあって
なるほどね
確かに
復帰したらやるか
お待ちしてます
復帰してこれをやる余裕があるのか
分からないけど
いっぱいあるよ
ソウタが戻ってきたらやってもらおうって
リスト化してないけど
いっぱいあるよ
リスト化しといてくれよせめて
いやいいよリスト化しなくていい
バックログに積んで
ソウタが戻ってきたら頼むリスト
7月まで
お願いします
NPMパッケージにおけるAIマルウェアスキャナー回避手法
じゃあ最後の記事いきますか
はい
サラッとでいいんですけど
ソケット
私のソケットセキュリティアムブログで
NPMパッケージ
ユーゼイズプロンプトインジェクション
ランドトークンフローディング
ディストラプトAIマルウェアスキャナー
何かっていうと
シャイフラットファミリー
シャイフラットフォークたちが
いろんなアシュが出てる中で
そのアシュの一つとして
AIで
マルウェア判定をするようなやつ
に対する防御策として
NPMパッケージ
のマルウェアのコードの中に
コメントで
プロンプトインジェクションを
試みるようなマルウェアとか
またそのトークンをめちゃくちゃ無駄に
消費させるためにわけ分からんぐらい
長い文字列を混ぜ込むみたいなものが
確認されてますよっていう話ですね
結構
面白いのが
プロンプトインジェクション
の指し方としては
目的としてはマルウェア判定されないこと
なんで結構
仮にマルウェア判定しにきてる
ってなった時に視点を
逸らすような
拡覧するような指示を埋め込んでみたり
とかまた
物量で単純に攻める数万行
のコメントを埋め込む
みたいなことをしていて
それはそうだって感じなんですけど
あくまでそのコードコメント
なんで静的解析とかには
引っかからないものの
得られればそのまま読ませちゃうと
そのコメントを文字列として
読み込んじゃうっていう部分を
指しにきてるっぽいぞ
みたいな部分の紹介記事って感じですね
うん
なんかまあ
いたちごっこのループが始まったなって感じがして
早速出てるんだなっていうのは
面白いなっていうのと
コンテキスト爆発狙うのは普通に賢いなって
思うというか
最近あんま見ないけど
絵文字でトークン爆発とか
トークンボムみたいな概念あるけど
そういうの
とかをうまく組み合わせると
割と地味だけど有効な
防衛手段になってしまうのかな
と思ったりしつつ
って感じですね
この章に関してはコメントを
静的解析で前処理で
潰しちゃえばいいのかなと思うんだけど
まあまあコード量自体を
無駄なゴミコードを増やすとかは
できると思うし
変数名にいろいろ入れるとかも
原理者は可能なのかなとか
いろいろアイディアあるよなって思って
うーん
あとなんかちょっとこの間見たけど
エアに書かせるコードは
ひたすらめっちゃコメント書かせろ
みたいなことを主張として
言ってる人がいて
え?そういうこと?
そう
ごめん趣旨は分からなくなっちゃった
俺もそんなに真剣に見てなかったし
なんかでも仮にそういう動きが今後出てくるとしたら
めっちゃその
コメントは全部先に
静的解析で弾いちゃうみたいなのと
クソ逆行するなって思うから
なんか
確かにねコメント書かせるあれかな
その
ドキュメントとして
書かせるとか
主旨としてはそんな感じ
人間が読まないのありかもな
趣味で書いてるコード
めちゃくちゃコメント書かれるんだよな
無視してる
コメント消させてるわ
なんかあえて放置して
育ててみてるけどねやっぱ
いずれ嘘になってんだよな
普通に余計なコメントは
しないに越したことないわ
今んとこはね
そう見える
スキャンするときはもう
どうなんでしょうね
AIだけでマルウェアスキャン
どうなんだろうちょっと分かんないね
匠ガードの中の人に
オフレコで話を聞きたい感じがする
こういうの実際困るんですか
とか
AIだけで判定してるわけではないとも
思うから
実際起動して通信先見るとかしてんのかな
分かんないですけど
こんなのあるんだな
さらっと紹介でした
193大会な感じがしますね
面白いね
いろんなこと考える
思ったより早く
車輪が回り始めた感じがする
なんかでもあれだね
OSSのプルリクエストの
差分にクソ長いコメント書いてたら
それ気づくか
パッケージロックJSONとかに
変な文字で混ぜられたら
気づけないんじゃないかな
差分表示されないじゃん
デフォルトで
アイデアとしては全然ありない気がする
パッケージロックJSONの中に
無意味な文字列を仕込める
スペースってあんの
ないけど
目的次第ではバリットなパッケージロックJSONで
ある必要はないじゃん
確かにパッケージ名がクソ長いとかね
そうだね
あんだけでかいファイルだから
差し込めるフィールド1個ぐらいあっても
おかしくなさそうな気がする
ちょっといや気になっちゃったな
パッケージロックJSON
見てみましょうか
フォーマットじゃなくて
なんて調べたらいいんだろう
インテグリティとかは
ライセンスとかは別に変なあたり
埋め込んでもいいんじゃない
ライセンスは確かにそうだね
インテグリティも多分
これは漕けるかな
URL埋め込める場所もあるから
そこもお好きにどうぞ
URLは確かに何とでもなるね
あと余計なフィールド生やしても
ワンチャン動かないかな
隙間
確かに余計なフィールド
確かに動きそうだね
JSONだもんね
OSとか
CPUとかのフィールドもあるな
結構いろいろあるね
知らんかったな
クソデカ
クソデカパッケージロックJSON
作ってみようぜ
画像に
埋め込むとかもいけないのかな
画像はさすがに無理か
ああいう面白いの最近見ないな
npmとかpnpmって
どれくらいのサイズのロックファイル扱えるのかな
わかんねえな
考えたことないな
普通に
DOSになるようなサイズの
パッケージロックJSON作れるんじゃない
npmインストールした瞬間にもう
なんか
ハンクするみたいな
next.jsの
パッケージロックJSONとか何行あるんだろう
僕なんかさらっと開いた自分のアプリは
6000行だったけど
どっちかというとファイルサイズでいてえな
でも
ネットサイトでは
pnpmロックか
next.jsとか
38000行
まあでもそんなもんか
リアクトの
yarn.lockは
804kb
まあテキストファイルだからタグが連れてんだな
そうだね
next.jsのやつはそれで言うと
1.25mb
それでもそんなもんか
まあよほど
変なことしなければ
なんかJSTSの
プロダクトで
クソでかいやつ
プロダクトとかソフトウェアでクソでかいやつって何があるのかな
next.jsが思いつかないな
next.jsよりでかそうなものって
なんかある
なんか
なんでもかんでも詰め込んだwebアプリぐらいしか思いつかないな
そのパッケージはさ
みんなお行儀いいからちゃんと分けてると思うんだよね
確かにね
astroとかもでかそう
まあでも806kbある
ロックファイル選手権やるか
来週まで
eslintとか
eslintもそんなにあるかな
もしかして
どうだろう
なんかいろいろ
入りそうだな
ロックファイルないじゃん
ロックファイルないんだよね
eslintそもそもなんか
めちゃくちゃ細部化されてると思うんだよな
すごい
readmeになんでロックしないのって
あれがあるのおもろ
今時ロックしろよって
話もありますからね
版はジグ
版はそもそもね
プリティアとか
知らんが
ネクストJSが一番だって
絶対そんな
そんな個別のパッケージ
大したことない
プリティアは390kb
確かにネクストJS圧倒的だな
ネクストJSを参照して
何でも無理にしてるwebアプリケーションが
絶対一番でかいよ
でも別に
ネクストJSのロックは
内包されないからさ
確かにそうだね
そうでした
内包されないわけじゃないんだけど
まあいいや
別にまるっと同じ内容が
親の
リポジトリの
ロックファイルに含まれるわけじゃないからさ
ネクストJS入りだから
それを内包するって話じゃないじゃん
そうだね
来週まで探しておいてください
もう何の話か分かんなくなっちゃって
ロックファイルソードができればいいんだよな
いいですか
そんな感じでお疲れ様でした
お疲れ様ですまた来週も
頑張りましょう
あお便りお待ちしてます
忘れてた
xgoogleフォームお待ちしてます
日本船のね
感想もお待ちしてますんで
来週も結果出てる
あーなるほどね
そう
このボットガスで
試合結果を知ってる人がいたらめちゃくちゃ面白いけど
まあお楽しみにしてください
お怒りのお便りが
届くかも
さすがにニュース見るって
そんな
これ配信されるまでには
見ておいてください
それはもうちょっと受け付けられない
次回ね
スウェーデン戦ですか
結果をお楽しみにしましょう
楽しみにしてます
じゃあそんな感じで
皆さんありがとうございますおやすみなさい
おやすみなさい
