ISO/SAE TR 8477:2026

Technical
Report
ISO/SAE TR 8477
First edition
Road vehicles — Cybersecurity
2026-11
verification and validation
Véhicules routiers — Vérification et validation de la cybersécurité
Reference number
© ISO/SAE International 2026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may be
reproduced, or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO or SAE International at
the respective address below or ISO’s member body in the country of the requester.
ISO copyright office SAE International
CP 401 • Ch. de Blandonnet 8 400 Commonwealth Dr.
CH-1214 Vernier, Geneva Warrendale, PA, USA 15096
Phone: +41 22 749 01 11 Phone: 877-606-7323 (inside USA and Canada)
Phone: +1 724-776-4970 (outside USA)
Fax: 724-776-0790
Email: copyright@iso.org Email: CustomerService@sae.org
Website: www.iso.org Website: www.sae.org
Published in Switzerland by ISO, published in the USA by SAE International

© ISO/SAE International 2026 – All rights reserved
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 1
3.1 Terms and definitions .1
3.2 Abbreviated terms .1
4 Verification and validation (V&V) in the context of cybersecurity . 1
4.1 General .1
4.2 Conceptual cybersecurity requirements .3
4.3 Difference between verification and validation (V&V) .3
4.3.1 Relation to the levels of the requirements hierarchy .3
4.3.2 Relation to layers of the architecture .4
4.4 Logical sequence of activities .6
4.5 Functional and non-functional properties .7
4.6 Relation with TARA .7
4.7 Impact of refinement on V&V work products .8
4.8 Assumptions .9
4.9 Relation to types of development .10
4.9.1 General .10
4.9.2 Use of an existing component .10
4.9.3 Out-of-context development .10
4.9.4 Component off-the-shelf .10
5 Verification and validation (V&V) strategy and planning .11
5.1 Strategy .11
5.2 Planning .11
6 Method Groups .13
6.1 General . 13
6.2 Review . 13
6.3 Analysis . 13
6.4 Formal method . 13
6.5 Code analysis .14
6.6 Functional testing .14
6.7 Vulnerability scanning . 15
6.8 Fuzz testing . 15
6.9 Stress testing .16
6.10 Fault injection .16
6.11 Penetration testing .17
6.12 Cryptographic testing .17
7 Examples of applications of methods.18
8 Verification and validation (V&V) reporting .21
8.1 General .21
8.2 Instances of verification reporting. 22
8.3 Instances of validation reporting . 23
Annex A (informative) Difference with cybersecurity assessment .26
Bibliography .28

© ISO/SAE International 2026 – All rights reserved
iii
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
SAE International is a global association of more than 128,000 engineers and related technical experts in
the aerospace, automotive and commercial-vehicle industries. Standards from SAE International are used to
advance mobility engineering throughout the world. The SAE Technical Standards Development Program is
among the organization's primary provisions to those mobility industries it serves aerospace, automotive,
and commercial vehicle. These works are authorized, revised, and maintained by the volunteer efforts of
more than 9,000 engineers, and other qualified professionals from around the world. SAE subject matter
experts act as individuals in the standards process, not as representatives of their organizations. Thus, SAE
standards represent optimal technical content developed in a transparent, open, and collaborative process.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1 and the SAE Executive Standards Committee Policy. In
particular, the different approval criteria needed for the different types of ISO documents should be noted.
This document was drafted in accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see
www.iso.org/directives).
ISO and SAE draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and SAE take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and SAE had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents. ISO and SAE shall not be held responsible for identifying any or
all such patent rights.
SAE Executive Standards Committee Rules provide that: “This document is published to advance the state
of technical and engineering sciences. The use of this document is entirely voluntary, and its applicability
and suitability for any particular use, including any patent infringement arising therefrom, is the sole
responsibility of the user.”
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was jointly prepared by Technical Committee ISO/TC 22, Road Vehicles, Subcommittee SC
32, Electrical and electronic components and general system aspects, and SAE Committee SAE TEVEES18A,
Vehicle Cybersecurity Systems Engineering Committee.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html. Alternatively, to provide
feedback on this document, please visit http://standards.sae.org/PRODCODE.

