セキュアなソフトウェアを開発するために必要なこと

完璧なソフトウェアなど存在しません。これは、ソフトウェア開発において避けられない事実です。しかし、バグや欠陥の防止、その影響の緩和、そのような問題への対処方法の改善に努めることはできます。

本記事では、現在私たちが直面している状況をみていきます。未発見の欠陥や脆弱性について、正確な数を示すことはできませんが、目安となる推定値はあります。記事の後半では、これらの問題を未然に防止するために私たちが実際に講じている対策の一部と、脆弱性の管理方法についてご紹介します。

現状把握

バグや欠陥を回避・防止し、適切に問題を対処する方法を理解するには、まず、問題のタイプ、発生頻度や場所を知る必要があります。

仮に1,000行のコードがあるとしましょう。ここには、どれだけのバグや欠陥が含まれているのでしょうか。Steve McConnell氏の著書『CODE COMPLETE』が参考になります。いくつかの例外的なケースを無視したとしても、1,000行のコードにつき10～50個の欠陥があると、本書の統計では示されています。つまり、コードの20行ごと、または100行ごとに、コンパイラーが見逃すエラーが存在するというのです。これは予想外の多さではないでしょうか。本来であれば、エラーをこれほどまでに抑えている点で、ITシステムを称賛すべきところではありますが、予想以上の多さであることには変わりはありません。

しかし、数はそれほど大きな問題ではありません。重要なのは、「欠陥」が深刻な問題につながるかという点です。まず、セキュアなソフトウェアを開発するにあたり、「バグ」と「欠陥」という2つのタイプを区別して認識しなければなりません。「バグ」とは、一般的なプログラミングエラーを指します。一方、「欠陥」は、設計そのものに問題があることを意味します。バグを発見するには、後の「予防」セクションでも述べるように、大規模なツールキット（コードを精査し、さまざまなタイプのエラーを発見）が有効です。一方、欠陥は、ソフトウェアの設計や開発における疑う余地のない想定に起因することが多く、それが間違っていたり、無効であったりする場合、ハッカーに悪用されうる脆弱性を生み出す恐れがあるため、発見が困難です。

従って、欠陥を悪用されうる脆弱性にさせないことが重要です。コードにおけるすべてのエラーが、悪用されるわけではありません。攻撃者によるバグや欠陥の悪用を防ぐうえで有効なアーキテクチャーを理解することで、開発中に起こったミスの脆弱性への転用を防ぎ、発見したバグや欠陥の悪用可能性を正確に把握することができます。つまり、自身の業務を評価する際、特に新製品を開発する際には、欠陥がもたらす影響を感じ取る能力が求められるのです。

予防

ソフトウェアアーキテクチャー

すべてのソフトウェア開発において、ベースとなるのはユーザーが求めるニーズの分析です。その分析結果は、機能/技術面において必要とされるソフトウェアアーキテクチャーを設計するために使用されます。この設計は、International Software Architecture Qualification Board (iSAQB^®)によって認証を受けた、経験豊富なソフトウェア開発者とアーキテクトが共同で行います。さらに、製品開発に直接関与しないセキュリティ専門家チームからの意見も取り入れることで、アーキテクチャーから暗号化技術の基本的な使用方法に至る、その製品のコンセプトが作り上げられます。

コーディング、テスト、そして教育

出来上がった製品設計に沿ったソフトウェアを開発する際、私たちはさまざまテクノロジーを駆使し、可能な限り早い段階でコードのエラーを発見・修正できるよう努めています。特に、バージョン管理システムは、ピアレビューを原則とするソフトウェア開発において欠かすことはできません（実際、Wibu-SystemsではGitを採用しています）。「抑制と均衡」なしに、開発者がたった一人で、コードを完成させることはほぼ不可能と言ってよいでしょう。

SonarLintは、開発環境での静的コード解析に使用されます。一方、ソースコードの継続的な静的解析や、ソフトウェアの技術的な品質評価においては、SonarQubeの商用版をビルドサーバーに採用しています。SonarQubeには、MISRA-CやCERT C/C++といった5000以上の静的解析プロセスが含まれており、クリーンコードの生成に役立ちます。ビルドごとに、コンパイラー警告と静的解析の結果が表示される仕組みになっています。

対して動的コード解析は、実行時にアプリケーションをチェックするために使用されます。様々な入力をシミュレートすることができるファジングという手法は、脆弱性を検出する際によく用いられます。Radamsa、LibFuzzer、AFL、WinAFL、GCC、ASAN、UBSAN、Valgrindなどのツールがあります。

新たに実装を行う場合には、ユニット単位でリグレッションテストを行います。この単体（ユニット）テストと自動化された結合テストは、欠陥に応じて適宜微調整されます。また、構成管理とオーケストレーションは、AnsibleとTerraformに委ねています。総じて、私たちは開発とテストのために大規模なインフラを投じており、それをコードと同等のものとして扱っています。

またビルド・テストのプロセスは、JenkinsとGitLab Runnerを用いて自動化しています。これは、サポートするすべてのオペレーティングシステム（OS）上で毎晩テストをビルドするなど、私たち人間には到底不可能であるからです。自動化されたテストで何らかの問題が発見された場合には、優先順位をつけてバックログとして記録した上で、原因を探り、解決へとつなげます。重大な問題が発見された場合は、どのような過程で発見されたか、誰が気づいたかに関わらず、即座にフラグが立てます。これにより、重大な問題への優先度が高まり、早期解決に結びつけることができます。

