Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
Responding to an Application Security Incident: Detection, Scoping, Preserving Evidence, Communication and Notification
In a security incident you preserve evidence first, derive the affected records from the audit log instead of guessing, then fix, and bring in legal and the person responsible for personal data in the first hour. A BOLA case in Bookstore where one institution reads another's orders: NIST SP 800-61r3, a hashed evidence copy, the affected-records query and its test, the fix, customer and KVKK notification, a runbook and a tabletop exercise.
Working with Penetration Testers: Scope, Rules of Engagement, Reading Findings, Retesting and After the Report
The value of a pentest depends on the scope and rules of engagement written before it starts, and on turning every finding into a regression test and a decision after it ends. Pentest, DAST, bug bounty and red team compared; scope, test accounts and stop conditions for Bookstore's Institutional Orders pentest, a severity dispute, a false positive with evidence, grouping by root cause, fixes and tests for F-01 and F-02, retest and the threat model update.
Vulnerability Management for Your Own Product: security.txt, Coordinated Disclosure, GitHub Security Advisories and CVEs
A vulnerability report from outside first needs a door: an RFC 9116 security.txt, SECURITY.md and GitHub private vulnerability reporting; then triage, a private fix in the draft advisory, a CVE request and publication on the same day as the fixed release. Serving and testing security.txt from the Bookstore API, sectxt validation, the advisory flow for the Bookstore.Contracts NuGet package, bug bounties and safe harbor.
Writing Security Requirements: Choosing a Level with OWASP ASVS 5.0, Acceptance Criteria and Security Champions
A security requirement means choosing an ASVS level in writing and verifying every selected item with a test or evidence, not filling in 345 rows. For Bookstore: an ASVS 5.0 Level 2 target plus one Level 3 item taken on purpose, a requirements file, security acceptance criteria and an abuse story, the Definition of Done, an xUnit test that keeps the file and the tests in step, the security champion and a NIST SSDF mapping.
Finding and Prioritising Threats with STRIDE: STRIDE per Element, Attack Trees, Risk Scoring and Mitigation Decisions
You apply STRIDE to every DFD element according to its type, rank the threats by likelihood × impact, decide to mitigate, eliminate, transfer or accept each one, and tie every decision to a test or a risk register row. On the Bookstore webhook and the institutional purchase approval: LINDDUN, attack trees, why DREAD was dropped and xUnit tests that verify the four-eyes rule, with real output.
What Is Threat Modeling? The Four Questions, Data Flow Diagrams and Trust Boundaries for the Bookstore Checkout
Threat modeling means asking "what can go wrong?" on a representation of the system before the code is written, and it helps most at design time. With the four questions of the Threat Modeling Manifesto, DFD elements and trust boundaries we model the Bookstore checkout, payment and shipping flow, version the model as JSON in the repo with OWASP Threat Dragon 2.6.2 and tie it to the PR template.
Cross-Border Transfers and Breach Readiness: Cloud Regions, LLM Providers, Standard Contracts and the 72-Hour Notification
A transfer abroad is not only where the server is; logs, backups, e-mail, analytics and LLM prompts are transfers too, and since 2024 they must rely on an adequacy decision, an appropriate safeguard such as a standard contract, or an occasional case. On Bookstore we keep the sub-processor inventory in code, check the five-business-day notification of standard contracts at start-up, and use an access log to get a breach's scope and the 72-hour deadline within the first hour.
Privacy Notices, Explicit Consent and Cookies: Recording Consent, Cookie Banners, Consent Mode and Commercial Message Permissions (İYS)
A privacy notice is given for every processing activity, while explicit consent is obtained separately and only where processing relies on it; consent must be provable, versioned and revocable. On Bookstore we build an append-only ConsentRecord, an Angular banner with equal buttons following the Authority's cookie guide, Google Consent Mode with a denied default, Playwright tests that verify them, and reporting commercial e-mail permissions to İYS within three business days.
Personal Data in Logs, Telemetry and Analytics: URLs, Exception Messages, IP Addresses, Session Replay and Error Reporting Tools
Personal data rarely enters logs through a LogInformation call; it gets in through an e-mail address in the URL, a record passed to a log message, an exception message, a span tag or a metric label. On Bookstore's checkout flow we show these leaks with real output, lock them down with a test that searches for canary values, clean browser error reports, truncate IP addresses and add telemetry to the inventory.
Retention, Deletion and Anonymisation: "Delete My Account", Soft Delete, Backups, Caches and the Periodic Destruction Job
A "delete my account" request is not one DELETE but a separate decision for every piece of data: the profile is erased, orders are detached from the person and kept for the legal period, then anonymised. On Bookstore we show the foreign key pitfall, why soft delete is not enough, how each copy is erased, the periodic destruction job, the destruction log and how an erasure ledger stops erased customers from returning after a backup restore, with real output.
Protecting Personal Data: Always Encrypted, Application-Level Encryption, Pseudonymisation, Masking and Test Data
The way to protect a sensitive personal data field is to choose the layer by threat: TDE protects the disk, Always Encrypted the DBA, application-level AES-GCM the backups and replicas, and masking only the screen. On Bookstore we encrypt the invoice national ID with purpose-bound AES-GCM, search it with an HMAC blind index, show it masked to support and move test environments to synthetic data with deliberately invalid IDs generated by Bogus.
Personal Data Inventory and Privacy by Design: Classifying Data, Marking It in Code and Minimisation
The technical half of a personal data inventory can be generated from code: we classify entities with Microsoft.Extensions.Compliance attributes and derive tables, columns, purposes, retention periods and copies from the EF Core model. A test that catches unclassified fields, a SQL Server sensitivity label script, minimisation decisions such as an age confirmation instead of a birth date, PCI DSS and LINDDUN on Bookstore, with real output.