© ISO/SAE International 2026 – All rights reserved
iv
Introduction
This document elaborates on verification and validation (V&V) of the cybersecurity of items and components
[1]
of road vehicles in accordance with ISO/SAE 21434 . It provides considerations on:
— V&V strategy;
— methods that can be applied;
— distribution of activities between customer and supplier;
— logical sequence of activities.
The objectives are different between V&V; however, both can use identical or similar methods.
The choice of methods and the extent of the rigour with which they are applied are part of a project- and
organization-specific strategy. This document focuses on strategy and does not prescribe methods.
V&V are part of development of an item or component and involve multiple activities, including repeating
(e.g. iteration or feedback loop) or complementing activities.

© ISO/SAE International 2026 – All rights reserved
v
Technical Report ISO/SAE TR 8477:2026(en)
Road vehicles — Cybersecurity verification and validation
1 Scope
This document provides considerations on the planning and execution of verification and validation (V&V)
[1]
of the cybersecurity of items and components of road vehicles, in the context of ISO/SAE 21434 .
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/SAE 21434, Road vehicles — Cybersecurity engineering
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/SAE 21434 apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.2 Abbreviated terms
CAN controller area network
CS cybersecurity
CVSS common vulnerability scoring system
CWE common weakness enumeration
E/E electric / electronic
ECU electronic control unit
PIN personal identification number
TARA threat analysis and risk assessment
V&V verification and validation
4 Verification and validation (V&V) in the context of cybersecurity
4.1 General
[1]
This clause provides an overview of V&V in the context of cybersecurity, elaborating on ISO/SAE 21434 .

© ISO/SAE International 2026 – All rights reserved
Verification in cybersecurity addresses whether the architecture and design of an item or component satisfy
the cybersecurity requirements. In general, it answers the question “are we building the cybersecurity of
the item or component right?” Verification results can be an input to validation.
Validation in cybersecurity addresses whether an item is appropriately and sufficiently cybersecure.
In general, it answers the question “are we building the right item regarding cybersecurity?” Validation
applies to the item integrated in the target vehicle, considering the interfaces of the item, its operational
environment and threat scenarios.
[2]
See also IEC 60050-192:2015 , 192-01-17 and 192-01-18.
Figure 1 and Figure 2, respectively, provide examples of V&V activities. These figures are not intended to
[3]
be exhaustive – not all relevant work products of ISO/SAE 21434:2021 are included, nor are all relevant
activities.
Key
work product (WP)
part of WP / other
activity
verify / validate
V&V input
Figure 1 — Examples of verification activities

© ISO/SAE International 2026 – All rights reserved
Key
work product
part of WP / other
activity
verify / validate
V&V input
Figure 2 — Examples of validation activities
V&V activities can be performed by a customer, a supplier or other parties, according to the cybersecurity
interface agreement. This agreement includes information exchange, such that each party is able to fulfil
corresponding responsibilities.
V&V provide evidence that can be judged in a cybersecurity assessment, see Annex A.
4.2 Conceptual cybersecurity requirements
The term “conceptual cybersecurity requirement” – meaning “cybersecurity requirement directly derived
from a cybersecurity goal” – is used in this document to facilitate elaborating validation. For reference,
[3]
ISO/SAE 21434:2021 , 3.1.36, defines cybersecurity validation as confirmation of only the adequacy and
achievement of the cybersecurity goals of the item, and effectiveness of cybersecurity controls in preventing
or mitigating risk associated with threat scenarios.
[3]
The work product “cybersecurity concept” (see ISO/SAE 21434:2021 , 3.1.13) includes these conceptual
cybersecurity requirements, as well as their allocation.
[3]
The work product “cybersecurity specification” (see ISO/SAE 21434:2021 , 3.1.21) includes the
cybersecurity requirements associated with lower levels of the requirements hierarchy, as well as the
corresponding architectural design.
4.3 Difference between verification and validation (V&V)
4.3.1 Relation to the levels of the requirements hierarchy
Verification relates to any level of the requirements hierarchy.

