DEV Community: Sakramen

Feature Matching: From Brute Force to a Robust Pipeline

Sakramen — Sat, 15 Aug 2026 16:15:08 +0000

Why Feature Matching Matters

Feature detection finds interesting points in a single image — corners, blobs, distinctive textures. Feature matching is the next step: figuring out which keypoint in image A corresponds to which keypoint in image B, meaning they represent the same physical point in the world. This correspondence is the foundation of image stitching, 3D reconstruction, visual localization, and object recognition.

Brute-Force Matching

The simplest strategy compares every descriptor in image A against every descriptor in image B and keeps the closest one. For N features in image A and M in image B, that's N×M distance computations.

The distance metric depends on the descriptor type:

Float descriptors (SIFT, SURF) use L2 (Euclidean) distance.
Binary descriptors (ORB, BRIEF, BRISK) use Hamming distance — the number of bits that differ — computed efficiently with bitwise XOR plus a popcount.

The cost adds up fast. With 5,000 features per image and 128-dimensional SIFT descriptors, brute-force matching means 25 million 128-dimensional distance computations. That's fine for small images but becomes a bottleneck at scale.

FLANN: Approximate Nearest Neighbors

FLANN (Fast Library for Approximate Nearest Neighbors) builds an index — typically a randomized k-d tree or a hierarchical k-means tree — over the descriptors of one image. Instead of scanning every descriptor for every query, each lookup only examines a small subset of likely candidates.

This trades exactness for speed: FLANN is typically 10–100x faster than brute-force, but it can occasionally miss the true nearest neighbor since it's approximate. For most vision tasks that tradeoff is worth it — a slightly imperfect match rarely matters once you filter matches downstream anyway. OpenCV picks an appropriate FLANN algorithm automatically based on descriptor type.

Lowe's Ratio Test

Not every feature in image A has a genuine match in image B. Parts of the scene may be occluded, backgrounds may only appear in one image, or two unrelated features may look coincidentally similar. Raw nearest-neighbor matching doesn't know the difference — it always returns something.

The ratio test, from David Lowe, filters these out. For each feature in image A, find its two nearest neighbors in image B, then compute:

distance(best match) / distance(second-best match) < threshold

Keep the match only if this ratio is below the threshold — commonly 0.75.

The logic: if a feature has one clearly closest neighbor and everything else is far away, that match is trustworthy. If the best and second-best candidates are nearly tied, the descriptor is ambiguous and the match shouldn't be trusted, regardless of which one scored slightly better.

In practice this eliminates 70–90% of false matches while keeping most true ones. It should be considered a mandatory step in any matching pipeline, not an optional refinement.

RANSAC for Outlier Rejection

Even after the ratio test, some bad matches slip through. RANSAC (Random Sample Consensus) is a robust estimation technique built to handle exactly this: separating inliers (correct matches) from outliers when a meaningful fraction of your data is wrong.

The algorithm:

Sample — randomly pick the minimum number of matches needed to estimate the geometric model (4 points for a homography, 5 for a fundamental matrix).
Estimate — compute the model from that sample.
Score — count how many of the remaining matches agree with the model within some distance threshold (inliers).
Repeat — run many iterations, keep the model with the most inliers.
Refine — re-estimate the final model using all inliers from the winning iteration.

RANSAC is surprisingly tolerant of bad data — it can recover the correct model even when 50% or more of the matches are wrong. The number of iterations required depends on the inlier ratio and desired confidence. As a concrete example: with a 50% inlier ratio and 4-point samples, about 72 iterations get you to 99% confidence of having sampled at least one all-inlier set.

The Full Pipeline

Putting it together, a robust matching pipeline looks like:

Detect features and compute descriptors in both images.
Match descriptors with brute-force or FLANN.
Filter with Lowe's ratio test (threshold ~0.75).
Estimate a geometric model with RANSAC to reject remaining outliers.
Refine the model using all surviving inliers.

