#セキュリティ

Claudeの安全対策と聞くと、つい「危ないことをしそうなら止める仕組みかな」と思いがちですが、今回のInfoQの記事で面白いのは、Anthropicがその発想をかなり冷たく、そして現実的に捉えているところです。要するに、モデルそのものを賢くするだけでは足りない。ファイルに触れられる範囲、ネットに出られる範囲、実行できる範囲を、環境側でガチガチに制限しないとダメだ、という話です。 この考え方、地味に見えてかなり重要です。AIの安全性というと、プロンプトに注意書きを入れるとか、危ない出力を検出する分類器を挟むとか、そういう「ソフトな制御」がまず浮かびます。でもAnthropicは、そういうものは効くときもあるが、保証にはならない、と割り切っています。個人的にはここがいちばん筋がいいと思いました。AIは人間みたいに「まあ今回はやめておこう」と自制してくれる存在ではないので、最後は環境で縛るしかない、という発想です。 Claudeの安全対策は、モデル内部の注意喚起よりも「実行環境の制限」を重視している Claude.ai、Claude Code、Claude Coworkでは、それぞれ危険の

1Passwordが、Claude向けの新しいブラウザー連携を出しました。これが何を変えるのかというと、AIエージェントがログイン作業を手伝えるのに、パスワードそのものは見なくて済むようになる点です。 地味に見えますが、これはかなり大きい。 AIに「このサイトに入って、あの作業をして」と頼むとき、いちばん怖いのは“中身を全部見せること”でした。パスワードや認証情報は、AIに渡した瞬間から扱いが難しくなる。そこを1Passwordは、端末上で復号し、作業ごとにユーザーの許可を挟むという形で解こうとしています。 ClaudeのAIエージェントが、1Passwordの認証情報を使ってWeb操作できる ただし、パスワード自体はAIに見せない設計 復号は端末側で行うため、認証情報がむやみに外へ出にくい 操作のたびにユーザー承認を求めるので、勝手に進む感じではない いわゆる「AIに権限を渡す」問題に対する、かなり実務寄りの答えに見える この記事で面白いのは、単なる便利機能の話ではなく、AI時代の「ログイン」をどう安全に扱うかという、かなり面倒で重要な問題に踏み込んで

Anthropicが、コードを書いている途中で脆弱性を見つけて警告してくれる「security-guidance」というプラグインを、Claude Code向けに無償提供しました。しかも対象は特定プランだけではなく、すべてのClaude Codeユーザー。こういう「便利だけど高そう」な機能を最初から広く配るのは、かなり攻めた打ち方だと思います。 Claude Code向けの新しいプラグイン「security-guidance」が公開された コード編集の流れの中で、リアルタイムに脆弱性を検出して警告する 仕組みは「Hook」を使った自動実行で、手動で毎回呼び出す必要はない 監査は3段階で行われる - ファイル編集時 - ターン終了時 - コミット時 危険なライブラリの誤用、危ないデシリアライズ、DOM操作、認証バイパスなどを検出対象にしている Anthropicの内部テストでは、プルリクエストへのセキュリティコメントが30〜40％減ったという インストールにはClaude Code CLI v2.1.144以降とPython 3.8以降が必要 今回の話で面白いのは、セキュリティチェックを

Model Context Protocol（MCP）の世界で、かなり実務的で、しかも地味に効くアップデートが正式版になりました。 その名も Enterprise-Managed Authorization（EMA）。ざっくり言うと、「社内のID管理基盤でMCPサーバーへのアクセスをまとめて管理できる仕組み」です。 MCPは、AIアシスタントや開発ツールが外部サービスとつながるための共通規格として広がってきました。ただ、企業で使うとなると、思った以上に面倒が多い。サーバーごとにOAuthの許可画面が出て、社員が一人ずつポチポチ承認していく。これ、個人利用ならまだしも、組織運用だとかなりしんどいです。今回のEMAは、その“しんどさ”をかなり正面から潰しにいっています。 Enterprise-Managed Authorization（EMA）がstableになった 企業はIdP（Identity Provider）でMCPサーバーへのアクセスを一元管理できる ユーザーは初回ログイン時に自動で接続され、サーバーごとのOAuth許可が不要になる アクセス制御は