© ISO/SAE International 2026 – All rights reserved
Validation relates to the highest level of the requirements hierarchy, i.e. validation relates to:
— cybersecurity goals;
— conceptual cybersecurity requirements;
— requirements allocated to the operational environment;
— assumptions that influence the derivation of cybersecurity goals or conceptual cybersecurity
requirements, including assumptions concerning the operational environment;
NOTE A supplier developing a component can make assumptions that concern the item level and makes these
available to the customer.
— cybersecurity claims.
Figure 3 illustrates the relation of V&V to the requirements hierarchy.
Figure 3 — Verification, validation and relation to the requirements hierarchy
4.3.2 Relation to layers of the architecture
An item or component can include multiple layers of architectural abstraction. Figure 4 illustrates how
cybersecurity requirements can be allocated to different architectural layers.

© ISO/SAE International 2026 – All rights reserved
Figure 4 — Cybersecurity requirement allocation to architectural layers
A weakness or vulnerability can exist in any layer of the architecture and thus violate cybersecurity
requirements allocated to that layer (and ultimately violate the corresponding cybersecurity goals).
Accordingly, both V&V can relate to any layer of the architecture:
— At any architectural layer, verification can be performed against artefacts such as cybersecurity
requirements, architectural design or implementation, based on a strategy (see Clause 5);
— Validation can relate to any layer of the architecture, as any layer can ultimately bring about a violation of a
cybersecurity goal or a conceptual cybersecurity requirement. At higher architectural layers, validation
can be performed against cybersecurity controls that are not detailed enough to be fully implemented
(i.e. not “buildable”) and cybersecurity claims.
Figure 5 further illustrates the relation between cybersecurity work products, levels of the requirements
hierarchy and architectural layers considering V&V activities. All references in Figure 5 relate to
[3] [3]
ISO/SAE 21434:2021 , e.g. work product ISO/SAE 21434:2021 , [WP-09-01].

© ISO/SAE International 2026 – All rights reserved
Key
work product
part of WP / other
activity
requirements, design interaction
requirements hierarchy
verify / validate
V&V inputs
Figure 5 — Relation of V&V activities to requirement hierarchy levels and architectural layers
4.4 Logical sequence of activities
V&V can range from early to late development activities. A cybersecurity activity can be performed as soon
as the corresponding inputs are available. Doing so is beneficial for V&V, as it facilitates addressing findings
earlier. The later a finding is uncovered, the more difficult it can be to address. For example, a finding of an
opportunity for abuse – it can be difficult to address this finding if that involves modifying functionality late
in development.
Accordingly, a validation activity:
— can be started based on preliminary results, e.g. threat scenarios and cybersecurity goals can be
identified based on preliminary architectural design in conjunction with preliminary TARA results. This
input can be sufficient to start some, but not all, validation activities;

