セキュリティ

TL;DR: SOPS で暗号化していた API トークン複数種が GitHub Actions の workflow log に平文で露出した。原因は 「masking 登録ループが存在しない一時ファイルから読まれていて空回りしていた」 という pre-existing なバグ。gh run delete でログ削除 + 該当 secrets を rotate して被害を抑制。再発防止のため 構造的予防 (source-from-file) + 静的検知 (lint) + ドキュメントルール + PR レビュー時 security review の 4 層で対策。 0. 文脈 ある社内自動化基盤の Phase 0 検証中、workflow_dispatch で配信 workflow の dry_run を初めて起動したところ、復号済 secrets が workflow ログの env header に平文表示された。本記事はその post-mortem である。 技術スタック: GitHub Actions (Linux runner) SOPS + age による secrets 暗号化（リポ内 commit） LLM ベースの workflow agent (custom action 経由) による skill 実行 メッセージング基盤 / CRM / 課題管理 SaaS への API トークン群 1. 何が起きたか dry_run 検証で起動した workflow の途中 step、Run skill step の env: block 表示で複数の API トークンが平文表示された: ...

「Claude に作らせたアプリを即デプロイして稼ぐ」——この流れが加速する一方で、セキュリティや法的義務を丸ごとスキップしたまま本番リリースしてしまうケースが急増している。トルコのデザイン系インフルエンサー Yiğit Akın Kaya が X（旧Twitter）に投稿した辛辣なツイートが、エンジニアコミュニティで話題になっている。 「バイブコーダーに悲しいお知らせ。Claude にアプリを作らせて即リリース、即マネタイズしようとしていた連中が、次々と法廷に引きずられ始めている」 この記事ではそのツイートをもとに、AIで高速開発したアプリを本番公開する前に必ず確認すべきセキュリティチェックリストを日本語でまとめる。 なぜ今、バイブコーダーが訴訟リスクを抱えるのか Claude や GPT-4o などの LLM を使えば、数時間でそれなりの外観と機能を持つ Web アプリが作れる。しかしツイートが指摘するように、開発者の多くが「派手なUI」には投資するが「退屈なセキュリティと基盤」はスキップしてしまう。 問題は、セキュリティ上の欠陥はサービス開始後に顕在化することだ。個人情報漏洩・不正アクセス・著作権侵害・プライバシーポリシー不備——これらは各国の規制（日本なら個人情報保護法、EUなら GDPR など）に抵触し、法的責任を問われる。 本番公開前に確認すべき5つのセキュリティチェックリスト ツイート原文（トルコ語）では 5 つの項目が挙げられている。日本のコンテキストに合わせて補足する。 1. SQL インジェクションと XSS の脆弱性スキャン LLM が生成するコードは、入力値の検証やエスケープ処理を省略しがちだ。 1 2 3 # OWASP ZAP による簡易スキャン例 docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py \ -t https://your-app.example.com SQL インジェクション: ORM やプリペアドステートメントを使っているか確認する。生の文字列結合で SQL を組み立てていたら即アウト。 XSS: ユーザー入力を HTML に埋め込む箇所では必ずエスケープ処理を入れる。React / Vue はデフォルトで対策済みだが、dangerouslySetInnerHTML や v-html の使用箇所は要チェック。 2. .env ファイルの漏洩防止 API キーやデータベース接続文字列が .env ファイルに入っていたとして、それが意図せず公開されていないか確認する。 ...

