To set up static code analysis for multi-language source scanning in a CI/CD workflow, the easiest path is to use a tool or platform that supports multiple languages out of the box, then wire it into your pipeline as an automated quality gate.

1) Choose the right tool

Pick based on what you want to detect:

• General code quality + bugs + security: SonarQube / SonarCloud
• Security-focused scanning: Semgrep, CodeQL
• Linting/formatting per language: language-specific linters like flake8, eslint, golangci-lint, pylint, rubocop, etc.
• Dependency and secret scanning: SCA/secret tools like Snyk, Trivy, gitleaks

For true multi-language scanning, common choices are:

• SonarQube/SonarCloud for unified quality analysis
• Semgrep for fast multi-language rule-based scanning
• CodeQL for deep security analysis across multiple languages

2) Define your scanning scope

Decide what will be scanned in each run:

• Source code only
• Tests too
• Generated code excluded
• Vendor/third-party dependencies excluded
• Infrastructure as code included (.tf, YAML, Helm, etc.)

Typical exclusions:

• node_modules/
• vendor/
• dist/, build/
• coverage/
• generated files

3) Add the tool to your repository

Usually this means:

• adding a config file
• defining rulesets
• specifying exclusions
• setting severity thresholds

Examples:

• Semgrep: .semgrep.yml
• SonarQube: sonar-project.properties
• CodeQL: workflow config in .github/workflows/

4) Integrate into CI/CD

Run the scanner on:

• every pull request
• every merge to main branch
• optionally on a nightly schedule

Typical pipeline stages:

1. Checkout code
2. Install dependencies if needed
3. Run static analysis
4. Upload results/artifacts
5. Fail the build on critical findings

5) Enforce quality gates

Set thresholds such as:

• no new critical vulnerabilities
• no high-severity issues on changed code
• maintain code coverage
• limit code smells/duplication

This prevents regressions while allowing legacy issues to be handled separately.

---

Example setup options

Option A: SonarQube in CI

Good when you want a centralized dashboard and quality gates.

Example sonar-project.properties

sonar.projectKey=my-app
sonar.projectName=my-app
sonar.sources=src
sonar.exclusions=**/node_modules/**,**/vendor/**,**/dist/**,**/build/**
sonar.sourceEncoding=UTF-8

Example GitHub Actions step

name: SonarQube Scan

on:
  pull_request:
  push:
    branches: [ main ]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: SonarQube Scan
        uses: SonarSource/sonarqube-scan-action@v2
        with:
          args: >
            -Dsonar.projectKey=my-app
            -Dsonar.host.url=${{ secrets.SONAR_HOST_URL }}
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

Option B: Semgrep for multi-language scanning

Good for fast security and code-pattern analysis.

Example GitHub Actions

name: Semgrep

on:
  pull_request:
  push:
    branches: [ main ]

jobs:
  semgrep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run Semgrep
        uses: semgrep/semgrep-action@v1
        with:
          config: auto

This scans many languages automatically and applies a broad ruleset.

Option C: CodeQL for deep security analysis

Good for GitHub-native security scanning.

Example GitHub Actions

name: CodeQL

on:
  push:
    branches: [ main ]
  pull_request:

jobs:
  analyze:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
      actions: read
      contents: read

    strategy:
      matrix:
        language: [ 'javascript-typescript', 'python', 'java' ]

    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: ${{ matrix.language }}
      - uses: github/codeql-action/autobuild@v3
      - uses: github/codeql-action/analyze@v3

---

6) Make it multi-language friendly

If your repo includes several languages:

• scan each language with the same tool if possible
• otherwise chain multiple linters/scanners in one job
• use a monorepo-aware config to target subdirectories

Example approach:

• Python: ruff or pylint
• JavaScript/TypeScript: eslint
• Go: golangci-lint
• Java: spotbugs or checkstyle
• Multi-language security: Semgrep or CodeQL

7) Report results clearly

Send findings to:

• CI logs
• PR comments
• dashboard (SonarQube/SonarCloud)
• SARIF upload for GitHub Security tab

8) Start with “warn only,” then enforce

A practical rollout:

1. Run scans without failing builds
2. Fix or triage existing issues
3. Set baseline
4. Enforce on new code only
5. Expand rules gradually

---

Recommended baseline architecture

For most teams, a good setup is:

• Semgrep or CodeQL for security scanning
• SonarQube/SonarCloud for code quality
• Language-specific linters for formatting and style
• Run on pull requests
• Fail only on new critical/high issues
• Exclude generated and dependency directories

---

If you tell me:

1. your CI system (GitHub Actions, GitLab CI, Jenkins, Azure DevOps, etc.),
2. your languages,
3. whether you want security, quality, or both,

I can give you a ready-to-paste pipeline config.