© ISO/SAE International 2026 – All rights reserved
— can be updated at any time during development. Early validation evidence can be re-affirmed, or enriched,
later, e.g. when a prototype or final TARA results become available;
— is concluded before the release for post-development.
If early validation results do not invalidate cybersecurity goals, it is an indicator of an appropriately and
sufficiently cybersecure item and components.
4.5 Functional and non-functional properties
V&V considers:
— functional properties, i.e. relating to the behaviour of an item or component. For example, confirmation
of wanted behaviour or the absence of unwanted behaviour;
— non-functional properties relied upon. For example, a processing load limit. Verification can uncover that
a property relied upon is not (e.g. oversight), or no longer (e.g. design evolution without proper change
management) implemented.
4.6 Relation with TARA
This subclause elaborates on the relation between TARA activities and V&V activities.
If the TARA relies on properties associated with the item (e.g. a cybersecurity control implemented by the
design) or on assumptions, it is validated that:
— those properties on which TARA relies are indeed implemented;
— the credit the TARA takes from them is valid, e.g. that a cybersecurity control relied upon is as effective
as expected in the TARA;
— assumptions made are valid.
Figure 6 illustrates the TARA relying on item properties and how that relates to other cybersecurity
activities.
© ISO/SAE International 2026 – All rights reserved
Key
flow of activities
remark concerning interaction between work products
Figure 6 — Relation between TARA and other cybersecurity activities
Examples of reliance of TARA on properties associated with an item and corresponding validation:
— attack feasibility rating relying on a secure boot. If the secure boot is not implemented, or if its design is
not as effective as expected by the risk assessment, the claimed attack feasibility rating is invalid;
— attack feasibility rating relying on procedures defined in a post-development manual. If that manual
does not actually contain such information, or if the defined procedures are ineffective, the claimed
attack feasibility rating is invalid;
— risk assessment relying on a cybersecurity control implemented external to the item (this can be specified
as a requirement on the operational environment or expressed as an assumption on the operational
environment).
For more examples, see Clause 7.
Such properties, and corresponding expectations, relied upon in the TARA can be shared with a supplier,
such that the supplier is able to provide supporting evidence to the customer.
4.7 Impact of refinement on V&V work products
[1]
Cybersecurity engineering involves maintaining the work products of ISO/SAE 21434 (see
[3]
ISO/SAE 21434:2021 , [RQ-06-09]), including maintaining consistency between them. This can involve an
update of V&V work products. An update of a work product typically occurs within an organization. A frozen
baseline of work products is expected at handover between customer and supplier. However, a supplier or
customer can identify a finding after handover that affects the other party.
Maintaining the consistency between work products can be supported by change management and
configuration management.
© ISO/SAE International 2026 – All rights reserved
An update of one or more work products can be triggered by:
a) a finding (e.g. uncovered by V&V activities);
NOTE 1 A finding is analysed. Based on the results of this analysis, the finding is managed to closure.
b) a change of the item or of one of its components (e.g. due to an update or to address a finding);
NOTE 2 If a change is planned to an item or component, the impact on the other work products is analysed and
those are updated, if applicable. The update of the V&V activities considers all other updated work products.
c) a refinement of a work product (e.g. architectural design refined into a more detailed layer) as
cybersecurity engineering can be incremental.
NOTE 3 A refinement can trigger an update of other work products, such as:
— the TARA, to identify new opportunities for attack (e.g. a threat scenario that a preliminary TARA based on a
preliminary architecture was not able to identify) or to more accurately assess a risk parameter;
— verification work products, as refining the architecture enables refinement of the cybersecurity requirements;
— validation work products to confirm that the (refined) design achieves the intended effects (according to the
conceptual cybersecurity requirements) and does not introduce unintended consequences, such as opportunities
for abuse by attackers.
EXAMPLE Activities triggering updates
Activity Relating to Detail
1 Preliminary threat Threat scenario A A design solution for meeting the cybersecurity requirements
analysis (addressing threat scenario “A”) is not yet specified
2 Design increment Implementation of cyber- Implementation of a PIN code
security requirements
addressing threat scenario A
into design
3 Preliminary threat Update of threat analysis, Update uncovers that the PIN code implementation provides
analysis considering PIN code imple- an opportunity for abuse (i.e. inducing PIN entries) as part of a
mentation new attack path to provoke known threat scenario “B”
4 Preliminary risk Update of risk assessment Considering the new attack path (exploiting the opportunity
assessment regarding threat scenario B, for abuse), the risk associated with threat scenario B is not
considering new attack path accepted
5 Design increment Address unreasonable risk Potential for abuse is addressed by implementing a PIN rate
associated with scenario B limit
6 Validation incre- Uncovered opportunity for Confirm that the identified opportunity for abuse is adequate-
ment abuse ly addressed by the updated design
4.8 Assumptions
Any work product can rely on assumptions. These assumptions are explicitly documented in the
[1]
corresponding work product (see work products defined in ISO/SAE 21434 ) and subject to verification or
validation.
Assumptions that influence the derivation of cybersecurity goals or conceptual cybersecurity requirements,
including assumptions concerning the operational environment are validated. Other assumptions, e.g.
related to development out-of-context, can be verified.
Assumptions can relate to, for example, attack feasibility rating, impact rating, the vehicle, another item, a
cybersecurity control external to the vehicle, human behaviour, the operational environment, or measures
not implemented by E/E. For examples of validation of such assumptions, see Clause 7.
An assumption can be made explicit at any time, e.g. during testing.

