Security scanners are most useful when they help people decide what to do next. Codename MDASH is designed around that idea: it does not simply report possible code weaknesses, it grades how believable they are, sorts them into practical work queues, and gives developers code-level guidance while keeping the final decision in human hands.

Confidence is not the same as severity

Codename MDASH uses artificial intelligence (AI) to inspect code and report likely security weaknesses. Each finding carries two different judgments: how bad the issue would be if it is real, and how confident the scanner is that the issue is real. Keeping those judgments separate is important. A severe issue with weak evidence deserves review; a lower-severity issue with strong evidence may still be safe to defer.

MDASH uses a 10-level confidence hierarchy that runs from UNLIKELY to PROVEN. In the Microsoft Defender portal, that detailed hierarchy is shown in broader bands such as Likely, Suspect, and Unlikely, which are easier to scan in a work queue. Each finding also receives a severity of Critical, High, Medium, or Low, and is tagged with a Common Weakness Enumeration (CWE) identifier, such as CWE-89 for SQL injection.

📌
Two questions. Confidence asks whether the scanner is probably right; severity asks how much the issue matters if it is right.
Confidence is how sure the scanner is; severity is how bad the issue would be if real. Confidence vs Severity Confidencehow sure Severityhow bad Is it real? How bad if real Unlikely to proven Critical to low
Confidence is how sure the scanner is; severity is how bad the issue would be if real.

The three triage buckets

MDASH collapses the confidence and severity signals into three triage buckets. This is the layer that turns scanner output into work. The first bucket is Validated by AI scanner: the system has high confidence that the finding is real and that its severity is high enough to matter. These are the findings to fix now or assign to an owner.

The second bucket is Flagged for review. These are high-severity findings that the AI scanner could not fully validate by itself. They should not be ignored, but they also should not be treated as proven without human investigation. The third bucket is Low priority, which contains Low and Medium severity findings regardless of confidence. These findings are usually suitable for deferral, muting, or background cleanup.

  1. Validated by AI scanner: act first because the scanner believes the issue is real and important.
  2. Flagged for review: investigate because the potential impact is high but the evidence is incomplete.
  3. Low priority: defer, mute, or batch because the severity is Low or Medium.
Confidence and severity collapse into three buckets that turn output into work. Triage Buckets Validatedfix now Flagged for reviewneeds human Low prioritydefer later
Confidence and severity collapse into three buckets that turn output into work.

Sorting is a policy decision made visible

The Defender portal’s default order is meant to put the most actionable work at the top. It sorts first by triage bucket, with Validated by AI scanner before Flagged for review before Low priority. Inside each bucket, it sorts by severity from Critical to High to Medium to Low. Inside the same severity, it sorts by confidence, with Likely before Suspect before Unlikely.

That ordering matters because it encodes a practical security policy. It says that validated high-impact findings should outrank uncertain ones, and that lower-severity findings should not crowd out work that could reduce material risk. Teams can still filter and export results, but the default view nudges them toward a sensible first pass.

The default view sorts by bucket, then severity, then confidence. Sort Order By bucketmost actionable By severitycritical first By confidencelikely first
The default view sorts by bucket, then severity, then confidence.

Where results live

MDASH findings are published to Microsoft Security Exposure Management (MSEM) in Microsoft Defender XDR, under the Codename MDASH - Agentic code scanner initiative. Microsoft Defender XDR is Microsoft’s extended detection and response portal. The MDASH initiative page is purpose-built for AI scanner findings and does not show findings from non-AI scanners.

Results can arrive from two places. One path is the Defender command-line interface (CLI), which lets a user run scans from a local or automated environment. The other path is a remote scan started from the portal through a connector. Remote results are labeled so teams can distinguish them from CLI-originated results. The page reflects results from the last 90 days.

The dashboard gives several views of the same risk picture: an agentic code security score shown as a 0 to 100 percent donut, a 14-day score trend, a feed of recent scans across repositories and branches, hotspots by repository, file, and weakness type, and detailed recommendation lists. The score is severity-weighted, so more serious findings pull it down more. Its scope is default branches. MDASH findings currently affect only the MDASH-specific risk score in the initiative; they do not affect the tenant’s secure score or general risk score.

⚠️
Scope matters. The MDASH score is useful for this initiative, but it does not change the tenant secure score or the tenant risk score.

What reviewers see in a scan

The initiative dashboard is not just a summary page. The latest AI code scans view provides a chronological feed across repositories and branches, with a colored bar that breaks recommendations into the three triage buckets. It also offers a one-click comma-separated values (CSV) export of findings in the Validated by AI scanner bucket.

