「チームワークあふれる社会を創る」という企業理念のもと、チームワーク支援のグループウェアを開発するサイボウズ様は、2011年ごろから会社としてセキュリティへの取り組みを進めてきました。独自に運営する脆弱性報奨金制度などをはじめ、国内でも先進的なセキュリティへの取り組みを続ける同社の大塚氏・長友氏にお話をうかがいました。 サイボウズ株式会社様 グローバル展開する国産グループウェアの先駆けとして、「kintone」「サイボウズOffice」「Garoon」「メールワイズ」などを展開

SBOM の必要性が増している背景や国内外の状況、具体的な SBOM の仕様、SBOM 対応の方法についてお伝えしました。

特にゼロデイ攻撃を抑えて6位にランクインしている「脆弱性対策情報の公開に伴う悪用増加」とは、まさに既知の脆弱性を利用した攻撃のことを指摘しており、SBOMを利用して現在利用されているソフトウェアやそのバージョンが管理できていれば、事前に被害を抑えられたものであると言えるでしょう。 SBOMを取り巻く国内外の状況米国大統領令におけるSBOMの位置付けこれまでに説明してきたような既知の脆弱性に対する攻撃に対処するため、米国では2021年5月にSBOMに関する大統領令が発令されました。この中には、米国国立標準技術研究所（NIST）と米国商務省電気通信情報局（NTIA）が協力してSBOMの最小構成要素を定めること、NISTがソフトウェアサプライチェーンを明確にするためのガイドラインを策定すること、また製品購入者への SBOM提供に関する項目も含まれています。 さらに、ここで検討された内容をもとに政

2022年7月に「アジャイル開発におけるセキュリティ | パターン・ランゲージ」が公開されました。 こちらのドキュメントは、「アジャイル開発においてセキュリティをどのように担保するか」をパターン・ランゲージを使って解説されたものになっており、DevSecOpsに取り組むためにとても参考になります。 今回はDevSecOpsを成功させるためのポイント共に「アジャイル開発におけるセキュリティ | パターン・ランゲージ」の内容を紹介し、具体的にどのようなことを検討し、取り組み必要があるのかを私の経験を踏まえて解説したいと思います。 「アジャイル開発におけるセキュリティ | パターン・ランゲージ」とは？「アジャイル開発におけるセキュリティ | パターン・ランゲージ」は、「脆弱性診断士スキルマッププロジェクトが作成した『アジャイル開発においてセキュリティをどのように担保するか』のヒントを過去の成功事

Amazon Translateでも利用されている機械翻訳フレームワークSockeyeとPythonのマイクロサービスフレームワークnamekoの任意のコード実行に繋がる脆弱性を発見し、報告を行い、CVEを2件(CVE-2021-43811, CVE-2021-41078)取得しました。 オープンソースソフトウェア(OSS)の脆弱性を発見、報告、CVEを取得までどのような過程を経たのか、OSSの脆弱性を見つける場合にはどのようにすると良いのか、報告方法はどうすればいいのか、今回の経験をもとにポイントを紹介します。 脆弱性報告の経緯 そもそもOSSの脆弱性を発見した経緯としては、前回の「TensorFlowだけじゃない！安全でないデシリアライゼーション in Python」の記事を書く中で、GitHubでyaml.unsafe_loadやyaml.UnsafeLoaderで検索すると脆弱な実

node-tarで発見された任意のファイルの書き込み・上書きの脆弱性(CVE-2021-32804)について調査を行いました。 node-tar 3.2.2, 4.4.14, 5.0.6, 6.1.1以前のバージョンを利用している場合、この脆弱性の影響を受けることがあります。 加えて、node-tarを間接的に利用している場合にも影響を受けることがあります。具体的には、npmもtarファイルを扱う処理にnode-tarを使っているため、脆弱なバージョンのnpmを使って、信頼できないtarファイルを処理することで影響を受ける場合があります。 今回は、CVE-2021-32804の修正コミットを確認してどのような脆弱性だったのか確認し、実際に脆弱性が再現できるのかDockerで環境を用意して検証を行いました。 また、npmにも影響があるかの検証も行い、こちらもDockerの環境にて確認を行いま

XXE（XML 外部エンティティ参照）は、アプリケーションが XML を解析した際に XML の特殊構文を悪用されて発生する脆弱性です。本記事では XXE の仕組みから対策方法までを解説していきます。

CSRF（Cross-site Request Forgery：クロスサイトリクエストフォージェリ） は Web アプリケーションのユーザー（利用者）に意図しない通信リクエストを送信させ、利用者の意図しない処理をサービスに実行させることが可能となる脆弱性、またはその脆弱性を利用した攻撃手法を指します。 昨今のサイバーセキュリティにおける代表的な攻撃手法です。 本記事では CSRF の仕組みから対策方法までそれぞれ解説していきます。 CSRF の概要CSRF（クロスサイトリクエストフォージェリ）は、Web アプリケーションが偽装された（本来送信されるべきではない）リクエストを正規のものとして受信してしまう脆弱性、または攻撃手法を意味します。 CSRF には呼び名がいくつか存在し、以下のような名称で呼ばれることもあります。 シーサーフ XSRF リクエスト強要 セッションライディング ※名前の

