Dimitri K. TeguiaSoftware Engineer

Software that holds up under attack.

Focused on secure backends, network infrastructure, security for rail systems, reliable CI/CD

01 · Focus

Where I work

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

Infrastructure

Networks and pipelines that are boring in the best way: segmented, encrypted, automated, observed. Much of it tried out first in my own lab.

  • Networking
  • Reverse proxies & TLS
  • Segmentation & VPN
  • Firewalling
  • Observability
  • CI/CD

Engineering

Clean, tested code across the stack, from Python research tooling to Java and TypeScript services.

  • Python
  • Java
  • TypeScript
  • SQL
  • C++
  • Docker
  • Linux
  • REST APIs
02 · Open source

dynamoscan

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.

model formats, from PyTorch to GGUF
10+model formats, from PyTorch to GGUF
level behavioural tracing
syscalllevel behavioural tracing
isolation, no network
Dockerisolation, no network
View on GitHub
Real output from a test model, condensed.
03 · Approach

How I build

The same few rules, whether it's a single service or a whole network. Here they are as a reference design.

Reference topologyInternet traffic reaches services only through a single TLS edge. Admin access goes through a VPN. Services, admin and data live in separate zones. A direct path from the internet is denied.segmented zonesdefault denywwwinternetedge · TLSVPNservicesadmindata
  1. 01

    Least privilege. Every account and key can do exactly one job.

  2. 02

    Default deny. Nothing is reachable unless it has to be.

  3. 03

    One ingress. A single TLS-terminating front door, nothing around it.

  4. 04

    Automate it. If it's done twice, it becomes a pipeline.

  5. 05

    Observe it. Logs and metrics before something breaks, not after.

04 · About

The person behind it

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.

M.Sc. Computer Science, TU Braunschweig
Thesis: Security Analysis of Machine Learning Model Serialization Formats
B.Sc. Computer Science, TU Clausthal
Thesis: Design and Implementation of a Modular Software Solution for Enabling One-Way Communication over Data Diodes in OT Networks
05 · Contact

Open to interesting problems

Working on something that has to be secure and reliable? I'd be glad to hear about it.