Analysis of Security Vulnerabilities in S-100-Based Maritime Navigation Software

Abstract

The S-100 standard for Electronic Chart Display and Information Systems (ECDIS) uses Lua scripts to render electronic charts, yet lacks security specifications for script execution. This paper evaluates automated Static Application Security Testing (SAST) tools versus expert manual review for S-100-compliant software. Four SAST tools were applied alongside an expert review of OpenS100, a reference implementation for next-generation ECDIS. While automated tools identified numerous defects, they failed to detect 83% (19/23) of expert-identified vulnerabilities, including an unrestricted Lua interpreter flaw with a Common Vulnerability Scoring System (CVSS) score of 9.3. This vulnerability enables Remote Code Execution (RCE) via malicious portrayal catalogues, verified through Proof of Concept (PoC) development. The analysis demonstrates that SAST tools are constrained by limited maritime domain knowledge and challenges in analyzing cross-language semantic risks at the C++–Lua interface. The findings establish that identified vulnerabilities stem from specification gaps in the S-100 standard rather than isolated coding errors. These results indicate that functional safety certifications require supplementation to address design-level security risks. The evidence supports that the International Hydrographic Organization (IHO) incorporate security controls, such as script sandboxing and library restrictions, into the S-100 framework before the 2029 mandatory adoption deadline.

1. Introduction

Maritime navigation has evolved from paper nautical charts to Electronic Navigational Charts (ENC), with the International Hydrographic Organization (IHO) introducing the S-100 standard to replace the legacy S-57 format [1]. The S-100 standard separates data from visualization through a portrayal engine that interprets Lua scripts to render Electronic Chart Display and Information Systems (ECDIS). While S-100 includes cryptographic mechanisms such as IEC 63173-2 SECOM (Secure Communication Between Ship and Shore) along with Part 15 digital signatures ensuring chart data originate from authorized hydrographic offices, cryptographic integrity guarantees source authenticity but does not guarantee script safety [2,3]. Malicious portrayal scripts from compromised sources could manipulate chart rendering, leading to navigation hazards or operational disruptions. Modern operating system protections such as Data Execution Prevention (DEP) defend software that interprets scripts for standard compliance. Commercial security analysis tools effectively detect common software defects, such as buffer overflows, but face limitations when different programming languages interact. The S-100 portrayal engine exemplifies this challenge, as navigation-critical logic flows between C++ chart parsing and Lua execution.

To measure this gap, this study directly compares automated SAST tools against expert manual review on the OpenS100 reference implementation. Contributions are: (1) the first dual-methodology empirical evaluation on S-100 software; (2) identification of a CVSS 9.3 critical flaw enabling RCE via portrayal catalogues, with verified PoC; (3) proof that vulnerabilities stem from standard specification gaps rather than coding errors; (4) a validated mitigation patch preserving functional compatibility; and (5) standardization recommendations for the IHO ahead of the 2029 mandatory adoption. The remainder is organized as follows: Section 2 reviews background and related work, Section 3 describes the three-phase methodology, Section 4 presents findings, Section 5 analyzes the critical-flaw case study, Section 6 discusses limitations and standardization, and Section 7 concludes with recommendations.

2. Background and Related Work

2.1. S-100 Standard and Portrayal Engine Architecture

The IHO S-100 Universal Hydrographic Data Model provides the technical foundation for next-generation ECDIS. S-100 was developed to overcome the rigid data structure and maintenance limitations of the legacy S-57 standard and is designed to align with the ISO 19100 series of geographic information standards [1]. The standard extends beyond defining encoding formats by providing a flexible framework for developing various marine-related data product specifications based on object-oriented modeling using the Unified Modeling Language. From a technical perspective, a key architectural change in S-100 is the separation of data features from portrayal visualization logic. Unlike legacy systems that relied on static symbol tables and hardcoded visualization rules, S-100 defines a portrayal mechanism in Part 9 (Portrayal), Part 9a (Portrayal-Lua), and Part 13 (Scripting). Specifically, S-100 Edition 5.2.0 Part 9a Section 9a-4.1 mandates: "Lua version 5.1 shall be used for implementing portrayal functions" [4]. Additionally, Part 13 Section 13-7.1 specifies the Lua version requirements [5]. PCs consist of XML files containing rendering rules and Lua scripts for their execution, which systems dynamically load at runtime to render maritime objects on displays.

