SEC提出書類におけるサイバーセキュリティのトレンド

SECの10-K提出書類を分析すると、CISOがCIOの管轄下でサイバーセキュリティを担う一方、企業はNISTフレームワークに依拠してAIおよびサプライチェーンリスクの拡大に対処していることが明らかになった。

2023年、証券取引委員会(SEC)は上場企業に対し、10-K年次報告書にサイバーセキュリティに関する新たなセクションを設けることを義務付けた。このセクションは「サイバーセキュリティのリスク管理、戦略、ガバナンス、およびインシデント」を開示するものである。私はこれらの報告書においてサイバーセキュリティの上級幹部が自社について何を伝えているのかに興味を持ち、いくつかのAI技術を試す機会も兼ねてリサーチプロジェクトとして取り組むことにした。

本稿はS&P上位200社におけるSection 1.Cに関する調査結果と、使用したAI技術を含む分析手法の2部構成となっている。

10-K Section 1.C

Section 1.Cについては、ハーバード・ロースクールの研究PwCの調査国際会計情報システムジャーナルの論文など、すでに優れた分析が行われている。いずれも参考になる内容だったが、どれも初回提出分を対象として1年以上前に実施されたものだ。またハーバード・ロースクールの研究は上位100社のみを対象としていた。私は今年度の提出書類を使って同様の分析を再現できるか、また2024年と2025年の間に大きな変化があるかといった独自の問いにも答えてみたいと考えた。

企業はサイバーセキュリティリスクに関するガバナンスを開示することが求められている。主な要件として、取締役会によるサイバーリスクの監督体制、担当委員会、および重大なサイバーセキュリティ上の脅威を評価・管理する経営陣の役割について説明することが含まれる。経験年数が記載される場合も多い。

ハーバードの研究と同様に、上級サイバーセキュリティ担当者の役職と経験年数、報告先、取締役会内でサイバーセキュリティを監督する委員会、および活用している標準規格を確認する。すべての企業がこれらの情報をすべて記載しているわけではないが、大半は記載していた。また、2024年と2025年の全体的なトレンドについても分析する。

サイバーセキュリティのトップはCISO

最高情報セキュリティ責任者(CISO)は引き続きサイバーセキュリティの主要な責任者であり、70%以上の企業がサイバーセキュリティの責任者としてCISOを挙げている。CISOの数は2024年から2025年にかけてわずかに増加し、137社から142社となった。2位と3位はCIOとCSOがそれぞれ遠く離れた形で続く。同役職の平均経験年数は約23年(標準偏差6年、140社が報告)である。

多様な報告体制の中でCIOがトップを維持

最高情報責任者(CIO)はサイバーセキュリティ担当幹部の報告先として引き続き首位を占めており、2024年から2025年にかけて安定している(約49社対約48社)。これはCIOが最も多い報告先であるという各種調査や報道と一致している。サイバーセキュリティ担当者をCIOの管轄下に置くことは最善の形ではなく、利益相反を生む上に、企業レベルでのサイバーセキュリティの重要性を低下させるという別のCSO記事の見解に私も同意する。機能しないとは言えないが、より優れた体制が存在する可能性は高い。2024年・2025年のデータいずれにも明確な代替案は見られず(下記グラフ参照)、CISOの報告先は多様であることが少ない相対値から読み取れる。CEO、CFO、CTOも一般的な報告先ではあったものの、明確な2位は存在しなかった。また、50社以上において10-Kの記載から報告先が明確でなかった点も注目に値する。

Image

Derek Dye

取締役会による監督

取締役会内では、監査委員会がサイバーセキュリティの監督を担う最も一般的な組織であり、全企業の60%を占めている。監査・リスク委員会、監査・財務委員会など監査の各種バリエーションを含めると約70%(138社)に達する。監査に関連する数値は2024年から2025年にかけて概ね横ばいで推移した。2位と3位はそれぞれリスク委員会と取締役会全体が遠く続く。

NIST CSFが最多採用

米国立標準技術研究所(NIST)のサイバーセキュリティフレームワーク(CSF)は最も参照されているサイバーセキュリティ標準であり、2024年から2025年にかけて増加している(113社対118社)。次いで多いのがISO 27001で、こちらも2024年から2025年にかけて増加した(49社対55社)。興味深いことに、システム・組織管理(SOC)を言及した企業はわずか17社にとどまった。大規模な公開企業においてSOC報告書の重要性を考えると、この数字は低いように思える。

