Scan Bicep IaC with SonarQube

Catch Azure infrastructure misconfigurations before deployment with SonarQube.

Introduction

30 Second Summary

One misconfigured cloud resource can expose an entire organization's data to the internet. Most cloud security breaches trace back to infrastructure misconfigurations that slipped through unreviewed.

In this project, you will set up a local security scanning workflow that catches dangerous misconfigurations in Azure infrastructure code before they ever reach production.

What You'll Build

A local DevSecOps scanning pipeline that uses SonarQube to analyze Bicep infrastructure-as-code templates for security vulnerabilities and enforce a quality gate that blocks insecure code from passing.

By the end of this project, you'll have:

  • A SonarQube Community Build instance running locally in Docker, scanning intentionally insecure Bicep templates that trigger security hotspots.
  • A custom quality gate configured with strict security conditions that prevents insecure infrastructure code from being marked as passed.
  • A demonstrated scan proving that your quality gate blocks insecure code from silently passing analysis.
  • Secret Mission: Fix all the security vulnerabilities in your Bicep templates and achieve a passing quality gate.

Do I need an Azure account?

No. This project runs entirely on your local machine using Docker. You will write Azure Bicep templates, but you will not deploy them to any cloud environment. All you need is a Mac with a terminal.

Install Docker Desktop and Start SonarQube

Before you can scan any code for security issues, you need an environment to run the scanner and display results. Docker lets you run SonarQube as a container on your Mac without installing Java, databases, or other dependencies.

In this step, you will install Docker Desktop, start a SonarQube container, and create a project with an authentication token so the scanner can send results to SonarQube.

In this step, get ready to:
  • Install Docker Desktop on your Mac.
  • Start a SonarQube Community Build container for local code scanning.
  • Create a project and generate an authentication token for the scanner.
Install Docker Desktop for Mac

Docker Desktop is the application that runs containers on your Mac. It provides the docker command-line tool you will use throughout this project.

  • Open your browser and navigate to the Docker Desktop for Mac download page.
  • Click the download button for your Mac (Apple chip or Intel chip).
  • Open the downloaded Docker.dmg file.
  • Drag the Docker icon into the Applications folder.

What happens during installation?

macOS may perform security checks the first time you open Docker. This can take a minute or two. You may also be asked for your Mac password to allow Docker to make system changes.

  • Press Cmd+Space to open Spotlight.
  • Type Docker and press Enter to open Docker Desktop.
  • Complete the setup wizard that appears on first launch. Accept the Docker Subscription Service Agreement to proceed.
  • Wait for the Docker engine to start. You will see a green indicator in the bottom-left of the Docker Desktop window when it is ready.
  • Verify Docker is running by opening Terminal and running this command:
docker --version

You should see output like Docker version 28.x.x, build ... with a version number of 20.10 or higher.

✔️ I see version 20.10 or higher

Docker is installed and ready. Move on to the next substep.

ⓧ I see an older version

You have an outdated version of Docker installed. You need version 20.10 or higher for this project.

  • Open Docker Desktop.
  • Click the gear icon to open Settings.
  • Select Software updates and click Check for updates.
  • Install the latest update and restart Docker Desktop.
  • Run docker --version again to confirm the version is 20.10 or higher.

ⓧ Command not found

Docker is not available in your terminal. This usually means Docker Desktop has not finished starting.

  • Check that Docker Desktop is running. Look for the whale icon in your menu bar at the top of your screen.
  • If the whale icon is not there, open Docker Desktop again using Spotlight (Cmd+Space, type Docker, press Enter).
  • Wait for the engine to start (green indicator in Docker Desktop), then try the command again.
  • If it still does not work, close Terminal and open a new Terminal window. Then run docker --version again.
Start SonarQube Community Build

SonarQube Community Build is a free static analysis platform that detects security vulnerabilities, bugs, and code smells. You will run it as a Docker container using an embedded database, which is perfect for local evaluation.

  • Pull and start the SonarQube container by running this command in your Terminal:
docker run -d --name sonarqube -e SONAR_ES_BOOTSTRAP_CHECKS_DISABLE=true -p 9000:9000 sonarqube:latest

What does this command do?

  • docker run -d starts a new container in the background (detached mode).
  • --name sonarqube gives the container a name so you can easily reference it later.
  • -e SONAR_ES_BOOTSTRAP_CHECKS_DISABLE=true disables Elasticsearch bootstrap checks, which is required for running in a local evaluation setup.
  • -p 9000:9000 maps port 9000 on your Mac to port 9000 inside the container so you can access SonarQube in your browser.
  • sonarqube:latest pulls the latest SonarQube Community Build image from Docker Hub.