This five-step sequence is the standard backbone behind virtually every classical feature-based vision task — stitching panoramas, aligning point clouds, localizing a camera against a map. Skipping any single stage — matching without the ratio test, or accepting matches without RANSAC — tends to produce systems that work on easy images and fall apart on real-world ones.

Learn More

This post covers the core ideas from the full lesson on Feature Matching, part of the Feature Detection & Description chapter in NeutralBlock's Computer Vision track. The full lesson, like everything on NeutralBlock, is free: https://neutralblock.com/learn/computer-vision/cv-chapter-2/feature-matching

How Buffer Overflows Actually Hijack Program Execution

Sakramen — Fri, 14 Aug 2026 16:43:02 +0000

Why the Stack Matters

When a program runs, its memory splits into regions: the text segment (executable code), the data segment (globals/statics), the heap (grows upward, dynamically allocated), and the stack (grows downward, holds function call frames).

Every function call pushes a new stack frame containing local variables, the saved base pointer (EBP/RBP), and the return address — the address execution jumps back to once the function finishes. That return address is the target of a classic buffer overflow.

The Vulnerable Pattern

void vulnerable(char *input) {
    char buffer[64];
    strcpy(buffer, input);
}

strcpy copies input into buffer with no length check. If input is longer than 64 bytes, the extra bytes spill past the buffer into whatever sits next on the stack — which, sequentially, is the saved base pointer and then the return address. Write enough carefully chosen bytes and you're no longer overflowing a buffer, you're rewriting where the CPU jumps when the function returns.

How the Exploit Actually Works

A stack-based overflow exploit generally follows five steps:

Identify the vulnerability — find a function that copies user input into a fixed-size buffer without bounds checking.
Determine the offset — figure out exactly how many bytes are needed before you start overwriting the return address. Tools like Metasploit's pattern_create and pattern_offset generate unique byte patterns so you can pinpoint this precisely instead of guessing.
Control the return address — overwrite it with a pointer to memory you control.
Insert shellcode — place executable machine code in the buffer itself, so there's something worth jumping to.
Use a NOP sled — prepend the shellcode with a run of no-operation instructions. This widens the target area so minor address miscalculations still land inside the sled and slide into the shellcode.

The Defenses That Exist Now

Modern systems don't leave this wide open. Several protections stack on top of each other:

Protection	What it does	How it gets bypassed
Stack canaries	Random value placed before the return address, checked before the function returns	Information leaks that reveal the canary value
ASLR	Randomizes memory layout on each run	Brute force, info leaks, or return-oriented programming
DEP/NX	Marks stack memory non-executable	Return-oriented programming (ROP) chains
PIE	Randomizes the executable's base address	Info leaks combined with ROP

Notice the pattern: almost every defense is eventually worked around with either an information leak or ROP — chaining together small existing code fragments already marked executable, instead of injecting new shellcode. Defense in depth here means each protection raises the cost of an exploit, not that any single one is unbeatable alone.

Heap Overflows Are a Different Beast

Stack overflows go after the return address. Heap overflows instead corrupt the metadata that malloc and free use internally to track allocated chunks. Corrupting that bookkeeping data can hand an attacker an arbitrary write primitive — the ability to write attacker-chosen values to attacker-chosen addresses. It's more complex to pull off than a stack overflow, but it can sidestep protections that are specific to the stack.

Fixing It at the Source

All of this traces back to one root cause: functions that copy data without checking length. The fix starts in the code, not in the mitigations:

Replace strcpy with strncpy or strlcpy
Replace sprintf with snprintf
Replace gets with fgets (never use gets, full stop)
Where you can, use a memory-safe language like Rust, Go, or Java instead of C/C++

And turn on the compiler-level protections wherever the code does stay in C/C++:

-fstack-protector-all
-D_FORTIFY_SOURCE=2
-pie
-z relro -z now

None of these make unsafe code safe on their own — they raise the bar for exploitation while the real fix is bounds-checked input handling.

