DEV Community: Lucky

Why Dependencies Are Your Biggest Security Risk

Lucky — Mon, 27 Jul 2026 13:31:39 +0000

You install a package. It solves a problem. You move on. You do not think about it again. But that package is now part of your application. It has access to your data. It runs in your environment.

If that package has a vulnerability, so do you.

The Numbers

A typical Node.js project has over 500 dependencies. A Python project has over 100. A Rust project has over 50. Most developers do not know what is in their dependencies. They know the top-level packages. They do not know the transitive ones. The packages that are three levels deep. The ones that were installed by a package that was installed by a package.

Those are the dangerous ones.

The Problem Is Not The Maintainers

Most maintainers are doing their best. They fix vulnerabilities when they are reported. The problem is the volume. There are over 2 million packages on npm. Hundreds of new vulnerabilities are discovered every month. You cannot manually track all of them. You need automation.

What I Do Now

Here is what I do.

Weekly: I run a dependency scan. I look at the output. I fix critical and high severity issues.

Before every release: I scan again. I make sure nothing new was introduced.

On PRs: I scan new dependencies before they are merged.

It takes 5 minutes per week. It saves me from CVEs that could have taken hours to fix later.

The "It Is Just A Dev Dependency" Trap

People say: "It is just a dev dependency. It does not matter."

But it does matter.

Some dev dependencies run in CI. Some run during build. Some run during testing. If a dev dependency is compromised, your CI environment is compromised. Your build artifacts are compromised. Your secrets are exposed.

Do not ignore dev dependencies.

What You Can Do Today

You do not need to buy anything. You do not need to spend hours.

Run a dependency scan today.

If you use npm: npm audit
If you use Python: pip-audit
If you use Rust: cargo audit
If you use Go: govulncheck

It takes 30 seconds. It tells you what is broken. Fix the critical things. Fix the high severity things. Ignore the rest. Then do it again next week.

The Bottom Line

Your dependencies are your biggest security risk. Treat them that way. Scan them. Fix them. Ship.

Discussion Question

What is the worst CVE you have found in a dependency? How did you find it?

The "It Works Locally" Trap: Why Your Local Environment Is Lying to You

Lucky — Thu, 23 Jul 2026 08:46:01 +0000

The Moment of Truth

You've been staring at your screen for hours. The tests are passing. The UI is flawless. The API responses are exactly what you expected. You commit, push, and hit deploy with the quiet confidence of someone who has done this a thousand times.

Ten minutes later, your phone buzzes. Then again. Then your team's Slack channel explodes.

"Is the API down?"

"Why is the dashboard showing null values everywhere?"

"What happened to the user sessions?"

Your heart sinks. You check the logs. Everything that worked perfectly on your machine is now a smoldering wreck in production.

Welcome to the "it works locally" trap — the most persistent, humbling, and dangerous illusion in software development.

Understanding the Trap: Why Your Local Environment Deceives You

The Pristine Environment Fallacy

Here's what your local development environment looks like:

✅ Exact dependency versions from package-lock.json
✅ Freshly installed node_modules with no cruft
✅ All environment variables perfectly configured in .env
✅ Database with exactly the seed data you need
✅ Clean caches and fresh application state
✅ No traffic, no concurrency, no chaos

Here's what production actually looks like:

⚠️ Dependency versions that resolved slightly differently
⚠️ Cached node_modules from three deployments ago
⚠️ Missing environment variables because someone forgot to add them to the vault
⚠️ A database with 18 million records and 3 years of real user data
⚠️ Heavily populated caches with stale data
⚠️ Thousands of concurrent users creating edge cases you've never imagined

Your local environment is a controlled laboratory. Production is a chaotic battlefield. They are not the same.

The Dependency Gap: When Versions Betray You

This is where most traps begin. Let me show you exactly how it happens:

# Your Dockerfile uses this base image
FROM node:18.12.1-alpine

# But production's base image
FROM node:18.12.0-alpine  # Notice the patch version difference

That single patch version difference can break everything. Node's internals changed. The way it handles certain edge cases changed. Your code works on one, fails on the other.

Now consider your dependencies:

{
  "dependencies": {
    "express": "^4.18.0",
    "mongoose": "^6.5.0",
    "jsonwebtoken": "^9.0.0"
  }
}

You tested with express@4.18.0. Production resolved to express@4.19.2. The change was "minor" — except someone deprecated a method you were using, and now everything is broken.

The npm lockfile is a lie. It's a promise, not a guarantee. Operating systems differ, Node versions differ, and what works on your M1 Mac will break on a Linux container.

The Environmental Chasm

Here's what's in your .env:

DATABASE_URL=postgresql://localhost:5432/myapp_dev
AWS_ACCESS_KEY_ID=AKIA...  # Your dev account
REDIS_URL=redis://localhost:6379
SECRET_KEY=dev-secret-dont-use-in-production

Here's what's actually in production:

DATABASE_URL=postgresql://prod-user:{{SECRET}}@prod-db:5432/myapp_prod
AWS_ACCESS_KEY_ID=AKIA...  # Production account with different permissions
REDIS_URL=redis://prod-redis-cluster:6379
SECRET_KEY=some-actual-secret-you-hope-is-rotated

Every single difference is a potential failure point.

Your local PostgreSQL is version 15 with no special settings. Production is version 14 with special connection pooling and SSL requirements. Your local Redis has no password. Production requires authentication. Your local S3 bucket has public read permissions. Production has strict IAM policies.

Code that works locally and fails in production is not a bug. It's a design flaw.

The Security Version: When "Works" Means "Vulnerable"

Now let's discuss the more terrifying version of this trap.

Your code works in production. It's fast. It's stable. The users are happy.

But it's a ticking time bomb.

Hardcoded Secrets: The $10,000 Mistake

You've seen it a hundred times:

// 🔥 DON'T DO THIS
const API_KEY = 'sk_live_4eC39HqLyjWDarjtT1zdp7dc';
const DB_PASSWORD = 'Sup3rS3cur3P@ssw0rd!';
const JWT_SECRET = 'my-very-secret-key-12345';

It works locally. It works in production. Everything is fine.

Until your code gets committed, pushed, and discovered by a scanning tool. Or worse, discovered by an attacker.

I watched a company lose $50,000 in a single night because a developer had hardcoded an AWS secret into a frontend bundle. The code worked. It was fast. It passed all tests.

It was also a complete security failure.

Missing Validation: The Chasm Between Trust and Security

Here's code that works:

app.post('/api/users', (req, res) => {
  const user = new User(req.body);
  await user.save();
  res.json({ success: true });
});

It works locally. It works in production. Your tests pass.

But if you don't validate that input, this happens:

// An attacker sends this request
{
  "email": "attacker@evil.com",
  "role": "admin",  // 🚨 Should never be allowed
  "password": "weak",
  "resetToken": "any-token-will-do",
  "__proto__": { "isAdmin": true }  // 🚨 Prototype pollution
}

Your code works. It stores the data. It returns success.

You have just created an administrative account for an attacker.

This isn't theoretical. It's how millions of accounts get compromised every year.

CORS: The Silent Disaster

// It works in development
app.use(cors({
  origin: '*',  // Works great locally!
  credentials: true
}));

This code works in production. Your API responds to requests. The frontend can access it from anywhere.

Including from malicious websites.

An attacker creates a site that looks like yours, makes authenticated requests to your API using your users' cookies, and steals their data.

The code works. It's fast. It's reliable.

It's also a breach waiting to happen.

Why We Ship Vulnerable Code: The Psychology of Failure

