「監視ツールは入れています。アラートも設定しています。でも障害は、ユーザーから教えてもらっています」 これを、複数の組織で聞いた。そのたびに少し複雑な気持ちになる。問題はツールではないからだ。 「入れているのに気づかない」の原因は、たいてい同じ3つの場所にある。複数の組織で同じパターンを見ていると、それが確信に変わった。設定の問題というより問いの立て方の問題だ。 「監視できている」の定義が、ずれていた 監視の目的を「インフラが正常かどうか確認すること」だと定義すると、多くの組織では「監視できている」になる。CPUは正常、メモリは正常、エラーレートも閾値内。それを見て「問題ない」と判断する。 ところがその間に、ユーザーは「画面が真っ白」「ボタンが押せない」という体験をしている。 あるチームの支援に入ったとき、まさにその状況だった。監視ダッシュボードはすべてグリーンだ。それでも「ユーザーから使

背景: 何が起きているか 2025年9月、Shai-Hulud攻撃がnpmエコシステムを直撃した。ngx-bootstrap、ng2-file-upload、@ctrl/tinycolor等の正規パッケージが改ざんされ、postinstallフックで難読化済みのbundle.jsを実行、npm/GitHub/クラウドの認証情報を窃取しwebhook経由で外部へ送信した。最終的に数百パッケージが汚染された。[1] 2025年11月のSHA1-Hulud(第2波)では、被害者をGitHub Actions self-hosted runnerに変換し、リポジトリにワークフローを注入してAWS/Azure/GCP認証情報を吸い出す手口に進化。600以上のパッケージ(Zapier、PostHog、Postman等)が影響を受けた。[2] 2026年3月にはAxiosが直接侵害された。攻撃者はメンテ

Decision Quality (DQ) は SDG が体系化した意思決定の質の枠組みで、良い意思決定の条件を6つに分解する。 Frame（解くべき問題の枠組み） Alternatives（選択肢） Information（情報） Values（評価基準） Sound Reasoning（論理的推論） Commitment to Action（実行へのコミット） 全体の質は一番弱い要素で決まる、というのがDQの中心的な主張である。意思決定そのものと、その結果は区別する。良い意思決定でも結果が悪いことはあるし、その逆もある。 設計判断の現場で繰り返し観測される失敗の多くは、6要素のうち Frame と Values の2つの取り違えで説明できる。Valuesを 評価軸 として8つに整理し、Frame の取り違えは 支配軸の取り違え として捉える。残りの4要素も副次的に絡む。早合点 は In

How to Align SEO within the Product Triangle To Get 
Buy-In & Support - #RIMC

はじめに こんにちは。GMO Flatt Security株式会社 セキュリティエンジニア(兼Claude Codeオタク)の石川（@ryusei_ishika）です。 Claude CodeやCursorなどのAIエージェントを活用したバイブコーディングが急速に広まっています。私自身、社内ではClaude Codeのリリース（ほぼ毎日）のたびにそのリリースノートの重要なポイントを解説しているほか、Biz職向けに「バイブコーディング講座」を実施するなど、社内でのAI活用の普及にも取り組んでいます*1。 リリースノートが公開されていると、出勤後すぐに便利な機能を解説する石川 昨今、AIエージェントを日常的に使い込むなかで、従来の開発では起きにくかったセキュリティリスクが顕在化しつつあると感じています。例えば、先日AIエージェント経由で.envの認証情報が漏洩し、外部サービスのアカウントが乗っ

20- スイス おそらく多くの人が、この国がランキングでもっと上位にいると期待していたでしょうね… 実際には、フランス語圏の部分が多くのポイントを減らしています（人口が現在のフランスに非常に似ていて、何を指しているか分かると思いますが） それが安全性の感覚をかなり下げてしまうし、しかもスイスにいるという感じがしないんです。 とはいえ、リストには入りますよ。ドイツ語圏の部分は本当に絵になるんです。 Pato Bonato @patobonato 19- Emiratos Árabes Unidos 🇦🇪 Un lugar que es de los más seguros del mundo, te da la tranquilidad de que podes caminar a cualquier lado, por cualquier lugar. No lo ubico más

本記事は2026年4月25日時点で公開されている情報に基づきます。事件の最終的な影響範囲・攻撃手法の詳細は今後の公式発表で更新される可能性があります。 はじめに 2026年4月24日、クラウドファンディング国内最大手の 株式会社CAMPFIRE が、最大 22万5846人分 の個人情報が漏えいした可能性があると発表しました。プロジェクト実行者の口座情報や支援者の住所など、極めてセンシティブな情報が対象です。 事件の起点は GitHubアカウントへの不正アクセス。「GitHubが侵害されただけでなぜ顧客情報が？」と思った方は多いのではないでしょうか。本記事では、公開情報から事件の経緯と攻撃の流れを整理しつつ、エンジニアとして組織を守るために今すぐ見直すべきポイントをまとめます。 何が起きたか — タイムライン CAMPFIREが段階的に公表してきたプレスリリースをもとに、時系列を整理します。

