Imagine a busy factory that checks each product before it leaves the door. MDASH, the name Microsoft uses for this code-checking system, works in a similar way. Code, which means the written instructions that tell software what to do, goes in. A short list of likely real problems comes out. The goal is not to flood people with guesses. The goal is to give security teams a small set of findings they can understand, trust, and fix.

The simple idea: an assembly line for finding bugs

Think of a car inspection line. One station checks the brakes. Another checks the lights. Another checks whether the engine runs safely. No single station does everything, but together they give a clear answer.

Microsoft describes MDASH as a pipeline, which means a set of steps where the output of one step becomes the input for the next step. In this case, the input is a codebase, which means all the code for a software project. The output is a short list of security findings, which means reports about problems that may let someone misuse the software.

A bug is a mistake in software. A vulnerability is a bug that could create a security risk, such as letting the wrong person see data or make the program crash. MDASH is built to look for these higher-risk bugs, then explain why they matter.

📌
Plain version. MDASH is not just one quick artificial intelligence check; it is a staged investigation.
MDASH runs five stages that turn a codebase into a short list of findings. The Pipeline Prepare Scan Validate Dedupe Prove
MDASH runs five stages that turn a codebase into a short list of findings.

Stage 1: Prepare, like drawing a map before a search

Before a detective knocks on doors, they learn the streets. They ask: where are the entrances, where are the shortcuts, and which places have had trouble before?

MDASH starts the same way. In the Prepare stage, it reads through the codebase and builds a map of the software. It looks at what the main pieces are, how those pieces connect, and where outside information enters the program.

Outside information is data that comes from somewhere the program does not fully control, such as a web request from the internet. Security people often call this untrusted input, which means information that should not be accepted as safe until it has been checked.

MDASH also studies the project’s history of past changes. This helps it understand the terrain. Some parts of a project change often. Some parts handle risky data. Some parts connect to many other parts. The map helps MDASH choose where to look most closely.

Prepare builds a map of the code before any hunting begins. Prepare Stage Preparebuild a map Main piecesand links Input entersuntrusted Past changeshistory
Prepare builds a map of the code before any hunting begins.

Stage 2: Scan, like sending specialists to look for suspects

Now picture several trained inspectors walking through the same building. One knows electrical problems. One knows plumbing. One knows fire exits. Each person looks for the kind of trouble they understand best.

In the Scan stage, MDASH uses specialist auditor agents. An agent is a software helper that is given a task. An auditor agent is a helper that inspects code for possible problems.

These agents look at promising parts of the code and create candidate findings. A candidate finding is a possible bug report that still needs to be checked. Each one includes the reason the agent thinks the problem may be real, plus the clues it found in the code.

This stage is important because it casts a wide net. But the word candidate matters. At this point, MDASH has leads, not final answers.

⚠️
A lead is not proof. The Scan stage finds possible problems, but later stages decide which ones deserve trust.

Stage 3: Validate, like putting each suspect on trial

A fair courtroom does not accept one side of a story. One side argues that the suspect is guilty. The other side challenges the evidence. The judge listens for what holds up.

MDASH uses a similar debate in the Validate stage. For each candidate bug, one group of agents argues that the bug is real. It tries to show that an attacker, which means a person or system trying to misuse software, could reach the weak spot and abuse it.

Another group argues the opposite. It looks for reasons the bug may not be reachable, may not matter, or may be blocked by other code. This back-and-forth helps remove false positives. A false positive is an alarm that looks like a real problem but is not actually one.

This is one of the key ideas behind MDASH. It does not treat every first guess as true. It makes the finding survive a challenge before it moves forward.

✅
Why this helps. A challenged finding is usually more useful than an unchecked guess.
Validate is a debate where evidence decides if a candidate is real. The Debate For the bugit is real Againstit is safe Can reach it Blocked by code Real problem False alarm
Validate is a debate where evidence decides if a candidate is real.

Stage 4: Dedupe, like realizing five witness reports describe one event

Imagine five people report a loud bang. One says it came from the alley. One says it broke a window. One says a car alarm followed. These may sound like separate events, but they could all describe the same accident.