Go Deeper

This covers the mechanics of memory layout, exploitation steps, and mitigations. The full lesson is free: Buffer Overflows.

AI Governance 101: What ML Practitioners Actually Need to Know

Sakramen — Thu, 13 Aug 2026 16:48:08 +0000

AI regulation isn't abstract policy anymore. If you're building systems that touch hiring, credit, healthcare, or law enforcement, there are now legal requirements attached to your model's behavior — and the penalties are real. Here's what actually matters for practitioners, without the fluff.

The EU AI Act: risk tiers, not blanket rules

Adopted in 2024, the EU AI Act is the first comprehensive AI law, and it works by classifying systems into four risk tiers:

Unacceptable risk — banned outright. Government social scoring, real-time biometric ID in public spaces (with narrow exceptions), manipulative AI targeting vulnerable people.
High risk — hiring, credit scoring, healthcare diagnostics, law enforcement, critical infrastructure, education. These require a conformity assessment, a documented risk management system, data governance controls, transparency, human oversight, and accuracy/robustness testing.
Limited risk — chatbots, emotion recognition, deepfake generators. The obligation here is simpler: tell users they're interacting with AI.
Minimal risk — spam filters, game AI, most recommendation systems. No specific legal requirements, though voluntary codes are encouraged.

The part that should get your attention: non-compliance for high-risk systems can cost up to €35 million or 7% of global annual turnover, whichever is higher. That's not a slap on the wrist — it's a board-level risk.

High-risk systems also need ongoing post-market monitoring and registration in an EU database, not just a one-time sign-off before launch.

NIST AI RMF: voluntary, but increasingly load-bearing

The US hasn't passed anything like the AI Act. Instead, NIST published the AI Risk Management Framework (AI RMF) — voluntary, not law, but referenced in federal procurement and rapidly becoming the de facto standard for US organizations doing this work seriously.

It has four core functions, and they map cleanly onto the ML lifecycle:

Govern — set policies, define who owns AI risk, build accountability structures before you build anything else.
Map — understand context: intended use, stakeholders, likely harms, deployment environment.
Measure — test for bias, evaluate robustness, check performance across subpopulations, using both quantitative and qualitative methods.
Manage — prioritize the risks you found, implement mitigations, monitor in production, keep an incident response plan ready.

If you're not sure where to start with governance internally, this four-function structure is a reasonable skeleton even outside the US.

Sector rules stack on top of horizontal law

Horizontal AI legislation isn't the whole picture. Specific sectors have their own layered requirements:

Healthcare: the FDA regulates AI/ML-based Software as a Medical Device, and has proposed rules for continuously-learning models that keep adapting post-deployment — these need a predetermined change control plan, not a one-time approval.
Finance: the Federal Reserve and OCC require explainability for AI-driven credit decisions under the Equal Credit Opportunity Act. The SEC has proposed rules targeting AI-driven investment advisors.
Employment: NYC's Local Law 144 requires bias audits for automated employment decision tools, with results published publicly — not just kept in an internal report.
Autonomous vehicles: NHTSA requires manufacturers to report crashes involving automated driving systems.

If your model touches any of these domains, the horizontal AI law is the floor, not the ceiling.

Corporate frameworks fill the gaps

Google, Microsoft, and IBM all publish their own responsible AI frameworks. They're voluntary, but they matter in practice — they shape hiring expectations, client requirements, and often preview where regulation is headed. IBM's approach is notable structurally: it runs a centralized AI ethics board with actual authority to halt projects that don't meet its standards, which is a governance pattern worth borrowing even at smaller scale.

Different regions, different philosophies

EU: prescriptive, risk-based, legally binding.
US: sector-specific, voluntary-framework-heavy, optimized for innovation speed.
China: comprehensive rules specifically targeting algorithmic recommendation, deepfakes, and generative AI, with content moderation and transparency requirements.
UK: pro-innovation, delegates oversight to existing sector regulators rather than creating a new AI-specific body.
Canada: AIDA creates requirements for high-impact systems and a dedicated AI and Data Commissioner role.