Apache ライセンス （アパッチライセンス、Apache License）とは、オープンソースソフトウェアを開発・配布する際に用いられる代表的なオープンソースライセンスのひとつで、利用許諾のための条件などを定めているものです。 本記事では Apache ライセンスの概要から Apache License 2.0 の内容、適用方法、掲載例について解説していきます。 Apache ライセンスの概要 Apache ライセンスは、Apache ソフトウェア財団（ASF）によって作成されたソフトウェア向けライセンス規定です。 バージョン 1.1 以前は Apache Software License（ASL）と呼ばれていました。 世界中のソフトウェアで Apache ライセンスは利用されており、2020 年に GitHub で公開されているプロジェクトの 18% が Apache License

yamoryを導入するまでは、担当者が定期的に脆弱性情報のサイトを見に行き、情報を確認する形で実施していました。 ただし、このやり方だと月に2〜3日分のエンジニアの工数がかかってしまうし、担当者によって参照するサイトが異なる等やり方もばらばらであり、情報のばらつきや検知スピードの担保が困難な面もありました。 また、お客様から「脆弱性のニュースが出ているが、対応は大丈夫か」といったお問い合わせがあった際もその都度担当者が調査しており、やはり工数がかかっていました。 当時、お客様からオープンソースのライブラリの脆弱性についてお問い合わせを受けることが多く、その対応に追われている時にちょうど展示会で yamoryを知りました。 早速試してみたところ、お客様からお問い合わせを頂いていたライブラリの脆弱性がまさに検知されたので、詳しい説明を聞きたいとyamoryに連絡をしました。 エンジニアが上記の

OWASP Top 10 Proactive Controls（OPC）とは、ソフトウェア開発者向けに作成された設計や実装時のセキュリティのベストプラクティスをまとめたものです。 本記事では、本記事作成時点での最新版の OWASP Top 10 Proactive Controls 2018 についての概要と 2016 との比較について解説していきます。 OWASP Top 10 Proactive Controls 2018 の概要OWASP Top 10 Proactive Controls は、OWASP Top 10 などで有名な OWASP（Open Web Application Security Project）という Web アプリケーションセキュリティの情報共有、啓発を目的としたコミュニティが提供するドキュメントのひとつです。 OWASP Top 10 では、重要な We

ソフトウェアを開発されている方は、オープンソース・ソフトウェア（OSS）を利用して開発することが多いと思います。 OSS の導入時には最新のバージョンのものを利用するため脆弱性が含まれていなかったとしても、時間が経つにつれ脆弱性が新たに公開され、セキュリティリスクが高まることがあります。 自分たちが使っている全てのライブラリとそのバージョンを常に把握して、新たに公開された脆弱性がないかどうかを人手で監視することは非常に労力のかかる作業でしょう。 開発チームの規模が大きく、複数のプロジェクトを管理する場合にはより多くの工数がかかることが予想されます。 脆弱性管理ツール「yamory」 では、これらの作業を自動化し、自分たちに影響がある脆弱性情報だけを通知することができます。 また、脆弱性の対応優先度を自動で分類し、脆弱性への対策を提示することもできるので調査工数を削減することもできます。 本

これは CVE のそもそもの目的が以下の 2 つであることが関係しています。 識別可能性の確保 … 個々の脆弱性に固有の CVE 識別番号を割り当て、CVE 識別番号によって脆弱性を識別可能とすること 命名…個々の脆弱性に（業界標準的な）名前を付けること これらを一般に提供することでサイバーセキュリティやサイバー攻撃に対する情報連携を効率化し、実際の対策面は外部サイトや他の脆弱性データベースやセキュリティ機関に任せるというのが CVE の立ち位置として見られます。 なお、この目的などについては MITRE 社が提供する CVE の WEB サイト上にも記載されています。 脆弱性の対策などを含んだ情報登録がなされている脆弱性情報データベースの代表例としては、NIST（National Institute of Standards and Technology: アメリカ国立標準技術研究所)]

株式会社アシュアードが主催・登壇するセミナーをご紹介しています。各セミナーの詳しい内容については、詳細ページよりご確認いただけます。脆弱性対策でお悩みの方はぜひお気軽にご相談ください。

本記事では、実際のコードを交えて Java における安全ではないデシリアライゼーションの解説を行い、この脆弱性を見つけた場合にどのように扱えばよいのか、どのような対策を行えばよいのかを解説します。

