#Hacktivity2021 // Security Awareness in Development

## Overview Ákos Chilling, a manager at Bosch leading automotive security testing, discusses how large organizations can build security awareness among developers and engineers. He frames security as an essential product quality attribute and describes Bosch's multi-faceted approach to embedding security awareness across a 73,000-person R&D organization.

## Bosch's Security Context Bosch develops physical products (automotive components, power tools, home appliances, e-bikes, trucks) rather than purely software systems. This introduces unique security challenges: physical supply chains, owner motivation to modify vehicles (tuning), unlimited attacker physical access, and public accessibility of devices. These factors necessitate cross-functional security involvement beyond software engineers—hardware engineers, system engineers, functional safety specialists, testers, and managers must all understand security risks.

## Technical Example: Relay Attack on Car Remotes Chilling illustrates interdisciplinary security needs with a relay/replay attack on car remote controls. When a user presses the remote, a signal with a secret key opens the vehicle. While the key uses a random number generator that changes each time (making prediction difficult), an attacker can jam the signal during transmission, capture it, and replay it later. The car accepts a buffer of subsequent keys to handle legitimate delayed presses, enabling this attack. This published attack was reproduced in Bosch labs and exemplifies how hardware, software, and system design must collaborate on security.

## Bosch's Security Framework Bosch maintains an incident response team and published vulnerability disclosure program (accessible via product security links on Bosch websites, though many products carry third-party branding and cannot be disclosed directly). Security is integrated into a risk-based engineering process covering the full product lifecycle, with defined customer and supplier interfaces based on dialogue rather than fixed frameworks.

## Shift-Left Testing and Security Testing Chilling emphasizes the testing principle of "shift left"—finding bugs early reduces fix costs. Rather than waterfall development followed by testing, Bosch uses a V-model where specification review and test design begin immediately. Unit testing and code review are heavily emphasized. Applied to security, vulnerability testing and penetration testing occur before production, but designing for security from initial concept—and making developers security-aware from day one—is even more effective. This led Bosch to launch "Hack Like a Bosch," an internal CTF (Capture The Flag) gamification event.

## Hack Like a Bosch: Gamification for Awareness The event was designed to raise security awareness among non-security developers before they begin projects. Key design choices included: gamification (CTF format rather than traditional training), beginner-level focus, inclusion of non-software security challenges (reflecting physical product security), and internal hosting on the corporate network for privacy and security compliance (no external access, no hacking tools, only company-approved software permitted). Bosch partnered with external provider Israelit Lab, with internal domain experts reviewing challenges for relevance. The event was conducted entirely online in English and scaled globally across Bosch.

## Event Results and Challenges The event featured 30 challenges (11 non-software) and attracted nearly 500 players in teams. Nine teams completed all challenges, primarily existing security experts and software professionals. However, the event proved more difficult than intended and more software-focused than desired. Formulating engaging non-software challenges within a game environment remained unsolved; some required manual review instead of automated flag generation. Despite this, participants—especially those already working on security processes—reported gaining practical experience (e.g., buffer overflow exploitation) for the first time.

## Takeaways Cybersecurity is essential product quality requiring awareness across all developers; it is not solely a software problem but involves hardware, systems, and architecture. Internal gamification events are useful and enjoyable. Cross-domain collaboration is critical. Chilling noted limited feedback on whether participants applied security thinking in subsequent projects, suggesting the need for better impact measurement. Bosch plans to repeat the event.

## Questions Discussion covered technical details of the replay attack (including the buffer of acceptable keys and user behavior when the first unlock fails) and measured success (primarily reaching the security community rather than transforming general-population awareness). The event required six months and roughly ten people working in flexible time alongside their day jobs, with reasonable external budget for game development.