The same thing can happen in code review. Different agents may find the same underlying flaw from different angles. One report may focus on where risky data enters. Another may focus on where the program fails later.

Dedupe is short for de-duplicate, which means to remove repeated copies of the same thing. In this stage, MDASH tries to recognize when several reports are really one problem. It then combines them into a single, clearer item.

This matters for the people who must fix the code. If the same bug is reported five ways, the team may waste time sorting the pile instead of solving the problem. Dedupe helps turn noise into a cleaner work list.

Stage 5: Prove, like showing the lock really opens

A locksmith can say a lock looks weak. That is useful. But it is stronger evidence if the locksmith can show, safely and with permission, that the lock opens with a certain key.

For some kinds of bugs, MDASH tries to do something similar. Where it can, it builds an actual input that triggers the flaw. An input is information given to a program, such as text in a form or data sent over a network.

If the input makes the bug happen, MDASH has a live demonstration that the vulnerability is genuine. That kind of evidence is stronger than a theory because it shows the problem can occur in practice.

Not every bug can be automatically proven this way. Some need human judgment. When MDASH cannot prove a bug by making it happen, the finding may still be reported as a lead for a person to check.

📌
Some proof is manual. If MDASH cannot safely prove a finding by itself, a human reviewer may still need to decide.

What comes out, and the decisions people must make

At the end of the assembly line, the team does not want a mountain of maybes. It wants a smaller set of high-confidence findings. High-confidence means the evidence is strong enough that the finding is more likely to be real and worth attention.

Each finding includes supporting evidence and guidance written for people. Guidance means practical advice about what to fix or where to look next.

Microsoft delivers the results in two forms. One is a machine-readable file, which means a file that other software tools can process. The standard format is called Static Analysis Results Interchange Format (SARIF). Static analysis means checking code without running the whole program, and results interchange format means a shared way to exchange the findings between tools.

The other form is a friendly report for security teams to review in the Microsoft Defender portal. A portal is a web page or app where people sign in to manage information and take action.

This is where real decisions begin. A leader or practitioner must decide which findings to fix first, who owns each fix, how fast the work should happen, and when a human review is needed. MDASH can improve the quality of the list, but people still decide how to act on it.

  • Fix proven, high-risk findings before weaker leads when time is tight.
  • Assign each finding to a team that knows that part of the code.
  • Use the SARIF file when other tools need to read or track the results.
  • Use the human-readable report when people need to understand and plan the fix.
  • Keep human review for findings that are important but not automatically proven.
Each stage narrows a pile of maybes into high-confidence findings. Fewer, Stronger Many maybes Validated Deduped High-confidence
Each stage narrows a pile of maybes into high-confidence findings.

The main lesson

It is tempting to describe systems like MDASH as simply asking artificial intelligence (AI) to look at code. Artificial intelligence means software that can perform tasks that usually require human thinking, such as reading, comparing, and reasoning over patterns.

That simple description misses the most important point. MDASH is organized as a disciplined process: prepare the map, scan for leads, validate the claims, dedupe repeated reports, and prove what can be proven.

The value is not magic. The value is structure. Each stage reduces confusion. Each stage adds context. The final result is meant to be a shorter, clearer, better-supported list of bugs for humans to review and fix.

Key takeaways

  • MDASH is a staged pipeline for finding security bugs in code.
  • It first maps the codebase so it knows where risky areas and outside data may be.
  • Specialist agents create candidate findings, but those are only leads at first.
  • Validation uses a built-in debate to reduce false positives.
  • Dedupe combines repeated reports so teams do not fix the same bug several times.
  • When possible, MDASH proves a bug by triggering it with a real input.

Glossary

MDASH
The name Microsoft uses for a system that investigates code and reports likely security bugs.
Code
Written instructions that tell software what to do.
Codebase
All the code that belongs to one software project.
Bug
A mistake in software that can make it behave in the wrong way.
Vulnerability
A bug that could create a security risk.
Pipeline
A set of steps where each step passes its result to the next step.
False positive
An alarm that looks like a real problem but is not actually one.
Dedupe
Short for de-duplicate, meaning to combine or remove repeated copies of the same thing.
Static Analysis Results Interchange Format (SARIF)
A standard file format that lets software tools share code-checking results.