2.2. Software Vulnerability Detection Methods

Diagnostic techniques for identifying and managing security defects in software are broadly categorized into static analysis and dynamic analysis. Static analysis examines program syntax and control flow without executing source code to identify potential weaknesses, enabling comprehensive examination of entire codebases but carrying the possibility of false positives. In contrast, dynamic analysis monitors memory corruption and exception occurrences in real time while executing programs, accurately capturing threats during actual operation but unable to diagnose unexecuted code regions. Weaknesses are classified according to the Common Weakness Enumeration (CWE) framework [6], which catalogs commonly occurring security weaknesses in software architecture, design, and code, defining types such as Buffer Overflow (CWE-120) and Code Injection (CWE-94). When security weaknesses develop into concrete attacker-exploitable defects they are termed vulnerabilities, assessed for severity using CVSS version 3.1 [7]. CVSS provides quantitative metrics from 0.0 to 10.0, evaluating vulnerabilities on eight Base metrics including Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope, and confidentiality, integrity, and availability impacts.

2.3. Related Work

Maritime cybersecurity research has grown substantially following the IMO MSC.428(98) resolution mandating cyber risk management in 2021 [8]. Li et al. conducted a comprehensive review of maritime cyber attacks [9], presenting a multi-dimensional taxonomy covering ECDIS, AIS, GNSS, VDR, and GMDSS, identifying third-party components and outdated operating systems as primary ECDIS vulnerabilities. However, their taxonomy focuses on network-level attacks and does not address vulnerabilities in navigation data standards requiring dynamic script execution. Longo et al. analyzed attack scenarios for manipulating maritime radar images through the ASTERIX protocol, demonstrating network vulnerabilities [10]. Empirical vulnerability research on operational ECDISs documented consistent security deficiencies across manufacturers: Svilicic et al. found Windows 7 systems with vulnerable SMBv1 protocols still active in 2024 [11], and Jo et al. analyzed JAN-901B and TransNav units finding similar patterns of unpatched systems and exposed services [12]. None of these studies, however, addresses script execution security in the portrayal layer.

2.4. Research Gap and Contributions

Table 1 of the original paper summarizes reviewed studies across three research categories, highlighting the systematic absence of work at the intersection of maritime navigation standards, embedded scripting security, and domain-specific vulnerability detection: ECDIS security (network-level only, no data standard security), S-100 standard security (limited coverage despite 2029 mandate), Lua sandbox security (no maritime application), safety-critical systems (no embedded scripting frameworks), SAST limitations (47–80% miss rates for general vulnerabilities), and LLM-assisted SAST (general code, no maritime application). The literature review reveals three research gaps: first, S-100 security research is limited despite voluntary adoption beginning January 2026 and mandatory new installations from January 2029; second, no study compares SAST tools against expert review on S-100 software; third, security implications of unrestricted Lua execution in portrayal engines are unanalyzed. This study closes these gaps through dual evaluation on OpenS100, identification of a verified critical flaw, and a patch plus standardization recommendations.

3. Methodology

This paper conducts a three-phase analysis procedure to verify the detection effectiveness of security analysis tools targeting OpenS100, an S-100 standard implementation, and to identify security blind spots arising from domain-specific logic. Figure 2 of the original paper illustrates the experimental workflow comprising three sequential phases. Phase 1 establishes the analysis target and build environment. Phase 2 executes the automated static analysis pipeline where four tools generate raw issues that undergo CWE classification and deduplication to produce a refined defect dataset. Phase 3 conducts expert manual code review through attack surface identification, risk-based code audit, and security assessment of discovered vulnerabilities.

3.1. Analysis Target System and Environment

