Static Application Security Testing (SAST)

The Hard-Coded API Key That Cost Us 6 Figures

"We've been breached. Someone's been using our AWS account for cryptocurrency mining."

The date: June 3, 2019. The bill: $47,000 for a single weekend. The cause: a hard-coded AWS access key checked into Git... 8 months earlier.

The attacker found it using a simple GitHub search: "aws_access_key_id" filename:config.js. Within minutes, they had launched 200 EC2 GPU instances for crypto mining. Our alerting? Failed to catch it because it happened over a weekend.

The worst part? We had SonarQube running. It had flagged the hard-coded secret. The developer had marked it as "Won't Fix" because "it's just for testing."

That "testing" key had full production access.

This incident taught me three painful lessons:

1. SAST tools are only effective if teams act on findings

2. Security findings need to be unmissable, not buried in dashboards

3. "Won't Fix" should require security team approval

This article documents how we transformed SAST from a checkbox tool that generated noise into a critical security gate that developers actually trust and use.

What You'll Learn

• Setting up effective SAST scanning

• Integrating SAST into CI/CD pipelines

• Tuning rules to reduce false positives

• Managing and prioritizing findings

• GitLab + SonarQube integration

• Making SAST findings actionable

What is SAST?

Static Application Security Testing analyzes source code for security vulnerabilities without executing it.

SAST Overview:

  How It Works:
    - Parses source code into Abstract Syntax Tree (AST)
    - Analyzes code flow and data flow
    - Identifies patterns matching vulnerability signatures
    - Reports potential security issues
  
  What It Finds:
    - SQL Injection
    - Cross-Site Scripting (XSS)
    - Hard-coded secrets
    - Path traversal
    - Insecure deserialization
    - XML External Entity (XXE)
    - Server-Side Request Forgery (SSRF)
    - Cryptographic issues
  
  What It Doesn't Find:
    - Runtime vulnerabilities (use DAST)
    - Configuration issues (use IaC scanning)
    - Dependency vulnerabilities (use SCA)
    - Business logic flaws (use manual review)
  
  When to Run:
    - On every commit (fast scans)
    - On merge requests (comprehensive)
    - Nightly (full project scan)
    - Before deployments

SAST vs Other Security Testing

Key Difference: SAST finds potential vulnerabilities in code structure; DAST finds actual vulnerabilities in running applications.

Setting Up SAST: GitLab + SonarQube

We use two layers of SAST:

1. GitLab SAST - Fast, integrated, baseline scanning

2. SonarQube - Deep analysis, quality gates, historical tracking

GitLab SAST Setup

GitLab provides built-in SAST scanning using industry-standard analyzers.

1. Enable GitLab SAST

# .gitlab-ci.yml
include:
  - template: Security/SAST.gitlab-ci.yml

variables:
  SAST_EXCLUDED_PATHS: "test/, spec/, node_modules/, vendor/"
  SAST_ANALYZER_IMAGE_TAG: "3"  # Pin version for consistency
  SCAN_KUBERNETES_MANIFESTS: "true"

# Customize SAST job
sast:
  stage: security-scan
  variables:
    SEARCH_MAX_DEPTH: 20  # How deep to search for files
  artifacts:
    reports:
      sast: gl-sast-report.json
    expire_in: 1 week
  allow_failure: false  # Block on SAST failures
  rules:
    - if: $CI_COMMIT_BRANCH
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

GitLab automatically selects analyzers based on languages detected:

Language	Analyzer	What It Finds
JavaScript/TypeScript	Semgrep, ESLint	XSS, prototype pollution, insecure crypto
Python	Bandit, Semgrep	SQL injection, command injection, hardcoded secrets
Java	SpotBugs, Semgrep	OWASP Top 10, insecure deserialization
Go	Gosec, Semgrep	SQL injection, hardcoded credentials
C#	Security Code Scan	OWASP Top 10, .NET specific vulns

2. View Results in Merge Requests

Findings appear automatically in MR security widget:

Security Scanning Results
-------------------------
🔴 2 Critical
🟠 5 High
🟡 8 Medium

SQL Injection Vulnerability
  File: src/api/users.ts:45
  Severity: Critical
  Description: User input directly concatenated into SQL query
  
  Vulnerable Code:
    const query = `SELECT * FROM users WHERE id = ${req.params.id}`;
  
  Fix:
    Use parameterized queries:
    const query = 'SELECT * FROM users WHERE id = ?';
    db.query(query, [req.params.id]);

