A method and system for developing and managing automotive network security based on regulations

Abstract

The application discloses a kind of based on the process method and system of development management of automobile network security according to regulations, it is related to automobile network security technical field, the method includes: obtaining automobile network security development project information;Determine the development index of automobile network security development project, each development index belongs to research and development stage and each development index must comply with the regulations and articles;According to the research and development stage and the regulations and articles that must be complied with of each development index, the three-dimensional mapping relationship between regulations and articles-development index-research and development stage is constructed;According to the three-dimensional mapping relationship between regulations and articles-development index-research and development stage, the compliance task list of each research and development stage is constructed;Through compliance task list, whether the compliance check of each research and development stage work and deliverable is guided. Realize according to regulations and articles to guide production, solve the technical problem that current regulations and articles are disjointed with development process.

Description

Technical Field

[0001] This invention relates to the field of automotive cybersecurity technology, and in particular to a regulatory-based automotive cybersecurity development management process method and system. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] To ensure automotive cybersecurity, automotive cybersecurity development must comply with relevant regulations, which require risk assessment, vulnerability management, data security protection, and emergency response during vehicle development.

[0004] When the automotive industry conducts cybersecurity development, it uses independent vulnerability scanning and penetration testing tools to discover security vulnerabilities in the later stages of development; it uses a basic R&D process management system for task allocation and progress tracking; and it uses local risk assessment tools to identify security risks at specific stages.

[0005] The above approach has the following drawbacks: regulations and laws are disconnected from the development process, abstract regulatory requirements are difficult to translate into specific development tasks, resulting in ambiguous compliance judgments and a high risk of compliance omissions in cybersecurity development, and thus failing to guarantee the compliance of cybersecurity development. Summary of the Invention

[0006] To address the aforementioned issues, this invention proposes a regulatory-based automotive cybersecurity development management process method and system. It constructs a three-dimensional mapping relationship between regulatory provisions, development indicators, and R&D stages. Based on this mapping relationship, it builds a compliance task list for each R&D stage. This compliance task list guides the verification of compliance for each R&D stage's operations and deliverables, effectively transforming regulatory clauses into specific development tasks, ensuring full compliance throughout the development process, and avoiding compliance omissions.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: Firstly, a regulatory-based approach to automotive cybersecurity development and management is proposed, including: Obtain information on automotive cybersecurity development projects; Determine the development metrics for the automotive cybersecurity development project, the R&D stage to which each development metric belongs, and the laws and regulations to be followed for each development metric; Based on the R&D stage to which each development indicator belongs and the laws and regulations to be followed, a three-dimensional mapping relationship is constructed between laws and regulations, development indicators, and R&D stages. Based on the three-dimensional mapping relationship between regulations, development indicators, and R&D stages, a compliance task list is constructed for each R&D stage. The compliance task list guides the verification of compliance of operations and deliverables at each stage of R&D.

[0008] Furthermore, obtain the updated laws and regulations; The updated laws and regulations are used to update the three-dimensional mapping relationship between laws and regulations, development indicators, and R&D stages.

[0009] Furthermore, the compliance task list includes standardized operating procedures, compliance checkpoints, and inspection rules; Each R&D phase shall perform standardized operations in accordance with the standardized operating procedures in the compliance task list; When a task reaches a compliance checkpoint, the deliverables generated at that checkpoint are verified for compliance using the inspection rules.

[0010] Furthermore, it also acquires operational data at each stage; Analyze operational data at each stage to identify automotive cybersecurity risks; Based on the identified automotive cybersecurity risks, determine the appropriate response measures; The measures taken are used to address automotive cybersecurity risks, and the effectiveness of these measures is verified.

[0011] Furthermore, the person in charge of each research and development phase was identified; The compliance task list for each R&D phase is distributed to the person in charge of each R&D phase to guide the work of each R&D phase.

[0012] Furthermore, it also obtains operational process data, deliverable data, and compliance verification result data generated when the compliance task list guides the work at each stage of R&D. A compliance audit report is generated based on the work process data, deliverable data, and compliance verification results data.

[0013] Secondly, this invention proposes a regulatory-based automotive cybersecurity development management process system, comprising: The project information acquisition unit is used to acquire information about automotive cybersecurity development projects. The project analysis unit is used to determine the development indicators of automotive cybersecurity development projects, the R&D stage to which each development indicator belongs, and the laws and regulations that each development indicator must comply with. The mapping relationship table construction unit is used to construct a three-dimensional mapping relationship between laws and regulations, development indicators, and R&D stages based on the R&D stage to which each development indicator belongs and the laws and regulations to be followed. The compliance task list generation phase is used to construct a compliance task list for each R&D stage based on the three-dimensional mapping relationship between regulations, development indicators, and R&D stages. The compliance task list guides the verification of compliance of operations and deliverables in each R&D stage.

[0014] Thirdly, a computer device is proposed, the device comprising: A processor, adapted to execute computer programs; A computer-readable storage medium storing a computer program, which, when executed by the processor, implements a regulatory-based automotive cybersecurity development and management process method proposed in the first aspect.

[0015] Fourthly, a computer-readable storage medium is proposed, which stores a computer program adapted to be loaded and executed by a processor, which is a regulatory-based automotive cybersecurity development and management process method proposed in the first aspect.

[0016] Fifthly, a computer program product is proposed, which includes a computer program. When the computer program is executed by a processor, it implements a regulatory-based automotive cybersecurity development and management process method proposed in the first aspect.

[0017] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention proposes a regulatory-based automotive cybersecurity development management process method and system. The method constructs a three-dimensional mapping relationship between regulatory provisions, development indicators, and R&D stages. Based on this mapping relationship, a compliance task list for each R&D stage is constructed. The compliance task list guides the verification of compliance of operations and deliverables at each R&D stage, realizing the transformation of regulatory provisions into quantifiable and executable development indicators. This achieves accurate transformation of regulatory requirements into development tasks, ensuring full compliance throughout the development process and avoiding the risk of compliance omissions.