ゆうちょ銀行の通帳やアプリを久しぶりに記帳したら、身に覚えのない「ゆうちょリヨウキヨク20595」のような行を見つけて青ざめた——という報告はSNSでも定期的に見かける。結論から言うと、これは不正利用の証拠ではなく、ゆうちょ銀行のATMネットワークが取引記録に付与する局番号入りの取扱店識別子だ。中身は難しくない。エンジニア視点で見ると、レガシーな勘定系システムが抱えがちな「表示制約」の実例として面白い。 まず引っかかるのが、コンビニで下ろしたはずなのに「ゆうちょ」と印字される点だ。ファミリーマートに設置されている緑色のATMは、実はファミリーマート自前の機械ではなく、ゆうちょ銀行が設置・運用しているATMである。つまりコンビニのATMを使っても、勘定系から見れば「ゆうちょのATMを使った」という扱いになり、通帳には郵便局の窓口やATMで取引したときと同じフォーマットで記録が残る。ローソンやミニストップなど他チェーンでも同様の提携パターンがあり、見た目のブランドと処理系統が一致しないケースは珍しくない。 「リヨウキヨク」の後ろに続く5桁の数字は、取引が行われた取扱局（支店・ATM

GitHubのopenai/codexリポジトリに、ちょっと地味だけどかなり重要な要望が出ています。内容はシンプルで、AIエージェントに読ませたくないファイルを明示的に除外したい、というものです。 これ、派手さはないんですが実際にはかなり大事です。AIにコードを書かせる時代になっても、「これは見せていい」「これは絶対にダメ」の線引きは、人間がしっかり持っていないと危ない。そこをちゃんと仕組みにしよう、という提案です。 このIssueで求められているのは、エージェントが読み込んだり、モデルに送ったりしてはいけないファイルやパスを明示できる機能です。 しかも単なる一時的な指定ではなく、次の2段階を想定しています。 リポジトリごとの設定 ユーザー全体のグローバル設定 たとえば、プロジェクト内に `.codexignore` のようなファイルを置いて「このリポジトリではこのファイル群は触るな」と定義する。一方で、ユーザー側にも「どのプロジェクトでも `.env` や秘密鍵っぽいものは見せない」という共通ルールを持てるようにしたい、という考えです。 ここで面白いのは、**“プロジ

Semgrepは、IDOR（本来見えるべきでない他人のデータに触れてしまう脆弱性）を見つけるベンチマークで、いくつかのモデルを同じ条件で比較した その結果、open-weightモデルのGLM 5.2が、素のプロンプトだけでClaude Codeを上回った ただし、Semgrepの自社パイプラインは依然として強く、モデル単体の勝負とは別のレイヤーで性能を引き出している この記事の本質は「どのモデルが一番強いか」より、「ハーネス（周辺の仕組み）がどれだけ効くか」を切り分けた点にある open-weightは、社内環境で動かしやすいので、セキュリティ用途ではかなり魅力があると思う Semgrepのこの記事、AIモデルのランキング発表に見えて、実はかなり地味で重要な問いを突いています。 「脆弱性検出の性能って、モデルそのものの力なのか、それとも周辺の仕組みの力なのか？」という話です。 これ、地味ですがめちゃくちゃ大事です。 生成AIの世界では、つい「どのモデルが最強か」に目が行きがちです。でも実務では、モデル単体よりも、どうやってコードを読ませ、どこを見せ、どう検索させ、どう結果を整えるかの