セキュアなコードを知らなければ、セキュアなソフトウェアを生み出すことはできません。私たちが開催している定期的なトレーニングでは、OWASPトップ10に載っているようなセキュリティ上重大なリスク、そして特定の言語、オペレーティングシステム（OS）、またはコンテナのベストプラクティス、さらにはファジングを含めた、さまざまな事柄に関して学ぶことのでき、コード上に存在する典型的な欠陥を回避するための方法を開発者は習得することができます。また新入社員研修では、ITセキュリティとその問題に対する正しい認識をしっかり頭に入れられるようなトレーニングを用意しています。これらトレーニングには、社内外のオプションを活用しており、世に存在するさまざまな脅威と、そのリスクを軽減する方法について、社員の理解が深まるよう工夫を凝らしています。長期的な視野のもと、社員一人一人にセキュリティーに対する鋭い感覚が備わることを願い、教育を大事にしてます。

サードパーティー製のソフトウェア

ソフトウェア開発者であれば誰でも、機能の多くはゼロから開発されることなく、他の開発者によって作成されたライブラリをもとに構築されると知っているはずです。つまり、ライブラリの選択を誤れば、ソフトウェアセキュリティにとって深刻な問題となり、それを悪用した攻撃者が、企業やそのサプライヤーに不正アクセスする可能性が出てきます。このような攻撃は、サプライチェーン攻撃と呼ばれ、私たちWibu-Systemsも警戒しています。具体的には、依存関係（サプライヤー）を減らす、外部から持ち込むコンポーネントは慎重に選択し、監視を強化するといった対策を講じています。また、現在のコードバージョンをサプライヤーのリポジトリから直接ビルドプロセスが読み込む行為は、特にリスクが高いと考えています。これは、セキュアな最新のパッチがすべて適用されていることを前提に行われますが、未発見の有害なコードが侵入するリスクも伴います。従って、弊社のビルドシステムでは、オンラインアクセスを必要とせず、結果的にそのようなリスクを未然に防いでいます。

オペレーション

Wibu-Systemsでは、ソフトウェア製品だけでなく、CmCloudソリューションのようなサービスも提供しています。弊社のオペレーティングシステム（OS）と同様に、CmCloudを含めたサービスの多くは、弊社がユーザーの代わりに、常時監視、モニター、サービス業務を担います。製品は随時アップデートされ、ユーザーは常に、新たな機能や改善が備わったバージョンを利用することができます。

また、サポートが終了したオペレーティングシステム（OS）上で動作している可能性の高い旧バージョンの製品については、継続的なサポートを提供しています（別途、要契約）。例えばCodeMeterソフトウェアのバージョン7.21には、最新バージョンの全てのセキュリティ更新も含まれていながら、Windows 7でも使用可能です。

対処

以上すべての予防措置を講じた場合、理論上、安全性は確保されます。しかし、現実はそう簡単にはいきません。そして、本記事の著者である私たちも、すべての欠陥を取り除くことができるとは思っていません。ほんの小さな欠陥が、予期せぬ事態を招く場合もあるということを忘れないでください。過去の「Log4Shell」という重大なセキュリティインシデントから受けた教訓を深く胸に刻むべきです。

すべての問題を防ぐことは不可能である以上、欠陥や問題にどう対処するか考えなければなりません。まず最も重要なこととして、どのソフトウェアにも欠陥は存在すると認める必要があります。その上で、エラーを誰が起こしたのか、見つけたのかではなく、それにどう対処するかを考えることが大切です。脆弱性が故意や重大な過失によって作られたものではないという前提に基づくならば、意味もなく憤る必要はないはずです。

問題がサードパーティー製のソフトウェアによるものである場合、以下の3つの行動をとる必要があります。

• ・悪意ある攻撃から自社とユーザーを守るため、脆弱性のない最新バージョンを可能な限り早く入手する
• ・サードパーティーから潜在的な影響について可能な限り多くの情報を受取り、その情報をもとに対応策を考える
• ・常に最新の情報を得る

一方で、脆弱性が発見されたソフトウェアの会社は、顧客へより良いサポートを提供するため、何らかの体制を整える必要があります。脆弱性の報告を受ける窓口や重大な脆弱性などの対応を行うチーム（CERT（Computer Emergency Response Team））の設置、また各製品の担当者や現場の顧客との綿密な連携などが含まれます。

一つひとつの局面の詳細は、本記事に書ききれないほどであり、十分注意を払う必要があります。ここでは、連携体制とその必要な組織構造について例に挙げてみます。たった一種類の製品に影響する1つの脆弱性でさえも悩ましいのですから、複数の製品に影響する脆弱性は、あらゆるビジネス分野において非常な深刻な問題となることは明らかです。経営資源はただでさえ限られているのにも関わらず、脆弱性が生じたと同時に、複数の問題への対処を迫られるとともに、可能な限り組織化・標準化された形で情報を共有しなければなりません。組織が大きくなればなるほど、緊急チームを常時設置し、関連するすべての問題に対処することは不可能になります。従って、必要な手順を予め定めたうえで、過去の問題からの教訓を活かして改善を繰り返していくことが重要です。実際Wibu-Systemsでは、過去の教訓を受けて Product Security Boardを設置しました。この委員会には、各製品チームとCERTのメンバーが所属し、必要に応じて他部門のスタッフとの連携も行います。これにより、ノウハウの迅速な収集・共有が可能になります。また各メンバーは、開発チーム全体の代表として発言するため、各チームでの意思疎通が容易となり、迅速な対応が可能です。CERTは、暗号化技術に関する専門的なノウハウ提供に加えて脆弱性の分析をサポートする立場として、顧客への情報共有を行っています。弊社の「対応」に関するより詳細な情報はKEYnote 43をご覧ください。

 

KEYnote 46 – Edition Fall/Winter 2023

貴社の課題をCodeMeterで解決しませんか？
お気軽にお問合せください。製品説明および最適な使い方をご提案します。

お問合せ