自社開発の落とし穴

「自社でサービスを開発しているから、システムは完全に我々の管理下にある。外部のSaaSを使うより安全だ」

こう考えている経営者は少なくない。確かに自社開発には多くのメリットがある。顧客のニーズに合わせた柔軟なカスタマイズ、競合他社との差別化、そして何より自社のノウハウが蓄積されていく喜びがある。

しかし、2025年9月に発生した Jaguar Land Rover Automotive PLC （以下、JLR）の大規模サイバー攻撃は、我々に重要な教訓を与えた。全世界の工場が数週間にわたって停止し、数千億円単位の損失を被ったこの事件の根本原因は、なんと2021年に漏えいしたプロジェクト管理ツール「Jira」の認証情報であった。つまり、4年前に自社開発環境に関する認証情報という小さな穴が、最終的に会社全体を麻痺させる大惨事となったのである。自社開発の現場では、こうした「時限爆弾」が今この瞬間も静かに時を刻んでいる可能性がある。

^{※本記事はサイバーセキュリティに関する啓発や考察を目的としています。特定の企業・団体を批判する意図は一切ありません。}

改めて JLR の被害を追いかけていく。2025年9月、英国の高級車メーカー、JLR は史上最悪レベルのサイバー攻撃を受けた。全世界の工場が数週間にわたって操業停止に追い込まれ、週5,000万ドル（約75億円）という莫大な損失を被った。この攻撃により、同社の株価は急落し、数千人の従業員が自宅待機を余儀なくされた。この大惨事の根本原因を知ったとき、多くの専門家が愕然としただろう。なんと、攻撃者が使用したのは2021年に漏えいしたプロジェクト管理ツール「Jira」の認証情報だったのである。

2021年、JLR の外部委託業者のPCにInfoStealerが感染。Jira の認証情報を漏えいさせた。この時点では大きな被害は発生しなかったため、適切な対応が取られることはなかったと思われる。しかし、この認証情報は闇市場で静かに取引され、攻撃者グループ「HELLCAT（RAY）」の手に渡った。2025年3月、HELLCAT グループは最初の攻撃を実施。なんと手に入れた古い認証情報が4年経っても有効で、これを使って JLR のシステムに侵入し、約350GBの機密データを窃取した。この時点でも、JLR は事態の深刻さを完全に理解していなかったのだろう。そして2025年9月、これまた同じ認証情報を使った大規模な攻撃が実行された。今度は単なるデータ窃取ではなく、製造ラインの制御システムまで侵害され、全世界の工場が停止に追い込まれたのである。JLR の操業停止は、同社だけの問題では終わらなかった。部品供給業者、販売店、物流業者など、数千社に及ぶサプライチェーン全体に深刻な影響を与えた。特に中小の部品メーカーの中には、JLR からの発注が止まったことで経営危機に陥る企業も続出した。一連の騒動で、JLR は数千億円単位の緊急借り入れを余儀なくされ、事態を重く見た英国政府は融資保証を付けるに至ったのである。

多くの中小企業が陥っている誤解がある。それは「我々は大企業ではないから、サイバー攻撃者に狙われることはない」という考えである。この認識が根本的に間違っているということはこれまでの連載で明らかにしてきた。現代のサイバー攻撃者にとって、中小企業はむしろ格好のターゲットなのである。その理由の一つに、中小企業の多くが開発環境のセキュリティ対策を軽視していることが挙げられる。大企業であれば専任のセキュリティチームがあり、厳格なアクセス制御や監視体制が開発環境に対しても整備されているだろう。しかし中小企業では「うちの開発メンバーはITのプロなんだから大丈夫だろう」とか「予算がないから」という理由で、開発環境に対しては基本的なセキュリティ対策すら講じられていないケースがまだまだ多い。

開発環境は企業のいわば「心臓部」である。ここには顧客データへのアクセス権限、本番環境への接続情報、そして何より企業の競争力の源泉であるソースコードが存在する。この心臓部を適切に守らずして、どうして企業を守ることができるだろうか。

近年、サイバー攻撃の手法は大きく変化している。従来のように企業のネットワークに直接侵入するのではなく、ソフトウェアの開発・流通プロセスを狙う「ソフトウェアサプライチェーン攻撃」が急増しているのである。この攻撃の恐ろしさは、正規のソフトウェア開発プロセスを悪用することで、企業が「自ら」悪意あるコードを取り込んでしまう点にある。

例えば、昨今世間を騒がせているオープンソースライブラリへの悪意あるコード注入である。現代のソフトウェア開発では、オープンソースライブラリの活用が不可欠であるため、攻撃者は人気の高いライブラリに悪意あるコードを混入させ、それを利用する企業のシステムを一網打尽にする。2021年、Java のログ出力ライブラリである Apache Log4j に見つかった脆弱性騒動は記憶に新しいが、これは氷山の一角に過ぎないのである。

