Modeling the Development of Energy Network Software, Taking into Account the Detection and Elimination of Vulnerabilities

Abstract

This paper solves the problem of modeling the scheme for developing software systems, which can be used in building solutions for secure energy networks. A development scheme is proposed in a set of representations through which each program of the software complex passes, namely the following representations: idea, conceptual model, architecture, algorithm, source code, graphic code, abstract syntax tree, assembler code, machine code, byte code, executed code. The main properties of each representation are indicated, such as the form (text, graphic, programming language, binary, and decoded), development (transformation) methods, as well as vulnerabilities that are detected in it. An example of each representation is given, particularly as applied to the energy networks. The scheme elements (representations, vulnerabilities, forms, etc.) and the main operations for working with their elements (representation transformation, vulnerability injection, and detection) are presented in an analytical form. An example of a development scheme for a simple software complex of energy networks is given. The classification of vulnerabilities is introduced; it divides the vulnerabilities according to the structural level, functioning disruption, and information impact. The vulnerabilities in each of the views are substantiated using the common vulnerabilities and exposures (CVE) database. An experiment was conducted to demonstrate the vulnerability spread across representations during the development of a software complex example for the energy network. The features of the applications of the obtained results for energy networks are taken into account. The advantages, disadvantages, and limitations of the study, as well as ways to eliminate them, are discussed.

1. Introduction

1.1. Relevance

The energy sector is the most important state branch and it has critical importance in all areas of its functioning. Ensuring sustainable energy network functioning is the key to the stable existence and development of the state and its society. The energy networks included in the sector in the modern world operate on the basis of hardware solutions (power plants, generators, transformers, industrial controllers, etc.) controlled by software [1]. Random and malicious errors (rootkits, viruses, backdoors, etc.) in the program codes of technical devices can cause physical failures and accidents; these incidents can lead to power outages in cities, disruptions to the operations of critical enterprises, human casualties, etc. Thus, the problem of ensuring the energy network’s cyber stability is extremely relevant. The situation is complicated by the fact that modern energy networks have huge scales, heterogeneous subsystems, and complex mechanisms in their interactions, i.e., they consist of a whole range of programs, the security of which is, in itself, a separate problematic issue. Software bugs exploited during cyber attacks [2] on energy systems and vulnerabilities are considered the most dangerous since attackers can use them to build different attack vectors to cause maximum damage. For example, exploiting a vulnerability, CVE-2022-44037, in ECU-C power control software, can lead to an attacker gaining access to confidential information and being able to conduct a series of wireless attacks with admin rights. A similar threat exists for Locus Energy LGate as a result of a vulnerability (CVE-2016-5782).

One of the most pressing problems in the field of software security is the insufficient number of satisfactory ways to search for vulnerabilities. Existing methods can be considered suitable only for certain vulnerability types or conditions of use; for example, tracking program exceptions by “fuzzing” data in the memory of the program under test. To solve this problem, it is necessary, first of all, to investigate the very object that gives rise to it; the vulnerabilities, in this case, are static and dynamic properties (determining the life cycle in the process of developing programs and their complexes) [3]. A dynamic properties analysis will allow for a wider coverage of all possible search methods since they directly depend on what kind of vulnerability it is, and how and where it appears, which directly affects the detection. In turn, static properties provide only convenient classifications of vulnerabilities and partially form additional knowledge about them.

1.2. Formulation of the Problem

Based on the relevance of this problem, the following investigation goal involves: “Improving the information security of software complexes of energy networks in the process of their development”.

Moreover, the scientific–technical research task involves “Modeling the development of energy network software complexes taking into account the detection and mitigation of vulnerabilities”.

The subject area of the investigation can be considered the evolution of software complexes for energy networks during the program creation process and the vulnerabilities that appear in this case.

Based on the investigation goals and tasks, the following hypotheses were put forward (proven during the research):

Hypothesis 1.

Creating a full-fledged software complex is a sophisticated, multi-stage process involving transitions between multiple representations, with constantly emerging vulnerabilities from various classes.

Hypothesis 2.

The process of creating even a trivial software complex for an energy network entails a sophisticated model for transforming program representations and requires a systematic approach to its modeling.

Hypothesis 3.

Vulnerabilities can occur in almost every software complex representation.

Hypothesis 4.

The appearance of a vulnerability during the early stages of developing a software complex for energy networks leads to the spread of vulnerabilities in the later stages and significantly complicates their detection.

Confirmation of all hypotheses will mean the completion of the research task and, consequently, the achievement of the research goal.

1.3. Research Results

The main scientific results of the work are as follows.

First, a review of contemporary research in the field of program development and complex software systems was carried out. As a result, it is justified that there are no models suitable for solving the problem.

Secondly, a graphical scheme for the development of the software complex is proposed. It consists of several fundamental software complex representations, connected according to the software engineering logic. Moreover, the points of occurrence and detection of emerging or introduced vulnerabilities are indicated.

Thirdly, the development scheme is described in an analytical form, which makes it possible to apply various mathematical apparatuses to it. In addition to the schema analytic notation itself, additional operations for transforming representations, as well as introducing and detecting vulnerabilities, are introduced.

Fourth, the scheme’s applicability for software solutions in the energy network is shown (using a hypothetical example).

Fifthly, experiments were carried out to substantiate the operational viability of the scheme, in terms of transforming the software complex representations and vulnerabilities.

1.4. Novelty

The research novelty is determined by the main scientific results obtained and consists of the following:

• For the first time, representations are introduced through which any software complex passes (especially those used in an energy network), and the main properties of representations are given, i.e., purpose, form, and method of creation. At the same time, existing models either reflect only a small part of the software engineering process or do not have a sufficient degree of abstraction;
• A practical experience analysis in the field of software engineering made it possible to build a new scheme of consistent transformations between the software complex representations, thereby systematizing and supplementing similar studies;
• Unlike the existing descriptions of software engineering technology, the proposed scheme has a much greater formalization, as it has graphical and analytical forms;
• Unlike the accepted description of the development of a separate program, the proposed scheme describes the entire complex; this is especially in demand in complex systems used in the energy network;
• The introduced classification of vulnerabilities, unlike similar ones, not only has a stricter class division, but also exists in the software complex representations—from a human-oriented conceptual model to a machine-oriented code with instructions;
• The conducted experiments clearly demonstrate the characteristics of vulnerabilities, namely their static nature (in terms of their structural level) and dynamic nature (in terms of their propagation during the transformation of representations in the process of solving the simplest problem of managing the distribution of energy power); this consideration of vulnerabilities is more fundamental than similar approaches.

In a broad sense, the novelty of this paper lies in a new unified representation of the software complex development process, taking into account the different vulnerabilities, scales, and characteristics of energy networks.

1.5. Contribution (Significance)

The theoretical significance of this work is as follows. First, a scheme (in the form of a generalized model) was created that strictly describes the process of software engineering. Secondly, a set of methods for classifying vulnerabilities, which are applicable to wider types of program representations and their complexes for the energy network, has been expanded. Thirdly, the software engineering process of the developed software complex has an analytical form, thereby enhancing the formalization of this area.

The practical significance of the work is as follows. Firstly, the proposed scheme allows designing the entire process of developing program representations of any scale and complexity, which will be in demand when creating energy networks. Secondly, accounting for vulnerabilities in the scheme (including their classes, points of occurrence, and detection) allows for a more systematic and reasonable approach to their detection, thereby increasing the security of the software systems of an energy network.

1.6. Content

The structure of this paper is as follows. Section 2 provides an analytical review of relevant works on the life cycle of software development (hereinafter—SDLC), with an emphasis on applicability in the development of energy networks. Section 3 proposes a scheme for developing a software complex in graphical form. Section 4 describes the introduced classifications of the software vulnerabilities of the software complex. Section 5 provides an example of the application of a development scheme for a simple energy network. Section 6 describes in detail the software complex representations, including the analytical recordings of the properties. Section 7 proposes a scheme for developing a software complex in analytical form. In Section 8, a theoretical (retrospective-=factual) experiment is carried out to prove the validity of the concept of the proposed scheme. In Section 9, a practical experiment is carried out to demonstrate the mapping of vulnerabilities during the evolution of representations. Section 10 discusses the features of the proposed solution and compares the development scheme with analogs.

2. Overview of Works

A review of scientific articles related to the research topic was carried out in the following areas, including those relevant to energy networks. First, the development of SDLC models was examined since this is the main task of the current study. Secondly, evaluation methods based on SDLC were examined, which will increase the process efficiency and security of the resulting software systems. Thirdly, various selected approaches to the development of individual stages of the SDLC were examined, as the current study assumes the creation of a detailed development scheme. Fourth, we looked at the security of software as the basis for the security of energy networks. Finally, external effects from the use of software were examined, as within the subject area of cyber–physical systems, such effects can also have negative consequences on the functioning of energy networks.

2.1. SDLC Models

The topic of SDLC has been relevant for quite a long time [4]. This topic is of particular relevance in the energy network since the efficiency of energy infrastructure facilities depends on the quality of software development.

Many of the SDLC models that have been proposed for the general economy have resulted in costly delays in the energy network due to difficulties in coordinating the SDLC process and the software qualification process [5,6]. Therefore, SDLC modeling work for the power industry has focused on finding a compromise between the stability and security of software and its reasonable cost.

Gurianov et al. [7] considered some SDLC models and software development methodologies based on them. Thus, the methodology presented in [8] allows, based on various characteristics of the project (project size, team experience, complexity, stability of requirements, project risks, etc.), supporting the choice of the SDLC model using fuzzy logic.

Sharma and Wadhwa [9] suggested a hybrid SDLC model, which combines the strengths of the classical rational unified process model and two flexible models: Scrum and Extreme Programming. It is shown that the proposed hybrid model eliminates many of the shortcomings of its predecessors, such as low design productivity, difficulties in accommodating rapid changes in requirements, and the possibility of exceeding budgets.

The SDLC model proposed in [10] focuses on the maintainability of the software to minimize maintenance problems. It is shown that this model leads to an increase in the convenience of software products.

Kiyak [11] demonstrates the possibility of using various machine learning methods, such as clustering and regression, for SDLC modeling.

Wan et al. [12] show that SDLC models for machine learning software systems should take into account the uncertainty and randomness of machine learning systems and provide for the use of a special version of the control systems for these applications.

Akbar et al. [13] present a new SDLC model, called the AZ model, which allows for the introduction of new activities during the SDLC, overcomes the limitations of traditional models, and significantly affects the production of a quality product in a short time.

Garg et al. [14] provide an analysis of the advantages and disadvantages of some SDLC models, namely the classical waterfall model [15], waterfall iterative model [16], prototype model, spiral model, incremental prototyping model [17], V-model, and rapid application development (RAD) model [18]. It is shown that all models are acceptable for their classes of program learning.

Swacha [19] provides an overview of SDLC models; they emphasize environmental friendliness and the sustainability of programmatic learning.

Öztürk [20] present an SDLC model that is focused on saving energy consumption and temperature conditions. For this, a special programming language Eco, which is a descendant of the Java language, is proposed.

2.2. Evaluation Methods

Winne and Beikirch [21] consider a method for assessing the complexity and effort of developing a distributed real-time programmable electronic system; this method is proposed for achieving an optimal SDLC.

Ciric et al. [22] propose the inclusion of an important and relevant factor, i.e., the ability in SDLC models. Accounting for this factor leads to the need to take into account the acceptability of changes, continuous development, and close interactions of versions of the software project. As shown in [23], the importance of taking ‘ability’ into account in large software development teams increases even more.

Sakulin et al. [24] propose uing a neural network to assess the quality of a software project, the input of which receives the values of metrics characterizing the SDLC model.

2.3. SDLC Stages

Recently, great interest has been shown in the possibility of using machine learning for various stages of SDLC [25,26]. Thus, in [27], it is shown that machine learning can have fairly high efficiency at the stage of software testing. In this case, supervised learning based on the ANN (artificial neural network) and DT (decision tree) models are most often used.

Bindewald et al. [28] suggest including a machine learning model in the toolkit (tool) for the automated formation of the architecture of the OPLA-Tool software product. The model provides the developer with the opportunity to analyze individual moments of the process for optimizing programmatic learning, allowing to reduce the cost of creation.

Perini et al. [29] offer a precedent-based programmatic learning requirement ranking method that uses machine learning methods to prioritize requirements. A similar problem is solved in [30], which uses deep learning based on a convolutional neural network to classify programmatic learning requirements.

Guo et al. [31] propose using recurrent neural network models that take into account the semantics of artifacts (of requirements and domain knowledge) to create trace links.

