ソフトウェア監査レビュー

ソフトウェア監査レビュー、またはソフトウェア監査は、ソフトウェア開発組織のメンバーではない1人以上の監査人が「仕様、標準、契約上の合意、またはその他の基準への準拠を評価するために、ソフトウェア製品、ソフトウェアプロセス、またはソフトウェアプロセスセットを独立して検査する」ソフトウェアレビューの一種です。^[1]

「ソフトウェア製品」とは、ほとんどの場合、何らかの技術文書を指しますが、これに限定されるわけではありません。IEEE Std. 1028 ^{[2]では、32 の「監査対象となる}ソフトウェア製品の例」のリストが提供されています。これには、さまざまな種類の計画、契約、仕様、設計、手順、標準、レポートなどの文書製品だけでなく、データ、テスト データ、配信可能なメディアなどの非文書製品も含まれます。

ソフトウェア監査は、ソフトウェア開発組織の外部の独立した担当者によって実施され、技術的な内容、技術的な品質、または管理上の意味ではなく、製品またはプロセスのコンプライアンスに関係するという点で、ソフトウェアピアレビューやソフトウェア管理レビューとは異なります。

ここで「ソフトウェア監査レビュー」という用語は、IEEE Std. 1028 で説明されているソフトウェア監査の形式を指定するために採用されています。

「ソフトウェア監査の目的は、ソフトウェア製品とプロセスが適用される規制、標準、ガイドライン、計画、および手順に準拠しているかどうかを独立して評価することです。」^[3] 以下の役割が推奨されます。

• イニシエーター（監査対象組織のマネージャー、監査対象組織の顧客またはユーザー代表、または第三者）は、監査の必要性を決定し、監査の目的と範囲を確立し、評価基準を指定し、監査担当者を特定し、必要なフォローアップ アクションを決定し、監査レポートを配布します。
• 主任監査人（「独立した客観的な評価を行う能力を低下させる可能性のある偏見や影響から自由な」人物でなければなりません）は、監査計画の作成、監査チームの編成と管理、および監査が目的を達成していることの確認などの管理タスクを担当します。
• レコーダーは、監査チームによって行われた異常、アクション項目、決定、推奨事項を記録します。
• 監査人(主任監査人と同様に偏見がないことが必要) は、監査計画で定義された製品を検査し、観察結果を文書化し、是正措置を推奨します。 (監査人は 1 人だけの場合もあります。)
• 監査対象組織は監査人と連絡を取り、監査人が要求するすべての情報を提供します。監査が完了したら、監査対象組織は是正措置と推奨事項を実施する必要があります。

監査の以下の原則を反映させるべきである: ^[4]

• 適時性:プロセスとプログラミングが、障害や弱点に対する潜在的な脆弱性に関して継続的に検査されるだけでなく、発見された強みの分析の継続、または類似のアプリケーションとの比較機能分析によってのみ、更新されたフレームを継続できます。
• ソースのオープン性:暗号化プログラムの監査では、オープン ソースの取り扱いをどのように理解すべきかを明確に示す必要があります。たとえば、オープン ソース アプリケーションを提供しているが、IM サーバーをオープン ソースとして扱っていないプログラムは、批判的に考える必要があります。監査人は、暗号アプリケーション内でのオープン ソース性の必要性というパラダイムに対して独自の立場を取る必要があります。
• 綿密さ:監査プロセスは、一定の最低基準を指向する必要があります。最近の暗号化ソフトウェアの監査プロセスは、品質、範囲、有効性、メディアの受け止め方の経験において大きく異なることが多く、認識が異なる場合があります。一方ではプログラミング コードを読み取るための特別な知識が必要であり、他方では暗号化手順の知識も必要であるため、多くのユーザーは、正式な確認の最も短い声明さえ信頼しています。したがって、監査人としての個々のコミットメント (品質、規模、有効性など) は、自分自身で反射的に評価し、監査内で文書化する必要があります。

• 財務状況:ソフトウェアが商業的に開発されたかどうか、監査が商業的に資金提供されたかどうか (監査費用は有料) を明らかにするために、さらなる透明性が必要です。個人の趣味やコミュニティ プロジェクトなのか、営利企業が背後にいるのかによって違いが生じます。
• 学習の観点の科学的参照:各監査では、コンテキスト内での調査結果を詳細に記述し、進捗と開発のニーズを建設的に強調する必要があります。監査人はプログラムの親ではありませんが、監査人が PDCA 学習サイクル ( PDCA = 計画、実行、確認、改善) の一部と見なされる場合は、メンターの役割を果たします。検出された脆弱性の説明の横に、革新的な機会と潜在能力の開発の説明も記載する必要があります。
• 文献の組み込み:読者は、1 つのレビューの結果だけに頼るのではなく、管理システムのループ (例: PDCA、上記を参照) に従って判断し、開発チームまたはレビュー担当者がさらなる分析を実行する準備ができていること、また開発およびレビューのプロセスで学習に積極的に取り組み、他の人のメモを考慮することを確認する必要があります。監査のたびに、参考文献のリストを添付する必要があります。
• ユーザーマニュアルとドキュメントの組み込み:さらに、マニュアルと技術ドキュメントが存在するかどうか、また、これらが拡張されているかどうかも確認する必要があります。
• イノベーションへの言及を特定する:オフラインとオンラインの両方の連絡先にメッセージを送信できるアプリケーション (GoldBug の場合もそうですが) は、チャットと電子メールを 1 つのアプリケーションで考慮し、高い優先度でテストする必要があります (電子メール機能に加えてプレゼンス チャットの基準)。監査人は、イノベーションへの言及も強調し、さらなる研究開発のニーズを裏付ける必要があります。

この暗号アプリケーションの監査原則のリストは、技術的な分析方法を超えて、特に考慮すべきコアバリューについて説明しています。

ソフトウェア監査の一部は、アプリケーション コードを分析し、標準、ガイドライン、ベスト プラクティスへの準拠を評価する静的分析ツールを使用して実行できます。静的コード分析ツールのリストには、コードからアーキテクチャのレビューまで非常に広範囲をカバーしているものもあり、ベンチマークに使用できます。