DevSecOps Pipeline with SonarCloud

Integrate SAST and DAST security scanning into a CI/CD pipeline.

Introduction

30 Second Summary

Every application has security vulnerabilities hiding in the code. The difference between a hobby project and a production-ready one is whether you catch those vulnerabilities automatically, before they reach users.

In this project, you will build two automated security scanning pipelines that run every time you push code to your repository. One scans your source code for vulnerabilities before it runs. The other attacks your running application to find weaknesses that only appear at runtime.

What You'll Build

A DevSecOps pipeline that integrates SonarCloud for static code analysis and OWASP ZAP for dynamic security testing into your GitHub Actions CI/CD workflow.

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

  • A SonarCloud SAST workflow that automatically scans your code for vulnerabilities, bugs, and code smells on every push.
  • An OWASP ZAP DAST workflow that starts your backend server and runs a baseline security scan against it.
  • Real security findings visible in your SonarCloud dashboard and as a GitHub issue created by ZAP.
  • Secret Mission: Configure a quality gate that blocks insecure code from being merged into your main branch.

Are there any prerequisites?

You need a public GitHub repository with a MERN stack application already set up. You also need VS Code and Git installed on your machine.

No prior CI/CD experience is required. This project walks you through everything from scratch.

Set Up SonarCloud and GitHub Secrets

Before your pipeline can scan code for vulnerabilities, it needs a secure connection between GitHub and SonarCloud. SonarCloud is a cloud-hosted static analysis service that inspects your source code without running it.

In this step, you'll create a SonarCloud account, link it to your repository, and store a secure authentication token so GitHub Actions can communicate with SonarCloud on your behalf.

In this step, get ready to:
  • Create a SonarCloud account linked to your GitHub repository.
  • Generate a SonarCloud authentication token.
  • Store the token as a secret in your GitHub repository.
Create your SonarCloud account and import your repository

SonarCloud needs access to your GitHub repository so it can analyze the code you push. You'll sign up using your GitHub account and import your MERN app as a new project.

  • Open your browser and navigate to sonarcloud.io.
  • Click Start now to begin the sign-up process.
  • Select GitHub as your DevOps platform.
  • Sign in with your GitHub credentials when prompted.

What happens during sign-up?

SonarCloud will ask you to authorize the SonarQube Cloud application on GitHub. This grants SonarCloud read access to your repositories for analysis.

After authorizing, you'll be guided through creating a SonarCloud organization linked to your GitHub account.

  • Follow the on-screen steps to install the SonarQube Cloud application on your GitHub account.
  • On the subscription page, select the Free plan.
  • Review the organization details at the bottom of the page.
  • Note your organization key (this is typically your GitHub username).
  • Click Create organization.

You'll now see the project import page where you can select which repositories to analyze.

  • Select your MERN application repository from the list.
  • Click Set up to import it as a SonarCloud project.
  • Accept the default new code definition and click Create project.

Your project is now created. Note the project key shown on the project page. It follows the format your-github-username_your-repo-name.

Why do I need the organization key and project key?

These two values tell the SonarCloud scanner exactly which project to report results to. You'll use them in a configuration file in the next step.

Don't see your repository in the import list?

Make sure your repository is public. SonarCloud's free plan supports unlimited public repositories but requires them to be public.

Check that you granted SonarCloud access to all repositories during the GitHub app installation step. You can adjust this under your GitHub account's application settings.

Help me connect SonarCloud to my GitHub repository.

Generate a token and store it as a GitHub secret

GitHub Actions needs a way to authenticate with SonarCloud when it runs your scan. You'll generate a personal access token in SonarCloud, then store it as an encrypted secret in your GitHub repository.

  • In SonarCloud, click your account avatar in the top-right corner.
  • Select My Account.
  • Click the Security tab.
  • In the Generate Tokens section, type a name for your token (for example, github-actions).
  • Click Generate.
  • Copy the token value immediately using the copy icon next to it.

Copy the token now. You cannot see it again.

Once you leave this page or dismiss the notification, the token value is hidden permanently. If you lose it, you'll need to generate a new one.