© ISO/SAE International 2026 – All rights reserved
Both the design properties and validation of assumptions relied upon during cybersecurity engineering
can be in the scope of disciplines other than cybersecurity. Accordingly, cybersecurity validation can be
concerned only with obtaining the results of validation by the other disciplines, and not the generation of
such evidence.
4.9 Relation to types of development
4.9.1 General
Reuse and out-of-context development are not mutually exclusive, i.e. a component developed out-of-context
[3]
can be a new development or a reuse. See also ISO/SAE 21434:2021 , 6.4.4, 6.4.5 and 6.4.6.
4.9.2 Use of an existing component
The reuse of an existing item or component involves an analysis of their suitability. This can include
identifying whether existing work products are sufficient to support reuse. This can apply to a component
[1]
not developed according to ISO/SAE 21434 , such as a legacy component or an off-the-shelf component not
specifically developed for automotive application.
For example, a V&V strategy (see Clause 5) for a component with insufficient V&V evidence, and for which
the design cannot be inspected, can address the lack of provided evidence by:
— specifying test cases and test methods with a blackbox approach to confirm that the threat scenarios are
addressed;
— substituting missing evidence (e.g. identified by performing a gap analysis) with results from
[3]
cybersecurity monitoring of that component or of a similar component (see ISO/SAE 21434:2021 ,
Clause 8); and
— inspection of the specified configurations of the reused component to confirm it operates as intended for
the threat scenarios.
The analysis for reuse also includes analysing the impact of any change made to the item, component or
the operational environment, such as the impact on existing V&V work products. To address changes,
supplemental V&V activities can be planned, e.g. regression analysis or regression test.
4.9.3 Out-of-context development
An out-of-context development can be based on assumptions, relating to:
— the expected context in which a potential customer intends to use that component, e.g. use conditions;
— expected cybersecurity goals, conceptual cybersecurity requirements or other cybersecurity
requirements, i.e. those that a supplier anticipates will be specified and allocated (by a potential
customer) to the component developed out-of-context.
Such assumptions are documented in the corresponding work products. Verification can be performed
against assumed requirements and can be considered as equivalent to verification against agreed
requirements.
If a customer plans to use a component developed out-of-context, it is integrated into context. If corresponding
cybersecurity activities are distributed, these are specified in a cybersecurity interface agreement. V&V
includes confirming the assumptions made by the supplier. If an assumption is not valid, customer and
supplier jointly agree on how to address this.
4.9.4 Component off-the-shelf
An off-the-shelf development is a development without an interface agreement. Even if there is no interface
regarding the development of a component off-the-shelf, a cybersecurity interface agreement regarding
post-development can be pertinent, e.g. regarding cybersecurity monitoring. A vendor of an off-the-shelf

