Divan-e-Cyber

As with cybersecurity, interpretation and attribution count.

  • Closing the Loop in AI Code Fixes

    CTEM Was Built for a Different Problem
    Continuous Threat Exposure Management gave security teams something they badly needed: a systematic way to move from reactive alert-handling to proactive exposure reduction. Scope your environment. Discover what’s exposed. Prioritize by real risk. Validate that risk. Mobilize a fix.
    The framework is sound. But every stage of it was designed with one assumption so obvious nobody wrote it down: a human wrote the remediation.
    When a developer fixed a vulnerability in 2019, a few things were true. They understood the code they were changing – or at least had a working mental model of it. A peer reviewed the diff. The review process was the verification layer. It was imperfect, but it existed, and it was independent of the process that found the vulnerability.
    That independence mattered more than anyone realized.

    What Changes When AI Proposes the Fix

    Your CTEM program is working. Findings are being discovered, prioritized, and closed. Your metrics look clean. Your mobilization rate is up.
    And somewhere in your codebase right now, there is unverified code that your vulnerability management workflow put there.


    Walk through what the current toolchain actually does.
    MDASH – Microsoft’s multi-model agentic scanning engine – finds a vulnerability. It doesn’t rely on pattern matching. It reasons about code logic the way an attacker would, catches what traditional static analysis misses, and produces a finding with full context. So far, this is discovery working better than it ever has.
    Then Security Copilot or GitHub Copilot Autofix proposes a remediation. It analyzes the vulnerability, understands the surrounding code, and rewrites it. The diff appears in the PR. It looks clean. It addresses the finding. Tests pass.
    The developer reviews it. Approves it. Merges it.
    Finding closed.
    But here’s what didn’t happen: nobody scanned the fix.
    The new code that Copilot wrote – the remediation itself – re-entered your codebase as unverified input. It passed a code review, which is a human judgment about whether the logic looks correct. It did not pass the same agentic scanning process that caught the original vulnerability.
    You closed one loop. You opened another. Most CTEM programs have no process for the second one.

    Why This Is Different From “Review Your Code Reviews”


    This is not an argument that code reviews are insufficient, or that developers are careless. Both of those arguments are old and mostly unhelpful.
    This is a structural problem with a specific cause.
    When MDASH finds a vulnerability in AI-generated code, it is often finding something that exists because the original code contained logic that no human fully modeled. That’s the point – it catches what pattern matching misses precisely because human comprehension isn’t the detection mechanism.
    But when Copilot proposes a fix for that vulnerability, the reviewer’s ability to independently verify correctness depends on their comprehension of the original logic. If that logic was generated by AI and never fully understood by a human, the reviewer is evaluating an AI’s answer to a question they never completely understood in the first place.
    The diff looks right. The fix is syntactically correct. The tests pass.
    None of that answers the question: did the fix introduce something new?

    The Recursive Problem


    AI-proposed fixes are code. Code has vulnerabilities. The system that found your original vulnerability did not scan the remediation.
    This is not a theoretical edge case. It is the default state of every AI-assisted remediation workflow that hasn’t explicitly addressed it. Which, right now, is most of them.
    The attack surface for your remediation code is real. A fix that parameterizes an XPath query is easy to reason about – any practitioner can verify it. But as AI-generated code increases as a percentage of your total codebase, and as the vulnerabilities being fixed involve increasingly complex logic, the gap between “syntactically correct fix” and “semantically correct fix” widens.
    Your CTEM program is not built to see that gap. It was designed to close findings, not to treat remediations as new inputs requiring their own discovery cycle.

    The Question Your CTEM Program Can’t Currently Answer


    Go look at your last ten closed findings that were remediated by AI-proposed fixes.
    For each one, ask: was the remediation code scanned before it merged?
    If the answer is no – or if you’re not sure – your mobilization stage has a gap that your metrics aren’t showing you.
    The framework works. The assumption embedded in it doesn’t hold anymore.
    Part 2 of this series covers what fix verification actually requires, and why “have a human review the diff” is not a sufficient control when the code complexity exceeds the reviewer’s mental model.

    What “Mobilization Complete” Needs to Mean Now
    The traditional definition is straightforward: the finding is resolved, the fix is deployed, the ticket is closed.
    That definition needs one additional condition: the remediation has been scanned.
    Not reviewed. Scanned. By the same class of tooling that found the original vulnerability. Because a human code review and an agentic scan are answering different questions. The review asks whether the fix looks correct. The scan asks whether the fix introduced something new.
    You need both answers before you close the loop.
    This is achievable today. MDASH can run as a post-fix gate in your pipeline before PR merge. That’s not a significant workflow change – it’s a pipeline step. But it only happens if you build it in deliberately. It will not happen by default.
    Most teams haven’t built it in. Most teams don’t know they need to.

    Read more: Closing the Loop in AI Code Fixes
  • You named it.

    Persian last names

    Persians didn’t have last names until the 20th century, when in 1925 Reza Shah mandated it. My full last name, Mashhadi Ghadiri, falls into two of the 7 categories of Persian last names. The first part, Mashhadi, refers to someone who has made the pilgrimage to Mashhad, one of the holiest cities in Iran in the Islamic faith, and nods to both power and pilgrimage — Ghadiri comes from ‘Qadir,’ meaning capable. It’s a name about choosing the path with intention.

    Naming cybersecurity incidents

    Cybersecurity incidents are typically named using one of several conventions to aid tracking, communication, and analysis. Common methods include using the date of occurrence (e.g., “Incident-20250425”), the affected entity (e.g., “M365-Incident”), or the threat actor or campaign involved (e.g., “APT29-LateralMove”). Other approaches focus on the attack technique (e.g., “RDP-BruteForce”), the targeted asset (e.g., “ProdAPI-SQLInjection”), the malware or tool used (e.g., “Emotet-Infection”), or a combination of severity and category (e.g., “Critical-DataExfil”). These naming structures help standardize incident reporting and streamline response across teams, but often can make sharing information or understanding similar attacks across entities or organizations.

    So what?

    Both systems are designed to convey identity, origin, and context in a compact, recognizable form. Both systems reflect a deep cultural or operational need: to encode meaning, history, and relationship into something short enough to be remembered—but rich enough to be understood.

    The version you choose to name a cybersecurity incident—just like choosing a surname—shapes how it’s perceived, tracked, and responded to. Here’s why it matters:

    1. Clarity and Communication

    • A well-chosen name instantly signals what happened and to whom.
      • “TokenTheft-SessionHijack” is more actionable than “Incident-0425”.
      • Similarly, Shirazi gives cultural/geographic context in a way Reza alone does not.

    2. Attribution and Analysis

    • Names tied to threat actors (APT29), techniques (RDP-BruteForce), or tools (CobaltStrike) allow teams to connect dots across incidents.
      • Just like Mashhadi tells you someone made pilgrimage to Mashhad, Mimikatz-Use implies credential dumping.

    3. Triage and Prioritization

    • Including severity or asset class in a name helps with prioritization.
      • Critical-DataExfil is clearly urgent.
      • In Persian names, Qadir (capable) implies rank or responsibility, signaling social weight.

    4. Long-Term Tracking and Reporting

    • Incident names become part of historical data and intelligence feeds.
      • Consistent naming enables automation, dashboards, and trend analysis.
      • Attacks follow histories and societal changes across ‘generations’ just the same.

    5. Cultural and Strategic Implications

    • Names reflect what the organization values or fears—whether it’s data loss, nation-state actors, or internal misuse.
      • Just as Persian surnames once signaled social class or religious devotion, incident names can shape an org’s security posture narrative with this incident and future incidents.

    In short: Choosing the right naming convention isn’t just administrative—it’s strategic. It defines how people talk about the threat, understand its origin, and decide what to do next.

    Read more: You named it.
  • Two Very Different Languages — Or Are They?

    People are always surprised when I say this, but learning Farsi and learning cybersecurity have a lot in common.

    One is the language of my heritage. The other, the language of my profession. But both require the same things: pattern recognition, patience, humility, and the ability to sit with complexity.

    When I started learning cybersecurity, the connections I made to the world around me felt like entering the Matrix.
    When I started learning to read and write in Farsi, I felt the exact same way.

    I followed the white rabbit. 🐰


    Cybersecurity is a Language and a Culture

    In cybersecurity, you don’t just learn tools — you learn tools have tenses that render the past and the present, they both parse and normalize, and require interpretation to determine intent. You learn how painfully systems struggle to communicate and how mimicry can fool anyone into thinking maybe dexterity in a single tool is fluency.

    It’s a language of patterns and antipatterns. In fact, you may be familiar with a favorite of mine, “Collection is not detection” by Mark Simos.


    The best part is as you start to recognize the signals, and you think MAYBE you are fluent, there are levels upon levels of meaning depending on where you look and listen.


    Farsi is a Language and a Culture

    Farsi taught me to read between the lines, and to know that one word might carry five meanings. Its a language where understanding that how something is said often matters more than what’s said.

    There’s poetry in it, as well as its patterns that come in the form of rhythm and subtlety.

    The best part is as you start to recognize the signals, and you think MAYBE you are fluent, there are levels upon levels of meaning depending on where you look and listen.

    See what I did there?


    Guess what else is true between the two?

    • You don’t have to be fluent to participate.
    • Mistakes are inevitable — and necessary.
    • The point isn’t perfection. It’s attempting to understand.
    • Every system, whether human or digital, has its own logic — and its own vulnerabilities.

    I purposefully seek out new things in both Farsi and cybersecurity every day.

    Sometimes I learn a new proverb.
    Sometimes I learn a new attack vector.
    And sometimes I realize the same principles in one applies to the other.

    • Build trust with shared vocabulary intentionally.
    • Pay attention to signals.
    • And never assume what’s on the surface is the whole story.

    So what is Fluency?

    I’m not fluent in either yet — not in the way I hope to be, but that isn’t the point.
    I am invested. I am here to keep learning. I tell my kid frustration is the feeling of your brain growing and learning. It’s a crucial part of the experience!


    Translating complexity is frustrating, in Farsi or cybersecurity. Explaining concepts to those whose native language just…doesn’t have the words adds even more layers. In Farsi, many in the older generations speak in proverbs rather than directly. I used to find it insanely frustrating because a literal translation only rippled the surface. Now, I appreciate the layers and the water that moves underneath the ripples.

    I want to share with you a line from Ferdowsi’s Shahnameh. It just so happens to be a very meaningful text to most Persians as is the the story that saved the Persian language from extinction.

    به عمل کار برآید، به سخندانی نیست

    be amal kār bar-āyad, be sokhandāni nist

    “Work gets done through action, not fancy words.”

    It is used when someone overpromises, or in mentorship moments where effort is more respected than eloquence.

    Effort is more respected than eloquence.

    Wild how that directly translates into cybersecurity just the same…😳😅

    Thank you to the MSFarsi team for helping me connect with both sides of my love of language and culture. I will be starting a mentoring community for female identifying Farsi language speakers who are and looking to get into cybersecurity. More to come in a future post.

    Read more: Two Very Different Languages — Or Are They?
poetry

🔐 Ghazal: “All Access Is Conditional”

(a modern security poem in ghazal form)


In this realm of cloud and claim, all access is conditional
The lover may knock, but still — permission is provisional

The gate is silent, the ID speaks, its posture holds the key
From signal comes salvation — detection is intuitional

Trust no device, no sign-in time, unless the risk aligns
The dance of context and control is wholly intuitional

Her token glowed, yet prompts appeared — a second factor asked
The veil may lift, but only when the bond is traditional

No open ports, no phantom guests, no silent lateral flow
My realm is built on principle, protection constitutional

From Persia’s gardens to Azure clouds, the guardians still remain
Their watchful eyes in every log — the shield is unadditional

And Mona writes, like Hafez would, of XDR and fate
To love the user is to test — the trust must be conditional*

Poetry inspired by a cybersecurity mindset

Exploring the intersection of creativity and security through poetry. Mona reflects on thoughts and lessons that shape her approach.

poetry

© 2025 Mona Ghadiri. All content, including text, images, and original poetry, is the intellectual property of Mona Ghadiri unless otherwise noted. Unauthorized use or reproduction is prohibited.