その他の興味深い観察点として、企業が広範な取り組みとして挙げている内容やインシデントの開示状況があった。

  • サードパーティおよびサプライチェーンのリスク管理。外部パートナーやサプライヤーが巨大な攻撃経路となることを認識し、複数の企業が厳格なサードパーティリスク管理(TPRM)プログラムを導入している。これらのプログラムでは、契約前のセキュリティ評価、継続的なモニタリング、ベンダーに対するセキュリティ基準の維持および侵害の迅速な報告を契約上の要件として課している。相互接続が進む経済環境や企業プロセスにおける外部ツール・サービスへの依存が高まる中、サードパーティのサイバーセキュリティプログラムは不可欠である。
  • プロアクティブなテストとインシデント対応への備え。企業は受動的な防御から、プロアクティブなテストやシミュレーションへと移行しつつある。これには定期的なペネトレーションテスト、脆弱性スキャン、独立した外部監査人やコンサルタントを活用したプログラムの成熟度評価やコントロールのテストが含まれる。さらに、ほぼすべての企業が正式なインシデント対応計画(IRP)を整備し、定期的な「机上演習」を実施してサイバー攻撃をシミュレーションし、経営、法務、業務チームが実際の危機に対応・復旧できる準備を整えている。ただし詳細は重要であり、10-Kは企業の手法を詳細に説明する技術文書ではないため、記載されていること自体は評価できるが、内容の多くは定型文にとどまっている。
  • 人を中心としたセキュリティ対策。人的エラーが主要な脆弱性であることを認識し、全社必須のサイバーセキュリティ意識向上トレーニングが標準的な要件となっている。これらのトレーニングプログラムは、従業員の警戒心をテストし即座にターゲットを絞ったフィードバックや補習トレーニングを行うための定期的なフィッシングシミュレーションで補完されることが多い。AIによるディープフェイクの高度化に伴い、これらのトレーニングも適応していく必要がある。
  • 継続的な脅威にもかかわらず「重大な影響なし」を一貫して開示。提出書類全体に共通するトレンドとして、各社が継続的かつ高度に進化するサイバー攻撃に直面しながらも、これまでのところ事業戦略、業績、財務状況に重大な悪影響を与えたインシデントは発生していないと認めている点が挙げられる。特に重要インフラや通信事業者がVOLT/SALT TYPHOONその他の攻撃に繰り返し晒されている状況を踏まえると、この点は興味深い。また多くの企業がサイバー賠償責任保険を活用して財務リスクを軽減していると開示しているが、すべての潜在的損失をカバーできない可能性があるとも頻繁に注記している。重大な影響、報道内容、正式な開示の間にはさらに興味深い発見がある可能性が高いため、追加調査を行う予定である。
  • 人工知能。AIは50社以上が言及しており、サイバーセキュリティにおける諸刃の剣として参照されることが増えている。各社はAIと機械学習を活用して脅威の検知を自動化し、大量のセキュリティデータを処理している。しかし一方で、AIが攻撃者に対してより高度かつ高速な攻撃(ディープフェイク、高度なフィッシングなど)を可能にするという認識を示した企業も複数あった。さらに7社がAIと知的財産の開示に関する懸念を言及しており、PrudentialとCapital Oneはこのリスクについて最も明確な表現を用いていた。

第2部:データ収集と分析

これは非常に反復的なプロセスであり、作業を進めるにつれて複雑さが増し、精度への要求も高まった。この分析にはいくつかのコーディング手法とAIツールを使用した。最初は大規模なモデルにすべての作業を任せようとしたが、そのレベルの作業を引き受けてもらえずすぐに行き詰まった。また、10-Kの提出書類を取得するためには、AIエージェントに尋ねる以上の作業が必要であることも明らかになった。

そこでバイブコーディングの出番となった。私はCとJava、BASHスクリプティングで育ち、今までPythonを避けてきた。Pythonへの反感ではなく、必要性を感じてこなかったこと、そして既知のものに頼るという怠惰さが勝ってきただけだ。今回は格好の追加課題となった。datamule Pythonモジュールとバイブコーディングを活用し、上位200社の最新10-Kをすべてローカルマシンにダウンロードすることができた。そこから別のPythonスクリプトを使って1.Cセクションを別ファイルに抽出した。提出書類の約5%で異なるフォーマットが使われていたり、サイバーセキュリティの記載が10-Kの別セクションにあるなど、若干の問題が生じた。約15社がリスクセクションや他の箇所に記載していた。これらの情報を抽出するために、Geminiのコマンドライン版(gemini-cli)を活用した2つ目のPythonスクリプトを使用した。

