ETSI TR 104 287 V1.1.1 (2026-08)

• Abstract:

  DTR/MTS-TST12SecValMet

• Status: Not Published
• Technical Committee: MTS TST - Testing
• Current Stage: 12 - Citation in the OJ (auto-insert)
• Due Date: 22-Aug-2026
• Completion Date: 10-Aug-2026

TECHNICAL REPORT
Methods for Testing and Specification (MTS);
Security Testing;
Security Validation Methodology for IoT components

2 ETSI TR 104 287 V1.1.1 (2026-08)

Reference
DTR/MTS-TST12SecValMet
Keywords
IoT, methodology, ML, security, testing
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part of this document may be reproduced in any form, by any means and in any media, without the prior written
authorization of ETSI and except as expressly permitted below.
By way of exception and when the document is a normative deliverable (European Standard (EN),
Technical Specification (TS), Group Specification (GS) or ETSI Standard (ES)), ETSI authorizes to reproduce
and incorporate into products, services and technical documentation only those extracts (e.g. templates) that are strictly
necessary for the technical implementation of the normative deliverable, to ensure compliance with the latter.
Nothing in this notice shall be construed as limiting any mandatory exceptions to copyright provided by applicable law.

© ETSI 2026.
All rights reserved.
ETSI
3 ETSI TR 104 287 V1.1.1 (2026-08)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
Executive summary . 4
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 9
3.1 Terms . 9
3.2 Symbols . 9
3.3 Abbreviations . 9
4 Security testing overview . 10
4.1 General . 10
4.2 Current state of SAST . 11
4.2.0 General . 11
4.2.1 Secure coding standards . 11
4.2.2 Code review . 12
4.2.3 Symbolic execution. 12
4.2.4 Taint analysis . 13
4.2.5 AI-driven static analysis . 13
4.3 Current state of DAST . 13
5 Specification of a security validation methodology . 16
5.1 General . 16
5.2 Static Application Security Testing (SAST). 17
5.3 Dynamic Application Security Testing (DAST) . 18
5.4 Interactive Application Security Testing (IAST) . 19
5.4.1 General . 19
5.4.2 Verification of SAST findings . 19
5.5 Firmware Fuzzing. 22
5.5.0 Firmware Fuzzing Introduction . 22
5.5.1 Static Memory containing global variables . 22
5.5.2 Stack and Heap sanitization . 23
6 Validation of security patches . 23
6.1 Introduction . 23
6.2 Genetic grey‑box fuzzing for security patch validation. 23
History . 25

