Parasoft offers solutions to ensure compliance with numerous safety and quality standards. How exactly do your tools support compliance with standards like IEC 61508?
Parasoft facilitates compliance with functional safety standards such as IEC 61508 as well as industry-specific standards like ISO 26262 or IEC 62304 through automation and support of verification and validation activities. This includes static code analysis, unit testing, code coverage, and requirements traceability.
With static analysis, we ensure that secure programming practices are followed and that the code complies with standards like MISRA for functional safety or CERT and CWE for security. Through automated unit tests, we verify whether the code behaves as specified. Additionally, we use structural code coverage to ensure that all relevant parts of the code are tested — from statement to branch to MCDC coverage, as required by IEC 61508 depending on the SIL level.
Beyond that, we support traceability from requirements down to test cases. Our tools help create a traceability matrix, identify gaps, and properly document all evidence. Using dashboards, developers can monitor test status and requirements fulfillment at any time.
In short: Our solutions largely automate software testing, significantly reduce effort, and deliver verifiable results. Our C/C++ testing tools are also certified for safety-critical development. This builds trust and minimizes development risks — especially for safety-relevant applications.

Ricardo Camacho is Director of Safety & Security Compliance at Parasoft. © Parasoft

You mentioned ISO 26262 and traceability. Are there any differences compared to IEC 61508?
At the core, no. Both standards require comprehensive traceability of requirements throughout all development phases. Requirements are progressively refined along the V-model, from high-level safety or security requirements down to detailed specifications. Traceability ensures that every requirement is tested, verified, and validated. The same applies to other standards such as IEC 62304 (medical devices) or DO-178C (aviation). The principle is the same: every requirement must be demonstrated through appropriate tests.

Can you explain the difference between static and dynamic analysis in a few sentences?
Static analysis inspects the code purely by reviewing it, without executing it. Dynamic analysis, on the other hand, means executing the code to check its runtime behavior. This includes unit tests, integration and system tests, as well as acceptance tests. Essentially, dynamic analysis covers all tests that run the code in real or simulated scenarios to validate functionality, robustness, and performance.

How important is static code analysis for safety-critical or safety-relevant software?
Static analysis is essential for detecting errors, vulnerabilities, and deviations from coding guidelines early — before the code is ever run. This supports the ‘shift-left’ approach: finding issues as early as possible in the development cycle, which is much cheaper than fixing them later.
Beyond classic rule violations, our static analysis also checks data and control flow. This way, faulty pointers, division by zero, or unused — ‘dead’ — code can be found. In fact, we often find the same errors with static analysis that would otherwise require extensive unit tests — but much faster.
Seamless integration into modern development processes is also important: Our ‘Parasoft C/C++test’ tools can be integrated into CI/CD pipelines like Jenkins, GitHub, GitLab, or Azure DevOps. Developers can also run analyses directly from IDEs like ‘VS Code’, ‘Eclipse’, or ‘Visual Studio’, or fully automate them in the build process. This makes static analysis a continuous part of quality assurance.

Where do you see risks when relying too heavily on automated tests?
Automated tests are extremely helpful, but they don’t replace engineering expertise. Automation helps achieve broad test coverage quickly — but critical edge cases or unusual errors are often only found through the know-how and intuition of experienced engineers.
For example: I’ve seen two developers test identical code. One relied exclusively on automated tests and achieved 100% code coverage — but missed a bug that his colleague discovered with carefully designed manual edge test cases. So: Automation, yes — but always combined with human expertise.

In your experience, where do companies most often fail when implementing standards?
Often, there’s a lack of understanding of the requirements. Many are unsure which processes, evidence, or artifacts are needed for standards like IEC 61508. Without precise knowledge, important steps are overlooked or documentation is incomplete.
My advice: Work closely with audit specialists and certification bodies — and involve internal experts or consultants if necessary. For example, we’re considering providing our customers with standardized checklists so they know which documents, test evidence, or verifications they need to deliver.