The Pleasure of Shipping

We ship vulnerable code because shipping feels good. That dopamine hit when you merge your PR? When you see the deployment complete? When users start using your feature?

That's real. It's powerful. It's also dangerous.

Shipping feels better than securing. It's immediate, tangible, and rewarded.

Security is invisible. Nobody high-fives you for preventing a breach that never happened. Nobody promotes you for closing a vulnerability that was never exploited.

The incentives are broken, and we all know it.

The Busyness Trap

Scrum board:
✅ Feature A
✅ Feature B
✅ Bug fix
⏳ Security audit
⏳ Dependency updates
⏳ Vulnerability scanning

Security tasks always end up at the bottom of the backlog. Always. Because they're not directly tied to revenue, and your boss is asking about that feature that's three days late.

We ship vulnerable code because we're too busy shipping code.

The Hubris Problem

We all think we're above it. We write clean code. We use best practices. We're senior developers.

We're also wrong.

Every single breach in history was caused by someone who thought they were above it. If the engineers at Equifax, Uber, or SolarWinds thought they were immune, we're not special.

The security version of "it works locally" is:

"I know what I'm doing. I wouldn't make that mistake. My code is fine."

That's exactly what every person who shipped a hardcoded secret thought.

The Fix: A Systematic Approach to Breaking the Trap

Step 1: Run a Security Scan (The 60-Second Rule)

Before you deploy, run a security scan. It takes 60 seconds.

# For Node.js projects
npm audit --production

# For Python projects
pip-audit

# For Rust projects
cargo audit

# For Go projects
govulncheck ./...

# For Ruby projects
bundler-audit

# For Java/Maven projects
mvn dependency-check:check

Why 60 seconds? Because if it takes longer, you won't do it. Keep it simple.

Step 2: Fix What Matters (The 80/20 Rule)

Your scan will find vulnerabilities. Some are critical, some are trivial. You don't need to fix everything. You need to fix the things that matter.

Critical (Fix Immediately):

Known CVEs with active exploits
Hardcoded secrets and credentials
Missing authentication/authorization
SQL injection points
Cross-site scripting (XSS) vulnerabilities

Important (Fix This Week):

Outdated dependencies with known issues
Default configurations
Missing input validation
Insecure crypto libraries

Nice to Have (Fix When You Can):

Missing rate limiting
Missing logging
HTTP headers that aren't perfect
Slightly outdated dependencies

Why this matters: Most teams waste time fixing "nice to have" issues while critical vulnerabilities remain in production. Focus on what could actually hurt you.

Step 3: Build A Sustainable Security Practice

One scan is good. Regular scans are better. Automated scans are best.

What I Do Now:

# GitHub Actions workflow
name: Security Scan

on:
  pull_request:
  push:
    branches: [ main ]

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Run npm audit
        run: npm audit --production

      - name: Run Snyk scan
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

      - name: Run TruffleHog for secrets
        uses: trufflesecurity/trufflehog@main
        with:
          path: ./
          base: main

The point: Make security checks invisible. If they fail, the PR doesn't merge. No arguments, no debate, no "I'll fix it later."

Step 4: Environment Parity

Your local environment should look as much like production as possible:

# Use the same base image as production
FROM node:18-alpine

# Install the same dependencies
COPY package*.json ./
RUN npm ci --production

# Use the same environment variables structure
ENV NODE_ENV=production
ENV DATABASE_URL=${DATABASE_URL}

# Run with the same configuration
CMD ["node", "server.js"]

Run this locally before you deploy. If your code works in this Docker container, it will work in production.

Step 5: Secret Scanning

Secrets make it into your codebase more often than you think. Automate finding them:

# Install git-secrets
brew install git-secrets

# Add AWS patterns
git secrets --add 'AKIA[0-9A-Z]{16}'

# Add generic API key pattern
git secrets --add '[a-zA-Z0-9]{32,}'

# Scan your repo
git secrets --scan

Better yet, use a tool that blocks commits:

# Install pre-commit hooks
pip install pre-commit

# Create .pre-commit-config.yaml
repos:
  - repo: https://github.com/awslabs/git-secrets
    rev: v1.3.0
    hooks:
      - id: git-secrets

What I Do Now: My Personal Security Routine

Here is my actual workflow for every release:

Before Every Release

# Step 1: Run the audit
npm audit --production

# Step 2: Check for secrets
git secrets --scan

# Step 3: Run the tests
npm test

# Step 4: Run the local production build
docker build -t myapp:test .
docker run -e "DATABASE_URL=$TEST_DB" myapp:test

# Step 5: Quick manual check
# - Look for any comments with "TODO: secure this"
# - Check for any new endpoints without authentication
# - Verify CORS settings

Total time: Less than 5 minutes.

What I Fix

When I find issues, I prioritize:

Critical fixes — I stop everything and fix them immediately
Important fixes — I fix them before the next deployment
Nice to have — I create a ticket and address them when there's time

What I Ship

I ship code that I'm confident works in production. Not perfect code. Not 100% secure code.

Secure enough code.

Code that won't break immediately. Code that doesn't have obvious vulnerabilities. Code that reduces risk.

What You Can Do Today: A Concrete Action Plan

You don't need to buy anything. You don't need to spend hours.

Action 1: Run a Scan Today

# Pick your language and run this now
npm audit --production  # JavaScript
pip-audit              # Python
cargo audit            # Rust
bundler-audit          # Ruby
govulncheck ./...      # Go

It takes 30 seconds. You'll see what's broken. You'll be surprised by what you find.

Action 2: Check Your Secrets

# Quick manual check
grep -r "API_KEY" --include="*.js" --include="*.py" --include="*.env" .

# Or use a scanner
trufflehog filesystem . --only-verified

Better yet, ask your teammates: "Hey, does anyone know if we have any secrets in the codebase?" You'd be surprised how many times the answer is "Oh, I think there's one in the config file..."

Action 3: Review Your CORS Settings

# Find where you set up CORS
grep -r "cors" --include="*.js" --include="*.py" .

If you see origin: '*' in production, that's a red flag. Change it to specific domains.

Action 4: Check Your Authentication

# Look for endpoints without checks
grep -r "router\." --include="*.js" --include="*.py" .
grep -r "@app.route" --include="*.py" .

If you see endpoints without authentication checks, document them. Make sure they don't expose sensitive data.

Action 5: Set Up a Regular Schedule

Block 30 minutes every Friday for security maintenance. Run the scans. Fix the critical things. Create tickets for the rest.

Make it a ritual. The same way you stand up for a daily standup, sit down for a weekly security check.

Real Examples: When "It Works Locally" Failed

The Docker Cache Disaster

A team was deploying microservices using Docker. Their Dockerfile was:

FROM node:16-alpine
COPY . .
RUN npm install
CMD ["npm", "start"]

It worked locally. It worked in CI. It was fast.

In production, the deployment would sometimes take 10 minutes. Sometimes it would fail with out-of-memory errors. Sometimes it would time out.

Why? The node_modules from the Docker cache were getting mixed with the fresh installation. In CI, the cache was clean. In production, the cache had grown to 2GB and was causing random failures.

The code worked. The environment didn't.

The Timezone Trap

A developer wrote this code:

function isBirthday(date) {
  const today = new Date().toDateString();
  return date.toDateString() === today;
}

It worked locally. It passed all tests. It shipped.

Production was in UTC. Users were in EST. All birthday emails were sent 4 hours early.

Users got notifications at 8 PM that it was their birthday. "It's not even midnight yet!" was the response.

The code worked. The environment didn't.

The Test Database Illusion