Developers see security findings where they review code, not in separate dashboards.

SonarQube Setup

SonarQube provides deeper analysis with quality gates and historical tracking.

1. Deploy SonarQube

# docker-compose.yml
version: '3.8'

services:
  sonarqube:
    image: sonarqube:9.9-community
    container_name: sonarqube
    ports:
      - "9000:9000"
    environment:
      - SONAR_JDBC_URL=jdbc:postgresql://postgres:5432/sonar
      - SONAR_JDBC_USERNAME=sonar
      - SONAR_JDBC_PASSWORD=${SONAR_DB_PASSWORD}
    volumes:
      - sonarqube_data:/opt/sonarqube/data
      - sonarqube_logs:/opt/sonarqube/logs
      - sonarqube_extensions:/opt/sonarqube/extensions
    depends_on:
      - postgres
    networks:
      - sonarnet

  postgres:
    image: postgres:14-alpine
    container_name: sonar-postgres
    environment:
      - POSTGRES_USER=sonar
      - POSTGRES_PASSWORD=${SONAR_DB_PASSWORD}
      - POSTGRES_DB=sonar
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - sonarnet

volumes:
  sonarqube_data:
  sonarqube_logs:
  sonarqube_extensions:
  postgres_data:

networks:
  sonarnet:
    driver: bridge

Start SonarQube:

# Start SonarQube
docker-compose up -d

# Wait for startup (takes ~2 minutes)
docker-compose logs -f sonarqube

# Access at http://localhost:9000
# Default credentials: admin/admin

2. Configure Quality Gate

Quality gates define pass/fail criteria for your code:

# SonarQube Quality Gate: "DevSecOps"

Conditions:
  
  Security:
    - Vulnerability (Critical): 0 allowed
    - Vulnerability (High): 0 allowed
    - Vulnerability (Medium): < 5 allowed
    - Security Hotspots Reviewed: > 80%
  
  Maintainability:
    - Code Smells: < 50
    - Technical Debt: < 30 minutes
    - Duplicated Lines: < 3%
  
  Reliability:
    - Bugs: < 10
    - Bug (Critical): 0 allowed
  
  Coverage:
    - Code Coverage: > 70%
    - New Code Coverage: > 80%

3. GitLab Integration