Claude Code をはじめとする AI エージェントの運用で 「シークレットをどこにどう置くか」 は避けて通れない設計判断になります。Git リポジトリに暗号化したまま置ける SOPS（旧 Mozilla SOPS、現在は CNCF Sandbox プロジェクト）は GitOps と相性がよく、小〜中規模のチームや個人開発では有力な選択肢の一つです。 ただし、シェルやファイル操作の権限を持つ AI エージェントと組み合わせる場合、「AI が自分で復号して中身を覗き見・漏洩させない」 ための3つのガードレール設計が前提になります。本記事では SOPS のメリットと AI エージェント特有のリスク、そして推奨構成をまとめます。 SOPS を AI エージェント運用で使うメリット SOPS は「Git リポジトリに暗号化したまま秘匿情報を保存できる」シンプルなツールです。AWS KMS、GCP KMS、Azure Key Vault、age、PGP など、環境に合わせた暗号化バックエンドを選べます。 AI エージェントとの相性で見ると、特に次の3点でメリットがあります。 構成管理の簡素化 — 開発環境（.env など）とデプロイ環境の秘密情報を、同じ Git ワークフローで一貫管理できる diff が読みやすい — SOPS は YAML / JSON の 値だけを暗号化 し、キー（変数名）は平文で残せるため、AI エージェントが「どんな設定項目があるか」を構造として理解できる 柔軟なバックエンド — クラウド KMS から手元の age キーまで、用途に応じて使い分けられる 特に「キー名は平文・値だけ暗号化」という設計は、AI エージェントに「設定の存在は知らせるが値は見せない」運用と非常に親和性が高い構造です。 なお、マネージド型のクラウドサービスでシークレットを集中管理したい場合は、Infisical のような選択肢もあります。「Git で持つか／サービスで持つか」は採用判断のポイントになります。 AI エージェント特有のリスク 一方で、Claude Code のように Bash 実行権限を持つエージェントに SOPS を扱わせると、以下のリスクが顕在化します。 ...

RBAC（Role-Based Access Control：ロールベースアクセス制御）とは、ユーザーに直接権限を与えず、ロールを介して権限を管理する仕組みです。 AWS の IAM、Kubernetes、GitHub、Microsoft 365 など、現代のほとんどのプラットフォームがこの考え方を基盤にしています。 一言で言うと、「社員一人ひとりに鍵を渡すのではなく、役職ごとのマスターキーを管理する」仕組みです。本記事では RBAC の基本構造、必要性、ABAC との違い、AWS IAM・Kubernetes での実装例までをまとめます。 RBAC の基本構造 RBAC は主に 3 つの要素の組み合わせで成り立っています。 ユーザー (User) — システムを利用する個人 ロール (Role) — 「管理者」「編集者」「閲覧者」といった役割。権限の集合体 パーミッション (Permission) — 「ファイルの読み取り」「データの削除」といった具体的な操作権限 ユーザーは直接パーミッションを持つのではなく、ロールを介して権限を獲得します。この「間接化」が RBAC の本質です。 なぜ RBAC が必要なのか 従来の ACL ベースの管理（ユーザーごとにリソースの権限を個別に設定する方式）では、組織が大きくなるにつれて管理が破綻します。RBAC を導入することで、以下のメリットが得られます。 1. 管理の効率化 異動や入社があった際、個別に何十もの設定を変更する必要がなく、適切な「ロール」を割り当てるだけで済みます。退職時もロールを外せば一括で権限が剥奪されます。 2. セキュリティの向上（最小権限の原則） 業務に必要な権限だけをセットにしたロールを作成することで、過剰な権限付与によるリスクを防げます。最小権限の原則（Principle of Least Privilege）を組織的に実現する手段として最も普及しているのが RBAC です。 3. コンプライアンスの強化 「誰がどのような権限を持っているのか」をロール単位で把握できるため、監査が容易になります。SOC 2、ISO 27001、PCI DSS などのコンプライアンス監査では、アクセス権限のレビューが必須項目になっており、RBAC ベースの設計だとレポート作成が圧倒的に楽になります。 具体例：ドキュメント管理システム ユーザー 割り当てられたロール 実行できる操作 (パーミッション) 佐藤さん 管理者 (Admin) 作成、編集、削除、ユーザー追加 鈴木さん 編集者 (Editor) 作成、編集 高橋さん 閲覧者 (Viewer) 閲覧のみ もし鈴木さんが管理者に昇進した場合、鈴木さんの設定を一つずつ変えるのではなく、付与するロールを「編集者」から「管理者」へ切り替えるだけで、すべての権限が更新されます。 ...