© ISO/SAE International 2026 – All rights reserved
component can make relevant documentation available for verification or validation activities performed by
the customer.
5 Verification and validation (V&V) strategy and planning
5.1 Strategy
A V&V strategy provides a framework for how corresponding activities can be planned and executed. A
strategy can be item- or component-specific.
A strategy can rely on supplier evidence. For example, activities addressing an attack path can rely on
evidence provided by a supplier, as part of a strategy addressing all attack paths. In this case, the customer
provides the information that enables the supplier to generate that evidence.
A strategy can include, for example:
a) identification of the item or component(s) in scope and their interfaces;
b) definition of what the corresponding activities intend to establish;
c) selection of methods and the rationale for their selection;
EXAMPLE 1 Rationale can be based on one or more of the following:
[4]
— cybersecurity assurance level (see ISO/SAE PAS 8475 ),
— argument as to why the set of selected methods minimizes the possibility of unidentified vulnerabilities remaining,
— corresponding vulnerabilities already being covered by the same method performed at a higher architectural
layer (such that a specific testing method can be omitted at lower architectural layers when multiple architectural
layers are considered together), or
— organizational rules and guidelines, such as criteria applied across items or components developed by the
organization, or a trustful procedure (internal to the organization or between customer and supplier).
EXAMPLE 2 Trustful procedure can be based on one or more of the following:
[5]
— a common code of conduct for security testing, such as CREST – Codes of Conduct , Open Worldwide Application
[6] [7]
Security Project – Code of Conduct , International Software Testing Qualifications Board Code of Ethics ;
[8] [9] [10]
— a coordinated disclosure process (see ISO/IEC 29147 , ISO/IEC TR 5895 , policymaker.disclose.io , CMU
[11]
CERT/CC – Vulnerability Disclosure Policy Templates ).
d) reference to a cybersecurity plan and to corresponding cybersecurity interface agreements.
5.2 Planning
[3]
A cybersecurity plan (see ISO/SAE 21434:2021 , 6.4.2) includes the planning of the V&V activities. It can
include, for example:
a) specification of activities;
EXAMPLE 1
— identification of methods or test design techniques;
— level of integration, e.g. unit test;
— test cases;
— test coverage;
— testing environment.
© ISO/SAE International 2026 – All rights reserved
b) responsibilities for activities;
c) timeline;
NOTE V&V activities can be performed concurrently to be able to make appropriate decisions early in
development.
d) criteria for performing activities;
EXAMPLE 2
— entry criteria (conditions for being able to start an activity), such as readiness of a subject under test, availability
of documents, test cases, environment or tools;
— exit criteria (conditions for being able to consider an activity as completed), such as method only considered as
completed if all corresponding test cases have been examined;
— repetition criteria, such as criteria for retesting or regression testing.
e) pass/fail criteria for the results;
f) prioritization of activities (to support “shifting left”);
EXAMPLE 3
— verification of cybersecurity controls that are difficult to change late during development;
— validation of conceptual cybersecurity requirements to confirm that they do not provide a potential for abuse,
such as those implemented by secure boot, over-the-air update client, immobilizer PIN code.
g) coordination between cybersecurity activities;
EXAMPLE 4 Coordination between TARA activities and validation activities.
h) communication channels and frequency;
i) management of findings regarding the item or component, or deviations from the plan;
j) planning of distributed activities;
EXAMPLE 5 Agreement on:
— how activities are distributed among involved parties;
— testing scope;
— communication, including trustful communication (see 5.1, Example 2);
— making work products available;
— how to address findings, or deviations from the plan, identified by customer or supplier.
k) management of automation in the activities.
Existing experience can be considered in a strategy, or in planning, to optimize efforts. In particular, existing
experience allows to focus resources on new or especially relevant aspects of cybersecurity controls in the
context of the item or component. For example, existing knowledge regarding cybersecurity controls can be
used as an input to define test cases and test specifications.
Example of an excerpt of a cybersecurity plan:
— obtain a bill of materials as an input;
— identify known vulnerabilities based on bill of materials;
— perform a vulnerability scan;