If you ship globally, you're effectively subject to the strictest applicable regime for each market you touch.

What this means for your actual pipeline

Compliance isn't a document you write after the model ships. In practice it means:

Documenting training data, architecture decisions, and evaluation results as you go
Building monitoring that catches performance degradation and bias drift in production, not just accuracy drops
Defining accountability explicitly — who is responsible when the model causes harm
Having an incident response procedure ready before you need it
Keeping audit trails a regulator (or auditor) could actually review

Treating this as an afterthought is the expensive path. Embedding it into the ML lifecycle from day one is cheaper and, frankly, just better engineering practice.

Meeting Latency Budgets in Real-Time Vision Systems

Sakramen — Tue, 11 Aug 2026 16:50:50 +0000

Autonomous vehicles need to process frames in 50-100ms to react to obstacles. Augmented reality needs 16ms frame times to hit 60fps without feeling laggy. Industrial inspection has to keep pace with a moving line. These are hard latency budgets, and hitting them consistently takes engineering across the whole pipeline, not just a fast model.

Latency Is Not Just Inference Time

End-to-end latency in a vision system breaks down into several stages, each with its own typical range and its own optimization lever:

Stage	Typical Latency	Optimization Lever
Image capture	1-33ms (depends on fps)	Camera selection, exposure settings
Data transfer	1-10ms	DMA, zero-copy buffers, GPU-direct capture
Preprocessing	2-10ms	GPU-accelerated resize, on-device normalization
Model inference	5-100ms	Model optimization, quantization, hardware selection
Post-processing	1-10ms	NMS optimization, result filtering
Action/response	1-5ms	Direct hardware control, efficient IPC

A team that spends all its optimization budget on the model while capture and transfer stay untouched is optimizing the wrong variable. A holistic view of the pipeline is what actually gets you under budget.

Batching: Throughput vs Latency

GPUs are massively parallel and sit underutilized when fed one image at a time. Batching fixes utilization but costs latency, so the strategy matters:

Static batching: wait to collect a fixed number of requests before running inference. Simple, but adds wait time equal to however long it takes to fill the batch.
Dynamic batching: process whatever requests arrived within a short time window (e.g., 5ms). This is what Triton Inference Server and TorchServe support natively, and it balances throughput against latency better than static batching.
Micro-batching: for streaming video from multiple cameras, batch frames across streams rather than across time from a single stream.

The right batch size is a function of your latency budget. If you have 100ms to work with and inference takes 30ms per image, a batch of 2-3 might be the sweet spot — bigger batches raise throughput but blow past the target.

Asynchronous Pipelines

Running every stage sequentially means your total latency is the sum of every stage's latency. Decoupling the stages so they run concurrently on different hardware changes that:

# Conceptual async pipeline
while running:
 # These run concurrently on different hardware
 future_frame = camera.capture_async() # Camera sensor
 future_preprocess = preprocess_async(frame) # CPU
 future_inference = model.infer_async(batch) # GPU
 future_postprocess = postprocess(results) # CPU

 # Pipeline: while GPU processes frame N,
 # CPU preprocesses frame N+1,
 # and camera captures frame N+2

With this pipeline parallelism, no piece of hardware sits idle waiting on another. The camera captures frame N+2 while the CPU preprocesses N+1 and the GPU infers on N. Throughput ends up bound by the slowest stage in the pipeline, not the sum of all of them.

Streaming Video Has Its Own Rules

Continuous streams introduce failure modes that don't show up when you're just benchmarking single images:

Frame skipping: if inference takes longer than the frame interval, don't let a queue build up. Drop stale frames and process the most recent one instead of working through a growing backlog.
Temporal redundancy exploitation: run full inference on keyframes and cheaper updates on the frames in between. If the scene hasn't changed much, reuse the previous result instead of recomputing from scratch.
Region-of-interest processing: run a lightweight detector across the full frame first, then reserve the expensive model for the regions that actually matter.
Multi-resolution strategies: detect at low resolution, then crop and process only the interesting regions at full resolution.