SonarQube takes approximately 1-2 minutes to fully start.

  • Check the startup progress by running:
docker logs sonarqube

Look for the message SonarQube is operational in the output. If you do not see it yet, wait 30 seconds and run the command again.

  • Once SonarQube is operational, open your browser and navigate to http://localhost:9000.
  • Log in with the default credentials: username admin and password admin.
  • SonarQube will prompt you to change the default password. Set a new password you will remember.

SonarQube not loading at localhost:9000?

  • Make sure you waited at least 1-2 minutes after running the docker run command. SonarQube needs time to initialize.
  • Run docker logs sonarqube and check for error messages. If you see memory-related errors, make sure Docker Desktop has at least 4 GB of RAM allocated (open Docker Desktop, go to Settings, then Resources).
  • Run docker ps to confirm the container is running. If it is not listed, it may have exited. Run docker rm sonarqube and then re-run the docker run command above.

help me troubleshoot why SonarQube is not loading at localhost:9000 after running docker run

Create a project and generate an authentication token

SonarQube organizes scan results by project. You also need an authentication token so the scanner can securely send results to your SonarQube instance.

  • In SonarQube, click Create new project (or select it from the landing page).
  • Set the Project key to bicep-security-scan.
  • Set the Display name to Bicep Security Scan.
  • Click Set up.

What is a project key?

The project key is a unique identifier that connects your scanner configuration to this specific project in SonarQube. You will reference this key in your sonar-project.properties file later.

  • Under Provide a token, select Generate a token.
  • Name the token scanner-token.
  • Click Generate.
  • Copy the token value and save it somewhere safe (a text file or notes app). You will need this token to run the scanner in a later step.

Save your token now

SonarQube only shows the token value once at generation time. If you lose it, you will need to generate a new one. Copy it immediately and store it somewhere accessible.

Your scanning infrastructure is ready. Next up, you will write intentionally insecure Bicep templates to give SonarQube something to detect.

Write Intentionally Insecure Bicep Templates

Your SonarQube instance is running and has a project ready to receive scan results. Now it's time to give it something to scan.

In this step, you'll write Bicep infrastructure-as-code templates that contain deliberate security flaws. These templates define Azure resources with insecure configurations that SonarQube's Azure Resource Manager analyzer will flag.

In this step, get ready to:
  • Create a project directory with scanner configuration.
  • Write intentionally insecure Bicep templates targeting storage and networking.
  • Verify the project structure is ready for scanning.
Create the project directory and configuration file

Before writing any Bicep code, you need a project folder and a configuration file that tells the SonarScanner which project to report results to.

  • Move to your Desktop by running this command:
cd ~/Desktop
  • Create your project folder and move into it by running these commands:
mkdir bicep-security-scan
cd bicep-security-scan

Seeing 'File exists' error?

If you already have a folder named bicep-security-scan on your Desktop from a previous attempt, delete it first with rm -rf ~/Desktop/bicep-security-scan and try again.

Help me troubleshoot this

  • Create the sonar-project.properties file by running this command:
cat > sonar-project.properties << 'EOF'
sonar.projectKey=bicep-security-scan
sonar.projectName=Bicep Security Scan
sonar.sources=.
EOF

What does this configuration do?

  • sonar.projectKey=bicep-security-scan links scan results to the project you created in the SonarQube UI.
  • sonar.projectName=Bicep Security Scan sets the human-readable name displayed in the dashboard.
  • sonar.sources=. tells the scanner to analyze all files in the current directory.
  • Confirm the file was created by running:
cat sonar-project.properties

You should see the three configuration lines printed in your terminal.

Seeing an empty output or error?

Make sure you ran the cat > sonar-project.properties << 'EOF' command from inside the bicep-security-scan folder. Run pwd to check your current location.

Help me fix my configuration file

✔️ Awesome, I've got everything!

Great. Make sure you are still inside the bicep-security-scan folder before moving on.

ⓧ I'd like to double check the full code

Here is the complete sonar-project.properties file:

sonar.projectKey=bicep-security-scan
sonar.projectName=Bicep Security Scan
sonar.sources=.
Write insecure Bicep code

Now you'll create a Bicep template with intentionally insecure Azure infrastructure. This gives SonarQube real security misconfigurations to detect.

  • Create the main.bicep file with the parameters and an insecure storage account by running this command:
