EP4036739A1 - Risque de défaillance d'un tuyau de construction - Google Patents

Risque de défaillance d'un tuyau de construction Download PDF

Info

Publication number
EP4036739A1
EP4036739A1 EP21154323.6A EP21154323A EP4036739A1 EP 4036739 A1 EP4036739 A1 EP 4036739A1 EP 21154323 A EP21154323 A EP 21154323A EP 4036739 A1 EP4036739 A1 EP 4036739A1
Authority
EP
European Patent Office
Prior art keywords
report
swd1
code fragment
software file
analysis
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP21154323.6A
Other languages
German (de)
English (en)
Inventor
Tiago Gasiba
Silvio RIENER
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Priority to EP21154323.6A priority Critical patent/EP4036739A1/fr
Priority to PCT/EP2021/085083 priority patent/WO2022161683A1/fr
Publication of EP4036739A1 publication Critical patent/EP4036739A1/fr
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/562—Static detection
    • G06F21/563—Static detection by source code analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/75—Structural analysis for program understanding
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/77—Software metrics

Definitions

  • the invention relates to a device and a method for determining a susceptibility to errors in a build pipeline
  • the build process comprises several stages and is therefore implemented using a pipeline, also known as a build pipeline, see [2].
  • a pipeline also known as a build pipeline, see [2].
  • analysis methods that perform specific tasks, such as version control, code quality analysis, and/or compilation of the software files.
  • the stages are processed sequentially, with the output of one stage feeding data into the input of the subsequent stage.
  • a deterioration in quality compared to the state before the change should be able to be determined automatically and cost-effectively.
  • the device has the effect that the quality and thus the error susceptibility of a stage of the build pipeline can be tested in a simple and automated manner and can be displayed using the signal. This enables a cost-effective and highly efficient approach to quality assurance in software development, especially when there is a change in the configuration of the build pipeline or a change in one of the analysis methods.
  • the term signal is understood to mean a message, an electrical signal, a visual or an acoustic signal with which a person or a process can be informed that the at least one stage of the build pipeline has a susceptibility to errors, since this Level that failed to generate at least one expected piece of information of the level report that should be generated when analyzing the code fragment.
  • Error susceptibility is understood to mean that the code fragment contained in the at least one software file is not recognized or not recognized as expected by the analysis method of the build pipeline stage. If the code fragment is recognized by the analysis method, the report from the analysis method would contain expected partial information, which makes it clear that the analysis method has recognized the code fragment and given indications of its existence. If the code fragment is not recognized, this increases the susceptibility to errors in at least one stage, because this affects the quality of the software project dangerous or defective code fragment has not been recognized or has not been recognized correctly.
  • the term build pipeline is understood to mean a sequential analysis in one or more stages of one or more software files that are processed in a specified build environment of the software project.
  • the analysis is accomplished by respective analysis methods that analyze, for example, a code quality, a susceptibility of the software files to known viruses or security keys.
  • Code generation i. H.
  • a machine-readable code can be generated from a programming language.
  • the code fragment is understood to mean that a code on which the analysis of the respective stage is based is provided, which contains a potential vulnerability, such as a security gap, a known virus or software code that is easy for an attacker to compromise (also referred to as code ), e.g. a password as plain text.
  • the code fragment can consist of a single line of code or command as well as multiple lines of code with one or more commands, with these multiple lines of code being distributed over multiple locations in the software file to be subsequently analyzed and containing the code fragment.
  • the code fragment can be provided in a common programming language such as C, Java, Python, or also as machine-readable binary code, the code fragment being provided in such a way that it can be integrated into at least one software file for the software project.
  • the software files of the software project are written in C++, so that the code fragment is also advantageously provided in C++.
  • the code fragment is provided in such a way that it conforms to the circumstances of the build environment is customized for the software project and can be processed by the build pipeline.
  • the error description defines one or more pieces of information to be expected, with at least one of these pieces of information to be expected in the report, which is generated during or after analysis in the build pipeline stage, is to be expected if the analysis method finds the code fragment as a security-critical fragment.
  • the error description can describe the expected partial information using a language such as XML (extensible markup language).
  • the partial information to be expected can have certain keywords or combinations of keywords individually or in combination with other features that are expected in the report, such as a position of the code fragment in the software file with which at least one of the keywords is linked.
  • a text passage "the at least one report does not reproduce any of the at least one expected piece of information" is used. In other words, this text passage means that the report does not contain any information that can be assigned or corresponds to at least one of the partial pieces of information to be expected.
  • a software file is understood to be a file in which commands are reproduced in one or more lines of code for a processor using one or more common programming languages. In this way, commands can be reproduced in the software file in several lines of code using the C programming language, which map individual steps of an algorithm.
  • the code fragment can be inserted into an existing software file as one block or inserted in several places, or the code fragment describes all lines of the software file.
  • the error description can be provided as a function of the stage of the build pipeline and/or as a function of the analysis method of the stage.
  • This development makes it possible to provide a specific error description specifically for each stage or analysis method, as a result of which the analysis information can be evaluated more reliably than, for example, with an error description that is provided for two or more stages of the build pipeline.
  • the analysis information to be expected in the report can be specified as a function of the analysis method. For example, a language that is used by the analysis result, such as German or English, can also be specifically mapped by the error description.
  • the error description can be provided as a function of at least two of the stages of the build pipeline and/or as a function of the respective analysis method of the at least two of the stages.
  • the creation unit is also designed in such a way that the at least one code fragment can be introduced into an existing software file or into a software file that is to be newly created.
  • the circumstances of a software project in particular existing software files, can be addressed in a very flexible manner.
  • the code fragment can also be stored in a separate, possibly new, file.
  • the software fragment can, for example, replace existing code with safety-critical code. The latter enables the code fragment to be introduced in such a way that the respective analysis method is not immediately enabled to change the software project and the associated software files due to the presence of another software file. This improves the quality of an assessment of whether the build pipeline is more or less error-prone.
  • the creation unit is also designed in such a way that a position specification, in particular a line number, at which the at least one code fragment can be introduced into the software file, can be transmitted to the provision unit for provision in the error description.
  • this further development has the advantage that the code fragment cannot be introduced at a fixed point but at any point in an existing software file. This increases the flexibility when using the device and also improves quality when detecting a susceptibility to errors in at least one stage, because the code fragment can be introduced into the software file in a very flexible manner.
  • the creation unit is also designed such that after the software file has been created, the build pipeline can be started by sending a trigger signal.
  • the method shows the same advantages as the corresponding device.
  • the error description is provided depending on the stage of the build pipeline and/or depending on the analysis method of the stage.
  • the error description is a function of at least two of the stages Build pipeline and / or provided depending on the respective analysis method of at least two of the stages.
  • the software file is created in such a way that the at least one code fragment is integrated into an existing software file or into a software file that is to be newly created.
  • the creation of the software file can be implemented in such a way that a position specification, in particular a line number, at which the at least one code fragment is integrated into the software file, is transmitted for provision in the error description.
  • the software file is created in such a way that after the software file has been created, a trigger signal for starting the build pipeline is transmitted.
  • the invention also relates to use of the device according to one of the above statements or of the method according to one of the above statements in a build pipeline for a software project.
  • figure 1 shows a first exemplary embodiment of a device VOR according to the invention for generating a signal SIG.
  • the figure shows a build pipeline PIPE, in which a respective analysis of one or more software files SWD1, SWD2 is carried out for a software project in a predefinable build environment SET in three stages S1, S2, S3, each using an analysis method ASV1, ASV2, ASV3 .
  • the figure 1 also shows a database DB, which stores the software files to be analyzed by the build pipeline, for example to be analyzed sequentially or together subsequently in the build pipeline.
  • the respective software file When running through the build pipeline, the respective software file is first analyzed by the first analysis method ASV1 in the first stage S1, with a first report REP1 being created for the analysis, which, for example, has analysis information AINF on errors found or performance values.
  • the analyzed software file is then transferred in changed or unchanged form from the first stage S1 to the second stage S2, in which the transferred software file is analyzed by the second analysis method ASV2.
  • the analysis result is made available by means of a second report REP2, which has analysis information AINF.
  • the software file is then transferred in changed or unchanged form from the second to the third stage S3 of the build pipeline, in which it is analyzed using the third analysis method ASV3.
  • the analysis result is provided using the third report REP3, which includes analysis information AINF.
  • the software file is then in unmodified or passed it in modified form to a downstream process, such as a database or another stage of the build pipeline (in figure 1 shown only symbolically by an arrow departing from the third stage S3).
  • a providing unit BEE provides a code fragment SWDC and an error description DESC.
  • the error description describes one or more expected pieces of partial information TINF, which is or should be generated during or after the analysis of the software file having the code fragment on the basis of the code fragment.
  • the one or more expected pieces of information TINF can be included in the report generated from the analysis.
  • the code fragment has a secret which is entered when requesting login information for a computer system and which is checked by the code fragment after it has been entered.
  • a code fragment can represent a security gap because the login information, for example the password, is in plain text and can therefore easily be determined by an attacker on the computer system.
  • FIG 2 shows the code fragment in the form of a (complete) software file SWD1, which is written in a Python programming language as an example. To make it easier to read, each line is preceded by a three-digit number.
  • An error description DESC is made available for this code fragment, which has key words which are expected in the report REP1 of the first stage, for example in the form of an error message as expected piece of information.
  • an exact line specification or an approximate line specification can be specified, based on which a localization of the critical element in the software file can be identified.
  • the error description indicates that at least one of the keywords error, warning, error, SECRET_KEY, password, key and security gap is expected as part of the information expected from the report. Furthermore, the error description states that the report must identify the code snippet, which code snippet is also referred to as a critical element, by at least one of the keywords in lines 12-14.
  • a creation unit EIE of the device stores the code fragment as a software file in the database DB.
  • the storage takes place by transferring the software file SWD1 from the device to the database DB.
  • the code fragment can have a single line or multiple lines of code, with the creation unit storing the code fragment in one of the existing software files in the database.
  • the creation unit transfers the software file SWD2 from the database DB to itself, inserts or replaces one or more lines of code in the software file SWD2 according to the code fragment, and transfers the changed software file having the code fragment SWD2(SWDC) to the database DB for storage.
  • the creation unit can note the line in which the code fragment is stored in the software file and gives this information to the provision unit to provide this line specification in the DESC error description.
  • the code fragment includes only the critical element A.
  • the build pipeline is then started by a trigger TRGIT, for example initiated by the creation unit or by the build pipeline due to a change in software files in the database DB.
  • the build pipeline fetches one or more software files that are to be analyzed stage by stage S1, S2, S3 in the build pipeline, but at least the software file that contains the code fragment.
  • the first analysis method ASV1 analyzes whether the respective software file contains code parts that can be assigned to a known virus or Trojan.
  • the second analysis method ASV2 is used to determine whether the respective software file has weak points with regard to keeping passwords or security keys secret.
  • non-safety-related analyzes are carried out using the third analysis method ASV3, in which, for example, a machine-readable file that can be executed on a computer system is created.
  • All three stages deliver a report REP1, REP2, REP3 during or after the respective analysis is carried out, which is received by a receiving unit EME.
  • the respective report shows at least one item of analysis information AINF relating to a result of the analysis of the respective stage.
  • the second report REP2 indicates here among other things following analysis information AINF: "Software file SWD1: Warning in line 013".
  • the second report REP2 After the second report REP2 has been received, its content is sent to an evaluation unit AUE for evaluation, taking into account the description of the error.
  • the result of the evaluation unit shows that one or more keywords and/or a position specification, such as a line number, match the error description.
  • the analysis method has thus recognized the code fragment or the critical element and no signal is subsequently generated by a generation unit GEE.
  • the second report shows the following content, where matches, i.e. expected partial information of the error description with analysis information, are marked by underlining in all examples: "Software file SWD1: no errors found"
  • the second report shows one of the "Error" keywords, but the line specification is missing.
  • the evaluation unit therefore recognizes that the report does not contain any of the three pieces of information that is characterized by the error description.
  • the signal SIG is therefore generated by the generation unit GEE, which indicates that the second stage has not recognized the code fragment with the critical element.
  • the generated signal thus indicates that the analysis method of the second stage is susceptible to errors, ie a security gap, at least with respect to the critical element of the code fragment.
  • a second example of the second report based on the error description above (1st example) is: "Software file SWD1: Warning on line 013 ".
  • both one of the keywords and the expected line 012-014 of the error description match the second report. Therefore, no signal is generated in this example because the critical element, i.e. the code fragment, is recognized. However, for documentation purposes, another signal may be generated indicating code snippet detection. The absence of the SIG signal thus indicates that the device has recognized the security gap created by the code fragment and that the second stage S2 of the pipeline is therefore not susceptible to errors for this security gap.
  • the error description indicates that one of the keywords DX11 formed by group 1, "Error, Warning, Error” and one of the keywords DX12 formed by group 2, "SECRET_KEY, password, key” in the second report Analysis of the code fragment is expected.
  • one of the pieces of information to be expected is TINF: "Warning” and "Key"
  • the second report reads in part: "2020:12:25_05:23 Warning: Element SECRET KEY "
  • a keyword from each of the two groups 1 and 2 is found here, so that the evaluation unit finds this when evaluating the second report and the generation unit therefore does not generate a signal.
  • the second report In addition to a respective keyword from group 1 containing the keywords "Error or Warning, Error” and group 2 containing the keywords "SECRET_KEY, password, key", the second report must also contain an indication that the code fragment is in one of the Lines 012 through 014 is found in the software file.
  • the second report reads in part: "2020:12:25_05:23 Warning: Element SECRET KEY "
  • a signal is generated because the evaluation unit does not find any line information in the report in combination with the respective keywords from groups 1 and 2, as characterized by the error description.
  • the second report reads in a modified form: "Warning: SECRET KEY item on line 13"
  • the evaluation unit detects one of the keywords from groups 1 and 2 and line 13, which is in the range of addresses 12 to 14 of the error description.
  • the second report includes information characterized by the error description.
  • the generation unit does not generate the signal SIG because the analysis method finds the keywords used by the error description according to the at least one expected piece of information in the report.
  • the second report provides the following information: "Software file SWD1; error-free analysis”.
  • the evaluation unit cannot assign the error description to the second report because none of the key words and no line information appear in the second report. Thus, the second stage analysis procedure did not detect the security vulnerability of the code fragment.
  • the generation unit then generates the signal SIG
  • the error description may be provided depending on the build pipeline stage and/or analysis method.
  • the first analysis method of the first stage delivers its report in German and the second analysis method of the second stage delivers its report in English.
  • the error description for the first level describes German keywords and the error description for the second level describes English words. Both error descriptions refer to the same code fragment.
  • the analysis unit evaluates the analysis information of the first report against the expected partial information based on the first error description.
  • the generation unit generates the signal if the evaluation shows that none of the partial information to be expected from the first error description is reproduced in the first report.
  • the evaluation unit evaluates the analysis information of the second report in an analogous manner, taking into account the second error description.
  • the generation unit generates the signal if the second report does not reflect any of the expected pieces of information based on the second error description.
  • the generation of the signal can be changed in such a way that if a signal is generated both on the basis of the first report and on the basis of the second report, a common signal is generated for both reports.
  • an error description that is used for two or more stages by the evaluation unit can also be provided.
  • the error description indicates that the report contains at least one keyword from a group "SECRET_KEY, password, key” with a line specification "013” and the keyword “DEBUG” with a range for a line specification "028-030" as expected partial information must have.
  • the square brackets [.] indicate that the line information specified within the square brackets must appear in the respective report together with the key value/words specified within the brackets, thus, for example, the keyword "SECRET_KEY” with the line 013 and the keyword “DEBUG” with one of the lines 028 to 030.
  • the keywords and/or positions belonging together can be specified by placing brackets in the error description. This approach allows multiple critical elements to be efficiently pushed into the build pipeline through a single code snippet for determining the vulnerability of a or several stages of the build pipeline can be introduced and evaluated.
  • the device and its units can be provided and implemented in software, hardware or in a combination of software and hardware.
  • individual steps, implemented by the units or by method steps can be stored in a memory as machine-readable code.
  • the memory is connected to a processor and input or output devices for communication with the database or the build pipeline via one or more buses.
  • the processor can read the code from the memory and execute it according to the steps of the inventive method or the functions realized by the units.
  • the device and the method of the invention are used, for example, in a build pipeline for a software project.
  • the device and method of the invention is in communication with the database and the build pipeline, i.e. for exchanging information such as software files and reports, but the build pipeline and the database are not part of the device or the method.
  • the signal generated by the generation unit can be visualized on a monitor for an administrator of the build pipeline to troubleshoot later.
  • the generated signal can be entered in an error message file, which is examined at a later point in time by the administrator or an error evaluation process of the build pipeline for detected error vulnerabilities in the build pipeline.
  • step S6 follows, which ends the method.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Virology (AREA)
  • Stored Programmes (AREA)
  • Debugging And Monitoring (AREA)