Hardware Options for Edge Deployment

The right hardware depends on your power, cost, and flexibility constraints:

NVIDIA Jetson (Orin, Xavier): 10-275 TOPS, the standard for edge AI in robotics and autonomous vehicles.
Google Coral (Edge TPU): 4 TOPS for TFLite models at 2W, well suited to always-on vision devices.
Intel Movidius (VPU): neural compute sticks common in smart cameras and drones.
Apple Neural Engine: 15.8 TOPS on M1, up to 38 TOPS on M3 Max, accessed through CoreML.
Custom ASICs: maximum efficiency for a fixed model architecture, at the cost of zero flexibility if requirements change.

Benchmarking Pitfalls

Always profile on the actual target hardware, not a dev workstation. Three things reliably distort results:

Cold start overhead: the first inference is slower because of memory allocation and kernel compilation. Warm up the model before you start timing.
Memory contention: other processes competing for GPU or CPU memory can introduce latency spikes that don't show up in isolated tests.
Thermal throttling: embedded devices can show degraded performance after several minutes of sustained load, so short benchmarks can be misleadingly optimistic.

Closing

Meeting a real-time latency budget is a systems problem, not a model problem. The camera, the transfer path, the batching strategy, the pipeline concurrency, and the hardware all contribute, and any one of them can become the bottleneck if ignored.

This is a condensed version of the full lesson, which goes into more depth on each of these topics: Real-Time Vision Systems, free on NeutralBlock.

How Two-Stage Object Detectors Went From 47 Seconds to Real-Time-Adjacent

Sakramen — Mon, 10 Aug 2026 16:45:06 +0000

Object detection has two broad architectural families: one-stage detectors that predict boxes and classes directly in a single pass, and two-stage detectors that first propose candidate regions, then classify and refine them. Two-stage detectors were the dominant approach from 2014 to 2017 and are still the most accurate choice on many benchmarks when latency isn't the constraint.

The interesting part isn't just that two-stage detectors work — it's how each generation solved a specific, identifiable bottleneck in the previous one. Here's the sequence.

R-CNN (2014): Prove CNN Features Work

R-CNN (Girshick et al.) was the first detector to apply deep learning effectively to the detection problem. Its pipeline had three independent stages:

Selective Search — a traditional segmentation-based algorithm generates ~2,000 region proposals per image.
CNN feature extraction — each proposal is resized to 227x227 and run through AlexNet to get a feature vector.
Classification — an SVM is trained per class on those features, plus a separate bounding box regressor to tighten the boxes.

This improved detection accuracy by 30% over prior hand-crafted-feature methods (like HOG) on PASCAL VOC, which was a genuinely big deal — it proved CNN features generalize to detection, not just classification.

The cost: running the CNN forward pass 2,000 times per image, once per proposal. That's about 47 seconds per image. Fine for a paper, useless for a product.

Fast R-CNN (2015): Stop Recomputing Features

The fix here is almost obvious in retrospect: don't run the CNN once per proposal. Run it once on the whole image, and extract each proposal's features from the resulting shared feature map.

The mechanism that makes this possible is RoI Pooling. Since proposals come in arbitrary sizes but downstream fully-connected layers need a fixed-size input, RoI Pooling divides each proposal's region of the feature map into a fixed grid — say 7x7 — and max-pools within each cell. Regardless of how big or small the original proposal was, you get a fixed-length vector out.

feature_map -> RoI Pooling(proposal_region, output_size=7x7) -> fixed_vector -> FC layers -> class + box offsets

This single change made Fast R-CNN 213x faster than R-CNN at test time, and it could be trained end-to-end instead of as three disconnected stages. But Selective Search — a non-learned, CPU-bound algorithm — was still sitting in the pipeline, costing about 2 seconds per image and capping how fast the whole system could go.

