IA Rompe tu Código

La IA ya escanea tu software en minutos — y no le importa si tienes un equipo de seguridad.

[DATO REAL]: En febrero de 2025, Thomas Ptacek — cofundador de Matasano Security, 25 años rompiendo sistemas por oficio — publicó “Vulnerability Research Is Cooked”. Su argumento: los LLMs ya encuentran vulnerabilidades reales a velocidad y escala que ningún equipo humano puede igualar. Cuando alguien así lo dice, prestas atención.

En este artículo vas a:

• Entender por qué el modelo mental de “nadie va a encontrar ese bug” está muerto
• Ver evidencia real: qué encontró Claude, qué automatizó OpenAI, qué colapsó el kernel de Linux
• Aprender las nuevas reglas del juego antes de que alguien las use contra ti
• Implementar escaneo automatizado de seguridad en tu CI/CD esta semana

01 EL PROBLEMA REAL

Un modelo de IA puede analizar un repositorio completo en minutos. No descansa, no se distrae, no cobra por hora. Anthropic reportó que Claude descubrió más de 500 vulnerabilidades en proyectos open-source ampliamente usados — buffer overflows, race conditions, inyecciones SQL, fallos de autenticación. No bugs triviales. Software que millones de personas usan cada día.

OpenAI construyó “Aardvark”, un pentester automatizado que le pasa un codebase al modelo y deja que busque fallos sistemáticamente. Un investigador senior revisa 500–1000 líneas por hora. Aardvark analiza repositorios completos en minutos.

IBM X-Force reportó un aumento del 44% en ataques vía aplicaciones públicas. RSAC 2026 — el evento de ciberseguridad más importante del mundo — estará dominado por un solo tema: IA aplicada a seguridad ofensiva. No es el futuro. Es ahora.

PIÉNSALO ASÍ

Antes, encontrar el bug oculto en tu código era como buscar una aguja en un pajar — requería semanas de un experto con café y paciencia. Ahora, la máquina pasa un imán por todo el pajar en cinco minutos y encuentra todas las agujas.

Antes	El costo	Después
Semanas de auditoría manual	El mismo bug	Minutos de escaneo automatizado
Pocos atacantes calificados	Tu endpoint expuesto	Herramientas al alcance de cualquiera
“Nadie va a encontrar eso”	Suposición válida	Suposición que te va a costar caro

02 POR QUÉ PASA

Hay dos fuerzas actuando al mismo tiempo y se refuerzan mutuamente.

Primera: la IA democratizó las herramientas ofensivas. Antes necesitabas años de expertise para hacer pentesting serio. Hoy, un fuzzer inteligente basado en LLM genera payloads contextuales, analiza respuestas, detecta blind SQLi y variantes que un scanner tradicional no vería — todo en minutos, sin conocimiento experto de quien lo corre.

Segunda: la misma IA que encuentra vulnerabilidades también las crea. El código generado por LLMs tiene patrones predecibles: inyecciones SQL, secrets hardcodeados, criptografía débil, dependencias inventadas. Tu equipo genera código más rápido con IA, pero ese código tiene más superficie de ataque. Y los atacantes ya usan IA para escanearlo.

El resultado: la ventana entre “bug introducido” y “bug explotado” se redujo de meses a días u horas. Es una carrera armamentista. Si no estás del lado correcto, pierdes.

03 LA SOLUCIÓN

Hay que voltearse la ecuación: usar la misma IA que ataca para defenderte antes de que alguien más llegue.

Pero hay una trampa que nadie anticipó. Si la IA encuentra vulnerabilidades más rápido, eso significa más reportes. Muchos más. Y el ecosistema no estaba preparado.

Daniel Stenberg — creador de cURL, probablemente la herramienta de línea de comandos más utilizada en la historia — lo vivió en carne propia. La cantidad de reportes de vulnerabilidades se multiplicó. El problema: la gran mayoría son basura. Reportes generados por IA que suenan convincentes, tienen formato profesional, citan CVEs reales… y están completamente equivocados. El modelo alucina una vulnerabilidad con la confianza de un experto. Los mantenedores — que trabajan gratis en su tiempo libre — gastan horas verificando falsos positivos.

