Chapter 9.2: Application & Pipeline Security

What it finds:

• **SQL Injection:** db.query("SELECT * FROM users WHERE id = " + user_id)
• **Hardcoded Secrets:** val apiKey = "sk_live_123..."
• **Buffer Overflows:** (In C/C++) strcpy(buffer, user_input)
• **Logical Flaws:** Code that will never be reached (dead code).

Tool 1: GitHub Code Scanning (CodeQL)

If your project is on GitHub, this is the easiest way to start. CodeQL is GitHub's powerful SAST engine.

1. Go to your GitHub repository.
2. Click the **"Security"** tab.
3. Find **"Code scanning"** and click "Set up."
4. GitHub will suggest a workflow file. Just commit it.

This will create a codeql-analysis.yml file in your .github/workflows folder. Now, every time you push, CodeQL will run, and it will report vulnerabilities *directly on your pull request*.

Tool 2: SonarQube (The Industry Standard)

SonarQube is the most popular, comprehensive platform for "static code analysis." It does SAST, but also measures "Code Quality" and "Code Smells" (e.g., duplicated code, overly complex functions).

How it Works:

1. You run a SonarQube server (e.g., in Docker).
2. You add a "SonarScanner" step to your CI pipeline.
3. The scanner analyzes your code and sends the report to your SonarQube server.
4. The server shows a dashboard with a grade (A-F) and a "Quality Gate."
5. You configure your pipeline to *fail* if the Quality Gate (e.t., "no new bugs allowed") is not met.

Example: SonarQube in GitHub Actions

name: Build, Test, and Scan
on: push

jobs:
  sonar-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0 # Needed for SonarQube to analyze branches

      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: '17'
          distribution: 'temurin'

      - name: Analyze with SonarQube
        uses: sonarsource/sonarqube-scan-action@master
        env:
          # These secrets are set in GitHub repo settings
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
          SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}

Part 3: SCA (Software Composition Analysis)

This is arguably the **most important** security scan you can run. **Your code is not just *your* code.** If you're using Node.js, you have 1,000+ dependencies in node_modules. You didn't write them. Are they secure?

SCA tools scan your dependency files (package.json, requirements.txt, pom.xml) and check all your libraries (and *their* dependencies) against a global database of **CVEs (Common Vulnerabilities and Exposures)**.

The `Log4Shell` Example (CVE-2021-44228)

In 2021, a critical vulnerability (Log4Shell) was found in log4j, a very popular Java logging library. Hackers could gain *full control* of a server just by sending a special text message. SCA tools instantly saved millions of companies by:
1. Scanning their code.
2. Reporting: "VULNERABILITY FOUND: You are using log4j 2.14. This is vulnerable. You **must** upgrade to 2.17."

Tool 1: GitHub Dependabot (The "Easy Button")

This is built into GitHub and is the easiest way to do SCA.
Go to **Repo > Settings > Code security and analysis** and enable **Dependabot alerts** and **Dependabot security updates**.

That's it! Now, when a vulnerability is found in one of your dependencies, Dependabot will **automatically create a Pull Request** for you, upgrading the library to the safe version. All you have to do is "Merge".

Tool 2: Snyk (The CI/CD Tool)

Dependabot is great, but it's not a CI check. Snyk is a popular tool that you can run *in* your pipeline to *fail the build* if a new, high-severity vulnerability is found.

  security-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        
      - name: Install Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '18'
          
      - name: Install Snyk
        run: npm install -g snyk
        
      - name: Run Snyk to check for vulnerabilities
        run: snyk test --fail-on=high
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

Part 4: Container & Image Scanning

Okay, we've scanned our source code (SAST) and our dependencies (SCA). We're safe, right? **No.**
Your Dockerfile starts with FROM node:18-alpine. This alpine OS image itself contains *other* software (like openssl, curl, libc). What if that openssl version is 5 years old and has a critical bug?

A **Container Scanner** analyzes every layer of your *built Docker image* and checks all the OS packages and app dependencies inside it for known CVEs.

Tool: Trivy (The Best Open-Source Tool)

Trivy, by Aqua Security, is the most popular, fastest, and easiest-to-use open-source scanner. You run it in your CI pipeline *after* you build your image but *before* you push it to a registry.

Example: Trivy in GitHub Actions

name: Build, Scan, and Push Docker Image
on: push

jobs:
  build-and-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Build the Docker image
        run: docker build -t my-app:latest .
        
      - name: Install Trivy
        uses: aquasecurity/trivy-action@v0.12.0
        with:
          scan-type: 'image'
          image-ref: 'my-app:latest'
          format: 'table'
          # Fail the build if any CRITICAL vulnerabilities are found
          exit-code: '1'
          severity: 'CRITICAL'
          
      - name: Log in to GHCR
        # ... (This step only runs if Trivy passes) ...
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.repository_owner }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Push the clean image
        run: docker push ghcr.io/${{ github.repository_owner }}/my-app:latest

Part 5: DAST (Dynamic Application Security Testing)

**What is DAST?** This is "black-box" testing. DAST tools don't know your source code. They act like a *real hacker* and attack your *live, running application* (on a staging server) from the outside.

They will "crawl" your website and then try to inject malicious payloads into every input field, form, and URL parameter to find vulnerabilities.

What it finds:

• Cross-Site Scripting (XSS):** Can it inject a <script>alert(1)</script> tag?
• **SQL Injection:** Can it send ' OR 1=1; -- in the login form?
• **Insecure Headers:** Is your server missing key security headers like Content-Security-Policy?

  dast-scan:
    runs-on: ubuntu-latest
    needs: deploy-to-staging # Wait for deployment to finish
    
    steps:
      - name: Run ZAP Baseline Scan
        uses: actions/zap-scan@v0.0.19
        with:
          # The URL of your live staging app
          target: 'https://staging.codewithmsmaxpro.me'
          docker_name: 'owasp/zap2docker-stable'
          # This will fail the build if ZAP finds any high-risk issues
          fail_action: true

  secret-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0 # Fetch all history for scanning
          
      - name: Run Gitleaks
        uses: gitleaks/gitleaks-action@v2
        env:
          # This token is needed to report back to the PR
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}