Faster R-CNN (2015): Replace the Last Non-Learned Component

Faster R-CNN's contribution is the Region Proposal Network (RPN): a small neural network that shares the backbone's feature map and generates proposals directly, replacing Selective Search entirely.

The RPN works like this: a 3x3 convolution slides over the feature map, feeding two parallel 1x1 convolutions — one producing objectness scores (2k values), one producing box offsets (4k values). At each spatial location, it evaluates k anchor boxes of different scales and aspect ratios (typically k=9: three scales x three ratios), predicting whether each anchor contains an object and how to adjust its coordinates.

Training uses a multi-task loss:

L = L_cls(objectness) + lambda * L_reg(box_offsets)

Anchors are labeled positive if they have IoU > 0.7 with any ground truth box, and negative if IoU < 0.3 with all ground truth boxes. This threshold strategy yields hundreds of high-quality proposals in a single forward pass, no external algorithm required.

The result: a single, fully end-to-end trainable network running at roughly 5 FPS. Not real-time, but orders of magnitude faster than R-CNN's 47 seconds per image, while matching state-of-the-art accuracy.

Where This Goes Next

The two-stage idea didn't stop at Faster R-CNN. Cascade R-CNN extends the pattern to three sequential stages, each trained with a progressively stricter IoU threshold, so detections get refined more precisely at each step.

The underlying tradeoff hasn't changed: two-stage detectors spend more compute deciding where to look before classifying, which costs speed but tends to pay off in accuracy. For applications where real-time inference isn't required and precision matters — medical imaging, satellite imagery, quality inspection — this family of architectures is still a reasonable default.

Nodes and Networks: How Blockchains Actually Stay Decentralized

Sakramen — Mon, 10 Aug 2026 06:25:43 +0000

When someone says "Bitcoin has over 15,000 nodes worldwide," they mean 15,000+ independent computers are each running Bitcoin software and each maintaining their own full copy of the blockchain. No server owns the truth. Every node checks it for itself.

That single fact — every node independently verifies every transaction and block against protocol rules — is the reason blockchains don't need a central authority. If one node tries to cheat, the rest simply ignore it. There's no admin account to compromise because there's no admin.

Not All Nodes Do the Same Job

Full Node

Downloads and stores the entire blockchain, every block since genesis, and independently validates everything against consensus rules.

Highest security
~500 GB for Bitcoin
~1 TB for Ethereum

This is the backbone of network security. A full node doesn't trust anyone's summary of the chain; it recomputes validity itself.

Light Node (SPV)

Stores only block headers, not full transaction data. Uses Merkle proofs and relies on full nodes to verify transactions.

Low storage, ~50 MB
Trusts full nodes for verification
What most mobile wallets run

Mining/Validator Node

A full node that also participates in block creation. Miners (Proof of Work) solve computational puzzles; validators (Proof of Stake) stake cryptocurrency as collateral. Both earn rewards for securing the network.

Creates new blocks
Earns rewards
Requires specialized hardware (PoW) or capital at stake (PoS)

Archive Node

Everything a full node stores, plus historical state at every block height.

Complete history
~15+ TB for Ethereum
Used by explorers, analytics platforms, and enterprise tooling

Why Peer-to-Peer Instead of Client-Server

A traditional web service is client-server: your browser requests data from a company's servers. If those servers go down, the service is unavailable. That's a single point of failure by design.

Blockchain networks use peer-to-peer (P2P) architecture instead. Every participant is simultaneously a client and a server. Nodes connect directly to each other, typically maintaining 8-20 peer connections, and information spreads through the network like gossip: each node tells its peers, who tell their peers, until everyone has it.

How a Transaction Actually Propagates

