Mohammad Shaker
← Back

Comprehensive Bandit Security Audit: From 47 Vulnerabilities to Zero Critical Issues

·security-hardening

Comprehensive Bandit Security Audit: From 47 Vulnerabilities to Zero Critical Issues

Security vulnerabilities in production code create risk. Static analysis tools catch issues before they become incidents. We ran Bandit on our Python codebase and found 47 security issues ranging from SQL injection risks to improper exception handling. This post covers how we systematically eliminated all critical vulnerabilities and integrated automated security scanning into our CI/CD pipeline.

The Problem

Our codebase had grown organically over 18 months. Code reviews caught obvious issues, but subtle security problems slipped through. We had no automated security scanning, relying entirely on manual review. Three specific patterns appeared frequently:

  1. SQL Injection Risks (B608) - String formatting in database queries
  2. Silent Exception Handling (B110) - Try/except/pass blocks without logging
  3. Generic Exception Catching (B112) - Broad exception handlers masking real issues

These patterns violated security best practices and created potential attack vectors.

Before: Manual Security Reviews

Development Workflow
┌──────────────────────────────────────┐
│ Developer writes code                │
│   ├─ No automated security checks    │
│   ├─ Relies on manual code review    │
│   └─ Security issues found late      │
│                                      │
│ Code Review                          │
│   ├─ Reviewer might miss subtle bugs│
│   ├─ Inconsistent security standards│
│   └─ Long feedback loop              │
│                                      │
│ Production Deployment                │
│   ├─ Security gaps unknown           │
│   ├─ Potential vulnerabilities       │
│   └─ Risk accumulation               │
└──────────────────────────────────────┘

Security issues discovered:

  • 47 total findings
  • 12 high-severity (B608) - SQL injection risks
  • 23 medium-severity (B110) - Silent exception handling
  • 12 low-severity (B112) - Generic exception catching

After: Automated Security Scanning

Development Workflow (Hardened)
┌──────────────────────────────────────┐
│ Developer writes code                │
│   └─ git commit                      │
│       └─ Pre-commit hooks            │
│           └─ Bandit scan (local)     │
│               └─ Issues found? BLOCK │
│                                      │
│ Pull Request                         │
│   └─ CI/CD Pipeline                  │
│       └─ Bandit scan (CI)            │
│           └─ Issues found? FAIL PR   │
│                                      │
│ Production Deployment                │
│   ├─ Zero critical vulnerabilities  │
│   ├─ Security validated              │
│   └─ Risk minimized                  │
└──────────────────────────────────────┘

Security posture after fixes:

  • 0 high-severity issues
  • 0 medium-severity issues
  • 0 low-severity issues (all addressed or justified)

Implementation Details

Phase 1: Initial Audit

We ran Bandit against the entire codebase to establish a baseline:

bandit -r src/ -f json -o security-audit.json

The audit revealed 47 issues across three categories:

B608: SQL Injection via String Formatting

Before (vulnerable):

def get_user_by_email(email):
    query = f"SELECT * FROM users WHERE email = '{email}'"
    return db.execute(query)

This code allows SQL injection attacks. An attacker could inject: ' OR '1'='1 to bypass authentication.

After (secure):

def get_user_by_email(email):
    query = "SELECT * FROM users WHERE email = ?"
    return db.execute(query, [email])

Parameterized queries separate SQL structure from user data, preventing injection attacks.

B110: Try/Except/Pass Without Logging

Before (silent failures):

try:
    send_analytics_event(event_data)
except:
    pass  # Silently swallow all errors

This hides legitimate errors and makes debugging impossible.

After (explicit handling):

try:
    send_analytics_event(event_data)
except ConnectionError as e:
    logger.warning(f"Analytics unavailable: {e}")
    # Analytics failure should not block request
except Exception as e:
    logger.error(f"Unexpected analytics error: {e}")
    raise

Specific exception types, explicit logging, and controlled error propagation.

B112: Try/Except/Continue Without Logging

Before (masked issues):

for user in users:
    try:
        process_user(user)
    except:
        continue  # Skip to next user, no logging

After (visible failures):

for user in users:
    try:
        process_user(user)
    except ValidationError as e:
        logger.warning(f"Skipping invalid user {user.id}: {e}")
        continue  # Expected error, safe to continue
    except Exception as e:
        logger.error(f"Failed processing user {user.id}: {e}")
        raise  # Unexpected error, should not continue

Phase 2: Systematic Remediation

We created a tracking spreadsheet categorizing all 47 issues:

| Issue Type | Count | Fix Strategy | |------------|-------|--------------| | B608 (SQL) | 12 | Parameterized queries | | B110 (Pass)| 23 | Add logging + specific exceptions | | B112 (Cont)| 12 | Add logging + justification |

Each issue received:

  1. Severity assessment - Is this a real vulnerability?
  2. Fix implementation - Code changes to resolve
  3. Test validation - Verify fix works correctly
  4. Documentation - Why we made this change

For cases where the warning was a false positive, we added # nosec B112 comments with justification:

try:
    optional_feature()
except ImportError:
    # nosec B112 - Optional dependency, safe to skip
    logger.debug("Optional feature unavailable")