概要 インターネットから物理的に切り離されたコンピュータ（エアギャップ PC）は、長らく「最後の砦」とされてきた。しかしイスラエルのベングリオン大学 Cyber Security Research Center のチームは、CPU の負荷変動が生む低周波磁場を使ってデータを外部に送信する 概念実証マルウェア「ODINI」を開発し、その限界を根本から問い直した。 同チームが 2018 年に arXiv で公開し、2020 年に IEEE Transactions on Information Forensics and Security に掲載された本研究は、ファラデーケージで遮蔽された機器からさえもデータを盗み出せることを実証している。 エアギャップとは何か エアギャップ（air gap）とは、ネットワーク接続を一切持たない状態でコンピュータを運用する手法だ。核施設の制御システム、軍の機密端末、金融機関のコアシステムなどで採用される。ファラデーケージ（電磁シールドされた筐体）と組み合わせることで、電波による傍受にも対応できる「究極の隔離」とみなされてきた。 ODINI の攻撃原理 CPU 負荷 → 電力消費 → 磁場変動 ODINI が悪用するのは、CPU が集中的な演算を行うと電力消費が増加し、低周波の磁場変動 が生じるという物理現象だ。 感染済みの PC — 事前に何らかの手段（USB、サプライチェーン攻撃など）でマルウェアを仕込む CPU コアへの意図的な負荷 — マルウェアが CPU コアに高負荷演算を繰り返し課し、電力消費を人工的に変動させる 磁場へのデータエンコード — ASK（振幅偏移変調）や FSK（周波数偏移変調）を使い、盗み出したいデータをビット列として磁場のパターンに乗せる 外部からの受信 — 攻撃者側は磁気センサーをそばに持ち込み、変調された磁場を受信してデータを復元する この手法の核心は「低周波磁場」にある。高周波電磁波はファラデーケージで容易に遮断できるが、低周波磁場はインピーダンスが非常に低く、金属筐体を含む物理的シールドを貫通してしまう。 主要スペック 項目 値 データレート（最大） 40 bps 受信可能距離 約 100〜150 cm 必要な権限 不要（一般ユーザー権限で動作） ファラデーケージの遮蔽効果 無効（低周波磁場は通過） 管理者権限が不要という点が特に厄介だ。攻撃コードは通常の演算処理を模倣するため、プロセス監視だけでは検知が難しい。 ...

個人開発アプリの認証は「絶対に」WorkOS を使え — MCP 化で知った最強の選択肢 では、WorkOS AuthKit の Dynamic Client Registration（DCR）対応が MCP 認証の決め手になる、という話を書いた。 MCP × OAuth 2.1 の全体像は MCP のセキュリティが OAuth 2.1 で大幅進化 で扱った。本記事はその中で SHOULD/MAY 扱いされている DCR を仕様レベルで深掘りする補足記事だ。 具体的には、DCR を定義する RFC 7591 そのものの仕様と、MCP 認証で必ず連動する周辺 RFC 群（9728 / 8414 / 9068 / 8707 / 7636）の関係 を、Claude Code の自動ログインフローを追いながら整理する。 この記事でわかること: なぜ事前登録なしにクライアントが認可サーバーに繋がってくるのか（RFC 7591 / 9728 / 8414 の連動） Claude Code の自動ログインフローを HTTP リクエスト単位で何が起きているか なぜ JWT の audience 検証で詰まるのか（RFC 9068 / 8707 と DCR の構造的な相性問題） なぜ MCP では Dynamic Client Registration（DCR）が必要なのか 従来の OAuth 2.0（RFC 6749）は、クライアント（アプリ）を事前に手動登録する 前提だった。Google や GitHub の OAuth を使うときに、開発者が「アプリを登録 → client_id と client_secret を発行 → コードに埋め込み」という流れだ。 ...

本記事では、Python の AST を活用して AI による脆弱性検出を効率化する手法を紹介します。Qiita の @PythonHaru 氏が公開した記事「コードを1行も読ませずに、AIに脆弱性を100%特定させる方法（理論編）」は 530 いいね・471 ブックマークを獲得し、X（旧 Twitter）でも急速に拡散しました。 この記事のポイント AI（LLM）に生のソースコードを読ませるのは、効率の悪い「情報の暴力」（情報量が多すぎて AI が処理しきれない状態） Python の ast モジュールで生成した Deep Structure Map（コードの骨格図）こそ、AI の推論能力を最大化する データの流入から危険地帯への到達をグラフ理論で定義すれば、理論上 脆弱性は100%特定可能 AIコードレビューの限界 GitHub Copilot や ChatGPT にコードをそのまま貼り付けて「脆弱性ある？」と質問する手法は今や一般的ですが、大規模プロジェクトでは2つの致命的な欠陥が生じます。 コンテキストの霧（AI が変数の出自を追跡できなくなる状態）— 数千行のコードを前にした AI は「どの変数がどこから来たか」を見失い、ハルシネーションを起こしやすくなる トークンの浪費 — コードの「書き方」というノイズに注目してしまい、肝心の「ロジックの破綻」に辿り着く前にリソースを使い果たす そこで著者は、AI にコードを1行も読ませるのをやめました。代わりに渡したのが、自作の解析コードが抽出した「コードの設計図（Deep Structure Map）」です。 Deep Structure Map：AI に「骨格」だけを渡す ソースコードは人間が読むための「肉体」ですが、AI が論理推論に必要なのは純粋な「神経系（ロジック）」です。Python の ast モジュールを使い、コードを以下の構造データへ変換します。 DeepAnalyzer クラス（ast.NodeVisitor を継承） 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 import ast class DeepAnalyzer(ast.NodeVisitor): def __init__(self): self.classes = [] self.functions = [] self.variables = [] self.scope_stack = [] self.call_graph = {} def visit_ClassDef(self, node): self.classes.append(node.name) self.generic_visit(node) def visit_Call(self, node): # 関数呼び出しをコールグラフとして記録 self.generic_visit(node) ast.NodeVisitor を継承した DeepAnalyzer がコード全体を走査し、クラス・関数・変数のスコープ情報とコールグラフを収集します。AI にはこの「関係性の結晶」だけをインプットします。 ...