[0018] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0019] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments of this application and their descriptions are used to explain this application and do not constitute an undue limitation of this application.

[0020] Figure 1 This is a flowchart illustrating a regulatory-based automotive cybersecurity development and management process method proposed in an embodiment of the present invention. Figure 2 This is an overall flowchart of a regulatory-based automotive cybersecurity development and management process proposed in an embodiment of the present invention. Detailed Implementation

[0021] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0022] It should be noted that the following detailed descriptions are illustrative and intended to provide further explanation of this application. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains.

[0023] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments according to this application. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0024] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0025] It should be noted that all data acquisition is conducted in accordance with laws and regulations and with user consent, and the data is used legally.

[0026] To ensure automotive cybersecurity, automotive cybersecurity development must comply with relevant regulations, such as Regulation R155 issued by the United Nations World Forum for Harmonization of Vehicle Regulations (WP.29), which has been implemented in many countries and regions, including the European Union and China, and has become a core standard for compliance in the automotive industry. This regulation requires automakers to establish a cybersecurity management system throughout the entire lifecycle of vehicle development, and to conduct risk assessments, vulnerability management, data security protection, and incident response.

[0027] When the automotive industry conducts cybersecurity development, it uses independent vulnerability scanning and penetration testing tools to discover security vulnerabilities in the later stages of development; it uses a basic R&D process management system for task allocation and progress tracking; and it uses local risk assessment tools to identify security risks at specific stages.

[0028] Furthermore, some companies have developed their own cybersecurity development standards, but these standards are not systematically mapped to the R155 regulations, making compliance difficult to guarantee.

[0029] Although existing technologies offer some support for certain aspects of automotive cybersecurity development, they still have the following core shortcomings: (1) Disconnect between regulations and development process: Abstract regulatory requirements are difficult to translate into specific development tasks, and developers lack clear compliance guidelines, resulting in vague compliance judgments and a high risk of compliance omissions; (2) Severe process fragmentation: There is a lack of a unified collaborative management platform for the definition, design, testing, production and after-sales of network security development. Security control at each stage operates independently, and the efficiency of cross-departmental information transmission is low, forming "information silos". (3) Lack of closed-loop risk management: Existing risk assessment tools can only achieve risk identification and assessment, but they are not effectively linked with the disposal and verification process. High-risk hazards are difficult to completely eliminate, and the effectiveness of risk management cannot be quantified. (4) Insufficient traceability audit capability: Process data is stored in different tools or systems, lacking a unified traceability mechanism, making it difficult to respond quickly to the compliance verification requirements of regulatory authorities, and making it difficult to provide compliance evidence; (5) Poor regulatory adaptability: When regulations are revised, the existing system cannot quickly adjust the development requirements in sync, making it difficult to guarantee the long-term compliance of the system.

[0030] The aforementioned deficiencies make it difficult for automotive cybersecurity development to meet mandatory regulatory requirements, not only facing compliance and access risks, but also potentially leading to vehicle cybersecurity incidents due to inadequate security controls.

[0031] To ensure that automotive cybersecurity development meets mandatory regulatory requirements, this invention proposes a regulatory-based automotive cybersecurity development management process method. This method addresses the problems in existing technologies, such as the disconnect between regulatory provisions and development processes, independent operation of security controls at each stage, lack of closed-loop risk control, and insufficient traceability and auditing capabilities due to scattered storage of process data. Ultimately, these issues lead to automotive cybersecurity development failing to meet mandatory regulatory requirements.

[0032] This invention proposes a regulatory-based automotive cybersecurity development and management process method, applicable to, for example... Figure 2 The application system shown can be deployed on an enterprise private cloud or local server, supporting Windows Server 2019 and above, and Linux CentOS 7.0 and above operating systems. It is compatible with commonly used automotive industry R&D management tools (such as JIRA and Git), network security testing tools (such as Nessus vulnerability scanner and CANoe bus testing tools), and document management systems (such as SharePoint). Data interoperability is achieved through a RESTful API interface. Data transmission uses AES-256 encryption to ensure data security.

[0033] The application system includes: The compliance mapping center, deployed on a server, is used to store a structured regulatory clause database. The regulatory clause database stores the full text of the regulations in a hierarchical manner of chapter-clause-subclause. The compliance mapping center includes a regulatory clause parsing unit and a mapping relationship generation unit. The regulatory clause parsing unit uses natural language processing algorithms based on lexical analysis and semantic parsing to decompose the regulatory clauses into quantifiable development indicators that include frequency indicators, time limit indicators, or technical parameter indicators. The mapping relationship generation unit establishes a three-dimensional mapping relationship between regulatory clauses, development indicators, and R&D stages. The full lifecycle management module is deployed on the server and communicates with the compliance mapping center. Based on the three-dimensional mapping relationship between regulations, development indicators and R&D stages, it constructs a compliance task list for each R&D stage. The R&D stages cover the requirements definition, design and development, testing and verification, production and delivery, and after-sales maintenance of automotive R&D. Each stage's compliance task list is configured with standardized operating procedures, compliance checkpoints and deliverable templates. The compliance checkpoints are configured to automatically trigger compliance verification rules based on the three-dimensional mapping relationship table. The risk closed-loop management module is deployed on the server and communicates bidirectionally with the full lifecycle management module. It is used to execute the closed-loop management process of risk identification, risk assessment, risk handling, and effect verification of deliverables. The risk closed-loop management module has a built-in automotive network security risk library. The risk assessment adopts the risk matrix method to calculate the risk value and classify the risk level according to the degree of impact and the probability of occurrence. The traceability audit module is deployed on the server and communicates with the compliance mapping center, the full lifecycle management module, and the risk closed-loop management module. It is used to collect process data from each module in real time and establish a unique traceability number and timestamp. The process data generates data fingerprints through a hash algorithm to ensure that it is tamper-proof. It supports multi-dimensional traceability queries and automatically generates compliance audit reports that meet regulatory requirements. The collaborative interaction module, deployed on the server and communicating with the full lifecycle management module, supports multi-department hierarchical permission management and task collaboration. It assigns operation permissions according to the roles of project leader, R&D engineer, test specialist, and compliance specialist, and provides functions such as task collaboration, document upload and download, and online review, so as to realize real-time information sharing and efficient collaboration across departments. The alarm and early warning module is deployed on the server and communicates with the full lifecycle management module and the risk closed-loop management module. It is used to preset compliance thresholds, task progress thresholds and risk level thresholds, and monitor the operation status at each stage in real time. When any one or more of the information exceeds the corresponding threshold, an alarm notification is sent to ensure that the problem is responded to in a timely manner.