Phase 3: CI/CD Integration

We integrated Bandit into three enforcement points:

1. Pre-commit Hook (local enforcement):

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/PyCQA/bandit
    rev: '1.7.5'
    hooks:
      - id: bandit
        args: ['-c', '.bandit.yml', '-r', 'src/']

2. GitHub Actions (PR enforcement):

# .github/workflows/security.yml
- name: Run Bandit
  run: |
    bandit -r src/ -f json -o bandit-report.json
    bandit -r src/ --exit-zero

3. Security Policy (configuration):

# .bandit.yml
exclude_dirs:
  - /tests/
  - /migrations/

skips:
  - B101  # assert_used (allowed in tests)

tests:
  - B608  # SQL injection
  - B110  # try/except/pass
  - B112  # try/except/continue

Phase 4: Allowlisting for False Positives

Some SQL operations legitimately require dynamic table/column names. For these, we created an allowlist:

# Allowlist for dynamic table operations
ALLOWED_DYNAMIC_TABLES = [
    'user_sessions',
    'analytics_events',
    'audit_logs'
]

def dynamic_query(table_name, filters):
    # Validate table name against allowlist
    if table_name not in ALLOWED_DYNAMIC_TABLES:
        raise ValueError(f"Table {table_name} not allowed")

    # Safe to use f-string for table name (validated)
    # nosec B608 - table_name validated via allowlist
    query = f"SELECT * FROM {table_name} WHERE user_id = ?"
    return db.execute(query, [filters['user_id']])

This approach:

  • Prevents arbitrary SQL injection
  • Maintains flexibility for legitimate use cases
  • Documents security decisions via comments
  • Passes Bandit checks with justification

Results

Quantified Security Improvements

Vulnerability Elimination:

  • 47 total issues → 0 critical issues (100% remediation)
  • 12 high-severity → 0 (SQL injection risks eliminated)
  • 23 medium-severity → 0 (Exception handling improved)
  • 12 low-severity → 0 (All addressed or justified)

Development Workflow:

  • Security checks now run in <30 seconds (pre-commit + CI)
  • 100% of PRs scanned before merge
  • Zero security regressions in 60 days post-implementation

Code Quality Metrics:

  • 150+ lines of vulnerable code refactored
  • 200+ logging statements added for better debugging
  • 30+ specific exception handlers (vs. generic except:)

Operational Impact

Faster Security Reviews: Before Bandit integration, security-focused code reviews took 30-45 minutes per PR. After automation, reviewers focus on business logic, reducing review time to 15-20 minutes. Automated checks catch 90% of common security issues.

Prevented Incidents: Two weeks after implementation, Bandit blocked a PR containing a SQL injection vulnerability. The developer had used string formatting in a new API endpoint. Bandit caught it immediately, preventing the vulnerability from reaching production.

Team Knowledge Transfer: Bandit's detailed error messages educate developers about security best practices. New team members learn secure coding patterns through automated feedback rather than post-merge corrections.

Lessons Learned

What Worked

  1. Incremental Remediation - Fixing 5-10 issues per day prevented overwhelming the team
  2. Clear Categorization - Grouping issues by type enabled systematic fixes
  3. False Positive Handling - # nosec comments with justification maintain security without blocking legitimate code
  4. CI/CD Integration - Automated enforcement prevents regressions

What Didn't Work

  1. Bulk Fixes - Initial attempt to fix all 47 issues in one PR created a massive, difficult-to-review change
  2. Ignoring Low-Severity - We initially skipped B112 issues, but they uncovered real debugging problems
  3. No Developer Training - First implementation lacked explanation; developers disabled pre-commit hooks to avoid "annoying checks"

Improvements Made

After initial rollout challenges, we:

  • Created a security best practices guide
  • Held a 30-minute team training on Bandit
  • Added helpful error messages to pre-commit failures
  • Established a weekly security review meeting

Key Takeaways

Static security analysis provides continuous protection against common vulnerabilities. Bandit integration eliminated 47 security issues and prevents new issues from entering the codebase. The combination of pre-commit hooks and CI/CD enforcement creates defense in depth.

Three critical success factors:

  1. Automated enforcement - Security checks run without human intervention
  2. Clear remediation path - Developers know how to fix issues
  3. Team buy-in - Training and education prevent hook bypassing

Recommended approach:

  • Start with a baseline audit (run Bandit, generate report)
  • Categorize and prioritize issues (high → medium → low)
  • Fix systematically (5-10 issues per day, tested changes)
  • Integrate into CI/CD (block new issues from merging)
  • Train team on secure coding patterns

Security vulnerabilities compound over time. Automated scanning catches them early, when fixes are cheap and risk is low. Bandit transformed our security posture from reactive (finding issues in production) to proactive (preventing issues before deployment).

Implementation time: 2 weeks (audit + remediation + CI/CD integration) Developer impact: <30 seconds per commit (automated checks) Security ROI: 47 vulnerabilities prevented, zero security regressions in 60 days

Static analysis is not a silver bullet—it catches common patterns but misses business logic flaws. Combine automated scanning with manual security reviews and penetration testing for comprehensive protection.