Hi, I'm Sedat Özdemir. I've spent close to a decade in security, mostly on the offensive side: penetration testing web applications, APIs, internal networks and mobile apps, red team work, and more recently offensive AI. Over time most of my work shifted from reporting findings to changing the process that produces them: getting SAST/DAST into CI, hardening container and Kubernetes configurations, fixing how secrets are handled.
I came to security from software. I've done full stack development in 12 programming languages, and I understand how an application breaks partly because I know how I'd have built it. I spent years doing systems administration too; Linux and Windows are both second nature. Together those two mean that when I report a finding, I can also see the work facing the person who has to fix it.
I've spent most of my career in regulated industries. That taught me to take the human side of this work as seriously as the technical side: closing a vulnerability starts with working out who will close it and why they'd want to. A recommendation that is technically correct but impossible for anyone to act on ends up in the same place as one that was never written.
Outside work I'm still at a screen. I trained in UI/UX and design, and I stand behind the design work I do, this site included. I'm into photography and video, shooting with a Sony A7 II and a DJI Mini 5. What's left of my time goes to AI: how custom models get trained for security work, and how those models are secured themselves. That's the question I'm most curious about right now.
I look at bug bounty programmes, play CTFs, and write up what I learn. This blog is where those notes live: how a vulnerability actually works, where a tool falls short, why a particular misconfiguration keeps coming back.
There's plenty I don't know, and I write about that too. I'm not deep in every area, and on some subjects I trust the people who actually do the work far more than I trust myself. When I'm not sure about something I try to say so in the post. I think the most damaging habit in this industry is stating an uncertain thing with certainty.
About this blog
Everything here is my own opinion and does not represent any organisation I work for or have worked for. Every example I use comes either from public sources (CVE records, vendor advisories, open source code) or from my own test lab. I don't share information, incidents or findings relating to any employer, client or their systems, neither directly nor by implication. IPs and domains in technical examples are defanged and fictional.
What I worked on in past roles
- Compliance audits. I worked on building security programmes in preparation for audits such as PCI DSS, PCI SSF and BDDK. The lesson: what gets you through an audit is the boring work in the months beforehand, not audit week itself.
- Remediation programmes. I ran the process of closing critical and high findings across a large number of production applications. The hard part was never finding them; it was turning them into work that fits a development team's sprint.
- Teams and process. At various points I worked with security teams and cross-functional Agile teams, trying to keep doing hands-on work while leading. I didn't always manage it.
- Tooling decisions. I handled security tooling budgets and vendor evaluation. The lesson I took from it: most teams don't have a tooling gap, they have tools nobody looks at.
- Internal tooling. For cases where data must not leave the organisation, I built analysis tooling that runs in-house. The goal wasn't a magic AI; it was speeding up repetitive work.
What you can write to me about
Conference or meetup talks, interviews, or correcting a mistake in a post. If you're early in your career, I'd rather talk about which problem you want to solve than which certification to take. A "where should I start" question from someone new is as welcome as an email pointing out a mistake in one of my posts.