Security
I think through how a system could be attacked and design it so those paths stay closed.
- Threat modelling
- Secure by design
- Hardening
- Secure deployments
Dimitri K. TeguiaSoftware Engineer
Focused on secure backends, network infrastructure, security for rail systems, reliable CI/CD
I think through how a system could be attacked and design it so those paths stay closed.
Networks and pipelines that are boring in the best way: segmented, encrypted, automated, observed. Much of it tried out first in my own lab.
Clean, tested code across the stack, from Python research tooling to Java and TypeScript services.
Finds malicious code hidden in machine learning models.
Model files can execute code the moment they are loaded. dynamoscan loads them under syscall tracing, optionally in a locked-down container without network, so a model that phones home or spawns a shell is caught by what it does, not by what it looks like.
Started as my master's thesis on the security of ML model serialization formats.
The same few rules, whether it's a single service or a whole network. Here they are as a reference design.
Least privilege. Every account and key can do exactly one job.
Default deny. Nothing is reachable unless it has to be.
One ingress. A single TLS-terminating front door, nothing around it.
Automate it. If it's done twice, it becomes a pipeline.
Observe it. Logs and metrics before something breaks, not after.
I'm a software engineer who likes to ask how things could go wrong before they ship: hostile input, an untrusted network, a dependency that isn't what it claims to be.
Day to day, I build security products for railway infrastructure, where reliability isn't optional. At home, I run a small lab where I try out networking and infrastructure ideas before relying on them elsewhere.
Away from the keyboard, I play basketball, mostly for the challenge of getting a little better each time.
Working on something that has to be secure and reliable? I'd be glad to hear about it.