The Scans tab shows scan-level operational details, including status, repository, branch, trigger source, tokens consumed, start time, duration, per-severity stacked bars, per-triage stacked bars, and a run identifier such as run_d73220eb. The Security recommendations tab is where teams filter, review, and export individual findings. Together, these views support both operational follow-up and higher-level risk analysis.

  • Use the scan feed to understand what ran recently and where.
  • Use hotspot views to find repositories, files, or weakness classes that repeat.
  • Use the Scans tab to troubleshoot scan behavior and compare scan runs.
  • Use the Security recommendations tab to work individual findings and export review data.

Remediation stays developer-controlled

MDASH outputs findings in Static Analysis Results Interchange Format (SARIF), a machine-readable format used by security tools. SARIF output can be ingested by GitHub Advanced Security, Azure DevOps, and other compatible tooling. MDASH also provides a richer HyperText Markup Language (HTML) view with human-readable remediation guidance for each finding, and those findings can be reviewed in the Defender portal.

The remediation guidance is code-level rather than architectural. MDASH can help point to a vulnerable function or pattern and suggest how code might be patched, but it does not redesign systems, propose alternative architectures, or choose among broader remediation strategies. It can group related findings so a developer may address them in one fix.

MDASH is read-only. It discovers vulnerabilities and produces guidance, but it does not modify the environment, apply fixes, open pull requests, or push remediations on its own. The Defender CLI includes a defender fix option that can generate a suggested function-level fix on a new branch for developer review. That autofix workflow uses SARIF findings, the GitHub Copilot CLI, and a completed MDASH scan. It is a separate developer-initiated flow, not a Foundry flow. Any proposed change should be reviewed, validated, and approved by developers before it is merged.

✅
Read-only by design. MDASH does not change code or infrastructure unless a developer starts a separate fix workflow and approves the result.
MDASH discovers and guides but never changes your environment. Read-Only Output Read-onlyno auto-fix SARIF exporttooling HTML guidancehuman-readable Groups fixesone change Code-levelnot architecture
MDASH discovers and guides but never changes your environment.

The decision for leaders and practitioners

The practical question is not whether MDASH found every possible issue. It is how the organization will use its ranked evidence. A security leader may decide that Validated by AI scanner findings above a severity threshold require a service-level objective, while Flagged for review items need a human triage queue. A development lead may decide that Low priority findings are batched into planned maintenance unless they affect sensitive code.

For continuous integration and continuous delivery, often shortened to CI/CD, MDASH can run in pipelines. Teams can scan locally with the Defender CLI using interactive login, or use a Microsoft Entra app registration with a client secret for non-interactive authentication. The SARIF output works with GitHub Advanced Security and Azure DevOps.

MDASH scans can be long-running, and AI-based analysis is non-deterministic, meaning two runs may not behave exactly like a fast compiler check. For that reason, CI/CD integration is usually better suited to asynchronous security review than to deterministic build-blocking gates. In practice, this means treating MDASH as a strong risk-discovery and prioritization signal, not as the only pass-fail rule for shipping software.

📌
Leadership choice. The main operating decision is how fast each bucket must be reviewed, assigned, fixed, or deliberately deferred.

Key takeaways

  • MDASH separates confidence from severity so teams can judge both evidence and impact.
  • Every finding lands in one of three triage buckets: Validated by AI scanner, Flagged for review, or Low priority.
  • The Defender portal centralizes the last 90 days of MDASH AI scanner results and shows a severity-weighted MDASH-specific score.
  • Findings are available as SARIF for tooling and as human-readable guidance for review in the portal.
  • MDASH is read-only; any suggested fix is developer-initiated, reviewed, validated, and approved before merge.
  • CI/CD use is best treated as asynchronous security review rather than a deterministic build-blocking gate.

Glossary

Artificial intelligence
Artificial intelligence is software that performs tasks, such as analysis or classification, that normally require human judgment.
Common Weakness Enumeration
Common Weakness Enumeration is a standard catalog of software and hardware weakness types, often referenced by identifiers such as CWE-89.
Microsoft Security Exposure Management
Microsoft Security Exposure Management is the Microsoft Defender area that helps organizations view and manage security exposure across assets and findings.
Microsoft Defender XDR
Microsoft Defender XDR is Microsoft’s extended detection and response portal for investigating and managing security signals.
Command-line interface
A command-line interface is a text-based way to run software commands, often used by developers and automation systems.
Static Analysis Results Interchange Format
Static Analysis Results Interchange Format is a machine-readable standard for exchanging static analysis findings between tools.
Continuous integration and continuous delivery
Continuous integration and continuous delivery is the practice of automatically building, testing, and preparing software changes through a pipeline.
Pull request
A pull request is a proposed code change submitted for review before it is merged into a shared branch.