ベストセラーのビジネス書「7 つの習慣(7 Habits of Highly Effective People)」では、目標を達成している成功者たちには共通する資質があり、誰もがこれら資質の1 つ1 つを特定して実践できる、という理論を説いています。BSIMM(Building Security In Maturity Model)プロジェクトは、この前提をソフトウェアセキュリティに適用することで組織のSSIを調査し、それらの組織の活動について直接インタビューを実施した結果を毎年公開しています。今回で12回目の公開となるBSIMMレポートは、2008年の参加企業は9社でしたが、2021年には128社へと成長し、約3,000のソフトウェア・セキュリティ・グループ・メンバーと6,000を超えるサテライト(別名セキュリティチャンピオン)メンバーが15万を超えるアプリケーションで、約40万の開発者と協力しています。
2021年版のBSIMMレポート(BSIMM12)は、金融サービス、フィンテック、独立系ソフトウェアベンダー(ISV)、IoT、ヘルスケア、テクノロジーなど、さまざまな分野にわたる128の組織のソフトウェアセキュリティ活動からの匿名化されたデータを調査しました。 参加組織には、Aetna、Bank of America、Citigroup、Freddie Mac、Johnson&Johnsonなどの業界のリーダーが含まれます。
BSIMM12で調査された組織の多くは、従来の業種と同一視していますが、すべてが基本的にソフトウェアビジネスに属していることを認識しています。ソフトウェアは、すべての組織の運用において主導的な役割を果たします。ソフトウェアの開発と展開の遅れは、収益と利益を促進する生命線である製品のリリース日に影響を与えますが、ソフトウェアを販売したり、組み込みソフトウェアを含む製品を販売したりする企業は、セキュリティ、コンプライアンス、または品質の問題について妥協することはありません。
ソフトウェアまたはソフトウェア駆動型製品を直接販売していない企業も、ソフトウェアの品質とセキュリティに依存しています。ソフトウェアは、給与、請求、売掛金、売上管理、および顧客管理システムを実行します。また、生産管理、在庫管理、倉庫保管を行い、ビジネスを継続するために流通システムを実行します。サービス産業では、ソフトウェアを使用して、顧客の分析、最適化、モデル化、対話、およびサポートを行うからです。
BSIMM12の調査結果によれば、ソフトウェアリスクはビジネスリスクであり、ビジネスリスクを効果的に管理するには、ソフトウェアリスクへの適切な対処が必要です。
ソフトウェアセキュリティに則った振る舞いを義務付けることから、セキュリティチームに開発チームとのパートナーシップを構築させる傾向があります。これは、ソフトウェアデリバリーのクリティカルパスで、セキュリティに対する取り組みを積極的に行うことを目的としています。
BSIMM12のデータが示しているのは、特定の時点での欠陥を発見するやり方よりも、継続的な監視とレポートを好む企業が多く、ソフトウェア開発とガバナンスプロセスの改善を推進するためにセキュリティ・テレメトリを使用しているということです。
なるべく早期に問題を特定することは今も重要な課題であり、大規模なテスト・イベントを細かく分割して、適切なタイミングでチェックを実行することの必要性が高まっています。しかし一部のテストに関しては、デプロイメント・オーケストレーションまたはポスト・デプロイメント環境まで待ってから実施することが最も早期かつ適切なタイミングであるという認識もソフトウェア・セキュリティ・グループ内で高まっています。
コードとしてのガバナンス(Governance-as-Code)は、セキュリティ・プラクティスとコンプライアンス・ポリシーの順守を、手動で行うのではなく、より一貫性があり、効率的で、反復可能で、自動化されたアプローチに移行します。年初に収集されたBSIMMデータによれば、組織が人手による人間駆動型のガバナンス・アクティビティを自動化によって置き換えるプロセスに着手しつつあることが明らかになっていました。BSIMM12の観測結果によれば、ソフトウェアセキュリティのスタンダードとポリシーの唯一の拠り所が、ソフトウェア定義によるライフサイクル・ガバナンスの本質である、人間が解読可能な構成コード、または脆弱性の発見を実行する簡単なコードになりつつあることを示しています。
BSIMM12の調査データに基づいて、ソフトウェア・セキュリティ・イニシアティブ(SII)を作成するプロセスで、組織は次の主要なアクションを検討する必要があります:
包括的なソフトウェア・インベントリを作成する:
このインベントリには、自社の資産だけでなくオープンソースおよびサードパーティー・コードのソフトウェアBOM も含めることが推奨されます。「2020 Magic Quadrant for Application Security Testing」の中で、Gartner 社は「ソフトウェア・ベンダーに対し、定期的に更新される詳細なソフトウェアBOMの納入を必須条件として課しているエンタープライズソフトウェアのバイヤーは、2019 年時点では5% 未満にとどまっていますが、2024年には少なくとも半数には達するでしょう」と予測しています。BoM を人手で作成するのは理論上は可能かもしれませんが、それを維持管理しようとすると、結局は長い開発期間をかけて自動化することが必要になります。自動ツールで生成したBoMなら、使用しているコードのバージョン番号、脆弱性情報、ライセンスなどの包括的な情報が得られます。また、オープンソースの場合であれば各オープンソース・コンポーネントが使用している可能性のある依存ファイルについても理解を深めることもできます。
ソフトウェア開発ライフサイクル全体で、フェーズごとに区切った小規模なセキュリティアクティビティを実装する:
大規模で時間のかかる合否判定ゲートではパイプラインの進行が遅れてしまうため、テストは小規模なものを心がけるようにします。
自動化された セキュリティツールを導入する:
これらのツールを使用すると、内製ソフトウェアであれ、サードパーティーの商用ソフトウェアであれ、オープンソースであれ、自社の重要なソフトウェアに潜む不具合、脆弱性、悪質なコードを特定して容易に修正できます。
過去12年間、BSIMMレポートは、独自のSSIをより広範なBSIMMコミュニティと比較するための「物差し」として世界中の組織で使われてきましたが、自社が「導入期」、「成熟期」、「最適化期」のどのフェーズにあるかを見極めることがすべての土台となります。幹部は自社のAppSecプログラムが現在どのフェーズに該当するかをまず見極める必要があります。
企業の知名度やそのAppSecプログラムの成熟度にかかわらず、BSIMMはあらゆる企業の幹部が業界のトレンドやリスク、優先事項、その他の要因に照らし合わせて自社を測定するための評価軸となります。BSIMMの用途はそれだけではありません。各組織のニーズに合わせたAppSecプログラムの作成、改善から成功までの道筋を示すロードマップとしての役割もあります。自社の目標を特定した後、そこにBSIMMのデータを重ねることにより、どのような追加対策や投資が必要なのかを判断できます。