OpenS100, an open-source project developed based on the S-100 viewer of the Korea Hydrographic and Oceanographic Agency (KHOA) under the Ministry of Oceans and Fisheries (MOF), was selected as the analysis target [33]. OpenS100 serves as a reference implementation similar to other maritime security research testbeds such as MaCySTe, which provides a containerized environment for maritime IT/OT system experimentation [34]. Unlike general-purpose testbeds, however, OpenS100 specifically implements S-100 standard compliance, with the project repository showing 18 forks indicating its use as a foundation for derivative implementations. This widespread adoption pattern means vulnerabilities identified in OpenS100 are likely to propagate to dependent systems unless developers independently implement security controls not specified in the S-100 standard. OpenS100 is a C++-based reference implementation designed to accommodate various S-100 product specifications including S-101, the next-generation electronic navigational chart standard, as well as S-102 and S-124. The system strictly follows S-100 Part 9a Portrayal with Lua and Part 13 Scripting specifications for PC implementation.

3.2. Automated Static Analysis Pipeline

In the first-phase diagnosis, an automated pipeline integrating multiple static analysis tools was established to identify security weaknesses throughout the source code. The tools employed are: FlawFinder, detecting security-vulnerable function calls in C/C++ source code that can cause buffer overflows or enable command injection on a risk scale of 1 to 5; CppCheck, detecting a broad range of programming errors including memory leaks, null pointer dereferences, and uninitialized variable usage, classifying them by severity as Error, Warning, or Style; Microsoft Visual C++ Code Analysis, a static analysis engine embedded in Visual Studio detecting buffer overruns, type mismatches, and uninitialized memory access; and GitHub CodeQL, employing query-based semantic analysis constructing a relational database from source code, enabling detection of complex vulnerability patterns through declarative queries, classifying issues as Error, Warning, or Recommendation. Since each tool uses independent defect naming conventions and severity criteria, a refinement process was necessary for standardization. All detected defects were reclassified into categories based on security characteristics, with Table 2 of the original paper presenting the security category definitions used.

3.3. Expert Manual Code Review

In the second phase, expert manual code review was conducted to identify security blind spots in S-100 standard-specific logic that static analysis tools failed to detect. The review was performed by a PhD student with 4 years of vulnerability research experience, Offensive Security Certified Professional (OSCP) certification, and Capture The Flag (CTF) competition participation since 2010, combined with 3 years of maritime software development and 5 years of Lua programming in embedded systems. The review scope encompassed the OpenS100 codebase at commit f13cd82, totaling 1291 source files with 101,129 lines of code (LOC) excluding external libraries. Given the infeasibility of exhaustive review, risk-based prioritization was employed through attack surface analysis focusing on untrusted data processing paths. The review concentrated on 842 files comprising 60,680 LOC (60% of the codebase), covering the critical data processing pipeline from chart file loading through FC and PC parsing to final rendering. This scope included GISLibrary (104 files, 21,465 LOC for ISO 8211 and HDF5 parsing), the PortrayalCatalogue module (254 files, 11,665 LOC for Lua integration), the FeatureCatalog module (135 files, 7351 LOC), and the S100Engine core (93 files, 5087 LOC).

4. Findings

Analysis results confirmed that static analysis tools demonstrate high detection rates for syntactically clear errors but show limited effectiveness in detecting defects requiring understanding of overall program operational logic and vulnerabilities based on complex data flows spanning multiple files. Automated tools identified 1530 unique defect locations, while expert review discovered 23 vulnerabilities with minimal overlap: one complete match at identical source locations, three partial matches for related defects, and 19 expert-only findings representing the majority of manual review results. This paper employs a staged disclosure strategy aligned with coordinated vulnerability disclosure principles: among the 23 identified vulnerabilities, four high-impact flaws were verified through functional PoC development, while the remaining 19 were identified through code audit. Detailed exploitation methods for these vulnerabilities are withheld pending remediation, balancing academic transparency with protection of safety-critical maritime infrastructure. Table 5 of the original paper summarizes the expert-review vulnerability summary, including severity classification, automated tool detection status, and PoC verification status.

