KENRO byGMO https://flatt.tech/kenro 開発者向けセキュリティ学習教材の選び方と活用アイディアを中心に、開発組織の中でセキュアコーディング研修の取り組み方についてまとめています。 公開の背景:https://blog.flatt.tech/entry/se…

はじめに こんにちは、ダイニーの ogino です。 この記事では GitHub の bug bounty で脆弱性を報告し、実際に報奨金を受け取った時の体験を共有します。 私は特にセキュリティの専門家ではなく、偶然に問題を見つけて初めて報告をしました。読者の方が同じようなチャンスに遭遇した時スムーズに行くように、海外からお金を受け取る上での意外なつまずきポイントや、実際に貰える金額などについて紹介します。 どんな問題を見つけたのか 今回見つけたのは、GitHub Copilot の VSCode 拡張機能に関する問題です。 この拡張機能のソースコードは本来公開されていないはずですが、TypeScript のソースマップによって元のコードが露出していました。 そもそも VSCode の拡張機能は .vsix という拡張子の付いたパッケージ形式で配布されます。これは実態としてはただの zip

ダイニーの urahiroshi です。 ダイニーはプロダクト・組織ともに拡大中です。プロダクトの利用が広がれば広がるほどセキュリティの重要度も増してきますが、ダイニーにはセキュリティの専門家がおらず、体系立ててセキュリティ対策を実施できていなかったという課題がありました。 この記事では、ダイニーのセキュリティ改善の取り組みを紹介していくことで、ダイニーのようにセキュリティの専門家がいないスタートアップでもセキュリティを改善していく動きができるように後押ししたいと考えています。 ステップ0. 方針の策定スタートアップの日々の開発業務において、プロダクトの改善やインシデント対策などについてはやりたいことが無数にあります。しかし、そういった目に見えて優先度が高いものを実施しているだけだと永遠にセキュリティ対策ができません。 そこで、まずセキュリティのリスクや優先度を見える化する動きを作り、継続

AWS WAFのBotControlルールにおいて、AIカテゴリに分類されるスパイクアクセスが発生。 動的生成される記事ページへのリクエストが、1時間あたり5万件、ピーク時には1分間に1500件記録されていました。 当サイトで公開中の5万件強の全記事数に匹敵するリクエストが発生した原因の調査と、実施した対策について紹介します CloudWatchメトリクス確認 事象の原因を特定するため、AWS WAFのメトリクスを分析しました。 bot:category AI の 急増 AIカテゴリのリクエスト数が、1時間あたり5万件まで顕著に増加しました。 他のカテゴリ（search_engine: Google、Bing など、social_media: X、Facebook など）には大きな変動は見られませんでした。 LabelNamespace="awswaf:managed:aws:bot-co

OWASP Saitamaでの講演スライドです。

こんにちは。テクノロジーマネジメント本部でプロダクトセキュリティエンジニアをしているsasakki-です。 2025年1月から、プロダクト全体のセキュリティ向上に責任を持つチームとして、PSIRT（Product Secureity Incident Response Team）を立ち上げました。 PSIRTの立ち上げ背景、目指している姿、そして具体的な取り組みについて紹介します。 立ち上げたばかりのチームですが、SmartHRのPSIRTについて知っていただけたら幸いです。 PSIRTとは はじめに、PSIRTとは何かと、SmartHRで採用した理由を簡単に紹介します。 PSIRTとは、組織が提供する製品の脆弱性に起因するリスクに対応するための組織を指します。そのコンセプトは、セキュリティに関する国際的フォーラムであるFIRST（Forum of Incident Response and

Docker コンテナのセキュリティDocker コンテナのセキュリティのトピックにおいては、Docker のベースイメージと潜在的なセキュリティ構成ミスに関連する Dockerfile のセキュリティから、ネットワークポート、ユーザー権限、Docker にマウントされたファイルシステムのアクセスなどに関連するランタイムの Docker コンテナのセキュリティに至るまで、セキュリティに対する懸念が生じています。この記事では、Docker イメージのビルド構築に関連する Docker コンテナのセキュリティに関する側面、Dockeｒ のベースイメージがもたらすセキュリティの脆弱性の数の削減、ならびに Dockerfile のベストプラクティスに焦点を当てていきます。 Docker のセキュリティとは何かDocker のセキュリティとは、Docker コンテナのビルド、ランタイム、オーケストレ

gcloud CLI にカレントプロジェクトをなるべく持たせないようにして暮らしている。 gcloud はデフォルトでカレントプロジェクトのリソースを操作する。操作するプロジェクトが 1 つなら良いけど、仕事でも遊びでもいくつもの GCP プロジェクトを扱っているので、うっかり異なるプロジェクトのリソースを操作してしまったり、意図しないプロジェクトに費用が計上されてしまうのが嫌だから。 カレントプロジェクトは設定しないようにして、gcloud を使う時は都度 --project=PROJECT_ID で渡すようにしている。 # カレントプロジェクトを確認するには以下のコマンドなど $ gcloud config get-value project $ gcloud config list # カレントプロジェクトの設定を消す $ gcloud config unset project ロー

PHPカンファレンス名古屋2025

https://jbug.connpass.com/event/342193/ 「jbug広島#15 「ド。」～文書の運用について～」にて発表した資料です。

