Five layers of security scanning in 24 hours

Published: February 2026 | Author: Lindsay Smith | Reading time: 6 mins


The debate about AI-generated code has a blind spot. Most people ask whether AI writes secure code. Few talk about AI's ability to detect, manage and remediate insecure code, whoever wrote it.

Yesterday morning, our production application had no automated security scanning. By this morning, we had five layers of continuous vulnerability detection and a baseline report of every finding, and the one production vulnerability was already fixed. The total human effort was a conversation with Claude Code.

This is a story about managing code better.

What we built in 24 hours

We needed security scanning for Sasha, a production Node.js application deployed through Docker to cloud infrastructure. The goal was continuous visibility into vulnerabilities across dependencies, source code, container images and the supply chain.

Five scanners now run nightly:

1. CodeQL: semantic analysis
CodeQL is GitHub's static analysis engine. It builds a complete data-flow model of the codebase and traces tainted input from HTTP requests to file operations, database queries and HTML output. It is the heaviest scanner. A custom query that we wrote lets it recognise our own sanitisation functions. CodeQL catches subtle vulnerabilities that pattern matching misses.

2. OSV Scanner: dependency vulnerabilities (Google)
OSV Scanner checks every lockfile against the Open Source Vulnerabilities database. If a dependency has a known CVE, OSV Scanner finds it. It runs nightly because new vulnerabilities are disclosed constantly. A clean scan today tells you nothing about tomorrow.

3. Trivy: dependency vulnerabilities (Aqua Security)
Trivy is a second dependency scanner with a different vulnerability database. We run two on purpose. The two scanners use different sources, heuristics and detection logic. In security scanning, that overlap gives useful redundancy.

4. Semgrep: pattern-based static analysis
Semgrep runs 543+ community OWASP rules that look for common anti-patterns: path traversal, injection, insecure defaults, missing security headers and shell=true in subprocess calls. It is faster and shallower than CodeQL, and it catches obvious problems that deep analysis can over-think.

5. Dependabot: dependency updates
Dependabot monitors npm packages, GitHub Actions versions and Docker base images. It opens PRs automatically when updates are available. This is the preventive layer. It keeps dependencies current before vulnerabilities are disclosed.

Every scanner uploads results in SARIF format to GitHub's Security tab, so one dashboard shows the findings from all five. An alert opens when a scanner detects an issue and closes when the code is fixed. You do not track findings by hand or in a spreadsheet.

Fixing while scanning

Claude Code then fixed what the scanners found.

The baseline scan found one production vulnerability: axios 1.13.2 had a denial-of-service CVE. In the same conversation in which it set up the scanners, Claude Code identified the CVE, upgraded the dependency, checked that the build still compiled, re-ran the scanner to confirm zero findings and updated the documentation.

It also found that most of the 8,277 Semgrep findings across the full repository were noise. 7,381 of them were missing SRI attributes on generated HTML documentation files, outside the application code. Claude Code excluded the irrelevant directories and configured the scanners to focus on production code.

Here the AI worked as a security engineer. It triaged findings, told false positives from real vulnerabilities, applied fixes, checked that each fix worked and documented the work.

Five layers instead of one

One scanner is not enough.

Each tool sees different problems:

  • CodeQL understands data flow but is slow and needs careful tuning
  • OSV and Trivy use different vulnerability databases, so running both closes gaps
  • Semgrep catches pattern-level issues (like shell=True in Python subprocess calls) that semantic analysers may not flag
  • Dependabot updates dependencies before vulnerabilities are disclosed

A path traversal vulnerability in an Express route might be caught by CodeQL's data-flow analysis, Semgrep's pattern matching, or both. A newly disclosed CVE in a transitive dependency might appear in Trivy's database before OSV's, or vice versa. A Docker base image might ship with a vulnerable system library that no source-code scanner would find.

Defence in depth matters in practice, because no single tool catches everything.

SOC 2

Before AI existed, I led security programmes like this one. I know what this work costs in human time.

Automated vulnerability scanning, exclusion policies, a documented rationale for each suppressed finding, baseline reports, continuous monitoring and operational documentation are a core part of SOC 2 Type II compliance. They address the Common Criteria for system monitoring (CC7.1), risk assessment (CC3.2) and change management (CC8.1).

Without AI, this work requires:

  • A security engineer or consultant who understands both the scanning tools and your specific architecture
  • 2-3 weeks minimum to evaluate, select, and configure scanners
  • Another 2-3 weeks to tune false positives, establish baselines, and write suppression policies
  • Ongoing documentation that auditors can review
  • Regular evidence that scans run and that findings are addressed

That is at least six weeks of expert work. It often takes longer, because the person who configures the scanners seldom knows the application well enough to tune the results without long back-and-forth with the development team.

We did it in 24 hours. The work was the same: the same decisions, the same configurations and the same documentation. The AI that did the work had the full context of the codebase and the architecture, and it could evaluate each finding against the code.

You still need a person who knows what good security looks like. The AI removes the mechanical overhead that made good security expensive.

Insecure AI code

The usual concern is that AI generates insecure code. The concern is fair, because careless use of any tool produces careless results. It misses a larger point.

Before AI, writing secure code required expertise. Setting up security scanning required different expertise. Maintaining those scans required ongoing effort. Remediating findings required yet more expertise. Most teams did not have enough of any of these, so they shipped with no scanning at all.

Their attack surface was the same size. They could not see it.

Now, the same AI that can write code can also:

  • Configure five layers of security scanning in an afternoon
  • Triage thousands of findings and separate real vulnerabilities from noise
  • Fix the real ones immediately
  • Generate the documentation an auditor needs
  • Explain why each exclusion policy exists

Security posture has improved a lot, because the barrier to proper controls has fallen.

You can still write sloppy, insecure code. You can no longer say that you could not afford to check it.

From writing code to managing code

Most teams have not reached this stage yet. AI in software development has focused almost only on generation: write code faster, build features sooner, ship more. The next stage is management, where AI maintains, monitors, secures and operates the code it helped create.

Our setup is plain. Five open-source scanners, configured through GitHub Actions, run on a cron schedule and upload to a standard dashboard. Any competent security engineer could have built the same thing by hand. The difference is time, context and access.

AI can now create a vulnerability and find it. It can add an insecure dependency and upgrade it. It can write the code and the scanner configuration that catches problems in that code. That changes the economics of software security.

Security scanning no longer needs dedicated specialist headcount. Any team can set it up in a day. The scanners are free, and so is the CI platform. You configure and maintain them in a conversation with the AI.

The decision to use it is yours.

Our setup

If your team wants to do the same, this is the setup:

Layer Tool What it does Schedule
Semantic analysis CodeQL Data-flow tracing across JS/TS, C#, Actions Weekly + push/PR
Dependency scan OSV Scanner Google's vulnerability database Nightly
Dependency scan Trivy Aqua Security's vulnerability database Nightly
Static analysis Semgrep 543+ OWASP pattern rules Nightly
Dependency updates Dependabot npm, GitHub Actions, Docker base images Weekly

All results appear in GitHub Security > Code scanning alerts, on one dashboard.

Total cost: zero. Total setup time with Claude Code: one working session.

The six-week security engagement now fits in one afternoon.

made with bernard

Cookie settings