ETSI
4 ETSI TR 104 287 V1.1.1 (2026-08)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables (European Standard (EN), Technical Specification (TS),
Group Specification (GS) or ETSI Standard (ES)) may have been declared to ETSI. The declarations pertaining to these
essential IPRs, if any, are publicly available for ETSI members and non-members, and can be found in
ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI IPR online database.
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™, LTE™ and 5G™ logo are trademarks of ETSI registered for the benefit of its Members and of the
3GPP Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of ®
the oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Methods for Testing and Specification
(MTS).
The aim of the present document is to outline a unified methodology for security validation of IoT components, with a
particular focus on automated security testing techniques and their integration into supply-chain-oriented frameworks
such as Device Security Passports (DSPs). The present document has been influenced by research and implementation
results from the DOSS project ("Secure-by-Design IoT Operation with Supply Chain Control").
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Executive summary
The security of Internet of Things (IoT) systems depends critically on the trustworthiness of their constituent
components, including firmware, embedded software, third‑party libraries (incl. open‑source libraries) and in‑house
applications. The present document describes a security validation methodology for IoT components that supports
secure‑by‑design development and supply‑chain‑aware validation.
ETSI
5 ETSI TR 104 287 V1.1.1 (2026-08)
The methodology integrates:
• Static Application Security Testing (SAST): Early‑lifecycle analysis of source and binary code to identify
security weaknesses before deployment. The methodology combines rule‑based analysis, secure‑coding
standards and AI‑enabled vulnerability prediction and classification.
• Dynamic Application Security Testing (DAST): Runtime testing of binaries, firmware and services without
requiring source code, with emphasis on coverage‑guided fuzzing and specialized embedded‑firmware
fuzzing.
• Interactive Application Security Testing (IAST): Combined use of SAST and DAST results to focus
dynamic testing on the most relevant code regions and to confirm or negate static analysis findings, thereby
reducing false positives.
• Security patch validation: Test techniques to validate that a security patch fully addresses a vulnerability and
does not leave alternative exploit paths open.
The methodology is designed to integrate with supply-chain-oriented artefacts such as a Device Security
Passport (DSP) [i.7]. Testing artefacts (findings, coverage metrics, evidence of patch validation) are exposed to the
DSP so that component manufacturers, integrators and operators can:
• assess component security posture;
• prioritize remediation activities;
• support regulatory and certification processes (for example in the context of the Cyber Resilience Act); and
• maintain an auditable security history across the full component life-cycle.
Introduction
The security of IoT systems is increasingly recognized as a critical concern across industrial, consumer and critical
infrastructure domains. IoT products are typically assembled from heterogeneous hardware and software components
originating from multiple vendors, open-source communities and in-house development efforts. These components are
updated independently, reused across product families and operated in diverse environments for extended periods of
time. This supply-chain-centric reality complicates traditional, monolithic approaches to security assurance and creates
a need for methodologies that are capable of addressing components both individually and in the context of the wider
system in which they operate.
At the same time, the regulatory landscape is evolving significantly. The European Cyber Resilience Act (CRA) [i.1]
introduces binding obligations for the security of products with digital elements, including IoT devices, across their full
lifecycle. These obligations require manufacturers, importers and distributors to demonstrate that their products have
been designed, developed and maintained in accordance with appropriate security practices. Structured, repeatable and
traceable security testing is therefore no longer a purely technical concern but is becoming a prerequisite for regulatory
compliance and market access.
Existing security testing practices are, however, fragmented. The following limitations are observed in current industrial
practice:
• Static analysis is often used in software development, but it often produces incorrect results and is not linked
to dynamic testing. Dynamic testing and fuzzing campaigns are often scoped to individual products or selected
interfaces, executed late in the development lifecycle.
• Lack of interactive techniques that combine static and dynamic analysis.
• Patch validation is commonly performed in an ad-hoc manner, with limited automation and insufficient
traceability of the evidence generated.
ETSI
6 ETSI TR 104 287 V1.1.1 (2026-08)
These limitations are particularly consequential in IoT deployments, where the attack surface is distributed across many
heterogeneous devices, communication interfaces, network services and backend components, and where the
exploitation of a single residual vulnerability can compromise entire fleets of products simultaneously. The growing
emphasis on regulatory frameworks such as the CRA further increases the need for reliable, auditable and repeatable
security testing processes.
The DOSS project ("Secure-by-Design IoT Operation with Supply Chain Control") has addressed these challenges by
introducing the Supply Trust Chain (STC) concept. The STC proposes a Device Security Passport (DSP) for
components, which records security-relevant information across a component's full lifecycle, and a Component Tester
(CT), which generates and provides automated security testing evidence to the DSP platform. The security testing
methodology developed within DOSS integrates static, dynamic and interactive application security testing as well as
structured patch validation into a coherent, supply-chain-aware process.
The present document generalizes and abstracts the methodology developed in the context of the DOSS project, with
the objective of making it applicable across IoT domains and independent of any specific project tooling or platform
infrastructure. It provides an overview of the current state of the relevant security testing techniques, specifies a unified
methodology that defines how these techniques are combined through explicit information flows and complementary
capabilities, and describes how the resulting testing evidence can be structured for integration with supply-chain
artefacts such as the DSP. In doing so, the present document aims to support component manufacturers, system
integrators and device operators in establishing security validation processes that are technically rigorous,
lifecycle-aware and aligned with emerging regulatory and certification requirements.