cat > main.bicep << 'EOF'
param location string = resourceGroup().location
param storageAccountName string = 'insecurestorage${uniqueString(resourceGroup().id)}'

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    allowBlobPublicAccess: true
    supportsHttpsTrafficOnly: false
    minimumTlsVersion: 'TLS1_0'
  }
}
EOF

What security flaws does this storage account have?

  • allowBlobPublicAccess: true allows anyone on the internet to read blob data without authentication.
  • supportsHttpsTrafficOnly: false allows unencrypted HTTP connections, exposing data in transit.
  • minimumTlsVersion: 'TLS1_0' permits outdated TLS versions with known vulnerabilities.
  • Verify the storage account was written by running:
cat main.bicep

You should see the two parameters and the full storage account resource block.

File content looks wrong or truncated?

The heredoc delimiter EOF must appear on its own line with no leading spaces. If you see only a partial file, delete it with rm main.bicep and run the command again. Make sure EOF is flush against the left margin.

Help me fix my Bicep file

  • Add the insecure network security group below the storage account by running this command:
cat >> main.bicep << 'EOF'

resource nsg 'Microsoft.Network/networkSecurityGroups@2023-04-01' = {
  name: 'insecure-nsg'
  location: location
  properties: {
    securityRules: [
      {
        name: 'AllowAllInbound'
        properties: {
          priority: 100
          direction: 'Inbound'
          access: 'Allow'
          protocol: '*'
          sourcePortRange: '*'
          destinationPortRange: '*'
          sourceAddressPrefix: '*'
          destinationAddressPrefix: '*'
        }
      }
    ]
  }
}
EOF

What security flaws does this network security group have?

  • protocol: '*' allows all protocols instead of restricting to TCP or UDP.
  • sourceAddressPrefix: '*' accepts traffic from any IP address on the internet.
  • destinationPortRange: '*' opens every port on the target, including sensitive services like SSH (22) and RDP (3389).

Together, these create a rule that allows all inbound traffic from anywhere to everywhere. This is the network equivalent of leaving every door unlocked.

  • Verify the complete file by running:
cat main.bicep

You should see both the storage account resource and the network security group resource, separated by a blank line.

Only seeing the storage account?

Make sure you used >> (double arrow) in the second command, not > (single arrow). A single arrow overwrites the file. A double arrow appends to it. If the NSG is missing, run the second cat >> command again.

Help me fix my missing NSG code

✔️ Awesome, I've got everything!

Great. Double check you have both the storage account and NSG in main.bicep before continuing.

ⓧ I'd like to double check the full code

Here is the complete main.bicep file:

param location string = resourceGroup().location
param storageAccountName string = 'insecurestorage${uniqueString(resourceGroup().id)}'

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    allowBlobPublicAccess: true
    supportsHttpsTrafficOnly: false
    minimumTlsVersion: 'TLS1_0'
  }
}

resource nsg 'Microsoft.Network/networkSecurityGroups@2023-04-01' = {
  name: 'insecure-nsg'
  location: location
  properties: {
    securityRules: [
      {
        name: 'AllowAllInbound'
        properties: {
          priority: 100
          direction: 'Inbound'
          access: 'Allow'
          protocol: '*'
          sourcePortRange: '*'
          destinationPortRange: '*'
          sourceAddressPrefix: '*'
          destinationAddressPrefix: '*'
        }
      }
    ]
  }
}
Verify your project structure
  • Confirm your project has exactly two files by running:
ls

You should see main.bicep and sonar-project.properties in the output.

Missing a file?

If either file is missing, make sure you are inside the bicep-security-scan folder on your Desktop. Run pwd to confirm your location shows /Users/yourname/Desktop/bicep-security-scan. If you are in the wrong folder, navigate back with cd ~/Desktop/bicep-security-scan and re-create the missing file.

Help me find my missing files

Your insecure infrastructure templates are ready. Next up, you'll run the SonarScanner against these files and explore the security hotspots it detects.

Run the Scan and Explore Security Hotspots

You have insecure Bicep code sitting in a directory, and a SonarQube instance waiting to analyze it. The missing piece is the scanner that reads your files and sends the results to SonarQube for evaluation.

In this step, you will run the SonarScanner CLI via a Docker container to analyze your Bicep templates. Then you will explore the security findings SonarQube surfaces and learn how the hotspot review workflow helps teams triage risks.

