立場別

By role

一つの報告を、
三人がそれぞれの問いで読む。

セキュリティの話は、社内の誰に向けるかで中身が変わります。それでもAthenaraが残すものは一つです。再現できた問題、その手順と証拠、確かめた範囲とまだ確かめていない条件、修正後の再確認。同じ記録を、判断する人、守る人、直す人が、それぞれ自分に要る箇所から読みます。

そして三人のうち誰も、毎日これを動かす役は負いません。舵取りを担う人を、新たに置く必要はありません。

i. — Executive経営・役員

「いつから危なかったのか。その間、誰が確かめていたのか。」

読むところ確かめた範囲と、まだ確かめていない条件

年に一度の出来事から、
毎朝の確認事項へ。

経営の立場でセキュリティに向き合う機会は、多くの会社で年に一度に限られます。外部診断の予算を承認し、2週間後に報告書を受け取り、指摘への対応を確認します。そこから次の診断までの約50週、プロダクトが安全かどうかを示す新しい材料は届きません。

その間もプロダクトは変わり続け、顧客に使われ続けます。問題が起きたときに問われる上の二つに、年に一度の報告書だけでは答えられません。

経営の判断に関わる四つの変化

01リスクの見え方年に一度の報告書毎朝更新される記録診断の直後だけ安全が確かめられ、残りの期間は分からない、という状態がなくなります。確かめた範囲と結果は、日ごとに積み上がっていきます。
02コードの行き先社外の診断会社やAIサービス社内の1台から出ない推論に使うAIモデルも含めて社内で完結します。コードも、検証結果も、見つかった問題も、外部には送りません。
03人の手当て専門人材の採用今いる担当者が結果を読む何を調べるかを指示する専門家も、夜間・休日の当番も要りません。人が関わるのは最初の設置と設定、朝に結果を読むこと、重点を変えたいときにチャットで伝えることだけです。
04設備データセンターや専用ラック机に載る1台NVIDIA DGX Spark 1台で動きます。外部の計算資源を借りる契約も、専用の設備工事も前提にしていません。

説明できる状態をつくる

残るのは、再現できた問題の一覧だけではありません。どの範囲を確かめて何も起きなかったのか、どの条件はまだ確かめていないのか、修正のあと直ったのかが、証拠つきで上書きされずに残っていきます。

取締役会や顧客、監督する立場の相手から問われたとき、手元にあるのは「年に一度、診断を受けています」という一文ではなく、日々の確認の記録です。すべての問題を見つけると約束するものではありません。ただ、何を確かめ、何がまだかを、その日の時点で答えられます。

最初の一つの選び方データは社外に出ない

ii. — Securityセキュリティ担当

「溜まった警告のうち、本当に危ないのはどれか。」

読むところ再現できた問題と、その証拠

読むべきものは、
警告の山ではなく、
再現できた問題だけ。

セキュリティ担当の一日は、確かめきれない指摘に削られていきます。静的解析の警告、外部からの通知、報告書の指摘事項。どれが本当に危ないのかは、一件ずつ開いて裏を取るまで分かりません。人手が足りなければ、未確認のまま溜まっていく一方です。

Athenaraは、この裏取りを引き受けます。隔離した使い捨ての環境でプロダクトを起動し、実際に問題が起きるかを試します。担当者に届くのは、再現できた問題だけ。推測だけの警告は出しません。届いた問題には、同じことをもう一度起こす手順と、そのとき観測した証拠が必ず付きます。

手放せること、残ること

Handed over

警告を一件ずつ開き、本当に危ないかを裏取りする作業
次に何を調べるかを、毎日決めて指示すること
夜間や休日に、調査が止まっていないかを見張ること

Still yours

朝、再現できた問題と、確かめた範囲を読む
重点を置きたい方向を、チャットで一言伝える
届いた問題を開発に渡し、修正を見届ける

調べた結果が、次の調査の土台になる

外部診断の報告書は、次の診断が来れば読み返されなくなります。Athenaraの結果は、証拠つきの知識として社内に残り続け、次に何を確かめるかを決める材料になります。すでに確かめた範囲を何度も調べ直すことはなく、コードが変わって判断が古くなれば、改めて確かめ直します。

時間が経つほど、そのプロダクトに詳しい担当者が一人、社内に育っていくのと同じ状態になります。異動や退職で人が入れ替わっても、記録は残ります。

方針は、ふだんの言葉で

「ログイン周りを重点的に見てほしい」
「決済まわりを重点的に見てほしい」
「このプロジェクトは一旦休止」

担当者とAthenaraの接点は、チャット一つ。専門用語で調査計画を書く必要はありません。重点を置きたい機能や、しばらく止めたいプロジェクトをふだんの言葉で伝えれば、次に確かめる問いがそちらへ寄っていきます。

伝えなければ、Athenaraはこれまでの結果とコードの変更を見て、自分で次を決め続けます。方針を出すのは、出したいときだけで構いません。

報告の中身と読み方実際に動かして確かめる仕組み

iii. — Engineering開発責任者

「どこを、どう直せばよいのか。直ったと言えるのか。」

読むところ再現手順と、修正後の再確認

開発の流れは止めずに、
毎週の変更を確かめ続ける。

開発責任者にとって、セキュリティ対応の負担は二つあります。一つは、診断やレビューのたびに開発の手が止まること。もう一つは、届いた指摘が曖昧で、本当に直すべきものなのか、どう再現すればよいのかを開発者が自分で調べ直さなければならないことです。

Athenaraは、開発の流れの外側で動きます。届く報告には、開発者がそのまま手を動かせる再現手順が付いています。

開発と並んで回る一巡

1Change開発いつも通り変更を出す機能の追加も修正も、これまでの流れのまま。
2PullAthenara差分を取り込む変更が溜まれば読み取り専用で取り込み、判断を見直します。
3TryAthenara隔離環境で試す使い捨ての環境でプロダクトを起動し、問題が起きるかを見ます。
4ReportAthenara手順つきで報告する再現できたものだけを、手順と証拠を添えて残します。
5Fix開発報告を見て直す手順どおりに起こしてみれば、原因を追えます。
6RetestAthenara同じ条件で試し直す直ったかどうかを確かめ、結果を記録に残します。

触れないもの

本番環境接続しない検証は隔離したコンテナの中で、その場で起動したプロダクトに対してだけ行います。
対象のコード書き換えない読み取り専用で参照します。修正のコミットやプルリクエストを勝手に作ることはありません。
リポジトリの権限読み取りのみGitHubと連携する場合も、読み取り専用の権限で取得します。社内で直接置くこともできます。
開発の手順変えないレビューやリリースの流れに、新しい承認や待ち時間を差し込みません。

開発者に渡せる報告と、修正後の試し直し

「この辺りが危ないかもしれない」という指摘は、開発者にとって調査の宿題を一つ増やすだけです。Athenaraの報告は、実際に起きたことの記録から始まります。手順どおりに操作すれば、開発者の手元でも同じ問題を起こせます。確かめて問題が起きなかった範囲と、まだ確かめていない条件も分けて書かれているため、修正の影響範囲を見積もるときに、どこまでが確認済みかを判断の材料にできます。

修正が入れば、その変更を取り込み、報告と同じ条件で試し直します。直っていればそう記録し、まだ起きるならそのまま示します。確認のために開発者が手順を組み直したり、再診断を依頼したりする必要はありません。いつ見つかり、いつ直り、いつ確かめ直したかが、プロダクトの記録として積み上がっていきます。

直したあと、同じ条件での試し直し安全設計

運用