Now you'll store this token securely in your GitHub repository so your workflow can use it.

  • Open your MERN application repository on GitHub.
  • Click the Settings tab at the top of your repository page.
  • In the left sidebar under the Security section, click Secrets and variables.
  • Click Actions.
  • Click New repository secret.
  • In the Name field, type SONAR_TOKEN.
  • In the Secret field, paste the token you copied from SonarCloud.
  • Click Add secret.

What is a repository secret?

Repository secrets are encrypted values that GitHub Actions workflows can access at runtime. GitHub never displays the secret value again after you save it.

Your workflow will reference this token using the ${{ secrets.SONAR_TOKEN }} syntax. This keeps your credentials safe even if someone views your workflow files.

Don't see the Settings tab on your repository?

You need admin or owner access to the repository. If you forked the MERN app from someone else, make sure you're looking at your own fork, not the original repository.

Help me find where to add secrets in my GitHub repository.

Verify your secret is saved
  • On the same Actions secrets and variables page, confirm that SONAR_TOKEN appears in the Repository secrets list.

You should see SONAR_TOKEN listed with an "Updated" timestamp. The value itself is hidden, which is expected.

Why is the secret value hidden?

GitHub encrypts secrets the moment you save them. Even repository administrators cannot view the value after creation. This is a security feature that prevents accidental exposure of credentials.

Your authentication is in place. Next up, you'll write your first GitHub Actions workflow that uses this token to run a SonarCloud scan every time you push code.

Create the SonarCloud Workflow

Your SonarCloud account is connected and your secret is safely stored. Now it's time to create the automated workflow that scans your code every time you push changes.

GitHub Actions workflows are YAML files stored inside your repository. They define automated tasks that GitHub runs for you. You'll write a workflow that triggers SonarCloud's scanner whenever code is pushed to your main branch or a pull request is opened.

In this step, get ready to:
  • Create a GitHub Actions workflow file for SonarCloud scanning.
  • Configure a properties file that tells SonarCloud what to analyze.
  • Push both files to trigger your first automated scan.
Create the SonarCloud workflow file

GitHub Actions looks for workflow files in a special directory called .github/workflows/ at the root of your repository. Any .yml file placed there becomes an automated pipeline.

  • In VS Code, open the Explorer sidebar on the left (press Cmd+Shift+E on macOS or Ctrl+Shift+E on Windows).
  • Click the New File icon at the top of the Explorer panel.
  • Type .github/workflows/sonarcloud.yml as the file name and press Enter.

Why type the full path?

VS Code automatically creates any intermediate folders that don't exist yet. Typing the full path .github/workflows/sonarcloud.yml creates both the .github and workflows directories for you in one step.

  • Paste the following workflow code into the new sonarcloud.yml file:
name: SonarCloud Analysis

on:
  push:
    branches:
      - main
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  sonarcloud:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 0

      - name: SonarQube Scan
        uses: SonarSource/sonarqube-scan-action@v8.2.0
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

What does this workflow do?

  • name: sets the display name you'll see in the GitHub Actions tab.
  • on: defines when the workflow runs. It triggers on every push to main and on pull requests that are opened, updated, or reopened.
  • fetch-depth: 0 tells the checkout step to download your full Git history. SonarCloud needs this to accurately track when issues were introduced.
  • SonarSource/sonarqube-scan-action@v8.2.0 is the official SonarCloud scanner action. It reads your SONAR_TOKEN secret to authenticate with your SonarCloud project.
  • Save sonarcloud.yml by pressing Cmd+S (macOS) or Ctrl+S (Windows).
  • Confirm the file appears under .github/workflows/ in the Explorer sidebar.

Don't see the .github folder?

Some systems hide files and folders that start with a dot. In VS Code's Explorer, the .github folder should still be visible. If you don't see it, make sure you typed the path correctly with the leading dot. Check that you pressed Enter after typing the filename to confirm creation.

help me find my .github folder in VS Code

✔️ Awesome, I've got everything!

Great. Make sure you've saved the file before moving on.

ⓧ I'd like to double check the full code

name: SonarCloud Analysis

on:
  push:
    branches:
      - main
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  sonarcloud:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 0

      - name: SonarQube Scan
        uses: SonarSource/sonarqube-scan-action@v8.2.0
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
Create the SonarCloud properties file