GPL ライセンス （ジーピーエルライセンス、GPL License、GNU General Public License）とは、オープンソースソフトウェアを開発・配布する際に用いられる代表的なオープンソースライセンスのひとつで、利用許諾のための条件などを定めているものです。 本記事では GPL ライセンスの概要から掲載例について解説していきます。 GPL ライセンスの概要 GPL は GNU General Public License の略で、GNU プロジェクトのためにリチャード・ストールマンによって作成されたライセンスです。 フリーソフトウェア財団（FSF; Free Software Foundation）によって公開・管理されています。 GPL ライセンスは、コピーレフト性を持つライセンスとして有名です。 WordPress を始め、さまざまなソースコードなどへ付与されているこ

2020 年 12 月 8 日に Apache Struts 2 の脆弱性 S2-061（CVE-2020-17530）が公開されました。 影響としては、Struts 2.5.25 までのバージョンで OGNL 式の二重評価によってリモートコード実行（RCE）が引き起こされる恐れがあります。 また、既に PoC（攻撃）コードが公開されていますので、Apache Struts 2 を利用されている方は 2.5.26 へアップデートを行うことをお勧めします。 Security Bulletins S2-061 https://cwiki.apache.org/confluence/display/WW/S2-061 yamory では、PoC コードの検証を行い悪用可能であることも確認しました。 脆弱性を悪用した攻撃の仕組み 検証環境今回は以下のような環境で検証を行いました。 ベースイメージ

MIT ライセンス （エムアイティーライセンス、MIT License）とは、オープンソースソフトウェアを開発・配布する際に用いられる代表的なオープンソースライセンスのひとつで、利用許諾のための条件などを定めているものです。 本記事では MIT ライセンスの概要から掲載例、各種ライセンスの比較について解説していきます。 MIT ライセンスの概要MIT ライセンスは、マサチューセッツ工科大学で作成された代表的な寛容型オープンソースライセンスのひとつです。 MIT ライセンスの規定はシンプルで、ソフトウェアを自由に扱ってよいこと、再頒布時に著作権表示とライセンス表示を含めること、作者や著作権者はいかなる責任も負わないことを定めています。 MIT ライセンスの大きな特徴は、MIT ライセンスを用いて公開されたプログラムを改変したり、自らのプログラムに組み込んだ派生的な著作物は、ソースコードを公開

HTTP リクエストスマグリング（Http Request Smuggling, HRS）は、フロントエンドの Web サーバー（リバースプロキシー、ロードバランサーなど）とバックエンドの Web サーバーで、 HTTP リクエストに対し異なる解釈をしてしまうことで発生する脆弱性です。 この脆弱性が悪用されると、攻撃者によって作成されたリクエストを別のユーザーのリクエストに追加し、フィッシング、クロスサイトスクリプティング（XSS）、キャッシュ汚染、セキュリティ制御のバイパスなどの影響を受ける可能性があります。 本記事では HTTP リクエストスマグリングについての概要から対策方法についての解説と、実際に公開されているライブラリの脆弱性について少し掘り下げて解説します。 HTTP リクエストスマグリングの概要 HTTP リクエストスマグリングが発生する仕組み HTTP リクエストスマグリン

オープンリダイレクト（Open Redirect）攻撃は、リダイレクト処理の実装不備を悪用し、被害者となるユーザを意図しない URL に誘導をする攻撃手法・脆弱性です。 意図しないリダイレクトを発生させるだけですと、大きな問題は起こせないと思われるかもしれませんが、正規ドメインから悪性ドメインへ意図しない誘導を行える場合、フィッシング詐欺などに悪用される可能性があります。 フィッシング詐欺に悪用された際のオープンリダイレクトは、危険度が高まります。​ 本記事では、オープンリダイレクトの原因と対策について触れたあと、対策方法や、開発者としてこのオープンリダイレクトを見つける方法についてご紹介します。 また、オープンリダイレクトを使った高度な攻撃手法（OAuth2 を狙ったオープンリダイレクト）の例について解説します。 オープンリダイレクトの概要 オープンリダイレクトは、「正規サービスのドメイ

ビジネススピードを確保しつつ、脆弱性のリスクを抑えるにすれば良いのでしょうか。本記事では、Clean Architecture を用いて脆弱性への対応力「レジリエンス」を高めるアプローチを解説します。

バッファオーバーフローとは、攻撃者によってメモリ上に確保したバッファを超えて書き込みが行われる問題（脆弱性）であり、この問題を利用した攻撃手法を指します。 別名としてバッファオーバーランとも呼ばれます。 バッファオーバーフローの脆弱性を軽減するには、攻撃者がどのようにして悪用するのか、またどのような危険性があるのか、理解することが重要です。 本記事では、バッファオーバーフロー攻撃についての概要と対策方法について、Web アプリケーション開発に携わっている視点から解説していきます。 バッファオーバーフロー攻撃はどのようにして発生するのかバッファとは、データが 1 つの場所から別の場所に転送する際に、データを一時的に保持するメモリストレージ領域のことをいいます。 プログラムがデータをバッファに書き込もうとした際に、データの量がメモリバッファのストレージ容量を超えてしまうと、隣接するメモリ位置を