EP21154323.6A 2021-01-29 2021-01-29 Risque de défaillance d'un tuyau de construction Withdrawn EP4036739A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP21154323.6A EP4036739A1 (fr) 2021-01-29 2021-01-29 Risque de défaillance d'un tuyau de construction
PCT/EP2021/085083 WO2022161683A1 (fr) 2021-01-29 2021-12-09 Susceptibilité aux erreurs d'un pipeline de construction

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP21154323.6A EP4036739A1 (fr) 2021-01-29 2021-01-29 Risque de défaillance d'un tuyau de construction

Publications (1)

Publication Number Publication Date
EP4036739A1 true EP4036739A1 (fr) 2022-08-03

Family

ID=74418290

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21154323.6A Withdrawn EP4036739A1 (fr) 2021-01-29 2021-01-29 Risque de défaillance d'un tuyau de construction

Country Status (2)

Country Link
EP (1) EP4036739A1 (fr)
WO (1) WO2022161683A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005091139A2 (fr) * 2004-03-17 2005-09-29 Siemens Aktiengesellschaft Procede pour evaluer des rapports de verificateur de code

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005091139A2 (fr) * 2004-03-17 2005-09-29 Siemens Aktiengesellschaft Procede pour evaluer des rapports de verificateur de code

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Continuous Integration Improving Software Quality and Reducing Risk", 1 January 2007, ADDISON WENSLY, article PAUL M DUVALL: "Continuous Integration Improving Software Quality and Reducing Risk", pages: 1 - 318, XP055038890 *
AL-SABBAGH KHALED WALID ET AL: "Selective Regression Testing based on Big Data: Comparing Feature Extraction Techniques", 2020 IEEE INTERNATIONAL CONFERENCE ON SOFTWARE TESTING, VERIFICATION AND VALIDATION WORKSHOPS (ICSTW), IEEE, 24 October 2020 (2020-10-24), pages 322 - 329, XP033806734, DOI: 10.1109/ICSTW50294.2020.00058 *

