BS ISO IEC 23643:2020 pdf free download.Software and systems engineering — Capabilities of software safety and security verification tools.
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 (loT), and general purpose Operating Systems and middleware). Additionally, the number of products and system development cases, where 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.
BS ISO IEC 23643 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?”
1 Scope
BS ISO IEC 23643 specifies requirements for the vendors and gives guidelines for both the users and the developers of software safety and security verification tools. The users of such tools include, but are not limited to, bodies performing verification and software developers who need to be aware and pay attention to safety and/or security of software. BS ISO IEC 23643 guides the verification tool vendors to provide as high-quality products as possible and helps the users to understand the capabilities and characteristics of verification tools.
BS ISO IEC 23643 introduces use cases for software safety and security verification tools and entity relationship model related to them. BS ISO IEC 23643 also introduces tool categories for software safety and security verification tools and gives category specific guidance and requirements for the tool vendors and developers.
2 Normative references
There are no normative references in BS ISO IEC 23643.
3 Terms and definitions
For the purposes of BS ISO IEC 23643, the following terms and definitions apply.
ISO and JEC maintain terminological databases for use in standardization at the following addresses:
all or part of the programs, procedures, rules, and associated documentation of an information processing system
[SOURCE: ISO/IEC 19770-3:2016, 3.1.26, modified — Note 1 to entry has been removed.1
320
software item
identifiable part of a software (3.19) product, consisting of source code, object code, control code, control data, or a collection of these
Note 1 to entry: Software item is a generic term that designates well-identified parts of software source code, object code or data. A software item belongs to a syntactic category of the programming language in which the software is written. Examples are classes, variables, functions and types. A software item is an identifiable part of a software product.
software safety
ability of software (3.19) to be free from unacceptable risk (3.13)
Note 1 to entry: It is the ability of software to resist failure and malfunctions (lU) that can lead to death or serious injury to people, loss or severe damage to property, or severe environmental harm.
Note 2 to entry: Software quality, including software safety, is achieved using software engineering. Software engineering for safety-critical systems (jj..) emphasizes the following directions:
— process engineering and management;
— selecting the appropriate tools and environment for the system; the principle of using the best tools fit to the purpose prevails as in most engineering disciplines;
— adherence to requirements.
By definition the use cases specify a sequence of actions that a system can perform, when interacting with its users (i.e. the actors of the system). In this document, the use cases are defined at a level where the users interact with one or more software safety and security verification tools. Selection of the tools to be used can be made following the processes of ISO/EEC 20741, which introduces the generic process for evaluating and selecting any software engineering tools (see Annex 13).
In BS ISO IEC 23643 the detailed variations for using specific tools are ignored because the purpose of introducing use cases here is not to give specifications for building the tools but to help the readers to understand the environment where the tools are used. For that purpose, the use cases are not presented in any standard format, but rather as usage scenarios, although the term “use caseN is still used.
Actors of software verification are as follows:
— Developers perform the development and verification tasks given in the life-cycle. They produce all intermediate products to be verified. They also perform the validation of the intermediate products and testing, sometimes together with the client.
— Evaluators are verifying and validating the software against some safety or security standard. They are independent from the developers’ tasks, but may belong to the same (15t party) or an independent third-party organization.
— Certification bodies examine the verification results already done, perform further verifications if needed and deliver, if acceptable, a certificate to the software verified. Certification bodies are always third-party organizations (ISO/IEC 17000).
Figure 3 introduces the overview of verification use cases and the actors related to them. Purpose of the verification and the criticality of the TOV are the main differentiators of the use cases. The higher the criticality of the TOV is in terms of safety and security, the more demanding the verification process is, and the more expertise is required from the evaluator(s).