Kim et al. [32] propose a machine learning-based approach to program classification, which makes it possible to find illegal software versions. This approach uses a random forest model with API call rates as input.

Galan et al. [33] propose a flexible SDLC model that takes into account the need for the reuse of old hardware, free open-source software training, and server and machine virtualization.

2.4. Software Security

Lee et al. [34] attempt to improve the reliability of the developed software; a model of the Bayesian belief network (BBN) is proposed, which estimates the number of errors in the software, taking into account its SDLC. The parameters and structure of the model are formed on the basis of expert assessments.

Lee and Kang [35] propose evaluating the failures of the software for the monitoring and control systems of power plants, taking into account probabilistic safety assessments. Evidence from the operational data is taken into account in the process of quantifying the probability of software failures.

Lee et al. [36] propose a method for improving the quality of SDLC by assessing and integrating the risks and cost factors. These factors include the cost of software quality control, the cost of detecting and fixing software defects, and the cost of a power plant accident caused by residual defects. In this case, Bayesian trust networks are used to estimate the number of defects.

Karg and Beckhaus [37] propose a method that considers the introduction and removal of software defects with varying degrees of detail in order to bridge the gap between classical cost accounting and specific software development models.

The use of deep learning methods for SDLC modeling was proposed in [38]. This model is used to create a deep view of software learning defects to improve the performance of failure prediction models.

Pecorelli et al. [39] suggest using machine learning methods to mitigate the data imbalance problem when solving the code smell detection problem.

Maneerat and Muenchaisri [40] propose a code smell detection by using seven machine learning algorithms, as well as cross-validation to evaluate the performance and prevent overfitting.

Garcia-Mireles [41] propose a method that takes into account the concepts of sustainability in the classification of SDLC quality models. For this purpose, it is proposed to use classification features such as purpose, area, the number of quality-related terms, and stability parameters.

Jockenhövel-Barttfeld et al. [42] propose using probabilistic safety assessments for modeling failures in the software of nuclear power plants. The assessment of the probability of failure takes into account the results of the operating experience of the system at the application functions level.

2.5. Software Effects

Kern et al. [43] propose a model that describes the cause-and-effect relationships between software products and their impacts on the resulting energy demand of the equipment, the expectations of users in meeting the requirements, and the ability of users to effectively manage the software product.

Zhu et al. [44] propose analyzing the raw data of the program code, which affects the power consumption of the software, using a deep neural network.

Anthony et al. [45] offer an SDLC model that shows how software developers can apply environmentally sustainable practices for using software applications.

Jockenhövel-Barttfeld et al. [45] propose using probabilistic safety assessments for modeling failures in the software of nuclear power plants. The assessment of the probability of failures takes into account the results of the operating experience of the system at the level of application functions.

An analysis of publications in each of the selected subfields allows us to draw the following conclusions. The SDLS models are too general, not taking into account all stages of software development, neglecting the complexity of software systems, and providing insufficient consideration of the emergence, existence, and detection of vulnerabilities. This allows them to be used for energy networks in limited conditions. The assessments used on the basis of SDLS are poorly used to assess the security of software systems, which also affects the increased cyber–physical risks from the implementation of vulnerabilities. The development of individual stages of the SDLS is only partially presented (for requirements, architecture, and partly for the source code), which will not allow such approaches (used in energy networks) as two-dimensional programming to be interconnected with them. Software safety is represented by a sufficient number of publications, which will be partially used in the current work. However, the approaches used do not allow reflecting vulnerabilities within the SDLS. Externalities from the use of software are represented by a small proportion of publications and reflect the results of using final software products, not taking into account the errors in them during the development at earlier stages (for example, in a conceptual model or architecture). Thus, the impact of shortcomings in the upper-level design of the energy network on the functioning of the low-level functionality cannot be reflected.

Moreover, based on the analysis of scientific works close to the current research problem, there are no satisfactory solutions. Thus, some do not allow modeling the development process, some do not consider aspects of secure software development, some are highly specialized (for example, only for software power consumption), and some are intended only for selecting and customizing existing models. Thus, the problem posed can be regarded as inadequately studied, necessitating further research, which has been conducted in this study.

Moreover, the results of the current work will be compared in more detail with similar results from other researchers during the discussion in Section 10.

A generalized scheme of the software development process and its complexes will be proposed in the next section.

3. Program Development Scheme

3.1. Basic Concepts

To conduct any research, it is necessary to use a conceptual apparatus that allows one to describe the progress of the work done in an intuitive and unambiguously understandable way. In this case, this is especially important because the basic terms of the subject area of research have extremely ambiguous interpretations, leading them to difficult comparisons of results and conflicting conclusions. Thus, we introduce the following (more specific and precise) definitions of the concepts used below, which will improve the unambiguity of the results of the investigation.

A software program (SW) is a concept that refers to a certain automatic procedure (specific or generalized) for solving a well-defined task related to information processing, i.e., the so-called information task. In view of manufacturability, the SW creation process consists of typical stages; within each stage, certain processes (or their combinations) produce the corresponding transformations. Thus, the SW exists in various representations (states, points of development), each of which is created on the basis of the previous one; it serves as the input for certain stages or processes and output for others.

A software program complex (SWC) is a concept that refers to a collection of SWs that interact to solve a single set of tasks used for one aim. Such SWCs are used in various large sectors with many subtasks, external influences, and high risks from the implementation of information threats, which can be attributed to almost all energy networks. At the same time, the development of SWCs involves a tree structure based on the solution of the main problem, which then diverges into many small subtasks that look similar to SWs. Thus, we will consider SWCs as associations of SWs focused on individual tasks used in the energy network.

A SWC representation (hereinafter referred to as ‘representation’) is a concept that refers to a separate stage in the evolution of a problem solution, gradually concretizing through the transition from a human-understandable to a machine-oriented form. That is, the goal of solving the problem is preserved throughout the entire process of creating the SWC, changing its form from one that a person can work with to one that can be performed automatically. At the same time, similar to any natural evolution, the development of a solution to a problem can have branches into parallel representations due to the use of processes to various kinds (for example, algorithms can be described graphically or textually, and machine or byte codes can be obtained as assemblies that are executed).

A representation purpose is a concept that means some purpose for the existence of the representation, which determines its main difference from the rest and, as a result, it is a unique form that is most suitable for working with.

A representation form is a concept that refers to the appearance of the SWC in this representation, used to create, parse, and modify the representation. Thus, the SWC architecture will be in the form of images with text inserts in a spoken language, and individual SW source codes will be in the form of text in a programming language.

Representation functionality is a concept that refers to an interconnected set of SWC functions in the representation, which defines the main logic of the work of all (existing and future) SWs. Thus, for example, the functionality of the SWC architecture describes the logic of the energy network at the subsystem and module levels, and the functionalities of SW source codes define the same logic but at the implementation levels of individual algorithms within the framework of the programming language paradigm.

A software complex development scheme is a concept that refers to a set of transitions between SWC representations from an initial idea (invented by a person) to a code ready for execution (that is, implementing the idea for automation).

To reduce the ambiguity in the division of SWC into representations, we will define the latter based on their real existence in software engineering, as well as take into account common application practices. Thus, for example, the representations via the flowcharts of algorithms have the right to exist; despite the fact that flowcharts are rarely used in the actual SW creations, they are used for documentation and are standardized. However, this practice of not using individual representations comes solely from economic considerations, overestimated ambitions, and the ability of code developers to keep algorithms in mind, ultimately negatively affecting the quality and safety of the software being created. Following the same logic, the internal representation of the byte code in the virtual machine (possibly in the form of machine instructions for the just-in-time mode, performing such a transformation at the runtime) will not be considered a separate representation, since it belongs to the runtime, and the creation of the SW in this case ends with the representation of the executable byte code.

The execution environment is a concept that refers to software and hardware environments, in which the representation (usually binary or software text) performs the functionality embedded in it. The most famous and widely used representation can be considered the source code, which is some kind of text-readable message in a special language or notation intended for a strict description of the solution procedure. This code can be executed directly (scripted) or converted into, managed, and executed by a virtual machine (byte code) or platform-specific (machine). The latter case is considered classically used when creating embedded software.

Within the framework of the introduced concepts, we immediately note that neither here nor below do we consider a specific SW form used mainly for problem specifications and providing expected results, corresponding with the declarative programming paradigm (examples of the source codes of such SWs are SQL query languages and markup HTML). Such an exception is precisely designed to remove the confusion about the concepts and paradigms used.

Vulnerability is a concept representing the differences between the initial (ideal, originally conceived) and current (intermediate or actually executed) SWC functionalities in a given representation. The differences in the form of representations, obviously, are quite legitimate, since they just serve as ways to “transport” the SWC functionality from human-oriented to a machine (that is, an automation-executing SW).

Since vulnerabilities in most cases are specifically related to cybersecurity issues, we will clarify these differences by those that lead to “illegal” changes in the processing of information flows, i.e., violations of confidentiality, integrity, and availability of information when processed by SWCs in these representations. Thus, if the initial representation has functionalities that provide one state of cybersecurity, for example, complete confidentiality of information, and the final representation has functionality that provides another, for example, loss of confidentiality, then in the process of converting representation, there is a vulnerability leading to information leakage. This implies a somewhat paradoxical statement that if the initial representation (in terms of functionality) does not specify the state of the task in terms of cybersecurity (for example, it does not seek to ensure confidentiality), then information leakage in the final representation is quite acceptable and will not be associated with a vulnerability. This statement is true, but with the caveat that it refers to the incorrect use of SWCs being used outside of their original intention, or not for their intended purpose, i.e., not under the intended conditions. Here, we can provide a rather striking “anti-example” of what is today called the vulnerabilities of the TCP/IP stack protocols. On 2 November 1988, ARPANET was attacked by a program that later became known as the “Morris worm”—6800 computers were temporarily disabled. For this, several features of the functioning of network services were used, as well as some “weak” points of computer systems, later called vulnerabilities. Taking into account the fact that ARPANET, which was the prototype of the internet, was created back in 1969 (20 years before the “legendary” DoS attack), these “vulnerabilities” were naturally due to insufficient attention to cybersecurity issues at that time.

With these considerations in mind, let us clarify the introduced concept of vulnerabilities as “differences between the initial and final representations”: “Vulnerability is a maliciously or accidentally introduced defect, which in any case manifests itself as a distortion of the functionality relative to previous Representations”. Moreover, since the idea does not have a previous representation, it can be considered “invulnerable”.

Despite the noted paradox, it can still be assumed that the introduced concepts more clearly and deeply delineate the boundaries of the subject area of research compared to the usual ones, including standardized ones. The consequence of this is a clearer understanding of both the causes, points, and consequences of the appearance of vulnerabilities, as well as how they are detected. Based on the features of the introduced representation system (namely, there are no vulnerabilities in the initial representation; representations themselves do not change, each new representation is obtained from the old one by a special process of SWC creation), the following fundamental conclusions can be drawn.

• Each new (current, next) representation contains all of the vulnerabilities of the old (previous) representation, with two exceptions (which will be discussed below), as well as additional ones introduced in the current process of the creation. As a result, the final representation stores the vulnerabilities accumulated during the creation of the intermediate representation.
• The disappearance of vulnerabilities in the process of SWC creation is possible in two cases: implicitly (when creating a new representation) and purposefully (by special actions). The first case corresponds to a random event where the differences in representations A and B are the mirror images of the differences in representations B and C, resulting in no difference in representations A and C (the “double fault” effect); such a situation can manifest itself as a result of the interactions between both individual vulnerabilities and entire information subsystems. The second case involves the use of additional means of detecting and neutralizing vulnerabilities during the SWC creation.
• Since the SWC creation goes in the direction of reducing the level of abstraction in the representation, it is obvious that any emerging vulnerability built on the same entities must have a similar level, which is its static property. The dynamic property of a vulnerability in the form of a life cycle can be defined on the basis of representations, as the path from its occurrence to detection.

According to the last conclusion made regarding abstraction levels of representations, it can be argued that the way to classify vulnerabilities can be based (among other things) on the structural level of the “origin” in the SWC. Moreover, in the classification, it is advisable to take into account its essence as the difference in functionality, and correlate with classic threats, such as the violation of confidentiality, integrity, and availability of information. A specific taxonomy of vulnerabilities will be given later.

In real practice, many representations of different software developments can be subjectively omitted, merged with others, or brought into the runtime. Thus, a small SW could be created by writing source code and compiling it to machine code, running directly on the CPU. However, if such a simplification is justified for creating the simplest SWs, then for large SWCs (especially in sectors such as the energy network), such a practice will negatively affect the cybersecurity of the processed data, since it will not allow for the effective search for vulnerabilities.