Los mantenedores del kernel de Linux enfrentan el mismo problema multiplicado por cien. Algunos reportes son reales y valiosos. Pero separarlos del ruido requiere el mismo expertise que se necesitaba para encontrar los bugs. Más señal útil, sí. Pero también exponencialmente más ruido.

La solución correcta no es solo correr más scanners — es integrarlos en tu proceso con supervisión humana que filtre el ruido y actúe sobre lo real.

El enfoque que funciona: escaneo automatizado en cada commit, revisión de ingenieros con criterio de negocio, fuzzing de APIs antes de cada release, auditoría de dependencias, y threat modeling actualizado trimestralmente que incluya vectores de IA.

04 CÓMO IMPLEMENTARLO

1. Agrega escaneo de seguridad a tu CI/CD — esta semana, no en el próximo sprint:

# .github/workflows/security.yml
name: Security Gate
on: [push, pull_request]

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

      # SAST — análisis estático
      - name: Semgrep
        uses: returntocorp/semgrep-action@v1
        with:
          config: >-
            p/owasp-top-ten
            p/javascript
            p/typescript

      # Dependencias vulnerables
      - name: Audit dependencies
        run: npm audit --audit-level=high

      # Secrets que no deben estar en el repo
      - name: Gitleaks
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      # Si CUALQUIERA falla, el PR no se mergea

2. Audita tu superficie de ataque pública. Haz un inventario de cada endpoint, subdominio y servicio expuesto a internet. Si no sabes qué tienes afuera, no puedes defenderlo:

# Descubrimiento de subdominios
subfinder -d tudominio.com -o subdominios.txt

# Escaneo de puertos
nmap -sV -sC -oN scan_results.txt tudominio.com

# Fuzzing de endpoints
ffuf -w /usr/share/wordlists/common.txt \
  -u https://tudominio.com/FUZZ \
  -mc 200,301,302,403

3. Revisa el código generado por IA con lupa. Cada pieza que sale de un LLM pasa por revisión humana con criterio de seguridad. El patrón más común que la IA introduce: concatenación de strings en SQL. Este endpoint parece funcional y pasa tests básicos — pero está roto:

// Código generado por IA — vulnerable a SQLi
app.get('/api/search', (req, res) => {
  const { query, category } = req.query;
  const sql = `SELECT * FROM products
    WHERE name LIKE '%${query}%'
    AND category = '${category}'`;
  db.query(sql, (err, results) => res.json(results));
});

Un fuzzer con IA lo encuentra en menos de cinco minutos. No necesitas ser hacker elite para correrlo.

4. Actualiza tu modelo de amenazas. Si el último tiene más de 6 meses, está desactualizado. Incluye: IA como vector de ataque (fuzzing automatizado), IA como fuente de vulnerabilidades (código sin revisión), supply chain attacks potenciados por IA, y phishing hiper-personalizado.

5. Entrena a todo el equipo, no solo a los devs. El 90% de los breaches empiezan con un humano haciendo click donde no debía.

6. Mide el MTTR. Mean Time To Remediate. Ya no se trata de si van a encontrar un bug. Se trata de qué tan rápido lo parcheas.

05 ¿ES PARA TI?

Sí, si tu empresa:

• ✅ Tiene software en producción con endpoints públicos (API, app web, servicios)
• ✅ Usa IA para generar código o automatizar desarrollo
• ✅ Todavía asume que “nadie va a encontrar ese bug” porque la ruta no es obvia

No, si:

• ❌ No tienes ningún sistema expuesto a internet — sin superficie pública, el riesgo es menor
• ❌ Ya tienes escaneo automatizado en CI/CD, fuzzing periódico y threat modeling trimestral — vas bien, esto es confirmación, no novedad

Preguntas frecuentes

¿El escaneo automatizado reemplaza una auditoría de seguridad profesional? No. El escaneo automatizado encuentra lo que tiene patrones conocidos — OWASP Top 10, dependencias vulnerables, secrets expuestos. Una auditoría profesional encuentra fallos de lógica de negocio, vulnerabilidades de arquitectura y combinaciones de issues que solo un humano con contexto puede ver. Son complementarios, no sustitutos.

¿Es legal que la IA escanee mi propio código buscando vulnerabilidades? Sí, en tu propio código y en código open-source. El límite legal está en escanear sistemas de terceros sin autorización. Herramientas como Semgrep, CodeQL o Gitleaks en tu CI/CD son completamente legítimas y recomendadas.