[0034] Based on the aforementioned application system, this invention proposes a regulatory-based automotive cybersecurity development management process method. It constructs a three-dimensional mapping relationship between regulatory provisions, development indicators, and R&D stages. Based on this mapping relationship, it builds a compliance task list for each R&D stage. This compliance task list guides the verification of compliance for each R&D stage's operations and deliverables, transforming regulatory clauses into quantifiable and executable development indicators. This achieves precise conversion of regulatory requirements into development tasks, ensuring full compliance throughout the development process and avoiding compliance omissions.

[0035] like Figure 1 , Figure 2 As shown in the embodiment of the present invention, a regulatory-based automotive cybersecurity development and management process method includes: S1: Obtain information on automotive cybersecurity development projects; S2: Determine the development indicators for the automotive cybersecurity development project, the R&D stage to which each development indicator belongs, and the laws and regulations to be followed for each development indicator; S3: Based on the R&D stage to which each development indicator belongs and the laws and regulations to be followed, construct a three-dimensional mapping relationship between laws and regulations, development indicators, and R&D stages; S4: Based on the three-dimensional mapping relationship between regulations, development indicators, and R&D stages, construct a compliance task list for each R&D stage; S5: Use a compliance task list to guide the verification of compliance of operations and deliverables at each stage of R&D.

[0036] In some embodiments, automotive cybersecurity development project information includes vehicle model, development cycle, participating departments, and the versions of regulations to be followed.

[0037] The vehicle model identifier is used to uniquely identify the development project and is generated using the company's internal coding rules, such as "PRJ-2024-001". The R&D cycle records the planned start time and expected end time of the project, in months. The participating departments record the organizational structure information involved in the project, including the R&D department, testing department, after-sales maintenance department, etc., clearly defining the division of responsibilities and collaborative relationships of each department.

[0038] Project information also includes the vehicle's technical parameters, such as network architecture topology diagrams, a list of key ECUs, communication bus types (CAN, LIN, FlexRay, Ethernet, etc.), in-vehicle operating system types, and V2X communication capabilities. These technical parameters provide foundational data for subsequent risk identification and compliance task customization.

[0039] This invention also generates a unique project ID based on the project information, establishing a data association foundation for all subsequent operations.

[0040] In this embodiment of the invention, the full text of each regulation is obtained in advance, and the full text of each regulation is stored in a structured manner according to the "chapter-clause-sub-clause" to generate a hierarchical regulation tree; core compliance requirements are manually annotated, and relevant materials such as official interpretation documents and industry implementation guidelines are uploaded; Natural language processing algorithms are used to break down regulatory clauses into development indicators (such as breaking down "vulnerability management requirements" into "vulnerability scanning frequency ≥ once per month" and "high-risk vulnerability repair time limit ≤ 72 hours"). After manual review and confirmation, these indicators are linked to the five major R&D stages to form a three-dimensional mapping relationship between regulatory clauses, development indicators, and R&D stages, and then stored in the regulatory database.

[0041] Taking Regulation R155 as an example, the process of forming a three-dimensional mapping relationship between regulatory clauses, development indicators, and R&D phases includes: Lexical analysis is used to break down legal provisions into word units. The lexical analysis employs the jieba word segmentation tool, combined with a professional dictionary in the field of automotive cybersecurity, to accurately segment the legal text. The professional dictionary contains over 300 specialized terms such as "vulnerability management," "penetration testing," "key injection," "ECU," and "CAN bus," ensuring accurate word segmentation.

[0042] The system identifies quantification requirements within word units through semantic parsing. Semantic parsing employs Named Entity Recognition (NER) technology to identify time expressions, frequency expressions, numerical expressions, and technical parameter expressions in regulatory clauses. For example, regarding clause 7.2.4.2 of Regulation R155, which states that "a vulnerability management process should be established to ensure that vulnerabilities are patched within a reasonable timeframe," the system identifies "reasonable timeframe" as a time constraint expression and quantifies it according to industry standards as "high-risk vulnerability patching timeframe ≤ 72 hours, medium-risk vulnerability patching timeframe ≤ 7 days, low-risk vulnerability patching timeframe ≤ 30 days."

[0043] Quantifiable requirements are extracted as quantifiable development metrics, and these metrics are then linked to corresponding R&D stages. These quantifiable development metrics include frequency metrics, time-limit metrics, and technical parameter metrics. Frequency metrics include, for example, "vulnerability scanning frequency ≥ once per month" and "penetration testing frequency ≥ once per quarter." Time-limit metrics include, for example, "high-risk vulnerability remediation time limit ≤ 72 hours" and "security incident response time limit ≤ 24 hours." Technical parameter metrics include, for example, "key length ≥ 256 bits," "encryption algorithm using AES-256," and "log retention time ≥ 180 days."

[0044] The R&D phase comprises five stages: requirements definition, design and development, testing and verification, production delivery, and after-sales maintenance. Based on the semantic characteristics of development metrics, the system automatically determines their corresponding R&D stage. The determination rules are based on a pre-set knowledge base containing over 200 mapping rules between development metrics and R&D stages. For example, metrics related to "vulnerability scanning" are automatically associated with the testing and verification and after-sales maintenance stages; metrics related to "key injection" are automatically associated with the production delivery stage; and metrics related to "threat modeling" are automatically associated with the requirements definition and design and development stages.

