Security-JAWS【第41回】〜Day1〜でAWS WAFの運用について発表しました！
こんにちは！ アンドパッド セキュリティグループの 宜野座(ぎのざ)です。 2026/05/16(土)に開催された Security-JAWS【第41回】〜Day1〜 にて登壇の機会をいただき、私のセッションでは「AWS WAFの運用を地道に改善し、自社で運用可能にするプラクティス」というタイトルで発表をしました。 今回はCfPを出した背景やセッションでお話しした内容の補足、興味深かったセッションの内容をご紹介します。 Security-JAWS にこれから現地参加したい、CfPを出してみたいと考えている方にも参考になると何よりです。 Security-JAWS について なぜCfPを出したのか CfP採択後の準備 セッションの内容について セッションでは話せなかったこと AWS WAFの新規作成 AWS WAF ルールのPriorityの順番 AWS WAFの更新作業が属人化してしまう 興味深かったセッション Session4: 10サービス以上のメール到達率改善を地道に継続的に進めている話 Session8: Claude Code / Codex / Kiro に AWS 権限を渡すとき、何を設計すべきか Security-JAWS 全体を通しての感想 We are actively hiring! Security-JAWS について AWS を利用している人なら知っている有名なイベントですが、念のため紹介すると、AWSを利用する上で非常に重要な要素であるセキュリティの活用を共有して、より安全にAWSを利用することを目的として、立ち上がったイベントです。 詳しくは connpassページをご参照ください。 s-jaws.connpass.com そして今回は10周年イベントということで、改めて10周年おめでとうございます 🎉🎉 登壇者の記念Tシャツもいただきましたので、大切にします！ なぜCfPを出したのか AWSに関わる大きなイベントでもいつか発表してみたいとは思っていたのですが、なかなか挑戦できずにいました。 そんな中 3月に Security.any というイベントでも登壇の機会をいただき、せっかくの機会なので他のイベントにもチャレンジしてみようと思ったのが最初のきっかけでした。 そして以前から AWS x Security といえば Security-JAWS というくらい 多くの方が参加するイベントだと知っており、10周年のイベントには元々参加しようと思っていたのですが、もしかすると1年くらいかけて取り組んでいたAWS WAFの取り組みが発表できるのではないかと考え、CfPの提出に挑戦してみました。 CfP採択後の準備 4月にCfPの採択のご連絡をいただいて本格的に準備を開始し、CfPに提出していた登壇概要の情報からどのような内容を伝えられると参考になるだろうと1年余りの取り組みを改めて振り返りながらスライド作りに取り組みました。 スライドのデザイン統一・全体構成についての意見・分量が適切かというところではAIにも意見を貰いながら、4日前から時間を測った練習を何度か実施し、時間を大幅にオーバーしていたのでスライドを削ったり全体の時間の調整を行なうという流れで準備を進めていました。 ここまでの個人的な準備に加えて、社内でもチームの方を中心にたくさんレビューいただいて、無事発表に間に合わせることができました。 セッションの内容について 今回は1番最初のセッションの枠をいただきまして、「AWS WAFの運用を地道に改善し、自社で運用可能にするプラクティス」というタイトルで発表しました。 speakerdeck.com 準備に少し手間取ってしまい皆さまに申し訳なかったですが、会場が温かい雰囲気だったため、そこまで緊張せずに話せてよかったです。 またいくつか参考になったというコメントをXでもいただき、非常に嬉しかったです。 セッションでは話せなかったこと セッションの時間は非常に限られていたので、課題を4つに絞っていました。 そのため細かな課題はスキップしていたので、ここで一部共有したいと思います！ AWS WAFの新規作成 AWS WAFの新規作成を簡単に行えないというところも課題としてありました。 主に以下が課題の要因だったと考えています。 AWS WAFに設定するべき、マネージドルールがわからない 新規作成の時に必要な手順がわからない まずは1つ目の課題を解消するために、設定を必須とするマネージドルールのポリシーを定めていきました。 現在AWSが提供している全てのマネージドルールを確認し、未導入のものは有効性を検証の上追加したり、すでに導入されているものでも必須ではないものを除外したりという選定を行いました。 続いて2つ目の課題を解消するために、1つ目の課題解消で決めたポリシーを元にGitHubにてTemplateディレクトリを作成しました。 そしてREADMEに新規作成の手順を追加し、現在はWAFの作成依頼に対して数時間程度で対応可能となりました。(元々既存ルールの調査やコードの修正、申請などで数日かかっていました。) AWS WAF ルールのPriorityの順番 ルールはPriorityの値が小さい順に評価されますが、整理を始める前は独自 allowルール、独自 blockルール、AWSマネージドルールが様々なPriorityで設定されているという課題がありました。 そのためどのようにリクエストが評価されるかの確認がしにくかったり、追加箇所で悩むことがありました。 こちらの課題を解決するために、以下のようなルールを設けることにしました。 allowルール: Priority 0 - 49 block ルール: Priority 50 - 99 AWSマネージドルール: Priority 100 以降で設定 AWS WAFの更新作業が属人化してしまう コード化を終えたタイミングでAWS WAFマネージドルールのバージョン最新化に取り組んでいましたが、最初のうちは個人でアップグレードの対応が行われており、属人化が課題となっていました。 しかし、その後更新手順を整備したタイミング(登壇でお話しした内容)で、チームで担当者をアサインする体制に移行したことで現在はチームで分担しながら実施する運用とすることが出来ました。 コード化をしていたことで非常にスムーズにチームでの運用へ移管することができたと思います。 興味深かったセッション 今回のセッションは全部で11セッションありました。 その中からこのテックブログでは、特に私が興味深かったセッションを2つ紹介します。 他のセッションの資料も以下にアップされていますので、ぜひご参照ください。 Security-JAWS【第41回】~Day1~ 2026年05月16日(土) - 資料一覧 - connpass Session4: 10サービス以上のメール到達率改善を地道に継続的に進めている話 1つ目は、株式会社エス・エム・エス SRE 山口 隆史さんの発表になります。 2024年2月のGoogleガイドラインによって、SPF/DKIM/DMARCが必須の対応となり地道に改善を進めているというお話しでした。 SPF/DKIM/DMARCのわかりやすい説明に加えて、問題となったケースについての紹介もあり、非常に有益な内容でした。 そして改めてセキュリティの取り組みは銀の弾丸はなく、地道な運用が必要なんだと感じました。 speakerdeck.com Session8: Claude Code / Codex / Kiro に AWS 権限を渡すとき、何を設計すべきか 2つ目は、アジアクエスト株式会社 足立 和生さんのセッションになります。 様々なAIツールの企業導入が進んでいますが、AWSなど他のパブリッククラウドの権限をどの範囲で許可するかは非常に悩ましい問題だと思います。 その中で、人間用のIAMロールとAI用のIAMロールを分けた方が良いよという話であったり、Claude Code / Codex / Kiro と統制観点で比較したりと興味深いお話しでした。 こちらのセッションを聴いて、改めてAIに渡している権限は今のままで大丈夫だろうか。と考えるきっかけになりました。 speakerdeck.com Security-JAWS 全体を通しての感想 イベント全体を通して、みなさんが楽しく過ごされているのが印象的でした。 そしてAWSを利用する上で学びとなる内容もたくさんあり、イベント会場も素敵でリラックスしてイベントに参加することができました。 運営のみなさま、素晴らしいイベント運営ありがとうございました！ これからもまた参加したいと思います 🙌 We are actively hiring! アンドパッドのセキュリティグループではチーム力を更に向上させて、一筋縄ではいかないセキュリティ課題への挑戦を続けていきます。 そのためにも「セキュリティ施策をどんどんリードしていきたい！」「これまでの開発経験をセキュリティ分野で活かしてしてみたい！」など、多様なバックグラウンドをお持ちの方と一緒に働きたいと考えています。 カジュアル面談もいつでも大歓迎ですので、ご興味がある方はぜひ以下より申し込みお待ちしております。 hrmos.co またその他にも、さまざまなポジションを募集していますのでご興味がある方はぜひご参照ください。 hrmos.co
- AWS
- セキュリティ
- IaC
ソフトウェアサプライチェーン攻撃対策実践レポート 2026春
こんにちは、アンドパッドセキュリティチームの小野寺です。 近年、ソフトウェア開発のエコシステムを狙ったソフトウェアサプライチェーン攻撃が大きな脅威となっており、開発環境や CI/CD パイプラインにおけるセキュリティの強化が急務となっています。 アンドパッドでは、以前のブログでご紹介した EDR によるサプライチェーン攻撃対策とあわせて、より多層的な防御策の導入を進めています。 本記事では、弊社が直近で取り組んだソフトウェアサプライチェーン攻撃に対する具体的な対策について、実践的なアプローチと実運用にのせる上での工夫や課題を交えてご紹介します。 Takumi Guard の導入 GitHub Copilot Coding Agent の Firewall に Custom allow list が必要となる場合がある 他のジョブによって .npmrc がコミットされてしまう 利用方法に応じたレートリミット 外部 Action の SHA 固定による不変性の担保 GitHub Actions の permissions 最小化 AIエージェントを活用した対応 まとめ We are hiring! Takumi Guard の導入 Takumi Guard は GMO Flatt Security 社が提供する、悪意のあるパッケージをブロックするレジストリプロキシです。 flatt.tech アンドパッドでは Takumi Guard を以下の方法で利用しています。 開発者端末全台に Takumi Guard のプロキシを設定 Node.js のパッケージもしくは Python ライブラリをインストールする GitHub Actions で、Takumi Guard をレジストリプロキシに設定 2026年4月22日に RubyGems にも対応されたため、追加で対応を検討しています！ EDR によるサプライチェーン攻撃対策とあわせて、ソフトウェアサプライチェーン攻撃の入り口となりやすい開発者端末への悪意あるパッケージの混入を防いでいます。 加えて、攻撃対象となりやすい CI/CD パイプラインへ Takumi Guard を導入し、サプライチェーン全体のセキュリティ強化を図っています。 既に多くの開発者の方がブログで触れられているため、機能や導入手順の詳細なご紹介は割愛しますが、導入の容易さが考慮された設計となっていることもあり、アンドパッドでも大きな問題が発生することなく、スムーズに開発サイクルへ組み込むことができました。 その中でも、実運用にのせる上でいくつか注意が必要な事項がありましたので、この場でご紹介します。 GitHub Copilot Coding Agent の Firewall に Custom allow list が必要となる場合がある GitHub Copilot Coding Agent を利用している開発組織も多いと思いますが、その場合には注意が必要です。GitHub Copilot Coding Agent は既定で Firewall が構成されており、有効になっている許可リスト以外への通信はブロックされます。 そのため、以下の条件に合致する場合には、GitHub Copilot Coding Agent から *.flatt.tech レジストリへの通信が弾かれてしまいます。 リポジトリの .npmrc に *.flatt.tech レジストリが追加されている GitHub Copilot Coding Agent がパッケージのインストールを伴う作業を実施する 上記のようなケースでは、個別に GitHub Copilot Coding Agent の Custom allow list に *.flatt.tech を追加する必要があります。 導入時点では、この Custom allow list はリポジトリ単位で個別に設定をする必要がありました。 しかし、2026年4月のアップデートにより Organization レベルで設定ができるようになり、リポジトリごとの設定の手間は不要になっています。 github.blog 他のジョブによって .npmrc がコミットされてしまう GitHub Actions で Takumi Guard をレジストリプロキシに設定するステップを追加した場合、同一ワークフローの後続ステップによって .npmrc の変更が自動コミットされてしまうケースがありました。 弊社では GitHub にコードを push すると、自動でコード整形（フォーマット）およびコミットを行う CI を利用しています。このステップの前に Takumi Guard を設定する処理を追加したところ、書き換えられた .npmrc まで一緒に自動コミットされてしまう事象が発生しました。 これを避けるために、npm install 実行後に明示的に git checkout -- .npmrc のステップを追加し、.npmrc の変更を元に戻すことで自動コミットを回避可能です。 利用方法に応じたレートリミット Takumi Guard は、利用方法（匿名利用や認証利用など）によって複数のレートリミットが設定されています。それぞれの値については以下をご参照ください。 shisho.dev 弊社では直近のサプライチェーン攻撃への対策として、決定から開発者端末への導入までを短期間で実施したため、一部の環境・ユーザーにおいてレートリミットに達してしまうケースが発生しました。 特に「匿名利用」の場合、制限単位が IP アドレス単位となります。そのため、オフィス出社時など複数人が同一のグローバル IP を利用する環境下では、匿名利用モードではなく、メール認証を行うなどレートリミットを意識した導入方法の検討が必要になると考えます。 現在は、よりレートリミットの閾値が高い組織ユーザートークンや Bot トークンでの導入も可能になっているため、そちらの利用を検討いただくのがおすすめです。 以上、組織や開発環境単位で大規模に導入するにあたって、気を付けていただくと良い点を紹介しました。 現在は、組織単位での感染可能性の通知など、集中管理を意識した様々な機能のリリースが発表されています。今後もセキュアな開発環境の構築に向けて、継続的に改善していきます。 外部 Action の SHA 固定による不変性の担保 GitHub Actions で外部 Action を利用する際、タグ指定ではなく SHA で固定することが公式ドキュメントで推奨されています。 SHA 固定が推奨される理由は以下の通りです。 参照している外部 Action が侵害された場合、タグはそのままで悪意のあるコードに差し替えられるリスクがある Git のタグは後から別のコミットに付け替え可能 Immutable-releases を利用したタグは除く SHA は不変（変更不可能）なため特定コミットを確実に参照し、意図しないコードの混入を防ぐことが可能 社内のワークフローの SHA 固定状況にバラツキがあったため、全てのワークフローで SHA 固定する対応を実施しました。 SHA 固定への書き換えはルールが明確なため自動化と相性が良く、pinact 等のツールを使うことで大きな問題なく対応が可能でした。 github.com 併せて今後のワークフロー追加・変更に対応するため、Enforce SHA Pinningの利用を検討しました。Enforce SHA Pinning は Organization、リポジトリレベルで SHA 固定を強制できる機能です。 この機能は自分たちのワークフローだけでなく、使用している外部 Action で呼び出されている Action も含め、依存先を再帰的にチェックします。そのため、コントロール外のところでエラーが発生する可能性があり、今回の短期対策では使用を見送りました。 外部 Action で SHA 固定されていない箇所があると、そこから侵害の影響を受ける可能性があるため、外部 Action を精査して Enforce SHA Pinning を有効化したいと考えています。 GitHub Actions の permissions 最小化 GitHub Actions では permissions を明示的に指定することで、GITHUB_TOKEN に付与される権限を最小に絞ることが可能です。 公式ドキュメントでも最小限の権限を付与することが推奨されています。権限の最小化によりサプライチェーン攻撃を防ぐことはできませんが、万が一ワークフローが侵害された場合に被害を最小限に抑えるためにも重要な対策となります。 2023年2月から Read repository contents permission がデフォルトになりましたが、それ以前に作成された Organization、リポジトリでは Read and write permissions がデフォルトになっています。 github.blog 弊社の Organization は上記変更以前から存在しているため Read and write permissions が設定されており、permissions が明示的に指定されていないワークフローも存在することから、全ワークフローに permissions を追加しました。 AIエージェントを活用した対応 SHA 固定の対応では pinact を使用することで自動的に修正できました。 一方、permissions の最小化では、必要な権限をワークフローの記述だけで判断できず、利用している Action のソースコードや GitHub API のドキュメントまで確認して初めて明らかになるケースも多く、同様の自動化は困難でした。自動化ツールも存在しますが、対応している Action のカバレッジに限界があります。 そこで、AIエージェントを活用した permissions 指定を併用することにしました。ワークフローファイルを読み込ませ、外部 Action のソースコードや GitHub API のドキュメントを参照しながら各ステップに必要な権限を推定させることで、人手で行う場合と比べて大幅に効率よく対応できました。また、contents: read をデフォルトとし、それ以上の権限が必要な場合のみ明示するという方針をあらかじめ与えることで、必要最小限の権限のみを付与するようにしています。 まとめ 今回は、アンドパッドでのサプライチェーン攻撃対策の取り組みについて紹介しました。 攻撃が活発に行われているエコシステムを対象に、開発チームへの負担を抑えながら実施できる優先度の高い対策から着手しました。 今回の対策はあくまで出発点であり、今後継続して侵害の予防・早期検知・迅速な対応の強化に取り組んでいく予定です。 具体的には、より広範なエコシステムへの対応、CI/CD の外部通信の制御・ログの可視化等を検討しています。 サプライチェーン攻撃は特定の組織だけの問題ではなく、ソフトウェア開発全体に関わるリスクです。本記事が、同様の課題に取り組むエンジニアの参考になれば幸いです。 We are hiring! セキュリティチームでは、ANDPADのセキュリティをより強固なものにする仲間を募集しています！少しでも興味を持った方は以下採用ページをご確認ください。 hrmos.co
- セキュリティ
- CI/CD
- GitHub Actions
Security.any#09で「建設DXを支えるANDPAD: 2025年のセキュリティの取り組みと卒業したいセキュリティ」というタイトルで発表しました！
こんにちは！ アンドパッド セキュリティグループの 宜野座(ぎのざ)です。 2026/03/19(木)に開催されたSecurity.any#09でアンドパッドは会場スポンサーとして協賛し、スポンサーLTに参加させていただきました！ 私のLTでは、「建設DXを支えるANDPAD: 2025年のセキュリティの取り組みと卒業したいセキュリティ」というタイトルで発表いたしました。 今回はスポンサーLTと興味深かったLTの内容、現地の様子をご紹介します。 Security.any にこれから参加したいと考えている方にも参考になると何よりです。 Security.anyについて Security.any#09の会場の様子 スポンサーLTについて 興味深かったLT 1. ReactのdangerouslySetInnerHTMLは“dangerously”だから危険 2. 灯台下暗し - 物理侵入の実際 3. セキュリティチャンピオンによるPSIRTがボトルネックになりやすい体制からの卒業 Security.any#09全体を通しての感想 We are actively hiring! Security.anyについて connpassページでは、以下のように紹介されています。 サイバーセキュリティについての『アウトプット』を通して人との『繋がり』や学ぶことを『楽しむ』コミュニティです！！ またイベント冒頭でも「セキュリティという幅広い話題で、みんなで笑いながら情報交換する場としたい」とのことで紹介がありました。 アンドパッドのセキュリティグループでもエンジニアリングの楽しさを追求したり、学び合うことを大切にしているので、コミュニティの思いに非常に共感しました。 Security.any#09の会場の様子 今回アンドパッドは会場を提供していたのですが、私自身もこのスペースでのイベントに参加するのは初めてで新鮮でした。 入り口には社員手塗りの大きなANDPADのロゴがあり、皆様をお出迎えします。会場を含めアンドパッドの向き合う建設業界をイメージした場所になっています。 イベントスペース入り口 登壇スペース スポンサーLTについて 今回はスポンサーLTの枠をいただきまして、「建設DXを支えるANDPAD: 2025年のセキュリティの取り組みと卒業したいセキュリティ」というタイトルでお話しをさせていただきました。 昨年取り組んでいたことから発生した卒業したいことと、卒業できたらどんなことに取り組んでいきたいかということについて紹介しています。 speakerdeck.com 外部でのイベントの登壇は初めてというのもあり、緊張もしていたのですが会場の雰囲気が温かく、あまり緊張せずに話すことができました。 登壇の様子 懇親会の際には、アンドパッドの取り組んでいる業界課題についてやセキュリティについていくつか質問を受けたり、非常に楽しく過ごせました！ 興味深かったLT 興味深いLTばかりだったのですが、その中から印象に残っているものを3つ紹介したいと思います。 1. ReactのdangerouslySetInnerHTMLは“dangerously”だから危険 1つ目は、普段からアンドパッドもお世話になっている GMO Flatt Security株式会社 の石川琉聖さんによるLTです。 現在でもGMO Flatt Security株式会社ではXSSが4番目に多く見つかり、非常に狙われる攻撃とのことで、Reactの機能を用いたXSSの対策に関する様々な事例を交えた紹介をしていました。 最後には週明け会社でやってほしいことの紹介もあり、非常に学びの多いLTでした。 ＜登壇資料＞ speakerdeck.com 2. 灯台下暗し - 物理侵入の実際 2つ目は、ぼうけんさんによる物理侵入によるセキュリティリスクに関するLTです。 物理被害の絶対数は少ないため目立たないが、実際に日本でも被害が発生しており、物理とサイバー両方のセキュリティリスク評価を国内でもっと推進していく必要があるということをお話しされていました。 また日本では物理侵入を評価するような人材も少ないという課題から専業ベンダを起業したとのことで、その行動力に驚かされました。 日本は比較的安全な国でもあるので、物理侵入が容易なオフィス・ビルもあると思いますし、改めて気をつけていくのが大切なんだと考えさせられました。 3. セキュリティチャンピオンによるPSIRTがボトルネックになりやすい体制からの卒業 サイボウズ株式会社 の yoshiking さんによるセキュリティチャンピオンの取り組みに関するLTです。 開発現場でありがちな「セキュリティはPSIRTに任せておけばよし」という状態から卒業したいということで、どのようにセキュリティチャンピオンを始めたかや具体的なアクションについても紹介がありました。 セキュリティとスピードのトレードオフについても言及があり、似たような課題をアンドパッドも抱えており印象に残りました。 今のところ、順調にセキュリティチャンピオンの取り組みも拡大できているということで今後の展望についてもお話があり、アンドパッドでもセキュリティチャンピオンの取り組みをしていきたいという話が最近出たことがあったので、先行事例として非常に参考になりました！ ＜関連記事＞ blog.cybozu.io Security.any#09全体を通しての感想 セキュリティをメインとしているオフラインイベントへの参加は今回が初めてだったのですが、非常に温かい場で、参加している皆様がすごく楽しそうにされているのが印象的でした！ すごく素敵なコミュニティだと思いましたので、これからも定期的に参加したいと思います。セキュリティを始めたてという方にもおすすめのコミュニティだと思いますし、気軽に参加いただけると思います。 お会いした際はお話しできるのを楽しみにしています！ We are actively hiring! アンドパッドのセキュリティグループでは2026年も幅広い取り組みを推進しています。 現在のグループの力だけでは達成が難しい課題もたくさん出てくると思いますので、セキュリティ施策をどんどんリーディングしたい！開発経験を活かして、セキュリティ分野でも仕事をしてみたい！など、様々なご経験のある方を求めています。 カジュアル面談もいつでも大歓迎ですので、ご興味がある方はぜひ以下より申し込みお待ちしております！ hrmos.co またその他にも、さまざまなポジションを募集していますのでご興味がある方はぜひご参照ください！ hrmos.co
- セキュリティ
RubyGems/Bundler における Cooldown 機能の議論と現状
こんにちは、Ruby コミッタの柴田です。最近は暖かくなり、ガーデニングで栽培しているバラや藤の新芽や花芽が出てくる時期になってきたので、しっかり花を咲かせるように薬剤や肥料の準備をしなければ〜と必要なものの買い物計画を立てている真っ最中です。 今回はサプライチェーンセキュリティの対策として他のエコシステムで導入が進んでいる「Cooldown（クールダウン）」機能を紹介し、私がメンテナンスしている RubyGems と Bundler でも導入するべきか検討した背景と、今後の方向性についてお話しします。 Cooldown とは何か Cooldown とは、パッケージの新しいバージョンがリリースされてから一定期間が経過するまで、そのバージョンへの更新を行わないようにする仕組みです。 この機能の主な目的はサプライチェーン攻撃の緩和です。悪意のあるコードが含まれたパッケージがリリースされた場合、待機期間を設けることでセキュリティ研究者やコミュニティがその問題を発見・報告するまでの時間を確保できます。William Woodruff 氏の調査 によれば、検証した10件のサプライチェーン攻撃のうち8件が1週間未満の悪用期間であったとされており、7日間の Cooldown でもほとんどの攻撃を防げた可能性があります。 Andrew Nesbitt 氏の記事「Package Managers Need to Cool Down」でもまとめられているように、2025年後半から2026年にかけて、この Cooldown 機能を言語パッケージマネージャ本体に組み込む動きが急速に広がっています。 プログラミング言語のエコシステムにおける Cooldown 機能 Cooldown に相当する仕組みは、まず依存関係の更新ツールで導入され、その後パッケージマネージャ本体へと広がっています。なお、ツールごとに設定名が異なり（minimumReleaseAge、min-release-age、npmMinimalAgeGate、exclude-newer、uploaded-prior-to など）、少なくとも10種類以上の名前が存在します。ポリグロットな環境では注意が必要です。 依存関係更新ツール GitHub の Dependabot は 2025年7月に cooldown ブロックを導入しました。デフォルトの待機日数に加えて、セマンティックバージョニングのレベル別（major / minor / patch）に異なる日数を指定でき、セキュリティアップデートは Cooldown をバイパスします。 # .github/dependabot.yml version: 2 updates: - package-ecosystem: "bundler" directory: "/" schedule: interval: "weekly" cooldown: default-days: 3 semver-major-days: 7 Renovate では minimumReleaseAge（旧名 stabilityDays）が利用できます。パッケージごとやアップデート種別ごとに粒度の高い制御が可能です。 { "minimumReleaseAge": "3 days", "packageRules": [ { "matchUpdateTypes": ["major"], "minimumReleaseAge": "7 days" } ] } パッケージマネージャ pnpm は v10.16（2025年9月）で minimumReleaseAge を導入しました。パッケージマネージャ本体に Cooldown を組み込んだ先駆的な実装です。値は分単位で指定し、minimumReleaseAgeExclude で特定のパッケージを除外できます。 # pnpm-workspace.yaml minimumReleaseAge: 1440 # 24時間 minimumReleaseAgeExclude: - '@myorg/*' npm は CLI 11.x（2026年2月）で min-release-age を導入しています。Bun は 2025年10月に minimumReleaseAge を、Deno は --minimum-dependency-age をそれぞれ導入しており、JavaScript エコシステムでは主要なランタイムすべてが Cooldown に対応しました。 Python エコシステムでは uv がもともと再現可能なビルドのために提供していた --exclude-newer オプションに相対期間指定（"7 days" のような記法）が追加され、Cooldown 用途にも利用できるようになりました。pip も 26.0（2026年1月）で --uploaded-prior-to を導入しています。pip は絶対タイムスタンプのみの指定である点が uv と異なります。 RubyGems/Bundler の現状 このように多くのツールや言語パッケージマネージャで Cooldown の導入が急速に進んでいます。一方で RubyGems/Bundler 本体には現時点では Cooldown 機能が存在しません。 そこで、RubyGems/Bundler でも rubygems/rubygems の Discussion にて Cooldown 機能の要望があり、導入するべきか、Ruby のコミュニティメンバーや RubyGems 開発チームと議論を行いました。以下にその論点を整理します。 「人柱」問題 私自身が最初に感じた懸念がこれです。Cooldown は「誰かが先にインストールして問題を発見してくれる」ことを暗黙に前提としています。しかし多数のユーザが Cooldown を有効にすると、新しいバージョンを試す人がいなくなり、待機期間が意味をなさなくなります。何もしないよりは良いかもしれませんが、OSS の構造的な限界がある仕組みだと考えています。 セキュリティ修正の遅延 厳密な Cooldown は、緊急のセキュリティパッチの適用も遅延させてしまいます。悪意のあるリリースと緊急のセキュリティ修正を静的解析ツールが自動的に区別することは技術的に困難であり、Cooldown によってかえってセキュリティリスクが高まるケースもあり得ます。 「安心感」という錯覚 10年間更新されていないソフトウェアに未発見の脆弱性が存在する可能性があるように、時間の経過そのものがセキュリティを保証するわけではありません。Cooldown は一定の安心感を与えますが、それが実際のセキュリティ向上に直結するとは限りません。 セキュリティ研究者によるスキャンの時間確保 一方で、セキュリティ研究者が悪意のあるパッケージを発見するための時間を確保する意味は存在します。 実例として、RubyGems セキュリティチームのメンバーである Maciej Mensfeld 氏 の取り組みが挙げられます。Mensfeld 氏は Ruby 向けのサプライチェーンセキュリティプラットフォーム Diffend の開発者であり、これまでに様々なエコシステムで 20,000 件以上の悪意のあるパッケージを検出・報告しています。 RubyGems でも 2020 年に 700 以上のタイポスクワッティング型の悪意ある Gem（例: rails に対する rail）を発見し、2022 年には年間 400 件以上の悪意あるパッケージが削除されました。RubyKaigi 2023 での発表「RubyGems on the watch」でもこれらの取り組みが紹介されています。 現在も、rubygems.org では Gem のリリース後に Maciej 氏を含むセキュリティチームによるレビューが行われており、攻撃コードが含まれると判断した gem は削除されます。Cooldown は単なる時間稼ぎではなく、こうしたスキャン基盤と組み合わせることで初めて実効性を持つ仕組みだと考えています。 RubyGems/Bundler に Cooldown 機能を導入する際の検討事項 以上の議論を踏まえると、短期的な視点では Cooldown 機能を RubyGems/Bundler のオプションとして提供、中長期的には技術的により効果的な対策を講じるのが良いのではないかと考えています。 Bundler での Cooldown オプションの提供 企業環境を中心に要望が多いこと、また Dependabot や Renovate が既に同等の機能を提供していることから、RubyGems/Bundler 単体でも設定できるようにすることには意味があると思っています。 仕様としては以下のようなものを考えています。 bundle update --cooldown 3 のように CLI オプションで指定する bundle config set cooldown 3 のようにグローバル設定で指定する Gemfile 内でブロック構文を用いて特定の Gem にのみ Cooldown を適用する粒度の高い制御 gem install コマンドでも同様の Cooldown をサポートし、GitHub Actions などの CI/CD 環境でも利用可能にする あくまでオプションであり、デフォルトでは無効とするのが妥当だと考えています。ユーザが自分の運用方針に合わせて選択できる形が望ましいでしょう。 RubyGems.org でのスキャンとメタデータ提供 Cooldown の実効性を高めるためには、単に時間が経過したかどうかだけでなく、その Gem が検査済みかどうかという情報も重要になってきます。RubyGems.org 側で以下のような仕組みを整備できると、より実効性のある対策になると考えています。 新しい Gem のリリースに対する自動スキャンの実施とスキャン済みであることをインデックスのメタデータとして公開 最近のメンバーシップ変更や Trusted Publishing の無効化など、リスクの高い条件が揃ったリリースに対する遅延の導入 RubyGems/Bundler がこれらのメタデータを参照して動作を制御できるようにする さらに「スキャン済みであることを示すバッジがあると良いのでは」という提案もあり、RubyGems.org の UI として検討する価値があると思います。 Cooldown とは別のアプローチ Cooldown とは別に、gem install 時のコード実行そのものをサンドボックス化するアプローチも議論としてあります。 github.com RubyGems や Bundler は最近 Download と Install を分離する変更が入りました。 github.com この変更はパフォーマンス向上が目的ですが、2つの処理を分離することにより、Download の後に SAST などを用いてコードの検証、問題がない場合は Install など、自動化を可能としつつ現在よりも効果的な対策が望めます。 まとめ RubyGems/Bundler における Cooldown 機能について、他のエコシステムの動向と議論の背景を紹介しました。Cooldown は完璧な解決策ではありませんが、RubyGems.org 側でのスキャンやメタデータの提供と組み合わせることで、実効性のある対策にできる可能性があります。 アンドパッドでは、こうした OSS のセキュリティやエコシステムの改善に興味があるエンジニアを募集しています。RubyGems/Bundler のようなエコシステムの基盤技術について議論しながら、プロダクト開発やセキュリティ対策を実行していくことに興味がある方は、ぜひご応募ください。 hrmos.co
- Ruby
- セキュリティ
- OSS
アンドパッド 技術イベントのご案内 2026 年 3 月
こんにちは、 id:sezemi です。 小 3 の娘がガチャガチャ (いまはカプセルトイというのが主流 ...) にハマっており、その中でも "こめちゅあ" を集めています。 ただハマったのが最近で、いま出ている vol.2 より、 vol.1 に夢中になっていて、収集が難しくなっております。 もし「こめちゅあ vol.1 がココにあるよ！」という情報があれば、こそっと X でメンションいただけると、とても喜びます。 さて、アンドパッドでは、技術やプロダクト開発、組織に関するさまざまなカンファレンス・イベントでの登壇、開催や会場提供などを行っています。毎月、イベント情報をまとめてお知らせしています。ぜひご参加ください !! また今回は前月 2 月の開催レポートもお知らせします。 なお、開催状況により、満員となってしまっている場合、すでに受付を終了している場合がございます。 1. 登壇情報 | Road to SRE NEXT 2026 @福岡 開催日時 : 2026年3月13日(金) 会場 : 株式会社アンドパッド 主催 : 株式会社Fusic オープンオフィス イベント概要 : SRE の普及・発展を目指すカンファレンス「SRE NEXT」のプレイベントです。 申込方法 : イベントページからお願いいたします。 https://sre-lounge.connpass.com/event/382311/sre-lounge.connpass.com 本イベントにて 谷合 純也 が登壇予定です。 谷合 純也 @jnytnai0530 2025 年 11 月入社。現職ではマルチプロダクトを横断的に支援する SRE チームに所属。トイルの自動化や様々な仕組みづくりに関心があります。ｱｻﾋｨｽｩﾊﾟｧﾄﾞｩﾙｧｧｧｧｲが好きなエンジニア。 谷合 純也 のテックブログ執筆記事 アンドパッドのSRE・DBRE・CRE：2025年の活動ハイライト 発表タイトル: SRE がやりたい仕事に集中するための処方箋 SRE が本来の職務であるサイト信頼性や自動化に集中できず、 DB 相談やアカウント発行などの「便利屋化」する現状があります。 本発表ではアンドパッドの事例を元に、「やらないこと」を明確にして解決するプラクティスをご紹介します。 2. 登壇・会場提供情報 | Security.any #09 卒業したいセキュリティLT 開催日時 : 2026年3月19日(木) 会場 : 株式会社アンドパッド 主催 : Security.any イベント概要 : Security.any が主催するイベント「Security.any #09 卒業したいセキュリティLT」が開催されます。 申込方法 : イベントページからお願いいたします。 https://security-any.connpass.com/event/382763/security-any.connpass.com 本イベントにて、アンドパッドが会場提供を行うほか、 Kiyotaka Ginoza が登壇予定です。 Kiyotaka Ginoza @kiyogino 派遣エンジニア企業にてインフラエンジニアとして勤務したのち、 2020 年 6 月にアンドパッドに入社。 SRE として運用やセキュリティの課題に数年取り組み、 2024 年からセキュリティチームのテックリードに就任。 趣味は読書、サッカー観戦。 Kiyotaka Ginoza のテックブログ執筆記事 アンドパッドセキュリティチーム 初のチーム合宿を開催！ 3. 登壇情報 | Tamachi.sre#3 開催日時 : 2026年3月19日(木) 会場 : 株式会社IVRy オフィス 主催 : Tamachi.sre イベント概要 : Tamachi.sre は田町らへんでやる SRE のオフライン勉強会です。 SRE のテーマであれば、何でも発表は OK のイベントです。 申込方法 : イベントページからお願いいたします。 https://tamachi-sre.connpass.com/event/381960/tamachi-sre.connpass.com 本イベントにて、アンドパッドが 島根 雄也 が登壇予定です。 島根 雄也 @YEngine8 新卒で百貨店に総合職として入社。 2018 年にラクスにテクニカルサポートとして入社し、 IT 業界へ。 2021 年 10 月、アンドパッドに CRE として入社。 島根 雄也 のテックブログ執筆記事 SRE Kaigi 2025 でアンドパッドCREチームの5年史を発表しました 2026 年 2 月の開催レポート ここからは先月に開催されたイベント・カンファレンス等のレポートです。 1. Go Conference mini in Sendai 2026 非公式 前夜祭 日時 : 2026年2月20日(金) 会場 : enspace 5B1 主催 : アンドパッド 当日のタイムライン: #sendaigo 予定されていた前夜祭が急遽中止となった関係で、非公式ながらアンドパッドが前夜祭を開催しました。 告知が急だったにも関わらず、熱心な Gopher が集まり、定員 40 名満席となりました。 ご参加いただいた皆さま、ありがとうございました ! そこで #golang_friends という、 Ruby コミュニティでカンファレンスで出会った方と仲良く写真を撮って、友だちになる #rubyfriends をオマージュしたハッシュタグを提案したのですが、いくつか写真が投稿されており、胸熱でした。 今後、広まることを願っております。 また当日のプログラムの 1 つ、座談会形式でタイムテーブルを眺めた予習会では、急遽声がけしたにも関わらず、二つ返事で OK いただいた tenntenn さん、 sivchari さんに出演いただきました。 ありがとうございました ! お陰様で、沢山の方に喜んでいただけたようでした。 前夜祭を取り上げていただいた参加レポート ujiprog.com sago35.hatenablog.com 2. 登壇情報 | Go Conference mini in Sendai 2026 日時 : 2026年2月21日(土) 会場 : アーバンネット仙台中央 カンファレンスルーム 主催 : Sendai.go 当日のタイムライン: #sendaigo 通常は 1 トラックでの開催が多い Go Conference mini ですが、今回は 2 トラック構成で多彩なトークが行われ、アンドパッドからも 小島 夏海、sunecosuri が登壇しました。 なお、 Go Conference mini in Sendai 2026 については別途、テックブログで参加・協賛レポート記事を近日公開します。 ぜひご期待ください。 3. Go 1.26 リリースパーティ 日時 : 2026年2月25日(水) 会場 : 株式会社アンドパッド 主催 : Gophers Japan 当日のタイムライン: #go126party 定期開催されている Go の新しいバージョンのリリースを祝うパーティです。 1.26 で入った様々な新機能を紹介いただきました。 アンドパッドは会場提供を行ったほか、 tomtwinkle が「米国のサイバーセキュリティタイムラインと見る Go の進化」というタイトルで登壇しました。 私も配信を担当しながらトークを聞いていたのですが、 arthur1 さんのトーク「go directiveを最新にしすぎないで欲しい話──あるいは、Go 1.26からgo mod initで作られるgo directiveの値が変わる話 / Go 1.26 リリースパーティ」で、 Go 1.26 が出たのに、 Go 1.25 で入った機能を喜ぶ、というお話がとても印象に残りました。 1.26 がリリースされると、ビルドに要求されるバージョンを定義する go directive まで 1.26.0 に上がってしまい、まだ公式のサポート期間内であるはずの Go 1.25 を使っているユーザー環境に対して、予期せぬツールチェーンの更新を強いてしまったり、特定の環境下でビルドが通らなくなってしまったりします。 また、その他、パッチのバージョンによってはまだバグが残存していたり、セキュリティ修正が必要だったりするケースがあり、あえて 1 つ前のバージョンを使いたいケースもありますが、これも出来ません。 なかなか使う側にとってもツライ話ですし、 OSS 作者にとっては最新版への速やかな追従を強制されるので、なかなか負担が大きいですね。 この現状を変える proposal が通ることを願っています。 4. 福岡Rubyist会議05 スポンサー 日時 : 2026年2月28日(土) 10:00–18:00 会場 : リファレンス駅東ビル 3 階 会議室H-2 主催 : Fukuoka.rb 当日のタイムライン: #fukuokark05 「最近、何してる？」をテーマに開催されました。 アンドパッドは スポンサー として協賛し、ブースを出展したほか、 hsbt によるスポンサートークも行いました。 ブースでは、アンドパッドの「最近、何してる？」としてプロダクト本部・開発本部における AI 活用状況を紹介しました。 同じようにブース来場者の方にも同じアンケートを実施したところ、アンドパッドの活用状況と、ほぼ同じような傾向が見られたことが発見でした。 現在の業務で AI に渡したいと感じる負担が大きい作業はどれですか？ という質問の回答として、既存コード（他人が書いたコード）の読解・調査 が一番でした スポンサートークでは hsbt が主にアンドパッドの会社紹介・業界説明をしました。 エンタープライズなお客様での利用が増えていることに驚かれたり、福岡にアンドパッドの支社があるのは知らなかったなど、いい反響をいただきました。 興味を持たれた方はぜひアンドパッド福岡オフィスでお会いしましょう ! また、トークでは こしば家 による「ふつうの Rubyist、ちいさなデバイス、大きな一年」では Tiny デバイスを使ったデモを披露されるなど、とても賑やかなトークがあったほか、「Rubyist としてアメリカで 10 年戦ったらどうなったか」では登壇された Jugyo さんが、長年勤めた会社をレイオフされても Ruby/Rails を使っていたことで新しい会社に転職できた、という、いいお話を披露されるなど、テックトーク / ソフトトークどちらも織り交ぜたタイムテーブルで、とても楽しかったです ! 参加された皆さま、登壇された皆さま、そして 福岡Rubyist会議05 Team の皆さま、ありがとうございました !! まとめ 採用広報から 3 月に開催されるイベント予告と、 2 月の開催レポートをお届けしました。 またイベントやカンファレンスでお会いできることを楽しみにしています ! また、アンドパッドでは技術コミュニティが大好きな採用広報を大歓迎しています。 広報の経験がない方でも Welcome です！ カジュアル面談やご応募、お待ちしております。 hrmos.co
- SRE
- セキュリティ
- Go
- Ruby
なぜGoは「デフォルトが一番安全」を目指すのか？ - Secure by DesignとGo の動向
はじめに どうも、ANDPADテックリードの tomtwinkle です。 今回は Go 1.26 リリースパーティで話す予定…でしたが、どうも尺に収まらないので泣く泣くカットした分 を事前に記事として公開しておく内容です。 と言いつつ、この記事も書いてたら分量多くなりすぎて Go 1.26 ネタが入りきらなかったので Go 1.26 ネタを聞きたい人はリリースパーティーで会いましょう。 発表後、Go 1.26ネタを含んだ第二弾を公開予定です。たぶん。 https://gocon.connpass.com/event/381405/gocon.connpass.com みなさんは 「Secure by Design」 という言葉をご存知でしょうか？ 元ネタ自体はAnn Cavoukian博士が1990年代の半ばにIPCの官庁出版物に書いた「Privacy by Design」をモジッたものだと思います。 2000年代初頭にマイクロソフトがビル・ゲイツの号令（Trustworthy Computingメモ）のもと、SDL（Security Development Lifecycle） を導入した時期から、ソフトウェア工学の文脈で頻繁に使われるようになり 2023年に米国のCISA(Cybersecurity and Infrastructure Security Agency) が「Secure by Design - Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software」というガイドラインを出したことで今、再度注目を浴びているキーワードです。 www.cisa.gov 英語が読める人はPDFを見てもらうのが一番手っ取り早いと思いますが、日本語で読みたい人向けに全文翻訳記事を以前書きました。結構同じこと書いてあって冗長だし長いのでAIに要約してもらったほうが良いかもしれません。 zenn.dev この記事用の「Secure by Design」のざっくり概略 よし、みんな記事を読んだよね！ ……だと流石に記事として不親切なのでざっくりと今回の記事に関連する部分だけ概要を書いておきます。 Secure by Design とは 「製品を作ってからセキュリティ対策をする（bolted on）のではなく、設計（デザイン）の段階からセキュリティを組み込んでおく（baked in）」 ということです。 CISAの「Secure by Designガイドライン」を読んでいくと 「Secure by Default」 というキーワードが出てきます。 要するに、何らかのシステムやプログラミング言語の関数などを利用する際に Defaultのまま利用するのが一番安全にしておくように設計しておきなさい という事ですね。 「Secure by Designガイドライン」の本質は「セキュリティの責任をユーザー（利用者）からベンダー（製造者）へ移す」点にあります。 Secure by Defaultではない設計例 C言語のgets関数 (C11以降は廃止されました) #include <stdio.h> int main() { char str[10]; printf("文字列を入力してください: "); gets(str); // 10文字以上入力されるとバッファオーバーフローが発生する printf("入力された文字列: %s\n", str); return 0; } PHP の echo構文や 短縮構文<?= ?> <div> <!-- 変数の文字列をエスケープせずにHTMLにそのまま書き出してしまうため、XSSの危険がある --> こんにちは、<?= $name ?> さん </div> 特に昔から使われているプログラミング言語では歴史的経緯から利用者の選択と自由を最大限尊重する設計であるため、エスケープ機能などは実装者が意識的に行う必要があります。 ここに書いた特定言語を貶める意図はありません、念の為。 特に暗号化ライブラリを取り巻く状況などは過去と現在では大きく状況が異なっています。 Go言語でのSecure by Defaultな設計の例 Go の database/sql // 標準パッケージが提供している関数の引数通りに利用すれば自動的にPreparedStatementが利用される db.Query("SELECT * FROM users WHERE name = ?", userName) // わざわざ実装者が明示的に文字列結合しないとSQLインジェクションが起きない query := fmt.Sprintf("SELECT * FROM users WHERE name = '%s'", userName) db.Query(query) Go の html/template Go Playground - The Go Programming Language // 悪意ある入力 input := "<script>alert('XSS')</script>" // テンプレート定義 // {{.}} の部分に入力が入る tpl := template.Must(template.New("page").Parse(` <div>{{.}}</div> <a href="/search?q={{.}}">Link</a> `)) // 実行 tpl.Execute(os.Stdout, input) // <div> の中ではHTMLエスケープされる // <div><script>alert('XSS')</script></div> // href のURLクエリの中では、URLエンコードされる // <a href="/search?q=%3cscript%3ealert%28%27XSS%27%29%3c%2fscript%3e">Link</a> 「JCDC」「Secure by Design宣誓」と Go CISAはこの「Secure by Design」ガイドラインを出した際に ガイドラインを守りますという「宣誓」を行った企業 を発表しています。 www.cisa.gov そして、その企業の中に Goチームを抱えるGoogleのサインが存在している ことが分かります。 www.cisa.gov なんとなく、2023年前後のGoのリリース(Go 1.20 - ) や Go Blogを見ていると徐々にセキュリティ関連のリリースが何となく増えたなという印象がありませんか？ 気のせいかな？タイムラインでGoと周辺で起きた事件を調べてタイムラインにしてみましょう。 Go(と関連する周辺)のセキュリティ対応タイムライン というわけでGo Blogでのセキュリティ対応に関する記事と米国でのサイバーセキュリティに関するニュースをピックアップしてタイムラインを作成しています。 元ネタは基本的にはGo BlogとCISAのリリースと「piyolog」と「セキュリティホール memo」。いつもお世話になっております。 go.dev piyolog.hatenadiary.jp www.st.ryukoku.ac.jp Goに関係するものを 太字 にしています。 2020年12月13日 - サプライチェーン攻撃 SolarWinds事件 2021年5月7日 - ランサムウェア Colonial Pipeline事件 2021年5月12日 - 大統領令第14028号 “Executive Order on Improving the Nation’s Cybersecurity”（国家のサイバーセキュリティ強化に関する大統領令) 2021年8月5日 - JCDC（共同サイバー防御コラボレーティブ）の設立 ここでCISAとGoogle、Amazon、Microsoftなどが共同でサイバーセキュリティを協議開始 2021年9月15日 - <a href="https://go.dev/blog/tls-ciph
- Go
- セキュリティ
- 暗号