Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
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.
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.
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.
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.
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.
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.