¿Qué hago si el scanner reporta muchos falsos positivos? Esto es exactamente el problema que enfrentó el kernel de Linux con reportes generados por IA. La clave es configurar las reglas del scanner para tu contexto específico y asignar a alguien con criterio técnico para el triage — no delegar el triage al mismo que escribe el código.

Acción inmediata: Agrega Gitleaks a tu repo hoy. Tarda menos de 15 minutos y te dice inmediatamente si hay secrets expuestos en tu historial de commits — el tipo de vulnerability que más impacto tiene y menos tiempo toma encontrar.

¿Quieres que revisemos tu pipeline de seguridad? → Habla con DCM

In February 2025, Thomas Ptacek – one of the most respected security researchers on the planet, co-founder of Matasano Security, the guy who literally wrote the book on cryptographic attacks – published a post that shook the entire industry. The title: “Vulnerability Research Is Cooked.” Done. Over. Finished.

This wasn’t some AI evangelist selling hype on LinkedIn. This was someone who’s spent 25 years breaking systems for a living. And when someone like that says the game has changed, you pay attention.

His argument was devastatingly simple: language models are now capable of finding vulnerabilities in real software, at a speed and scale no human team can match. The paradigm where a company could assume “nobody will find that bug” – because finding it required weeks of reverse engineering by an expert fueled by coffee and patience – is over. Now those same bugs get found by a model in minutes. And not just one. Hundreds. Thousands.

Welcome to the new reality of cybersecurity.

The evidence: who found what and how

This isn’t speculation. The results are already on the table.

Anthropic: 500+ vulnerabilities in open-source code

Anthropic reported that Claude discovered over 500 vulnerabilities in widely-used open-source projects. We’re not talking about trivial bugs like “missing semicolon.” We’re talking about real vulnerabilities – buffer overflows, race conditions, injections, authentication logic flaws – in software that millions of people rely on every day.

The model didn’t just find the bugs. It explained them. Generated proof-of-concept exploits. Suggested patches. In minutes, it accomplished what previously took days or weeks of manual auditing. If you’ve already read our analysis of how AI generates code without anyone reviewing the security, this is the flip side of the coin: the same technology that introduces vulnerabilities also finds them.

OpenAI: Aardvark and automated pentesting

OpenAI wasn’t sitting still either. They developed an internal tool called “Aardvark” – an automated vulnerability research system built on their models. The concept’s straightforward: give the model access to a codebase and let it systematically hunt for flaws, like a human pentester would but without resting, without getting distracted, without charging by the hour.

What’s remarkable isn’t just that it works. It’s the speed. A senior researcher might review 500-1000 lines of code per hour looking for vulnerabilities. A model like the ones powering Aardvark can analyze entire repositories in minutes. Not with the same contextual depth as an experienced human – not yet – but with coverage and consistency that no team can replicate.

RSAC 2026: the conference that will confirm the shift

The RSA Conference 2026 – the world’s most important cybersecurity event – will be dominated by one theme: AI applied to security research. Nearly every keynote, every panel, every demo will revolve around the same thing. AI isn’t the future of offensive security. It’s the present.

Security firms that used to sell “our elite team of hackers reviews your code” now sell “our elite team of hackers assisted by AI reviews your code.” Those that didn’t make that pivot are already falling behind.

The flood: too many reports, not enough humans

Now comes the part nobody anticipated. If AI can find vulnerabilities faster, that means more reports. Way more. And the ecosystem wasn’t ready.

Daniel Stenberg and the cURL nightmare

Daniel Stenberg – the creator and maintainer of cURL, arguably the most widely-used command-line tool in computing history – has been vocal about the problem. Since AI models became capable of analyzing code, the volume of vulnerability reports submitted to the cURL project has multiplied.

The catch: the vast majority are garbage.

Stenberg reported an explosion of AI-generated reports that sound convincing, are professionally formatted, cite real CVEs… and are completely wrong. The model hallucinates a vulnerability, presents it with expert-level confidence, and someone submits it as a report. The maintainers – who already work for free in their spare time – now have to spend hours verifying false positives generated by a machine.

The Linux kernel: drowning in noise