bunny.netが、Bunny DNSのDNSクエリ課金を完全に撤廃しました。 ざっくり言うと、DNSの問い合わせ回数に応じて料金が増える仕組みをやめた、という話です。しかも「無料化」と言っても、ただの宣伝文句ではなく、クエリ数の上限なし・リクエスト単位の課金なしまで踏み込んでいます。 DNSは普段あまり意識しない仕組みですが、Webサイトやアプリにとってはかなり重要です。住所録みたいなもの、と説明されることが多いですが、bunny.netのDNSはそれよりずっと賢い。単に名前をIPアドレスに変換するだけではなく、遅延や稼働状況を見て、どこに通信を振るかまで決められる“ルーティングエンジン”寄りのDNSです。ここがこの発表の面白いところだと思います。 bunny.netは、Bunny DNSについて次のような変更を発表しました。 DNSのクエリ課金を廃止 DNS hostingは1アカウントあたり500ドメインまで無料 クエリ数の上限なし 1リクエストごとの課金なし smart records や health monitoring も

AnthropicのAIモデル「Mythos」を、独立系の開発者コミュニティが“セキュリティバグ探し”で試している、というのが今回の話です。元記事のテーマはかなり率直で、「このモデルは脆弱性を見つける力が本当にあるのか？」を、机上の宣伝ではなく実戦寄りのベンチマークで確かめようとしている、というものです。 AIの話はすぐに盛られがちですが、セキュリティの世界はそんなに甘くありません。バグを見つけるのは、ただコードを読むだけではなく、「ここ、妙に危ないな」と違和感を拾う作業でもある。だからこそ、Mythosのようなモデルがどこまで通用するかは、かなり面白い試金石だと思います。 独立系の開発者コミュニティが、AnthropicのMythosを脆弱性検出で検証している 目的は「AIがセキュリティバグを見つけられる」という主張の実力確認 ベンチマークは、宣伝文句ではなく実際の検出能力を見るためのもの AIがコードレビューやデバッグを助ける可能性はあるが、過信は禁物 セキュリティ領域では、AIの“それっぽさ”より再現性と正確さが重要になる 元記事のタイトルは少し遊び心があります。`Will it

2,000人以上が参加し、6,000通超のメールでAIアシスタントを攻撃した 目的は、`secrets.env` という秘密情報ファイルの中身を漏らさせること 結果は、一度も漏えいなし。無断返信も成功しなかった ただし、実験中にGoogleのメールアカウント停止やAPI料金の増加など、運用面のトラブルはかなり起きた 著者は、AIエージェントに強い権限を持たせるのはまだ危ない、と考えている それでも、思っていたより prompt injection（指示のすり替え攻撃）に強かった、というのがこの実験の意外な結論 Fernando Irarrázavalさんが公開したのは、かなり実地っぽいセキュリティ実験です。 自作のAIアシスタント「Fiu」に、誰でもメールを送りつけられるようにして、なんとか秘密情報を吐かせようとする。いわば「AI相手の公開耐久テスト」ですね。 狙われたのは `secrets.env` の中身です。`.env` 系のファイルは、アプリのAPIキーやパスワードなどを入れることが多いので、漏れたら普通にまずい。そこをAIに読ませ、しかもメール返信機能まで使わせて、だ

GitHubが、`actions/checkout` の最新版で、よくある「pwn request」攻撃パターンをブロックするようにしました。 ざっくり言うと、権限の強いワークフローの中で、信用できないforkのPull Requestコードをうっかり実行してしまう事故を減らすための変更です。 これ、地味に見えてかなり大事です。CI/CDやGitHub Actionsを触っている人なら「まあ注意していれば大丈夫でしょ」と思いがちですが、攻撃者はその“うっかり”を狙ってきます。しかも `pull_request_target` は、仕組みを理解していないと本当に危ない。 `actions/checkout` v7 が、fork由来の危険なPull Requestのチェックアウトをデフォルトで拒否 対象は主に `pull_request_target` と、条件付きで `workflow_run` GitHubは「pwn request」の典型パターンを減らしたい考え 必要なら `allow-unsafe-pr-checkout: true` で回避もできる ただし、これでActi

Cloudflareが、self-managed OAuth をすべての開発者に開放しました。 これ、地味に見えてかなり大きなニュースです。というのも、OAuthは「外部アプリに、どこまで何を許可するか」を安全に扱うための仕組みで、SaaS連携や社内ツール、いま流行りのagentic toolまで、あちこちで土台になっているからです。 Cloudflareは自社のAPIを使って自動化やCI/CD、各種連携を作れる強いプラットフォームですが、これまでは第三者向けのOAuthは一部の手動オンボーディング済み統合に限られていました。 つまり、誰でも自由に「Cloudflare用のOAuthアプリ」を作れる状態ではなかったわけです。 その制限が外れた。ここが本題です。 CloudflareのOAuthが、限られた提携先だけでなくすべての開発者に開放された API token中心の運用よりも、権限を細かく分けやすく、取り消しもしやすい その裏側では、OAuthエンジンの大規模アップグレードをかなり慎重にやっていた データベース移行は派手。1億件超の更新・挿入が走っ

Googleが2026年6月に公開した記事は、かなり重要です。というのも、Gemini 3.5 Flash に computer use が標準機能として組み込まれたからです。これまで computer use は Gemini 2.5 の専用モデルとして提供されていましたが、今度はメインの Flash モデルに内蔵された、という話です。 地味に見えて、これはかなり大きい。 AI が「文章を返す」だけでなく、画面を見て、理由を考え、クリックや入力まで行う方向へ、実用のレベルで一歩進んだ感じがあります。個人的には、ここは生成AIの見え方が変わる節目だと思います。 Googleの説明をかみ砕くと、Gemini 3.5 Flash に「computer use」という道具が最初から入った、ということです。これを使うと、AI エージェントを作る人たちが、ブラウザ、モバイル、デスクトップをまたいで動く自動化を組みやすくなります。 ここでいう AI エージェントは、単に質問に答えるAIではありません。 「このサイトを開いて、必要な項目を探して、フォームに入れて、次の画面に進

Califが、Apple M5搭載のmacOSで動くカーネルのメモリ破壊系エクスプロイトを公開した 対象は、Appleの新しい防御機構 MIE（Memory Integrity Enforcement） が有効な環境 ローカルの一般ユーザー権限から root シェルまで到達する、権限昇格の攻撃チェーンだという 研究チームは、脆弱性発見から約5日で動作する exploit を作ったと主張している 詳細な技術情報は、Appleが修正を出したあとに公開する予定 個人的には、「新しい防御は無敵ではない」という現実をかなり強く突きつける話だと思う セキュリティ研究者グループの Calif が、Appleの最新チップ M5 上で動くmacOSに対して、カーネルのメモリ破壊系脆弱性を使った公開エクスプロイトを作った、と発表しました。 ざっくり言うと、これは 「Macのかなり深いところ、OSの中核である kernel を攻撃して、管理者権限より強い root 権限まで上がれる攻撃を実際に動かした」 という話です。 しかも相

`Copy Fail`（CVE-2026-31431）は、ローカルの未特権ユーザーがroot権限を奪える脆弱性として公開された Podmanのrootless containerでも、この脆弱性でコンテナ内のrootシェルは取れてしまう ただし、Podmanのrootless構成では、ホスト全体への被害はかなり抑えられるのが重要なポイント 理由は、Podmanがuser namespaceとLinux capabilitiesを使って、コンテナのrootをホストrootと切り離しているから とはいえ、`read-only`化、capability削減、使えるコマンドの制限、firewallなど、防御を重ねる設計はやはり大事 コンテナの脆弱性の話は、どうしても「結局、全部危ないの？」で終わりがちです。 でも、Gabriel Garrido氏の記事はそこをもう一段深く掘っていて、Podmanのrootless containerは何が強くて、何が弱いのかをかなり実感しやすい形で説明していました。個人的には、こういう「理屈だけじゃなくて、実際に

dnsmasqで深刻なセキュリティ脆弱性が6件見つかったと案内された 対象はかなり古い版を除く、ほぼすべての非古参バージョンに及ぶ 既にCERT経由でベンダーへ事前共有されており、各社の修正版配布が期待されている 2.92安定版向けに2.92rel2が公開され、パッチが適用済み 開発版でも修正は順次取り込まれ、2.93rc1のタグ付けと早期の安定版リリースが予告されている 作者は、AIを使ったセキュリティ調査の急増で、脆弱性報告の整理がかなり大変になっていると述べている dnsmasqの作者 Simon Kelley 氏が、メーリングリストでかなり強いトーンの告知を出しました。内容をざっくり言うと、「dnsmasqに深刻な脆弱性が6件あり、今日CERTからCVEが公開される。修正版も出したので急いで更新してほしい」という話です。 dnsmasqは、DNSキャッシュやDHCPなどをまとめて扱える軽量ソフトです。家庭用ルーターや小さなサーバー、組み込み機器など、意外なほど広い場所で使われています。 つまり、ここで「深刻」と言われるのは

Project Zeroが、Pixel 10向けに新しい0-click exploit chain（ユーザー操作なしで成立する攻撃のつながり）を公開した 以前のPixel 9向け攻撃は、Dolbyの脆弱性を起点にAndroidのroot権限へ到達するものだった Pixel 10では、前回使ったBigWaveドライバが載っていなかったため、代わりにVPUドライバを発見して突破口にした そのVPUドライバには、mmapの実装ミスにより、ユーザー空間からカーネルメモリを読み書きできる致命的な欠陥があった しかも攻撃の成立に必要なコードはわずか5行、フルエクスプロイトも1日未満で作れたという ただし、Googleの修正対応は前より改善しており、報告から71日で修正されたのは評価できる Google Project Zeroが、Pixel 10で使える0-click exploit chainを公開しました。 0-clickというのは、名前の通り被害者が何も操作しなくても成立する攻撃のことです。たとえば怪しい

「いつものマクロ付きブックを開いたら、黄色い『コンテンツの有効化』ボタンが消えて、赤い『セキュリティ リスク』バーになっていた」——これが2026年のExcelマクロ問題の象徴だ。原因の構図は数年前から大きく変わっている。最大の転換点は、インターネット由来のファイル（MOTW = Mark of the Web 付き）のVBAマクロを、Officeが既定で問答無用にブロックするようになったこと。昔のように「有効化」を1クリックでは動かせない。本稿では2026年時点で本当に効く対処を、頻度と効果の高い順に整理する。 :::chat me|9:02|先輩、昨日まで動いてた集計マクロが今日いきなり「セキュリティリスク」って赤帯出て動かないんですけど…！ pro|9:03|それ、たぶんファイルをメールかチャットで受け取り直したでしょ me|9:03|あ、はい。Teamsで再共有してもらいました pro|9:04|それが原因。ネット越しに来たファイルには「MOTW」って印が付いて、Excelがマクロを自動ブロックするの。2022年から既定でそうなってる me|9:04|「コンテンツの有効

GitHubは、社員1人の端末に悪性のVS Code extensionが入ったことをきっかけに、約3,800件の内部リポジトリへの侵害を確認した。 現時点でGitHubは、影響を受けたのは社内リポジトリのみで、顧客データが外部で漏えいした証拠はないとしている。 攻撃者側はBreachedフォーラムで、約4,000件のprivate codeを持ち出したと主張し、5万ドル以上で売ろうとしていた。 後続の更新では、この事件はTanStackのnpmサプライチェーン攻撃と関連づけられ、社員がNx Console extensionの悪性版を入れたとされている。 こうした事件は、「便利な開発ツール」がそのまま攻撃入口になることをはっきり示していて、かなり嫌な現実だと思う。 BleepingComputerによると、GitHubは約3,800件の内部リポジトリが侵害されたことを認めました。きっかけは、GitHub社員の1人が悪性のVS Code extensionをインストールしたことです。 VS Code