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

3.1

application domain

well-defined set of applications

3.2

capability

quality of being able to perform a given activity

[SOURCE:ISO 19439:2006, 3.5]

3.3

certificate

attestation document issued by an independent third-party certification body

[SOURCE:ISO 22222:2005, 3.2]

3.4

defect

fault, or deviation from the intended level of performance of a system or software (3.19)

3.5

dynamic program analysis

process of evaluating a software (3.19) system or component based on its behaviour during execution

Note 1 to entry: The definition means that the software shall actually be compiled and run on a certain number of input data test cases. The physical response from the system is then examined and compared to expected results. Dynamic program analysis can be done manually or using an automated process. The results are examined either manually (e.g. with small input test data) or automatically using oracles.

3.6

entity

data concept that may have attributes and relationships to other entities

[SOURCE:ISO/TR 25100:2012, 2.1.3, modified — Note 1 to entry has been removed.]

3.7

evaluator

competent person engaged in the verification (3.33) or validation (3.32) of a system or software (3.19)

3.8

false negative

true defect (3.4) that has not been observed

Note 1 to entry: The term is used for analysis tools producing defect information during the analysis of an application. In the presence of false negatives, the tool is said to be incomplete with respect to the real set of defects in the software (3.19) under analysis. False negatives can be due to several reasons such as 1) the use of heuristics for detecting defects, 2) too restrictive analysis data.

3.9

false positive

observed defect (3.4) which does not correspond to a true defect

Note 1 to entry: The term is used for analysis tools producing defect information during the analysis of an application. False positives appear during the analysis because of several possible reasons, such as lack of precision of the analysis rules.

3.10

formal verification

activity proving or disproving the correctness of intended applications with respect to a formal specification or a property, using formal methods of mathematics

3.11

malfunction

behaviour of a system or component that deviates from the specifications

3.12

protection

process to secure content

[SOURCE:ISO/IEC 15444-8:2007, 3.24]

3.13

risk

effect of uncertainty on objectives

Note 1 to entry: ISO 22538-4 defines risk as “probability of loss or injury from a hazard”.

[SOURCE:ISO 31000:2018, 3.1, modified — Notes 1, 2 and 3 to entry have been removed; a new Note 1 to entry has been added.]

3.14

safety

freedom from unacceptable risk (3.13)

3.15

safety-critical system

3.16

security

resistance to intentional, unauthorized act(s) designed to cause harm or damage to a system

3.17

security level

combination of a hierarchical security (3.16) classification and a security category that represents the sensitivity of an object or the security clearance of an individual

Note 1 to entry: The minimum security level is an indication of the minimum protection (3.12) required.

3.18

semi-formal verification

method that is based on a description given in semi-formal notation

3.19

software

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.]

3.20

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.

3.21

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 (3.11) that can lead to death or serious injury to people, loss or severe damage to property, or severe environmental harm.

3.22

software security

ability of software (3.19) to protect its assets from a malicious attacker

Note 1 to entry: According to software product quality model in ISO/IEC 25010, software security applies to software assets and is decomposed into the following set of properties: confidentiality, integrity, availability, authentication, authorization and non-repudiation.

3.23

software unit

smallest independent piece of software (3.19) , which can be independently translated, and which can be tested with the relevant data on whether it performs to specification

3.24

static program analysis

sub-field of formal methods concerned by analyzing the properties of a software (3.19) code without executing this code in the target (binary) format

3.25

system safety

ability of a system to be free from unacceptable risk (3.13)

Note 1 to entry: A system is defined as a set or group of interacting, interrelated or interdependent elements or parts, that are organized and integrated to form a collective unity or a unified whole, to achieve a common objective. In a broader view the definition of a system consists in the hardware, software (3.19) , human systems integration, procedures and training. Therefore, system safety is part of the systems engineering process and should systematically address all of these domains and areas in engineering and operations in a concerted fashion to prevent, eliminate and control hazards.

Note 2 to entry: A system safety concept helps the system designer(s) to model, analyze, gain awareness about, understand and eliminate the hazards, and apply controls to achieve an acceptable level of safety (3.14) . The systems-based approach to safety requires the application of scientific, technical and managerial skills to hazard identification, hazard analysis, and elimination, control, or management of hazards throughout the life-cycle of a system, program, project or an activity or a product. Hazop is one of several techniques available for the identification of hazards.

3.26

target of verification

TOV

software (3.19) , or a set of software items (3.20) or units (3.23) , to be verified (e.g. in terms of safety (3.14) and security (3.16) )

Note 1 to entry: Target of evaluation (TOE) is a commonly used term in systems security techniques. TOE is defined as a set of software, firmware and/or hardware possibly accompanied by guidance.

3.27

target software

final product of a software (3.19) development process, containing at least the binary code able to run on the target computer

Note 1 to entry: Target software may consist of several files, including binary and source files, libraries, installation and compilation script files, documentation and data files. The target software often relies on underlying layers of software, that are not part of the target software, but that are necessary to be executed on the target platform, for instance libraries.

3.28

target system

complete computing platform capable of running the target software (3.27)

Note 1 to entry: A target system consists of hardware resources and software (3.19) resources installed on the hardware.

3.29

toolbox

set of tools completing each other in terms of capabilities, to cover a larger area of their intended use

3.30

trust

degree to which a user or other stakeholder has confidence that a product or system will behave as intended

[SOURCE:ISO/IEC 25010:2011, 4.1.3.2]

3.31

use case

specification of a sequence of actions, including variants, that a system (or other entity (3.6) ) can perform, interacting with actors of the system

[SOURCE:ISO 15745-1:2003, 3.35, modified — The domain"<class>" at the beginning and"[UML]" at the end of the definition has been removed.]

3.32

validation

confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled

[SOURCE:ISO/IEC 25000:2014, 4.41, modified — Note 1 to entry have been removed; EXAMPLE has been added.]

3.33

verification

confirmation, through the provision of objective evidence, that specified requirements have been fulfilled

[SOURCE:ISO/IEC 25000:2014, 4.43, modified — Note 1 to entry have been removed.]

3.34

verification method

method for producing objective evidence that specified requirements of a system have been fulfilled

3.35

verification tool

instrument that can be used during verification (3.33) to collect information about the target of verification (3.26) , to perform interpretation of information or to automate part of the verification

3.36

vulnerability

potential flaw or weakness in software (3.19) design or implementation that could be exercised (accidentally triggered or intentionally exploited) and result in harm to the system

Note 1 to entry: The CVE classification (see Reference [25]) defines the de-facto standard classes of the known software vulnerabilities.

Note 2 to entry: A vulnerability is exploitable if it can be activated in practice.