Alex Rebert
Alex Rebert is a Senior Staff Software Engineer leading memory safety in the Information Security Engineering organization, whose goal is to keep Google’s products secure and users safe.
Before Google, Alex co-founded ForAllSecure to help companies find unknown vulnerabilities, where he led the team that created Mayhem, an autonomous agent that could find, exploit, and patch vulnerabilities. Mayhem won the DARPA Cyber Grand Challenge in 2016. Alex was named one of MIT Tech Review's 35 Innovators Under 35 and Forbes' 30 Under 30.
Before Google, Alex co-founded ForAllSecure to help companies find unknown vulnerabilities, where he led the team that created Mayhem, an autonomous agent that could find, exploit, and patch vulnerabilities. Mayhem won the DARPA Cyber Grand Challenge in 2016. Alex was named one of MIT Tech Review's 35 Innovators Under 35 and Forbes' 30 Under 30.
Authored Publications
Sort By
Preview abstract
2022 marked the 50th anniversary of memory safety vulnerabilities, first reported by Anderson et al. Half a century later, we are still dealing with memory safety bugs despite substantial investments to improve memory unsafe languages.
Like others', Google’s data and internal vulnerability research show that memory safety bugs are widespread and one of the leading causes of vulnerabilities in memory-unsafe codebases. Those vulnerabilities endanger end users, our industry, and the broader society.
At Google, we have decades of experience addressing, at scale, large classes of vulnerabilities that were once similarly prevalent as memory safety issues. Based on this experience we expect that high assurance memory safety can only be achieved via a Secure-by-Design approach centered around comprehensive adoption of languages with rigorous memory safety guarantees.
We see no realistic path for an evolution of C++ into a language with rigorous memory safety guarantees that include temporal safety. As a consequence, we are considering a gradual transition of C++ code at Google towards other languages that are memory safe.
Given the large volume of pre-existing C++, we believe it is nonetheless necessary to improve the safety of C++ to the extent practicable. We are considering transitioning to a safer C++ subset, augmented with hardware security features like MTE.
View details