[0045] Simultaneously, the corresponding legal provision number, full text of the provision, and link to the official interpretation document for each development indicator are recorded to establish a traceable correspondence. The legal provision number adopts a standard format, for example, "R155-7.2.4.2" represents Article 2 of Section 2, Chapter 7 of Regulation R155.

[0046] The three-dimensional mapping table of regulations / legal provisions, development indicators, and R&D stages includes three fields: Regulation / Legal Provision Number, Development Indicator Number, and R&D Stage Identifier. The Regulation / Legal Provision Number field stores information such as the regulation / legal provision number, clause number, full text of the clause, revision version number, and effective date. The Development Indicator Number field stores information such as the indicator name, quantification standard, inspection rules, priority level, and responsible department. The R&D Stage Identifier field stores information such as the stage name, stage start and end dates, prerequisite dependencies, and required deliverables.

[0047] For example, regarding Article 7.2.4.2 of the R155 regulation, the mapping table records: the regulation article number "R155-7.2.4.2", the corresponding development indicator number "IND-001" (indicator name "vulnerability scanning frequency ≥ once per month"), and this indicator is associated with the development stage identifiers "STAGE-03" (testing and verification stage) and "STAGE-05" (after-sales maintenance stage).

[0048] After the 3D mapping table is generated, an integrity check is automatically performed. The check rules include: verifying that all mandatory provisions of Regulation R155 are covered; verifying that each development indicator is associated with at least one development phase; and verifying for duplicate or conflicting mappings. If the check fails, the system generates a check report, marks the missing or conflicting entries, and sends a notification to the administrator.

[0049] The present invention can also extract the regulations to be followed from the regulatory database for automotive cybersecurity development projects, and the corresponding three-dimensional mapping relationship between the regulations, development indicators and R&D stages, as the three-dimensional mapping relationship between the regulations, development indicators and R&D stages of automotive cybersecurity development projects; based on the three-dimensional mapping relationship between the regulations, development indicators and R&D stages, a compliance task list for each R&D stage is constructed.

[0050] In some embodiments, the system is grouped by R&D stage, extracts all development metrics associated with each stage, and automatically generates a compliance task list for that stage. The compliance task list includes standardized operating procedures, compliance checkpoints, and inspection rules. The standardized work process defines the specific tasks and steps to be performed in this stage, the logical dependencies between the steps, and the input and output requirements for each step; Compliance verification key points are set at critical nodes in each stage to trigger automated compliance checks. The setting of key points is based on a risk-oriented principle, prioritizing verification points in high-risk areas and nodes where regulations mandate compliance. For example, a compliance verification key point is set after the "analyze scan results" step in the testing and verification phase, and after the "key injection" step in the production delivery phase. Each key point is configured with attributes such as trigger conditions, verification objects, and verification timing. The inspection rules define the specific judgment logic for compliance verification and use a rule engine to achieve automated verification. The rule engine supports various judgment methods, including logical operations (AND, OR, NOT), numerical comparisons (>, <, =, ≥, ≤), string matching, regular expressions, and time calculations. For example, for the development metric "high-risk vulnerability remediation time limit ≤ 72 hours", the inspection rule is defined as follows: extract the vulnerability discovery timestamp field "vulnerability_detected_time", extract the vulnerability remediation completion timestamp field "vulnerability_fixed_time", calculate the time difference "time_diff = vulnerability_fixed_time - vulnerability_detected_time", and judge "time_diff ≤ 72 hours". If the judgment result is True, the verification passes; if it is False, the verification fails and the non-compliance item is recorded.

[0051] Each task in the compliance task list is configured with attributes such as task number, task name, task description, task manager, collaborators, completion deadline, deliverable template, and reference links to ensure that the task is executable and traceable. The task manager is designated from the personnel list of participating departments, and the system automatically sends task notifications.

[0052] Each R&D phase shall perform standardized operations in accordance with the standardized operating procedures in the compliance task list; When a task reaches a compliance checkpoint, the deliverables generated at that checkpoint are verified for compliance using the inspection rules.

[0053] In some embodiments, a person in charge for each research and development phase is also identified; The compliance task list for each R&D phase is distributed to the person in charge of each R&D phase to guide the work of each R&D phase.

[0054] Specifically, each R&D phase follows standardized operating procedures outlined in the compliance task list. The responsible personnel for each R&D phase receive the compliance task list via the system's web interface or mobile app, view task details, download operation guidance documents and deliverable templates, and execute tasks according to the standardized operating procedures.

[0055] During task execution, the system records process data in real time, including task start time, executors, operation logs, intermediate results, and deliverable upload records. The operation logs are stored in a structured format, containing fields such as operation timestamp, operator ID, operation type, operation object, and operation result, ensuring full traceability.

[0056] When each stage reaches the critical compliance verification point, the deliverable data for that stage is verified using the aforementioned inspection rules. When task execution reaches the critical compliance verification point, the system automatically triggers the inspection rules, extracts the deliverable or process data generated in that stage from the database, and performs automated verification according to the preset inspection rules.

[0057] For example, during the testing and verification phase, after a vulnerability scan is completed, the system automatically extracts the vulnerability list from the scan report, analyzes the vulnerability's CVSS score, vulnerability type, impact scope, and other attributes, and judges it according to the inspection rule "number of high-risk vulnerabilities = 0". If the scan report contains high-risk vulnerabilities with a CVSS score ≥ 7.0, the verification fails, the system automatically generates a non-compliance record, including the non-compliance item number, non-compliance item description, relevant laws and regulations, responsible person, discovery time, and other information, and sends an alert notification to the responsible person.

[0058] When the compliance verification fails, the alarm notification module triggers an alarm notification, which is sent via one or more of the following methods: email, system pop-up, and mobile push notification. The alarm notification includes a summary of the non-compliance item, a detailed description, rectification suggestions, and a rectification deadline. The system automatically blocks subsequent processes, requiring the responsible party to complete the rectification within the specified time limit and resubmit for verification after rectification.