The Unrestricted Lua Interpreter vulnerability was undetectable by all four automated tools, while integer overflow flaws achieving denial of service via heap corruption (RCE blocked by Windows Segment Heap), buffer overflow achieving denial of service (RCE blocked by /RTC compiler protection), and integer truncation verified at code level requiring files exceeding 4 GB for exploitation were likewise expert-only. The matrix shows automated tools excel at syntactic memory defects yet are entirely blind to domain-logic flaws, proving that automated coverage alone gives a false sense of security for safety-critical navigation software.

5. Case Study: Unrestricted Lua Interpreter

This chapter provides in-depth analysis of vulnerabilities that automated static analysis tools failed to detect. Four high-impact vulnerabilities were verified through functional PoC development on the tested platform: first, the Unrestricted Lua Interpreter flaw enabling RCE; second, integer overflow in data parsing achieving DoS via heap corruption though RCE was blocked by Windows Segment Heap; third, buffer overflow achieving DoS though RCE was blocked by /RTC compiler protection; and fourth, integer truncation verified at code level whose exploitation requires files exceeding 4 GB. The Lua interpreter vulnerability was selected as the primary case study for three reasons: (1) it demonstrates the highest severity (CVSS 9.3 Critical) with RCE capability on the tested platform; (2) it appears to originate from a design-level gap in the S-100 standard itself rather than implementation error; and (3) all four automated static analysis tools failed to detect it. The remaining 19 vulnerabilities were identified through rigorous code audit and follow logically similar patterns where automated tools fail to capture domain-specific security requirements. Following staged disclosure principles and security research ethics, this chapter presents only the information necessary to demonstrate the vulnerability's existence and impact, omitting specific attack code or details.

5.1. Vulnerability Discovery and Analysis

The S-100 standard mandates the use of the Lua programming language (version 5.1) for PC implementation, as specified in Part 9a (Portrayal-Lua) and Part 13 (Scripting) [4,5]. The OpenS100 system (commit f13cd82) follows this specification by employing a Lua script engine to process PCs. PCs consist of Lua script collections defining electronic chart visualization rules, determining how each Feature in chart data is rendered on displays. Expert review confirmed that this Lua script execution environment was configured without appropriate security isolation. The core of the vulnerability lies in the Lua interpreter initialization process within the OpenS100 portrayal engine. When initializing the Lua execution state, the system unconditionally loads all standard Lua libraries without sandboxing or capability restrictions. Listing 1 of the original paper shows the vulnerable initialization sequence in the OpenS100 portrayal engine implementation: lua_State *L = luaL_newstate(); luaL_openlibs(L); // Loads ALL standard libraries. The interpreter initialization unconditionally loads all standard Lua libraries, including os, io, debug, and package modules, exposing dangerous system-level capabilities to any subsequently loaded PC script.

5.2. Attack Path Analysis

This attack method can be executed through two pathways. The first pathway involves malicious PC distribution. Attackers copy legitimate PCs and insert malicious code into Lua script files. When distributed disguised as improved rendering or additional features, malicious code executes the moment users select the Catalogue and read the chart data in OpenS100 settings. Since the S-100 standard provides no mandatory digital signature or verification mechanism for PCs, users may have limited means to verify Catalogue origin and integrity. The second pathway is supply chain attack. Official S-100 PCs are provided by IHO or national hydrographic offices. If such organization systems are compromised or manipulated by insiders, large numbers of users could be affected. Given shipping and port infrastructure characteristics where identical Catalogues are widely used globally, a supply chain attack could impact multiple ECDIS installations. In contrast to memory vulnerability-based attacks, this vulnerability exploits legitimate interpreter functionality through the unrestricted configuration, rendering operating system security mechanisms such as Address Space Layout Randomization (ASLR), DEP, and Control Flow Guard (CFG) less effective, since Lua interpreters execute as normal program components.

5.3. Proof-of-Concept Demonstration