You submit a transaction from your wallet. It goes to whichever node your wallet is connected to.
That node validates it: correct format, valid signature, sufficient balance. Invalid transactions get rejected right there.
If valid, the node broadcasts it to its 8-20 connected peers.
Each peer independently validates and rebroadcasts to its own peers. The transaction spreads exponentially.
Within seconds, the transaction has reached nodes worldwide and is sitting in mempools, waiting to be included in a block.

No central router coordinates this. It's just repeated local validation and rebroadcast, scaled across thousands of independent machines.

Why This Architecture Is Hard to Kill

Geographic distribution: nodes run on every continent, so a regional outage or disaster can't take the network down.
No single point of failure: even if 90% of nodes went offline, the remaining 10% could keep the network operating.
Censorship resistance: no central authority can block a transaction. If one node refuses to process it, thousands of others will.
Self-healing: nodes that go offline can rejoin later and automatically sync the blocks they missed from peers.

What It Takes to Run One Yourself

Requirement	Bitcoin Full Node	Ethereum Full Node
Storage	500+ GB SSD	1+ TB NVMe SSD
RAM	2+ GB	16+ GB
Internet	Unmetered, 50+ Mbps	Unmetered, 100+ Mbps
Initial Sync Time	1-7 days	2-14 days

Running your own full node gets you a few concrete things: your transactions aren't routed through someone else's infrastructure, you're verifying against your own copy of the rules instead of trusting a third party's node, and you're adding to the pool of validators that makes the network harder to disrupt.

Closing

The short version: nodes are computers running blockchain software, each holding a copy of the ledger. Full nodes validate everything independently; light nodes lean on full nodes for verification through Merkle proofs. There's no central server, connections are peer-to-peer, and data spreads by gossip. That combination is what makes these networks resilient and hard to censor.

Full lesson, free: https://neutralblock.com/learn/fundamentals/blockchain-fundamentals/nodes-and-networks

Purple Teaming: Closing the Loop Between Attack and Detection

Sakramen — Sun, 09 Aug 2026 16:25:35 +0000

The Problem With Traditional Red Team Reports

A standard red team engagement works like this: the offensive team operates covertly, tries to achieve objectives without being caught, and delivers a report at the end summarizing what worked. The blue team reads it, maybe weeks or months later, and has to reverse-engineer exactly which detection failed and why.

Meanwhile blue teams often write detection rules in isolation, without ever confirming those rules actually fire against a real execution of the technique they're meant to catch. Two teams, two blind spots, no feedback loop.

Purple teaming is the fix: red and blue work together, in real time, so that every attack execution is immediately paired with a detection check.

A Concrete Example: DCSync

Say the red team executes a DCSync attack against Active Directory, which abuses domain replication to pull password hashes.

In a traditional engagement, the report just says "DCSync was successful." In a purple team exercise, the blue team is watching the SIEM, EDR, and domain controller logs while the attack runs. If nothing alerts, both teams stop and figure out why immediately. Two common causes:

The SIEM has no rule for DsGetNCChanges replication requests originating from a non-domain-controller host.
The relevant Windows event (Event ID 4662) isn't even being collected.

The blue team writes and deploys the detection rule on the spot. The red team re-executes the exact same attack to confirm the new rule fires with an alert an analyst could actually act on. That's the whole point: verified, not assumed.

MITRE ATT&CK as the Shared Language

Purple teaming needs a common vocabulary so both teams are testing and measuring the same thing. MITRE ATT&CK provides that: a catalog of adversary techniques organized under tactical objectives like initial access, execution, persistence, privilege escalation, defense evasion, credential access, discovery, lateral movement, collection, exfiltration, and command and control.

Teams use ATT&CK to pick which techniques to test in a given session, track what's covered across the matrix over time, and prioritize based on techniques known to be used by threat actors relevant to their industry.

Exercise Structure

A purple team exercise generally follows six steps:

Scope and prioritize — pick ATT&CK techniques based on threat intel for your industry. You can't test everything in one sitting.
Baseline detection — document what rules, log sources, and response procedures already exist for each chosen technique, before anything is executed.
Execute and observe — red runs each technique while blue watches every detection layer: SIEM, EDR, NDR, firewall logs. Both sides document what happened.
Analyze gaps — for each technique, determine if it was detected, at which layer, how long it took, and whether the alert gave an analyst enough context to investigate.
Remediate and retest — build or tune detections for the gaps found, then re-run the attack to confirm the fix works with acceptable fidelity.
Document and track — log everything in an ATT&CK coverage heatmap. This becomes an ongoing detection maturity scorecard.

Atomic Red Team

Atomic Red Team is an open-source library of small, focused test scripts, each mapped to a specific ATT&CK technique. An "atomic test" does one thing: dump LSASS memory, create a scheduled task for persistence, run DNS tunneling, and so on.

They're designed to be safe to run in production with proper authorization, which makes them the practical building blocks of a purple team exercise. Instead of designing a custom attack script for every technique, teams pull an atomic test off the shelf and work through the ATT&CK matrix systematically.

Metrics That Matter

Metric	Description	Target
Detection Coverage	% of tested ATT&CK techniques with working detections	Increase each quarter
Mean Time to Detect	Average time from attack execution to alert generation	Under 5 minutes for priority techniques
Alert Fidelity	True positive vs. false positive ratio per rule	Above 80% true positive rate
Response Completeness	Whether runbooks cover all investigation/containment steps	Full coverage for top 50 techniques

These give you something a narrative pentest report doesn't: a trackable scorecard of detection maturity over time, not just a snapshot of what one red team happened to bypass on one particular day.

Why It's Worth Adopting

Purple teaming turns security testing from a periodic, adversarial exercise into an ongoing, collaborative one. Instead of finding out three months later that a technique slipped through, you find out immediately, fix it immediately, and verify the fix immediately.

The full lesson, with the complete exercise framework and metrics breakdown, is free here: Purple Teaming

DEV Community: Sakramen

Feature Matching: From Brute Force to a Robust Pipeline

Why Feature Matching Matters

Brute-Force Matching

FLANN: Approximate Nearest Neighbors

Lowe's Ratio Test

RANSAC for Outlier Rejection

The Full Pipeline

Learn More

How Buffer Overflows Actually Hijack Program Execution

Why the Stack Matters

The Vulnerable Pattern

How the Exploit Actually Works

The Defenses That Exist Now

Heap Overflows Are a Different Beast

Fixing It at the Source

Go Deeper

AI Governance 101: What ML Practitioners Actually Need to Know

The EU AI Act: risk tiers, not blanket rules

NIST AI RMF: voluntary, but increasingly load-bearing

Sector rules stack on top of horizontal law

Corporate frameworks fill the gaps

Different regions, different philosophies

What this means for your actual pipeline

Further reading

Meeting Latency Budgets in Real-Time Vision Systems

Latency Is Not Just Inference Time

Batching: Throughput vs Latency

Asynchronous Pipelines

Streaming Video Has Its Own Rules

Hardware Options for Edge Deployment

Benchmarking Pitfalls

Closing

How Two-Stage Object Detectors Went From 47 Seconds to Real-Time-Adjacent

R-CNN (2014): Prove CNN Features Work

Fast R-CNN (2015): Stop Recomputing Features

Faster R-CNN (2015): Replace the Last Non-Learned Component

Where This Goes Next

Further Reading

Nodes and Networks: How Blockchains Actually Stay Decentralized

Not All Nodes Do the Same Job

Full Node

Light Node (SPV)

Mining/Validator Node

Archive Node

Why Peer-to-Peer Instead of Client-Server

How a Transaction Actually Propagates

Why This Architecture Is Hard to Kill

What It Takes to Run One Yourself

Closing

Purple Teaming: Closing the Loop Between Attack and Detection

The Problem With Traditional Red Team Reports

A Concrete Example: DCSync

MITRE ATT&CK as the Shared Language

Exercise Structure

Atomic Red Team

Metrics That Matter

Why It's Worth Adopting