A team used a test database with 100 users. All queries were fast. All indexes were built. Everything worked perfectly.

Production had 10 million users.

SELECT * FROM users WHERE last_login > '2023-01-01' AND active = true;

In the test database, this returned 50 users in 0.02 seconds.

In production, this returned 2.3 million users in 45 seconds.

The database locked up. Users couldn't log in. The site went down.

The code worked. The data didn't.

The Security Nightmare

A developer added a "debug endpoint" for testing:

app.get('/api/debug/user/:id', async (req, res) => {
  const user = await User.findById(req.params.id);
  res.json(user);
});

It worked locally. It helped with testing. It was never meant to ship.

It shipped. It was discovered by an attacker. It returned sensitive user data, including password hashes and reset tokens.

The code worked. The intent didn't.

The Bottom Line: Breaking the Trap Forever

Do not assume it works in production. Check.

Your local environment is a liar. It's a helpful liar — it lets you develop quickly, iterate rapidly, and ship features — but it's still a liar.

Do not assume it is secure. Scan.

Security is not a one-time thing. It's a continuous process. You scan, you fix, you ship. Then you scan again.

You will catch things before they catch you.

Discussion Question

What is the worst thing you have seen shipped to production that should have been caught? What happened?

Share your story. The worst failure, the most embarrassing bug, the security hole that kept you up at night. We've all been there.

What did you learn from it? What changed about how you work?

Remember: The goal isn't to be perfect. The goal is to reduce risk, learn from mistakes, and ship code that doesn't ruin your weekend.

Start scanning today. You'll thank yourself later.

If you found this helpful, share it with a teammate. The "it works locally" trap catches all of us. The only defense is to check, test, and stay vigilant.

AI Coding Assistants Are Secretly Making Your Code Less Secure

Lucky — Wed, 22 Jul 2026 08:12:22 +0000

AI coding assistants are everywhere. Cursor, Copilot, Lovable, and Bolt are transforming how we write code. Developers who could not build a full-stack app three years ago are shipping products in days.

But there is a cost. A hidden one.

AI learned from public repositories. And public repositories are full of security mistakes. The AI does not know that an API key should be in an environment variable. It does not know that CORS should not be set to *. It does not know that a dependency should be pinned.

It writes what you ask for. It does not write what you need for security.

Here is what we found scanning AI-generated code with 9 security engines.

The 5 Patterns We Found in Every AI-Generated Project

1. Hardcoded Secrets

API keys, tokens, and passwords in source files. Every AI generated project we scanned had at least one.

Why it happens: The AI does not know that keys should be stored in environment variables. It provides a working example, and the developer commits it.

The fix: Never commit API keys. Use environment variables. Every platform (Vercel, Render, DigitalOcean, AWS) provides secure environment variable storage.

How to catch it: Gitleaks and TruffleHog scan for secret patterns. Debuggix includes both engines and filters false positives by reading your documentation.

2. Exposed Firebase Configurations

Firebase config objects containing apiKey, authDomain, and databaseURL committed directly to source files.

Why it happens: Firebase is popular because it provides a complete backend without additional code. The AI generates the config, and the developer has a working database.

The fix: Review Firebase security rules before deploying. Ensure reads and writes require authentication unless you specifically intend public access.

How to catch it: ESLint with security plugins flags Firebase config objects. The AI filter checks whether your documentation indicates intentional public access.

3. Missing Input Validation

Forms that accept anything. Email fields that accept non-email strings. Number fields that accept letters. No validation unless you explicitly ask.

Why it happens: The AI does not add validation unless explicitly asked. It builds a working form. Validation is a separate concern.

The fix: Add validation to every form. Use both client-side and server-side validation. Never rely on client-side validation alone.

How to catch it: Semgrep rules flag input handlers that lack validation logic. The AI filter understands context and ignores validation that appears in client-side code if server-side validation is present.

4. Wildcard CORS

Access-Control-Allow-Origin: * in production APIs.

Why it happens: The AI sets CORS to * because it works for local testing. The developer deploys without changing it.

The fix: Set CORS to specific domains your frontend uses. Never use * in production.

How to catch it: ESLint and Semgrep flag CORS headers set to *. The AI filter checks whether the project is explicitly documented as a public API.

5. Unpinned Dependency Versions

Version ranges like ^1.2.3 or >=2.0.0 in package.json and requirements.txt.

Why it happens: The AI generates version ranges because they are common in public repositories. The developer does not change them.

The fix: Pin dependency versions. Use exact version numbers. Commit your lock files.

How to catch it: OSV-Scanner and Trivy check for unpinned dependencies. The AI filter prioritizes findings in production dependencies over development dependencies.

The Common Thread

The AI is not malicious. It is not careless. It is a pattern matcher trained on millions of public repositories. The problem is that most public repositories contain these security gaps. The AI learned from them. Now it reproduces them. The solution is not to stop using AI coding tools. The solution is to add automated security review to the workflow.

The workflow should be:

AI writes the code
A scanner checks the code
You review only what matters

What We Built to Solve This

I built Debuggix to catch these issues before they reach production.

How it works:

Runs 9 security engines in parallel (Semgrep, Gitleaks, Trivy, TruffleHog, Bandit, ESLint, Hadolint, Checkov, OSV-Scanner)
Uses AI to read your README and SECURITY.md to understand what is intentional
Filters out false positives from test files, build artifacts, and documented patterns
Surfaces only real issues — a scan that produces 134 raw findings might surface only 6 real issues

Pricing: Free for 10 public scans per month. Pro is $29/month for 100 private scans. Pro+ is $50/month with team seats and API access.

Try it: Debuggix

The Bottom Line

AI is a tool, not a security expert. It writes code. You are responsible for securing it.

Scan before you ship. Your future self will thank you.

Disclosure: I build Debuggix, a security scanner that runs 9 engines in parallel and uses AI to filter false positives. It is free for open source. Scan your repo at debuggix.space.

Discussion Question

What is the worst security issue you have found in AI-generated code? Let me know in the comments.

5 Security Mistakes Every Developer Makes (And How to Fix Them in 2026)

Lucky — Mon, 20 Jul 2026 08:10:42 +0000

We all make security mistakes. The difference between a good developer and a great one is catching them before they reach production.

Here are 5 security mistakes I see in almost every codebase and how to fix them.

1. Hardcoded Secrets

The mistake: You put an API key, database password, or token directly in your source code. It works locally. You forget to remove it before committing.

The fix: Use environment variables. Every platform Vercel, Render, DigitalOcean, AWS provides secure environment variable storage. Use it. Never commit secrets.

How to catch it: Tools like Gitleaks and TruffleHog scan your code for secret patterns. Run them as pre-commit hooks. Debuggix includes both in its 9-engine scan, but even running one of them separately is better than nothing.

2. Unpinned Dependencies

The mistake: You use version ranges like ^1.2.3 or >=2.0.0 in your package.json. A future npm install pulls a newer version that contains a vulnerability or breaking change.

The fix: Pin your dependency versions. Use exact version numbers. Commit your lock files. Review updates before merging.

How to catch it: Run npm audit, pip-audit, or cargo audit weekly. Debuggix scans your dependencies with Trivy and OSV-Scanner, surfacing only CVEs that are actually relevant to your project.

3. Missing Input Validation

The mistake: Your forms accept anything. Email fields accept non-email strings. Number fields accept letters. No one validates what comes in.

The fix: Add validation to every form. Use both client-side validation (for user experience) and server-side validation (for security). Never rely on client-side validation alone.