What role do coding guidelines like MISRA play today?
MISRA defines coding guidelines for safe and robust programming in C and C++. It ensures consistent code quality (e.g., safe, secure and reliable) — internally within the development team and should be required from your extern suppliers. The goal is to identify bugs in the code, fix them and deliver safe and predictable software, which also satisfies compliance requirements defined in industry-specific safety standards like IEC 61508 or ISO 26262.
MISRA guidelines are also constantly being evolved to keep pace with new C language constructs found in version C17 also known as C18. At Parasoft, we actively contribute to its development — one of our experts is a member of the MISRA C and C++ working group. This allows Parasoft to not only fully support all guidelines, but also help shape the rules to be practical and future-prooffor industries ranging from automotive to medical technology and aerospace.

What is special about the current MISRA version?
The new version, MISRA C 2025, builds on MISRA C 2023. There are four new rules, two have been removed, and 13 have been revised. Three focus areas stand out: predictability, portability, and security.
For example, predictability: some compilers behave differently with bit-shift operations. New rules ensure that the code works consistently across all platforms. Regarding security, MISRA is responding to the growing threat landscape and tightening guidelines, e.g., for dynamic memory management. It also stipulates that AI-generated code must be subject to the same checks as human-written code.

It was mentioned that rules were removed. Does deleting these rules affect maintainability?
No. When a rule is removed or disapplied, it’s done consciously and with good reason. This simply means that this rule is no longer checked during analysis. So you no longer look for something that is now considered irrelevant or where the perspective has changed.
Example: In the past, there was a rule stating that a function should have a single point of exit at the end (Rule 15.5) prohibited the use of ‘goto’ statements or jumps out of functions or switch blocks. Since many developers deliberately used this behavior, the rule was deleted. Today, this case is simply no longer flagged, and there’s no need to file a deviation if this behavior is desired. Older tool versions may still detect it, but then you just need a deviation statement.

What advice would you give companies that are just starting to work with the new MISRA version?
For companies that have been using MISRA for a long time and have an established culture, not much will change. For newcomers: MISRA is extremely helpful but should be introduced gradually. My advice: First activate only the most important, high-priority rules to avoid being overwhelmed by hundreds or thousands of violations. This gives developers a chance to get used to the rules and not feel discouraged by the volume of notifications. It’s also important to integrate MISRA into an agile development process, so code is checked regularly and feedback flows directly into development. This not only improves the code but also makes developers better software engineers in the long term. The key is that the team accepts, applies, and understands the rules and why they matter. Companies, products, and developers all benefit from this.

What impact do regulatory developments such as the EU Cyber Resilience Act (CRA) have on guidelines like MISRA?
Such legal requirements have a major impact. For example, products can only be sold in the EU if they meet the CRA’s security requirements. This includes proving security measures throughout the entire lifecycle. For tool vendors like us, this doesn’t mean a completely new development but rather that we help our customers satisfy these regulatory verification and validation requirements. In addition to development, this also involves post-release security, such as key management for vehicles or protection of sensitive data. For digital components with communication capabilities, security features such as passwords or biometric authentication must also be implemented. All these requirements must be tested — this is where static analysis with standards like MISRA, OWASP, CWE, or CERT comes in. Parasoft also covers API testing or service virtualization alongside embedded solutions to detect security gaps in communication interfaces. In short: Regulations have a major impact on our customers. If they don’t comply, they can’t sell their products.

How might the role of coding standards like MISRA develop in the future?
MISRA will continue to evolve, just like the C and C++ programming languages. There will be new rules; outdated rules will be removed or adjusted. A key trend is the increasing focus on security. Here, MISRA overlaps with security standards such as CERT C/C++. In the future, MISRA will likely include even more security aspects — perhaps even consider new languages like Rust, which are currently being discussed. For tool providers like us, this means we need to handle overlaps between standards like MISRA and CERT smoothly to avoid conflicts or duplication. The goal is to make the application of multiple standards as seamless as possible for companies. In summary: MISRA itself will continue to grow, especially in the area of security, and we as a provider will further develop our tools to fully support this development.