In this step, get ready to:
  • Scan your Bicep code using the SonarScanner CLI Docker image.
  • Explore detected security hotspots in the SonarQube dashboard.
  • Understand the hotspot review workflow and risk categories.
Run the SonarScanner CLI via Docker

The SonarScanner CLI is the tool that reads your source files and sends analysis results to the SonarQube server. You will run it as a Docker container so you do not need to install Java or configure any local dependencies.

  • In your Terminal (already inside the bicep-security-scan directory), run the scanner by executing this command:
docker run --rm \
  -e SONAR_HOST_URL="http://host.docker.internal:9000" \
  -e SONAR_TOKEN="your-token-here" \
  -v "$(pwd):/usr/src" \
  sonarsource/sonar-scanner-cli
  • Replace your-token-here with the token you generated in Step 1 (the one named scanner-token).

What does this command do?

This command pulls and runs the sonarsource/sonar-scanner-cli Docker image. Here is what each flag does:

  • --rm removes the container automatically after the scan finishes.
  • -e SONAR_HOST_URL tells the scanner where to find your SonarQube server. host.docker.internal is how Docker Desktop for Mac lets a container reach the host machine.
  • -e SONAR_TOKEN authenticates the scanner with your SonarQube project.
  • -v "$(pwd):/usr/src" mounts your current directory into the container at /usr/src, which is the default analysis directory for the scanner.
  • Wait for the scan to complete. You should see an EXECUTION SUCCESS message at the end of the terminal output.

Not seeing EXECUTION SUCCESS?

  • If you see a connection error mentioning host.docker.internal, confirm that Docker Desktop is running (check the whale icon in your menu bar).
  • If you see an authentication error, double-check that you pasted the correct token value and that there are no extra spaces around it.
  • If the scanner cannot find your sonar-project.properties file, make sure you are running the command from inside the bicep-security-scan directory.

Help me troubleshoot my SonarScanner Docker run command failing.

Explore the results in the SonarQube UI

The scanner has sent your analysis results to SonarQube. Now you can see exactly what security issues it found in your intentionally insecure Bicep code.

  • Return to http://localhost:9000 in your browser.
  • Select your Bicep Security Scan project from the projects list.
  • On the project dashboard, observe the summary showing detected issues and security hotspots.
  • Select the Security Hotspots tab to see all security-sensitive code flagged by the analyzer.
  • Click on an individual hotspot to open its details.
  • Read through the three review tabs: What's the risk?, Assess the risk, and How can I fix it?.

What should I see?

Your dashboard should show multiple security hotspots corresponding to the insecure properties in your main.bicep file. These include findings related to public blob access, disabled HTTPS enforcement, weak TLS, and the overly permissive network security group rule.

Each hotspot links directly to the line of code that triggered it, so you can see the exact property value causing the security concern.

Understand the hotspot review workflow

Security hotspots are different from regular code issues. They highlight security-sensitive code that requires a human decision about whether the code is actually safe or needs to be fixed.

What is a Security Hotspot?

A Security Hotspot is code that touches a security-sensitive area but is not automatically classified as a vulnerability. It requires a developer to review the context and decide whether the code is safe or needs a fix.

Hotspots are categorized by review priority (High, Medium, Low) based on alignment with the OWASP Top 10 and CWE Top 25. Higher priority hotspots are most likely to need a fix.

How does the review workflow work?

For each hotspot, SonarQube provides a three-step review process:

  • The What's the risk? tab explains why the hotspot was raised.
  • The Assess the risk tab helps you decide whether a fix is needed.
  • The How can I fix it? tab provides secure coding recommendations.

Unreviewed hotspots count against your quality gate. In the next step, you will configure a custom quality gate that enforces zero unreviewed hotspots.

Your scan results are in and you have seen exactly how SonarQube surfaces insecure infrastructure patterns. Next up, you will create a custom quality gate that enforces strict security rules and blocks any insecure code from passing.

Configure a Custom Quality Gate

In the previous step, you explored the security hotspots that SonarQube found in your insecure Bicep code. You saw what each vulnerability looks like and how SonarQube categorizes them by risk level.

Now you need a way to enforce those findings. A quality gate is a set of pass/fail conditions that your code must meet. If any condition is violated, the gate marks the project as "Failed." In this step, you will create a custom quality gate that blocks code with unreviewed security hotspots or new issues from passing.

In this step, get ready to:
  • Create a custom quality gate in SonarQube.
  • Review the pre-populated security enforcement conditions.
  • Associate the gate with your Bicep Security Scan project.
Create a new quality gate