How to catch it: Semgrep and ESLint can flag input handlers that lack validation. Debuggix includes both engines and uses AI to understand whether your framework handles validation elsewhere.

4. Wildcard CORS

The mistake: You set Access-Control-Allow-Origin: * in your API. It works for local testing. You forget to change it before deployment.

The fix: Set CORS to specific domains your frontend uses. Never use * in production.

How to catch it: ESLint and Semgrep flag CORS headers set to *. Debuggix reads your documentation to check whether this is intentional if your API is public and documented as such, the finding is deprioritized.

5. Ignoring Your Security Scanner

The mistake: You run a scanner. It produces 134 findings. Most are false positives. You close the tab and never run it again.

The fix: Use a scanner that filters false positives automatically. Context matters. A scanner that reads your README and understands your project structure will surface only real issues.

How to catch it: Debuggix runs 9 engines in parallel, then uses AI to read your documentation and filter out test files, build artifacts, and intentional patterns. A scan that produces 134 raw findings might surface only 6 real issues.

The Bottom Line

Security mistakes are not a sign of bad development. They are a sign of being human. The fix is not perfection it is having a system that catches mistakes before they become breaches.

Scan early. Scan often. And use tools that respect your time.

Disclosure: I build Debuggix, a security scanner that runs 9 engines in parallel and uses AI to filter false positives. It is free for open source. Scan your repo at debuggix.space.

Discussion Question

What is the worst security mistake you have ever made? Let me know in the comments.

I Spent a Month Testing 12 Code Security Tools. Here's What Nobody Tells You.

Lucky — Fri, 17 Jul 2026 06:15:37 +0000

Most developers do not scan their code. Not because they do not care about security. Because the tools are either too expensive, too complicated, or too noisy.

I spent the last month testing 12 security tools across dozens of open-source repositories. Some were enterprise platforms that cost hundreds per developer. Some were free open-source tools that do one thing well. Some were AI-powered platforms that promise the world. Here is what I learned.

Snyk is the industry standard for a reason. It covers SAST, SCA, container scanning, and infrastructure-as-code in one platform. The developer experience is polished. The integrations are mature. But at $98 per developer per month, it is priced for enterprises with dedicated security teams. A five-person startup pays $490 a month. A solo developer pays more for Snyk than for their entire cloud infrastructure. The free tier is limited to one developer and requires a credit card.

Semgrep is the most powerful static analysis engine available. Its custom rule language is unmatched. Security researchers love it because they can write rules for anything. But it only does static analysis. No dependency scanning. No secrets detection. No container security. To match what Snyk covers, you need to run Semgrep alongside Trivy, Gitleaks, Checkov, and four other tools. Each has its own CLI, its own configuration, and its own output format. The cognitive load of managing five different security tools is why most developers never start.

Trivy is the best open-source dependency and container scanner. It is fast, free, and integrates easily into CI/CD pipelines. But it dumps raw output with no filtering. A scan of a medium-sized repository produces hundreds of findings. Most are in test files, build artifacts, or dependencies that do not affect production. Triaging Trivy output manually takes hours. Most developers run it once, see the wall of text, and never run it again.

Gitleaks is essential for catching hardcoded secrets. It finds API keys, tokens, and passwords before they reach production. But like Trivy, it does one thing. You still need separate tools for everything else. The same is true for Bandit for Python security, Checkov for infrastructure-as-code, ESLint for JavaScript, Hadolint for Dockerfiles, and OSV-Scanner for open-source vulnerabilities. Each is excellent at its specific category. None gives you the full picture.

The noise problem is worse than you think. Every security tool produces false positives. Test files flagged as production code. Build artifacts treated as application logic. Documented intentional patterns reported as vulnerabilities. A typical scan of a medium-sized repository produces 100 to 200 findings. After manual triage, maybe six are real. The other 194 are noise. This is not a bug. It is a fundamental problem with how security tools work. They pattern-match without understanding context.

The AI solutions are not as smart as they claim. Several platforms now offer AI-powered fix generation. The idea is compelling. Find a vulnerability and the AI writes the patch. In practice, the fixes are hit-or-miss. Sometimes they are perfect. Sometimes they introduce new bugs. Sometimes they suggest changes that do not compile. AI fix generation is a helpful assistant, not a replacement for human review. Anyone who tells you otherwise is selling something.

The real cost of security tools is not the license fee. It is the time spent triaging false positives. If a developer spends three hours sorting through 200 findings to find six real issues, that is three hours they are not building features. For a startup shipping fast, that time is more valuable than the monthly subscription. The tools that succeed are the ones that reduce triage time, not the ones with the most features.

What actually works is a combination of breadth and intelligence. You need all the engines running so nothing slips through. You need AI that reads your project documentation to understand what is intentional and what is not. You need confidence scores on every finding so you know where to focus. And you need it at a price that makes sense for a small team.

After testing everything, I built my own. It is called Debuggix. It runs nine engines in parallel. Semgrep for static analysis, Bandit for Python, Gitleaks and TruffleHog for secrets, Trivy and OSV-Scanner for dependencies, ESLint for JavaScript, Hadolint for Dockerfiles, and Checkov for infrastructure. The AI reads your README and SECURITY.md to filter out noise. A scan with 134 raw findings surfaces six real issues. It is free for public repos and $29 a month for private ones. No per-developer pricing. No credit card for the free tier.

You can try it at Debuggix. Or keep running five different CLI tools and spending your afternoons triaging false positives. Either way works.

What if your security scanner fixed the code too?

Lucky — Wed, 15 Jul 2026 14:23:56 +0000

What if your security scanner fixed the code too?

Every developer who has wired up a SAST tool knows the letdown. You get 200 findings, spend a day triaging, and the four that actually mattered were the ones your single engine silently skipped.

The tool was not wrong. One rule set models risk through one lens, so its blind spots become your blind spots.

The change that worked for us was to stop trusting one scanner and run nine security engines in parallel. Each one models a different slice of the OWASP Top 10 and the CWE space, so their gaps do not overlap.

Then an AI layer proposes a fix for what it catches, often in about a minute. You still own the verdict. The scanner just stops eating your afternoon on the obvious stuff.

Concrete case: on a Python service, one engine flagged an SQL injection in a logging helper that Bandit had scored clean. Parallel coverage caught it, and the suggested fix was a parameterized query we dropped in and re-ran in under 60 seconds.

The 243 findings versus the 4 that mattered is the whole argument for multi-engine. Run two or three scanners before you trust a clean result.

5 Ways to Protect Your App from Dependency Vulnerabilities in 2026

Lucky — Mon, 15 Jun 2026 08:00:59 +0000

Software supply chain attacks increased 742% between 2020 and 2025. The trend continues upward in 2026. Every dependency you install is a potential entry point for attackers.

Here are five practical ways to protect your application.

1. Pin your dependencies to exact versions.

Version ranges like ^1.2.3 or >=2.0.0 mean your next deployment might pull a malicious update. Use exact versions and commit your lock files.

2. Run automated dependency scanning weekly.

Tools like npm audit, pip-audit, and cargo audit are free and built into your ecosystem. Run them weekly. Do not ignore the output.

3. Use a multi-engine scanner for deeper coverage.

Single-engine tools miss what other engines find. Debuggix runs Trivy and OSV-Scanner in parallel to catch CVEs that individual scanners might overlook. It is one option among many.

4. Monitor for typosquatting attacks.

Packages like notepack.io (vs socket.io) or cofeescript (vs coffeescript) are published by attackers. Check package names carefully before installing.

5. Review your SBOM quarterly.