Linux kernel maintainers face the same problem multiplied by a hundred. The kernel’s one of the largest and most critical projects in the world, and it’s now receiving a volume of AI-generated bug reports that’s overwhelming human triage capacity.

It’s not that all the reports are false. Some are real and valuable. But separating them from the noise requires the same type of expertise needed to find the bugs in the first place. It’s like looking for a needle in a haystack – except someone just multiplied the size of the haystack by 50.

The automated discovery paradox

Here’s the fundamental tension: AI finds real vulnerabilities at unprecedented speed, but it also generates a volume of false positives that threatens to collapse response systems. It’s the classic signal-to-noise ratio problem. More useful signals, yes. But also exponentially more noise.

What this means for your codebase

Let’s cut to the chase. If you’ve got a company with software in production – whether it’s an app, an API, an internal system, whatever – the equation has changed radically.

You can’t assume “nobody will find that bug” anymore

This was the security mental model for most companies until a couple of years ago. “Yeah, there’s an unvalidated endpoint, but it’s on an internal route nobody knows about.” “Sure, the password hash is SHA1, but nobody’s getting access to the database.” “Yeah, there’s a SQL injection in the reports module, but only 3 people use it.”

That model’s dead.

An AI model can analyze your source code (if it’s open source), your public API (through automated fuzzing), or your web application’s patterns and find those bugs in hours. IBM X-Force reported a 44% increase in attacks through public-facing applications. That’s not a coincidence. The tools to find and exploit vulnerabilities have been democratized.

AI-generated code needs more review, not less

Here’s a brutal irony. The same AI that finds vulnerabilities also creates them. As we documented in our analysis of vibe coding and its security risks, LLM-generated code has predictable vulnerability patterns: SQL injections, hardcoded secrets, weak cryptography, hallucinated dependencies.

So you’ve got a scenario where:

1. Your team generates code with AI (faster, but potentially more vulnerable)
2. Attackers use AI to find those vulnerabilities (faster than ever)
3. Your exposure window shrinks from months to days or hours

It’s an arms race. And if you’re not on the right side, you lose.

A concrete example

Picture this. Your team uses an LLM to generate a search endpoint:

// AI-generated code -- looks functional, passes basic tests
app.get('/api/search', (req, res) => {
  const { query, category } = req.query;
  const sql = `SELECT * FROM products 
    WHERE name LIKE '%${query}%' 
    AND category = '${category}'
    ORDER BY created_at DESC`;
  db.query(sql, (err, results) => {
    res.json(results);
  });
});

Before, a human attacker had to discover this endpoint, manually test different payloads, and find the injection. That could’ve taken weeks if the endpoint wasn’t obvious.

Now, an AI-powered automated fuzzing tool can:

# AI-powered automated fuzzer -- finds the injection in seconds
import requests
from ai_fuzzer import SmartFuzzer

fuzzer = SmartFuzzer(
    target="https://yourapp.com/api/search",
    params=["query", "category"],
    attack_types=["sqli", "xss", "path_traversal"]
)

# The fuzzer generates intelligent payloads, not brute force
# It analyzes responses, detects time-based blind SQLi,
# error-based SQLi, and variants traditional scanners would miss
results = fuzzer.run(max_time=300)  # 5 minutes

for vuln in results.confirmed:
    print(f"[CONFIRMED] {vuln.type} in {vuln.param}")
    print(f"  Payload: {vuln.payload}")
    print(f"  Evidence: {vuln.evidence}")

Five minutes. Your endpoint gets exposed in five minutes. And you don’t need to be an elite hacker to run that script.

The new rules of the game

The cybersecurity landscape has shifted and the old rules no longer apply. Here are the new ones:

Rule 1: Assume everything will be scanned. Every public endpoint, every API, every form. If it’s exposed to the internet, someone (or something) will test it. Not in months. In days.

Rule 2: Security through obscurity’s officially dead. “Nobody knows about that route” isn’t an argument anymore. Models don’t need to “know” your route. They can infer it, discover it, or simply try every reasonable combination.

Rule 3: Remediation speed’s the new critical metric. It’s not about whether someone will find a bug. It’s about how fast you patch it after they do. MTTR (Mean Time To Remediate) matters more than ever.

Rule 4: The perimeter isn’t the defense line anymore. With a 44% increase in attacks via public applications (IBM X-Force), security needs to exist at every layer. From code to infrastructure, through dependencies.

