Riscure True Code

Up until now the process of software evaluation was a manual task with corresponding high costs and long lead times. It is also quite common that an evaluation takes place at the end of the development cycle causing higher costs to resolve issues opposed to when issues would have been found in the development phase. Finding vulnerabilities and issues during the development phase and immediately resolving them can be up to a 100 times cheaper compared to doing the same later in the process. Riscure True Code brings this promise of shifting to the left within reach through a tight integration in the development, sharing discovered vulnerabilities instantly with all team members. Riscure True Code integrates tightly with the development environment that is used by your team and integrates with any other SDLC and DevSecOps tools to automate as much as possible.

Static Application Security Testing (SAST)

With True Code for Static Application Security Testing (SAST) or White Box testing we provide all the logical static checks.  Static checks are performende on the C/C++ code without executing it. Specifically for embedded software we have extended these static checks with all the checks that the Riscure Lab has developed over the last 2 decades  and we have added static checks for Fault Injection attacks that are specific for situations where the software meets the hardware. Over 100 static checks in total can be performed on pieces of the code or the entire code base.

Dynamic Application Security Testing (DAST)

Only SAST code checks are not enough to get a secure embedded software solution. Fault injection in the hardware can cause the software to behave in an undesired manner, which is why it is necessary to check for vulnerabilities while the software is executed. To get actional feedback we added some extra code at runtime to catch the precise location in the C/C++ code that caused the code to behave unexpected and to be able to mitigate the vulnerabiltiy at the specific line of code.

True Code has two options to check for vulnerabilities at runtime, Fault Injection simulation and Fuzzing. These two methods of Dynamic Application Security Testing (DAST) are described below.

Fault Injection Simulation (DAST)

True code can simulate the target architecture and introduce glitches into it to simulate a Fault Injection attack and measure the behavior of the software. By running the software repeatedly on the architecture and introducing glitches the behavior is measured and any undesired behavior reported. True Code gives direct feedback in the C/C++ code that is responsible for the unexpected behavior and mitigating actions can be taken by the developers. Currently, the Risc-V and Arm architectures are supported, which covers a large part of the market, but other architectures can also be supported even before they are put into production. This requires the RTL of the target architecture but we offer a DIY solution so you do not have to expose your IP.

Fuzzing (DAST)

With Fuzzing True Code exhausts communication variations to identify unexpected behavior. Fuzzing is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion. Interfaces can be vulnerable for this type of testing. True Code gives direct feedback about the interfaces that are vulnerable and mitigating actions can be taken. True Code helps to make unit tests and test scenarios to test your interfaces by harnessing and stubbing the code and make an entry path. We also measure how much coverage of the code the fuzzing has achieved. By using True Code you will save many hours of manual labor to set up the fuzzing.

True Code for Automotive

The ISO/SAE 21434 heavily emphasizes on risk identification methods and establish processes to address the security risks. Automotive Safety Integrity Level (ASIL) is used for classification of the hazards. The distinction between unintended (safety) risks and intended (security) risks has not been made in this standard. It goes without saying that vehicles cannot truly be safe if they are not also secure.

Modern vehicles can have up to 100 Electronic Control Units (ECUs in them depending on their class, make, and model, with the number of ECUs rising even higher in the case of electric vehicles. Each ECU has embedded software running on them. Mitigation of the security risk should be part of the embedded software development process to comply with the standards.

Managing cyber security risks in Automotive is done with Threat Analysis and Risk Assessment (TARA). In this model the threats are identified and mitigating actions determined. With True Code you will have a complete implementation for the development and test phase in the TARA model. From static and fault injection code checks to fault injection simulation and Fuzzing at runtime.

True Code for IoT

Connected IoT devices comprise many parts from different manufactors. This creates a complex ecosystem of manufactors and suppliers that need to proof the robustness and the hardening for security vulnerabilities of their products. Although security guidelines like SESIP and PSA Certified are helping to address the IoT security challenge, it is not nearly enough to protect these devices against malicious intentions. IoT devices are inexpensive, accessable and can be physical tampered with, making it an easy target for hackers.

From that perspective it makes sense to make sure that the embedded software running on that device has no vulnerabilities. Measures are taken with secure elements, asymetric keys and digital certificates, but it is also important to make sure that glitches in the hardware do not result in code being skipped and therefore undo the counter measures.

True Code does specific embedded software and firmware code checks to make sure that the code is not vulnerable for hardware Fault Injection. By simulating fault injection on the target architecture the behavior of the software  at runtime is tested and feedback supplied to take mitigating actions. Interfaces can be tested at runtime by using our automated Fuzzing.  All these checks are automated in the development and DevOps process to make sure that the complete code base is checked and regression testing is done each time when new code is submitted.