Docker Sandboxesは、Claude Code、Gemini CLI、Codex、Copilot、Kiroなどのコーディングエージェント向けに特別に設計された、使い捨て可能で分離された実行環境です。 エージェントには自由が必要です。マシンには必要ありません。 コーディングエージェントは無人で実行されるときに最も効果を発揮します。しかし、現在の選択肢にはトレードオフがあります。: OSレベルのサンドボックスはワークフローを中断させることがあり、プラットフォームごとに挙動も異なります。 コンテナは、エージェント自身もDockerを必要とするようになるまでの一つの選択肢です。 フルVMは遅く、リソース消費が大きく、リセットも容易ではありません。 許可プロンプトは自律性ではありません。本当に必要なのは分離です。 Docker Sandboxesは、エージェントに実際のシステム環境を提供

クエリが遅くなった。直そう。ここから問題が始まる プロジェクト管理SaaSを1年ほど運用すると、Issueテーブルが200万行、変更ログテーブルが2000万行を超えてくる。ソフトデリートを採用していれば物理削除されないので、行数は増える一方だ。 最初の兆候はユーザーからの報告だった。「Issue一覧の読み込みが遅くて、フィルターを切り替えるたびに5秒くらい待たされるんですが」。スロークエリログを見ると、フィルター付きのIssue一覧クエリがp95で3秒を超えている。インデックスを追加すれば改善する。スキーマ変更も1つ控えていた。どちらもやること自体は明確だった。 問題は「200万行のテーブルにDDLを打つ」という行為そのものにあった。膨れ上がったテーブルに対するスキーマ変更は、パフォーマンスを改善するための作業が、新たな障害を引き起こす可能性を持っている。治療のための手術が患者を殺しかねな

セキュリティグループのCIDR設定について、同じ指摘を3回レビューコメントに書いた。1回目は「うっかり」で済ませ、2回目で「仕組みで防げるな」と思い始め、3回目のとき「これはレビューで防ぐ問題ではない」と腹が決まった。 アプリ開発者からキャリアをスタートしSREに転向し、Webサービスの立ち上げからPlatform SREまで4社で担ってきた。あるWebサービスのSREチームで、Policy as CodeをCIパイプラインに組み込んだ。この記事はその記録だ。 何が問題だったか 当時、複数の開発チームがTerraformでインフラを管理していた。変更のたびにSREチームへのレビュー依頼が来る運用だったが、問題が2つあった。 一つは「レビュアーによって指摘内容が変わる」ことだ。自分がいるときはセキュリティグループの開放範囲を必ずチェックするが、別のメンバーが担当した日は見落とされることがあっ

https://dev.classmethod.jp/articles/claude-code-security-basics/

GitHub Quick Review (ghqr) is a powerful command-line interface (CLI) tool that analyzes GitHub enterprises, organizations, and repositories to ensure compliance with GitHub best practices and security recommendations. Its main objective is to offer users a comprehensive assessment of their GitHub resources, allowing them to easily identify security gaps, misconfigured settings, and areas for impr

Harness Engineering Meetup Tokyo #1、TOPバッターとして、ハーネスエンジニアリングについての導入的説明を行いました。

追記: セキュリティ監査の仕事がAIに代替されるということを言いたいわけではありません。監査でのチェックに含める項目など、セキュリティがやっていることの全般的な枠組みに変革を余儀なくされるということを書いています。ぜひ最後までお読みいただき、奇譚なき意見をください。 2026年4月、AnthropicはClaude Mythos Previewを公開した。このモデルは数千件のゼロデイを自律的に発見したと報告され、Mozilla Firefox 150はこのモデルで発見された271件の脆弱性を一括パッチした。一方でAI自動ペンテスト企業XBOWはHackerOneのリーダーボードを席巻している。セキュリティ業界は数年以内に、「コードの脆弱性を見つける」という課題をほぼ自動化可能な問題に変えるだろう。しかし、この事実はセキュリティ業界にとって勝利ではない。むしろ、いま売られているセキュリティ商

