04 — By sector
No. 04
業界別
By sector
同じ一台でも、
効くところは業界ごとに違います。
コードを社外に出せないことが一番の壁になる会社もあれば、変更の速さに確認が追いつかないことが一番の悩みという会社もあります。
以下の事情は、業界でよく見られるものを一般化したものです。個別の規程や契約への適合を示すものではありません。Athenaraは、定められた診断や社内の審査を置き換えるものでも、すべての問題を見つけると約束するものでもなく、手続きと手続きのあいだに入った変更を、日常の確認として拾い続けるためのものです。
四つの事情と、応える性質
- 01コードを外に出せないKept inside社内の1台で完結する構成
- 02規程や契約が先に立つRules安全設計
- 03変更が止まらないChange設置した日から続く調査
- 04専門の人手が足りないFew hands実際に動かして確かめる仕組み
i. — Finance金融
Kept inside
外に出せない
顧客の資産や取引を扱うコードは、それ自体が持ち出しを制限される情報になりがちです。社内規程や取引先との契約が、外部の診断会社やクラウド型のAIサービスへ渡すこと自体を難しくしています。
Never still
止められない
一方で、サービスの改修は止まりません。新しい商品、画面の改善、外部サービスとの連携。変更のたびに、確かめるべき箇所は増えていきます。
金融のシステムは、この二つを同時に抱えることが少なくありません。年に一度の診断で見られるのは、その時点のコードだけ。そのあいだの改修は、確かめられないまま積み上がっていきます。
必要なのは、コードを社外に出さないまま、改修と同じ速さで確かめ続ける手段です。Athenaraは、外に出さないことと、止めないことを両立させるために、社内の1台に置いて使います。
社内で説明するときの材料
安全性について社内の関係者に説明するとき、問われるのは「大丈夫か」の一言よりも、何をどこまで確かめたかです。Athenaraの報告には、再現できた問題の手順と証拠が必ず付き、確認できた範囲とまだ確かめていない条件が分けて残ります。
推測だけの警告は出さないため、開発側に渡す指摘は、手元でもう一度確かめられるものに限られます。修正が入れば同じ条件で試し直し、直ったかどうかを記録します。
ii. — Medical医療
見せて確かめることが、
いちばん難しい情報。
医療のシステムは、患者の情報に触れます。電子カルテ、予約、検査結果、会計。こうしたシステムではソースコードそのものにも慎重な取り扱いが求められやすく、外部の診断会社やクラウド型のAIサービスに渡して確かめることは、規程や契約の上で難しい場合がほとんどです。
一方で、システムを見る人手は限られています。医療機関の情報部門でも、医療向けのシステムを作る会社でも、セキュリティの専門家を常に置ける所は多くありません。確認は年に一度の診断と、日々の目視に頼りがちです。
ある一日
Evening
改修が入る
予約画面の改善、検査結果の表示の変更、他のシステムとの連携の追加。小さな変更でも、患者の情報に届く経路が変わることがあります。
Night
社内の1台が確かめる
Athenaraは更新された差分を取り込み、影響がありそうな箇所から問いを立てて試します。
Morning
担当者が結果を読む
昨夜のうちに確かめた範囲と、再現できた問題が残っています。問題には再現手順と証拠が付き、そのまま開発側に渡せます。
試すのは、本番に接続しない隔離した環境の中だけ。報告するのは推測ではなく再現できたものだけなので、少ない人手で大量の警告を読み分ける必要はありません。
iii. — Public sector官公庁・公共
官公庁や自治体、公共性の高いサービスのシステムでは、住民や利用者の情報を扱うため、ソースコードを外部の事業者やクラウド型のAIサービスに預けるには、規程や契約の上で慎重な判断が求められます。つながってよい外部の先も限られています。
その一方で、システムは長く使われ、担当は数年ごとに入れ替わります。確認は年度ごとの診断に頼り、その間の改修は次の診断まで確かめられないまま運用されます。前の担当が何を確かめていたかは、報告書の束の中に埋もれていきます。
四つの条件への応え方
- Local外に頼らない
- 推論に使うAIモデルを含め、すべてが社内の1台で動きます。外部のAIサービスには接続しません。対象のリポジトリは読み取り専用の連携で取り込むほか、手作業で置くこともできます。
- Resident予算の周期を待たない
- 設置した日から動き続け、コードが更新されれば差分を取り込んで確かめ直します。確認の機会が、年度ごとの診断の予定に縛られることはありません。
- Verified運用中のシステムを止めない
- 本番環境には接続せず、隔離した使い捨ての環境でその場で起動したプロダクトに対して試します。利用者が使っているシステムには触れません。
- Knowledge引き継ぎで消えない
- 見つかった問題、根拠、確かめた範囲とまだ確かめていない条件が、証拠つきで1台の中に残ります。担当が替わっても、何を確かめてきたかを最初から聞き直す必要はありません。
iv. — Product companies自社プロダクトを持つ企業
次の診断まで待つ
出した週のうちに、確かめる。
自社でプロダクトを持つ会社、とくにSaaSのように継続して機能を出し続ける会社では、コードは毎週、ときには毎日変わります。新しい画面、新しい料金プラン、外部サービスとの連携。変更のたびに、昨日まで安全だった箇所が安全でなくなる可能性が生まれます。
そうした会社ほど、セキュリティの専門家は多くありません。開発チームは機能を作ることに手一杯で、静的解析の警告を一件ずつ読み分ける余裕もありません。年に一度の診断は、出した機能の大半が通り過ぎたあとにやってきます。
Athenaraは、社内に一人、そのプロダクトだけを見続ける担当者を置くのと同じ状態をつくります。
出荷の速さに合わせる四つの性質
- Resident出荷の翌晩には、確かめ始めている
- 新しく入った箇所と、これまでに確かめた範囲を踏まえて、次に確かめる問いを自分で決めます。出荷のたびに診断を発注し直す必要はありません。
- Verified警告ではなく、再現できた問題が届く
- 開発チームに届くのは、再現手順と証拠の付いた問題だけ。裏取りに開発の時間を取られることはありません。
- Knowledge直したかどうかまで、記録に残る
- 修正が入れば同じ条件で試し直し、直ったかを記録します。機能が増えるほど、どこを確かめてきたかの記録も厚くなっていきます。
- Local自社の強みであるコードを、外に出さない
- プロダクトのコードは、自社の競争力そのもの。外部のAIサービスにコードを送らずに済みます。
今ある開発の流れに、足すだけ
すでにコミットごとに静的解析を回しているなら、それはそのまま続けてください。依存ライブラリの既知の脆弱性や設定の不備は、機械的に拾えます。Athenaraはその結果も踏まえて、実際に影響があるかを確かめる役を担います。
重点を置きたい機能があれば、チャットで「今週出した決済まわりを重点的に」と伝えるだけで、調査の順番が変わります。最初は、出荷の頻度が高いプロダクト一つから始められます。