Cache-moi si tu peux : patterns et pièges du cache en production - Devoxx France 2026 - Conférence
Cache-moi si tu peux : patterns et pièges du cache en production - Devoxx France 2026 - Conférence
LayerX QAエンジニアの小山です。 昨今、AIコーディングアシスタント(特にClaude Code等)の進化により、コードの実装やテスト追加のスピードが飛躍的に向上しています。しかし、AIにコードを書かせる際に「どこまで厳密なエラーハンドリングが必要か」「テストはどの程度書くべきか」といったことに迷われた経験はないでしょうか? 今回は、バクラク事業部の品質の定義やテスト戦略などを言語化し、Claude Codeが動く際にリスクの高い箇所を守るように動いてもらい、テストも同時に生成してもらう、早期テストで時間とコストを節約する試みについてご紹介します。 ソフトウェアテストの原則「早期テストで時間とコストを節約する」 筆者はJSTQB FLの公認コースのトレーナーを15年ほどしているのですが、JSTQB FLシラバスの中に「テストの原則」として7つの原則があります。その中の1つとして「早
こんにちは、エーピーコミュニケーションズ ACS事業部の福井です。 最近、AI系のセキュリティ標準である OWASP AISVS(Artificial Intelligence Security Verification Standard)を勉強しながら、GitHub Advanced Security(GHAS)との組み合わせを検証していました。 「GHASって有料じゃないの?」と思われるかもしれませんが、実はパブリックリポジトリなら全機能が無料で使えます。 せっかくなので、意図的に脆弱性を仕込んだ AI アプリのデモプロジェクトを作って、GHAS に読ませてみました。 その結果が、予想以上に面白かったんです。 GHAS とは何か、そしてなぜ試したか デモプロジェクトAI 搭載の便利ツールを作ってみる。 Secret Scanning:「万能ではない」を体で学んだ ダミーキーを使ったら、
CI/CDシリーズ: 1本目: Next.js + NestJSのモノレポでGitHub Actionsのデプロイパイプラインを構築した 2本目: Pull Requestごとにバックエンドも含めたプレビュー環境を自動構築する仕組みを作った 3本目: GitHub ActionsとECS Run TaskでDB操作を自動化する(この記事) CI/CDシリーズの3本目。今回はデプロイ以外の運用自動化、具体的にはDB操作のワークフロー化の話。 背景: なぜ運用タスクをワークフロー化するのか デプロイ以外にも繰り返し発生する運用タスクがある。マイグレーションの適用、マスタデータの投入、テストデータの投入、データパッチの適用など。 これらを手動でSSHやローカルからDB接続して作業する運用はセキュリティ的にちょっと厳しいところ。それにVPC内のリソースへのアクセスにも制約がある。今回はAurora
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? このたび、マイナビ出版から 「開発効率をアップする! Claude Code 実用入門」 という書籍を出します。 [Amazonはこちら]https://www.amazon.co.jp/o/ASIN/4839990204/mynavibooks-22/ なんでこの本を書いたかというと、より多くの人に、Claude Codeを使ってほしいから。これに尽きます。 Twitter(X)などのSNSを眺めていると、毎日のように新しい使い方が紹介されているのですが、「MCPを入れろ」「Skillを書け」「サブエージェントを並べろ」とか、みんな言
背景: 何が起きているか 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が直接侵害された。攻撃者はメンテ
「監視ツールは入れています。アラートも設定しています。でも障害は、ユーザーから教えてもらっています」 これを、複数の組織で聞いた。そのたびに少し複雑な気持ちになる。問題はツールではないからだ。 「入れているのに気づかない」の原因は、たいてい同じ3つの場所にある。複数の組織で同じパターンを見ていると、それが確信に変わった。設定の問題というより問いの立て方の問題だ。 「監視できている」の定義が、ずれていた 監視の目的を「インフラが正常かどうか確認すること」だと定義すると、多くの組織では「監視できている」になる。CPUは正常、メモリは正常、エラーレートも閾値内。それを見て「問題ない」と判断する。 ところがその間に、ユーザーは「画面が真っ白」「ボタンが押せない」という体験をしている。 あるチームの支援に入ったとき、まさにその状況だった。監視ダッシュボードはすべてグリーンだ。それでも「ユーザーから使
Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://raw.githubusercontent.com/microsoft/ghqr/main/scripts/install.ps1')) $ ghqr -v ghqr version v.0.2.1 $ ghqr list-recommendations ID SCOPE CATEGORY SEVERITY TITLE ───────────
注釈:追記すべき情報がある場合には、その都度このページを更新する予定です。 概要 Linuxは、オープンソースの基本ソフトウェア(OS)です。 このLinuxのカーネルにおいて、権限昇格の脆弱性(CVE-2026-31431、Copy Fail)が確認されています。 本脆弱性を悪用された場合、当該製品上で、ローカルでログイン可能なユーザにより、管理者権限を取得される可能性があります。 この脆弱性は、ネットワーク越しに攻撃できるものではなく、一般ユーザーの権限を前提とするものであると評価されています(CVSS v3.1 において、AV:L、PR:L と評価)。 CVE Record: CVE-2026-31431 ただし、脆弱性に関する検証コードが既に公開されています。 また、他の脆弱性と組み合わせることによる悪用や、複数名でカーネル環境を共有する運用形態(コンテナ等)の場合における影響が懸
はじめに 2026 年 5 月 1 日、マネーフォワードが「GitHub への不正アクセス発生に関するお知らせとお詫び(第一報)」を公表しました。GitHub の認証情報が漏えいし、第三者によりリポジトリがコピーされ、ソースコードと一部の個人情報が流出した可能性があるという内容です。同時に、銀行口座連携機能を一時停止する措置もとられました。 この事案は、エンジニア視点で見ると「仕方ない部分」と「明らかにアウトな部分」がはっきり分かれる、教科書のような事例になっています。GitHub 認証情報の漏えい自体は、正直に言ってどの会社でも起こり得ます。一方で、流出したとされる中身に 本番カード保持者の氏名と下 4 桁が 370 件、そして ソースコード内に各種認証キー・パスワード が含まれていたという点は、設計と運用の問題として議論せざるを得ません。 この記事ではセキュリティエンジニアの立場から、
『ハビットトラッカー』でなりたい⾃分になる!習慣を定着させるコツ毎日見ることの多い手帳には、自分の目標などを書き込んでいる人も多いのではないでしょうか。そんな前向きな気持ちを抱く人におすすめしたいのが、「ハビットトラッカー」。習慣化したい行動が実行できたかを記録するリストです。新たに迎える節目はもちろん、何でもない日からスタートしてももちろんOK。手帳の片隅に…あなたなりの「トラッカー」をプラスするだけで、なりたい自分に近づけますよ。今回は「ハビットトラッカー」の方法と「ハビットトラッカー」におすすめのアイテムを紹介します。2022年08月15日更新
2026年4月末、Linuxカーネルに極めて深刻な脆弱性が報告されました。通称「Copy Fail」と呼ばれるこの脆弱性(CVE-2026-31431)は、ローカルの一般ユーザーが数秒でroot権限を奪取できるというものです。 今回の記事では、情報システム部のセキュリティ担当として、この脆弱性のメカニズムと、組織が直ちに講じるべき対策について論理的に解説します。 この脆弱性に関する客観的な事実は以下の通りです。 専門家として分析すべきは、この脆弱性が「ディスク上のファイルを書き換えない」という点です。 1. ページキャッシュ汚染のステルス性 2. コンテナ環境における「境界」の無効化 3. 特権奪取のロジック 現時点での状況証拠から、今後の展開を次のように推測します。 情シス向けチェックリスト CVE-2026-31431 (Copy Fail) 対策緊急チェックリスト 実務上の重要ポイン
小西秀和です。 私はこれまで、設計に多くの時間をかけて熟考し、コードの品質にこだわり、それらを支える技術的な知識を深く積み上げることに情熱を燃やしてきました。そして、AWSの全認定資格を取得し、Japan AWS Top Engineerにも選出していただきました。知識と技術の蓄積こそが自分の価値だと信じていました。しかし、つい最近、その価値観を自己否定することにしました。 この記事では、AI時代にエンジニアが何に価値を置くべきか、何を手放し何を磨くべきかについて、私自身の経験と考察をまとめています。これは特定の誰かに向けた教訓めいた話ではなく、私自身が直面したパラダイムシフトの記録です。同じような葛藤を抱えているエンジニアの方にとって、何かしらの参考になれば幸いです。 1. 価値を失いつつあるもの - 「知っている」ことの意味が変わる 「知っている」こと自体の価値が、急速に薄れてきている
インフラ・CI/CDの変遷 ZEN Studyが10周年を迎えるにあたり、インフラやCI/CDの仕組みがどう変わってきたかを振り返ります。 インフラ・CI/CDの変遷 2016年〜: 立ち上げ期 2017年頃〜: Kubernetes導入期 2021年頃〜: IaC整備・CI刷新期 2023年11月頃〜: Amazon EKS移行期 2024年6月〜: サイバー攻撃後の再構築 これから取り組んでいきたいこと 2016年〜: 立ち上げ期 2016年のサービス開始時のZEN Studyは、EC2上にマイクロサービス群を直接デプロイする構成でした。本番環境にコンテナ系の技術は導入されておらず、アプリケーションのデプロイはCapistranoで行っていました。EC2インスタンス上のミドルウェアはitamaeで構成管理をしており、Rubyのバージョンアップ作業では各サービスの本番インスタンスに1台ず
Decision Quality (DQ) は SDG が体系化した意思決定の質の枠組みで、良い意思決定の条件を6つに分解する。 Frame(解くべき問題の枠組み) Alternatives(選択肢) Information(情報) Values(評価基準) Sound Reasoning(論理的推論) Commitment to Action(実行へのコミット) 全体の質は一番弱い要素で決まる、というのがDQの中心的な主張である。意思決定そのものと、その結果は区別する。良い意思決定でも結果が悪いことはあるし、その逆もある。 設計判断の現場で繰り返し観測される失敗の多くは、6要素のうち Frame と Values の2つの取り違えで説明できる。Valuesを 評価軸 として8つに整理し、Frame の取り違えは 支配軸の取り違え として捉える。残りの4要素も副次的に絡む。早合点 は In
JTC勤務だけど、入社してめちゃくちゃ幹事対応任されるので調整さん使ってたら、社員が幹部社員とセキュリティ担当者にこれは外部ツールだし問題なのではないかと連絡があったらしく禁止になりました 業務では使ってなかったんですけどアウトらしいです… https://t.co/o4Z5lSATb8 — つちー (@tsichi_) April 23, 2026 飲み会の日程調整に「調整さん」を使ってる人は多いと思います。登録不要で出欠確認をできる便利ツールの定番です。リンクのポストでも幹事が使ってたとあります。SaaSといえばSaaSなので、会社が許可してなければ禁止するというのは妥当な気もします。その一方で、ここに機密情報なんて書かれることがあり得ないので受け入れがたいと思う人も当然いるでしょう。 今回はこれをいちセキュリティ専門家として解説していきます。 どこにでもある典型的なシャドウITの問題
G-gen の杉村です。Google が提供する Google AI Studio で発行した API キーが何らかの方法で他人に知られたことにより、悪意ある主体によって大量に Gemini モデルへのリクエストが発行され、利用料が過剰に発生する事象が観測されています。当記事ではこの事象の説明と、対処法について解説します。 事象と背景 事象の原因 キーが他人に知られた原因 不正利用の原因 対策 対策の一覧 対象者 予算アラートと異常検知の設定 予算アラート 請求先アカウントの異常検知 迷惑メールに分類されない設定 Spend Caps の使用(Private Preview) 使用状況の把握 把握方法 課金レポートの確認 Cloud Asset Inventory の確認 API キーの制限の徹底 概要 API キーの所在の把握 API キーの制限 ベストプラクティスへの準拠 Google
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く