Naturally, in the course of the general evolution of software engineering, new representations may appear that are qualitatively different from the current ones; for example, applying the concept of “machine learning for code generation”.

3.2. Graphical Representation

A deep system analysis of the results of the scientific papers, as well as leveraging the author’s extensive experience in the field of software engineering, made it possible to create a software complex development scheme as a fairly generalized scheme of the life cycle of representations (hereinafter–‘scheme’), with the necessary degree of abstraction and a sufficient degree of detail, reflecting the development of the SWCs of most energy networks. The evolution graph of SWC representations (divided into stages) and their forms with potentially emerging vulnerabilities, which constitute the designated schemes in generalized forms, is shown in Figure 1 (the authors’ original results).

On the scheme, the nodes of the graph are the existing representations (they look similar to rectangles with white backgrounds), and the edges (the arrows indicate the directions) are the methods of their creation from the previous ones. Thus, the graph starts with the SWC idea representation (no. 1 in the scheme), and ends with two representations: the machine code (no. 9 in the scheme) and byte code (no. 10), each of which is ready for direct execution in the CPU (it looks similar to 3D rectangles). The script code, which is a subset of the original one (no. 5 in the scheme), can also be executed on a special interpreter in the CPU.

Such a fairly large variety of representations and transitions is precisely determined by the specifics of the complex SWCs, which are often used in energy networks. Thus, various elements of energy networks can be developed using various programming languages, for example, high-level and engineering logic using visual development languages (function block diagram of the ladder diagram), high-speed algorithms in C++, visual display tools in Java/C# languages, fast document processing and machine learning-based algorithm development in Python scripts, and controller control drivers in C and assembler languages. Moreover, to build a large energy network, it will be necessary to develop a safe conceptual model of the product, dividing it into its own architectures, taking into account the specifics of various energy sub-areas, and supporting the execution of programs on the CPU and various virtual machines.

The representation form on the scheme is indicated in its upper left corner (it looks similar to a yellow dotted rectangle) and can be one of the following: T—text, P—program, G—graphic, B—binary, D—decoded.

The vulnerability class that occurs in representations is indicated in the scheme in the lower right corner (it looks similar to a red dotted rectangle) and can be one of the following: CL—conceptual level, HL—high level, ML—middle level, LL—low level, AL—atomic level.

The classification of vulnerabilities will be described in more detail below. Let us provide a detailed description of all elements of the SWC presented in the scheme (see Figure 1).

3.3. Development Stages

Based on the historically established practice of programming, as well as the authors’ experiences of participating in the creation of large software projects, we can distinguish the following stages of creating SWCs and their constituent processes, located as conditional time axes in the upper part of the scheme:

• The solution stage is the first and is designed to create an idea for a software solution to the original problem;
• The analysis stage is designed to create a conceptual solution model for the idea of solving a problem;
• The designing stage is used to create a common architecture of solution modules for a conceptual model;
• The algorithmization stage is intended to create algorithms that perform the functions of architecture modules;
• The coding stage is designed to write module algorithms in the form of source code in programming languages;
• The coding stage is used to convert SW source code into a machine-oriented text entry;
• The assembling stage is designed to directly receive the SW machine code, which is ready to be executed on the CPU;
• The decoding stage is intended to decode machine instructions into a set of fields used by the CPU during the execution (for example, splitting an instruction for an Intel CPU to add a certain number MOV AX, 1 to the register into the MOV operation type, the register type AX, and the constant value 1).

3.4. Execution Processor

Formally, the decoding stage is not, by definition, included in the process of the SWC creation, but can be used to debug and test it on the CPU or in a special environment that emulates it. Thus, the CPU is designed to directly interpret the instructions of the machine code, the virtual machine executes the byte code, and the interpreter is designed to execute the script code. It is important to note that the virtual machine and the interpreter are just SW complexes, which are also executed by the CPU. However, within the framework of SWC modeling, they are separate independent entities.

3.5. Multitude of Relationships

From each representation, one new representation can be obtained (which is indicated by the notation “1:1”), as well as many (as indicated by the notation “1:N”). Thus, according to the conceptual model, it may be necessary to create several architectures, each of which is designed to work in its own part of the SWC. Each module of the architecture will have its own algorithm associated with it. Such an interpretation allows the scheme to be used to represent the development of one SW for solving the energy subproblem, as well as the entire SWC for the energy network. Note that it is possible that one of several representations will eventually be obtained, for example, if multiple instances of the machine code are loaded into the same address space, and decoded and executed by the CPU (which is marked with the notation “N:1”). Thus, following the scheme: representation nos. 1–3 are more in line with SWCs, representations nos. 3–10 correspond to individual SWs, and representation no. 11 is for directly executing multiple SWs on individual CPUs.

3.6. Formal Notation

In the interest of formalizing the notation of the scheme, we introduce the following designations for the previously mentioned fundamental objects of the subject area (single letter):

• R (abbr. for representation)—SWC representation;
• F (abbr. for form)—the form of the SWC representation, which can be one of the following classes: $F_T$ (for text), $F_G$ (for graphic), $F_P$ (for program), $F_B$ (for binary), $F_D$ (for decoded);
• A (abbr. for activity)—the activity or functionality of the representation (as functions, without specifying how they are written);
• V (abbr. for vulnerability)—SWC vulnerability.

We emphasize that all objects of the subject area are somehow connected to the entities of the information world.

Following the same logic, we introduce the notations for operations on objects (multi-letter): Tr (short for transformation)—the transformation of the representation in some way; Inj (short for infection)—injection of a vulnerability into the SWC representation in some way; Det (short for detection)—detection of a vulnerability in the SWC representation in some way. As a result of the actions, new objects are obtained (including those identical to the original ones).

Moreover, we will use the following fairly common (and, importantly, intuitively understandable and concise) mathematical apparatus notations:

• “∘”—action on an object (analogous to a function from one operand, which allows one to write a sequence of operations in a well-read form);
• Upper right index “n”—designation of the number of the representation;
• The right upper index “$x\to y$” is the designation of the transformation of the representation with index x to index y.
• “≡”—identity of expressions (i.e., fidelity for any values of their variables);
• “∖”—difference between objects (similar to the set subtraction);
• “$x\to y$” is an algorithm for converting object x to object y;
• “⌀”—non-existent object (may refer to a representation or a vulnerability);
• “$\mathbb{C}$”—obtaining the class of the object (may consist of subclasses, denoted as signatures in the lower right part of the symbol);
• “•”—operator for creating a new object from sub-objects (used to increase the readability of the record);
• “$:=$”—record of the algorithm for operating on objects.

Moreover, for simplification, we will simply denote representation with index k as ‘representation k’.

Based on the scheme (see Figure 1) and explanations for it, it can be argued that Hypothesis 1 is confirmed.

An important part of the scheme is the vulnerabilities that arise in it, which will be discussed in detail in the next section.

4. Vulnerabilities of the Software Complex

Based on the scheme and several previous conclusions, we propose the following three-component classification of vulnerabilities for SWCs of the energy network—${\mathbb{C}}_V$.

The combination of three ways of classifying the vulnerabilities (structural level, change in functionality, and impact on information flow) determines their general taxonomy, completely built on the basis of the proposed scheme, which indicates the integrity of the introduced methodological apparatus. Classifications can be applied independently, which allows them to be considered nested. Thus, the class of any vulnerability is determined by the set of introduced subclasses.

4.1. Structural Level Class

The scheme reflects the vulnerabilities of various classes according to their structural levels (as justified earlier), namely, as follows.

Firstly, there are CL vulnerabilities embedded in the SWC, during the first stages of its creation; for example, the lack of consideration of concepts related to user authentication in the energy distribution management system (obviously, if such a basic entity is not initially specified, then it is unlikely that it can appear in the architecture). Secondly, there are HL vulnerabilities, such as errors in the SWC architecture, e.g., violations of the general principles of the functioning of energy subsystems, a low level of information security mechanisms for the data stored in them, etc. Thirdly, there are ML vulnerabilities, such as incorrect implementations of subroutine algorithms, passing input parameters, returning from them, etc.; for example, the lack of checks for exceeding the permissible power when applying energy. Fourth, there are LL vulnerabilities, such as errors in calculations, data structures, access to them, etc.; for example, a wrong sign in the DC voltage value. Fifthly, there are AL vulnerabilities, such as errors in actions for the current program execution environment; these actions are responsible for implementing “low-level” calculations and data storage. For example, the wrong choice of processor instructions or registers when “deploying” the operation of adding variables to the CPU.

The proposed division of vulnerabilities is more than logical since each new class is inherent in its development stage [46]. Perhaps the only exception is the source code representation, since it can have both ML and LL vulnerabilities that are also inherent in the previous and subsequent representations. However, this is due to the fact that working with the source code takes up the bulk of the development time of any SW, and it, in one way or another, absorbs the surrounding representations. A special place in the scheme is occupied by graphic code representations since they combine both algorithms and the source code itself; accordingly, this leads to the appearance of ML and LL vulnerabilities at the same time.

Based on the above, the structural vulnerability class can be written as follows:

$${\left({\mathbb{C}}_V\right)}_S\equiv V_S\in \{V_{CL},V_{HL},V_{ML},V_{LL},V_{AL}\},$$

(1)

where the subscripts of the elements of the set V correspond to the abbreviation for vulnerability.

4.2. Malfunction Class

Due to the fact that the concept of vulnerability was introduced as the difference between the SWC functionality in representations (in a general sense, between the initial and final ones, and in a particular sense, a sequence of differences between intermediate ones), the appearance of a vulnerability in a certain representation can be understood as a fact that the functionality of the current representation differs from the previous one. The very essence of the concept of “difference” can be interpreted through the result of comparing the sets of functional elements of these representations, expanding the vulnerability taxonomy with the following subclasses: (1) The second representation lacks the functionality that was in the first—the vulnerability of the subclass “Functional loss”. (2) In the second representation, there is a new functionality that was absent in the first—the vulnerability of the “Functional injection” subclass. (3) The functionality of the second representation differs from the similar element of the first—the vulnerability of the subclass “Functional corruption”.

A visual graphical interpretation of such vulnerability subclasses is shown in Figure 2 (the authors’ original results).

Accordingly, the coincidence of the sets means that the vulnerability did not arise (at least when transforming these two representations); therefore, its subclass is missing because the functionality of SWC has not changed.

It should be noted that the vulnerability of the third subclass is, in a sense, identical to the vulnerabilities of the first two subclasses, since the removal of one element of the set and the addition of another can be interpreted as changing it; we will resolve this conflict by minimizing the number of vulnerabilities by prioritizing the selection of a third subclass instead of the first two.

Based on the above, the class of vulnerability violations can be written as follows:

$${\left({\mathbb{C}}_V\right)}_F\equiv V_F\in \{V_{-},V_{+},V_{\sim }\},$$

(2)

where the index “−” is the loss of the functionality, “+” is the introduction of the functionality, “∼” is the change in the functionality by the vulnerability.

4.3. Information Impact Class

Since the essence of the action of any SWC lies in some change in information (which is true for imperative programming paradigms—strictly describing the algorithm of work, as well as for declarative ones—describing the desired results without compiling steps to achieve them), then making changes to the SWC should have some effect on the final processing of information. Thus, for example, removing checks of input parameters from the SWC will lead to the appearance of new information flows that have not been processed before, and the disruption of its operation. On the other hand, an incorrect implementation of the complex parameter checking logic (for example, its implementation based on logical AND instead of logical OR) will cause the SWC to generate an error with correct input data. A third situation is also possible, which is partially close to a combination of the first two, when instead of checking the parameter for one set of values, another is used; that is, the information flow with correct input data disappeared, and the flow with incorrect data appeared (for example, an erroneous check of the high bit of a number instead of the low bit). The above considerations justify the introduction of another classification method, the most subjective of all (although it continues to have a sufficient level of formalization), namely, the impact on information flow due to the introduction of a vulnerability. It is important to note that these classes correlate quite well with the classic triad of confidentiality, availability, and integrity violations (although they operate at a more “subtle” level; instead of the global impact of the entire SWC on data, the local impact of conditionally insignificant changes in its functionality on internal information flows is taken into account), and, therefore, will be introduced as follows: (1) An analog of information confidentiality violation occurs when the data transfer to unauthorized processors, highlighting a vulnerability of the subclass“appearance of information flow”. (2) An analog of availability violation occurs when existing data do not reach the processors authorized for this), highlighting a vulnerability of the subclass “loss of information flow”. (3) An analog integrity violation occurs when data reach authorized processors, but in a modified form, highlighting a vulnerability of the subclass “change in the information flow”.

Based on the foregoing, the information impact vulnerability class can be written as follows:

$${\left({\mathbb{C}}_V\right)}_I\equiv V_I\in \{V_{-},V_{+},V_{\sim }\},$$

(3)

where the index “−” is the loss of the information flow, “+” is the appearance of the information flow, “∼” is the change in the information flow.

This classification allows us to divide the entire set of vulnerabilities into 5 × 3 × 3 = 45 classes, which can be considered sufficiently detailed. Then, the complex record of all the introduced classes as a single entity takes the following form:

$${\mathbb{C}}_V\equiv V_S•V_F•V_I\equiv {\mathbb{C}}_{SFI},$$

(4)

where ${\mathbb{C}}_{SFI}$ is a simplified notation of a combination of vulnerability classes.

Let us use the following example to demonstrate the classification. If a vulnerability is found in the authentication system algorithm for managing some energy subsystem (which corresponds to the ML vulnerability), implemented by adding a default password (corresponding to the introduction of functionality) and allowing unauthorized user objects to be authenticated for this (corresponding to the appearance of an information flow), then its composite class would be written as follows: ${\mathbb{C}}_V={\mathbb{C}}_{ML++}$.

One of the main purposes of the scheme is to model the process of developing the SWC for energy networks, which will be presented in the next section (via a clear example).

5. Applicability to Energy Network

Let us give the application of the scheme for a hypothetical example of the development of the simplest SWC for an energy network consisting of several SWs and solving the main problem—”Controlled distribution of power between consumers”. Such a particular SWC life cycle scheme is shown in Figure 3 (the authors’ original results); we will omit the indication of vulnerability classes, and indicate the presence of several representations using a postfix in the number. A brief description of each Rep in relation to the power system is given below (using the introduced formal notation):

