Part 5 : Security in the Commit Phase: Making CI/CD Smarter, Not Slower

When a developer pushes code, it kicks off the Commit phase of the DevOps pipeline. This is where the magic of automation happens: builds, tests, scans, and packaging all before the code goes anywhere near production.

But here’s the trick: we need to build security into this phase—without slowing developers down.

What Security Checks Fit Here?

Think of the Commit phase as speed security. We don’t have hours; we have minutes. So our checks need to be lightweight but effective:

1. Unit Tests → Catch coding mistakes immediately.

2. Incremental SAST (Static Analysis Security Testing) → Scan only the code that changed.

3. Lightweight Linting & Style Checks → Make code easier to review and maintain.

If all tests pass, we sign the build and store it in a secure artifact repository. This guarantees that what gets deployed later hasn’t been tampered with.

--------------------------------------------------------------------------------------------------------

The Goal of SAST in CI/CD

Here’s the important mindset shift:

• Traditional SAST tries to find all the vulnerabilities in the codebase. That’s slow and overwhelming.

• Modern SAST in CI/CD focuses on catching new vulnerabilities introduced by the latest changes.

This way, developers get feedback right away and can fix issues before moving on.

--------------------------------------------------------------------------------------------------------

Deep vs. Incremental Scanning

Not all scans are created equal:

• Full scans → Take hours or even days. Perfect for scheduled jobs (nightly, weekly).

• Incremental scans → Only look at the code that changed. Perfect for CI/CD, fast feedback in a few minutes.

--------------------------------------------------------------------------------------------------------

Tuning Scanners: Take the Hit for the Team

Static analyzers are notorious for false positives. If every scan blocks developers with noise, the pipeline will get ignored—or worse, bypassed.

That’s why the security team must “take the false positive hit.”

• Tune scanners to focus on high-risk, high-confidence findings.

• Store configuration in version control so changes are audited.

• Work with engineers to agree on what’s important enough to block the pipeline.

Pro tip: Fail the pipeline if any critical/high findings show up. Save the low-confidence stuff for deeper out-of-band scans.

--------------------------------------------------------------------------------------------------------

Writing Your Own Checkers

Sometimes tools don’t catch everything. That’s where custom checkers come in:

• Simple: grep for dangerous functions or hardcoded secrets.

• Advanced: write custom plugins for SAST tools like PMD or SonarQube.

Examples:

• Flag eval() or exec() in Python.

• Detect insecure crypto functions (like MD5, SHA-1).

• Catch hardcoded AWS keys or passwords.

--------------------------------------------------------------------------------------------------------

Different Tools, Different Strengths

Not all static analysis tools are equal. Here’s a cheat sheet:

• Coding style tools → Checkstyle, PMD, StyleCop, ESLint

  • Not security-focused, but make code easier to read and review.

• Bug pattern detectors → FindBugs, FxCop

  • Improve reliability and catch some security issues.

• Security-focused scanners → Find Security Bugs, Puma Scan, Fortify, SonarQube Security Rules

  • Look for vulnerabilities using data flow, control flow, and taint analysis.

Important: There’s very little overlap between these tools. If you want good coverage, you’ll probably need more than one scanner.

To handle duplicates across multiple tools, use aggregators like:

• OWASP Defect Dojo

• ThreadFix

• Code Dx

--------------------------------------------------------------------------------------------------------

How to Fit This into CI/CD

Here’s a practical Commit phase workflow:

1. Developer pushes code → CI kicks in.

2. Unit tests + lint checks run in parallel.

3. Incremental SAST scan runs in parallel.

4. If time limit breached, send an alert + break scans into smaller chunks.

5. If all checks pass → build is signed & pushed to artifact repo.

6. If critical issues found → block the pipeline until fixed.

Meanwhile, schedule nightly full scans with all checkers enabled. The security team reviews those results, filters out noise, and creates tickets for real issues.

--------------------------------------------------------------------------------------------------------

The Bigger Picture

Security in the Commit phase isn’t about finding everything. It’s about:

• Catching mistakes early

• Giving fast, actionable feedback

• Building security into the team’s Definition of Done

---------------------------------------------Dean--------------------------------------------------