A minimal PoC was written and executed to verify the vulnerability's actual impact. Following responsible disclosure principles, implementation details are omitted from this paper, with experiments conducted only to the level demonstrating vulnerability existence and impact. The PoC was constructed by adding a test script to a legitimate S-101 Electronic Navigational Chart product PC. The test script was written to execute harmless programs such as calculator and notepad causing no system harm, confirming external program execution capability. The attack procedure involved two steps: first, the malicious PC was selected in OpenS100 settings; second, a legitimate S-101 chart file was opened. Experimental results showed that the specified programs executed immediately upon opening the chart file on Windows 11, demonstrating RCE capability where malicious PCs distributed through official channels or supply chain compromise achieve code execution on target systems. Figure 5 of the original paper illustrates the attack execution on the tested Windows 11 configuration: upon loading the S-101 chart file after selecting the compromised Catalogue, the embedded Lua script executes operating system commands, launching the calculator application as specified by the attacker. Critically, chart data renders normally during attack execution as demonstrated by the PoC, so navigators notice no indication of compromised displayed information.

5.4. Impact Assessment

This vulnerability may have substantial impacts given the characteristics of ECDISs used in the shipping industry. ECDIS are core systems for vessel navigation safety, mandatory under the Safety of Life at Sea (SOLAS) convention [35]. If attackers gain control of ECDISs, navigation safety could be affected: chart information could be manipulated to display incorrect data, or hazard information hidden, potentially leading to navigation incidents. Since chart rendering proceeds normally during attack execution as demonstrated in the PoC, navigators may have limited indication that displayed information has been compromised, continuing to make navigation decisions based on altered data. This stealth characteristic distinguishes the vulnerability from traditional cyber attacks that typically generate observable system anomalies. Information leakage implications also warrant consideration: sensitive operational information such as vessel position data, route data, and cargo information could be exfiltrated for purposes including competitive intelligence or tracking specific cargo movements. For military-purpose vessels or vessels carrying strategic materials, additional security considerations apply.

5.5. Patch Validation and Mitigation

To verify the feasibility of mitigating the identified vulnerability, a secure Lua interpreter configuration was implemented and validated. The implemented patch employs the post-initialization removal approach to maintain compatibility with existing PC implementations while addressing the security vulnerability. Listing 2 of the original paper shows the secure configuration disabling dangerous Lua libraries after initialization: luaL_newstate(); luaL_openlibs(); then // [SECURITY PATCH] disabling dangerous libraries via luaL_dostring setting os=nil, io=nil, debug=nil, package.loadlib=nil, package.cpath='', loadfile=nil, dofile=nil, load=nil, rawset=nil, loadstring=nil. The patch blocks operating system command execution, file system access, debugging capabilities, native library loading, and dynamic code evaluation. Table 8 of the original paper summarizes blocked capabilities and mitigated risks: os target (execute, exit, remove, rename) blocked; io (open, popen, read, write) blocked; debug (sandbox bypass capabilities) blocked; package.loadlib (native DLL loading) blocked.

5.5.1. Execution Order and Rawget Bypass Prevention

The library removal timing is critical for security. A potential reviewer concern involves rawget() bypass attempts where malicious scripts might attempt to access removed libraries through low-level table operations. The patch design prevents this attack vector through strict execution ordering. The Lua interpreter initialization follows a deterministic sequence: (1) luaL_newstate() creates the Lua state, (2) luaL_openlibs() loads all standard libraries including os, io, and debug, (3) luaL_dostring() executes the security patch setting library references to nil, and (4) external PC scripts are loaded via load_file(). Because the patch executes before any external script loads, library references are already removed from the global table (_G) when malicious scripts attempt access. Consequently, bypass attempts such as rawget(_G, "os") return nil because the reference was eliminated in step (3) before the script executed in step (4). This ordering guarantee makes the patch resistant to rawget/rawset bypass techniques, setfenv/getfenv environment manipulation, and metatable-based __index interception.

5.5.2. Validation Testing Results