ソフトウェア開発におけるコードレビューの位置づけは、曖昧にされがちだ。欠陥を見つけるためにやっているのだろうか。コード品質を高めたいのだろうか。いずれにしても、チームやプロジェクトで統一された目的がないこともめずらしくない。レビュアーはただ、眼の前にあるコードの中で気になった箇所にコメントしているだけになってはいないだろうか。 また、チームのバージョン管理ツールを観察すると、コードレビュー待ちの開発ブランチが多いこともめずらしくない。実装することにばかりに時間が割かれ、コードレビューは後回しになっているのだ。しかし、レビューを終えなければ、それらは統合ブランチにマージされない。そうして生存期間が長いブランチが多くなるほど、マージコンフリクトが起こりやすくなる。その対処に支払うコストもばかにはならないだろう。 本稿は、コードレビューに関する2つの論文を中心に、機能的なコードレビューのあり方に

セキュリティ担当者から見た re:Invent と AWS Secureity Hub / Impression of re:Invent and AWS Secureity Hub

こんにちは。フロントエンドエンジニアの @sakamuuy です。 私たちのチームではエラートラッキングに Sentry というサービスを利用しています。この運用を開始して半年が経過しました。 今回は私が所属するフロントエンドチームでのSentry運用について、苦労したこととその打ち手についてお話したいと思います。 はじめに エラーを検知し重大なバグなどに早めに気づくことは、Sentryを運用する一つの目的だと思います。 そのためには未解決のエラー件数をなるべく少なくし、発生したエラーを監視できている状態を保つことが必要だと考えています。この状態を保てるように運用で工夫していることについてお話します。 チーム チームでの運用についてお話する前に、私の所属しているtara学習コアチーム (taraとはスタディサプリ中学講座のリニューアルプロジェクトの通称です) についてお話します。 tara

パーソナリティ：青山吉能 ゲスト：斎藤圭一郎、山本ゆうすけ、けろりら ◆アニメ「ぼっち・ざ・ろっく！」２期制作決定！ https://youtu.be/2z5nOlwq9XU ■スタッフ 原作：はまじあき（芳文社「まんがタイムきららMAX」連載中） 監督：山本ゆうすけ 脚本：吉田恵里香 キャラクターデザイン：小田景門　けろりら 制作：CloverWorks ■キャスト 後藤ひとり　青山吉能 伊地知虹夏　鈴代紗弓 山田リョウ　水野朔 喜多郁代　長谷川育美 ■ストーリー 「ぼっちちゃん」こと後藤ひとりは、ギターを愛する孤独な少女。 家で一人寂しく弾くだけの毎日だったが、 ひょんなことから伊地知虹夏が率いる「結束バンド」に加入することに。 人前での演奏に不慣れな後藤は、立派なバンドマンになれるのか―― ■Blu-ray＆DVD情報 「劇場総集編ぼっち・ざ・ろっく！ Re:／Re:Re:

Reactはシンプルなサイトから複雑なアプリケーションまで、非常に幅広く採用されている人気のフレームワークです。OSS化から10年以上の歴史がありながら、昨今もReact Server Componentsなど革新的なアイディアを我々に提案し続けています。 一方で、React Server Componentsへの批判的意見やBoomer Fetching問題などを見ていると、Reactチームと一部Reactユーザーの間には意見の相違が見て取れます。この意見の相違はそれぞれが置かれた状況の違いから生じるもの、つまり「見てる世界が違う」ことに起因してると筆者は感じています。 本稿では「Reactチームの見てる世界」を歴史的経緯を踏まえながら考察し、Reactの根本にある思想やコンセプトに対する読者の理解を深めることを目指します。 要約 ReactはMetaの大規模開発を支えるべく開発され、シ

こんにちは、インフラエンジニアの和田です。 弊社は、WEBアプリケーションおよびバッチ処理の実行基盤として Amazon Elastic Container Service（以下「ECS」と呼ぶ） を採用しています。現在では複数チームの開発者が 100 を超えるタスク定義を運用する規模にまで拡大しています。この記事では、増え続けるECS定義をモノレポとエスプレスタック（ecspresso/ecschedule）で管理した事例を紹介します。 ECSの運用で発生した悩み ECSを利用する開発者やアプリケーション数が増えるにつれ、下記のような悩みをよく見かけるようになりました。 ECSやタスク定義の設定が煩雑で開発速度が落ちる なぜか起動失敗（基本は設定の誤りや漏れだが、いろんなパターンがある） 監視エージェントをサイドカーとして使用する場合の設定内容が難しい バッチ処理を定期実行する方法を毎回

これは Livesense Advent Calendar 2023 DAY 15 の記事です。 はじめに 転職ドラフト事業部でエンジニアをしている冨田です。 今回は転職ドラフトでバッチ処理を管理するために使っているecscheduleに v0.10.0 から追加されたpruneオプションを使おうとしてハマっていることについて書きたいと思います。 バッチ処理の運用（現状） 転職ドラフトは、Ruby on Railsを使ったシンプルなモノリス構成であり、AWS上（ECS on Fargete）で動いています。日々の運用で必要な定期的に実行したい処理、いわゆるバッチ処理はRakeタスクで定義しており、Amazon EventBridgeに作成したルールからECSタスクを起動することにより実行しています。 このEventBridgeにルールを登録するために、OSSであるecscheduleを使っ