Security portfolio

Security work I led on my own live products

I'm Sergiu Vincze, self-taught, based in Belgium. I run and secure my own live products: the CauseHub donation platform, BLE Radar / Invisible Atlas, SevinHub HQ and the svh.li link shortener. I'm looking for a role in cyber security. Below is real work, newest first, written so you can check it.

How the work gets done: I direct an AI team. Compass coordinates, Sentinel does the security work, Forge reviews the code. I make the decisions, review the evidence and approve what goes live. Each card says who did what.
Belgium Romanian, English (C1), Dutch (basic) Open to a cyber security role
Cases

Problem, evidence, decision, build, test, result

12 Oct 2026 BLE Radar / Invisible Atlas Live

Stopping a scraping crawler pool at the edge

Problem
In one day, 27 to 29 of the 32 "users" our analytics counted on BLE Radar were one crawler pool in Shanghai: 33 rotating addresses inside a single /24 of China Telecom, running a real Chrome, one page per address, walking the public per-hex data pages. It skewed every analytics number and harvested data our terms of use forbid scraping.
Evidence
Web server logs, read as counts and networks only, and 14 days of app traffic: 0 real app users from China. The pool never asked for robots.txt, and no address made more than 3 requests to the stats page, so a per-address rate limit would never have fired.
My decision
Block China on BLE Radar only. Every other site stays open.
What was built
Sentinel built an nginx geo map of every China prefix (RIPEstat country data: 5,689 IPv4 and 2,383 IPv6 prefixes) that answers 403 before any PHP runs, scoped to one site. Carve-outs for our own server, search engines, payment webhooks. One command each for on, off, uninstall and refresh, a backup first, and an automatic undo if the config test fails.
How it was tested
A 61-check harness on a full copy of the nginx config with a private nginx: blocked against allowed addresses, uninstall leaves the site config byte-identical, bad list data is refused. I installed it myself, in manual mode.
Result
Live on BLE Radar only, with one command each to switch it on or off.
Also found
Every per-hex page cost about 1.4 s of database work: a denial-of-service lever for anyone, from any country. It is now cached at about 0.07 s, with the values verified equal to a direct read.
Log analysis Threat attribution by network nginx hardening Safe change management Rollback design
12 Oct 2026 SevinHub HQ Live

A drift guard on the deploy path

Problem
A deploy could silently overwrite a hand fix made on a live server (it happened once on CauseHub in September), and an automatic rollback would have left the dashboard unreadable to the web server because of wrong file modes.
What was built
My team built a guard: every deploy compares the live files with a recorded sha256 fingerprint and stops on any difference, records a new fingerprint after each good deploy, and a rollback restores the correct file modes. A drift report covers 3 projects. The script is locked with the immutable flag (chattr +i), and my AI agents cannot lift that flag or edit the deploy folder without my approval.
How it was tested
Forge, the code reviewer on my team, gave GO only after sandbox scenarios and mutation tests: deliberately broken copies of the script that the tests had to catch.
Result
First real use on 12 Oct at 22:18: an HQ release went out through the guard, with the test suite at 93 green and the live checks passing.
Secure CI/CD thinking Integrity checking Least privilege for AI agents Change control
12 Oct 2026 BLE Radar / Invisible Atlas Live

A fake position at the North Pole, and the latitude bug that let it in

Problem
One map cell at 87 degrees north appeared in the public atlas. It was traced to a probe: a client on a hosting network sent 6 typed whole-degree positions on 4 continents in 49 seconds. It earned nothing. A probe on 14 Sep showed the same pattern.
Investigation
Sentinel found that the existing server-side fake-position check refused 5 of the 6. The 6th slipped through because of a latitude bug: the check's 0.01 degree pre-filter was only 58 m of longitude at 87 degrees north, so the exact test never ran. Proven by rebuilding the session from the server's own cache and replaying it against the live code.
My decision
Remove the polar cell, with a backup first, then put the new guard live after Forge's review. The data cleanup goes ahead only on my go.
What was built
Sentinel built a server-side guard that refuses positions no phone can be at (beyond 85 degrees, and null island) on the very first upload, with a pre-filter measured in kilometres. It covers mining, the web walk mode, speed tests and live pins, and needs no app update.
How it was tested
Before and after on the same cases: the incident reproduces, then is refused, and both probes are refused 12 of 12. All 3,386 real map cells still pass. A 1-second regression guard was proven by a mutant.
Result
Live since 12 Oct, after Forge's review: the regression guard is green on the live code, and uploads from real phones are still accepted.
Incident response Root-cause analysis Data integrity Geospatial validation (H3) Regression testing
11 Oct 2026 Sites on my server Stage A live

Bot shield, stage A: cloud networks blocked at the firewall

Problem
Automated scanners probe every site for files and admin paths that do not exist here.
Evidence
Over 14 days and 1.29 million requests: 32,587 hits on 9 groups of paths no page here uses, from 626 addresses. Never a real file, and none from payment or search providers.
What was built
Sentinel built a shield in stages. Stage A: an nftables block of the cloud networks of Huawei, Tencent and Alibaba (6 ASNs, each verified on RIPEstat and bgp.tools; 735 IPv4 and 91 IPv6 ranges), minus payment, search, major clouds, the certificate authority and our own server, with an automatic list refresh behind 6 guards.
How it was tested
In an isolated harness with its own network namespace, a copy of the live config, and real fail2ban and nftables: 2,850 of 2,850 trap hits handled right while 3,071 real paths and 73 assets stayed unchanged; the shield end to end 72 of 72; an install rehearsal with rollback 26 of 26. The tests caught bugs before anything went live, for example a fail2ban date pattern that silently fell back to "now". Honest note: the rehearsal left one isolated test process running; it was found two days later and stopped.
Result
Stage A live since 11 Oct at 14:11, with certificate renewals proven to still work. Every later stage goes live only together with the privacy text that describes it.
Firewall rules (nftables) fail2ban ASN research Test harnesses Staged rollout

Left out on purpose: full addresses, keys, exact live configurations and any user data. The counts, networks and methods are real, and I'm happy to walk through any case in an interview.

How I work

The same five rules on every change

Evidence before action

Logs and counts first, then a decision. A number I cannot check does not go in a report.

Test on a copy

Every change is proven on a full copy of the real config before it touches a live server.

One-command rollback

On, off and uninstall are single commands, tested both ways before install.

Least privilege for agents

My AI agents build and test; risky live steps run in my hands, and guard scripts are locked.

Privacy first

Reports name networks and counts, never people, and the privacy policy is updated before any new data is collected.

Hiring for a security role?

Send me a message. I read every one myself.

Email me About me
SevinOS Invisible Atlas