この記事の一部分は、以下の雑誌に掲載されました。 デジタルトランザクションマガジン.

今年、PCI セキュリティ基準審議会は、PCI ソフトウェアセキュリティフレームワークの一環として、全く新しいソフトウェアセキュリティガイドラインを発表しました。今回の更新は、ソフトウェアセキュリティのベストプラクティスを最新のソフトウェア開発に沿ったもの にすることを目的としています。今回の更新は、ソフトウェアセキュリティのベストプラクティスを現代のソフトウェア開発に沿ったものにすることを目的としています。これは、このプロセスが時間とともに変化していることを認識し、私たちの生活の大部分が急速にデジタル化される前に設定されたセキュリティ基準を再考する必要があるという、素晴らしい取り組みです。

これは、私たちの業界が、変化するニーズに合わせて進化する、適応性のあるガイドラインという考えに、より密接に関わっていることの明確な証拠であり、また、安全な開発プロセスを怠り続けると、あっという間に制御不能に陥る可能性のあるサイバーセキュリティの状況の要求にも対応しています。当然のことながら、PCI セキュリティ基準審議会は、銀行・金融業界の管理機関としての役割を担っており（つまり、私たちがお金やクレジットカード、オンライン取引、POS などの保護を任せているソフトウェアのセキュリティ基準を設定している）、多くのリスクを抱えており、それを軽減するための大きなモチベーションを持っています。

これらの基準は、確かに前バージョンよりも改善されており、全体的な品質の一部としてセキュリティを優先した、迅速で革新的な機能開発の穴を塞ぐためにある程度の役割を果たしていますが、assessment 、まだまだ道のりは長いという現実には少々がっかりさせられます。

これは、私がこの取り組みに「バーン・ハンブッグ！」と言っているわけではありません。実は、この新しいセキュリティガイドラインは、私たちを左遷するには不十分なのです。

テストに固執していた（テストが遅すぎた）。

私が PCI セキュリティ基準フレームワークで見つけた重大な問題の 1 つは、テストに依存していると思わ れる点です。もちろん、ソフトウェアは依然としてテストされなければなりませんが（SAST/DAST/IAST プロセスはまだその役割を果たしています）、同じ罠に陥り、異なる結果を期待してしまうことになります。

私たちが知っている、愛している、信頼しているソフトウェアを作るために、1行1行のコードを書いているのは誰でしょうか？ソフトウェア開発者です。

スキャンツールや手作業によるコードレビューで、このコードをテストするのは誰でしょうか？AppSecのスペシャリストです。

彼らは何を発見し続けているのか？何十年もの間、私たちを悩ませてきた同じバグです。何年も前から修正方法がわかっている単純なものだ。SQLインジェクション、クロスサイトスクリプティング、セッション管理の脆弱性......彼らにとってはグラウンドホッグデーのようなものだ。彼らは、開発者自身が何年も前から修正する力を持っていたコード違反を見つけて修正することに時間を費やしていましたが、セキュリティが彼らのプロセスにおいて優先されていなかったことを除いては、「特に、機能提供が王様であるアジャイル開発の時代にあっては、セキュリティは創造的なプロセスとプロジェクト完了の勝利を奪うグリンチです。

assessment これは、どちらのチームも否定しているわけではありません。開発者とAppSecの専門家はどちらも非常に重要な仕事をしているにもかかわらず、お互いに邪魔をし続けています。このような状況は、欠陥のあるSDLCを永続させるだけです。セキュリティ意識の低い開発者は、否定的なセキュリティ文化の中で作業を行い、安全でないコードを作成し、それが最初に書かれた後にスキャン、評価、修正されなければなりません。AppSecは、本当に複雑な問題を解決する時間がほとんどありません。なぜなら、放っておけば企業に災いをもたらす可能性のある、繰り返し起こる小さな問題に追われているからです。

