刷新されたPCIセキュリティ基準委員会のガイドライン：十分な「シフトレフト」は実現したか？

本記事の一部は、Digital Transactions Magazineに掲載されたものです。

今年、PCIセキュリティ基準委員会は、PCIソフトウェアセキュリティフレームワークの一環として、全く新しいソフトウェアセキュリティガイドラインを公開しました。このアップデートは、ソフトウェアセキュリティのベストプラクティスを現代のソフトウェア開発に適合させることを目的としています。これは、私たちの生活の大部分が急速にデジタル化される以前に策定されたセキュリティ基準を見直す必要性を認め、プロセスが時代とともにどのように変化してきたかを認識する素晴らしい取り組みです。

これは、私たちの業界が、変化するニーズに合わせて進化する「適応可能なガイドライン」という考え方をより重視し始めていることの明確な証拠です。また、セキュアな開発プロセスを怠れば急速に制御不能に陥りかねないサイバーセキュリティ環境の要求に応えるものでもあります。当然のことながら、銀行・金融業界の統治機関として（つまり、私たちが資金、クレジットカード、オンライン取引、POS決済の保護を委ねているソフトウェアのセキュリティ基準を策定する機関として）、PCIセキュリティ基準委員会は大きなリスクを抱えており、それを軽減する強力な動機を持っています。

これらの基準は確かに以前のバージョンから改善されており、セキュリティを全体的な品質評価の一部として優先しつつ、迅速かつ革新的な機能開発を行うという現在の課題を解決する一助にはなります。しかし、私たちがまだ長い道のりの途上にいるという現実は、少々残念と言わざるを得ません。

決して、この取り組みを否定しているわけではありません。ただ、これらの新しいセキュリティガイドラインでは、「シフトレフト（開発の早期段階からのセキュリティ対策）」が不十分だという事実を指摘したいのです。

私たちは依然としてテストに固執しており、しかもそのテストのタイミングが遅すぎます。

PCIソフトウェアセキュリティフレームワークに見られる明白な問題の一つは、テストへの過度な依存です。もちろん、ソフトウェアのテストは不可欠であり（SAST/DAST/IASTプロセスにも役割はあります）、しかし私たちは同じ罠に陥り、異なる結果を期待し続けています。

私たちが知り、愛し、信頼するソフトウェアを生み出すために、コードを書き続けているのは誰でしょうか？それはソフトウェア開発者です。

スキャンツールや手動コードレビューを用いて、このコードをテストするという厄介な役割を担っているのは誰でしょうか？それはAppSec（アプリケーションセキュリティ）の専門家です。

これらの専門家が発見し続けているものは何でしょうか？何十年も私たちを悩ませてきた同じバグです。修正方法は長年知られているはずの単純な問題、つまりSQLインジェクション、クロスサイトスクリプティング、セッション管理の脆弱性などです。まるで「恋はデジャ・ブ」のような状況です。彼らは、開発者自身が長年修正する力を持っていたはずのコードの欠陥を見つけて修正することに時間を費やしています。ただ、開発プロセスにおいてセキュリティが優先されてこなかっただけなのです。特に、機能の提供が最優先されるアジャイル開発の時代においては、セキュリティは創造的なプロセスやプロジェクト完了の達成感を奪う「邪魔者」のように扱われがちです。

これはどちらのチームを非難するものでもありません。開発者もAppSecの専門家も、どちらも極めて重要な仕事をしていますが、お互いの邪魔をし合っているのが現状です。この状況は、セキュリティ意識の低い開発者がネガティブなセキュリティ文化の中で働き、脆弱なコードを生み出し、それが書かれたずっと後にスキャン・評価・修正されるという、欠陥のあるSDLC（ソフトウェア開発ライフサイクル）を永続させています。AppSecの専門家は、放置すれば企業に壊滅的な被害をもたらしかねない小さな繰り返し発生する問題に追われ、真に複雑な課題を解決する時間がほとんどありません。