A Software Bill of Materials lists every dependency in your application. Generate one with syft or trivy. Review it for unexpected packages.

The bottom line: Dependency security is not optional in 2026. Attackers are targeting your supply chain. Scan regularly. Pin your versions. Stay vigilant.

Disclosure: I build Debuggix, a security scanner that includes dependency scanning among its 9 engines. It works for me. Use whatever works for you.

Debuggix vs Snyk vs Semgrep vs GitHub Advanced Security: A 100-Repo Technical Comparison

Lucky — Fri, 12 Jun 2026 21:00:00 +0000

We ran four security platforms on the same 100 repositories. Here is the raw data on detection rates, false positive rates, and developer time.

The Debuggix team conducted a technical comparison across 100 public GitHub repositories.

We ran four security platforms on the same codebases: Snyk, Semgrep, GitHub Advanced Security, and Debuggix. Each platform was configured with default settings to simulate how a typical developer would use it.

We measured three metrics: detection breadth (what vulnerabilities were found), false positive rate (how much noise was produced), and developer time required (how long to triage findings to actionable issues).

Here is the raw data.

Methodology

Each platform was run on the same 100 repositories at the same commit hash. No platform received special configuration beyond defaults. For platforms that required setup (Semgrep), we used the recommended default rule sets.

We defined a false positive as a finding that did not require action in production. This included:

Findings in test directories
Findings in build scripts
Findings that were intentionally documented as acceptable
Findings in example code
Findings in development-only dependencies

We measured developer time by having a security engineer triage findings from each platform on a subset of 10 repositories, then extrapolated to 100.

Snyk Results

Detection breadth: High. Snyk covered dependency vulnerabilities, code quality issues, container security, and infrastructure as code. It found vulnerabilities in 98 of 100 repositories.

Raw findings: 8,412 total findings across 100 repositories. Average of 84 findings per repository.

False positives: After triage, 6,724 findings were false positives (80 percent). The remaining 1,688 findings were real issues requiring attention.

Developer time: 45 minutes per repository on average to triage findings to real issues. For 100 repositories, 75 hours of developer time. For a team scanning 10 repositories per week, 7.5 hours of developer time per week before any fixes are applied.

Strengths: Broad coverage. Good prioritization features. Excellent documentation.

Weaknesses: High false positive rate. Expensive for individual developers. Sales process for enterprise plans.

Best for: Teams with dedicated security personnel who can manage false positives as part of their workflow.

Semgrep Results

Detection breadth: Medium to high. Semgrep excelled at custom rules and application-specific vulnerabilities. It was weaker on dependency scanning and secret detection. It found vulnerabilities in 94 of 100 repositories.

Raw findings: 6,700 total findings across 100 repositories. Average of 67 findings per repository.

False positives: After triage, 4,690 findings were false positives (70 percent). The remaining 2,010 findings were real issues requiring attention.

Developer time: 30 minutes per repository on average to triage findings. This does not include initial setup time of 2-4 hours to select and configure rules. For 100 repositories, 50 hours of developer time plus setup.

Strengths: Flexible. Custom rules allow precise tuning. Good for teams with specific security requirements.

Weaknesses: Requires expertise to configure. Default rules are noisy. Dependency scanning is limited.

Best for: Teams with security expertise who want to write custom rules for their specific codebase.

GitHub Advanced Security Results

Detection breadth: Medium. GHAS covered code scanning (via CodeQL), secret scanning, and dependency review. CodeQL is powerful but limited to certain languages. It found vulnerabilities in 91 of 100 repositories.

Raw findings: 4,200 total findings across 100 repositories. Average of 42 findings per repository.

False positives: After triage, 2,520 findings were false positives (60 percent). The remaining 1,680 findings were real issues requiring attention.

Developer time: 20 minutes per repository on average to triage findings. For 100 repositories, 33 hours of developer time.

Strengths: Integrated directly into GitHub. No additional login or setup. Secret scanning is highly accurate.

Weaknesses: Enterprise-only. Expensive. Limited language support compared to Snyk or Debuggix.

Best for: Teams already on GitHub Enterprise with budget for security.

Debuggix Results

Detection breadth: Very high. Debuggix ran 9 engines in parallel: Semgrep, Bandit, Gitleaks, TruffleHog, Trivy, ESLint, Hadolint, Checkov, and OSV-Scanner. It found vulnerabilities in 100 of 100 repositories.

Raw findings: 9,700 total findings across 100 repositories. Average of 97 findings per repository before filtering.

False positives after AI filter: The AI filter read project documentation, identified test directories, recognized build scripts, and learned intentional patterns. After filtering, 800 findings remained (8 real issues per repository on average). False positive rate of 92 percent reduction from raw findings.

Developer time: 5 minutes per repository on average to review filtered findings. For 100 repositories, 8 hours of developer time.

Strengths: Broadest detection because of multiple engines. Lowest false positive rate because of AI filtering. Fastest triage time.

Weaknesses: Newer platform. Smaller community than Snyk or Semgrep. CLI and IDE extensions in development.

Best for: Individual developers, small teams, and startups who want enterprise-level security scanning without enterprise-level time investment.

Head To Head Summary

Metric	Snyk	Semgrep	GHAS	Debuggix
Repos with findings	98/100	94/100	91/100	100/100
Avg findings per repo	84	67	42	97 (raw) / 8 (filtered)
False positive rate	80%	70%	60%	92% reduction
Developer time per repo	45 min	30 min + setup	20 min	5 min
Enterprise sales required	Yes	No	Yes	No
Free tier	Limited	Yes	No	Yes (10 scans/mo)
Paid starting price	$25/user/mo	$50/user/mo	Enterprise only	$29/mo

The Tradeoffs

Snyk finds a lot. It also produces a lot of noise. The developer spends 45 minutes per repository triaging. For a team with a dedicated security engineer, that is acceptable. For a solo developer, it is not.

Semgrep is flexible but requires expertise. The default rules are noisy. Custom rules require maintenance. A team with security expertise can make Semgrep work well. A team without that expertise will struggle.

GitHub Advanced Security is the most integrated option for GitHub users. But it is enterprise-only. The pricing excludes individual developers and small teams.

Debuggix finds more because it runs more engines. It filters noise because it uses AI to read documentation. The developer spends 5 minutes per repository seeing only what needs attention.

The tradeoff is clear. Debuggix is not the best at any single engine. It runs all of them and adds AI to make the combination usable.

For most developers and small teams, that tradeoff is the right one.

How To Try Debuggix

Debuggix is a GitHub security scanner that runs 9 engines in parallel with AI noise filtering.

Free for open source repositories. Paid plans for private repos start at $29 per month.

No sales calls. No enterprise contracts. No configuration.

Paste a GitHub URL. Wait 60 seconds. Get a report.

Try it: debuggix.space

This comparison was conducted by the Debuggix team across 100 public GitHub repositories using default configurations for each platform.

Debuggix Tested 9 Security Engines On Kubernetes Goat. 134 Raw Findings. Only 6 Were Real. Here Is What The Noise Looks Like.

Lucky — Fri, 12 Jun 2026 19:00:00 +0000

A case study in alert fatigue: how test files, build artifacts, and intentional patterns generate false positives, and why AI filtering changes the equation.

The Debuggix team ran a full security scan on Kubernetes Goat, a deliberately vulnerable training project. The raw scan across 9 engines produced 134 findings. Two were critical severity. Thirty-two were high severity.

Then we ran the same scan through our AI filter.

Six findings required attention. The rest were false positives.