• $R^1$—idea (in text form) of creating SWS for the controlled distribution of power between consumers.
• $R^2$—conceptual model (in graphical form with text inserts), which consists of the following elements: (1) main power source, (2) power consumers, (3) power calculation for consumers, (4) power distributors, (5) collectors for power consumption statistics. The relationship between elements can be represented in the following intuitive form: $1\to 3\to 4\to 2$ and $4\to 5$.
• $R^3$—architecture (in graphical form with text inserts) consisting of the following modules: (1) capacity management (with description: receiving and distributing to consumers), (2) analytical calculations (with description: calculation of the capacity for consumers and the collection of power consumption statistics).
• $R^{4.1}$—the first algorithm (in the form of a graphic flowchart diagram with text inserts) that implements the functionality of the second module of the analytical calculations: the logic of power calculations for consumers.
• $R^{4.2}$—the second algorithm (in the form of a graphic flowchart with text inserts) that implements the functionality of the second module of analytical calculations: the logic of collecting statistics on power consumption.
• $R^{5.1}$—the first source code (in the form of the C++ text programming language) that implements the power calculation algorithm for consumers.
• $R^{5.2}$—the second source code (in the form of the Python text programming language, which implements the algorithm for collecting power consumption statistics.
• $R^{6.1}$—the first graphic code (in the form of the function block diagram graphical programming language), which implements the functionality of the first power control module: the logic of obtaining the total power.
• $R^{6.2}$—the second graphic code (in the form of the ladder diagram’s graphical programming language), which implements the functionality of the first power management module: the logic for collecting power consumption statistics.
• $R^{7.1}$—the first abstract syntax tree also known as AST (in binary form), representing the internal representation of the compilation of the graphical code (for the first functional of the first module), which implements the logic of obtaining the total capacity.
• $R^{7.2}$—the second AST (in binary form), representing the internal representation of the compilation of the graphical code (for the second functional of the first module), which implements the logic for collecting power consumption statistics.
• $R^{7.3}$—the third AST (in binary form), representing the internal representation of the compilation of the source code (for the first functional of the second module), which implements the power calculation algorithm for consumers.
• $R^{9.1}$—the first machine code (in binary form), obtained by assembly from the first AST.
• $R^{9.2}$—the second machine code (in binary form), obtained by assembly from the second AST.
• $R^{9.3}$—the third machine code (in binary form), obtained by assembly from the third AST.
• $R^{11.1}$—the first decoded code derived from the first machine code and responsible for obtaining the power from the common channel, which is executed in the first CPU.
• $R^{11.2}$—the second decoded code, derived from the second machine code and is responsible for distributing power to consumers, which is executed in the first CPU.
• $R^{11.3}$—the third decoded code derived from the third machine code and is responsible for the power calculation for consumers, which is executed in the second CPU.
• $R^{11.4}$—the fourth decoded code, obtained from the second source code and is responsible for collecting power consumption statistics, which is executed on the Python interpreter in the second CPU.

Figure 3. Particular scheme of the life cycle of the software complex representations for a simple energy network at the development stage.

Figure 3. Particular scheme of the life cycle of the software complex representations for a simple energy network at the development stage.

Consideration of the scheme of this example allows us to draw an important conclusion regarding the safety of the operation of this energy network. If the vulnerability is embedded in the conceptual model (i.e., CL class) or architecture (i.e., HL class), then it will be reflected in all subsequent representations. At the same time, its search and correction will be more difficult, which follows from the branching of the representations. Thus, if the architecture does not contain mechanisms for the secure transmission and storage of data, then any of the algorithms will be able to transfer the data to third parties. On the other hand, a minor vulnerability in representation no. 5.2 (in Python code) will only be reflected in representation no. 11.4 (i.e., in decoded code executed in the Python interpreter), which will not be critical for the entire system, and also significantly increase the possibility of its detection and correction. Thus, if floating-point numbers are erroneously rounded when collecting statistics, this will only lead to incorrect data in the system operation report.

Based on the particular scheme for the energy network (see Figure 3) and the vulnerability example for it, it can be argued that Hypothesis 2 is confirmed.

Although schema representations are intuitive, more detailed descriptions and formalization are needed; this will be done in the next section.

6. The Software Complex Representations

Let us describe in more detail each representation of the scheme (see Figure 1). For their applicability to energy networks, we will use the cross-cutting example of the distribution of energy capacities to consumers, discussed in Section 3.

6.1. Idea (No. 1)

The purpose of the SWC idea is to reflect some idea of the SWC and its functionality with the selected characteristics and properties.

We will write the representation as $R^1$.

The form of the presentation is verbal since there is no possibility of formalization: $F^1\in \left\{F_T\right\}$.

The representation is considered the beginning of any SWC and is created as a result of the creative process in solving a large problem, its vector.

The representation cannot have vulnerabilities (as already mentioned) since it is used as a future prototype of the desired result, i.e., it is “ideal”, despite its shortcomings and miscalculations: $Inj\circ R^1=V^1,V^1\equiv V_{SFI}^1\in ⌀$.

As a result, the search for vulnerabilities here also does not make sense: $Det\circ R^1=V^1,V^1\equiv V_{SFI}^1\in ⌀$.

The description of the representation is possible by any means (mainly cognitive) since the solution does not yet have any specific form at this step.

A typical example of a representation would be the recorded (organized) results of a brainstorming session.

In an energy network, an example of an SWC in the representation could be to manage the distribution of power between consumers with control over its consumption by collecting statistics.

6.2. Conceptual Model (No. 2)

The SWC conceptual model is its representation, which defines the basic concepts, their structures, relationships, and features, indicating the direction of the solution and the approaches used. Here, it is necessary to highlight the basic semantic structure and the corresponding terminological apparatus. We will write the representation as $R^2$.

The representation form is a verbal scheme (or verbal–graphical) that is the most suitable for describing generalized models with an attached text explanation: $F^2\in \{F_T,F_G\}$.

The representation is created as a result of the synthesis of possibilities for the implementation of the idea developed by SWC through the initial conditional formalization in the direction of the chosen solution: $R^2={Tr}^{1\to 2}\circ R^1$.

Only one conceptual model is created from the main idea: $M^{1\to 2}\equiv 1:1$.

In this representation, CL vulnerabilities may appear due to an incorrect concept of the main idea: $Inj\circ R^2=V^2,V_S^2\in \left\{V_{CL}\right\}$.

Their search is possible only manually due to the extremely high level of abstraction and the uniqueness of the representation, which operates with concepts: $Det\circ R^2=V^2,V_S^2\in \left\{V_{CL}\right\}$.

For the same reasons, there are no standard representation types.

An example of a representation can be any model of a sufficient level of abstraction and having a defining character for the created SWC, with a current purpose and the most appropriate form.

In a power system, an example of an SWC in a representation would be a model consisting of a main power source, power consumers, power calculation for consumers, a power distributor, and a power consumption statistics collector.

6.3. Architecture (No. 3)

The SWC architecture is its most complete high-level representation in the form of a diagram close to the source code, described using specific features (technologies, programming languages, patterns/paradigms, implementation tools, formats, etc.). The architecture defines the overall structure of the SWC, its physical and logical modules, and their interaction. From this position, the architecture defines the areas of responsibility of the entities (as well as their relationships) of each concept introduced by the conceptual model. We will write the representation as $R^3$.

The representation form is graphical (with verbal comments): $F^3\in \{F_T,F_G\}$.

The representation is created on the basis of the conceptual model as a result of the synthesis of requirements and capabilities using the experience of an expert architect: $R^3={Tr}^{2\to 3}\circ R^2$.

From the conceptual model, it may be necessary to create several architectures for different subsystems of the developed SWC: $M^{2\to 3}\equiv 1:N$.

HL vulnerabilities may appear in this representation due to the design errors: $Inj\circ R^3=V^3,V_S^3\in \left\{V_{HL}\right\}$.

Based on the extremely complex formalization and subjectivity of the assessment, in most cases, such vulnerabilities can only be found manually: $Det\circ R^3=V^3,V_S^3\in \left\{V_{HL}\right\}$.

An example of a representation would be the description of architecture using ADLs (architecture description languages) or their potential successor in the form of UML.

In a power system, an example of an SWC in representations can be a combination of the following related modules: a power management module (receiving and distributing to consumers) and an analytical calculation module (calculating power for consumers and collecting power consumption statistics).

6.4. Algorithm (No. 4)

An algorithm can be one of the following types: a flowchart (in the form of a graph of the sequence of steps for solving a problem), a structogram (in the form of a structure of blocks for solving a problem), and pseudocode (in the form of a text description in a special language that is not yet ready for compilation).

The representation has been repurposed for a partially formalized description of algorithms or processes. Thus, the block diagram of the algorithm has a graphical form with the verbal content of its elements. The structogram is similar to the block diagram and is designed to describe algorithms compiled in accordance with the structured programming paradigm. The pseudocode can also be referred to as the algorithm representation, as it is more abstract than the source code.

We will write the representation as $R^4$.

The form of the representation can be graphical with verbal comments (for flowcharts and gram structures) or programmatic (for pseudocode): $F^4\in \{F_T,F_G,F_P\}$.

The representation is created as a result of the synthesis of algorithms from the architecture, explicitly following the purpose of its modules or subsystems $R^4={Tr}^{3\to 4}\circ R^3$.

For one architecture, it is necessary to develop several algorithms that are responsible for the functioning of the modules: $M^{3\to 4}\equiv 1:N$.

In this representation, ML vulnerabilities may appear due to the incorrect solutions of subtasks defined by the modules by the algorithms: $Inj\circ R^4=V^4,V_S^4\in \left\{V_{ML}\right\}$.

The way to search for vulnerabilities is purely manual. $Det\circ R^4=V^4,V_S^4\in \left\{V_{ML}\right\}$.

An example of a representation is a flowchart of algorithms in accordance with the standard Nassi–Shneiderman diagrams [47] and, with some amendments, the Algol family of languages (abbreviated from algorithmic language).

In an energy network, an example of an SWC in representations can be a combination of the following algorithms that implement the analytical calculation module: an algorithm for calculating power for consumers and an algorithm for collecting power consumption statistics. The logic of the capacity control module is implemented using a graphic code.

6.5. Source Code (No. 5)

The source code can be one of the following types: classic (required for compilation to the native code) and scripted (ready to be executed by the appropriate interpreters).

The source code is the main “working” representation used by programmers and the last to be influenced by humans. The purpose of the representation is to implement algorithms in the chosen programming language with subsequent debugging, support, documentation, etc.

We will write the representation as $R^5$.

The representation form is the programming language and quite accurately reflects the content of the algorithms, since it determines the step-by-step specific implementation: $F^5\in \left\{F_P\right\}$.

Following the classical scheme of software engineering, the source code is obtained from algorithms (more often a standardized flowchart and structogram, and less often from the pseudocode) during the course of the routine activities of a typical programmer: $R^5={Tr}^{4\to 5}\circ R^4$.

From one algorithm, only one corresponding to it is obtained. Source code: $M^{4\to 5}\equiv 1:1$.

Since the representation is a connecting link between the algorithms themselves and their final low-level implementations, both LL vulnerabilities and ML vulnerabilities can appear in it due to errors in the implementation of algorithms or their incorrect interpretations by the programmer. $Inj\circ R^5=V^5,V_S^5\in \{V_{ML},V_{LL}\}$.

Vulnerability search methods are applicable both manually and automatically. The former capture the area of ML vulnerabilities, while the latter—LL vulnerabilities: $Det\circ R^5=V^5$, $V_S^5\in \{V_{ML},V_{LL}\}$.

An example of a representation can be any of a wide variety of mid- and high-level imperative programming languages (Pascal, Java, and C/C++/C#-like, etc.) or any scripting languages (JavaScript, Perl, Shell Script, etc.).

Note again that, in the case of script code (as a subset of source code), this representation is ready for direct execution in the interpreter on the CPU.

In the energy network, an example of SWC in representations can involve a set of two instances of the source code that implements the algorithm for calculating the power for consumers and the algorithm for collecting statistics on power consumption. In this case, the first source code can be written for the classical C++ programming language, and the second one for the Python scripting programming language.

6.6. Graphic Code (No. 6)

This representation combines the graphical algorithms of SWC and its source code, expanding the area of programming from a simple text to a more visual one. representations can be of two types: a two-dimensional block diagram and a functional diagram, which differ from the first in the specifics of the target application. This representation is quite often used in energy networks since it is intended for the implementation of production processes, control, and the management of devices for generating, transmitting, and distributing electricity.

The representation is used in the process of two-dimensional structured programming, combining two most important, and at the same time fundamentally different, functions: graphical visualization of execution algorithms and textual software implementation of its elements. Thus, the representation is considered a symbiosis of the other two—from the algorithm and source codes. representations can be shared when creating software by engineers (non-programmers), who describe more abstract logic for solving a problem, and by programmers, who specify its less abstract and detailed implementation: thus, representation is applicable as a language of communication and interaction between specialists of these two types.

We will write the representation as $R^6$.

The representation form is a set of graphic and programming languages—program–graphics, $F^6\in \{F_G,F_P\}$.

The representation is created as a result of the synthesis of algorithms from the SWC architecture with their subsequent concretization in the programming language, $R^6={Tr}^{3\to 6}\circ R^3$.

Modifications of the representation can be made simultaneously on the graphic component and on the text component since they are represented by rigidly connected entities. Similar to the algorithms, for one architecture it is necessary to develop several graphic code representations responsible for the functioning of its modules: $M^{3\to 6}\equiv 1:N$.

Both ML vulnerabilities and LL vulnerabilities can appear in this representation. The former are associated with incorrect algorithmic solutions to problems defined by the architecture (i.e., with engineers), while the latter are associated with their implementation or interpretation (i.e., with programmers). $Inj\circ R^6=V^6,V_S^6\in \{V_{ML},V_{LL}\}$.

Both manual and automatic ways of searching for vulnerabilities are applicable. The former capture the area of ML vulnerabilities, while the latter capture LL vulnerabilities: $Det\circ R^6=V^6,V_S^6\in \{V_{ML},V_{LL}\}$.

Examples of a representation are diagrams of the DRAKON language or those used in P-programming, activity diagrams of the UML language, as well as the programming languages FBD (abbr. for function block diagram), SFC (abbr. for sequential function chart), and LD (abbr. for ladder diagram).

In a power system, an example of SWC in representations can be a combination of the following two diagrams that implement a power control module: receiving power from a common channel (on FBD) and distributing power to consumers (on LD). At the same time, in this representation, only the distribution mechanism itself is specified, and the specific values of the allocated power are determined by the algorithms that implement the analytical calculation module.

6.7. Abstract Syntax Tree (No. 7)

The representation is intermediate between the human-oriented source code and the machine-oriented assembler, and, as a result, the machine code. As a rule, it is used to transform the code during the operation of the corresponding software tools—compilers, while partially discarding meta-information that is unnecessary for the SW operation (for example, comments on the source code, types of variables, etc.).

We will write the representation as $R^7$.

The form of the representation depends quite strongly on the specific implementation of the compiler, but as a rule, it has a binary form; although in some cases, the AST can be stored in external XML or JSON files: $F^7\in \left\{F_B\right\}$.

Based on the purpose of the AST, it is obtained from the source code (during compilation): $R^7={Tr}^{5\to 7}\circ R^5$.

Moreover, since the graphic code contains the source code, the representation can be obtained from it: $R^7={Tr}^{6\to 7}\circ R^6$.

Since the representation reflects only one source code in a more machine-oriented way, then: $M^{5\to 7}\equiv 1:1$ and $M^{6\to 7}\equiv 1:1$.

The representation allows software tools to perform a deeper analysis of the SW immediately before generating the executable code and contains LL vulnerabilities: $Inj\circ R^7=V^7,V_S^7\in \left\{V_{LL}\right\}$.

The same vulnerabilities can be found in representation: $Det\circ R^7=V^7,V_S^7\in \left\{V_{LL}\right\}$.

For example, for the Python byte code, there is the Bandit tool [48], which uses plug-ins to process the AST for security issues.

Examples of a representation, in general, are any descriptions of source codes using the AST in a suitable format. As a rule, the internal structure of such a tree in each source code processing software is its own.

In the energy network, an example of SWC in representations would be a collection of three internal representations of the operation logic comprising the operational logic of the two instances of the provided graphic code and one instance of the source code. The script code that implements the algorithm for collecting statistics on power consumption is not reflected in this representation because it can be directly executed in the Python interpreter.

6.8. Assembler Code (No. 8)

The representation specifies the end registers and instructions to be executed by the processor; it also contains usernames, data segments, and other more specific information.

We will write the representation as $R^8$.

The representation form is a programming language that is already less human-oriented, but not yet suitable for machine execution: $F^8\in \left\{F_B\right\}$.

The representation is generated from the AST (which will be described later) and is often not used because concrete machine instructions ready to be executed can be created without the intermediate assembler code: $R^8={Tr}^{7\to 8}\circ R^7$.

Since the representation is derived from only one AST, then: $M^{7\to 8}\equiv 1:1$.

In this representation, LL vulnerabilities may appear due to incorrect operation of the generation module (according to the previous representation) or low-level optimization of the machine code; however, the probability of this is extremely small: $Inj\circ R^8=V^8$, $V_S^8\in \left\{V_{LL}\right\}$.

Using this representation, it is possible to search for LL vulnerabilities in a manual, time-consuming way. In some cases, automation is used: $Det\circ R^8=V^8,V_S^8\in \left\{V_{LL}\right\}$.

However, due to the fact that the assembly code is considered intermediate, their search is postponed to subsequent representations.

An example of a representation can be any low-level machine-oriented language for a given processor, for example, MASM and TASM for the x86 family, VASM for the PowerPC and ARM families.

Although the representation code is not considered executable, there are internet projects with partial CPU emulation that partially allow this:

• https://www.tutorialspoint.com/compile_assembly_online.php (accessed on 15 May 2023);
• https://www.jdoodle.com/compile-assembler-nasm-online/ (accessed on 15 May 2023).

In the energy network of the SWC example in the representation, there may be none of the three ASTs given earlier; the machine code is immediately built without the use of intermediate assembler code.

6.9. Machine Code (No. 9)

The representation involves unreadable data strictly specifying the execution of processor instructions. We will write the representation as $R^9$.

The representation form is binary: $F^9\in \left\{F_B\right\}$.

The representation is generated according to the assembler code using special software tools, i.e.,  assemblers, completely omitting all meta-information that is unnecessary for the processor to execute (for example, the names of the transition methods: $R^9={Tr}^{8\to 9}\circ R^8$.

A common practice is to generate a representation directly from the source or graphics code by compilation using the AST: $R^9={Tr}^{7\to 9}\circ R^7$.

Moreover, to speed up the work, the representation can be obtained from the byte code (including during the operation of the virtual machine, using the so-called just-in-time mechanism [49]): $R^9={Tr}^{10\to 9}\circ R^{10}$.

Similar to the source code, AST, and assembly code, only one instance of the machine code is obtained from the previous representations: $M^{7\to 9}\equiv 1:1$, $M^{8\to 9}\equiv 1:1$ and $M^{10\to 9}\equiv 1:1$.

AL vulnerabilities may appear in this representation due to the incorrect work of the assembler code or just-in-time utilities; however, this is extremely unlikely: $Inj\circ R^9=V^9$, $V_S^9\in \left\{V_{AL}\right\}$.

Although only AL vulnerabilities can be introduced during creation, it is also possible to search for LL vulnerabilities using them: $Det\circ R^9=V^9,V_S^9\in \{V_{LL},V_{AL}\}$.

This is justified by the proximity of these classes of vulnerabilities and by the fact that enough “straightforward” rules are applied to generate representations from the AST.

An example of a representation can be any binary image of an embedded device or UEFI firmware.

The code of this representation is ready for direct execution on the CPU.

In the energy network, an example of SWC in representations involves a set of three instances of the machine code, obtained from three instances of the assembler code given earlier.

6.10. Byte Code (No. 10)

The byte code is a representation similar to machine representation, but is intended to be executed on a virtual machine. The byte code is considered to have passed the syntactic and semantic analyses and is ready for immediate execution. Its feature is independent from the finished hardware on which it must run since the code does not have platform-specific features; it is completely moved to the implementation side of the virtual machine.

We will write the representation as $R^{10}$.

The representation has a binary form, similar to assembly and machine codes, but taking into account the basis of instructions for the virtual machine: $F^{10}\in \left\{F_B\right\}$.

The byte code is obtained in a similar way to the machine code: $R^{10}={Tr}^{7\to 10}\circ R^7$ and $R^{10}={Tr}^{8\to 10}\circ R^8$.

The ratio of the sets of instances of this representation and the previous ones as one-to-one: $M^{7\to 10}\equiv 1:1$ and $M^{8\to 10}\equiv 1:1$.

A distinctive feature of the byte code involves the minimization of vulnerabilities in it due to the features (from the position of information security) of the programming languages for which it is generated; in particular, they do not work with memory, access to the file system is limited, built-in verification is used, as well as automatic garbage collection, etc. AL vulnerabilities may appear in this representation: $Inj\circ R^{10}=V^{10},V_S^{10}\in \left\{V_{AL}\right\}$.

By analogy with the machine code, this representation can search for AL vulnerabilities and LL vulnerabilities: $Det\circ R^{10}=V^{10},V_S^{10}\in \{V_{LL},V_{AL}\}$.

Their search is also carried out by automatic and time-consuming manual methods.

An example of a representation would be high-level assembly code for a virtual machine: CIL (abbr. for common intermediate language) for Net and JBC (abbr. for the Java byte code) for Java.

The code of this representation is ready for direct execution by a virtual machine on the CPU.

For a cross-cutting example, the SWC of a power system is not reflected in this representation. However, if the source code for the power calculation algorithm for consumers was developed in the Java programming language, then the corresponding instance of the byte code would be present in this representation.

6.11. Executed Code (No. 11)

The representation is the most “far” from the idea and close enough to the machine code, with the exception that it reflects the SW in a decoded form, directly executed on the CPU. We will write the representation as $R^{11}$.

The representation form with decoded instructions will be as follows: $F^{11}\in \left\{F_D\right\}$.

The representation is obtained from any previous ones that are ready to be executed on the CPU: $R^{11}={Tr}^{5\to 11}\circ R^5$, $R^{11}={Tr}^{9\to 11}\circ R^9$ and $R^{11}={Tr}^{10\to 11}\circ R^{10}$.

However, since a single CPU can execute multiple instances of code in parallel, then: $M^{5\to 11}\equiv N:1$, $M^{9\to 11}\equiv N:1$, and $M^{10\to 11}\equiv N:1$.

The same vulnerabilities can appear in this representation as in the machine code and byte code: $Inj\circ R^{11}=V^{11},V_S^{11}\in \left\{V_{AL}\right\}$.

However, based on the essence of the representation, only AL vulnerabilities can be detected: $Det\circ R^{11}=V^{11},V_S^{11}\in \left\{V_{AL}\right\}$.

The representation examples are the same as for the machine code.

In a power system, an example of an SWC in a representation would be the collection of the following two memory spaces, each used to execute the SW on its own CPU. In the first space, the logic for obtaining power from a common channel and distributing power to consumers (directly in the CPU) will work; this is built using a graphic code. In the second space, the logic of two algorithms will work: calculating the power for consumers (directly in the CPU) and collecting power consumption statistics (in the Python interpreter).

By using the analytical records entered into the schema elements, you can use them to build a basic mathematical-like apparatus, which will be done in the next section.

7. Analytical Recording of the Development Scheme

The resulting analytical records corresponding to the schema (see Figure 1) with additional properties of representations and vulnerabilities are presented in

Table 1. Analytical recording of the scheme for developing a software complex.

No.	Representation	Notation	Form	Production	Vulnerability Injection	Vulnerability Detection	Hardware Runtime
1	Idea	$R^1$	$F^1\in \left\{F_T\right\}$	Absent	$V_S\in ⌀$	$V_S\in ⌀$	Absent
2	Conceptual model	$R^2$	$F^2\in \{F_T,F_G\}$	$R^2=T{r}^{1\to 2}\circ R^1$ $M^{1\to 2}\equiv 1:1$	$V_S^2\in \left\{V_{CL}\right\}$	$V_S^2\in \left\{V_{CL}\right\}$	Absent
3	Architecture	$R^3$	$F^3\in \{F_T,F_G\}$	$R^3=T{r}^{2\to 3}\circ R^2$ $M^{2\to 3}\equiv 1:N$	$V_S^3\in \left\{V_{HL}\right\}$	$V_S^3\in \left\{V_{HL}\right\}$	Absent
4	Algorithm	$R^4$	$F^4\in \{F_T,F_G,F_P\}$	$R^4=T{r}^{3\to 4}\circ R^3$ $M^{3\to 4}\equiv 1:N$	$V_S^4\in \left\{V_{ML}\right\}$	$V_S^4\in \left\{V_{ML}\right\}$	Absent
5	Source code	$R^5$	$F^5\in \left\{F_P\right\}$	$R^5=T{r}^{4\to 5}\circ R^4$ $M^{4\to 5}\equiv 1:1$	$V_S^5\in \{V_{ML},V_{LL}\}$	$V_S^5\in \{V_{ML},V_{LL}\}$	For interpreter (in the case of scripts)
6	Graphic code	$R^6$	$F^6\in \{F_G,F_P\}$	$R^6=T{r}^{3\to 6}\circ R^3$ $M^{3\to 6}\equiv 1:N$	$V_S^6\in \{V_{ML},V_{LL}\}$	$V_S^6\in \{V_{ML},V_{LL}\}$	Absent
7	Abstract Syntax Tree	$R^7$	$F^7\in \left\{F_B\right\}$	$R^7=T{r}^{5\to 7}\circ R^5$ $R^7=T{r}^{6\to 7}\circ R^6$ $M^{5,6\to 7}\equiv 1:1$	$V_S^7\in \left\{V_{LL}\right\}$	$V_S^7\in \left\{V_{LL}\right\}$	Absent
8	Assembler code	$R^8$	$F^8\in \left\{F_B\right\}$	$R^8=T{r}^{7\to 8}\circ R^7$ $M^{7\to 8}\equiv 1:1$	$V_S^8\in \left\{V_{LL}\right\}$	$V_S^8\in \left\{V_{LL}\right\}$	For emulator (partially)
9	Machine code	$R^9$	$F^9\in \left\{F_B\right\}$	$R^9=T{r}^{7\to 9}\circ R^7$ $R^9=T{r}^{8\to 9}\circ R^8$ $R^9=T^{10\to 9}\circ R^{10}$ $M^{7,8,10\to 9}\equiv 1:1$	$V_S^9\in \left\{V_{AL}\right\}$	$V_S^9\in \{V_{LL},V_{AL}\}$	For CPU
10	Byte code	$R^{10}$	$F^{10}\in \left\{F_B\right\}$	$R^{10}=T{r}^{7\to 10}\circ R^7$ $R^{10}=T{r}^{8\to 10}\circ R^8$ $M^{7,8\to 10}\equiv 1:1$	$V_S^{10}\in \left\{V_{AL}\right\}$	$V_S^9\in \{V_{LL},V_{AL}\}$	For virtual machine
11	Executed code	$R^{11}$	$F^{11}\in \left\{F_D\right\}$	$R^{11}=T{r}^{5\to 11}\circ R^5$ $R^{11}=T{r}^{9\to 11}\circ R^9$ $R^{11}=T{r}^{10\to 11}\circ R^{10}$ $M^{5,9,10\to 11}\equiv N:1$	$V_S^{11}\in \left\{V_{AL}\right\}$	$V_S^9\in \left\{V_{AL}\right\}$	Inside CPU

(the authors’ original results).

Moreover, one can specify statements that follow the logic of the scheme.

Statement 1. The initial representation of any SWC is the idea (i.e., there is no previous representation):

$$\left\{\begin{array}{c}{R}^0\in ⌀\hfill \\ R^1\notin ⌀\hfill \end{array}\right.,$$

(5)

where “$\in ⌀$” and “$\notin ⌀$” refer to the absence and existence of representations, respectively.

Statement 2. The form reflects the SWC in one representation and cannot be applied to other representations:

$$x\ne y:F^x\left(R^y\right)\in ⌀,$$

(6)

where $F^x\left(R^y\right)$ refers to representation y in form x and “$\in ⌀$” means that the form does not exist.

Statement 3. The SWC life cycle consists of transforming representations:

$$R^{k+1}=T{r}^{k\to k+1}\circ R^k,$$

(7)

where $k+1$ is the index of the new representation obtained from representation k. The index $k\to k+1$ means the transformation method.

We emphasize that since the transformation occurs without introducing vulnerabilities, it is not the basic functionality of the SWC that changes, but the form of its presentation.

Statement 4. The vulnerability of the representation refers to a change in the functionality of the SWC (regardless of the form):

$$V\equiv A^1\setminus A^k,$$

(8)

where k is the index of the current representation, and $A^x$ is the set of functionalities performed by SWC in representation x.

Statement 5. The absence of vulnerability corresponds to the identity of the representations of the functionality embedded in the idea and the functionality implemented in the system:

$$A^1\equiv A^k\iff A^1\setminus A^k=V\in ⌀,$$

(9)

where “$\in ⌀$” means that any vulnerability does not exist.

Statement 6. A vulnerability can be introduced by an operation that changes the functionality in a representation compared to the functionality conceived in the SWC idea:

$$\widehat{R}=Inj\circ R,$$

(10)

where $\widehat{R}$ is the representation with introduced vulnerability (i.e., already insecure).

Statement 7. Introducing a vulnerability into a representation does not affect its form in any way:

$$\widehat{F^x}\equiv F^x,$$

(11)

where $F^x$ is the form of the secure representation, and $\widehat{F^x}$ is the form of the representation with the introduced vulnerability.

Statement 8. A vulnerability can be found by applying a discovery operation to a representation: $V=Det\circ R$.

Naturally, not every representation is suitable for detecting all classes of vulnerabilities (for example, “miscalculations” in the conceptual model are almost impossible to find in the machine code), as the following statement will be given:

$$V^k=De{t}^k\circ R^k.$$

(12)

where index k indicates that the vulnerability and the method of its detection belong to a certain representation.

At the same time, not all vulnerabilities can be found automatically and require the use of manual labor by an expert.

Statement 9. Vulnerability detection methods interact with the representation through the same form and, therefore, can only be applied to this representation:

$$(\forall x,y:x\ne y)\Rightarrow De{t}^x\circ R^y\in ⌀,$$

(13)

where “$\in ⌀$” means that no vulnerabilities will be found in the representations of these methods.

Statement 10. The vulnerability detection operation can be written as a way of finding the difference between the functionality embedded in the idea and the functionality implemented in the current representation; at the same time, the form of the representation is only a connecting link and does not affect the difference:

$$De{t}^k:=A^1\setminus A^k,$$

(14)

where $De{t}^k$ is a way to search for vulnerabilities in representation k.

Statement 11. The entire life cycle of SWC without introducing vulnerabilities can be represented as a set of the following chains of representation transformations:

$$R^n=T{r}^{n-1\to n}\circ R^{n-1}=T{r}^{n-1\to n}\circ \dots \circ T^{1\to 2}\circ R^1.$$

(15)

where $R^n$ is the current representation, $R^1$ is the original representation (i.e., idea), $R^{n-1}$ is the intermediate representation.

Obviously, in the case of an exact implementation of the functionality of the idea, there will be no vulnerabilities in any of the following representations:

$$(F^1\equiv F^k):V^k=De{t}^k\circ R^k=A^1\setminus A^k\in ⌀,$$

(16)

which confirms the previous statements.

Statement 12. The entire SWC life cycle with the introduction of vulnerabilities (for generality, on each transformation) can be represented as a set of the following chains of representation transformations:

$$R^n=In{j}^n\circ R^n=In{j}^n\circ T{r}^{n-1\to n}\circ R^{n-1}=In{j}^n\circ T{r}^{n-1\to n}\circ \dots \circ In{j}^2\circ T^{1\to 2}\circ R^1.$$

(17)

Statement 12 allows describing the scheme in a formal form, and performing analytical calculations on it.

The proof of the vulnerabilities’ existence, as indicated in the scheme for each presentation and used in the analytical records above, will be carried out in the next section.

8. Proof of Concept

As proof of the efficiency of the scheme in terms of reflecting vulnerabilities, we present the results of a retrospective factual experiment conducted by the authors. The essence of the experiment is to analyze the bases of vulnerabilities in order to attribute the moments of their occurrences to the corresponding representations. As a result, both the existence of the representations themselves and the classes of vulnerabilities in them will be justified. The CVE database (abbr. for the English common vulnerabilities and exposures) and scientific articles from the IEEE Xplore digital library were used as information about vulnerabilities.

8.1. Idea

According to the scheme, there are no vulnerabilities in the representation. In confirmation of this, no corresponding vulnerabilities were found in the databases.

8.2. Conceptual Model

Vulnerability CVE-2022-20660 lies in the storage of the administrator password for the Cisco IP Phone (7800 series) in clear text within the flash memory. The vulnerability relates to this representation because the general concept of this phone lacks the concept of a secure store for this kind of information and cryptographic functions to ensure this. Vulnerability confirmation: https://seclists.org/fulldisclosure/2022/Jan/34 (accessed on 15 May 2023) and its class: $C_V=C_{CL-+}$.

8.3. Architecture

Vulnerability CVE-2022-32259 lies in the fact that system images for installing or updating the SINEMA Remote Connect Server product contain unit test scripts, including confidential information. The vulnerability relates to this representation because the testing subsystem was left in the architecture of the version of the product intended for distribution and operation by end users. Vulnerability confirmation: https://cert-portal.siemens.com/productcert/pdf/ssa-484086.pdf (accessed on 15 May 2023) and its class: $C_V=C_{HL++}$.

8.4. Algorithm

The vulnerability of CVE-2021-4021 lies in the uncontrolled consumption of resources by the software product for reverse engineering Radare2 (and, as a result, DoS consequences). The condition for the vulnerability is to display a section of the ELF format file (64-bit version) for the MIPS processor architecture, which has a large section and is filled with zero values. The vulnerability relates to this representation since the original product algorithms did not contain restrictions on the maximum possible analyzed sequence of zero operations (the so-called NOP instructions), which led to resource depletion. Vulnerability confirmation: https://github.com/radareorg/radare2/issues/19436 (accessed on 15 May 2023) and its class: $C_V=C_{ML-+}$. It is hard not to note the paradoxical and comical situations, which lie in the fact that a tool for analyzing code for low-level vulnerabilities (in machine code) contains vulnerabilities of a much higher level (in algorithms).

8.5. Source Code

Vulnerability CVE-2022-39288 is a crash in the fastify web framework when passing an incorrect content type in the request header. This vulnerability is related to this representation. Although the algorithm to obtain a parser for a certain type of content is correct, its implementation uses a JavaScript object as storage for such parsers. This allows any string to be passed that is the key to the object’s class property, causing the web server to crash. Vulnerability confirmation: https://hackerone.com/reports/1715536 (accessed on 15 May 2023) and its class: $C_V=C_{LL\sim +}$.

8.6. Graphic Code

This representation essentially combines two aspects: algorithms and source code. An explicit assignment of vulnerabilities in the CVE to it was found. However, several common bugs in FBL (transitioning to vulnerabilities in the representation) were described in [50], namely the following:

• Incorrect use of the timer block due to the similarity of the functionality (the TON block, abbr. for the ON delay timer—postpones the start of the event, and the TOF block, abbr. for the OFF delay timer—postpones the stop of the event);
• An erroneous order of the inputs of logical operations (so, unlike the AND block for the logical operation “AND”, for the MUX block for multiplexing, their order matters);
• Incorrect use of the inverter (often, the graphic representation of the operation in the form of a small circle leads to its unnecessary addition or erroneous omission on the diagram);
• Incorrect notation of variables, which leads to incorrect assignments or calculations (the reasons for this can be attributed to the peculiarities of the graphical development of the algorithms and code).

Article [50], in addition to confirming these vulnerabilities, describes the author’s method of structural testing to detect them. The classes of these vulnerabilities (in the order in which they are listed) are as follows: (1) $C_V=C_{ML\sim ?}$ (index “?” means that the exact class of influence on information flows needs to be clarified, as it depends on the specific FBL scheme); (2) $C_V=C_{ML\sim \sim }$; (3) $C_V=C_{ML+\sim }$ or $C_V=C_{ML-\sim }$; (4) $C_V=C_{LL\sim }$.

8.7. Abstract Syntax Tree

Vulnerability CVE-2020-15294 lies in the incorrect operation of optimization algorithms, which leads to the generation of code that dereferences (i.e., receives a value by the pointer) the same address twice, potentially leading to arbitrary code execution. The vulnerability is related to this representation because the optimization is performed on the internal representation of the input program in the compiler. Vulnerability assertion: https://www.bitdefender.com/support/security-advisories/compiler-optimization-removal-modification-security-critical-code-vulnerability-bitdefender-hypervisor-introspection-va-9339/ (accessed on 15 May 2023) and its class: $C_V=C_{LL++}$.

8.8. Assembler Code

Vulnerability CVE-2022-38453 is the loss of privacy and the potential to gain full control over the CMS8000 (medical patient monitoring device https://5.imimg.com/data5/SELLER/Doc/2021/7/NM/EK/ZD/89804963/contec-cms-8000-multipara-patient-monitor-1-.pdf) (accessed on 15 May 2023) due to the compilation of important system files with debug information. The vulnerability is related to this representation, because even with the security of all earlier representations, compiling a program with incorrect flags makes the generated assembler code vulnerable to information attacks, which can lead to critical threats in the medical field. Vulnerability confirmation: https://www.cisa.gov/uscert/ics/advisories/icsma-22-244-01 (accessed on 15 May 2023) and its class: $C_V=C_{LL++}$.

8.9. Machine Code

The vulnerability CVE-2021-38300 lies in the possibility of executing arbitrary code in the kernel space (translated into the Russian kernel space) on the MIPS architecture due to the omission in the JIT compiler of the byte code with BPF (abbr. for the English classic Berkeley packet filters—a technology of some operating systems that allows byte codes to be executed at the kernel level for the efficient and secure analysis of network traffic [51]), which leads to the generation of a machine code with an invalid offset when using conditional cBPF constructs. The vulnerability relates to this representation, since even if the source code that generates the cBPF byte code is correct, the environment for translating it into machine code (i.e., the JIT compiler) poses a threat to information security. Vulnerability confirmation: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=37cb28ec7d3a36a5bace7063a3dba633ab110f8b (accessed on 15 May 2023) and its class: $C_V=C_{LL\sim +}$.

8.10. Byte Code

The vulnerability CVE-2022-31740 lies in the incorrect generation of byte codes by the WASM compilation utility (short for WebAssembly—a tool used for running compiled codes in modern web browsers [52]) on the Arm64 processor architecture, which led to errors in register allocation and potentially dangerous failures. The vulnerability is related to this representation because it is introduced when generating an executable assembly from the correct code of a high-level programming language (for example, C++). Vulnerability confirmation: https://bugzilla.mozilla.org/show_bug.cgi?id=1766806 (accessed on 15 May 2023) and its class: $C_V=C_{AL\sim +}$.

8.11. Executed Code

Vulnerability CVE-2022-1852 is a null pointer dereference in KVM, which can lead to a denial of service. This error occurs when an invalid instruction is executed in an Intel CPU guest operating system. The vulnerability is related to this representation because it lacks the necessary checks and code to respond to incorrect machine code instructions. Vulnerability confirmation: https://bugzilla.redhat.com/show_bug.cgi?id=2089815 (accessed on 15 May 2023) and its class: $C_V=C_{AL--}$.

Based on the given and confirmed vulnerabilities that really exist (or existed) in each representation, it can be argued that the private scheme in terms of vulnerabilities is reasonable. Thus, it can be argued that Hypothesis 3 is confirmed.

Based on the scheme, its representations, and existing vulnerabilities, it is possible to conduct a direct experiment on the development of an SWC for a simple energy network tasks (as seen in the next section).

9. Experiment

To demonstrate the mapping of the SWC vulnerabilities during the evolution of its representations, let us conduct the following practical experiment. The SWC will be related to the energy network in terms of capacity management. Suppose that the task of such a system is to equally allocate power for N consumers from a single channel. For the SWC, we take the most trivial solution from one SW, designed only to produce the indicated demonstration.

The essence of SW (or in other words, the main functionality) will be to calculate and allocate power to each N consumer, if the total energy power is P. Thus, it is necessary to implement an SW that, given N and P, would set the power $P/N$ to the consumers. Naturally, if there are no consumers (i.e., when $N=0$), the SW must return an error (because the division by zero is undefined) and stop redistributing power.

Let us artificially put the vulnerability into the conceptual model and show how its display changes during the development of the SWC (up to the machine code); that is, how all representations look with and without this vulnerability. The essence of the vulnerability will be that the check of the divisor by zero is omitted (that is, the rules for performing the arithmetic operation of division are violated). The vulnerability has the class $C_V=C_{CL--}$ because the functionality is missing, which leads to the processing of incorrect data (dividing by zero will most likely lead to an execution exception, which is also not processed).

The inability to detect a vulnerability in representations other than the one in which it was introduced will also be considered a confirmation of the scheme and all previously stated ideas in this subject area. As a programming language, we will choose the classic C language, and as a CPU, we choose Intel x86-64.

Next, we briefly describe all the transformations between the representations of this SWC.

9.1. Idea

The idea of the SWC is as follows: “The software complex must correctly allocate an equal share of the power capacity from the common channel to each of the N consumers”. As stated earlier, there is no vulnerability in the representation.

9.2. Conceptual Model

The representation form is shown in Figure 4 (authors’ original results). According to the representation, the SWC initiator (operator) invokes the operation for calculating the power distribution to consumers, which, based on the argument’s value, performs the provision of power to consumer operations. At the same time, in accordance with the idea, the power calculation should be performed in accordance with the entries in the “Calculation rules” (in particular, based on arithmetic rules). However, as a result of the introduced vulnerability, the possibility of passing the 0th argument in the power calculation element was skipped, i.e., the functionality changed in the form of a vulnerability of the “loss of functionality” class (hereinafter, the area of missing functionality is marked with a red background). As a result, there is no functionality to stop the power distribution. The proportion of the missing element relative to all elements (i.e., some equivalent of the “coverage area” by the vulnerability of the representation functionality through its form) is $1/5=20\%$.

9.3. Architecture

The form of the representation is shown in Figure 5 (authors’ original results). According to the essence of the representation obtained from the conceptual model, there must be a launch point (operator) and six modules responsible for entering the number of consumers, receiving the input power channel, calculating the power of consumers, supplying power to consumers, checking calculation data, and error generation. However, due to a vulnerability in the previous representation, the last two modules (responsible for data correctness) were skipped. Note that despite the fact that—already on this representation—we can assume the loss of functionality associated with the lack of modules for checking and generating errors, the original vulnerability has already begun to “spread” over the representation; two out of seven elements are missing (i.e., the coverage area is 2/7∼29%).

9.4. Algorithm

The form of the representation is shown in Figure 6 (authors’ original results). The representation has the form of a classic block diagram, according to which (after the start element), the number of consumers (N) is entered, and the total energy power channel (P) is obtained. In the absence of a conceptual vulnerability, there should have been a block for checking the number of consumers for 0, the corresponding error output, and turning off the power distribution mechanism. After that, the power available for each consumer is calculated and distributed. Due to the vulnerability, this block is absent in the block diagram, and the proportion of the missing functionality is $3/9=\sim$33%.

9.5. Source Code

With this representation, we present one of the typical implementations of the algorithm in the C language, shown in the Listing 1: Source code:

Listing 1. Source code.

The code fully reflects the logic of the SW flowchart. Code that is not essential for execution is marked with a gray background. The area of missing functionalities, marked with a red background, consists of 5 out of 13 lines, i.e., ∼38%.

9.6. Abstract Syntax Tree

A representation is usually a collection of graphs (for example, with code structure and control flow), tables (for example, types and code symbols), and other service information; at the same time, it depends quite strongly on the specific implementation of the compiler (despite the fact that it can even be used to build the logical structure of test documents). Therefore, without losing the correctness of the experiment, it can be omitted.

9.7. Assembler Code

The representation resulting from compiling the source code (via the AST) using the compiler from Microsoft Visual Studio Community 2019 (version: Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30145 for x86) shown in the Listing 2: Assembler code. The source code instructions are specified as comments prefixed with “;”. Assembler constructs that do not produce machine instructions are marked with a gray background.

According to the fact that the assembler code of the missing functionality (the code with a red background) consists of 7 assembler lines, and the entire SW code (without comments and lines that do not produce instructions) consists of 23, the area of the changed functionality is 7/23∼30%. Thus, the area of “spread” of the trace vulnerability has decreased in comparison with the Algorithm and the source code, but it is still larger than that for the conceptual model and architecture.

Listing 2. Assembler code.

9.8. Machine Code

The representation obtained by assembling the previous one will have a binary form, which can be written using a sequence of bytes (in hexadecimal form), as follows:

55 8B EC 83 EC 08 83 7D 08 00 75 14 68 00 40 40

00 E8 9A FF FF FF 83 C4 04 E8 C2 FF FF FF EB 1E

E8 AB FF FF FF 89 45 FC 8B 45 FC 99 F7 7D 08 89

45 F8 8B 45 F8 50 E8 B5 FF FF FF 83 C4 04 8B E5

5D C3

Obviously, this form of representation is absolutely not suitable for manual analysis by an expert. By analogy with the previous representations, the area with a red background corresponds to a vulnerability (naturally, in the sense of a change in functionality). Vulnerability coverage, as the ratio of the number of bytes of missing code to the total number of bytes, is $26/66=\sim$39%.

Let us summarize the experiment with an example of this trivial SWC, which was designed to solve a problem from the energy network. First, the basic idea of converting representations from the idea to the machine code is confirmed. Secondly, the vulnerability inherent in the earlier representation “lives” in all subsequent ones. Thirdly, the dynamics of the vulnerability coverage of the representation are almost constantly growing (with the exception of the assembly code and the missing AST), as evidenced by the histogram in Figure 7 (authors’ original results).

Thus, in comparison to the representation (conceptual model), the coverage of the vulnerability on the latter (machine code) has increased by $42/20=2.1$ times. Naturally, such dynamics of vulnerabilities depend on the properties of a particular SWC. However, the fact that even for a trivial piece of SW, which is used for controlling power distribution to consumers and implemented in fairly close ways, there has been a strong increase in the coverage of the vulnerability (which in some cases will lead to “losing” malicious code among safe ones, making it significantly more difficult to detect and “isolate”), indicates the extreme importance of taking into account static as well as dynamic properties (the moment of occurrence and detection, changes in the process of converting representations, coverage dynamics, interactions with other vulnerabilities, etc.). Thus, it can be argued that Hypothesis 4 is confirmed.

Despite the rather wide investigative scope and the detailed examination of individual elements, the authors nevertheless see a number of shortcomings and ways to overcome them. Moreover, it is advisable to compare the obtained solutions with the closest analogs. All this will be done in the next section.

10. Discussion

The division of the scheme into representations is not classical and reflects the authors’ vision of the field of software engineering. However, the numerous publications by the authors on this topic, for example [3,53,54], and their rich practical experiences and experiments allow one to speak about the correctness of such a set of representations.

The classification of representation forms and the representations themselves were introduced for the first time. However, the introduced classes of forms are intuitive and have been repeatedly mentioned in various literature sources [55,56]. The authors have only undertaken the tasks of systematizing and adapting these forms.

Theoretically, the number of links between representations can be significantly increased. Thus, for example, theoretically, it is possible to execute a graphic code; from the conceptual model, one can immediately obtain the source code; or the simplest algorithms will immediately generate a byte code. However, the scheme reflects the most common practice of developing SWC, in relation to energy networks. This scheme, from the point of view of the authors, is more thoughtful and safer.

A rather “revolutionary” statement is the fact that there are no vulnerabilities in the idea. Nevertheless, such an understanding of the SWC development process allows us to more accurately introduce the concept of the essence of vulnerability, i.e., as the difference in functionalities between what is included in the idea and what is implemented in a real software product. This approach will also emphasize the fact that the correct formulation of the idea can significantly reduce the number of future potential vulnerabilities and threats in the system.

There are a sufficient number of vulnerability classifications [57] and a logical question arises as to why the article introduces another one. However, the classification proposed by the authors makes it possible to describe vulnerabilities in a multifaceted way, i.e., by the level of the implementation in SWC, by changes in the functionality, and by the actions of this functionality on the information processing. At the same time, the classification of vulnerabilities is part of the overall scheme and, thus, complements it.

The prerequisites for the introduction of the analytical notation of the schema are as follows. Visually, the scheme has formalization features (strictly distinguished elements, the logic of their relationships, an enumerable set of properties, etc.), and it is advisable to write it using the appropriate analytical formulas. This will allow for the use of appropriate mathematical tools, which will have theoretical significance, for example, in proving the solutions of various problems of transformation representations, and practical significance, i.e., in the implementation of software tools for managing the process of creating, developing, and supporting the SWC. Accounting for the analytical model for the classification of vulnerabilities will allow it to be applied to the field of information security of software engineering.

As an experiment, an SWC was taken with a trivial SW that performs an arithmetic operation and controls the supply of electrical power. However, the purpose of the experiment is the so-called proof-of-concept of the material presented earlier. A complete experiment for a large SWC with different SW requires a particular investigation. We plan to do this in future studies.

To assess the advantages and disadvantages of the proposed scheme, we will conduct its criterion comparison with close analogs considered in the process of reviewing publications on the SDLC topic. As similar schemes (or models), we will take eight of them, i.e., the most suitable for solving the task of modeling the SWL development scheme for the interests of the cyber resilience of the energy network.

As criteria $Cr$ (abbr. for criterion), the following were reasonably chosen and assessed on a point scale: “−”—does not correspond (0 points), “+/−”—corresponds partially or potentially (0.5 points), “+”—corresponds completely (1 point):

• $C{r}_1$—applicability for modeling the program development scheme; this is the main problem to be solved;
• $C{r}_2$—applicability for the vulnerability of life cycle modeling; program development modeling is done with the aim of reducing information security threats in the final products;
• $C{r}_3$—the use of an analytical schema notation; this will allow one to see the relationships between the individual stages of SWC development and make predictions about future vulnerabilities, as well as apply formal devices;
• $C{r}_4$—applicability for the full development cycle (from idea to executable code); otherwise, problems at missing developmental stages may be missed;
• $C{r}_5$—simulation accuracy; if the accuracy is insufficient, the development process will contain system errors, and the identification of vulnerabilities will have errors of I and/or II types;
• $C{r}_6$—applicability for the entire software complex; energy networks consist of a whole set of programs and require specialized modeling;
• $C{r}_7$—the possibility of using machine learning; this is a modern trend that increases the efficiency of solving problems for various purposes [58];
• $C{r}_8$—reducing the influence of the human factor; this is one of the main reasons for the violation of the correctness of software engineering and the appearance of vulnerabilities in SW [59].

A criterion comparison of the scheme proposed in the article and the closest analogs is presented (in the order of publication date) in

Table 2. Criteria comparison of the scheme and its closest analogs.

Ref.	Authors and Title	Year	Cr_1	Cr_2	Cr_3	Cr_4	Cr_5	Cr_6	Cr_7	Cr_8	Total
[37]	Karg, L.M.; Beckhaus, A. “Modelling software quality costs by adapting established methodologies of mature industries”	2007	+/−	+/−	+	+/−	+/−	+/−	+/−	+	5
[8]	Ozturk, V. “Selection of appropriate software development life cycle using fuzzy logic”	2013	+	−	−	−	+/−	+/−	+	+/−	3.5
[10]	Velmourougan, S.; Dhavachelvan, P.; Baskaran, R.; Ravikumar, B. “Software Development Life Cycle Model to Improve Maintainability of Software Applications”	2014	+/−	+/−	−	−	+	+/−	+/−	−	3
[9]	Sharma, N.; Wadhwa, M. “eXSRUP: Hybrid Software Development Model Integrating Extreme Programing Scrum & Rational Unified Process”	2015	+/−	−	−	+	−	+/−	−	−	2
[34]	Lee, S.H.; Lee, S.J.; Chu, T.-L.; Varuttamaseni, A.; Yue, M.; Yang, S.; Eom, H.S.; Cho, J.; Li, M. “Development of a Bayesian belief network model for software reliability quantification of digital protection systems in nuclear power plants”	2018	+/−	+	+/−	−	−	+	+	−	4
[13]	Akbar, M.A.; Sang, J.; Khan, A.A.; Shafiq, M.; Hussain, S.; Hu, H.; Elahi, M.; Xiang, H. “Improving the Quality of Software Development Process by Introducing a New Methodology-AZ-Model”	2018	+/−	−	−	+/−	+/−	+/−	−	+/−	2.5
[38]	Tran, H.D.; Hanh, L.T.M.; Binh, N.T. “Combining feature selection, feature learning and ensemble learning for software fault prediction”	2019	−	+	+/−	−	+/−	+/−	+	+	4.5
[36]	Lee, S.H.; Lee, S.J.; Koo, S.R.; Varuttamaseni, A.; Yue, M.; Li, M.; Cho, J.; Kang, H.G. “Optimization of software development life cycle quality for NPP safety software based on a risk-cost model”	2020	+/−	+	+	+/−	+/−	+/−	+/−	+/−	5
	Current solution	2023	+	+	+	+	+/−	+	+/−	+	7

(authors’ original results).

Based on the comparison of the proposed scheme with the eight closest analogs according to the eight criteria (see Table 2), we can draw the following conclusions. Firstly, the scheme in total best satisfies all the criteria (7 points), lagging behind the closest competitors by (7 − 5)/7∼30%. Secondly, a significant advantage of the scheme lies in the full-fledged modeling of the software complex representations in the process of its development ($C{r}_1$), and in taking into account software vulnerabilities ($C{r}_2$); at the same time, the scheme uses a formal analytical notation ($C{r}_3$), which is also not available for all analogs. Thirdly, although the modeling accuracy of the scheme ($C{r}_5$) is not completely accurate (0.5 points), improving its accuracy is one of the objectives of the author’s future research. Fourth, machine learning in the scheme is currently only applicable (0.5 points), for example, in detecting anomalies in representation instances, in classifying vulnerabilities in the current representation, or in predicting them in subsequent representations. The introduction of artificial intelligent technologies is considered a promising direction for the development of this investigation. Fifthly, the criterion, which is satisfied by the least works, is $C{r}_4$. At the same time, the scheme fully satisfies this criterion (1 point), which once again emphasizes the novelty and uniqueness of the results obtained in the work.

At the introduction, four hypotheses were put forward, each of which was confirmed: Hypothesis 1—in Section 3, Hypothesis 2—in Section 5, Hypothesis 3—in Section 8, Hypothesis 4—in Section 9.

Finally, in the next section, we will summarize the results of the current investigation.

11. Conclusions

The schematic modeling of SWCs with vulnerabilities, focusing on the evolution of their representations, was carried out in the paper. This modeling is based on the authors’ practices and is supported by real examples; it allows for a deeper look at the dynamics of the software engineering process, taking into account the emergence and detection of vulnerabilities. The work fulfilled leads to the following conclusions.

Firstly, the examination of modern research in the fields of SW and SWC life cycle modeling showed that there are no sufficiently abstract models (that preserve the essence of the processes) and system models of the subject area. It indicates the novelty of the presented authors’ approach. The closest analogs suffer from fragmentation, absence of causal relationships, and constructive conclusions. For the first time, the authors introduce a clear and non-contradictory framework for SWC creation, which is divided into stages and processes where stratified vulnerabilities continuously “emerge” and “live”.

Secondly, it was found that after each stage of the SWC creation, the types of emerging and detected vulnerabilities in most cases coincide. It allows us to conclude that each representation needs its own search method that operates with the corresponding abstraction elements. Moreover, a possible solution may be the transformation of representations from later to earlier ones; that is, their restoration, since the increase in the level of abstraction associated with this will also raise the structural level of the vulnerabilities to be detected. Some of the representations are automatically converted to the previous ones (for example, machine code to assembler code, byte code to source code), with some using manual analysis (for example, algorithms to architecture), and some using specialized software tools (for example, machine code to algorithms).

Thirdly, the obvious staging in the SWC creation and the possibility of the direct execution of some of its final representations (e.g., binary machine, byte code, and script text) suggest the following version of the view of the software engineering process, combining and completely structuring all existing representations. Thus, the full path of the SWC creation to solve a given problem can be a pyramid-shaped and step-by-step process of transforming its representations, each of which is, in some sense, complete, and can be done real or mentally. Such an approach to describing the creation of an SWC will allow, at each step, the localization of the appearance of vulnerabilities in it, and the application of specialized and effective methods to search for them.

The analytical modeling of SWCs with vulnerabilities from the point of view of the evolution of its representations, supported by real examples, allows us to take a closer look at the dynamics of the process of creating SWCs and the existence of vulnerabilities. It leads to a number of the following conclusions.

Firstly, all objects and processes mentioned in the description of the scheme, as well as their derivatives, are transferred to the category of statements and written in an analytical form. As a result, a generalized analytical model was built, which is in strict accordance with the previous calculations.

Secondly, incorporating the conversion methods between representations when creating SWC made it possible to create a private analytical model that reflects the current state of the field of software engineering.

Thirdly, the introduction of the concept of vulnerability and operations related to it (introduction, detection, classification) in the models expanded the understanding of this rather sophisticated and controversial object in the field of information security.

The conducted experiments on the occurrence of vulnerabilities and their evolution between representations substantiate the conclusions drawn.

The proposed scheme, in contrast to similar ones, allows one to consider in more detail the entire process of creating an SWC of any composition, complexity, and scale. Moreover, the analytical record of the model will allow the use of appropriate mathematical tools to control the process of the SWC creation, predict vulnerabilities, and detect them.

The general novelties of the results of this paper are as follows: a unified representation scheme of software systems with a high degree of formalization, an analytical notation of the scheme, the correct and detailed classification of vulnerabilities, and taking into account various aspects of energy networks.

Based on the confirmation of the hypotheses put forward, it can be concluded that the assigned research task was completed and the goal was achieved. The features of applying the obtained results for energy networks are also taken into account.

The continuation of the work should be directed to the theoretical and practical aspects of the methods of the inverse transformation of representations, which (as has been said many times) will significantly increase the ability to detect and neutralize vulnerabilities in SWCs. For this, the authors consider the development of a separate area of intelligent reverse engineering as promising; for example, based on genetic decompilation. The main idea of the latter lies in the iterative approximation of previous representations to such a form and content that, when directly transformed, would give exactly the given representation. As a result, it will be possible to reduce the need for super-demanded software security experts.

The applications of the obtained results are relevant to energy networks for the following reasons. Firstly, energy networks have a large prevalence, complexity, and heterogeneity of the software and hardware devices used. Secondly, electroenergy is one of the foundations for protecting the critical infrastructure of a state. Thirdly, the number of attacks on energy networks is constantly growing since their success allows an attacker to disrupt the functioning of almost any modern information system.

To complete the current science report, in the next section, we will present the research limitations and ways to eliminate them.

12. Research Limits and Ways to Eliminate Them

Here, we indicate the main limitations of modeling software systems.

Firstly, the representation of the source code (which imposes specificity on the nearest representations) is considered only for the imperative programming paradigm, the classical languages of which are C/C++/Java, etc. However, consideration for other less popular programming paradigms (e.g., declarative, SQL-specific, HTML, etc. [60]) can be obtained using a similar research methodology. In this investigation, the choice of this paradigm was associated with the specifics of the energy network development.

Secondly, in modern projects, SWCs in some views are developed by separate development teams (which are especially popular for energy networks); this is not clearly reflected in the scheme (and in the model); for example, a packet with C++ source code classes can be developed by outsourcing. Although this does not significantly affect the overall development process and emerging vulnerabilities, the authors suggest developing their model in this direction; for example, by adding a second dimension (directed in depth) to the diagram. Thus, it will be possible to further improve the adequacy of the model in terms of its reflection accuracy for the real situation of software engineering.

Thirdly, all operations for obtaining a subsequent representation from the current one belong to the field of software engineering and have large scientific and practical bases. However, obtaining the previous representation from the current one (i.e., the reverse operation) belongs to the field of software reverse engineering (the most well-known task is denoted as decompilation); presently, it is quite complex and little researched. Moreover, at the same time, as mentioned earlier, in order to successfully detect a vulnerability, one must go to this state. However, the mechanism of reverse transitions between representations (including the transition from the machine code to the idea) constitutes a separate subject of investigation by the authors (with some qualitatively new results); the results will be published in the future.