Share via

Defender for Cloud DevOps Security findings dropped to 0 after agentless code scanning update

Dikshant Lather 40 Reputation points
2026-05-21T22:32:13.5566667+00:00

Hi Team,

I am facing an issue in Microsoft Defender for Cloud → DevOps Security.

Until recently, I was able to see security findings (code, secrets, dependencies, IaC, etc.) across my repositories. However, today I observed the following:

🔍 Current behavior:

  • DevOps connector status: ✅ Connected
  • Repositories: ✅ Visible (~500 repositories)
  • Findings: ❌ Showing 0 for all repositories

📅 Additional observations:

  • Earlier, findings were visible without any issue
  • This issue started today
  • I noticed that agentless code scanning appears to be auto-enabled in my environment
  • I did not manually enable this feature

Reference: https://learn.microsoft.com/en-us/azure/defender-for-cloud/agentless-code-scanning

❓ Questions:

  1. Could this issue be related to agentless code scanning being auto-enabled?
  2. Who enables agentless scanning — is it auto-enabled by Microsoft, policy, or user action?
  3. How can I check who enabled this feature ?
  4. Does agentless scanning replace or disable previous findings (e.g., SARIF/pipeline-based scanning)?
  5. Is there a delay expected before findings are populated again after enablement?
  6. How can I confirm that scanning is actually running successfully?
  7. Is there a way to force re-scan or re-sync findings?

✅ What I already verified:

  • Connector is healthy and connected
  • Repositories are discovered correctly
  • No intentional configuration changes from my sideHi Team, I am facing an issue in Microsoft Defender for Cloud → DevOps Security. Until recently, I was able to see security findings (code, secrets, dependencies, IaC, etc.) across my repositories. However, today I observed the following:

    🔍 Current behavior:

    • DevOps connector status: ✅ Connected
    • Repositories: ✅ Visible (~500 repositories)
    • Findings: ❌ Showing 0 for all repositories

    📅 Additional observations:

    • Earlier, findings were visible without any issue
    • This issue started today
    • I noticed that agentless code scanning appears to be auto-enabled in my environment
    • I did not manually enable this feature
    Reference:
    https://learn.microsoft.com/en-us/azure/defender-for-cloud/agentless-code-scanning

    ❓ Questions:

    1. Could this issue be related to agentless code scanning being auto-enabled?
    2. Who enables agentless scanning — is it auto-enabled by Microsoft, policy, or user action?
    3. How can I check who enabled this feature (audit logs / activity logs)?
    4. Does agentless scanning replace or disable previous findings (e.g., SARIF/pipeline-based scanning)?
    5. Is there a delay expected before findings are populated again after enablement?
    6. How can I confirm that scanning is actually running successfully?
    7. Is there a way to force re-scan or re-sync findings?

    ✅ What I already verified:

    • Connector is healthy and connected
    • Repositories are discovered correctly
    • No intentional configuration changes from my side