Rule 5: If you’re not using AI to defend, you’re at a disadvantage. Attackers already are. Not bringing the same weapons to the fight is tactical suicide.

How to prepare your organization

Here’s the practical stuff. What you can implement this week, not in some 18-month “digital transformation roadmap.”

1. Implement automated security scanning in your CI/CD

If you don’t have this, stop everything else and put it first:

# .github/workflows/security.yml
name: Security Gate
on: [push, pull_request]

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      # SAST - Static Application Security Testing
      - name: Semgrep
        uses: returntocorp/semgrep-action@v1
        with:
          config: >-
            p/owasp-top-ten
            p/javascript
            p/typescript
      
      # Dependencies - known vulnerabilities
      - name: Audit dependencies
        run: npm audit --audit-level=high
      
      # Secrets - make sure nothing slips through
      - name: Gitleaks
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      
      # If ANY of these fail, the PR doesn't get merged

2. Audit your public attack surface

Inventory everything that’s exposed to the internet. Every endpoint, every subdomain, every service. If you don’t know what you’ve got exposed, you can’t defend it.

# Basic subdomain discovery
subfinder -d yourdomain.com -o subdomains.txt

# Port scanning your public assets
nmap -sV -sC -oN scan_results.txt yourdomain.com

# Directory and endpoint fuzzing
ffuf -w /usr/share/wordlists/common.txt \
  -u https://yourdomain.com/FUZZ \
  -mc 200,301,302,403

3. Review AI-generated code with a magnifying glass

Don’t trust blindly. Every piece of code that comes out of an LLM goes through human review with a security mindset. If your team uses tools like Claude Code, configuring security skills and hooks automates part of this review, but it doesn’t replace human eyes.

4. Update your threat model

If your last threat model’s more than 6 months old, it’s outdated. Include:

• AI as an attack vector (automated fuzzing, exploit generation)
• AI as a source of vulnerabilities (unreviewed generated code)
• AI-powered supply chain attacks (slopsquatting, malicious dependencies)
• AI-assisted social engineering (hyper-personalized phishing)

5. Train your team

Not just devs. Everyone. 90% of breaches start with a human clicking where they shouldn’t. With AI generating increasingly convincing phishing, the human factor’s more critical than ever.

What DCM does differently

At DCM System, we’ve spent 12+ years building software for companies that can’t afford to get hacked. Banking, retail, healthcare, government. Systems where failure means real people lose money, data, or trust.

Our approach to this new reality’s simple: we use AI to attack ourselves before someone else does.

Every project that ships from our team goes through:

• Automated AI scanning on every commit – not at the end of the sprint, on every commit
• Senior engineer review by people who understand the business context, not just the code. This is exactly why we still bet on real engineers in an AI-dominated era
• Automated API fuzzing of endpoints before every release
• Dependency auditing with tools that detect supply chain attacks
• Quarterly threat modeling updates, including AI-specific attack vectors

We don’t wait for someone to report a vulnerability. We actively hunt for them. Every day.

If your company needs software that can withstand the scrutiny of an AI looking for bugs – which is exactly the scrutiny it’ll face in the real world – let’s talk. We build systems for the world that’s coming, not the one that already passed.

The bottom line: adapt or get exposed

AI finding vulnerabilities faster than humans isn’t a future threat. It’s today’s reality. Thomas Ptacek saw it. Daniel Stenberg’s living it. Linux kernel maintainers face it daily. IBM X-Force statistics confirm it. RSAC 2026 will turn it into industry consensus.

For Colombian businesses – and Latin American ones in general – this is particularly critical. The region faces an enormous cybersecurity talent deficit, and AI adoption for development’s accelerating without security culture keeping pace. It’s the perfect recipe for a wave of incidents.

The good news: the same tools creating the problem can also be part of the solution. The AI that finds vulnerabilities can also find them in your code before someone exploits them. But only if you use it proactively, integrated into your development process, with humans with good judgment overseeing the results.

The question’s no longer whether AI will find bugs in your software. The question’s whether you’ll find them first.

At DCM System we combine 12+ years of secure development experience with the most advanced AI tools to protect your code. If you need to audit your software, secure your pipeline, or build something that can handle the real world – get in touch.