「LOFY GANG」と名乗る攻撃グループは、執拗に著名パッケージへの攻撃を行っており、金銭と引き換えに開発者に不正なコードを注入させる例も確認されている。買収以外の具体的な攻撃手法としては、CI^※1/CD^※2パイプラインの侵害が挙げられる。パイプラインが侵害されると、悪意あるコードが自動的に本番環境に展開されてしまうのだ。これには開発者アカウントの乗っ取りが必要で、正規の権限を使ってソースコードの改ざんやバックドアの埋め込みが行われる。だからこそ、特に管理者権限を持つ開発者のアカウントが狙われやすい。企業は自社の開発者や利用しているライブラリを信頼しているからこそ、そこから送られてくるコードを疑わずに使用する。攻撃者はこの人間の心理を巧妙に突いてくるのである。

^{※1 CI：Continuous Integration（継続的インテグレーション）
※2 CD：Continuous Delivery（継続的デリバリー）}

デジタル資産の中でも、ソースコードなどの開発環境にあるものは現代企業にとって最も重要な資産の一つである。顧客データや財務情報と同じく、厳格に管理されるべき対象なのである。しかし、多くの企業では「開発者が使いやすいように」という理由で、セキュリティが軽視されている。

GitHub や GitLab などのソースコード管理ツールは、適切に設定されれば強力なセキュリティ機能を提供するが、デフォルト設定のまま使用していては、重要なコードが外部に漏えいする危険性がある。プライベートリポジトリの設定、アクセス権限の最小化、そして監査ログの有効化は最低限必要である。

また、開発者のアカウントには必ずMFA（多要素認証）を設定すべきである。パスワードだけでは、フィッシング攻撃やパスワードリスト攻撃に対して無力である。「面倒だから」「開発効率が下がるから」という理由でMFAを導入していない企業は、まさに玄関の鍵を開けっ放しにしているようなものである。これは2025年上旬から断続的に発生しているInfoStealer型の攻撃を見れば明らかだ。

あわせて認証情報のライフサイクルにも気を遣うべきである。開発者が退職した際のアカウント削除、定期的なパスワード変更、そして使用されていないアカウントの定期的な監査が必要である。JLR の事例では、まさにこの部分の不備が致命的な結果を招いた。本当に4年間も認証情報が更新されていなかったのだとすれば、かなり驚くべき管理体制なのである。

JLR の例で印象的なのは認証情報の漏えい元が外部業者だったことだろう。同社のセキュリティ水準も中々のものだったわけだが、委託先の管理体制も同様である。これに対応するには、第三者アクセスの定期監査、つまり外部業者に付与しているアクセス権限を定期的に見直し、不要なものは削除するなどの対応が欠かせない。契約関係が終了しているにも関わらず、システムアクセス権限が残っているケースは意外に多いのである。また、新たに外部業者を選定する際は、その会社のセキュリティ体制も評価対象に含める。価格だけで判断すると、後に大きなリスクを抱え込む可能性がある。

こうした課題に対して、NIST（National Institute of Standards and Technology：米国国立標準技術研究所）は2022年に「NIST Special Publication 800-218（SP 800-218）」の「Secure Software Development Framework（SSDF）」を策定した。これはソフトウェア開発におけるセキュリティのベストプラクティスを体系化したフレームワークで、以下4つの重要な柱から構成されている。少々小難しい内容にはなるが、ざっと説明することとする。

セキュアな開発を支える組織体制の確立。これには開発者に対するセキュリティ教育、セキュアコーディングの標準化、そして開発環境のセキュリティ要件の定義が含まれる。多くの中小企業では「個人任せ」や「可読性ルールのみ」になっているが、これは非常に危険な状態である。

開発プロセス自体を攻撃から守るための仕組みづくり。ソースコードの暗号化、アクセス制御の実装、そして最も重要な認証情報の管理がここに含まれる。JLR の事例が示すように、認証情報の管理不備は長期間にわたって企業を脅威にさらし続ける。

実際の開発段階において、セキュリティを考慮した設計・実装・テスト。脆弱性のあるライブラリの使用を避け、セキュリティテストを自動化し、コードレビューを徹底することが求められる。

発見された脆弱性に対して、迅速かつ適切に対応する体制の構築。インシデント対応計画の策定、パッチ管理プロセスの確立、そして顧客への適切な情報提供が含まれる。

^{参考：NIST「Secure Software Development Framework (SSDF) 」}

SP 800-218 は「完璧なセキュリティ」を求めているのではない。リスクに応じた適切な対策を、継続的に改善していくプロセスを重視しており、中小企業でも段階的に導入できるよう設計されている。

中小企業であれば、開発チームに対して本連載の内容などを共有し、今現在どのようなサイバー攻撃手法が存在しているのか、そのような攻撃に晒されないようなセキュアな設計思想やコーディングルールなどを共有する勉強会などを開催することで「Prepare（準備）」を、合わせて開発環境のセキュリティ整備をすることで「Protect（保護）」を、脆弱性が含まれるライブラリが含まれていないか、コーディングルールに反する危険な構文が含まれていないかなどをレビューするプロセスを入れることで「Produce（製造）」を、CSIRT^※1/PSIRT^※2の整備と脆弱性の追跡性を担保することで「Respond（対応）」に対応することができるだろう。まずはこの極めて基本的なステップを整備することから始めることを推奨する。

^{※1 CSIRT：Corporate-Security Incident Response Team（コンピューターセキュリティに関するインシデント対応組織）
※2 PSIRT：Product-Security Incident Response Team（プロダクトの脆弱性に関するインシデント対応組織）}