Where did you grow up, and what shaped you there?
Faezeh Nasrabadi: I grew up in Birjand, a city in eastern Iran with a strong tradition of education and scientific research. Growing up there, I was surrounded by highly accomplished people—especially close relatives with advanced degrees who built careers in academia, industry, entrepreneurship, and the public sector. Listening to them talk about pushing the boundaries of science in their own fields inspired me to follow a similar path.
When did the idea first emerge that you did not just want to do research?
I spent a significant amount of time conducting research, mentoring, and teaching. While finishing my Ph.D. research and writing my thesis, I found myself increasingly unwilling to let my tool, findings, and knowledge remain confined to the lab. Every new result felt rewarding, but I increasingly wondered whether it would ever make a difference beyond a research paper. That iss when I became interested in exploring how the work might create impact beyond research papers.
Was there a specific turning point?
What I just described was my internal drive, but the real turning point came when I received encouraging feedback from senior professionals in my field. During my PhD defense, instead of facing the usual barrage of tough questions, a highly experienced reviewer simply praised the novelty and impact of what I had built. Another reviewer scheduled a separate meeting just to discuss the toolchain's massive potential, helping me see a broader impact that I had overlooked while focusing on the technical details. Their recognition motivated me to spend a year investigating whether the problems my research addresses are genuinely important outside academia.
"My scientific mindset keeps me from being blinded by my own assumptions. It helps me focus on understanding real problems rather than building elegant solutions to problems that do not exist."
What is the idea you are exploring?
Imagine proving that a bridge is safe—but only analyzing the blueprint, never the bridge that was actually built.
That is similar to how much of today's software verification works. Most security proofs are performed on the source code developers write. But users never run source code on their devices—they run compiled machine code. During compilation and execution, subtle changes can introduce information leaks that were absent in the high-level proof. During my PhD, I developed a tool called CryptoBAP to investigate this gap. CryptoBAP analyzes compiled machine code and automatically extracts a mathematical model of its behavior. This makes it possible to mathematically prove security properties or uncover hidden security vulnerabilities on the exact software that ends up on a user's device—without even needing access to the original source code.
What problem do you want to investigate—beyond the technology itself?
The broader challenge I am interested in is reducing the false sense of security surrounding deployed software. Most users understandably assume that if the blueprint—their application's high-level source code—has been formally verified, the software running on their devices is equally trustworthy. Unfortunately, that is not always the case. Being able to prove the security of deployed binaries would provide much stronger assurance, protecting user privacy and security not just in theory but in practice.
What questions are you trying to answer?
At this stage, I am trying to answer two questions. First, can binary-level formal verification become practical enough that security engineers naturally integrate it into their existing workflows? Second, if that becomes possible, can verifying deployed binaries eventually become a standard expectation rather than a niche research capability?
This program is designed to empower Ph.D. students, postdoctoral researchers, and exceptional MSc students, to transform their innovative research in the fields of information security, privacy, and AI/ML into successful startups. On this site we provide you with a comprehensive overview of the program, its objectives, eligibility criteria, benefits, structure, and the application process.
What did the first few months of exploring broader impacts look like?
To test whether the gap between source-level proofs and deployed binaries mattered beyond academia, I engaged directly with industry practitioners. Those conversations suggested that practitioners see this gap as meaningful and worth investigating further.
What has surprised you most while exploring broader impacts?
What surprised me most is how differently the word "proof" is used outside academia. In research, "proof" has a precise mathematical meaning. In practice, it often refers to scan results, behavioral metrics, or compliance evidence. It taught me that technical precision alone is not enough—I first have to understand what people mean when they talk about security.
How has your research background influenced the way you approach real-world problems?
Coming from a research background, I have learned that instead of approaching a problem with a fixed idea of what the problem "should" be, I should start by listening carefully to what people actually experience. Then I form hypotheses, look for evidence to test them, and remain willing to revise my assumptions whenever the evidence proves me wrong. This scientific mindset keeps me from being blinded by my own assumptions and helps me focus on understanding real problems rather than building elegant solutions to problems that do not exist.