Empirical validation confirmed complete RCE mitigation while preserving PC compatibility. Table 9 of the original paper summarizes the patch validation test results: direct os.execute() returns nil with no execution (pass); rawget(_G, "os") bypass returns nil with bypass failing (pass); malicious PC loading has RCE blocked with charts rendering (pass); normal PC loading renders charts successfully (pass); feature processing executes visualization rules (pass); system stability with no crashes or errors (pass). The patch preserves essential Lua capabilities required by S-101 PCs, including require for module loading, rawget for metatable-safe table access within __index metamethods, and standard libraries (math, string, table, pairs/ipairs) for portrayal rule computation. The rawset function is proactively blocked as a defense-in-depth measure: static analysis of the S-101 reference PC confirmed zero rawset invocations across all 256 Lua source files, while its capability to bypass __newindex metamethods represents a potential sandbox evasion vector. This selective blocking approach achieves security hardening without breaking legitimate PC functionality, and the library removal patch introduces negligible performance overhead through a single luaL_dostring() call.

5.5.3. Security and Standard Functional Compatibility

A potential concern is whether disabling standard Lua libraries conflicts with the extensibility intended by the S-100 standard. Analysis of Part 9a demonstrates that this conflict does not arise under the current architecture. The S-100 Part 9a portrayal model defines a closed-loop execution environment where all data exchange between Lua scripts and the host system occurs exclusively through host callback functions [4]. Feature data and association information pass through host callbacks, returning drawing instructions to the host via HostPortrayalEmit [4]. Section 9a-7 explicitly states that the portrayal does not use a data input schema, with all data passed through the Part 13 host interface. This architecture means Lua scripts have no legitimate requirement for direct file system access (io), operating system command execution (os), runtime introspection (debug), or dynamic native library loading (package.loadlib). The disabled libraries fall entirely outside the functional scope defined by Part 9a. Empirical validation confirms this architecture: the proposed patch was tested against the S-101 reference PC distributed with OpenS100, comprising 256 files and 15,112 lines of Lua code, with all portrayal functions executing successfully with dangerous libraries disabled.

6. Limitations and Discussion

This section addresses methodological constraints and outlines future research directions for maritime software security.

6.1. Limitations

This paper analyzed a single reference implementation, OpenS100 at commit f13cd82, rather than multiple commercial ECDISs. This constraint arises from: (1) proprietary nature of commercial ECDIS software limiting source code access, (2) resource constraints preventing procurement and analysis of multiple licensed systems, and (3) regulatory restrictions on reverse engineering safety-critical maritime equipment. While direct experimentation on commercial ECDIS platforms was not conducted due to security licensing and intellectual property restrictions, the generalization argument rests on OpenS100's official status within the IHO S-100 infrastructure. OpenS100 is listed as an official interim S-100 infrastructure component in IHO document HSSC16-04.5A, Annex 2, and was recognized by the S-100 Working Group as "a key component in validating the practical implementation of S-100 standards" at S-100WG10 in September 2025 [36]. The project is maintained by KHOA under IHO oversight and uses the official IHO LuaScriptingReference for portrayal catalogue implementation. Its 18 repository forks on GitHub indicate widespread use as a foundation for derivative systems. Since the identified vulnerabilities originate from architectural gaps in the standard specification rather than implementation errors, any standards-compliant implementation most likely carries the same flaw.

6.2. PC Security Configuration Gap

Implementation of the Unrestricted Lua Interpreter mitigation patch revealed an unanticipated standards-level security gap extending beyond the study's original scope, demonstrating how security implementation efforts can uncover previously undocumented specification issues requiring standards-body intervention. Static analysis of the S-101 reference PC distributed with OpenS100 identified 13 rawget() invocations across 6 source files with two distinct usage patterns: analysis reveals 11 of 13 uses (85%) serve convenience rather than technical necessity, while 2 uses (15%) are structurally mandatory within the metatable __index implementation. The S-101 reference PC implements object inheritance through Lua's metatable mechanism: within __index metamethods, standard table access causes infinite recursion because accessing a nonexistent key triggers the same function, while rawget() bypasses this metamethod invocation, enabling direct table storage access without recursion. This represents a structural requirement of Lua's metamethod system rather than an implementation choice. Analysis of S-100 Edition 5.2.0 Parts 9a (Portrayal) and 13 (Scripting) — the authoritative specification for maritime geospatial data standards — reveals a significant absence: neither part specifies permitted or prohibited Lua interfaces, leaving critical isolation decisions to each implementer.