社内のチームメンバー(クラウド事業本部コンサルティング部)向けに 「 Claude Code を安全に使おう勉強会 」を開催しました。 Claude Code をセキュアに使う上での、 基本的な考え方や権限/サンドボックス機能の紹介、簡単なデモを実施しました。 DevelopersIO向けに調整したスライドを掲載します。 以下勉強会で連携した設定サンプルです。 Claude Code を安全に使おう勉強会: 補足資料 - Gist スライドの内容:テキスト情報を以降に記載します。参考になれば幸いです。 イントロ 勉強会の目的やアジェンダ、スコープについて話します。 勉強会の目的 Claude Code (に限らず、AIエージェント) はとても便利です。 しかしリスクもあり、暴走もします。 この勉強会では、 Claude Codeが適切な範囲で適切に動けるような、 ガードレールの敷き方 を学

先日登場したAnthropicの新しいモデル「Mythos」に関して、非常に興味深い話が流れてきました。マーク・フィッシャーとトマス・ネーゲルという二人の哲学者（思想家）によく言及するようなのです。これはAnthropicが新しいモデルを公表するたびに都度公開しているシステムカードに書かれており、大変興味深い事象だなと思いました。 The model brought up the British cultural theorist Mark Fisher in several separate and unrelated conversations about philosophy. When asked to elaborate on him in particular, Claude Mythos Preview would respond with statements like “

Matt Pocockさんが作った「grill-me」というAgent Skillsが、とてもシンプルなのですがとても良いので紹介したいと思います。 たった3行のスキル Agent Skillsってだいたい数十行〜150行くらいあるものが多い印象ですが、なんと grill-me はたったの3行。 この計画のあらゆる側面について、私たちが共通の認識に達するまで、徹底的に私に質問を投げかけてください。 設計のツリーを枝分かれの先まで一つひとつたどり、決定事項間の依存関係を順番に解決していきましょう。 各質問に対し、あなたの推奨する回答も併せて提示してください。 質問は一度に一つずつお願いします。 もしコードベースを探索することで答えが得られる質問であれば、質問する代わりにコードベースを調査してください。 こんな短い記述で何が変わるの？という感じですが、コーディングエージェントの挙動がガラッと変

1. はじめに こんにちは！はるぷです！サプライチェーン攻撃の対策してますか？？ 最近、サプライチェーン攻撃の話題が出るたび、「うちのサービスは本当に大丈夫だろうか」と社内がざわつくことはありませんか。依存ライブラリの棚卸しやSBOM整備に取り組んでいても、入り口が多すぎて全体を把握するのは至難の業です。 加えて、社内外から「サプライチェーン攻撃対策大丈夫ですよね？」と聞かれたとき、担当者として胸がキューっとなる辛い状態になりがちです。何かしらビシッと説明できるシステム的な一手が欲しい…。 そこで今回は、 「万が一、侵入を許してしまった後の早期発見」 に特化した対策を紹介します。 サプライチェーン攻撃によって不正コードが混入すると、多くの場合、外部のC&Cサーバ(攻撃者の司令塔)と通信を開始します。つまり、この「意図しない外向きの通信」をいち早くキャッチできれば、被害が拡大する前に食い止め

注: 本記事は執筆時点(2026年4月)の情報をもとに書いています。実際のご利用にあたっては、公式ドキュメント等の最新情報を参照し、正確性を確認の上ご利用ください。 さて、axiosへの攻撃の件で、サプライチェーンアタックの恐ろしさを改めて感じさせられました。外部ライブラリを使う場合、基本的にはセキュリティ面も含めて最新バージョンを使いたいわけですが、その更新作業は脆弱性が入り込みやすいタイミングでもあるというジレンマがあるわけです。 なので、以下のようなポリシーとフローでの外部ライブラリ利用が現状の推奨要件と言えるでしょう。 基本は最新バージョンを使う 機能面、パフォーマンス、セキュリティ面でより良い 追随を怠ると更新が困難になり、新機能が使えないだけではなく、セキュリティリスクも高まる ただし、新バージョンリリース直後ではなく、しばらくしてから最新版を適用する 最新バージョンに問題が無

スライド概要 無償・OSSから始める、コンテナ脆弱性管理負荷を大幅に削減する新しいアプローチ https://dockerjapan.connpass.com/event/388164/ 多数のOSSで構成されているコンテナイメージは、近年急増する脆弱性を狙ったサプライチェーン攻撃の主要な標的となっています。Docker ではこれに対するアプローチとして、脆弱性や依存関係を大幅に削減したデフォルトで安全なイメージ「Docker Hardened Images(DHI)」をリリースし、2025年12月に Community Edition として一部無償・オープンソースで提供しました。 このセッションではこの DHI の仕組み・哲学から既存のコンテナイメージからの移行方法、エンタープライズレベルのSLA・コンプライアンスを適用する方法までご紹介します。 ・Docker Hardened Im