wolfSSL製品には、それぞれ特定の目標と目的を持ついくつかのソフトウェアモジュールとコンポーネントが存在します。すべてのソフトウェア製品は、開発プロセスにおいて、要求される品質基準を使用し設計されていることを確認しています。ソフトウェアのライフタイム内の各ステップでは、コードの欠陥とリグレッションを非常に早期に検出できるよう、厳格なルールとテスト基準（厳格なファズベースのテストを含む）が課されています。
品質保証
コードの機能の最初の検証は、開発者の開発PCでローカルに実行します。 Gitのコミットフックとプッシュフックは、コードが機能とユニットテストの最初のセットに合格した場合にのみコードをリポジトリに送信できるようにしています。 プルリクエストが公開されると、非回帰テストと統合テストのフルラウンドが自動的に開始され、プルリクエストのステータスがテスト結果で更新されます。 プルリクエストが受け入れられるためには、ピアレビューと非回帰テストおよび統合テストに合格する必要があります。 プルリクエストのコードが変更されるたびに、レビュープロセス中にテストが自動的に再トリガーされます。
品質管理の自動化
wolfSSLでは、Jenkinsを使用してノード間のワークロードを調整し、定期的に品質管理を適用するハイブリッド（オンサイト+クラウドベース）インフラストラクチャを展開しました。これには、コード変更をコミットする都度メインラインへの取り込み可否評価のためにソフトウェアテストを実行することや、定期的に（たとえば、毎晩、毎週）適用される他のタイプの品質管理が含まれます。 ハイブリッドアプローチの背後にある理由は、wolfSSLソフトウェア製品の移植性という特徴によるものです。ソフトウェアは、いくつかの異なるハードウェアアーキテクチャで実行され、ハードウェア暗号化モジュールやTPMなどの特定のハードウェアコンポーネントと相互運用する必要があります。一部のjenkinsノードで物理マシンを使用すると、自動的に構成およびプログラムできるマイクロコントローラーボードなど、特定のハードウェアターゲットを構成および制御するメカニズムが提供されます。 一部のテストは、実行に長い時間がかかります。継続的インテグレーションツールは、品質管理ジョブのアプリケーションを長期間にわたって分割して、すべてのテストが定期的に実行されるようにするために非常に役立ちます。
第三者機関によるアルゴリズムとモジュールの検証
実装がスタンダードへ正確に準拠しているかを検証する目的で、NISTが推奨するツールと手順を使用してwolfSSLソフトウェアコンポーネントをテストしています。これには、一連の既知の入力値（テストベクター）と期待される結果を使用した機能テストの完全なセットが含まれます。多くの暗号化アルゴリズムの正しさは、計算の中間結果を調べることによっても検証できます。 NISTは、連邦政府の部門や機関が使用する暗号化モジュールの要件と標準を調整する一連の出版物（FIPS 140）も発行しています。米国とカナダにある認定された専門の第三者機関の取り組みにより、FIPS140規制への準拠を証明するための2つの検証プログラムが利用可能になりました。 wolfCryptはFIPS140-2認定を取得しており、最近承認されたFIPS140-3認定も既に申請しています。 FIPS認定では、暗号化モジュールが次の2つのプログラムの検証を通じて正常に送信される必要があります：
- 暗号化アルゴリズム検証プログラム（CAVP）は、実装された承認済み暗号化アルゴリズムの検証テストを提供します。
- 暗号化モジュール検証プログラム（CMVP）は、機密データおよび情報を保護するために政府および規制対象の業界が使用するモジュールを認定します。
CAVP / CMVPで使用されている同じタイプのテストをメインラインで自動的に繰り返し実行することで、コードの変更がFIPS140で指定されているアルゴリズムとモジュールの整合性に影響を与えないことを確認しています。
相互接続性テスト
プロトコルの動作が継続的インテグレーション全体で同じままであることを確認する非常に効果的な方法の1つとして、同じ標準の異なる実装で相互運用性テストを実行することが挙げられます。 wolfSSL品質管理インフラは、通信のリモートエンドポイントとして異なる実装を使用し、一般的なベクトルから開始する暗号化操作の結果を比較する、多数のスケジュールされたテストを提供しています。
ユニットテスト
ユニットテストはすべてのコアモジュールに必須であり、新しいコミット時に開発者のマシンで実行されます。 ユニットテストのカバレッジは毎週測定され、コードに新しい機能を追加するときにカバレッジの回帰がないことを確認します。wolfSSLの開発者は、継続的インテグレーションのためにJenkinsインフラによって提供される自動化のおかげで、毎週完全なコードカバレッジレポートをメールで受け取ります。
API一貫性検証
ある特定のテストセットは、実装の変更がアプリケーション開発の観点からAPIの使用法を変更しないことを確認します。 これらのテストは、APIに新しい関数を追加することを除いて、更新されることはありません。 APIはアプリケーションとライブラリ間のコントラクトであるため、バージョン間で一貫性を保つ必要があります。 これらすべての側面を検証することは、要件への準拠を検証するために毎晩実行されるテストのサブセットの目標です。
統合テスト
wolfSSLの移植性のため、カスタム構成を含めることによってテストドメインを拡張する必要があります。カスタム構成では、さまざまなアーキテクチャ用にソフトウェアをコンパイルし、コンパイル時の構成オプションとテストアプリケーションを組み合わせる必要があります。 テストスイートを実行するためのターゲットとして、実マシンと仮想マシンの両方が使用されます。 さまざまなアーキテクチャ（x86、ARM、PowerPC、RISC-V、MIPSなど）でテストを自動化することで、アーキテクチャ固有のリグレッションまたはバグをプロセスの早い段階で検出および識別でき、期待される動作はすべての場合で一貫しています。 継続的インテグレーションインフラストラクチャのハイブリッドモデルのおかげで、いくつかのターゲットがJenkinsノードに接続され、さまざまな特定のハードウェアおよびソフトウェア構成とユースケースを通じてソフトウェアテストの実行を担当します。
安全性審査：舞台裏のしくみ
継続的インテグレーションインフラストラクチャは、いくつかの分析ツールの実行も自動化します。
静的分析ツールは、コンパイル時オプションのさまざまな組み合わせを全て調べ、さまざまなコードパスをたどって、コード内の不整合を探します。これらのツールは、ソースコードレベルで厳密なチェックを適用することにより、コンパイラでカバーされない可能性のあるプログラミングミス、潜在的なエラー、および未定義の動作を検出できます。 wolfSSLが使用しているCIで自動化されたツールには、cppcheck、clang静的アナライザー（スキャンビルド）、Facebook推論などがあります。
メモリ分析は、メモリ処理に関連するバグを探すために定期的に実行されます。 wolfSSLは、valgrind memcheckツール、clangサニタイザー、およびその他の動的分析を使用してコードを実行します。これらのツールは、初期化されていない、または以前に解放されたメモリへのアクセス、未定義または初期化されていない値の使用、メモリリークなどのメモリエラーを検出します。 ファザーは、予期しない状況に対するコードの堅牢性を向上させるための非常に重要なリソースです。これらのツールの目的は、多数のランダムな入力をすばやく連続して挿入することにより、コードの誤動作を引き起こそうとすることです。
ファジングは、長い間見過ごされがちなコードのバグや脆弱性を検出するための非常に効果的な方法です。 wolfSSLでは、API関数とトランスポートバックエンドにフィードするために常にファザーを実行し、出力値の変更を調整するPRNGのすべての可能なシード値を定期的にローテーションします。ミューテーションファジングでは、特定のシード値でトリガーされたバグを、同じシード値で同じテストを手動で再起動することで再現できるため、機器やデバッガーによる再現性と分析が容易になります。これらの種類のツールは、アプリケーションドメイン、プロトコル構造、およびデータの特性を認識している必要があるため、wolfSSLは、この目的のために作成された2つの主要なファザーを使用します。 wolfFuzzはメモリバッファ上で動作し、内部暗号化操作をファジー化します。このメカニズムにより、非常に高速なファジングが可能になり、4兆個のPRNGシードの全範囲が3か月でテストされます。 2番目のツールであるwolfSSLNetwork Fuzzerは、TCP / IP上で実行されます。このため、移動中のデータのセキュリティを有効にするコードをテストするのははるかに遅くなりますが、より柔軟になります。
脆弱性管理
wolfSSLでは、脆弱性を非常に深刻に受け止めており、開示から36時間以内にソフトウェアの新しいバージョンをリリースすることをコミットしています。これにより、責任ある開示の場合、脆弱性の詳細または再現する概念実証が公開される前に、脆弱性が修正されます。
脆弱性のクレームは、問題の解決と新しいバージョンのリリースをスピードアップするために完了する必要がある標準操作手順（S.O.P.）で構成される緊急手順をトリガーします。脆弱性のクレームは最初の120分以内に確認します。このフェーズでは、問題と問題の再現方法を記したドキュメントを作成してエンジニアリングチームに内部的に配布します。これにより、問題が完全に解決できているかを判断するために、エラーを確認して修正案を評価することを可能にします。問題の複雑さにもよりますが、修正には数分から最大24時間かかる場合があります。修正の準備ができたら内部パッチ、または修正によってwolfSSL Gitリポジトリを監視する攻撃者になる可能性のある人に重要な情報が漏洩しないことが確認された場合はパブリックプルリクエストのいずれかの形式で送信されます。コードの変更は手動のコードレビューとテスト手順の両方で検証されるため、パスまたはパブリックPRは複数のエンジニアによってレビューされます。レビュープロセスループを数回繰り返した後、自動統合サーバーは、必要なすべてのプレリリーステストを実行して修正を検証します。検証の最後に、すべてのテストに合格すると、新しいリリースが発行され、利用可能なすべての通信チャネルを通じてすべてのユーザーと顧客に通知されます。
ご質問は、info@wolfssl.jpまでお問い合わせください。テクニカルサポートについては、support@wolfssl.comにお問い合わせください。
原文:https://www.wolfssl.com/wolfssl-quality-assurance/