[0059] The compliance verification results are recorded in the system database in real time, including verification time, verification item number, verification object, verification result (pass / fail), details of non-compliance items, processing status, and other information.

[0060] In some embodiments, operation data for each stage is also acquired; Analyze operational data at each stage to identify automotive cybersecurity risks; Based on the identified automotive cybersecurity risks, determine the appropriate response measures; The measures taken are used to address automotive cybersecurity risks, and the effectiveness of these measures is verified.

[0061] In this embodiment of the invention, risk identification is performed during each stage of the research and development process. The risk identification includes: First, acquire operational data for each development phase. This data includes test logs, design documents, vulnerability scan results, and compliance verification results. Test logs record detailed information during test execution, including test case numbers, test times, test results, and exception information. Design documents include architecture design documents, detailed design documents, and interface design documents, stored in Word or PDF format. Vulnerability scan results are generated by professional vulnerability scanning tools (such as Nessus and OpenVAS), containing a vulnerability list, CVSS scores, vulnerability descriptions, and remediation suggestions. Compliance verification results record the verification status of each compliance checkpoint and details of non-compliance items.

[0062] Secondly, the operational data is matched with risk characteristics in the built-in automotive cybersecurity risk database. This database contains typical risk characteristics and their triggering conditions, such as ECU vulnerabilities, bus hijacking, and remote intrusion. The built-in risk database is stored using a relational database and includes over 50 typical risk scenarios. Each risk scenario is configured with the following attributes: Risk Number (unique identifier), Risk Name, Risk Description, Triggering Conditions (defined using structured rule expressions), Potential Impact (description of impact on vehicle safety, data security, and user privacy), Historical Cases (real-world security incident cases), and References (CVE vulnerability database links, industry report links, etc.).

[0063] For example, the risk scenario definition for "ECU high-risk vulnerability" in the risk database is as follows: Risk ID "RISK-001", Risk Name "ECU high-risk vulnerability", Risk Description "The ECU software or firmware has a high-risk security vulnerability that can be remotely exploited, which may lead to attackers gaining control of the ECU", Triggering Conditions "The vulnerability scan results show a vulnerability with a CVSS score ≥ 7.0 AND the ECU affected by the vulnerability is a critical safety ECU (such as braking ECU, steering ECU, power ECU)", Potential Impact "Attackers can remotely control the vehicle's critical functions, causing the vehicle to lose control and threatening personal safety", Historical Case "2015 Jeep Cherokee remote hijacking incident (CVE-2015-5611)".

[0064] The system uses a rule-matching algorithm to extract key information from the job data and compare it with the triggering conditions in the risk database. For example, it extracts the vulnerability's CVSS score and the affected ECU information from the vulnerability scan results to determine whether the triggering condition of "CVSS score ≥ 7.0 AND affecting critical safety ECUs" is met.

[0065] Furthermore, when the operational data successfully matches the risk characteristics, a risk entry is automatically generated. This risk entry includes a risk number, risk type, triggering stage, associated regulations / legal provisions, and a preliminary impact description. The system automatically creates risk records. The risk number uses the format "Project ID-Risk Library Number-Sequence Number," for example, "PRJ-2024-001-RISK-001-01" represents the first risk entry in project PRJ-2024-001 that matches the RISK-001 risk scenario. The risk type inherits the risk name from the risk library. The triggering stage records the development stage in which the risk was identified. The associated regulations / legal provisions record which provisions of Regulation R155 the risk violates. The preliminary impact description inherits the potential impact content from the risk library.

[0066] Finally, the system supports manual reporting of specific risks, incorporating manually reported risk items into a unified risk list for management. The system provides a risk reporting form interface, allowing responsible personnel to manually fill in risk information. The form includes the following fields: Risk Name (required), Risk Description (required), Discovery Time (required), Discovery Stage (required), Supporting Evidence Attachments (optional, supports uploading screenshots, log files, test reports, etc.), and Preliminary Impact Assessment (optional). Manually reported risks are also entered into the system's risk list, with risk numbers formatted as "Project ID-MANUAL-Serial Number," for example, "PRJ-2024-001-MANUAL-01."

[0067] All identified risks (automatically identified + manually reported) are entered into the system's risk list. The risk list is displayed in a list format and supports filtering and sorting by risk level, risk type, trigger stage, processing status, and other dimensions.

[0068] Furthermore, it also includes a closed-loop process for performing risk assessment, risk management, and effectiveness verification on the aforementioned risk list: Risk assessment: The risk matrix method is used to calculate the risk value based on the impact and probability of occurrence of risk items, and the risk level is divided into high risk, medium risk and low risk.

[0069] Specifically, the system provides a risk assessment interface, where the responsible person assesses the impact and probability of occurrence of each risk item.

[0070] The impact assessment is selected from the following five levels: 1- Negligible (no substantial impact on vehicle functions, no impact on user experience), 2- Slight (slight impact on non-critical vehicle functions, slight decrease in user experience), 3- Moderate (significant impact on some vehicle functions, significant decrease in user experience), 4- Severe (severe impact on critical vehicle functions, may lead to functional failure, posing a safety hazard), 5- Catastrophic (fatal impact on vehicle safety functions, may lead to personal injury or major property damage).

[0071] The probability assessment is selected from the following five levels: 1-Very low (probability of occurrence <1%, almost impossible), 2-Low (probability of occurrence 1%-10%, unlikely to occur), 3-Medium (probability of occurrence 10%-50%, there is a certain possibility of occurrence), 4-High (probability of occurrence 50%-90%, very likely to occur), 5-Very high (probability of occurrence >90%, almost certain to occur).

[0072] The system calculates a risk value based on the impact score and the probability of occurrence score. The formula is: Risk Value = Impact Score × Probability of Occurrence Score. The risk value ranges from 1 to 25.

[0073] The system automatically determines the risk level based on the risk value: a risk value of 1 to 6 is considered low risk, a risk value of 7 to 12 is considered medium risk, and a risk value of 13 to 25 is considered high risk.