クラウドファンディングプラットフォーム CAMPFIRE が、GitHub アカウントへの不正アクセスを起点に最大 22 万 5,846 件の個人情報が漏洩した可能性があると発表しました（2026 年 4 月 24 日）。単なる「パスワード流出」ではなく、CD パイプラインを悪用してインフラを乗っ取るという、現代の DevOps が抱えるリスクを象徴するインシデントです。本記事ではエンジニア視点で攻撃経路を分析し、再発防止策を考えます。 インシデントの経緯 日時 出来事 2026-04-02 22:50 GitHub アカウントへの不正アクセスを検知。一部ソースコードが閲覧された可能性（初報） 2026-04-14 第二報：社員・取引先情報の閲覧可能状態を確認 2026-04-22 第三報：顧客情報管理システムへの不正アクセス痕跡を確認 2026-04-24 個人情報漏洩の可能性を正式発表（最大 22 万 5,846 件） 漏洩した可能性がある情報は以下のとおりです: プロジェクト実行者 12 万 929 件：氏名・住所・電話番号・口座情報など（2021 年 2 月以降） 支援者 13 万 155 件：氏名・住所・口座情報など（PayPal 決済、後払い、口座送金返金ユーザー） うち 8 万 2,465 件が口座情報を含む クレジットカード情報は対象外（CAMPFIRE 公式発表） 推定される攻撃経路 エンジニア向け技術解説として、@poly_soft（勝又健太）氏が X（旧 Twitter）で以下の攻撃チェーンを推察しています。この分析は公式発表を補完する形で、攻撃者が具体的にどう動いたかを示しています（以下はあくまで推定です）。 Step 1: CD 権限を持つ GitHub アカウントの侵害（推定） 攻撃者が最初に侵害したのは、単独で CD（継続的デプロイ）をトリガーできる権限を持つ GitHub アカウントであったと推定されます。 問題の設定として考えられるのは: ...

