AI-Driven Product Security for Software-Defined Vehicles

AUTOMOTIVE INDUSTRIES interview with Roy Fridman, CEO, C2A Security

Following C2A Security’s recent release of the Claude Inside version of EVSec, Automotive Industries spoke with CEO Roy Fridman about software-defined vehicle security, the changing role of AI in product cybersecurity, and what the next five years will demand of automakers and their suppliers.

Automotive Industries: C2A Security has launched a dedicated “Claude Inside” version of EVSec. What specific product security challenges in software-defined vehicles motivated this integration, and how does Claude’s reasoning capability enhance the platform’s value for automotive manufacturers?

Fridman: Software-defined and AI-enabled vehicles changed the math. A modern vehicle is a software product with thousands of components, dozens of ECUs, multi-tier suppliers, and continuous over-the-air updates. Work that used to be quarterly is now weekly.

Our customers were being forced into a choice nobody wants to make: ship updates at market speed and hope compliance holds, or take the time to do compliance properly and miss the launch window. That is not a tooling problem. It is structural.

EVSec attacks the structural problem. It reasons over the customer’s actual product architecture, components, vulnerabilities, and compliance obligations. It drafts, enumerates, and prioritizes; the customer’s experts review and approve. That combination with Claude is what gives manufacturers a practical way to use AI for real security outcomes, governance, and not just faster reports.

Automotive Industries: As AI accelerates vulnerability discovery and exploit analysis, how do you see the cybersecurity landscape changing for automakers, and what new risks should the industry be preparing for?

Fridman: AI is already increasing the speed and scale at which vulnerabilities are discovered, analyzed, and potentially exploited. We are seeing this across the industry, from Claude Mythos Preview and OpenAI’s Trusted Access for Cyber to Google DeepMind’s CodeMender and Big Sleep, alongside the adversarial AI tooling tracked by Google Threat Intelligence Group. Both attackers and defenders just got faster.

For automakers this means three shifts. The gap between vulnerability disclosure and exploit availability collapses. Supply chain attacks become more targeted, because adversarial AI can analyze supplier code and SBOMs at scale. And the volume of theoretical findings explodes, which means signal-to-noise becomes the bottleneck, not detection.

The industry needs to prepare for continuous, contextualized risk evaluation. Periodic assessments and static documentation will not survive this environment.

Automotive Industries: You have said that customers are not looking to find more issues but to understand which risks truly matter. How does EVSec help security teams distinguish between theoretical vulnerabilities and exploitable product risks in real-world vehicle environments?

Fridman: Most vulnerabilities in a typical SBOM are not exploitable in that specific product. The component may not be reachable, the affected function may not be invoked, the attack surface may not be exposed, or compensating controls may already neutralize the risk. Treating every CVE as equally urgent burns engineering time and does not improve security.

EVSec separates theoretical from exploitable by reasoning across multiple layers of product context. Binary analysis tells us what is actually deployed. Code-level reachability tells us whether a vulnerable function is even invoked. Threat intelligence tells us what is being weaponized in the wild. Compliance context tells us what regulators require evidence on. Claude reasons across all of it.

The output is a prioritized, defensible list of what matters now, with traceability back to the evidence. That is what security teams need to defend their decisions to engineering, to regulators, and to their executive team.

Automotive Industries: Modern vehicles generate vast amounts of architecture, software, supplier, and compliance data. How does EVSec’s contextual cyber model bring these elements together to support faster and more informed security decisions?

Fridman: Data without context is just noise. A vehicle program might have architecture diagrams in one system, ECU specifications in another, SBOMs from twenty suppliers in different formats, threat intelligence from multiple feeds, and compliance evidence scattered across spreadsheets and documents. None of that is decision-ready in its raw form.

The contextual cyber model is the product’s digital representation from a security standpoint. Every component, every interface, every threat scenario, every control, and every piece of compliance evidence is connected and traceable. When a new CVE is disclosed, the platform can immediately map the impact across that model, rather than triggering manual investigation across disconnected systems.

That grounding is what makes AI in product security trustworthy. Without it, AI is guessing. With it, AI becomes a multiplier on expert judgment.

Automotive Industries: Compliance requirements such as UN R155 and ISO/SAE 21434 continue to evolve. How does the new EVSec release help automotive companies streamline compliance efforts while maintaining continuous cybersecurity assurance?

Fridman: UN R155 CSMS certification is not a one-time audit. It is a demonstration that you have a working cybersecurity management system across the lifecycle. ISO/SAE 21434 expects continuous risk treatment as products evolve. The regulations are explicit that compliance is ongoing, but most organizations still treat it as a periodic deliverable because the manual workload of doing it continuously is overwhelming.