次に、主要な調査結果を保存してさらなる分析を可能にするためのデータベースをPostgreSQLで作成した。データを投入するために、各1.CファイルをGeminiとClaudeに通すPythonスクリプトをPython APIコールで作成した。

Gemini APIとAnthropic APIの活用は今回特に試してみたかった新しい要素であり、非常に興味深い結果をもたらした。LLMは大量のテキストを意味のある形に凝縮・要約する点で真価を発揮する。代替手段としては非常に複雑で手動で記述した正規表現が考えられるが、Gemini APIとAnthropic APIを使用すれば、以下のプロンプトを与えるだけでSQLコマンドに挿入できる文字列を生成してくれた。実際に動作するのを見るのは非常に感慨深かった。(**注:プロンプトインジェクションやデータポイズニングなども考えていたが、データセットは小規模かつ管理されたものであり、本番コードでもない!)

Image

Derek Dye

検証ステップとして、GeminiとClaudeの回答間で異なるデータベースエントリをすべて検出するスクリプトを作成し、元の1.Cセクションを再度Geminiに通してどちらの回答が優れているかを選ばせた。これによりフィールドによっては10〜30%のエントリが変更された。追加の分析はGoogle SheetsとGoogle NotebookLMで行った。

これにより基本的なAI活用ワークフローを構築した。エージェント型ではなかったが、自動化バージョンを作成するのは面白そうだ。このプロジェクトは、AIの生産性向上の可能性を示した。手作業なら少なくとも2倍かかっていたであろう詳細なリサーチを、約15〜20時間で行うことができた。同時に、精度が求められる場面での正確性という課題も浮き彫りになった。15〜20時間のうちの大部分は、AIの回答が正確であることを確認するための検証と改善に費やされた。

開発、デバッグ、実行にかかったトークンの総コストは約15ドルであり、高くはないが、すべてのプロジェクトで開発するほどのコストではない。そのコストの大部分は、データの正確性を確保するための改善と追加の検証チェックに費やされた。次のプロジェクトでは、ollamaを使ったllama3などのローカルLLMをローカルコンピュータで実行するか、このプロジェクトで作成したデータセットへのクエリを可能にするエージェントを試してみるかもしれない。

GEMINI_PROMPT = """
Analyze this SEC 10-K document and extract the following cybersecurity information.
Return the response strictly as a JSON object with these exact keys:
{
 "senior_cyber": "Name or title of the senior person responsible for cybersecurity. Provide a one word response either CISO, CTO, CSO, CIO, or position title.",
 "report_to": "Title or name of who the senior cybersecurity person reports to. one word response either CEO,
CTO, CSO, CIO, position title, or unknown. ",
 "board": "The board committee overseeing cybersecurity  Provide a 1-3 word answer. ",
 "standards": "The cybersecurity standards/frameworks used use provide 5-7 word answer. If unknown, state unknown. use acronyms if available (e.g., NIST, NIST CSF, NIST CSF 2.0, ISO 27001)",
 "years_of_experience": integer representing years of experience (use 0 if unknown)
}
"""
MODEL_ID = 'gemini-2.5-flash'
—----
               upsert_query = """
                   INSERT INTO company_cyber_filings_v1_4 (ticker, filing_date, senior_cyber, reports_to, board, st
andards, years_of_experience)
                   VALUES (%s, %s, %s,%s,%s,%s,%s)
                   ON CONFLICT (ticker, filing_date)  
                   DO UPDATE SET
                       senior_cyber = EXCLUDED.senior_cyber,
                       reports_to = EXCLUDED.reports_to,
                       board = EXCLUDED.board,
                       standards = EXCLUDED.standards,
                       years_of_experience = EXCLUDED.years_of_experience;
               """
               formatted_date = f"{year}-{month}-{day}" 
               cursor.execute(upsert_query, (
                   prefix,
                   formatted_date,
                   gemini_data.get("senior_cyber"),
                   gemini_data.get("report_to"),
                   gemini_data.get("board"),
                   gemini_data.get("standards"),
                   gemini_data.get("years_of_experience")
               ))
               cursor.execute(upsert_query, (prefix,f"{year}{month}{day}"))
               conn.commit()
               print(f"  -> Saved to database.")

本稿はFoundry Expert Contributor Networkの一環として公開されています。
参加をご希望の方はこちら。

翻訳元: https://www.csoonline.com/article/4177700/cybersecurity-trends-in-sec-filings.html

ソース: csoonline.com