Microsoft Security | Microsoft Defender | Microsoft Defender for Cloud

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Shubham Sharma 16,730 Reputation points Microsoft External Staff Moderator
    2026-05-22T03:46:07.1133333+00:00

    Hey Dikshant, sorry you’re running into this—seeing zero finding counts after agentless code scanning flipped on can definitely be confusing. I’ll walk through your questions and share some troubleshooting tips.

    1. Could this issue be related to agentless code scanning being auto-enabled? Yes. Defender for Cloud’s agentless code scanning is a new, umbrella feature that surfaces secrets, dependencies, IaC issues, etc., across all your Azure DevOps repos without installing pipeline extensions. When it’s enabled, the portal switches to show agentless-scan results and hides the old SARIF or pipeline-based findings until the first full agentless scan completes. That can look like “zero findings,” even though your previous scans aren’t gone—they’re just not being displayed while the new engine catches up.
    2. Who enables agentless scanning—Microsoft, policy, or user action?
      • Microsoft can roll it out automatically as part of the Defender CSPM/DevOps plan GA.
      • You can also flip it on or off from the DevOps Connector settings in the portal.
      • Lastly, an Azure Policy assignment (or management group policy) could toggle it via the Microsoft.Security/DevOpsSecuritySettings resource type.
    3. How can I check who enabled the feature? Check the Activity Log for your subscription/DevOps Connector resource—filter on operations like Microsoft.Security/DevOpsSecuritySettings/write or “Update DevOps security settings.” The caller identity in the log entry (user/service principal/IP) tells you who or what policy did the write. If you suspect an Azure Policy, review your policy assignments under Policy → Assignments and check who last modified it.
    4. Does agentless scanning replace or disable previous findings (e.g., SARIF/pipeline-based)? It replaces the display of pipeline-based findings in the DevOps Security view, but doesn’t delete historical SARIF results in your pipeline artifacts or in GitHub/Azure DevOps itself. Those results still exist in build logs or in GitHub Advanced Security. Once the agentless scan runs, you’ll see a combined set of findings in Defender for Cloud; until then it defaults to zero.
    5. Is there a delay expected before findings populate again after enablement? Absolutely. The first agentless repository scan can take up to a few hours (dependent on repo count/size). After initial discovery, subsequent scans run on a ~24-hour cadence. Until the initial pass completes, DevOps Security will show zero.
    6. How can I confirm that scanning is actually running successfully?
      • In the portal, go to Microsoft Defender for Cloud → DevOps Security → Connector details and look for “Last scan” timestamps.
      • Check the Activity Log for “Run agentless code scan” or similar operations.
      • If you have Log Analytics enabled, query the SecurityDevOpsScan table for recent entries.
      • You can also spot-check by breaking a repo (e.g. introduce a dummy secret) and seeing if it surfaces after the scan interval.
    7. Is there a way to force re-scan or re-sync findings? There’s no single “Rescan now” button in GA, but you can: a. Temporarily disable agentless scanning in the connector settings, save, then re-enable—this kicks off a fresh full scan. b. Disconnect and reconnect the DevOps Connector. c. Use the REST API (POST /providers/Microsoft.Security/devOpsSecuritySettings/{settingName}/runScan?api-version=2023-01-01) to programmatically invoke a scan. d. Push a new commit to a few repos; that’ll trigger pipeline-based SARIF scans (if you have CredScan or other scanners configured) which will repopulate their findings until agentless scan finishes.

    Reference list:

    If the answer is helpful, kindly upvote it. If you have extra questions about this answer, please click "Comment".

    Was this answer helpful?

    3 people found this answer helpful.

  2. AI answer

    2026-05-21T22:32:34.8333333+00:00

    Based on the available information, only the following aspects can be addressed.

    1. Agentless code scanning behavior and timing

    Agentless code scanning in Defender for Cloud works independently of CI/CD pipelines and uses the Azure DevOps or GitHub connector to automatically scan code and IaC configurations. Once enabled in the connector, the process is:

    1. Repository discovery: all repositories linked through the connector are identified immediately after connector creation and then every 8 hours.
    2. Code retrieval: the latest code from the default branch is retrieved after connector setup and then daily.
    3. Analysis: built‑in tools scan for vulnerabilities, misconfigurations, and create an SBOM.
    4. Findings processing: findings are processed into Defender for Cloud security recommendations.
    5. Results delivery: findings appear as DevOps security recommendations in Defender for Cloud.

    Scan frequency and duration:

    • Posture of repositories/pipelines/service connections: at connector creation and then every 8 hours.
    • Code and IaC scans: at connector creation and then daily.
    • Typical scan duration: 15–60 minutes per repository, depending on size and complexity.

    From this, a delay is expected between enabling agentless scanning and seeing findings, and there can be up to a day before new results appear after initial enablement.

    1. Where to see findings and confirm scanning is working

    After scans finish, security findings are surfaced as security recommendations in Defender for Cloud:

    1. Go to the Security recommendations tab in Microsoft Defender for Cloud.
    2. Review DevOps‑related recommendations, for example:
      • "Repositories should have code scanning findings resolved"
      • "Repositories should have infrastructure as code scanning findings resolved"
      • "Repositories should have dependency vulnerability scanning findings resolved"
    3. Selecting a recommendation shows affected files, severity, and remediation steps.

    If agentless scanning is running successfully, these recommendations will start to populate again for the onboarded Azure DevOps or GitHub repositories once the daily scans and processing complete.

    1. DevOps recommendations that represent agentless scan results

    For Azure DevOps, relevant recommendations include:

    • "Azure DevOps repositories should have code scanning findings resolved"
    • "Azure DevOps repositories should have dependency vulnerability scanning findings resolved"
    • "Azure DevOps repositories should have infrastructure as code scanning findings resolved"
    • "Azure DevOps repositories should have secret scanning findings resolved"

    These are populated from the scanning tools (including agentless code and IaC scanning and other DevOps security capabilities). If they show 0 affected resources, it typically means no qualifying findings are currently being surfaced for those repositories, or scans/findings have not yet completed processing.

    1. Expected delay and re‑scan behavior

    From the documented behavior:

    • Repository posture is reassessed every 8 hours.
    • Code and IaC scans run daily.
    • Each scan run typically completes within 15–60 minutes per repository.

    This implies:

    • After enabling agentless code scanning in a connector, it can take up to a day for new findings to appear.
    • There is no documented manual “force re‑scan” mechanism in the provided context; scans are scheduled by the service based on the above cadence.
    1. What can be checked now

    Within the documented scope, the following can be verified to confirm scanning and findings:

    1. Ensure the DevOps connector is onboarded and healthy (already verified).
    2. Wait at least one full daily scan cycle after agentless scanning enablement (up to 24 hours) and then:
      • Open Defender for Cloud → Security recommendations.
      • Filter for DevOps‑related recommendations such as:
        • "Repositories should have code scanning findings resolved"
        • "Repositories should have infrastructure as code scanning findings resolved"
        • "Azure DevOps repositories should have code scanning findings resolved" and similar.
    3. Check whether any repositories are listed under these recommendations and review their details.

    Information about who enabled agentless scanning, whether it was auto‑enabled, how to audit that action, and whether agentless scanning replaces or disables SARIF/pipeline‑based findings is not present in the provided context.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

    2 people found this answer helpful.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.