テストがコードのセキュリティ上の弱点のすべてであると考えることは、時間、費用、資源を無駄にすることになります。そして、毎日のように大規模なデータ侵害が発生しており、この方法が最適に機能していないことは明らかです。これらの新しい基準は、（おそらくすべての開発者がセキュリティ意識を持っているという前提で）最終製品の状態、つまりすでに構築されたものを評価しています。これは、欠陥を修正するのに最もコストがかかり、困難な段階です。まるで、豪華な新築の家を建てて、入居したその日に安全対策チームを呼んで危険性をチェックしてもらうようなものです。もし、基礎に何か問題があった場合、問題に対処するためにその場所に行く時間とコスト、そして全くの頭痛の種になることを想像してみてください。

開発チームにセキュリティのベストプラクティスを理解させ、効率的に安全なコードを書くための知識を身につけさせ、さらにすべての職場でポジティブなセキュリティ文化を創造し、維持するという、基礎からの取り組みが絶対に必要です。

それは学習曲線ですか？その通りです。不可能ですか？絶対に不可能ではありません。そして、それは退屈な苦行である必要はありません。開発者の創造性や問題解決能力に直接訴えるトレーニング方法は、銀行や金融の分野ではすでに大きな成功を収めています（Capital Oneでのラス・ウルフの経験が示唆しています）。

まだまだ完璧な "End-State "を求めています。

更新された PCI セキュリティ基準を、それが意図する文脈の中で見るならば、つまり、完成してユーザーが使えるようになった金融商品は、最適なセキュリティと安全性を実現するために、これらのベストプラクティスに従わなければならない、という意味では、まったく問題ありません。しかし、私の考えでは、金融機関であろうとなかろうと、すべての企業は、一歩下がって、サイクルの最初からこれを行う方がはるかに効率的であることを理解しさえすれば、機能品質と高水準のセキュリティの両方を代表するソフトウェアの最終状態に到達する最高のチャンスを得ることができます。

その完璧な最終状態とは？製品がスキャンされ、手作業でレビューされ、エラーのない完璧な状態で出荷されたときに起こるものを知っていますか？私たちはまだそれを探しています。今のところ、それはユニコーンです。

なぜこんなにもつかみどころがないのか。それにはいくつかの要因があります。

• スキャンツールは頼りにされていますが、必ずしも効果的ではありません。DAST/SAST/PCIスキャンを併用しても、コードベースに存在する可能性のあるすべての脆弱性を特定して明らかにすることはできないという事実と同様に、誤検出は、その使用によるイライラと時間の浪費を伴う副産物です。確かに、DAST/SAST/PCIスキャンは、すべての問題を解決してくれるかもしれませんが、本当にすべてを探しているのでしょうか？攻撃者は、保護されていると思っているものにアクセスするために、1つの脆弱性を利用するだけでよいのです。
• 開発者は同じ過ちを繰り返しています。開発者の間では、セキュリティに関する知識が分散されておらず、よく知られていて文書化されている「セキュア・コード・レシピ」（優れたセキュアなコードパターン）もありません。
• 協力的で前向きなセキュリティ文化の構築には重点が置かれていない。
• 開発者は、創造的なプロセスやアジャイル開発の方法論を妨げることなく、製品にセキュリティを組み込むための適切なツールを手に入れる必要があります。

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

安全でないソフトウェアがあるのは、スキャナーがないからではありません。安全でないソフトウェアがあるのは、開発者が使いやすく、理解しやすいセキュリティツールを提供されていないからです。

私たちは今、進化の時を迎えています。一般的なソフトウェア・セキュリティは、長年にわたって任意のものでした。

PCI Security Standards Council（PCI セキュリティ基準協議会）は、基準を設定するための支援を行っていますが、私は、業界での評価と影響力を持つPCI Security Standards Councilが、適切かつ積極的なトレーニングとツールに重点を置いた、開発者のための実用的なガイドラインを作成することに取り組んでほしいと思っています。今のところ、組織が開発チームにセキュリティを意識させ、コンプライアンスを徹底させるようなプレッシャーはなく、多くの開発者は、簡単に修正できる小さなミスが悪用されたときの重大さを理解していません。

人生で価値のあることは何でもそうですが、本当に変化を起こすには村が必要です。そして、この空気の変化は、（願わくば）私たちをさらに左へと導いてくれることでしょう。