SonarQube comes with a built-in quality gate called "Sonar way," but it is read-only. To customize the enforcement rules for your IaC project, you need to create your own gate.

  • In SonarQube at http://localhost:9000, select Quality Gates in the top navigation bar.
  • In the left panel, select the Create button.
  • In the dialog that opens, enter IaC Security Gate as the name.
  • Select Create.

Your new quality gate now appears in the left panel. SonarQube automatically copies the recommended "Sonar way" conditions into your new gate as a starting point.

What is a quality gate?

A quality gate is a set of conditions that code must satisfy to be considered acceptable. If any condition fails, the entire gate status becomes "Failed."

In a CI/CD pipeline, the gate status is checked programmatically to block deployments. Locally, you are proving the concept by observing the pass/fail status in the SonarQube dashboard.

Customize the quality gate conditions

Because you created the gate from scratch, SonarQube pre-populates it with the Sonar way conditions. These already include the two security-critical conditions you need.

  • Confirm that your IaC Security Gate is selected in the left panel.
  • In the right panel, look at the list of conditions. You should see these four:
  • No new issues are introduced (fails if the number of issues is higher than 0).
  • All new Security Hotspots are reviewed (fails if Security Hotspots Reviewed is less than 100%).
  • New code test coverage >= 80.0%.
  • Duplication in new code <= 3.0%.

Why keep all four conditions?

The coverage and duplication conditions will not affect your Bicep-only project because IaC files have no test coverage metrics. They simply do not apply.

The two conditions that matter for this project are the issues condition and the security hotspots condition. Together, they guarantee that any new issues or unreviewed hotspots will cause the gate to fail.

Associate the quality gate with your project

Creating a gate does not automatically apply it to any project. You need to explicitly associate your project with the new gate.

  • With your IaC Security Gate still selected in the left panel, scroll down to the Projects section in the right panel.
  • Select the Without tab to see projects not yet associated with this gate.
  • Find Bicep Security Scan in the list and select it to associate it with your custom gate.

Your project will now be evaluated against the IaC Security Gate instead of the default Sonar way gate.

What changed for your project?

Previously, your project used the built-in Sonar way gate, which has the same conditions but cannot be customized. Now it uses your custom gate, which you can tighten or relax as needed.

The next time you run a scan, SonarQube will evaluate your code against the conditions in this custom gate and display a clear "Passed" or "Failed" status.

Don't see the Projects section?

Make sure you are viewing the custom gate you just created, not the built-in Sonar way gate. Built-in gates do not show a Projects section because they cannot be associated manually.

If the Projects section still does not appear, scroll further down the page. It sits below the conditions list and the Permissions section.

Help me find the Projects section in my quality gate

Your custom quality gate is locked and loaded. Next up, you will re-run the scanner to trigger the gate evaluation and prove that insecure code cannot pass.

Demonstrate the Quality Gate Blocking Insecure Code

Your custom quality gate is configured and associated with the project. Now you need to prove it actually works.

In this step, you will re-run the scanner against your insecure Bicep code and watch the quality gate block it from passing. This is the moment where all your setup pays off.

In this step, get ready to:
  • Re-run the SonarScanner to trigger quality gate evaluation.
  • Verify the quality gate shows "Failed" in the SonarQube dashboard.
  • Understand how quality gates integrate with CI/CD pipelines in practice.
Re-run the scan to trigger quality gate evaluation

The first scan ran before your custom quality gate was associated with the project. You need a fresh scan for SonarQube to evaluate your code against the new gate's conditions.

  • In your terminal (still inside the bicep-security-scan directory), run the scanner again using Docker:
docker run --rm \
  -e SONAR_HOST_URL="http://host.docker.internal:9000" \
  -e SONAR_TOKEN="your-token-here" \
  -v "$(pwd):/usr/src" \
  sonarsource/sonar-scanner-cli
  • Replace your-token-here with the token you generated in Step 1.
  • Wait for the "EXECUTION SUCCESS" message to appear in your terminal output.

What does this command do?

This is the same scanner command you ran in Step 3. The difference is that your project is now evaluated against the custom IaC Security Gate instead of the default "Sonar way" gate.

SonarQube evaluates quality gate conditions after every scan completes. The new results will be checked against your stricter security conditions.

Not seeing EXECUTION SUCCESS?

Make sure the SonarQube container is still running. Run docker ps and check that the sonarqube container is listed.

If the container stopped, restart it with docker start sonarqube and wait 1-2 minutes before re-running the scanner.