© ISO/SAE International 2026 – All rights reserved
— cross-check the results against identified vulnerabilities;
— test with proof-of-concept exploits.
6 Method Groups
6.1 General
This clause provides an overview of method groups that can be selected in a strategy for verification or
validation. This document provides no recommendations for or against any particular method or method
group. The strategy can select methods not included in this clause.
[12]
More methods and specific details can be found in other documents, e.g. SAE J3322 .
The method groups listed in this subclause are not intended to be exhaustive, nor are the groups meant to be
strict categorizations (i.e. methods can be found in multiples of these groups).
Any method can be supported by a checklist.
6.2 Review
A review is a process or meeting during which artefacts are examined for comment or approval. Reviews
can provide evidence to support V&V. In this context, the term artefact can refer to any deliverable of a
development activity. For example, agreements, project plans and budgets, requirements, specifications,
designs, concepts, source code, user documentation, support and maintenance documentation, test plans,
test specifications, standards.
[13]
For more specific information regarding review, refer to SAE J3322: 2025 , 17.89.
Walkthrough and inspection are types of review:
a) Inspection is a formal review of a work product to identify issues, which uses defined team roles and
[14]
measurement to improve the review process (see ISO/IEC 20246:2017 , Annex D).
b) Walkthrough is a formal review in which an author leads members of the review through a work product
and the participants ask questions and make comments about possible issues (see ISO/IEC 20246:2017
[14]
, Annex D).
6.3 Analysis
Analysis involves the use of analytical techniques. Analysis can have specific purposes e.g. code analysis
(see 6.5), design analysis, requirements feasibility analysis, vulnerability analysis.
[13]
For more specific information regarding analysis, refer to SAE J3322: 2025 , 17.86, 17.87 and 17.88.
6.4 Formal method
Formal methods can provide a “mathematical proof” that software is correct, as all execution paths are
considered, which can prove the absence of certain software bug classes. For example, formal methods can
be used during verification to prove or disprove the correctness of an algorithm. A mathematical model
of the system is created (e.g. a finite state machine) and by using exhaustive exploration the model is
verified. Formal methods can provide an exhaustive exploration of the system being analysed, providing
completeness where scenario-based testing would not.
Formal verification can also be applied to prove cybersecurity requirements or properties in digital design.
The feasibility of a formal method can be limited to relatively simple components due to its intensive and
time-consuming nature.
It is possible that a formal proof is invalid, e.g. due to an incomplete specification.

© ISO/SAE International 2026 – All rights reserved
Abstract interpretation is a type of formal method.
[13]
For more specific information regarding formal methods, refer to SAE J3322: 2025 , 17.5.
6.5 Code analysis
Code analysis can include analysis of compiled code (e.g. binary code) or source code. This can highlight
[12]
poor coding practices or coding errors. Code analysis is defined in SAE J3322 as “analysis of source
code carried out without execution of that software.” Reviews can be used as a code analysis activity (see
[15]
ISO/IEC/IEEE 29119-4 ), but commonly code analysis refers to tool supported analysis of a software
implementation.
Code analysis is a collection of review techniques and automated source code analysis algorithms to identify
vulnerabilities or, if formal methods are used, to prove the absence of certain bug classes. Algorithms and
tools that prove the absence of weaknesses are called sound, i.e. they provide a logically stringent argument
that a certain error cannot occur. Algorithms and tools that are just able to detect vulnerabilities are called
unsound.
[13]
For more specific information regarding code analysis, refer to SAE J3322: 2025 , 17.1, and 17.18.
[16]
Code analysis tools can be used to check conformance with coding guidelines such as MISRA C or CERT-C
[17]
, or for code quality estimates. Thus, in that regard the tools test for source code indicating potential bugs
or cybersecurity issues (e.g. coding practices that lead to vulnerable code).
[13]
For more specific information regarding this type of code analysis, refer to SAE J3322: 2025 , 17.8.
In addition, analysis can be applied to verify whether the processing of cryptographic keys or passphrases is
correctly implemented.
[13]
For more specific information regarding this type of code analysis, refer to SAE J3322: 2025 , 17.17, and
17.16.
Binary analysis includes static binary analysis and dynamic binary analysis. In contrast to static code
analysis, an executable binary file is used instead of source code. The class of methods that falls under
dynamic binary analysis is not precisely defined. Examples are: dynamic symbolic execution
...