[0074] Risk assessment results are recorded in a risk list, including impact score, probability of occurrence score, risk value, and risk level. The system automatically sorts the risk list according to risk level and risk value, with high-risk risks listed first to ensure priority handling of high-risk risks.

[0075] Risk Management: Based on the risk level, a management solution is recommended from a pre-set management solution library, which includes technical and management measures. Users can formulate detailed management solutions and implement them, and the management progress is tracked in real time.

[0076] Specifically, the system has a built-in library of remedial measures, organized in a tree structure, divided into two main categories: technical measures and management measures. Technical measures include over 30 techniques such as applying security patches, enabling hardware isolation, enhancing access control, enabling encrypted communication, deploying intrusion detection systems, implementing code auditing, and adding security test cases. Management measures include over 20 management methods such as shortening remediation timelines, increasing retesting frequency, reporting to management, adjusting project plans, increasing manpower, strengthening training, and revising operating procedures.

[0077] Each remedial measure is configured with attributes such as applicable risk type, applicable risk level, implementation difficulty, expected cost, and expected effect. The system intelligently matches based on risk type and risk level to recommend the most suitable remedial measure. The recommendation algorithm uses a rule engine, with an example rule: IF Risk type="ECU high-risk vulnerability" AND Risk level="high risk" THEN Recommended measure=["Apply security patch (priority 1)", "Enable hardware isolation (priority 2)", "Shorten the remediation time to 48 hours (priority 1)", "Report to management (priority 1)"].

[0078] The responsible person can review the system's recommended remediation measures, edit and modify them, or add custom measures to form the final remediation plan. The remediation plan is recorded in a structured format, including the following: a list of remediation measures (each measure includes the measure name, measure description, implementation steps, responsible person, collaborating personnel, completion deadline, and required resources), remediation objectives (clearly defining the state to be achieved after remediation, such as "vulnerability remediation completed and retest passed"), and verification methods (clearly defining how to verify the effectiveness of the remediation, such as "re-run the vulnerability scan to confirm that the vulnerability has been eliminated").

[0079] Once the disposal plan is determined, the system creates an independent task record for each disposal measure. The tasks are incorporated into the task management system of the full lifecycle control module. The responsible person receives task notifications through the system and executes the disposal measures according to the implementation steps.

[0080] The system tracks the processing progress in real time, recording information such as task start time, current status (not started / in progress / completed / overdue), completion percentage, and execution logs. The processing progress is synchronized to the risk list in real time, allowing users to view associated processing tasks and their progress by risk number.

[0081] When the deadline for handling a task approaches (e.g., 24 hours before the deadline), the system automatically sends a reminder notification to the person in charge via email and mobile push notification. If the task is not completed by the deadline, the system automatically marks the task status as "overdue" and sends an escalation notification to the person in charge's supervisor.

[0082] Effectiveness verification: After the action is completed, the effectiveness of the action is verified through testing tools or compliance review. If the verification is successful, the risk is closed; if the verification fails, the risk is re-entered into the risk management process.

[0083] Specifically, once all handling tasks are marked as "completed," the system automatically triggers the effect verification process. The verification method is automatically selected based on the preset verification methods in the handling plan.

[0084] For vulnerability remediation risks, the system automatically invokes vulnerability scanning tools for retesting. The system calls vulnerability scanning tools such as Nessus or OpenVAS via API interfaces, configuring the scan target to be the affected ECU or system component, and executes the vulnerability scan task. After the scan is complete, the system parses the scan report and checks whether the original vulnerability still exists. If the vulnerability is no longer included in the scan report, the verification is considered successful; if the vulnerability is still included in the scan report, the verification is considered unsuccessful.

[0085] For design flaw risks, the system automatically triggers the design review process. The system sends a review notification to review experts, who then review the revised design documents to check whether design flaws have been fixed and whether the design solution meets safety requirements. Review experts submit their review comments, which can be either "pass" or "fail". If the review result is "pass", the verification is considered successful; if the review result is "fail", the verification is considered unsuccessful.

[0086] For risks related to configuration errors, the system automatically executes a configuration check script. The script reads the system configuration file and verifies whether critical configuration items have been modified according to the remediation plan. If the configuration items meet the requirements, the verification is considered successful; if the configuration items do not meet the requirements, the verification is considered unsuccessful.

[0087] The verification results are recorded in the risk list, including the verification time, verification method, verification result (pass / fail), verification report link, and other information.

[0088] Upon successful verification, the system automatically updates the risk status to "closed" and records the closure time. Closed risks will no longer appear in the list of pending risks, but the complete risk handling record can still be found in risk management reports and audit reports.

[0089] If verification fails, the system automatically returns the risk to the handling stage, updating the risk status to "Handling - Verification Failed". The system sends a notification to the responsible person, requiring them to re-analyze the reasons for the failure, develop a new handling plan or supplementary handling measures, and execute the handling task again. The risk re-enters the "Handling-Verification" cycle until verification is successful, thus achieving a closed loop.

[0090] The system records the complete history of risk handling, including each handling plan, each handling task, and each verification result, forming a complete risk management trajectory and supporting post-event traceability and experience summarization.

[0091] Through the closed-loop management mechanism of risk identification, assessment, handling, and verification, the risks at each stage of R&D are effectively controlled, significantly reducing the probability of vehicle cybersecurity incidents.

[0092] In some embodiments, updated laws and regulations are obtained; The updated laws and regulations are used to update the three-dimensional mapping relationship between laws and regulations, development indicators, and R&D stages.

[0093] This invention subscribes to the official website of the United Nations World Forum for Harmonization of Vehicle Regulations (WP.29) via an API interface to monitor the revision announcements of Regulation R155 in real time. The API interface adopts a RESTful architecture and is automatically invoked daily at 2:00 AM Beijing time to retrieve the regulatory announcement pages from the official website.

[0094] When a regulatory update is detected, the system automatically downloads the updated full text of the regulation, supporting multiple formats such as PDF, Word, and HTML. The system uses document parsing tools to extract the regulatory text content. For PDF format, OCR technology is used to recognize the text; for Word format, the python-docx library is used to parse the document structure; and for HTML format, the BeautifulSoup library is used to extract the main text content.

