AppliParkでは脆弱性にどう対応している?日々の確認と開発時の工夫
PHPの脆弱性をきっかけに、AppliParkの対応を紹介します。毎朝の情報収集、依存部品の点検、サーバー側の確認、更新とテストをどう組み合わせているのかをまとめました。
CONTENTSこの記事の目次7項目
PHPの脆弱性、証明書に関する問題、圧縮に使われる部品の不具合。最近、セキュリティに関するニュースを目にする機会が増えました。AppliParkを運営する立場としても、「自分のサービスには関係があるのか」を、その都度確かめる必要があります。 今回は、AppliParkでどのように情報を集め、開発時に何を確認しているのかをご紹介します。小さなサービスでも、公開して終わりにはできません。
今回のPHPの問題は、更新対象に該当しませんでした
2026年10月に話題となったPHP2shellについて、AppliParkのWebアプリ構成ではPHPを採用していないため、PHP本体を更新する対応はありませんでした。画面側にはNext.js・React、サーバー側にはKotlin・Spring Bootなどを使っています。 ただし、PHPを使っていないから脆弱性全般と無関係、ということではありません。どんな技術でも、新しい弱点が見つかる可能性があります。自分たちが使う部品に置き換えて、確認を続けることが大切だと考えています。
毎朝の情報収集を、公式情報の確認につなげる
私は個人でCodexを契約していて、dotsに「その日に発表された脆弱性を教えて」と毎朝知らせてもらう定期タスクをお願いしています。ニュースを自分で追うだけでは気づきにくい情報に目を向けるための、入口の一つです。 ただ、その報告だけで対象かどうかを決めるわけではありません。発表時刻や情報の取り込みにはずれがあり、見落としや誤りもあり得ます。気になる情報は、開発元の告知やIPAなどの一次情報へ戻り、対象バージョンや影響する条件を確認するようにしています。
開発に使っている部品については、Dependabotによる週次の更新確認も設定しています。関連する部品の更新をまとめて確認できるようにし、変更内容や互換性を見ながら取り込むための仕組みです。毎朝のニュース収集と、実際に使う部品の更新確認を組み合わせています。
アプリのコードだけでなく、使っている部品も調べる
Webアプリは、自分で書いたコードだけでは動きません。画面を作る部品、その部品がさらに使う別の部品、プログラムの実行環境、OSのパッケージなどが組み合わさっています。自分で直接追加したものだけを見ていると、確認が抜けてしまいます。 2026年10月29日の開発上の点検では、依存関係と実行環境を確認し、更新とテストを行いました。このときは、圧縮データの処理に使われるBrotliも更新対象に含めています。「圧縮方式そのものが全部危険になった」という話ではなく、その処理を行うライブラリの特定の実装・バージョンに問題がある、という見方が必要です。
この点検では、npm audit、OSV、Trivyといったツールも使い、アプリの依存部品や実行用イメージを調べました。これらは今回の点検で使った手段で、常に全項目を自動監視できているという意味ではありません。検出結果は使用状況と合わせて確認し、検出されなかったことだけで安全だとは判断しません。
開発時は「画面に出さない」だけで済ませない
- 入力はサーバー側でも確認する:必須項目や入力値の条件を、画面のチェックだけに任せないようにしています。
- 操作する権限を確認する:たとえば日記の更新・削除では、記録の番号だけでなく、利用者との紐づきもサーバー側で確認しています。
- 変更後の動作をテストする:更新時にはフロントエンド・バックエンドのテストやビルドを行い、普段の機能が壊れていないかを確認しています。
画面に他人の記録へのボタンがなければ十分、とは考えていません。画面を経由しない要求が届いても、サーバー側で操作できる範囲を確かめる必要があるからです。 また、修正版を入れた結果、別の機能が動かなくなることも避けたいところです。更新内容と互換性を確認してテストし、公開環境への反映と、その後の動作確認を別の工程として扱います。コードを直した時点で、本番も直ったと取り違えないことを大切にしています。
証明書の問題は、別の観点で確認する
証明書は、HTTPS通信で接続相手を確かめる仕組みに関わります。2026年10月には、eMudhraの中間認証局の秘密鍵が侵害されたことを受けて、Mozillaなどが対策を公表しました。これは、アプリの入力処理の不具合とは原因も対処の範囲も異なる問題です。 AppliParkはHTTPSを使っていますが、それだけでアプリの脆弱性を防げるわけではありません。証明書の問題では、サイト側の証明書だけでなく、通信する側が何を信頼するかという観点も必要になります。使っている言語の名前だけで判断せず、問題が起きた仕組みに合わせて確認する範囲を考える必要があります。
「一度直して終わり」にしないために
新しい問題に気づく、使っているものと照合する、必要な更新を行う、動作を確かめる。この積み重ねが、AppliParkの脆弱性対応の基本です。AIによる情報収集や自動チェックも活用しつつ、最後は公式情報と実際の構成を確認して判断します。 今回紹介した点検は、2026年10月29日時点の開発記録に基づくものです。本番環境に未知の問題も含めて一切の脆弱性がないことを証明するものではありません。できることを一つずつ続けながら、利用していただくサービスを育てていきます。
確認した情報
確認日:2026年10月29日。AppliParkの構成・依存関係の更新設定・自動テストの設定・入力と権限の確認処理・同日の依存関係点検記録を照合しました。
出典・参考資料PHPの脆弱性対策について(PHP2shell)IPA/2026年10月27日更新。対象となるソフトウェアと影響の確認に参照。ipa.go.jp出典・参考資料安全なウェブサイト運営にむけて(PDF)IPA/2021年3月。構成の把握と継続的な脆弱性対応の参考資料。ipa.go.jp併せて参照:PHP公式「PHP: News Archive - 2026」(10月26日のBrotliに関する告知)、Mozilla Security Blog「Protecting Firefox Users Following the Compromise of eMudhra Intermediate Certificates」(2026年10月20日)。