ETSI
7 ETSI TR 104 287 V1.1.1 (2026-08)
1 Scope
The present document specifies a methodology for automated security testing of IoT devices. It covers third-party,
open-source, and in-house software and serves as a basis for later tooling and framework implementation. The
methodology integrates Static Application Security Testing (SAST), including specialized vulnerability predictions, as
well as Dynamic Application Security Testing (DAST), and Interactive Application Security Testing (IAST) with a
particular focus on fuzzing approaches. In addition, the present document provides a detailed description of the
validation process for security patches.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's
understanding, but are not required for conformance to the present document.
[i.1] Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on
horizontal cybersecurity requirements for products with digital elements and amending
Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber
Resilience Act).
[i.2] DOSS Deliverable D3.1: "Unified component testing methodology", v1.0, 2024.
[i.3] DOSS Deliverable D2.2: "Integrated IoT supply chain concept and architecture", 2024.
[i.4] A. Takanen et al.: "Fuzzing for Software Security Testing and Quality Assurance", 2018.
[i.5] R. Baldoni et al.: "A survey of symbolic execution techniques", ACM Computing Surveys, 2018.
[i.6] M. Siavvas et al.: "Static-analysis-based approaches for secure software development", 2018.
[i.7] ETSI TR 104 285: "Methods for Testing & Specification (MTS); Device Security Passport".
[i.8] R. Seacord: "Secure Coding in C and C++", Addison-Wesley Professional, 2013.
[i.9] MISRA C:2025: "Guidelines for the use of the C language in critical systems", MISRA Limited,
2025.
[i.10] MISRA C++:2023: "Guidelines for the use of the C++17 language in critical systems", MISRA
Limited, 2023.
[i.11] D. Davidson et al.: "Fie on firmware: Finding vulnerabilities in embedded systems using symbolic
nd
execution", Proceedings of the 22 USENIX Conference on Security, Berkeley, 2013.
[i.12] K.-K. Ma et al.: "Directed symbolic execution", Static Analysis, pp. 95-111, 2011.
[i.13] N. Corteggiani et al.: "Inception: system-wide security testing of real-world embedded systems
th
software", 27 USENIX Security Symposium, 2018.
ETSI
8 ETSI TR 104 287 V1.1.1 (2026-08)
[i.14] Y. Shin et al.: "An empirical model to predict security vulnerabilities using code complexity
metrics", Proceedings of the Second ACM-IEEE™ international symposium on Empirical
software engineering and measurement, pp. 315-317, 2008.
[i.15] I. Chowdhury et al.: "Using complexity, coupling, and cohesion metrics as early indicators of
vulnerabilities", Journal of Systems Architecture, vol. 57, no. 3, pp. 294-313, 2011.
[i.16] R. Scandariato et al.: "Predicting vulnerable software components via text mining", IEEE™
Transactions on Software Engineering, vol. 40, no. 10, pp. 993-1006, 2014.
[i.17] Y. Pang et al.: "Predicting vulnerable software components through deep neural network",
Proceedings of the 2017 International Conference on Deep Learning Technologies, pp. 6-10, 2017.
[i.18] I. Kalouptsoglou et al.: "Examining the capacity of text mining and software metrics in
vulnerability prediction", Entropy, vol. 24, no. 5, 2022.
[i.19] J. Devlin et al.: "Bert: Pre-training of deep bidirectional transformers for language understanding",
arXiv preprint arXiv:1810.04805, 2018.
[i.20] J. Zhang et al.: "An empirical study of automated vulnerability localization with large language
models", arXiv preprint arXiv:2404.00287, 2024.
[i.21] I. Kalouptsoglou et al.: "Cross project vulnerability prediction based on software metrics and deep
learning", International Conference on Computational Science and Its Applications. Springer,
2020. ®
[i.22] OWASP Foundation: "OWASP Web Security Testing Guide (WSTG) v4.2", The Open Web
Application Security Project, 2020.
[i.23] V. J. M. Manès et al.: "The Art, Science, and Engineering of Fuzzing: A Survey", IEEE™
Transactions on Software Engineering, vol. 47, no. 11, pp. 2312-2331, 2021.
[i.24] Federal Office for Information Security: "Fuzzing Primer. A Fuzz Testing Introduction with
CC-specific Guidance", Version 1.6, 2020.
[i.25] M. Böhme, V.-T. Pham and A. Roychoudhury: "Coverage-based Greybox Fuzzing as a Markov
Chain", in Proc. ACM SIGSAC Conference on Computer and Communications Security (CCS),
pp. 1032-1043, 2016.
[i.26] M. Muench, J. Stijohann, F. Kargl, A. Francillon and D. Balzarotti: "What You Corrupt Is Not
What You Crash: Challenges in Fuzzing Embedded Devices", in Proc. Network and Distributed
Systems Security Symposium (NDSS), 2018.
[i.27] J. Zaddach, L. Bruno, A. Francillon and D. Balzarotti: "AVATAR: A Framework to Support
Dynamic Security Analysis of Embedded Systems' Firmwares", in Proc. Network and Distributed
Systems Security Symposium (NDSS), 2014.
[i.28] D. D. Chen, M. Woo, D. Brumley and M. Egele: "Towards Automated Dynamic Analysis for
Linux-based Embedded Firmware", in Proc. Network and Distributed Systems Security
Symposium (NDSS), 2016.
[i.29] A. Fasano et al.: "SoK: Enabling Security Analyses of Embedded Systems via Rehosting", in Proc.
ACM Asia Conference on Computer and Communications Security (AsiaCCS), pp. 687-701,
2021.
[i.30] K. Serebryany, D. Bruening, A. Potapenko and D. Vyukov: "AddressSanitizer: A Fast Address
Sanity Checker", in Proc. USENIX Annual Technical Conference (ATC), pp. 309-318, 2012.
[i.31] E. J. Schwartz, T. Avgerinos and D. Brumley: "All You Ever Wanted to Know about Dynamic
Taint Analysis and Forward Symbolic Execution (but Might Have Been Afraid to Ask)", in Proc.
IEEE™ Symposium on Security and Privacy (S&P), pp. 317-331, 2010.
[i.32] N. Nethercote and J. Seward: "Valgrind: A Framework for Heavyweight Dynamic Binary
Instrumentation", in Proc. ACM SIGPLAN Conference on Programming Language Design and
Implementation (PLDI), pp. 89-100, 2007.
ETSI
9 ETSI TR 104 287 V1.1.1 (2026-08)
[i.33] M. Tappler, B. K. Aichernig and R. Bloem: "Model-Based Testing IoT Communication via Active
Automata Learning", in Proc. IEEE™ International Conference on Software Testing, Verification
and Validation (ICST), pp. 276-287, 2017.
nd
[i.34] A.E. Eiben and J.E. Smith: "Introduction to Evolutionary Computing", 2 edition, Springer,
Berlin, Heidelberg, 2015.
[i.35] R. Barakat et al.: "Interactive Application Security Testing with Hybrid Fuzzing and Statistical
Estimators", in: CyberSecurity in a DevOps Environment, Springer, Cham, 2024.
[i.36] H. Pearce et al.: "Examining Zero-Shot Vulnerability Repair with Large Language Models," in
Proc. IEEE™ Symposium on Security and Privacy (S&P), pp. 2339-2356, 2023.
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
component: software or firmware artefact that can be tested independently
EXAMPLE: A library, service, firmware image, application module.
Component Tester (CT): system that implements the unified security testing methodology specified in the present
document
Device Security Passport (DSP): structured artefact or service that contains security‑relevant information about a
device or component across its lifecycle
EXAMPLE: SBOM/HBOM, test results, known vulnerabilities, patch history.
security patch: changes to software or firmware intended to correct a vulnerability
System Under Test (SUT): component or set of components under security testing
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACL Access Control List
AI Artificial Intelligence
API Application Programming Interface
ASA Automated Static Analysis
AST Abstract Syntax Tree
CFG Control Flow Graph
CI/CD Continuous Integration/Continuous Deployment
CoAP Constrained Application Protocol
CPU Central Process Unit
CRA Cyber Resilience Act
CT Component Tester
CWE Common Weakness Enumeration
DAST Dynamic Application Security Testing
DSP Device Security Passport
ELF Executable and Linkable Format
HBOM Hardware Bill Of Materials
ETSI
10 ETSI TR 104 287 V1.1.1 (2026-08)
HIL Hardware-In-the-Loop
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IAST Interactive Application Security Testing
IDE Integrated Development Environment
IoT Internet of Things
IR Intermediate Representation
I/O Input and Output
JSON Java Script Object Notation
LLM Large Language Model
ML Machine Learning
NLP Natural Language Processing
QEMU Quick Emulator
RAM Random Access Memory
REST Representational State Transfer
SAST Static Application Security Testing
SBOM Software Bill Of Materials
SDLC Software Development Life-Cycle
SOAP Simple Object Access Protocol
SQL Structured Query Language
STC Supply Trust Chain
SUT System Under Test
TCP Transmission Control Protocol
UDP User Datagram Protocol
URL Uniform Resource Locator
VP Vulnerability Prediction
VPM Vulnerability Prediction Model
4 Security testing overview
4.1 General
In current industrial practice, security testing of software and firmware is often fragmented and tool‑driven. Many
organizations deploy a static analysis tool in their development pipeline, perform some form of penetration testing or
fuzzing close to release, and run vulnerability scanners during operation. While these activities can be effective in
isolation, the lack of integration between them leads to several shortcomings:
• Static analysis is frequently used as a gate in continuous integration, but its findings are not consistently
followed up with targeted dynamic verification. As a result, teams may struggle with large numbers of
untriaged findings and may disable classes of rules to reduce perceived noise.
• Dynamic testing and fuzzing campaigns are typically scoped to selected products or interfaces and executed
late in the lifecycle, when architectural changes are difficult. Moreover, insights from dynamic testing (for
example, which inputs lead to crashes, which areas are hard to test) are rarely fed back into design or
secure‑coding practices.
• Firmware and other embedded software often receive less attention than applications running on operating
systems. Limited observability and platform‑specific constraints make it harder to apply existing tools, which
are typically oriented towards desktop or server environments.
Patch validation is largely ad‑hoc. Once a patch is released, it is common to re‑run a small number of regression tests or
the original proof‑of‑concept exploit. Alternative paths that still trigger the same underlying flaw, or closely related
vulnerabilities created by the patch, are often not explored systematically.
These limitations are particularly problematic in IoT scenarios, where the attack surface is distributed over many
devices, network services and backend components, and where exploitation of a single remaining vulnerability can
compromise entire fleets of products. The growing emphasis on regulatory frameworks such as the European Cyber
Resilience Act further increases the need for reliable, traceable and repeatable security testing processes.
ETSI
11 ETSI TR 104 287 V1.1.1 (2026-08)
The security validation methodology proposed in the present document addresses these shortcomings by defining
explicit information flows between the different security analysis and by placing the security testing within a
‑chain‑aware architecture. Static results are not treated as an end in themselves but as input to dynamic testing.
supply
Dynamic testing is not purely exploratory but is guided by static analysis findings and vulnerability prediction models.
Patch validation is not left to manual reasoning but is driven by structured fuzzing campaigns. All these activities are
mapped so that the resulting evidence can be reused throughout the lifecycle and, for example, can be added to a DSP.
4.2 Current state of SAST
4.2.0 General
Static code analysis is a well‑established technique and a central part of many secure‑development programmes.
Modern SAST tools support multiple programming languages, enforce secure coding standards and provide rule sets for
common vulnerability classes such as buffer overflows, injection, use of insecure APIs and insufficient input validation.
They are commonly integrated into Integrated Development Environments (IDEs) and CI/CD pipelines, where they
automatically analyse code upon check‑in or at build time.
Over the past two decades, research has significantly advanced the capabilities of static analysis. Techniques such as
symbolic execution, abstract interpretation, data‑flow analysis and taint analysis allow deeper reasoning about code
paths and data dependencies. At the same time, AI‑based approaches have emerged that use machine learning and deep
learning models - particularly Transformer‑based Large Language Models (LLMs) - to predict which components are
likely to contain vulnerabilities and to classify vulnerabilities into Common Weakness Enumeration (CWE) categories.
Despite this progress, SAST in practice still faces several challenges:
• It tends to generate a substantial number of findings, not all of which correspond to exploitable issues. Manual
triage can be time‑consuming, and teams are often required to prioritize which findings to address.
• It can only reason about code that is visible to the analyser. Interactions with closed‑source libraries, operating
systems or hardware are often modelled imprecisely, which may lead to both false positives and false
negatives.
• It is usually applied with limited context about how a component will be deployed. For instance, the same
piece of code may be high‑risk when exposed to the internet and low‑risk when only used in an internal,
access‑controlled system.
• It is not automatically linked to subsequent dynamic testing or patch‑validation activities. In many
organizations, static and dynamic testing teams work with separate tools and reporting formats, which makes it
harder to trace an issue from initial detection through to dynamic confirmation and resolution.
The methodology in the present document acknowledges these strengths and weaknesses. It uses SAST as an early and
broad coverage mechanism but explicitly complements it with dynamic and interactive techniques. Furthermore, it
leverages AI‑based Vulnerability Prediction Models (VPMs) to focus attention on parts of the code base that are more
likely to be problematic. The goal is not to replace human judgment but to provide a structured process and supporting
tools that make SAST more actionable and better integrated with the remainder of the security validation process.
4.2.1 Secure coding standards
Secure coding standards are rules, guidelines, and best practices that help developers write code with fewer
TM TM
vulnerabilities. Standards exist for many languages (e.g. Java , C#, Python ). For IoT and embedded systems, C/C++
standards are particularly relevant.
The Software Engineering Institute at Carnegie Mellon University publishes secure coding standards for C and
C++ [i.8]. The standards define rules and recommendations. Each rule has a severity, a likelihood of leading to an
exploitable vulnerability, and a remediation cost, which together determine a priority level (1 - 3). This prioritization
supports risk-based remediation. Recommendations are provided for additional guidance.
ETSI
12 ETSI TR 104 287 V1.1.1 (2026-08)
MISRA C [i.9] and MISRA C++ [i.10] standards, developed for safety‑critical systems, are widely used in industry.
The current MISRA C [i.9] standard, MISRA C:2025, defines 223 directives and rules, while the current MISRA C++
[i.10] standard, MISRA C++:2023 (targeting C++17), defines 179 guidelines. Compliance requires adherence to all
mandatory guidelines, adherence to required guidelines unless a formal deviation is documented, and consideration of
advisory guidelines.
4.2.2 Code review
Code review - manual and automated - is the most common static analysis practice. Manual reviews benefit from
human insight but are time‑consuming and require broad expertise (architecture, implementation, security). Automated
reviews use tools to detect vulnerabilities and verify compliance with coding standards. These tools take source or
binary inputs and produce human‑readable reports. While automation encapsulates expert knowledge, tools are limited
to their built‑in checks and may generate many warnings, including false positives.
In the context of automated code review, the software is transformed into an in-memory representation. For source
code, this may be an Abstract Syntax Tree (AST) or a Control Flow Graph (CFG). For binaries, instructions are lifted to
an Intermediate Representation (IR) to support platform independence. Subsequent analyses, including control-flow and
dependence analysis, type inference and checking, and program slicing, are then run over these representations, with
any potential issues being reported with messages and locations.
Because static analysis does not execute code, it lacks runtime context and cannot confirm findings on its own.
Validation is therefore required. False positives may arise when tools report issues that would not occur at runtime
(e.g. mitigated by secure configurations of external components). False negatives occur when tools lack rules to detect
certain issues.
4.2.3 Symbolic execution
Symbolic execution is a static analysis technique originally introduced for automated test generation [i.12] and
increasingly used to discover bugs and vulnerabilities across domains, including API implementations. Instead of
concrete values (e.g. specific integers or strings), it uses symbolic variables while exploring execution paths. It can be
applied to source code, intermediate representations, and binaries.
Symbolic variables are initially unconstrained. Constraints are added at control‑flow branches, and execution forks to
explore alternative paths. The accumulated constraints form the path condition. When a path terminates, an constraints
solver can produce concrete inputs that satisfy the path condition; these serve as test cases that drive real execution
along the same path. This enables high coverage and can expose security issues.
The advantages of this approach include the generation of test input in an automated manner, the assurance of high path
coverage, and the capacity to reason about complex properties when execution states are monitored. The challenges
inherent to this approach are as follows:
• Path explosion:
- each branch can double the number of paths;
- loops and indirect jumps exacerbate growth.
• Environment modelling:
- engines has to model types, pointers, platform registers, memory, instruction side effects, interrupts, and
hardware interactions [i.13].
Two common mitigations to path explosion are:
• Dynamic symbolic execution (concolic testing):
- analyse "interesting" instructions symbolically and others concretely;
- optionally restrict scope via program slicing.
• Path selection:
- prioritize or abandon paths using heuristics tailored to the domain [i.11], [i.12].
ETSI
13 ETSI TR 104 287 V1.1.1 (2026-08)
4.2.4 Taint analysis
Taint analysis detects vulnerabilities arising from improper data sanitization - when data derived from untrusted input is
used in security‑sensitive operations. Sources are program points at which untrusted data can be entered
(e.g. environment variables, stdin). Sinks are security‑sensitive operations that attackers may exploit (e.g. indirect
jumps). Analysis propagates a taint flag from sources according to a propagation policy. A vulnerability is reported
when tainted data reaches a sink. Note that program integrity may be compromised before a sink is executed (e.g. a
tainted return address due to a buffer overflow).
Static taint analysis considers all possible paths from sources to sinks and requires control‑flow and dependence
information. It struggles with indirect memory accesses, indirect calls, and pointer aliasing (multiple names referencing
the same memory chunk).
Key challenges include:
• Under‑tainting: missing certain information flows (especially those mediated by control dependencies), which
are hard to capture purely dynamically.
• Over‑tainting (taint spread): tainting values that are not derived from untrusted input.
4.2.5 AI-driven static analysis
Automated Static Analysis (ASA) automates code inspection for security weaknesses by analysing structure, syntax,
and logic without execution. ASA tools report potential issues (e.g. buffer overflows, exception handling errors, null
dereferences, memory corruption) based on predefined rules. ASA scales to large codebases and provides consistent,
thorough coverage with minimal manual effort.
However, ASA can generate many false positives. A Vulnerability Prediction (VP) mechanism can prioritize alerts by
estimating the likelihood that a component is vulnerable, thereby focusing attention on higher‑risk findings. Two
ML‑based VP approaches are common:
i) software‑metrics‑based (e.g. complexity, lines of code) [i.14], [i.15]; and
ii) text‑mining‑based, which tokenizes source code and learns textual patterns [i.16], [i.17].
The latter often performs better [i.18].
Recent NLP advances, especially Transformer‑based Large Language Models (LLMs), enable transfer learning for VP
[i.19].
Open challenges include choosing the optimal Transformer variant (encoder‑only, decoder‑only, encoder‑decoder) and
training configurations for VP, as studies often report final models without ablations. Another challenge is predicting
not only whether a component is vulnerable but also the type of vulnerability. The CWE system categorizes software
weaknesses, but expert‑driven assignment can be time‑consuming and lag behind disclosures [i.20].
4.3 Current state of DAST
DAST comprises techniques that exercise a running System Under Test (SUT) through its exposed interfaces and
monitor its behaviour for signs of security vulnerabilities or weaknesses. In contrast to SAST, which reasons about code
without execution, DAST observes concrete executions under specific inputs and environments. It is therefore well
suited to detecting vulnerabilities that depend on runtime state (e.g. memory layout, timing, configuration) or on the
interplay between multiple components.
‑application scanners towards
In industrial practice, DAST has evolved from manual penetration testing and simple web
a diverse landscape that includes web and API scanning, protocol‑level testing, coverage‑guided robustness testing of
binaries and services, firmware and Hardware‑In‑the‑Loop (HIL) testing, as well as dynamic taint analysis and various
forms of runtime instrumentation [i.23]. For IoT ecosystems, all of these aspects are relevant, because security depends
not only on internet‑facing web services but also on device‑local interfaces, embedded protocol stacks and cloud
backends that form part of the overall system.
ETSI
14 ETSI TR 104 287 V1.1.1 (2026-08)
The present clause provides an overview of the main dynamic testing approaches that are currently used or emerging for
IoT‑relevant software and firmware. Later clauses in the present document build on these techniques and embed them
into a unified security validation methodology.
Web and API scanning
The most established form of DAST is web and API scanning [i.22]. Commercial and open‑source scanners interact
with running web applications, device‑embedded web interfaces and HTTP‑based APIs. They typically discover pages
and endpoints, identify input vectors such as form fields, headers and query parameters, and then submit crafted
requests that embed attack payloads. The goal is to trigger observable misbehaviour, for example database manipulation
‑site scripting) or anomalous HTTP status codes,
(e.g. SQL injection), reflected payloads in HTML responses (cross
which indicate classes of vulnerabilities such as injection, cross‑site scripting, broken access control or insecure session
management [i.22].
Over the last decade, these tools have evolved from simple crawlers to platforms that understand REST, SOAP and,
increasingly, GraphQL and JSON‑based services. They can often import interface descriptions such as OpenAPI
specifications to drive systematic testing of API operations [i.22]. In the IoT domain,
...