Also Published As

Publication number Publication date
WO2022161683A1 (fr) 2022-08-04

Similar Documents

Publication Publication Date Title
EP3274825B1 (fr) Procédé et environnement d'exécution pour exécuter de façon sécurisée des instructions de programme
DE60017457T2 (de) Verfahren zur isolierung eines fehlers in fehlernachrichten
DE2515297A1 (de) Pruefsystem fuer logische netzwerke mit simulatororientiertem fehlerpruefgenerator
EP1192543A2 (fr) Procede et systeme pour determiner l'arborescence de defaillances d'un systeme technique, produit de programme informatique et support d'information lisible par ordinateur
WO2006105930A1 (fr) Systeme de diagnostic pour etablir une liste ponderee d'elements eventuellement defectueux a partir de donnees d'un vehicule et d'indications d'un client
EP2770434B1 (fr) Procédé de réalisation d'un inventaire des composants matériels rattachés à un système de test d'appareils de commande
DE102007010978A1 (de) Verfahren und Vorrichtung zur Unterstützung einer Diagnose eines elektrischen Systems mittels wahrscheinlichkeitsbasierter Fehlerkandidatenermittlung
DE112013000485T5 (de) Automatische Synthese von Einheitentests für Sicherheitstests
AT521713B1 (de) Verfahren zur Detektion sicherheitsrelevanter Datenflüsse
DE102015210651B4 (de) Schaltung und Verfahren zum Testen einer Fehlerkorrektur-Fähigkeit
EP3709166A1 (fr) Procédé et système de manipulation sécurisée de signal pour l'essai des fonctionnalités de sécurité intégrées
EP3232327A1 (fr) Procede d'essai d'un programme de commande d'un appareil de commande dans un environnement de simulation sur un ordinateur
DE102020213890A1 (de) Computerimplementiertes Verfahren und Vorrichtung zur Auswahl einer Fuzzing-Methode zum Testen eines Programmcodes
EP3134842B1 (fr) Dispositif informatique et procédé de détection des attaques sur un système technique à l'aide des événements d'une séquence d'événements
EP4036739A1 (fr) Risque de défaillance d'un tuyau de construction
DE10259794A1 (de) Verfahren und Vorrichtung für das Event Management
DE102009041098A1 (de) Verfahren zur Kennzeichnung eines in einem Computerspeichersystem enthaltenden Computerprogrammabschnitts
DE102021207872A1 (de) Kompositionelle verifikation von eingebetteten softwaresystemen
AT514731A2 (de) Verfahren zur Verifizierung generierter Software sowie Verifizierungseinrichtung zum Durchführen eines solchen Verfahrens
EP2194457B1 (fr) Dispositif de production d'un flux de données de référence marqué
EP2483776A2 (fr) Procédé et dispositif pour vérifier la configuration d'un système informatique
DE102021004427B4 (de) Verfahren zur lmplementierung und Nutzung von kryptografischem Material in wenigstens einer Systemkomponente eines informationstechnischen Systems
DE102022210264A1 (de) Verfahren zur Erkennung von potenziellen Datenexfiltrationsangriffen bei wenigstens einem Softwarepaket
DE102019128156A1 (de) Verfahren zur Überprüfung eines FPGA-Programms
DE102023132137A1 (de) Testverfahren und Testsystem zum Prüfen einer Sicherheit eines Fahrzeugs gegen Cyberangriffe

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20230204