# .gitlab-ci.yml
sonarqube-scan:
  stage: security-scan
  image: sonarsource/sonar-scanner-cli:latest
  variables:
    SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"
    GIT_DEPTH: "0"  # Full clone for accurate blame info
  cache:
    key: "${CI_JOB_NAME}"
    paths:
      - .sonar/cache
  script:
    - sonar-scanner
      -Dsonar.projectKey=${CI_PROJECT_NAME}
      -Dsonar.projectName="${CI_PROJECT_TITLE}"
      -Dsonar.sources=src
      -Dsonar.tests=test
      -Dsonar.host.url=${SONAR_HOST_URL}
      -Dsonar.login=${SONAR_TOKEN}
      -Dsonar.qualitygate.wait=true
      -Dsonar.qualitygate.timeout=300
      -Dsonar.javascript.lcov.reportPaths=coverage/lcov.info
      -Dsonar.typescript.lcov.reportPaths=coverage/lcov.info
      -Dsonar.exclusions=**/*.test.ts,**/*.spec.ts,node_modules/**
  allow_failure: false  # Block if quality gate fails
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

Add SonarQube token to GitLab CI/CD variables:

# Generate token in SonarQube UI
# Settings → Security → Users → Generate Token

# Add to GitLab
# Project Settings → CI/CD → Variables
SONAR_HOST_URL = https://sonarqube.example.com
SONAR_TOKEN = <your_token>

Real Vulnerability Examples

Example 1: Hard-Coded Secrets (The $47K Lesson)

Vulnerable Code:

// src/config/aws.config.ts
export const awsConfig = {
  accessKeyId: 'AKIAIOSFODNN7EXAMPLE',  // ❌ Hard-coded!
  secretAccessKey: 'wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY',  // ❌ Hard-coded!
  region: 'us-east-1'
};

SonarQube Finding:

Security Hotspot: Hard-coded credentials

Severity: Critical
File: src/config/aws.config.ts:3
Rule: typescript:S6290

AWS credentials should not be hard-coded. 
Hard-coded credentials can be easily discovered in source control 
and used by attackers to access your AWS resources.

Impact: CRITICAL - Full AWS account compromise

Fix:
  Use environment variables or AWS IAM roles instead.

Fixed Code:

// src/config/aws.config.ts
import { fromEnv } from '@aws-sdk/credential-providers';

export const awsConfig = {
  credentials: fromEnv(),  // ✅ Loads from AWS_ACCESS_KEY_ID env var
  region: process.env.AWS_REGION || 'us-east-1'
};

// For ECS/EKS, use IAM roles (no credentials needed)
// The SDK automatically uses the instance/pod IAM role

Example 2: SQL Injection

Vulnerable Code:

// src/api/users.controller.ts
export async function getUserById(req: Request, res: Response) {
  const { id } = req.params;
  
  // ❌ VULNERABLE: User input directly in query
  const query = `SELECT * FROM users WHERE id = ${id}`;
  const users = await db.query(query);
  
  res.json(users[0]);
}

Attack Vector:

# Normal request
GET /api/users/123

# SQL Injection attack
GET /api/users/1%20OR%201=1--

# Executed query:
SELECT * FROM users WHERE id = 1 OR 1=1--
# Returns ALL users!

SonarQube Finding:

Vulnerability: SQL Injection

Severity: Critical
File: src/api/users.controller.ts:12
Rule: typescript:S2077

User input from req.params.id is used directly in SQL query 
without sanitization, enabling SQL injection attacks.

CWE-89: Improper Neutralization of Special Elements used in SQL Command

Exploit scenario:
  GET /api/users/1%20OR%201=1--
  Attacker can read, modify, or delete any database records.

Fixed Code:

// src/api/users.controller.ts
import { query } from './db';

export async function getUserById(req: Request, res: Response) {
  const { id } = req.params;
  
  // ✅ SAFE: Parameterized query
  const users = await query(
    'SELECT * FROM users WHERE id = ?',
    [id]  // Parameters automatically escaped
  );
  
  if (users.length === 0) {
    return res.status(404).json({ error: 'User not found' });
  }
  
  res.json(users[0]);
}

Example 3: Path Traversal

Vulnerable Code:

// src/api/files.controller.ts
import * as fs from 'fs';
import * as path from 'path';

export async function downloadFile(req: Request, res: Response) {
  const { filename } = req.params;
  
  // ❌ VULNERABLE: No path sanitization
  const filePath = path.join('/uploads', filename);
  const content = fs.readFileSync(filePath);
  
  res.send(content);
}

Attack Vector:

# Normal request
GET /api/files/document.pdf

# Path traversal attack
GET /api/files/../../etc/passwd

# Resolved path:
/uploads/../../etc/passwd = /etc/passwd
# Attacker can read ANY file on the server!

SonarQube Finding:

Vulnerability: Path Traversal

Severity: High
File: src/api/files.controller.ts:8
Rule: typescript:S5131

User input (filename) used to construct file path without validation.
Attacker can use "../" sequences to access files outside intended directory.

CWE-22: Improper Limitation of a Pathname to a Restricted Directory

Fixed Code:

// src/api/files.controller.ts
import * as fs from 'fs';
import * as path from 'path';

const UPLOAD_DIR = '/uploads';

export async function downloadFile(req: Request, res: Response) {
  const { filename } = req.params;
  
  // ✅ Sanitize filename
  const safeFilename = path.basename(filename);  // Removes path components
  
  // ✅ Resolve absolute path
  const filePath = path.resolve(UPLOAD_DIR, safeFilename);
  
  // ✅ Verify file is within allowed directory
  if (!filePath.startsWith(UPLOAD_DIR)) {
    return res.status(403).json({ error: 'Access denied' });
  }
  
  // ✅ Check file exists before reading
  if (!fs.existsSync(filePath)) {
    return res.status(404).json({ error: 'File not found' });
  }
  
  const content = fs.readFileSync(filePath);
  res.send(content);
}

Example 4: Insecure Cryptography

Vulnerable Code:

// src/utils/encryption.ts
import * as crypto from 'crypto';

// ❌ VULNERABLE: MD5 is cryptographically broken
export function hashPassword(password: string): string {
  return crypto.createHash('md5').update(password).digest('hex');
}

// ❌ VULNERABLE: Weak encryption
export function encryptData(data: string): string {
  const cipher = crypto.createCipher('des', 'weak-key');  // DES is broken
  return cipher.update(data, 'utf8', 'hex') + cipher.final('hex');
}

SonarQube Findings:

Vulnerability: Weak hashing algorithm

Severity: High
Rule: typescript:S4790

MD5 is cryptographically broken and should not be used for password hashing.
MD5 collisions can be generated in seconds on modern hardware.

Fix: Use bcrypt, scrypt, or argon2 for password hashing.

---

Vulnerability: Weak encryption algorithm

Severity: High  
Rule: typescript:S5547

DES encryption is insecure and easily broken.
DES uses 56-bit keys which can be brute-forced.

Fix: Use AES-256-GCM for symmetric encryption.

Fixed Code:

// src/utils/encryption.ts
import * as bcrypt from 'bcrypt';
import * as crypto from 'crypto';

// ✅ SECURE: bcrypt with proper cost factor
export async function hashPassword(password: string): Promise<string> {
  const saltRounds = 12;  // 2^12 iterations
  return await bcrypt.hash(password, saltRounds);
}

export async function verifyPassword(password: string, hash: string): Promise<boolean> {
  return await bcrypt.compare(password, hash);
}

// ✅ SECURE: AES-256-GCM encryption
export function encryptData(data: string): string {
  const algorithm = 'aes-256-gcm';
  const key = crypto.scryptSync(process.env.ENCRYPTION_KEY!, 'salt', 32);
  const iv = crypto.randomBytes(16);
  
  const cipher = crypto.createCipheriv(algorithm, key, iv);
  const encrypted = Buffer.concat([
    cipher.update(data, 'utf8'),
    cipher.final()
  ]);
  
  const authTag = cipher.getAuthTag();
  
  // Return: iv + authTag + encrypted (all base64)
  return Buffer.concat([iv, authTag, encrypted]).toString('base64');
}

export function decryptData(encryptedData: string): string {
  const algorithm = 'aes-256-gcm';
  const key = crypto.scryptSync(process.env.ENCRYPTION_KEY!, 'salt', 32);
  
  const buffer = Buffer.from(encryptedData, 'base64');
  const iv = buffer.slice(0, 16);
  const authTag = buffer.slice(16, 32);
  const encrypted = buffer.slice(32);
  
  const decipher = crypto.createDecipheriv(algorithm, key, iv);
  decipher.setAuthTag(authTag);
  
  return decipher.update(encrypted) + decipher.final('utf8');
}

Managing SAST Findings

Prioritization Strategy

Not all findings are equally important. Our priority matrix:

Priority Levels:

  P0 - CRITICAL (Fix Immediately):
    - Hard-coded secrets in production code
    - SQL injection in authentication/payment flows
    - Command injection
    - Path traversal with file system access
    - Insecure deserialization
    SLA: 24 hours
  
  P1 - HIGH (Fix This Sprint):
    - XSS in user-facing features
    - Weak cryptography for sensitive data
    - Authorization bypass
    - SSRF vulnerabilities
    SLA: 1 week
  
  P2 - MEDIUM (Fix This Quarter):
    - XSS in admin panels (limited exposure)
    - Information disclosure (non-sensitive)
    - Deprecated crypto in non-critical paths
    SLA: 1 month
  
  P3 - LOW (Backlog):
    - Code quality issues
    - Minor security hotspots
    - False positives (after security review)
    SLA: Best effort

False Positive Management

Process for marking false positives:

False Positive Process:

  1. Developer Review:
    - Developer identifies potential false positive
    - Documents why it's false positive in SonarQube
  
  2. Security Review:
    - Security team validates claim
    - Requires:
      * Technical justification
      * Proof it's not exploitable
      * Documentation of compensating controls
  
  3. Approval:
    - Security team marks as "Won't Fix" or "False Positive"
    - Adds detailed comment for audit trail
    - Sets review date (quarterly)
  
  4. Periodic Review:
    - Quarterly review of all suppressions
    - Remove outdated suppressions
    - Re-evaluate with new context

SonarQube Suppression Example:

// src/api/admin.controller.ts

// NOSONAR - False positive justification:
// This endpoint is only accessible by admins with 2FA
// Input is validated by Joi schema before this function
// Compensating control: WAF rate limiting
export async function executeAdminCommand(req: Request, res: Response) {
  const { command } = req.body;
  // ... implementation
}

Baseline and Track Progress

Establish a baseline and track improvements:

# Initial scan (Oct 2019, post-breach)
Total Vulnerabilities: 342
  Critical: 47 (including the hard-coded AWS key)
  High: 128
  Medium: 167

# After 3 months (Jan 2020)
Total Vulnerabilities: 89
  Critical: 0  ✅
  High: 12
  Medium: 77

# After 6 months (Apr 2020)
Total Vulnerabilities: 23
  Critical: 0  ✅
  High: 0   ✅
  Medium: 23

# Current (Nov 2023)
Total Vulnerabilities: 5
  Critical: 0  ✅
  High: 0   ✅
  Medium: 5

IDE Integration: Shift Further Left

Catch issues before committing:

SonarLint for VS Code

# Install SonarLint extension
code --install-extension SonarSource.sonarlint-vscode

Configure connected mode to sync with SonarQube:

// .vscode/settings.json
{
  "sonarlint.connectedMode.project": {
    "projectKey": "my-project"
  },
  "sonarlint.connectedMode.servers": [
    {
      "serverId": "sonarqube",
      "serverUrl": "https://sonarqube.example.com",
      "token": "${env:SONAR_TOKEN}"
    }
  ]
}

Developers see security issues as they type, not in CI/CD.

Performance Optimization

SAST scans can be slow. Our optimizations:

1. Incremental Scanning

Scan only changed files in MRs:

sonarqube-scan:
  script:
    - |
      if [ "$CI_PIPELINE_SOURCE" == "merge_request_event" ]; then
        # Incremental scan for MRs (faster)
        sonar-scanner \
          -Dsonar.pullrequest.key=$CI_MERGE_REQUEST_IID \
          -Dsonar.pullrequest.branch=$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME \
          -Dsonar.pullrequest.base=$CI_MERGE_REQUEST_TARGET_BRANCH_NAME
      else
        # Full scan for main branch
        sonar-scanner
      fi

Result:

• Full scan: 8 minutes

• Incremental scan: 2 minutes (only changed files)

2. Parallel Analysis

Run multiple analyzers in parallel:

sast:
  parallel:
    matrix:
      - SAST_ANALYZER: [semgrep, eslint, bandit]

3. Caching

Cache SonarQube analysis cache:

sonarqube-scan:
  cache:
    key: "${CI_JOB_NAME}"
    paths:
      - .sonar/cache

Real Results

Metrics (2019 → 2023)

Before SAST (2018-2019):
  Security Incidents: 12 per year
  Hard-coded secrets in production: 47
  SQL injection vulnerabilities: 23
  Average time to find vulnerability: 3 months (in production)
  Cost per incident: $15K - $2.4M

After SAST (2020-2023):
  Security Incidents: 2 per year (not code-level)
  Hard-coded secrets in production: 0  ✅
  SQL injection vulnerabilities: 0  ✅
  Average time to find vulnerability: 5 minutes (in CI/CD)
  Cost per incident: $0 (prevented)

ROI:
  SAST tooling cost: $12K/year (SonarQube Enterprise)
  Prevented incidents: ~$500K/year
  ROI: 4,000%

Developer Feedback

Before SAST:

"Security team tells us about vulnerabilities 3 months after deployment. By then the code is in 20 microservices."

After SAST:

"I see security issues in my IDE as I code. Fixing them immediately is easy. I've become a better developer."

Key Takeaways

✅ SAST finds vulnerabilities in code before they reach production ✅ GitLab + SonarQube provides comprehensive SAST coverage ✅ Block on critical findings - don't allow security debt ✅ IDE integration (SonarLint) catches issues before commit ✅ Prioritize findings - not all issues are equally urgent ✅ False positive process essential for developer trust ✅ Hard-coded secrets are the easiest and costliest to exploit

What's Next

SAST finds vulnerabilities in source code. But what about vulnerabilities that only appear when code is running? The next article covers DAST (Dynamic Application Security Testing)—testing running applications for security issues.

---

Next Article: Dynamic Application Security Testing (DAST) →

---

Part of the DevSecOps 101 Series