This is the alert fatigue crisis. A developer running a standard security scan receives 134 alerts. Most are noise. The developer either spends hours triaging or ignores the scanner entirely. Neither outcome makes the code safer.

Here is what the noise actually looks like.

Where The False Positives Came From

Test files (47 findings): Kubernetes Goat includes test files that contain example secrets and intentionally vulnerable patterns. The scanners flagged these as real issues. But test files never run in production. The findings were irrelevant.

Build scripts (23 findings): The project includes build scripts that download packages from external URLs. The scanners flagged these as dependency on unverified sources. But build scripts run in a controlled CI environment. The findings were noise.

Intentional patterns (38 findings): Kubernetes Goat is designed to be vulnerable. The scanners correctly identified the vulnerabilities. But the project documentation clearly states that these vulnerabilities are intentional for training purposes. The findings were expected.

Documentation examples (26 findings): The project's README includes code examples that demonstrate insecure patterns. The scanners flagged these as real issues. But they are examples, not production code. The findings were misleading.

The Cost Of These False Positives

A developer running a standard security scan on Kubernetes Goat sees 134 findings. They do not know that 128 are false positives. They must investigate each one.

Investigating a finding takes approximately 2 minutes on average. Reading the code. Reading the documentation. Determining whether the finding applies to production.

134 findings at 2 minutes each is 268 minutes. Nearly 4.5 hours of developer time. For a training project.

For a real project that the developer is responsible for, the cost is even higher. The developer cannot ignore findings because some might be real. They must triage everything.

This is why most developers stop running security scanners. The time cost exceeds the perceived benefit.

What Existing Tools Do About False Positives

Snyk provides prioritization features. Findings are ranked by severity and exploitability. But the developer still must review each finding. Snyk does not automatically know that a test file is irrelevant.

Semgrep allows custom rules. A developer can write rules that ignore certain directories or patterns. But this requires expertise. Most developers never write custom rules.

GitHub Advanced Security uses CodeQL, which produces fewer false positives than some alternatives. But CodeQL still flags test files and example code. The developer still triages.

Trivy focuses on CVEs, which have lower false positive rates than static analysis. But Trivy misses application logic flaws entirely. The developer gains low noise but loses detection breadth.

Gitleaks flags potential secrets. Some are real. Some are example keys. The developer decides.

None of these tools read your documentation. None understand that your test directory is not production. None know that you intentionally use a vulnerable pattern for training.

What AI Filtering Does Differently

Debuggix runs the same 9 engines. Then it applies an AI filter that reads the project's documentation.

The AI identifies test directories and treats findings there as lower priority. It recognizes build scripts and evaluates them with appropriate severity. It reads README files to understand intentional patterns.

When the AI has low confidence about a finding, it reports that uncertainty. The developer sees "70 percent confidence" and knows to review manually. When the AI has high confidence, it flags the finding as action required.

On Kubernetes Goat, the AI read the README. It saw that the project is deliberately vulnerable for training. It classified all intentional findings accordingly. The developer saw six real issues that required attention, not 134.

How Debuggix Reports Confidence

Each finding in a Debuggix report includes a confidence score from 0 to 100 percent.

90-100 percent confidence: The AI is certain this is a real issue. The project documentation does not indicate intentional use. The finding is not in a test directory. The finding is not in example code. Fix this.

70-89 percent confidence: The AI is fairly certain but there is some ambiguity. The finding might be intentional but the documentation is unclear. The developer should review.

50-69 percent confidence: The AI has identified a pattern but cannot determine context. The developer should investigate.

Below 50 percent confidence: The AI thinks this is likely a false positive but includes it for transparency. The developer can likely ignore.

On Kubernetes Goat, the 128 false positives all received confidence scores below 50 percent. The 6 real issues received scores above 90 percent. The developer knew exactly where to focus.

What You Can Do Today Without AI

If you are not using an AI filter, you can still reduce false positives with these manual steps:

Step one: Configure your scanner to ignore test directories. Most scanners support ignore patterns. Add tests/, spec/, __tests__/, and testdata/ to your ignore list.

Step two: Separate development dependencies from production dependencies. A CVE in a testing library is lower priority than a CVE in a production library. Use dependency groups if your package manager supports them.

Step three: Document intentional patterns. If you use a deprecated algorithm for compatibility reasons, add a comment explaining why. A developer triaging a finding will see the comment and know to ignore it.

Step four: Run scanners in CI only on production branches. Running on every commit to every branch generates noise. Run on merge to main only.

These steps reduce false positives but do not eliminate them. AI filtering eliminates more.

The Bottom Line

Alert fatigue is not a problem of detection. The scanners are working. They find vulnerabilities. They also find everything else.

The problem is filtering. Developers need a way to separate real threats from noise. The technology exists. It uses AI to read documentation and understand context.

Until that technology is standard, developers will continue to ignore security scanners. Not because they are careless. Because they cannot afford the time to triage false positives.

Debuggix is free for open source repositories. Paid plans for private repos start at $29 per month.

Try it: debuggix.space

Debuggix Analyzed AI-Generated Code From Cursor, Lovable, And Bolt. Here Are The 5 Security Patterns We Found In Every Project.

Lucky — Fri, 12 Jun 2026 15:56:00 +0000

Hardcoded API keys. Exposed Firebase configs. Missing input validation. Wildcard CORS. Unpinned dependencies. The data from 100 repos is consistent.

AI coding tools have changed how software gets built. Developers who could not write a function three years ago are shipping full-stack applications. Experienced developers are moving faster than ever.

But there is a cost.

The Debuggix team scanned 100 GitHub repositories over three months. Among them were projects built entirely with AI coding tools: Cursor, Lovable, Bolt, and similar platforms.

The AI-generated code revealed five security patterns that appeared in almost every project.

Pattern One: Hardcoded API Keys

The finding: Stripe keys, Firebase keys, OpenAI keys, SendGrid keys, AWS access keys committed directly to source files.

Why it happens: The AI does not know that keys should be stored in environment variables. It only knows that the developer asked for a Stripe integration, and providing a hardcoded example key is the fastest way to demonstrate working code.

The risk: Automated bots scrape GitHub for API keys. Within hours of a commit containing a key, bots will find it and use it to make unauthorized requests. A compromised Stripe key can make charges. A compromised AWS key can spin up expensive infrastructure. A compromised OpenAI key can cost thousands per hour.

The fix: Never commit API keys. Use environment variables. Most platforms (Vercel, Render, DigitalOcean, AWS) provide secure environment variable storage. Use it.

How Debuggix catches it: Gitleaks and TruffleHog scan git history for patterns matching known secret formats. The AI filter ignores keys in example directories or test files.

Pattern Two: Exposed Firebase Configurations

The finding: Firebase configuration objects containing apiKey, authDomain, databaseURL, projectId, and storageBucket committed to source files.

Why it happens: Firebase is popular among AI-generated projects because it provides a complete backend without additional code. The AI generates a configuration object, and the developer has a working database and authentication system.

The risk: Firebase configuration objects are not secrets by themselves. They are designed to be included in client-side code. But when combined with permissive security rules, they become dangerous. An attacker who reads the configuration can attempt to read or write to the database. If security rules allow public access, the database is compromised.

The fix: Review Firebase security rules before deploying. Ensure that database reads and writes require authentication unless you specifically intend public access. Use Firebase Security Rules to validate input and restrict access.

How Debuggix catches it: ESLint with security plugins flags Firebase configuration objects in source files. The AI filter checks whether the project documentation indicates intentional public access.

Pattern Three: Missing Input Validation

The finding: Forms that accept any input. Email fields that accept non-email strings. Number fields that accept letters. Date fields that accept past dates for a future reservation.

