Car-hacking villages and why Indian OEMs should care

The community that finds vehicle bugs first

A car hacking village is a hands-on space, usually hosted at a security conference such as DEF CON, where researchers are given real vehicle hardware — electronic control units, gateways, instrument clusters, telematics units — and encouraged to break it in a legal, controlled setting. People sit at benches, sniff and inject CAN traffic, attack diagnostic services, and pull firmware apart. The output is a steady stream of demonstrated vulnerabilities in production-representative parts.

For an Indian OEM, the village is easy to dismiss as a spectacle. That would be a mistake. The village is a working model of how vehicle weaknesses get found in the real world: not by an internal team reading a specification, but by curious people with an oscilloscope and time. The question for an OEM is not whether that scrutiny happens, but whether it happens on your terms — through a disclosure channel you run — or on someone else's.

Why the format matters

Vehicle attacks are not exotic. Most start from properties of the in-vehicle network that have been public for years. The CAN protocol has no built-in authentication, so with bus access an attacker can inject, spoof and fuzz frames — the mechanics are covered in CAN bus attacks explained. Diagnostic access over OBD-II, and weak seed/key schemes in UDS SecurityAccess, give another way in. A village simply concentrates skilled people and real hardware against those surfaces and sees what falls out.

That maps directly onto the regulatory threat model. UN R155 Annex 5 catalogues the threats a cyber security management system must address across categories including communication channels, external connectivity and diagnostic access. Village findings are, in effect, live worked examples of those Annex 5 categories. An OEM that watches the community is watching its own threat catalogue being exercised for free.

What a village actually produces

The value is not the theatre; it is the artefacts. A serious village session produces:

Output	What it is	Why it matters to an OEM
Reproducible findings	A documented attack path against a specific interface	Becomes an input to your TARA and to type-approval evidence
Tooling and techniques	Reusable methods for CAN injection, firmware extraction, UDS abuse	Raises the floor for your own penetration testing
Trained people	Engineers who have done the work on real hardware	The talent pool your VSOC and security team hire from
Disclosure relationships	Researchers who know how to report responsibly	A channel that surfaces bugs before they are weaponised

None of these require you to expose a production vehicle. As with any structured vehicle assessment — see penetration testing a vehicle — the work runs against representative ECU benches, not a car off the line.

Why India specifically needs its own capability

Two forces make a domestic community more than a nice-to-have. First, regulation. India's CSMS standard, AIS-189, is aligned to UN R155, and its SUMS counterpart AIS-190 to UN R156; enforcement is proposed in MoRTH's June 2026 draft (G.S.R. 503(E)) but not yet finalised, and the capability an OEM must build does not depend on the exact date. R155's expectation of post-production monitoring and threat response assumes people who can recognise a real vehicle attack when they see one. Those people have to come from somewhere.

Second, the assessor side. Being named in Rule 126 of the CMVR as a test agency does not by itself confer cybersecurity scope — AIS-189 clause 5.3.1 requires the assessing agency to hold automotive cybersecurity and risk-assessment competence of its own. Competence, on both the OEM and the assessor side, is a skills problem before it is a paperwork problem. A community that produces skilled practitioners is upstream of everything else.

This is why industry-led capability building matters in India right now. AutoSifu and CIRT (Pune) co-built India's first SUMS workshop in November 2025 and the CSIP (Certified SUMS Implementation Professional) certification. These are not a car hacking village, but they are the same instinct applied to compliance and software-update engineering: put practitioners in front of real problems and build local depth rather than importing it transaction by transaction.

How to engage without exposing yourself

For an OEM, engaging the community sensibly means a few concrete steps:

• Run a coordinated disclosure channel. Publish a way for researchers to report a finding, commit to responding, and mean it. This is also the direction EU law is moving — the Cyber Resilience Act expects coordinated disclosure and active reporting of exploited vulnerabilities.
• Sponsor or seed local events. Benches, target hardware and a small prize turn curiosity into documented findings you can act on.
• Hire from the pool. Village and CTF participants are pre-filtered for exactly the hands-on skill a VSOC and a pentest team need. The routes into these roles are covered in building an automotive cybersecurity career in India.
• Feed findings into the CSMS. A community report should not die in an inbox. It should update the TARA, trigger risk treatment, and — where it touches regulation-relevant software — flow through to RxSWIN and an update campaign.

The mistake is to treat the hacking community as an adversary. In vehicle security the researcher who emails you is the cheapest security engineer you will ever have. The expensive one is the attacker who does not email you at all.

The state of play

India is early. The regulatory machinery — AIS-189, AIS-190, the Rule 126 agencies, CIRT's cybersecurity role — is being assembled, and the community that will stress-test it is still forming. That is precisely why the moment matters: the OEMs that build disclosure relationships and internal capability now will have people who can recognise an Annex 5 threat in the wild, and evidence to show an assessor, before the enforcement dates are notified.

The AutoSifu view

AutoSifu treats capability building and compliance as one job, not two. We work a single route — CSMS and SUMS to assessment, secure solutioning, and CoC/VTA support under R155/R156 and AIS-189/AIS-190 — with our strategic partner CIRT, the approval body, in the room rather than at the end of a queue. Community findings, penetration-test results and workshop-trained people all feed that route, so that the day an assessor opens your file, the evidence and the skills behind it are already there.