The Claude Inside version of EVSec turns compliance from a snapshot into a living system. Evidence is generated as a byproduct of the security work itself, not as a separate documentation exercise. When the architecture changes, the threat model updates. When a new CVE hits, the vulnerability assessment updates. The audit-ready output is always current.

The platform also maps to adjacent frameworks where relevant: IEC 62443, FDA cybersecurity requirements, and the EU Cyber Resilience Act. CRA is particularly important for automotive suppliers: connected products, ECUs, modules, gateways, or software placed on the EU market can create direct CRA obligations in addition to OEM-driven UN R155 and R156 evidence.

Automotive Industries: Threat modeling has traditionally been a labor-intensive process. How does the “Claude Inside” version of EVSec transform threat modeling and attack path analysis for vehicle manufacturers and suppliers?

Fridman: TARA has historically taken weeks or even months per project, and it has to be redone with every meaningful architectural change. For programs with frequent updates, the threat model is almost always out of date relative to the product. That is a structural weakness, not a process failure.

The Claude Inside version of EVSec generates and refines threat models from the inputs engineering teams already produce: product specifications, architecture files, ARXML, engineering documentation, and security requirements. It enumerates threats, builds attack paths, maps controls, and produces draft work products. In customer environments, we have seen TARA work accelerate by up to 75 percent and even more, while keeping expert review and analytical rigor in place.

Humans stay in the loop where it matters. Claude does the enumeration and automation that consumes most of an analyst’s time. Experts make the judgment calls. The result is that organizations can actually keep their threat models current with their products, which is what the regulations expect and what good security demands.

Automotive Industries: Software Bills of Materials are becoming increasingly important for automotive cybersecurity. How does EVSec use AI-driven SBOM intelligence and vulnerability analysis to help organizations prioritize remediation efforts more effectively?

Fridman: An SBOM by itself does not improve security. A list of components plus a list of CVEs is still a manual triage problem, often at a scale of tens of thousands of findings per program. Without intelligence on top, SBOMs become another compliance artifact rather than a security tool.

EVSec applies multiple layers of analysis. Binary analysis confirms what is actually deployed versus what is declared. Code-level reachability tells us whether a vulnerable function is even invoked. Supplier evidence and VEX data tell us where the supply chain has already addressed an issue. Threat intelligence tells us which CVEs are being actively exploited. Claude reasons across all of that to produce a remediation queue ranked by real-world exploitability, not raw CVSS.

For a vehicle program tracking thousands of components across multiple ECUs and suppliers, this is the difference between a backlog that is impossible to work with and one focused on what genuinely matters.

Automotive Industries: Many manufacturers are exploring AI, but concerns remain around governance, accuracy, and trust. How does C2A Security ensure that AI-assisted security analysis remains grounded in real product context and delivers reliable outcomes?

Fridman: The concern is legitimate. Generic AI in safety-critical, regulated environments is risky. Hallucinations, lack of traceability, and data governance gaps are real issues, because our customers operate in markets where being wrong has consequences.

Our approach has three pillars. First, Claude operates inside a structured product security environment, not as an open-ended assistant. It reasons over the cyber model, the regulatory frameworks, and the customer’s domain-specific data. That grounding dramatically reduces the surface area for hallucination. Second, every output is traceable to its source evidence, and experts always remain in the loop. Claude drafts and prioritizes; humans approve.

Third, we are LLM-agnostic by design. Customers who require on-premise deployment for data sovereignty can run a private LLM. Customers who prefer a different model provider can integrate that. The platform value comes from the cyber model and the orchestration layer, not from any single AI provider.

Automotive Industries: Looking ahead, how do you envision AI-driven product security orchestration evolving over the next five years, and what role do you expect platforms like EVSec to play in securing the future of connected and autonomous vehicles?

Fridman: Three forces are converging. AI is making both attackers and defenders dramatically faster. Regulation is tightening globally across UN R155 and R156, ISO/SAE 21434, AIS 198, the EU Cyber Resilience Act, FDA cybersecurity requirements, and frameworks we have not seen yet. And vehicles themselves are becoming more complex with autonomy, V2X, continuous OTA, and increasingly software-defined architectures.

Point solutions and static compliance tools will not survive this environment. The organizations that win will treat product security as a continuous, orchestrated discipline grounded in real product context, supported by AI automation, and integrated into the engineering lifecycle.

Five years from now, this will not be optional tooling. It will be foundational infrastructure for any manufacturer building connected, autonomous, or software-defined products.