6.3. Pathway to Standardization

The findings of this study have practical pathways for reaching international organizations responsible for electronic chart and ECDIS standards. The identified vulnerability has been assigned a Common Vulnerabilities and Exposures (CVE) identifier through the MITRE/CVE program, establishing a permanent public record accessible to ECDIS manufacturers, classification societies, and maritime regulatory bodies worldwide. CVE registration ensures the vulnerability is indexed in the National Vulnerability Database (NVD) and incorporated into commercial vulnerability management workflows used by equipment vendors. In accordance with coordinated vulnerability disclosure principles, the authors met with the main contributor of the OpenS100 project to present the research findings and identified vulnerability and agreed to integrate the security patch into the official repository. The patch is scheduled for upstream commit following acceptance of this paper and prior to publication, ensuring remediation is available to all downstream implementations before public disclosure of detailed exploitation methods. This coordinated approach balances academic transparency with responsible protection of operational maritime systems. Beyond public disclosure and developer coordination, the study recommends that the IHO mandate in future standard revisions: (1) process-level sandboxing through operating system mechanisms, (2) mandatory digital signatures and verification for PCs and FCs beyond chart data alone, and (3) defense-in-depth architecture ensuring multiple independent security layers.

6.4. Future Research

The following research directions are recommended. (1) Multi-Vendor ECDIS Verification: comprehensive ecosystem assessment requires analyzing commercial ECDIS implementations from multiple vendors to determine whether identified vulnerabilities represent systemic patterns or isolated occurrences. Such research requires industry collaboration and regulatory support to overcome proprietary code access constraints, similar to IACS Unified Requirements E26 and E27 for maritime cybersecurity introduced in 2022 [37,38]. (2) PC Vetting Pipeline: development of automated security verification infrastructure for PC distribution through IHO channels, comprising static analysis detecting prohibited API usage, dynamic sandboxed execution for behavioral analysis, cryptographic signing for authenticated distribution, and continuous monitoring for post-distribution vulnerability disclosure. (3) Maritime-Specific Security Tools: development of domain-aware static analysis tools incorporating S-100 trust models and maritime functional safety requirements. While general-purpose tools like CodeQL provide strong technical capabilities, they lack maritime domain knowledge necessary for detecting design-level vulnerabilities like the Unrestricted Lua Interpreter flaw. (4) S-100 Security Certification: supplementing current functional safety certifications with security criteria addressing design risks before the 2029 mandate.

7. Conclusions

This paper evaluated the vulnerability detection capabilities of automated static analysis tools versus expert manual review targeting the OpenS100 implementation. While automated tools identified numerous syntactic defects, they failed to detect the majority of expert-identified vulnerabilities, including the PoC-verified Unrestricted Lua Interpreter flaw enabling RCE on the tested platform. These results indicate that current functional safety certification frameworks require supplementation to address design-level cyber risks arising from structural gaps in the S-100 standard specification. Accordingly, the experimental evidence supports that IHO mandate the following security controls in future standard revisions: (1) process-level sandboxing through operating system mechanisms, (2) mandatory digital signatures and verification for PCs and FCs beyond chart data alone, and (3) defense-in-depth architecture ensuring multiple independent security layers. These recommendations align with established security principles from safety-critical domains including aviation and automotive.

As maritime digital transformation accelerates, security must be integrated from the design phase. This paper emphasizes that combining automated efficiency with domain-specific expertise is essential: automated tools provide broad syntactic defect coverage, while human domain expertise reveals the design flaws tools miss. The case study shows that a single specification-level flaw can endanger the entire global ECDIS fleet, making standards-level intervention — not just individual application fixes — necessary before the 2029 S-100 mandatory adoption deadline.

Finally, this work opens several directions: multi-vendor verification, automated vetting pipelines for portrayal catalogues, maritime-aware SAST tools, and an S-100 security certification framework. The dataset (1530 defect locations and 23 expert vulnerabilities) and withheld PoC materials are valuable assets for follow-on research under responsible disclosure.

References

Full reference list (38 sources) available in the original PDF.