[0095] The system identifies the updated full text of the regulations by version, recording metadata information such as the revision date, revision version number, and revised chapter. The version number adopts the semantic versioning specification, with the format "major version number.minor version number.revision number". For example, "R155-v2.1.3" indicates the second major version, the first minor version update, and the third revision of the R155 regulations.

[0096] Simultaneously, the system sends a regulatory update notification to the administrator. The notification includes a summary of the revisions, a list of revised chapters, a preliminary assessment of the scope of impact, and a download link. The notification is sent via both email and in-system messages to ensure administrators are promptly informed of regulatory changes.

[0097] The algorithm automatically extracts the differences between the updated and original legal provisions using a text comparison algorithm, generates a difference analysis report and mapping adjustment suggestions, and updates the three-dimensional mapping relationship table of legal provisions-development indicators-R&D stage using the updated legal provisions.

[0098] In some embodiments, the system also acquires process data, deliverable data, and compliance verification result data generated when the compliance task list guides the work at each stage of the research and development process. A compliance audit report is generated based on the work process data, deliverable data, and compliance verification results data.

[0099] The operational process data includes work execution records and risk handling files. Obtaining a compliance audit report includes: real-time data collection across the entire process by the traceability audit module, establishing a unique traceability number and timestamp to ensure data immutability; support for multi-dimensional traceability queries based on regulations, project stages, risk levels, and responsible parties; and automatic generation of a compliance audit report upon project completion, including information on compliance with regulations, risk control effectiveness, and a summary of traceability data.

[0100] The compliance audit report adopts a structured format and includes the following sections: Project Overview (basic project information, participating departments, R&D cycle), Regulatory Coverage (percentage of compliance with each regulatory clause, supporting evidence index), Compliance Compliance Rate at Each Stage (compliance rate at the requirements definition stage, design and development stage, testing and verification stage, production and delivery stage, and after-sales maintenance stage), Risk Management Effectiveness Assessment (total number of identified risks, distribution of high, medium, and low risks, risk closure rate, and average handling time), Traceability Data Index (list of key deliverables, summary of operation logs, and signature records of responsible persons), and Conclusions and Recommendations. The report supports export in PDF and Word formats. The PDF format uses digital signature technology to ensure the report's authenticity and completeness.

[0101] The above methods enable the automatic conversion of regulatory requirements into specific development tasks, ensuring compliance throughout the entire automotive cybersecurity development process and significantly reducing the workload of manually interpreting regulations and the risk of compliance omissions.

[0102] The regulatory-based automotive cybersecurity development and management process proposed in this invention has the following advantages: (1) By using the three-dimensional mapping relationship mechanism of "laws and regulations - development indicators - R&D stage", and combining natural language processing algorithms to perform lexical analysis and semantic parsing on laws and regulations, abstract legal provisions are transformed into quantifiable and executable development indicators, so as to realize the accurate transformation of legal requirements into development tasks, ensure compliance throughout the development process, and avoid the risk of compliance omissions. (2) Establish a standardized operating process system covering the five major R&D stages of requirement definition, design and development, testing and verification, production delivery and after-sales maintenance. Configure standardized process steps, compliance verification key points and inspection rules for each stage, unify operating specifications and deliverable requirements, break down departmental barriers, achieve efficient cross-departmental collaboration, and improve development efficiency and control consistency. (3) By constructing a full-process risk control mechanism of "identification-assessment-disposal-verification", combining the built-in automotive network security risk database to automatically identify potential risks, using the risk matrix method to assess the risk level, recommending compliant disposal measures, and verifying the effect through testing after disposal, we can ensure that high-risk hidden dangers are completely eliminated and reduce the probability of vehicle network security incidents. (4) Collect data throughout the entire process in real time, establish a unique traceability number and timestamp to ensure that the data is tamper-proof, support multi-dimensional traceability queries based on laws and regulations, project stages, risk levels, and responsible persons, and automatically generate a compliance audit report that includes compliance with laws and regulations, risk control effectiveness, and traceability data summary after the project is completed, which greatly reduces the cost of regulatory verification and compliance evidence collection. (5) When regulations are revised, the difference clauses between the updated regulations and the original regulations are automatically extracted through text comparison algorithm, and a difference analysis report and mapping adjustment suggestions are generated. The three-dimensional mapping relationship table and related task requirements can be updated quickly and synchronously to ensure the long-term compliance of the system and strong adaptability to regulations.

[0103] This invention also proposes a regulatory-based automotive cybersecurity development management process system, including: The project information acquisition unit is used to acquire information about automotive cybersecurity development projects. The project analysis unit is used to determine the development indicators of automotive cybersecurity development projects, the R&D stage to which each development indicator belongs, and the laws and regulations that each development indicator must comply with. The mapping relationship table construction unit is used to construct a three-dimensional mapping relationship between laws and regulations, development indicators, and R&D stages based on the R&D stage to which each development indicator belongs and the laws and regulations to be followed. The compliance task list generation phase is used to construct a compliance task list for each R&D stage based on the three-dimensional mapping relationship between regulations, development indicators, and R&D stages. The compliance task list guides the verification of compliance of operations and deliverables in each R&D stage.

[0104] It should be noted that the above-described embodiment of a regulatory-based automotive cybersecurity development and management process system is only illustrated by the division of the functional modules described above. In practical applications, the functions described can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. Furthermore, the regulatory-based automotive cybersecurity development and management process system and the regulatory-based automotive cybersecurity development and management process method embodiment provided above belong to the same concept; their specific implementation process is detailed in the method embodiment and will not be repeated here.

[0105] The present invention also discloses a computer device, the device comprising: A processor, adapted to execute computer programs; A computer-readable storage medium storing a computer program, which, when executed by the processor, implements a regulatory-based automotive cybersecurity development and management process method disclosed in an embodiment of the present invention.