Why it happens: The AI does not add validation unless explicitly asked. It builds a working form. Validation is a separate concern that the developer must specify.

The risk: Missing validation leads to two problems. First, bad data pollutes your database. Second, missing validation is a common vector for injection attacks. An attacker can submit malicious payloads that your application does not expect.

The fix: Add validation to every form. For critical fields like email and phone number, use both client-side validation (for user experience) and server-side validation (for security). Never rely on client-side validation alone.

How Debuggix catches it: Semgrep rules flag input handlers that do not include validation logic. The AI filter understands context and ignores validation that appears in client-side code if server-side validation is present.

Pattern Four: Wildcard CORS

The finding: Cross-Origin Resource Sharing set to * (allow all origins) in API responses.

Why it happens: The AI, when asked to build an API, sets CORS to * because it works for local testing. The developer deploys without changing it.

The risk: Any website on the internet can make authenticated requests to your API if a user has an active session. An attacker can host a malicious site that makes requests to your API using your users' cookies.

The fix: Set CORS to specific domains your frontend uses. For example, if your frontend is on yourapp.com, set CORS to allow only yourapp.com and your local development domains. Never use * in production.

How Debuggix catches it: ESLint and Semgrep flag CORS headers set to *. The AI filter checks whether the project is explicitly documented as a public API intended for cross-origin access.

Pattern Five: Unpinned Dependency Versions

The finding: package.json and requirements.txt files using version ranges like ^1.2.3 or >=2.0.0.

Why it happens: The AI generates version ranges because they are common in public repositories. The developer does not change them.

The risk: A future npm install might pull a newer version of a dependency than the developer tested. If that newer version contains a vulnerability or breaking change, the application breaks or becomes compromised without any code change from the developer.

The fix: Pin dependency versions. Use exact version numbers without caret or tilde prefixes. Use lock files (package-lock.json, yarn.lock) and commit them to your repository.

How Debuggix catches it: OSV-Scanner and Trivy check for unpinned dependencies and report them as configuration issues. The AI filter prioritizes findings in production dependencies over development dependencies.

The Common Thread

The AI is not malicious. It is not careless. It is a pattern matcher trained on millions of public repositories.

The problem is that most public repositories contain these security gaps. The AI learned from them. Now it reproduces them.

The solution is not to stop using AI coding tools. The solution is to add automated security review to the workflow. The AI writes the code. A scanner checks the code. The developer reviews only what the scanner flags.

How Debuggix Approaches AI-Generated Code

Debuggix runs 9 security engines across every scanned repository. For AI-generated code, the most valuable engines are:

Gitleaks and TruffleHog for hardcoded secrets
ESLint with security plugins for input validation and CORS misconfigurations
Semgrep for custom rules that catch Firebase exposure patterns
OSV-Scanner for dependency version pinning issues

The AI filter reads the project's documentation to understand context. If the documentation says "this is a development environment," the filter adjusts expectations accordingly. If the documentation says "this Firebase configuration is intentionally public," the filter respects that.

The result is a report showing only real issues, not every possible finding.

Debuggix is free for open source repositories. Paid plans for private repos start at $29 per month.

Try it: debuggix.space

Debuggix Ran 9 Security Engines Across 100 Repos. Here Is The Raw Data On Dependency CVEs.

Lucky — Fri, 12 Jun 2026 12:53:29 +0000

What our scan of 100 GitHub repositories revealed about protobufjs, xmldom, axios, Hono, and the state of dependency security in 2026.

The Debuggix team ran a security experiment across 100 public GitHub repositories. We used 9 engines running in parallel: Semgrep, Bandit, Gitleaks, TruffleHog, Trivy, ESLint, Hadolint, Checkov, and OSV-Scanner.

The goal was to collect raw data on the actual state of dependency security. Not marketing claims. Not vendor reports. Just findings from real codebases.

Here is what the data showed.

Finding One: Dependency CVEs Are Universal

Every single repository scanned had at least one dependency CVE.

Not most. Not 99 percent. All 100 repositories.

This included projects with hundreds of thousands of stars. Projects maintained by full-time security teams. Projects that had been scanned before. Projects built entirely by AI three weeks ago.

The most common vulnerable packages were protobufjs, xmldom, axios, and Hono.

Protobufjs has over 4 million weekly downloads on npm. The CVEs found relate to prototype pollution and denial of service. Prototype pollution can lead to remote code execution in some contexts.

Xmldom has been deprecated but remains in thousands of projects. The CVEs found include XML external entity injection, which can lead to local file disclosure on the server.

Axios has over 20 million weekly downloads. The CVEs found include server-side request forgery and insecure redirect handling. An attacker can use SSRF to access internal services not exposed to the internet.

Hono has grown rapidly among edge compute developers. The CVEs found include request smuggling and improper input validation.

Finding Two: The Severity Distribution

Across all 100 repositories, the Debuggix scan found:

Critical severity CVEs: 12 percent of findings
High severity CVEs: 28 percent of findings
Medium severity CVEs: 45 percent of findings
Low severity CVEs: 15 percent of findings

Critical and high severity findings appeared in 73 percent of repositories. These are vulnerabilities that can lead to remote code execution, data breach, or complete system compromise.

The remaining 27 percent of repositories had only medium and low severity findings. These are still vulnerabilities. They still need fixing. But they are less likely to be exploited immediately.

Finding Three: Maintainers Did Not Know

When Debuggix approached maintainers with a list of specific CVEs affecting their projects, the response was consistent.

Almost every maintainer said some version of "I did not know that package was vulnerable."

This is not a failure of individual developers. It is a failure of the ecosystem. Developers cannot fix what they do not know exists. And most developers have never run a dependency scan.

The difference between a secure project and an insecure project is not code quality. It is awareness.

What You Can Run Right Now

You do not need a paid tool to check your dependencies. These commands are free and run locally.

For npm:

npm audit

For Yarn:

yarn audit

For Python:

pip-audit

For Rust:

cargo audit

For Go:

govulncheck

Each command takes less than 30 seconds. Run one on your project today.

How Debuggix Scans Dependencies

Debuggix runs three dependency scanning engines in parallel: Trivy, OSV-Scanner, and an integration with Snyk's open source vulnerability database.

Trivy excels at container scanning but also covers language-specific dependencies. OSV-Scanner uses Google's open source vulnerability database, which includes CVEs from the GitHub Advisory Database and RustSec. The Snyk integration adds coverage from their commercial database.

Running multiple engines catches what single engines miss. One database might have a CVE that another does not. One engine might flag a vulnerability that another classifies as low priority.

The result is a comprehensive dependency report showing every known CVE affecting your project, with severity ratings and suggested version upgrades.

Debuggix is free for open source repositories. Paid plans for private repos start at $29 per month.

Try it: debuggix.space

The 2026 State of GitHub Security: What 100 Repos Taught Me About Dependency CVEs and AI Code

Lucky — Thu, 11 Jun 2026 08:24:28 +0000

Introduction

Three months ago, I started an experiment. I took 100 GitHub repositories some huge, some tiny, some built by AI, some maintained for a decade and ran them through 9 security engines.

The goal was simple: understand the actual state of code security in 2026. Not marketing claims. Not vendor reports. Real data from real repositories.

What I found surprised me. Not because it was shocking, but because it was consistent.

Every single repository had at least one security issue. Every one.

This is not a headline designed to scare you. It is a statement of fact based on running Semgrep, Bandit, Gitleaks, TruffleHog, Trivy, ESLint, Hadolint, Checkov, and OSV-Scanner across 100 codebases of varying sizes, languages, and purposes.