SonarCloud needs a configuration file to know which project it's analyzing and where your source code lives. This file sits at the root of your repository.

  • In the VS Code Explorer sidebar, click the New File icon again.
  • Type sonar-project.properties and press Enter.
  • Paste the following configuration into the file:
sonar.organization=[[SONAR_ORG="your-github-username"]]
sonar.projectKey=[[SONAR_PROJECT_KEY="your-github-username_your-repo-name"]]

sonar.sources=.
sonar.exclusions=**/node_modules/**,**/build/**,**/dist/**

What do these properties mean?

  • sonar.organization is your SonarCloud organization key. This matches the GitHub username or org you signed up with.
  • sonar.projectKey uniquely identifies your project in SonarCloud. You noted this when you imported your repository in the previous step.
  • sonar.sources tells the scanner to analyze everything from the current directory.
  • sonar.exclusions skips folders like node_modules, build, and dist that contain generated code rather than your source.

Find your organization and project keys

If you forgot these values, sign in to SonarCloud and navigate to your project's Information page. Both keys are displayed there. The organization key is typically your GitHub username in lowercase.

  • Save sonar-project.properties.
  • Confirm the file appears at the root level of your repository in the Explorer sidebar (at the same level as your package.json or server folder).

Not sure if the file is in the right place?

The sonar-project.properties file must be at the top level of your repository, not inside a subfolder. If it ended up inside .github or another directory, drag it to the root in the Explorer sidebar.

help me place sonar-project.properties in the right location

✔️ Awesome, I've got everything!

Great. Make sure you've saved the file before moving on.

ⓧ I'd like to double check the full code

sonar.organization=your-github-username
sonar.projectKey=your-github-username_your-repo-name

sonar.sources=.
sonar.exclusions=**/node_modules/**,**/build/**,**/dist/**
Commit and push your changes

Both files are saved locally. For the workflow to run, you need to push them to GitHub.

  • Open your terminal in VS Code by pressing Ctrl+` (backtick key, same on macOS and Windows).
  • Stage, commit, and push both files by running these commands:
git add .github/workflows/sonarcloud.yml sonar-project.properties
git commit -m "Add SonarCloud workflow and configuration"
git push origin main

What do these commands do?

  • git add stages the two new files so Git knows to include them in the next commit.
  • git commit saves the staged changes with a descriptive message.
  • git push origin main uploads your commit to GitHub. This push triggers the workflow you just created.
  • Open your repository on GitHub in your browser.
  • Click the Actions tab at the top of the repository page.
  • You should see a workflow run called SonarCloud Analysis in progress or recently completed. A yellow dot means it's running. A green checkmark means it passed.

Don't see a workflow run?

Make sure your push actually reached GitHub. Run git log --oneline -1 in your terminal and compare the commit hash with the latest commit shown on your repository's main page. If they don't match, try running git push origin main again.

Also check that the file is at exactly .github/workflows/sonarcloud.yml. GitHub only recognizes workflow files in that specific path.

help me troubleshoot why my GitHub Actions workflow isn't running

Your first automated security scan is running. Next up, you'll create a second workflow that attacks your running application to find vulnerabilities that static analysis can't detect.

Create the OWASP ZAP Scan Workflow

Your SonarCloud workflow scans your source code for vulnerabilities without ever running the application. That catches a lot, but some security issues only show up when the app is actually running.

In this step, you will create a second workflow that starts your Express backend inside the GitHub Actions runner, then unleashes OWASP ZAP against it. This is DAST in action: testing the running application the same way an attacker would probe it from the outside.

In this step, get ready to:
  • Write a GitHub Actions workflow that boots your backend server on the runner.
  • Add a readiness check and an OWASP ZAP baseline scan step.
  • Push the workflow and watch it run in the Actions tab.
Create the ZAP workflow file

Unlike the SonarCloud workflow, this one needs a live server to scan. That means the workflow must install dependencies, start your backend, and confirm it is responding before ZAP can do its job.

  • In VS Code, create a new file called zap-scan.yml inside your .github/workflows/ directory (the same folder that holds sonarcloud.yml).
  • Paste the following code into zap-scan.yml:
name: OWASP ZAP Baseline Scan

on:
  push:
    branches:
      - main

jobs:
  zap-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v6

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install backend dependencies
        run: |
          cd server
          npm install

      - name: Start backend server
        run: |
          cd server
          npm start &
        env:
          NODE_ENV: test

What does this code do?

This workflow triggers on every push to main. It runs on an ubuntu-latest runner provided by GitHub.

  • actions/checkout@v6 clones your repository onto the runner so the workflow can access your code.
  • actions/setup-node@v4 installs Node.js version 20 so you can run your Express app.
  • cd server && npm install moves into your backend directory and installs its packages.
  • npm start & starts the server in the background. The & is critical because without it the workflow would wait forever for the server process to finish.
  • NODE_ENV: test sets the environment so your app runs in test mode.

Backend directory name

The code above uses server as the backend directory. If your MERN project stores the Express app in a different folder (like backend or api), replace server with your actual directory name in both the install and start steps.

You won't see a change yet. The next section adds the security scan that completes this workflow.

Add the server readiness check and ZAP scan

The server takes a moment to boot. If ZAP tries to scan before the server is ready, the scan fails immediately. A simple retry loop solves this by polling until the server responds.

  • In zap-scan.yml, add the following steps directly below the Start backend server step:
      - name: Wait for server to be ready
        run: |
          for i in $(seq 1 30); do
            curl -s http://localhost:5000/ && break
            echo "Waiting for server... attempt $i"
            sleep 2
          done

      - name: Run ZAP Baseline Scan
        uses: zaproxy/action-baseline@v0.15.0
        with:
          target: 'http://localhost:5000'
          allow_issue_writing: true

What does this code do?

  • The Wait for server step runs a loop that attempts curl against http://localhost:5000/ up to 30 times, sleeping 2 seconds between each try. As soon as the server responds, it breaks out and moves on.
  • zaproxy/action-baseline@v0.15.0 runs the ZAP baseline scan inside a Docker container on the same runner. It connects to your server via localhost because both share the host network.
  • allow_issue_writing: true tells ZAP to create a GitHub issue in your repository listing every vulnerability it finds.

Port number

The workflow targets port 5000. If your Express app listens on a different port, update both the curl URL and the target value to match.

  • Save zap-scan.yml.

✔️ Awesome, I've got everything!

Great. Double check you have saved the file, then move on to push it.

ⓧ I'd like to double check the full code

Here is the complete zap-scan.yml file. Make sure yours matches exactly:

name: OWASP ZAP Baseline Scan

on:
  push:
    branches:
      - main

jobs:
  zap-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v6

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install backend dependencies
        run: |
          cd server
          npm install

      - name: Start backend server
        run: |
          cd server
          npm start &
        env:
          NODE_ENV: test

      - name: Wait for server to be ready
        run: |
          for i in $(seq 1 30); do
            curl -s http://localhost:5000/ && break
            echo "Waiting for server... attempt $i"
            sleep 2
          done

      - name: Run ZAP Baseline Scan
        uses: zaproxy/action-baseline@v0.15.0
        with:
          target: 'http://localhost:5000'
          allow_issue_writing: true

YAML looking off in your editor?

YAML is very sensitive to indentation. Every level uses exactly 2 spaces. Make sure your steps: entries are indented under jobs: > zap-scan: and that each - name: line aligns with the others.

help me fix YAML indentation errors in my GitHub Actions workflow

Commit and push the workflow
  • Stage, commit, and push the new workflow file by running these commands in your terminal:
git add .github/workflows/zap-scan.yml
git commit -m "Add OWASP ZAP baseline scan workflow"
git push origin main
  • Switch to your browser and open your GitHub repository.
  • Click the Actions tab at the top of the repository.
  • You should see a new workflow run called OWASP ZAP Baseline Scan in progress.

How long does the ZAP scan take?

The baseline scan typically takes 1 to 2 minutes. It runs passive checks only, meaning it observes traffic patterns without actively attacking your server. You will also see the SonarCloud workflow trigger again since you pushed to main.

Workflow failing immediately?

  • Check the error message in the Actions log. If it mentions a YAML syntax error, double check your indentation against the full code in the tab above.
  • If the Install backend dependencies step fails, confirm your backend folder is actually named server in your repository. Adjust the cd server lines if yours is different.
  • If the Wait for server step times out after 60 seconds, your Express app may not be starting on port 5000. Check your app's startup script and update the port in the workflow if needed.

help me debug my ZAP scan GitHub Actions workflow that is failing

Your second pipeline is now live. Next up, you will explore the security findings from both tools and learn how to read the results.

Interpret Your Security Findings

Your two security pipelines have finished running. Both SonarCloud and OWASP ZAP have analyzed your MERN application from different angles and produced real security findings.

The true value of a DevSecOps pipeline is the actionable intelligence it delivers. In this step, you will review findings from both tools and learn to tell the difference between code-level issues and runtime vulnerabilities.

In this step, get ready to:
  • Review your SonarCloud dashboard for static analysis findings.
  • Examine the ZAP-generated GitHub issue for dynamic scan alerts.
  • Download the detailed ZAP HTML report from your workflow run artifacts.
Review your SonarCloud dashboard

SonarCloud performs Static Application Security Testing (SAST). This means it reads your source code without running it, looking for patterns that indicate bugs, vulnerabilities, and poor practices.

  • Return to your SonarCloud dashboard at sonarcloud.io.
  • Click on your project name to open the project overview.
  • Look at the main metrics displayed on the dashboard. You should see categories for Bugs, Vulnerabilities, Security Hotspots, and Code Smells.
  • Click on any category with a count greater than zero to see the specific findings.
  • Select one finding to see the exact file and line number where SonarCloud detected the issue.

What do these categories mean?

Bugs are code errors that will cause incorrect behavior at runtime. Vulnerabilities are security weaknesses an attacker could exploit, like SQL injection or hardcoded credentials.

Security Hotspots are code patterns that need manual review to determine if they are truly insecure. Code Smells are maintainability issues that make code harder to understand or change over time.

Since your MERN app is intentionally vulnerable, you should see multiple findings across these categories. Take note of at least one specific vulnerability or security hotspot that SonarCloud identified.

Not seeing any findings?

Check that the SonarCloud workflow completed successfully in your GitHub Actions tab. A green checkmark means the analysis ran and results were uploaded to SonarCloud.

If the workflow passed but the dashboard shows zero findings, verify that your sonar-project.properties file has the correct organization and project key values matching your SonarCloud project.

Help me troubleshoot my SonarCloud dashboard showing no results

Review the ZAP-generated GitHub issue

OWASP ZAP performs Dynamic Application Security Testing (DAST). Unlike SonarCloud, ZAP actually runs your application and sends requests to it, observing how the server responds. This catches issues that only appear at runtime.

  • Switch to your GitHub repository in your browser.
  • Click the Issues tab at the top of your repository.
  • Find and open the issue created by the ZAP scan. It is titled with the ZAP scan results summary.
  • Read through the list of discovered alerts. Look for categories such as missing security headers, potential XSS, and information disclosure.

What is the difference between SAST and DAST?

SAST (SonarCloud) analyzes your source code directly. It finds problems like hardcoded passwords, SQL injection patterns, and unsafe function calls by reading the code. Think of it as a code reviewer that never runs the app.

DAST (OWASP ZAP) sends real HTTP requests to your running application. It finds problems like missing security headers, reflected XSS, and information leakage by observing how the server actually responds. Think of it as an automated penetration tester.

Using both together gives you coverage from two angles. SAST catches issues in code that might not be reachable yet, while DAST catches issues that only manifest at runtime.

Don't see a ZAP issue in your Issues tab?

Check that the ZAP scan workflow completed successfully in the Actions tab. If it failed, the issue will not be created.

Also verify that the allow_issue_writing: true line is present in your zap-scan.yml file. Without it, ZAP will not create an issue.

Help me figure out why ZAP did not create an issue in my repository

Download the ZAP HTML report

The GitHub issue gives you a summary of findings. ZAP also produces a detailed HTML report with full descriptions of each alert, risk levels, and remediation advice. This report is attached as an artifact to the workflow run.

  • Click the Actions tab in your GitHub repository.
  • Click on the most recent OWASP ZAP Baseline Scan workflow run.
  • Scroll down to the Artifacts section at the bottom of the workflow run summary page.
  • Click the zap_scan artifact to download it.
  • Unzip the downloaded file and open the HTML report in your browser.

The HTML report provides more detail than the GitHub issue. Each alert includes a description, the URL where it was found, the risk level, and suggested solutions.

What types of alerts does ZAP typically find?

A baseline scan runs passive checks only. It observes server responses without actively attacking the application. Common findings include missing security headers (like X-Content-Type-Options or Content-Security-Policy), information disclosure through server banners, and cookie configuration issues.

These findings are different from what SonarCloud reports. ZAP cannot see your source code. It only knows what the running server reveals through its responses.

Don't see the Artifacts section?

Make sure you clicked on the specific workflow run (the individual run entry with the commit message), not just the workflow name in the left sidebar. The artifacts section only appears on the run summary page.

If the workflow run failed before reaching the ZAP scan step, no artifact will be produced. Check the workflow logs for errors in earlier steps like the server startup.

Help me find my ZAP report artifact in GitHub Actions

You now have real security intelligence from two complementary tools. SonarCloud gave you code-level insights without running the app, and ZAP tested how your running server actually behaves. Next up, you will take this pipeline further with a Secret Mission that blocks insecure code from ever reaching your main branch.

Secret mission

Add a Quality Gate to Block Insecure Pull Requests

Your pipeline scans code, but it doesn't stop bad code from merging. In this secret mission, configure a SonarCloud quality gate that automatically blocks pull requests when the code fails security standards.

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely on free services. SonarCloud is free for public repositories, and GitHub Actions is free for public repositories. There are no ongoing costs to worry about.

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

  • SonarCloud project linked to your GitHub repository.
  • GitHub Actions workflows (sonarcloud.yml and zap-scan.yml).
  • GitHub repository secret (SONAR_TOKEN).
  • Branch protection rule on your main branch.
  • ZAP-generated GitHub issue in your repository.
  • sonar-project.properties configuration file.

Keep everything running

No action needed. Choose this if you are still actively building on your MERN application and want continuous security scanning on every push.

  • Both workflows will continue to run automatically on every push to main at no cost.
  • SonarCloud will keep analyzing your code and updating your dashboard.
  • The quality gate will continue enforcing code standards on pull requests.

Pause - I'll come back to this later

Disable the workflows so they stop triggering on every push. Your files and configuration stay intact for when you return.

  • Go to the Actions tab in your GitHub repository.
  • In the left sidebar, click SonarCloud Analysis.
  • Click the dropdown menu (the ... or kebab icon) and select Disable workflow.
  • Repeat for the OWASP ZAP Baseline Scan workflow.

To re-enable later, return to the same workflow in the Actions tab and click Enable workflow.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow each step below.

Delete the workflow files and configuration from your repository:

  • Delete the .github/workflows/sonarcloud.yml file from your repository.
  • Delete the .github/workflows/zap-scan.yml file from your repository.
  • Delete the sonar-project.properties file from the repository root.
  • Commit and push these deletions to your main branch.

Remove the GitHub repository secret:

  • In your repository, go to Settings > Secrets and variables > Actions.
  • Find SONAR_TOKEN and click the trash icon to delete it.

Remove the branch protection rule:

  • In your repository, go to Settings > Branches.
  • Find the protection rule for main and click Delete to remove it.

Close the ZAP-generated issue:

  • Go to the Issues tab in your repository.
  • Find the ZAP scan issue, open it, and click Close issue.

Delete the SonarCloud project:

  • Open your project in SonarCloud.
  • Go to Administration > Deletion.
  • Enter the project name in the confirmation dialog and click Delete.

Nice Work!

Nice Work!

You just built a fully automated DevSecOps pipeline that scans your MERN application for security vulnerabilities every time you push code.

You've learned how to:

  • Written GitHub Actions workflows from scratch, configuring triggers, jobs, steps, and secrets to automate security scanning on every push.
  • Integrated SonarCloud SAST and OWASP ZAP DAST into your CI/CD pipeline, scanning your code from both static and dynamic perspectives.
  • Interpreted real security findings from both tools, understanding the difference between code-level vulnerabilities and runtime security issues.
  • Secret Mission: Configured a quality gate that blocks insecure code from being merged into your main branch.

Ready to quiz yourself?