パストラバーサル（Path Traversal、以下パストラバーサルで統一） は、本来アクセスできないディレクトリに存在するファイルに対して、脆弱性を悪用してアクセスする攻撃手法・脆弱性です。 この脆弱性はディレクトリトラバーサル（Directory Traversal）とも呼称されています。 本記事では、パストラバーサルの脆弱性についてを説明した後、対策方法と、発展的な「nginx で発生してしまうパストラバーサル」についても触れていきます。 パストラバーサルとは？説明のため、1 つのアプリケーション例を題材として話を進めていきます。 以下のような構成の Web サーバがあったとしましょう。 ユーザーはインターネットを通じて、公開ディレクトリとして指定されている public ディレクトリへアクセスが行えるものとします。 また secret のディレクトリに対しては、ユーザがアクセスでき

リバースブルートフォース攻撃（逆総当たり攻撃、リバースブルートフォースアタック）とは、不正ログインを目的とする攻撃手法で、パスワードなどを固定して、ID 部分を変えながら総当たり的にログイン認証を繰り返していく攻撃です。 「ブルートフォース攻撃（総当たり攻撃）」という攻撃も存在していますが、リバースブルートフォース攻撃はその逆に当たる手法（パスワード部分ではなく ID などの部分の変更）を用いた攻撃になります。 総当たり攻撃の対策として、パスワードを一定回数間違えた場合に、対象アカウントをロックする手法が一般的には知られています。そうすることで「一定回数までしか攻撃者はログインを試せないため安全」という前提が作れるためです。 しかしリバースブルートフォース攻撃では、パスワードではなくユーザー ID 側を変更しながら攻撃を行うため、特定アカウントへの大量の認証施行は行われず、アカウントロック

クリックジャッキング（クリックジャック攻撃）とは、被害者にクリックさせたいURLやサービスの機能を、他のサイトの表示で覆い隠すことにより、視覚的に騙してクリックを行わせる攻撃手法です。 この攻撃により、悪意のあるサイトを訪問したユーザーがページ上をクリックしてしまうと、他のサイト上にある個人情報の流出や、データの破壊などの不利益を被ってしまう恐れがあります。 この脆弱性が2002年に報告されて以来、TwitterやFacebookなどのSNSを含むさまざまなサービスでクリックジャッキングの悪用が報告されています。 また、パソコンだけではなく、スマートフォンを使っていてもクリックジャッキングに出くわす可能性はあります。 このような被害者のアクションをトリガーとして攻撃が実施される脆弱性は、受動的攻撃と呼ばれています。 本記事ではクリックジャッキングの概要から、攻撃の仕組み、対策方法について解

yamory は、2020 年 8 月 27 日をもちましてリリースから 1 周年を迎えました。 ここまでご愛顧いただいているのは、yamory をご利用いただいている企業さま・ユーザーさまをはじめ、yamory に関わってくださっている皆さまのご支援のおかげです。心より感謝申し上げます。 yamory は 2019 年 8 月 27 日に、「すべてのエンジニアにセキュアな開発を。」を掲げ、アプリケーション・ライブラリの脆弱性管理に特化したサービスとしてリリースしました。 1 年が経ち、より多くの方々にご利用いただきやすいサービスを目指して機能拡充を進めてまいりました。また、ご利用いただいております企業さまも増えてきております。 今回は yamory の 1 周年を記念して、この 1 年間の取り組みを時系列でご紹介させてください。 リリース1周年を記念して、ステッカーを配布します yamo

書き起こしメディア「ログミーTech」に、yamory 主催 DevSecOps 勉強会 #1 の登壇レポートを掲載いただきました。

2020 年も半ばを過ぎましたがみなさまいかがお過ごしでしょうか。 yamory は 2019 年 8 月 27 日にサービスをリリースし、まもなく 1 年が経とうとしています。 この 1 年を振り返ると、Go 言語のサポートやIPA のセキュリティ製品の有効性検証の試行において対象製品に選ばれたり、オートトリアージ機能の特許取得、イエラエセキュリティ様との業務提携など多くの取り組みを行なってきました。 最近では、Jira Cloud 連携やライブラリの依存関係のツリー形式での表示、シングルサインオン（SSO）連携機能もリリースしました。 機能拡充と並行し、私が所属するセキュリティチームでは、日々新たに発見されるさまざまな言語のフレームワークやライブラリの脆弱性の調査・分析に力を入れております。 今回は 2020 年脆弱性管理レポートと題して、yamory 利用者様からのアンケート結果を交