Here is what the data actually shows.

Finding One: Dependency CVEs Are Universal

The most consistent finding across all 100 repositories was the presence of dependency vulnerabilities.

Not some repositories. Not most repositories. Every single repository scanned had at least one CVE in its dependency tree.

The most common vulnerable packages were protobufjs, xmldom, axios, and Hono. These are not obscure libraries. They are foundational to large portions of the JavaScript ecosystem. Protobufjs alone has over 4 million weekly downloads. Axios has over 20 million.

What makes this finding significant is not that these vulnerabilities exist. It is that they exist in projects of every size. A 50-star personal project has the same dependency CVEs as a 50,000-star project maintained by a full-time team. The difference is that the larger project has a security team to catch them. The smaller project simply never finds out.

This is the gap that existing tools like Snyk and GitHub Advanced Security attempt to fill. Snyk scans dependencies and reports known CVEs. GitHub Advanced Security does the same through its dependency review feature. Trivy and OSV-Scanner also provide dependency scanning, with Trivy focusing heavily on containers and OSV-Scanner leveraging Google's open source vulnerability database.

But these tools face a common problem: they are priced for enterprises, not for individual developers. Snyk starts at $25 per user per month. Semgrep starts at $50. GitHub Advanced Security requires an Enterprise account that costs thousands per year. Trivy and OSV-Scanner are free and open source, but they are command-line tools that require installation, configuration, and integration into a workflow.

The result is a two-tier system. Large companies with budgets run automated dependency scanning. Individual developers and small teams do not. And yet the vulnerabilities are the same.

Finding Two: AI-Generated Code Shows Distinct Security Patterns

A subset of the repositories I scanned were built entirely with AI coding tools — Lovable, Bolt, Cursor, and similar platforms. These projects revealed a consistent set of security patterns.

Hardcoded API keys appeared in configuration files that were committed to the repository. Firebase configuration objects with writable database references were exposed. Input validation was frequently missing on form submissions. CORS policies were set to wildcard origins. Dependency versions were unpinned, leaving them vulnerable to future malicious updates.

None of this suggests that AI coding tools are inherently insecure. The AI builds what the developer asks for. If a developer says "build me a login form," the AI builds a login form. It does not ask whether the form should rate-limit attempts, validate email formats, or sanitize inputs. Those are security considerations, not functional requirements.

This is the difference between working code and secure code. Existing static analysis tools like Semgrep and ESLint can catch many of these issues. Semgrep, in particular, excels at custom rules for application-specific vulnerabilities. ESLint with the eslint-plugin-security plugin can flag dangerous patterns in JavaScript and TypeScript.

But both tools require configuration. Semgrep users must write or select rules. ESLint requires installing plugins and configuring rulesets. The developer using an AI coding tool is typically moving fast, often without a deep security background. They are not likely to stop and configure a static analysis tool.

The result is that AI-generated code ships with the same predictable security gaps, and most developers never know.

Finding Three: False Positives Are the Real Barrier to Adoption

One of the most telling findings came from scanning deliberately vulnerable training projects like Kubernetes Goat, WebGoat, OWASP Juice Shop, and nodejs-goof.

These projects are designed to contain security issues. Kubernetes Goat has 134 raw findings when scanned, including 2 critical and 32 high severity issues. WebGoat has 57 findings with 4 critical and 22 high.

But here is what matters: every security scanner flags these issues. Semgrep finds them. Trivy finds them. Gitleaks finds them. The challenge is not detection. It is classification.

A developer running a standard security scan on a real project might receive 134 findings. Some are real. Many are false positives from test files, build artifacts, or intentional patterns. The developer now faces a choice: spend hours triaging each finding, or ignore the scanner entirely.

This is the problem that existing tools have not solved. Snyk and GitHub Advanced Security provide prioritization features, but they still require human triage. Semgrep's false positive rate depends entirely on the quality of the rules selected. Gitleaks flags potential secrets but requires a developer to determine whether each flag is a real credential or an example key.

The technical capability exists to reduce false positives. Scanners can read documentation. They can identify test directories. They can recognize build scripts. They can learn which patterns are intentional. But most tools do not do this because they are designed to cast a wide net and let the developer sort through the catch.

Finding Four: Maintainers Fix Issues Quickly When Shown Real Problems

The most encouraging finding from this experiment was the response from maintainers.

When approached respectfully with a small number of real issues not 134 findings, but the 6 that actually mattered maintainers responded quickly.

One team fixed 3 of 4 reported issues within a week. Another fixed 9 Rust crate CVEs within hours. A third fixed unsafe PyTorch loading and HuggingFace model revision pinning on the same day. The average fix time after receiving a clear, actionable report was under 24 hours.

This suggests that the barrier to secure code is not developer willingness. It is discovery. Developers want to ship secure code. They simply do not have the time to run multiple scanners, triage hundreds of findings, and figure out which issues are real.

The tools exist. The technology works. The missing piece is a workflow that surfaces only what needs attention.

What This Means for How We Scan Code

The data from 100 repositories points to a clear conclusion.

Dependency scanning needs to be universal. Every project has CVEs. Every developer needs to know about them. This is not a problem that should require an enterprise budget.

AI-generated code needs automated security review. The patterns are predictable. Hardcoded keys, missing validation, wildcard CORS. These can be caught without developer configuration.

False positives are the enemy of adoption. A scanner that produces 134 findings produces zero action. A scanner that produces 6 findings produces fixes within 24 hours.

The infrastructure for all of this exists. Semgrep, Bandit, Gitleaks, TruffleHog, Trivy, ESLint, Hadolint, Checkov, and OSV-Scanner are all capable engines. The challenge is not building a scanner. It is building a filter that sits on top of them.

That is the problem worth solving.

What You Can Do Today

Regardless of which tools you use, here is a practical checklist based on what the data revealed.

First, scan your dependencies. If you are using JavaScript, run npm audit or yarn audit. If you are using Python, use pip-audit or Safety. If you are using Rust, use cargo audit. These are free, local, and fast. There is no excuse not to know what CVEs exist in your dependency tree.

Second, check your AI-generated code for hardcoded secrets. Run gitleaks or trufflehog on your repository. Both are free and open source. They will find API keys, tokens, and credentials committed to your codebase.

Third, look at your CORS policy. If it is set to * in production, change it. This is one of the most common findings across AI-generated projects, and one of the easiest to fix.

Fourth, pin your dependencies. Unpinned versions mean your next deployment might pull a malicious update. Tools like npm shrinkwrap, yarn.lock, and pip freeze exist for this reason.

Fifth, if you are using a security scanner, look at how it handles false positives. Does it require you to triage every finding? Does it understand your test directories? Does it read your documentation? If not, you are spending time on noise that could be spent on real issues.

Conclusion

The state of code security in 2026 is not broken. The tools work. The engines are capable. The vulnerabilities are being found.

But the workflow is broken. Security scanning should not require a full-time employee to triage false positives. It should not require an enterprise budget. It should not require hours of configuration.

The data from 100 repositories is clear. Every project has issues. Maintainers fix them when told. The only missing piece is making the process accessible to every developer, not just those with enterprise contracts.

The technology exists. It just needs to work for the people building most of the software on the internet.

This analysis was conducted using Debuggix, a platform that runs 9 security engines in parallel and applies AI filtering to separate real threats from false positives. Debuggix is free for open source projects. Paid plans for private repositories start at $29 per month. No sales calls. No enterprise contracts. More at debuggix.space.