テストをコードのセキュリティ脆弱性を網羅する唯一の手段とすることで、私たちは時間、資金、リソースを浪費しています。日々大規模なデータ侵害が発生している現状を見れば、この手法が最適とは言えず、機能していないことは明らかです。これらの新しい基準は、依然として完成した製品の状態を評価するものです（おそらく、すべての開発者がセキュリティ意識を持っているという前提に立っていますが、現実はそうではありません）。これは、欠陥を修正するのに最もコストがかかり、困難な段階です。まるで、豪華な新築の家を建てたその日に、安全チームを呼んで危険箇所をチェックするようなものです。もし基礎に問題があれば、それを修正するためにどれほどの時間と費用、そして頭痛の種が必要になるか想像してみてください。多くの場合、最初からやり直す方が簡単で安上がりです（そして、最初のバージョンを作ったすべての人にとって、それは非常に不満の残るプロセスです）。

私たちは、根本から取り組まなければなりません。開発チームをセキュリティのベストプラクティスに関与させ、効率的かつセキュアにコーディングするための知識を身につけさせ、さらにあらゆる職場においてポジティブなセキュリティ文化を構築・維持することが不可欠です。

学習曲線は厳しいでしょうか？もちろんです。不可能でしょうか？決してそんなことはありません。そして、それは退屈な苦役である必要もありません。開発者の創造性や問題解決能力に直接訴えかけるトレーニング手法は、銀行・金融セクターですでに大きな成功を収めています。Capital OneにおけるRuss Wolfe氏の経験がその証拠です。

私たちは依然として完璧な「最終状態」を追い求めています。

更新されたPCIセキュリティ基準を、本来の意図である「完成したユーザー向けの金融製品は、最適なセキュリティと安全性のためにこれらのベストプラクティスに従うべきである」という文脈で見れば、全く問題ありません。しかし私の考えでは、金融かどうかにかかわらず、すべての企業が機能品質と高いセキュリティ基準の両方を備えたソフトウェアの最終状態に到達する最善の方法は、一歩立ち止まり、サイクルの最初から取り組む方がはるかに効率的であると認識することです。

その完璧な最終状態とは何でしょうか？製品をスキャンし、手動でレビューし、完璧でエラーのない状態でリリースされるという、あの状態のことです。私たちはまだそれを追い求めていますが、現時点では、それはユニコーンのような幻に過ぎません。

なぜそれほどまでに捉えどころがないのでしょうか？それにはいくつかの要因があります。

• スキャンツールは頼りにされていますが、常に効果的とは限りません。誤検知は時間と労力を浪費させる厄介な副産物であり、DAST/SAST/PCIスキャンを組み合わせたとしても、コードベース内のあらゆる脆弱性を特定・検出できるわけではありません。「問題なし」と判定されたとしても、本当にすべてを網羅できているのでしょうか？攻撃者は、保護されていると思い込んでいるシステムに侵入するために、たった一つの脆弱性さえあれば十分なのです。
• 開発者は同じ過ちを繰り返しています。セキュリティに関する知識は開発者間で共有されておらず、優れた安全なコードパターンである「セキュアコードレシピ」も広く認知・文書化されていません。
• 協力的で前向きなセキュリティ文化を構築することへの意識も欠けています。
• 開発者が創造的なプロセスやアジャイル開発手法を妨げることなく、製品にセキュリティを組み込めるよう、適切なツールで支援する必要があります。

これらのガイドラインは、ソフトウェアが準拠すべきセキュリティ基準を確認するための強力なチェックリストですが、ソフトウェアをその状態に導くための最適なプロセスについては、依然として議論の余地があります。

ソフトウェアが安全でないのはスキャナーが不足しているからではなく、開発者が指針となる使いやすく分かりやすいセキュリティツールを提供されていないからです。

私たちは今、進化の時代にいます。長年、ソフトウェアセキュリティは選択的なものでした。しかし今日では、特に機密情報（金融、医療、社会保障など）を扱う組織にとって、それは事実上必須となっています。

PCIセキュリティ基準委員会はベンチマークの策定に貢献していますが、彼らが持つ業界内での高い評価と影響力を活かし、開発者向けの実践的なガイドラインの策定にも取り組んでほしいと願っています。特に、適切で前向きなトレーニングやツールの提供を重視すべきです。現状では、開発チームのセキュリティ意識向上やコンプライアンス遵守を組織に促す圧力は存在せず、多くの開発者は、些細なミスが悪意ある攻撃者に悪用された場合の重大さを理解していません。

価値あるすべての物事と同様に、真の変化をもたらすには多くの人々の協力が不可欠です。そして、今まさに起きている変化が、私たちを（願わくば）さらに左側（開発の初期段階）へと導いてくれるはずです。