[0106] The computer device can be a portable mobile terminal, such as a smartphone, tablet, laptop, or desktop computer. Typically, a computer device includes a processor and memory.

[0107] A processor may include one or more processing cores, such as a core processor or a core processor. The processor may be implemented using at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), or PLA (Programmable Logic Array). The processor may also include a main processor and coprocessors. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content required to be displayed on the screen. In some embodiments, the processor may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0108] The memory may include one or more computer-readable storage media, which may be non-transitory. The memory may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory are used to store at least one computer program, which is executed by a processor to implement the intelligent vehicle control method provided in the method embodiments of this application.

[0109] In some embodiments, the computer device may also optionally include: a peripheral device interface and at least one peripheral device. The processor, memory, and peripheral device interface can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface via a bus, signal line, or circuit board. Specifically, the peripheral device includes at least one of: radio frequency circuitry, a display screen, a camera assembly, audio circuitry, and a power supply.

[0110] Peripheral device interfaces can be used to connect at least one I / O (Input / Output) related peripheral device to the processor and memory. In some embodiments, the processor, memory, and peripheral device interface are integrated on the same chip or circuit board; in some other embodiments, any one or two of the processor, memory, and peripheral device interface can be implemented on separate chips or circuit boards, which is not limited in this embodiment.

[0111] Radio frequency (RF) circuits are used to receive and transmit RF signals, also known as electromagnetic signals. RF circuits communicate with communication networks and other communication devices via electromagnetic signals. RF circuits convert electrical signals into electromagnetic signals for transmission, or convert received electromagnetic signals back into electrical signals. In some embodiments, the RF circuit includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a user identity module card, etc. The RF circuit can communicate with other terminals through at least one wireless communication protocol. These wireless communication protocols include, but are not limited to: the World Wide Web, metropolitan area networks, intranets, various generations of mobile communication networks (2G, 3G, 4G, and 5G), wireless local area networks, and / or WiFi (Wireless Fidelity) networks. In some embodiments, the RF circuit may also include circuitry related to NFC (Near Field Communication), which is not limited in this application.

[0112] The present invention also discloses a computer-readable storage medium storing a computer program adapted for loading and execution by a processor of a regulatory-based automotive cybersecurity development and management process method disclosed in the embodiments of the present invention.

[0113] The present invention also discloses a computer program product, which includes a computer program. When the computer program is executed by a processor, it implements a regulatory-based automotive cybersecurity development and management process method disclosed in the embodiments of the present invention.

[0114] The method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor. The software modules can reside in readily available storage media in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are omitted here.

[0115] Those skilled in the art will recognize that the units and algorithm steps described in conjunction with the embodiments herein can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0116] While the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.

Claims

1. A regulatory-based automotive cybersecurity development and management process method, characterized in that, include: Obtain information on automotive cybersecurity development projects; Determine the development metrics for the automotive cybersecurity development project, the R&D stage to which each development metric belongs, and the laws and regulations to be followed for each development metric; Based on the R&D stage to which each development indicator belongs and the laws and regulations to be followed, a three-dimensional mapping relationship is constructed between laws and regulations, development indicators, and R&D stages. Based on the three-dimensional mapping relationship between regulations, development indicators, and R&D stages, a compliance task list is constructed for each R&D stage. The compliance task list guides the verification of compliance of operations and deliverables at each stage of R&D.

2. The regulatory-based automotive cybersecurity development and management process method as described in claim 1, characterized in that, Obtain updated laws and regulations; The updated laws and regulations are used to update the three-dimensional mapping relationship between laws and regulations, development indicators, and R&D stages.

3. The regulatory-based automotive cybersecurity development and management process method as described in claim 1, characterized in that, The compliance task list includes standardized operating procedures, compliance checkpoints, and inspection rules; Each R&D phase shall perform standardized operations in accordance with the standardized operating procedures in the compliance task list; When a task reaches a compliance checkpoint, the deliverables generated at that checkpoint are verified for compliance using the inspection rules.

4. The regulatory-based automotive cybersecurity development and management process method as described in claim 1, characterized in that, It also acquires operational data for each stage; Analyze operational data at each stage to identify automotive cybersecurity risks; Based on the identified automotive cybersecurity risks, determine the appropriate response measures; The measures taken are used to address automotive cybersecurity risks, and the effectiveness of these measures is verified.

5. The regulatory-based automotive cybersecurity development and management process method as described in claim 1, characterized in that, Also, a person in charge for each stage of research and development was identified; The compliance task list for each R&D phase is distributed to the person in charge of each R&D phase to guide the work of each R&D phase.

6. The regulatory-based automotive cybersecurity development and management process method as described in claim 1, characterized in that, It also obtains the work process data, deliverable data and compliance verification result data generated when the compliance task list guides the work at each stage of R&D; A compliance audit report is generated based on the work process data, deliverable data, and compliance verification results data.

7. A regulatory-based automotive cybersecurity development management process system, characterized in that, include: The project information acquisition unit is used to acquire information about automotive cybersecurity development projects. The project analysis unit is used to determine the development indicators of automotive cybersecurity development projects, the R&D stage to which each development indicator belongs, and the laws and regulations that each development indicator must comply with. The mapping relationship table construction unit is used to construct a three-dimensional mapping relationship between laws and regulations, development indicators, and R&D stages based on the R&D stage to which each development indicator belongs and the laws and regulations to be followed. The compliance task list generation stage is used to construct a compliance task list for each R&D stage based on the three-dimensional mapping relationship between regulations, development indicators, and R&D stages. The compliance task list guides the verification of compliance of operations and deliverables at each stage of R&D.

8. An electronic device, characterized in that, The device includes: A processor, adapted to execute computer programs; A computer-readable storage medium storing a computer program, which, when executed by the processor, implements the regulatory-based automotive cybersecurity development and management process method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted for loading and execution by a processor of the regulatory-based automotive cybersecurity development and management process method according to any one of claims 1-6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the regulatory-based automotive cybersecurity development and management process method as described in any one of claims 1-6.

Images