ISO/IEC 23643:2020 ソフトウェアおよびシステムエンジニアリング—ソフトウェアの安全性およびセキュリティ検証ツールの機能 | ページ 3

※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。

導入

数十年以来、ソフトウェアの安全性およびセキュリティ検証ツールの重要性は、いくつかの理由により高まっています。1) ソフトウェア アプリケーションとシステムの複雑さの急速な増大、2) ソフトウェア アプリケーションとシステム間の統合の拡大によるセーフティ クリティカルなシステムの数の増加 (例: 重要インフラストラクチャ)、3) サイバー脅威の数の急速な増加、4) 高および中程度のクリティカル ソフトウェア駆動システム (例: 輸送、エネルギー生産、モノのインターネット (IoT)、および汎用オペレーティング システムなど) における安全性の緊急のニーズ。ミドルウェア)。さらに、オープンソース アプリケーションであってもここで, 増加しているため、安全性とセキュリティの検証と検証 (V&V) が不可欠となっています。

この文書は、その観点をソフトウェアに限定し、コンピューティングおよびその他のハードウェアを文脈から除外します。これらの他の領域では、他の V&V 手法とツールが使用されます。

ソフトウェアの安全性とセキュリティの検証は、必ずしもソフトウェアをコンポーネントとして使用するシステムのシステムの安全性とシステム セキュリティを検証するとは限らないことを認識することが重要です。ただし、検証されていないソフトウェアコンポーネントでシステムが構成されている場合、システムの安全性はいかなるレベルでも保証できません。

継続的なソフトウェア開発とそれに伴うバージョン管理配信を含む「継続的なすべて」には、継続的なソフトウェアの安全性とセキュリティの検証が必要です。新しいバージョンを作成するたびに、V&V をやり直す必要があります。一般的な「アジャイル開発プロセス」では、開発反復を短縮し、より頻繁に製品を提供できるため、従来の開発アプローチよりも頻繁な検証が必要になります。ソフトウェアの安全性やセキュリティが危険にさらされる可能性がある場合は、ソフトウェア開発中およびソフトウェア保守中に検証が必要です。

検証は、「正しい製品を構築しているか?」という質問に答えます。

検証は、「製品を正しく構築しているか?」という質問に答えます。

ソフトウェア検証では、ソフトウェア製品が要件や仕様で定義されている使用目的を満たしているかどうかをチェックします。言い換えれば (ISO/IEC 17029): 「検証の目的は、宣言された情報 (クレーム) が妥当かどうかを確認することです」。ソフトウェア検証では、ソフトウェアを実行する (テスト) か、その成果物 (仕様、モデル、または疑似コード) をレビューすることによって、仕様と要件が満たされているかどうかをチェックします。後者は、そのアーティファクトの 1 つをアニメーション化または静的に分析することで構成できます。 ISO/IEC 17029では、「検証の目的は、宣言された情報(主張)が真実であるかどうかを確認すること」と定義されています。 「テストツール」は既に ISO/IEC 30130 で十分にカバーされており、その主題となっているため、このドキュメントはテストに関するものではなく、成果物のアニメーション化と分析に関するものです。

この文書は、ISO/IEC 20741 で使用される一連の単一ツール機能の 1 つとして作成されています。

この文書では、ソフトウェアの安全性およびセキュリティ検証ツールの機能と要件を定義します。

言語、メソッド、および関連ツールは汎用であり、さまざまな種類の問題に適合できるため、このドキュメントはターゲット アプリケーション ドメインから独立しています (たとえば、機能仕様言語はあらゆる機能プログラムに使用できます)

Introduction

Since a few decades, the importance of software safety and security verification tools has increased for several reasons: 1) rapidly increasing complexity of software applications and systems, 2) increasing number of safety-critical systems through growing integration between software applications and systems (e.g. in critical infrastructures), 3) the rapid increase of the number of cyber threats, and 4) the urgent needs of safety in high and medium critical software-driven systems (e.g. transportation, energy production, Internet of Things (IoT), and general purpose Operating Systems and middleware). Additionally, the number of products and system development cases ここで, the origin of all software components to be used is not exactly known, even for open-source applications, is increasing and thus making safety and security verification and validation (V&V) essential.

This document restricts its point of view to software and excludes computing and any other hardware from the context. In these other domains, other V&V methods and tools are used.

It is important to realize that verification of safety and security of software does not necessarily verify the system safety and system security of a system using the software as a component. However, if a system consists of software components which are not verified, the safety and security of the system cannot be guaranteed at any level.

“Continuous everything”, including continuous software development and thus versioning delivery, requires continuous software safety and security verification. At every new version, V&V needs to be redone. The popular “agile development processes” permit shorter development iterations and more frequent product delivery, and consequently this requires more frequent verification than traditional development approaches. Verification is needed during software development as well as during software maintenance, whenever safety or security of software can be endangered.

Validation answers the question “are we building the right product?”

Verification answers the question “are we building the product right?”

Software validation checks if the software product satisfies the intended use, such as defined in requirements and specifications. In other words (ISO/IEC 17029): “purpose of validation is to find out, whether a declared information (claim) is plausible”. Software verification checks if the specifications and requirements are met either by running the software (testing) or by reviewing its artefacts (specification, model, or pseudo code). The latter can consist of animating or analyzing statically one of its artefacts. ISO/IEC 17029 defines that the “purpose of verification is to find out, whether a declared information (claim) is truthful”. This document does not concern testing but animating and analyzing the artefacts, because “testing tools” is already well covered by and is the subject of ISO/IEC 30130.

This document is prepared as one of the series of single tool capabilities which are used with ISO/IEC 20741.

This document defines capabilities of and requirements for software safety and security verification tools.

This document is independent of the target application domains, as the languages, methods and associated tools are of general purpose, and can fit into different kinds of problems (e.g. functional specification languages can be used for any functional program).