.env よ、安らかに眠れ——。 AI 時代の開発現場では、シークレット（API キー・データベースパスワード・証明書など）の扱い方が大きな課題になっています。従来は .env ファイルに書いておけばなんとかなっていました。しかしチーム規模が拡大したり、AI エージェントが複数のサービスを横断して動くようになると、.env ベースの管理はほころびを見せてきます。 Infisical は、そんな .env の時代を終わらせるべく登場したオープンソースのシークレット管理プラットフォームです。 .env の何が問題なのか .env ファイルによるシークレット管理には以下のような問題があります。 ディスクに残る: 誤って git add .env してしまうリスクが常に存在する 同期が難しい: 複数人・複数環境での値の一元管理が困難 ローテーションが手動: シークレットを更新するたびに全メンバーへの周知が必要 監査ログがない: いつ誰がどの値を変更したか追跡できない AI エージェントとの相性が悪い: エージェントが環境変数ファイルを読み書きすると漏洩リスクが増大する Infisical とは Infisical は、シークレット・証明書・特権アクセスを一元管理するオープンソースプラットフォームです。2026年4月時点で GitHub 26,000 スター超を獲得しており、Vault の OSS 代替として注目されています。 最大の特徴は、シークレットをランタイム時に取得する設計にあります。.env ファイルのようにディスクに値を保存しないため、ファイルベースの漏洩リスクを根本から排除します。 主な機能 シークレット管理 プロジェクト・環境（dev / staging / prod）ごとのシークレット管理 シークレットのバージョン履歴と自動ローテーション 変更の監査ログ シークレット参照（他のシークレットの値を参照する変数展開） 証明書管理（PKI） プライベート CA の構築と証明書の発行 ACME プロトコル対応で Let’s Encrypt 互換のワークフロー 証明書の有効期限監視と自動更新 統合機能 CLI: あらゆる言語・フレームワークのコマンドをシークレット付きで実行 SDK: Node.js、Python、Go、Java など主要言語のネイティブ SDK インフラ統合: Kubernetes、GitHub Actions、AWS、GCP、Azure など 基本的な使い方 インストール 1 2 3 4 5 # macOS (Homebrew) brew install infisical/get-cli/infisical # npm npm install -g @infisical/cli ログインとプロジェクト初期化 1 2 3 4 5 # Infisical にログイン infisical login # プロジェクトに紐付け infisical init シークレットを注入してコマンドを実行 1 2 3 4 5 # .env の代わりに Infisical からシークレットを取得してアプリを起動 infisical run -- node app.js # 環境を指定 infisical run --env=staging -- python manage.py runserver SDK から直接取得（Node.js の例） 1 2 3 4 5 6 7 8 9 10 11 12 13 14 import { InfisicalSDK } from "@infisical/sdk"; const client = new InfisicalSDK(); await client.auth().universalAuth.login({ clientId: process.env.INFISICAL_CLIENT_ID, clientSecret: process.env.INFISICAL_CLIENT_SECRET, }); const secret = await client.secrets().getSecret({ secretName: "DATABASE_URL", projectId: "my-project-id", environment: "production", }); AI 時代のシークレット管理 AI エージェントや MCP サーバーが普及した今、シークレット管理の重要性はさらに高まっています。 ...

生成 AI ツールの急速な普及により、IT 部門の承認を経ずに従業員が独自に AI を活用する「シャドー AI」が企業セキュリティの新たな盲点として注目されている。本記事では、シャドー AI が引き起こすリスクと、その対策について整理する。 シャドー AI とは 「シャドー IT」は以前からある概念だが、生成 AI の登場でその問題は一段と深刻になった。**シャドー AI（Shadow AI）**とは、IT 部門や情報セキュリティ部門の審査・承認を受けずに、従業員が業務で使用する AI ツールやサービスのことを指す。 ChatGPT・Gemini・Claude・Copilot などの生成 AI サービスは、個人アカウントで無料または低コストで利用できる。利便性が高いため、IT 部門の手続きを待たずに「とりあえず使ってみる」ケースが後を絶たない。 調査によれば、従業員の約 40% が業務で非承認の生成 AI ツールを使用しているとされており、多くの企業でシャドー AI が組織的な管理の外に広がっている。 シャドー AI が生む具体的なリスク 1. 機密情報・個人情報の漏洩 最も深刻なリスクは、社内の機密情報が AI サービス側に送信されることによるデータ漏洩だ。 実例: Samsung の機密漏洩事件（2023年） Samsung の半導体部門の社員が、ChatGPT に機密のソースコードを貼り付けてデバッグを依頼したり、社内会議の音声を要約させたりした結果、社内機密が外部サーバーに送信されたインシデントが発生した。この件が発覚した後、Samsung は社内での ChatGPT 利用を一時禁止している。 社員が AI に入力する情報として問題になりやすいのは: ソースコード・設計仕様書 顧客情報・個人情報（氏名、メールアドレス、契約情報など） 財務データ・未公開の経営情報 社内メール・会議議事録 多くの商用 AI サービスは、無料プランやデフォルト設定では入力データをモデルの学習・改善に利用する場合がある。エンタープライズ契約や特定のオプト設定が必要だが、シャドー利用ではそのような設定は行われていない。 2. コンプライアンス・規制違反 個人情報保護法（GDPR、日本の個人情報保護法）や業界固有の規制（医療分野の HIPAA、金融分野の各種規制）では、個人情報の取り扱いに厳しい要件がある。IT 部門の審査を通じて利用規約・データ処理契約を確認せずに AI ツールを使用すると、意図せず法令違反を犯す可能性がある。 3. AI の出力に対する品質・責任管理の欠如 生成 AI はハルシネーション（事実と異なる情報の生成）を起こす。IT 部門・品質管理部門が把握していないツールを使って作成された成果物がそのままリリースや提案書に使われると、品質問題に発展しうる。 ...