01 — Five gaps
No. 01
課題
Five gaps
危ないのは、脆弱性があることより、
あるかどうかを誰も確かめていない
時間が長いこと。
多くの会社のセキュリティ対策は、三つの習慣の上に立っています。年に一度の外部診断。確かめるときは、コードを外部の専門家やサービスに見せること。日々の確認は、静的解析ツールの警告任せ。
どれも間違いではありません。ただ、プロダクトが毎週変わり、コードの取り扱いに厳しい条件がつき、社内にセキュリティの専門人材がいない会社では、三つの習慣がそれぞれ穴を残したまま回っています。その穴は目に見えません。報告書は手元にあり、ツールも導入済みで、対策をしているという感覚だけは残るからです。
経営の側から見れば、問われるのは技術の細部ではありません。何かが起きたとき、「いつから危なかったのか」「その間、誰が確かめていたのか」に答えられるかどうか。
i.年1回の外部診断
1年のうち50週は、
事実上ノーチェックのまま。
セキュリティ診断は、年に一度という会社が大半です。外部の診断会社に依頼し、費用は数百万円、期間は2週間。手元に残るのは、報告書1冊。
この報告書が保証しているのは、診断した2週間の、その時点のコードについてだけです。診断の翌週に新しい機能が入れば、その機能は報告書のどこにも載っていません。次に確かめられるのは、1年後の診断を待ってから。
ii.社外に出せないコード
AIに見せたいが、
社外に出せない。
コードの安全性を確かめる手段は、これまでほとんどが社外にありました。外部の診断会社に依頼すれば、ソースコードは診断会社の手に渡ります。クラウド型のAIコードレビューなら、そのサービスへ送ることになります。どちらも、コードを社外に出すことが前提です。
一般的な業種なら、それは契約を一本結べば済む話かもしれません。しかし顧客の資産、患者の情報、行政の手続きを扱うシステムでは、ソースコードそのものが持ち出しを制限される情報です。社内規程や顧客との契約が、外部への提供自体を難しくしています。
その結果、AIで確かめたいという意思はあっても、渡してよい先が見つかりません。検討はこの一文で止まり、確認は年に一度の診断か、社内の目視に戻っていきます。そうして止まっている会社は、少なくありません。
iii.精査しきれない警告
警告は、出るだけでは
何も守らない。
静的解析ツールを入れると、警告は大量に出ます。ところが、そのうち本当に危ないものがどれなのかは、一覧を眺めても分かりません。コードの書き方として怪しいだけのものと、実際に攻撃に使えるものが、同じ体裁で並んでいるからです。
一件ずつ見分けるには、コードを読み、動かし、影響を確かめる人手が要ります。その人手が足りません。警告は精査されないまま溜まり、やがて誰も開かなくなります。
溜まった警告が奪うもの
放置された警告は、無害に見えて二つのものを奪います。一つは担当者の時間。推測だけの警告を一件ずつ確かめる作業は終わりが見えず、本来の開発を圧迫します。もう一つは警告そのものへの信頼。外れが続けば、本物が混ざっていても読まれなくなります。
ツールは導入済みで、警告も出ています。それでも、危ない一件が見つかるかどうかは、たまたま誰かが目を留めるかどうか次第です。
iv.毎週変わるプロダクト
プロダクトは診断の翌週も変わります。変更の一つひとつは小さくても、報告書に載っていないコードは週ごとに積み上がり、開発が速い会社ほど、その未確認の差分は厚くなります。年に一度の診断は、この差分を一年分まとめて受け止める形です。しかし診断を待つあいだも、差分はすでに顧客の手元で動いています。
一週間のうちに変わるもの
- 01新しい機能Feature新しい画面や入力が増えれば、外から触れられる入口も増えます。
- 02既存画面の手直しRevision表示や処理の順序を変えただけで、確認の抜け道が生まれることがあります。
- 03外部サービスとの連携Integration決済や認証を外部とつなぐたび、データの通り道がまた一本。
- 04依存ライブラリの更新Dependency自社で書いていないコードも、プロダクトの一部として一緒に変わります。
- 05権限と設定の変更Permission誰が何を見られるか。その線引きが、一行の変更で動きます。
速さの食い違い
確認が追いつかないなら、変更を減らせばよいという考え方もあります。けれども出荷の速さは、プロダクトを持つ会社にとって競争力そのもの。安全のために開発を止める判断は、経営として取りにくいものです。
かといって、診断の回数を増やすのも現実的ではありません。一回ごとに費用と期間がかかり、年に数回に増やしても、週単位の変更には届きません。
残る道は一つだけ。確認のほうが、開発のリズムについていくことです。
v.専門人材の不在
警告を読める人が、
社内にいない。
ツールは買えば入ります。難しいのは、その結果を読み解く人のほう。攻撃者の目でコードを読み、怪しい箇所を実際に動かして確かめられる人材は、どの会社でも取り合いです。採用できたとしても、一人に頼る体制は、その人が休めば止まり、辞めれば知識ごと失われます。
専門人材を置けない会社では、確認の仕事は開発者の片手間か、年に一度の外部診断に回されます。
専門人材に任せていた仕事の行き先
担当者に求めること
Athenaraの担当者に、セキュリティの専門知識は求めません。
- a.朝、結果を読む昨夜確かめた範囲と、再現できた問題に目を通します。
- b.一言で方針を伝える「決済まわりを重点的に」「この案件は一旦休止」とチャットで書くだけです。
- c.報告を開発者に渡す再現手順付きなので、そのまま修正の依頼になります。
調べた結果は、問題も観測も確認した範囲も、証拠つきで記録として残ります。時間が経つほど、そのプロダクトに詳しい担当者が社内に育つのと同じ状態になっていきます。担当者が替わっても、記録はそのまま残ります。