help me troubleshoot why my SonarScanner Docker command is failing

Verify the quality gate failure in the UI

With the scan complete, your project dashboard now reflects the quality gate evaluation. The insecure code you wrote should trigger a clear failure.

  • Return to http://localhost:9000 in your browser.
  • Select your Bicep Security Scan project.
  • Observe the quality gate status at the top of the project dashboard. It should prominently show Failed.
  • Look at the failure reasons listed below the status. These show which conditions were not met: unreviewed security hotspots and new issues detected.

Why does the gate fail?

Your IaC Security Gate has two conditions: all security hotspots must be reviewed (100%), and zero new issues are allowed.

Your insecure Bicep code triggers security hotspots (public blob access, HTTP allowed, TLS 1.0, wildcard NSG rules) that remain unreviewed. It also introduces new issues. Both conditions fail, so the gate blocks the code from passing.

Still seeing "Passed" status?

Make sure you associated the IaC Security Gate with your project in the previous step. Navigate to Quality Gates in the top navigation, select your custom gate, and confirm Bicep Security Scan appears in the Projects section.

help me figure out why my quality gate still shows Passed after scanning insecure code

Understand how this blocks failures from passing in practice

You have proven locally that insecure code triggers a gate failure. In a real development workflow, this same mechanism prevents insecure code from reaching production.

How does this work in a CI/CD pipeline?

In a CI/CD pipeline, the quality gate status is checked programmatically after the scan completes. Tools like Jenkins use a waitForQualityGate step, and GitHub Actions workflows query the SonarQube API to check the status.

If the quality gate status is not "OK", the pipeline fails and the code cannot be merged or deployed. No insecure infrastructure code slips through unreviewed.

This is the core value of what you built. Your quality gate acts as an automated gatekeeper. Code with unreviewed security hotspots or new issues cannot be marked as passing, whether you are scanning locally or in a full pipeline.

Secret mission

Fix the Vulnerabilities and Pass the Quality Gate

Your quality gate is doing its job. It caught the insecure Bicep code and blocked it from passing. Now flip it around: fix every vulnerability, re-scan, and prove that hardened infrastructure code earns a passing quality gate.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely locally using Docker, so there are no ongoing cloud costs. The SonarQube container does consume local disk space and memory while running.

Resources you used:

  • Docker container named sonarqube (running SonarQube Community Build with embedded H2 database).
  • Docker volumes for SonarQube data (created automatically by Docker).
  • Local project directory bicep-security-scan on your Desktop.

Keep everything running

No action needed. Choose this if you are still actively experimenting with SonarQube or want to scan additional Bicep templates.

  • Your SonarQube instance stays available at http://localhost:9000.
  • The sonarqube container uses approximately 2GB of RAM while running.
  • Docker Desktop remains installed on your Mac for future container workloads.

Pause - I'll come back to this later

Stop the running container to free up memory. Your data and configuration will be preserved so you can restart later.

  • Stop the SonarQube container by running:
docker stop sonarqube
  • When you are ready to continue, restart it by running:
docker start sonarqube
  • After restarting, wait 1-2 minutes, then open http://localhost:9000 to access SonarQube again.

Delete - I don't want to use this again

Remove all project resources and start fresh. This permanently deletes your SonarQube data, scan history, and local project files.

  • Remove the SonarQube container by running:
docker rm -f sonarqube
  • Reclaim disk space used by Docker volumes by running:
docker system prune --volumes

What does this command do?

The docker system prune --volumes command removes all unused Docker data, including stopped containers, dangling images, and unused volumes. This is not limited to SonarQube. If you have other Docker projects, only run this if you are sure you do not need their unused data.

  • Delete the local project directory by running:
cd ~/Desktop
rm -rf bicep-security-scan
  • Confirm the directory is removed by running:
ls ~/Desktop | grep bicep
  • You should see no output, confirming the folder is gone.

That's a Wrap!

That's a Wrap!

Nice work! You've just built a local DevSecOps scanning workflow that catches security misconfigurations in Azure Bicep templates before they ever reach production.

You've learned how to:

  • Scanned Infrastructure as Code using the SonarScanner CLI Docker image and explored security hotspots in the SonarQube UI.
  • Configured a custom quality gate that enforces zero unreviewed hotspots and zero new issues.
  • Demonstrated a quality gate failure proving that insecure infrastructure code cannot silently pass analysis.
  • Secret Mission: Fixed all vulnerabilities in the Bicep templates and achieved a passing quality gate.

Ready to quiz yourself?