DEV Community: Fernando Gallardo

30+ confirmed vulnerabilities in production OSS, at $6–7 per full codebase scan

Fernando Gallardo — Thu, 02 Jul 2026 20:49:05 +0000

We're not naming the platforms yet. Several findings are still in responsible disclosure, some without a confirmed patch. But we can share the methodology, the numbers, and enough about the findings to make this worth reading.

Over the past several months we ran our system against real open-source projects in production, used by thousands of organizations, across 7 programming languages. Result: 30+ confirmed real vulnerabilities, with at least one independently corroborated by a security researcher who has no connection to us. Here's how it works and what we actually found.

The architecture

The system has two main components.

Structural code modeling. Not text pattern matching, a graph that combines syntax, control flow, and data flow across the entire codebase. This is what lets the system reason about how files interact with each other, not just what's inside each file in isolation. Most vulnerabilities in real codebases don't live in a single function; they emerge from the interaction between components.

AI agents that reason like an attacker. For each candidate location flagged by the structural model, an agent generates a concrete exploitation hypothesis, then actively searches the code for evidence to disprove it. A finding only gets reported if the agent can't rule it out.

The hallucination problem in AI-based vulnerability detection is real and well-documented. Our answer to it is a three-layer independent verification pipeline:

Layer 1: Agent generates the attack hypothesis.
Layer 2: An independent analyst agent — with more context and access to surrounding code — whose sole job is to attempt to disprove Layer 1's finding.
Layer 3: Literal factual verification using a model from a different provider than the one that generated the original finding. It checks every specific claim, line numbers, function names, actual values against the source code, word for word.

Layer 3 already caught a real false positive in production that Layers 1 and 2 had passed as confirmed. The false positive was caused by a variable reassignment several function calls up the chain that neither earlier pass had followed far enough. That's the kind of thing that makes AI vulnerability reports unreliable in practice and the reason we built the verification architecture the way we did.

The prioritization engine: why the cost is so low

The $6–7 figure per full codebase scan comes from a specific architectural decision: the expensive AI reasoning only runs on a small fraction of the codebase.

The first pass is a deterministic prioritization engine, no LLM / no API cost, that scores every function in the repo based on structural signals: data flow complexity, external input handling, memory management patterns, interaction with authentication or cryptographic primitives, and similar heuristics. This runs fast and cheap. Its job is to filter out the 98–99% of code that almost certainly isn't worth deep analysis.

Only the functions that score above a threshold go to the AI reasoning layers. Here's what that looked like across three real runs:

Project B's higher percentage (17.4%) is an outlier, that codebase had a higher density of functions touching external input directly. The 0.4–0.9% range on the other two is more representative.

For comparison: a thorough manual security review runs at roughly 100–150 LOC/hour per specialist, by standard industry estimates. Project A would take approximately 1,900 human-hours at that rate around 48 weeks of full-time work. We're not claiming this is a controlled equivalence; a human expert prioritizes differently and wouldn't attempt 100% coverage of a repo that size. But the system does run 100% of the code through the prioritization engine before deciding what to go deep on, the coverage is systematic, not intuition-based.

Blind CVE reproduction as a reliability test

Before running against unknown targets, we validated the system's reliability by giving it codebases with known vulnerabilities it hadn't seen without telling it where the vulnerability was.

Test 1: Pre-patch version of a widely-used JWT/authentication library, with a public CVE for an algorithm confusion vulnerability. The system found it.

Test 2: Pre-disclosure version of infrastructure used across a large part of the AI application industry, with a critical pre-authentication SQL injection. The system found it. According to public reports, this same vulnerability was actively exploited within 36 hours of its official public disclosure.

These weren't needle-in-a-haystack scenarios designed to make the system look good — they were real codebases with the full complexity of production code, and the system found the right thing without being pointed at it.

What we found in the wild

Running against the latest public versions of several critical projects with no known CVE going in:

Heap buffer overflow in a widely-deployed, low-level infrastructure component. Found autonomously, without a prior hint. An independent security researcher, with no connection to us, reported the exact same bug at nearly the same time. The affected platform cross-validated both reports in their triage process. We can't inflate that validation, it was an external third party reaching the same conclusion independently.

JWT signature verification vulnerability without a prior CVE, in the latest public version of a widely-used piece of AI infrastructure.

Multiple vulnerabilities in a widely-adopted local AI runtime, memory exhaustion DoS, cryptographic integrity bypass, and command injection — currently in responsible disclosure.

Total across all runs and languages: 30+ confirmed vulnerabilities, all passing through the three-layer verification pipeline before being reported.

What this doesn't do

The system doesn't replace the security specialist making the final call. Every finding comes with a concrete attack hypothesis and specific evidence, but a human still decides what's real, what's in scope, and what gets reported. What changes is what that person spends their time on: they get a short list of findings with context, not thousands of functions to read through hoping something stands out.

We're not claiming zero false positives, the three-layer architecture exists precisely because we expect some to get through, and we're still refining based on patterns we've identified in production. What we are claiming is that the verification pipeline makes false positives significantly harder to sustain through all three layers than in a single-pass system.

Happy to answer questions about the architecture, the prioritization heuristics, or specifics on any of the finding categories. We'll share more on the individual vulnerabilities as disclosures are confirmed.

Vibe coding isn't the problem. Volume is.

Fernando Gallardo — Tue, 30 Jun 2026 16:00:00 +0000

The debate around vibe coding has settled into a predictable shape: people who write code with AI assistance are reckless, people who don't are careful, and the fix is to get more humans back in the loop. It's a comfortable narrative because it has a villain. It's also wrong, or at least pointed at the wrong target.

A senior engineer using Copilot or Cursor ships the same category of vulnerable code as someone vibe coding their first SaaS product. Not because skill doesn't matter, it does, for design decisions, architecture, knowing what to build. But for a specific class of security bug, skill level is almost irrelevant. The model suggesting the code was trained on a snapshot of the world that's already out of date the moment it ships, and it's generating that code at a volume no human review process was built to handle.

That's the actual problem, Not who's typing, How much code is being produced, and how fast the threat landscape underneath it moves.

The training data is always behind the threat

Every LLM used for code generation has a training cutoff. Everything it knows about secure patterns, vulnerable dependencies, and best practices is frozen at that point. New CVEs get published daily, the OSV database adds entries continuously, a package that was safe at training time can have a critical vulnerability disclosed the next week and the model has no way to know that.

This isn't a hypothetical edge case, It's the default state of every AI-assisted codebase. The model will confidently suggest:

import requests
response = requests.get(url, verify=False)  # commonly suggested, rarely flagged

verify=False disables TLS certificate verification. It shows up constantly in tutorials and Stack Overflow answers from years ago, exactly the kind of pattern that gets absorbed into training data and reproduced without context. The model isn't being careless, it's reproducing what it learned, and what it learned has a shelf life.

The same applies to dependency versions. A model trained six months ago might recommend a package version with a known CVE disclosed in the meantime, with no signal to the developer that anything's wrong. The code runs, the tests pass and the vulnerability ships.

The real shift is volume, not intent

Here's what actually changed in the last two years: the amount of code a single developer can produce went up by an order of magnitude. That's true whether they're using AI deliberately and carefully, or vibe coding an entire app over a weekend.

Code review processes, the ones most teams still use, were designed for a world where a senior engineer could reasonably read every line of every PR. That assumption breaks down when PRs are 5x larger and arrive 3x more often. Nobody decided to skip security review. The math of human attention just stopped working.

This is the part the vibe coding debate misses entirely. The conversation about "is it okay to ship code you don't fully understand" is a separate, legitimate question. But even code written by someone who understands every line is vulnerable to the same training-data lag, and produced at the same volume that overwhelms manual review. Blaming vibe coding treats the symptom and ignores the mechanism.

What manual review can't keep up with

Consider what's actually required to catch a vulnerability introduced by AI-suggested code:

Know the current CVE landscape, not what was true at training time, but what's true today
Trace data flow across files, not just read the diff in isolation
Check every new or updated dependency against live vulnerability databases (OSV, NVD, GitHub Advisories)
Do this at the speed code is being merged, not in a quarterly audit

A human reviewer can do all four. They cannot do all four, accurately, for every PR, every day, across a growing codebase, without it becoming their entire job. That's not a knock on engineers, it's a description of what the volume of AI-generated code actually demands.

This is where the conversation needs to shift from "should we trust AI to write code" to "how do we close the gap between code velocity and security review velocity." Those are different problems with different solutions.

Closing the gap requires matching the speed, not adding more humans

The instinct to fix this with more manual review doesn't scale, you'd need to grow your security headcount proportionally to your AI-assisted output, which defeats the purpose of using AI assistance in the first place.

What actually works is tooling that operates at the same speed code is generated, cross-referencing against vulnerability data that updates daily instead of training data that's frozen. This means scanning for vulnerable dependency versions against live databases, not static rule sets. It means analyzing the full project graph instead of isolated diffs, since vulnerabilities frequently emerge from how files interact rather than from any single file in isolation. And it means flagging deprecated or insecure patterns the moment they're introduced, not in a retrospective audit weeks later.

This is the gap Ixtli is built to close, normalizing OSV, NVD, and GitHub Advisories into a single engine that checks every PR against what's known today, not what was known when the model generating the code was trained. The point isn't to slow down AI-assisted development. It's to make the review process move at the same speed the code does.

What this means for your workflow

If you're shipping AI-assisted code, and at this point, almost everyone is, whether deliberately or as a byproduct of using modern editors, the relevant question isn't whether to trust the AI. It's whether your review process can keep pace with what it's producing.

A few things worth checking regardless of how your team writes code:

Risk	Why training-data lag makes it worse	What to do
Outdated dependency versions	Model recommends packages safe at training time, vulnerable now	Scan against live CVE databases on every PR
Deprecated security patterns	Old patterns (e.g. `verify=False`) persist in training data	Flag at commit time, not in quarterly audits
Cross-file vulnerabilities	Diff-based review misses interaction effects	Analyze full dependency graph, not isolated changes
Volume exceeding reviewer bandwidth	More code, same number of reviewers	Automate the first pass; humans review what's flagged

The skill of the person writing the code matters less here than most people assume. What matters is whether the system around that code can verify it against reality as it exists today, not as it existed when the model was trained.

If your team is shipping faster than your review process can verify, that gap doesn't close itself, it just gets wider as the codebase grows. Worth checking before it becomes the kind of thing you find out about from a security researcher instead of a teammate.

A single XSS can kill your startup

Fernando Gallardo — Tue, 30 Jun 2026 01:51:07 +0000

A single XSS can kill your startup

Everyone talks about churn from bad UX, slow load times, confusing onboarding, a button that doesn't work on mobile. The discourse around "losing users" is almost entirely product-focused.

Nobody talks about what happens when your update endpoint serves a javascript: URI to every user who checks for a new version. Or when your release notes field, the one that accepts markdown, gets used to inject a script tag into every client that renders it. Or when your static release token has no rate limiting, so an attacker has unlimited attempts to brute-force it.

These aren't theoretical scenarios, they're the kinds of findings that show up in a routine PR audit on a Tool version management system. And unlike a broken modal or a confusing signup flow, you don't get a Hotjar recording that tells you something went wrong. You get a breach report or you get silence, and find out six months later.

The vulnerability that doesn't look like one

Here's what a real pull request looked like recently, flagged during a security audit:

class ArtifactCreate(BaseModel):
    platform: str
    arch: str
    url: str  # accepts any URI
    sha256: Optional[str] = None

Four fields, No validation, The url field accepts https:// but it also accepts javascript:alert(document.domain), data:text/html,<script>..., and http://internal-svc:8080/admin.

When your Tool auto-update endpoint returns this URL and a client renders it, that's XSS. When your own Tool follows the URL to download a binary, that's SSRF and depending on your cloud setup, that could mean access to internal services, metadata endpoints, or worse.

The fix is four lines:

from typing import Literal
from pydantic import HttpUrl

class ArtifactCreate(BaseModel):
    platform: Literal["linux", "darwin", "windows"]
    arch: Literal["amd64", "arm64"]
    url: HttpUrl
    sha256: Optional[str] = Field(None, min_length=64, max_length=64)

But the point isn't the fix. The point is that this code shipped, reviewed, merged, deployed because nobody was looking at it from a security perspective. The developer wasn't careless, they were moving fast.
That's the context in which most startup code gets written.

What a compromised release token actually costs you

The same PR had a second issue: a static TOOL_RELEASE_TOKEN with no rate limiting on the authentication endpoint and no rotation mechanism.

Walk through what that means in practice:

An attacker brute-forces the token, no lockout, no throttle, unlimited attempts. They now have the ability to publish a fake Tool version with a malicious download URL.
Your users run tool update, they download and execute a binary from an attacker-controlled server and every machine that auto-updated is now compromised.

You don't know until someone reports it or until you see it in your access logs and realize what happened or until a security researcher publishes it.

The business cost isn't just remediation, it's the announcement you have to send to users, it's the news cycle if you're big enough, it's every enterprise customer who now has a security incident on their hands because of your tool. It's the contracts that get paused pending a security review. It's the investors who ask uncomfortable questions on the next call.

A static token with no rate limiting isn't a medium-severity finding, It's a supply chain attack waiting for someone with time and motivation.

Stored XSS is slower and worse

XSS via a javascript: URI is dramatic, stored XSS is quieter and harder to detect.

The same audit found that release_notes, a markdown field returned in API responses, was stored without sanitization. Any client that renders this content as HTML executes whatever's in it.

The attack vector: whoever controls the release token (or whoever gains access to the GitHub Action that uses it) can inject a payload into release_notes. It sits in your database and every user who queries your version endpoint gets it back.
If they're using a web-based dashboard, an Electron app, or any client that renders markdown to HTML, the script runs.

The insidious part is that this doesn't trigger on write, it triggers on read, potentially weeks or months later, across every client simultaneously.

Sanitizing on storage takes ten minutes:


import bleach

ALLOWED_TAGS = bleach.sanitizer.ALLOWED_TAGS | {"p", "pre", "code", "h1", "h2", "h3"}

def sanitize_release_notes(content: str) -> str:
    return bleach.clean(content, tags=ALLOWED_TAGS, strip=True)

The gap between "ten minutes to fix" and "six months of exposure" is that nobody thought to add it during the initial implementation. That gap is where startups get hurt.

The real question is what you're not seeing

These findings came from auditing one PR on one endpoint. A Tool version management route, not the authentication system, not the payment flow, not the data pipeline. One endpoint.

In our experience analyzing production codebases, the ratio holds pretty consistently: for every vulnerability someone finds during a focused review, there are several more in the surrounding code that nobody was looking at. Not because the team is negligent, but because security review requires a different mode of reading than code quality review.

A senior engineer reading this PR would catch the missing Literal types, probably flag the str on url as sloppy. But they'd need to be specifically thinking "what can an attacker do with this?" to trace the full exploit chain from a malicious URL in the database to code execution on user machines.

That's not a criticism of how developers read code, it's just a different skill set, applied at a different moment. Tools like Ixtl exist specifically to run that analysis at PR time before the code ships, while it's still cheap to fix, without requiring a dedicated security engineer on the team.

What it actually takes to close a startup

You don't need a nation-state attacker, You don't need a zero-day, You need:

One leaked GitHub Actions secret
One endpoint with no rate limiting
One Tool that auto-updates

And you can push a malicious binary to every user who runs your tool.

For a startup with enterprise customers, that's not a security incident, it's an existential one. One customer's security team reports it, the others hear about it, You spend the next quarter doing damage control instead of building product.

Vulnerability	Attack Vector	Business Impact
Unvalidated url field	XSS / SSRF	User machines compromised via auto-update
Stored XSS in `release_notes`	Payload delivery at scale	All clients exposed simultaneously
No rate limiting on token auth	Brute-force → full access	Supply chain compromise
Static token, no rotation	Indefinite exposure post-leak	No recovery path without redeployment

The conversation about why startups fail is almost entirely about product, market fit, and runway. Security failures don't show up in postmortems because most companies don't publish postmortems when they get breached.
They just quietly disappear, or spend years rebuilding trust they didn't know they were losing.

What to do before you ship

None of this requires a security team, it requires asking a different question during code review: what happens if someone uses this input maliciously?

For the specific issues above, the checklist is short:

Validate URL schemes, HttpUrl in Pydantic, or a custom validator that blocks everything except https:// to known domains
Sanitize any field that stores user-controlled content and gets returned in API responses
Add rate limiting to any endpoint that uses token-based auth, 5 requests per minute is enough to make brute-force infeasible
Rotate static secrets; use GitHub OIDC for CI/CD instead of long-lived tokens when possible

These are 30-minute fixes, individually. The hard part is knowing you need them before someone else figures it out first.

If you want a second opinion on what's in your PRs before they merge, ixtli.app runs this kind of analysis automatically not just on the diff, but across the full dependency graph of the project. The findings above were caught before the code shipped.
That's the only time catching them is cheap.

--
If this was useful, share it with the engineer on your team who reviews PRs. Not because they're doing something wrong but because this is the kind of thing that's easy to miss and expensive to learn the hard way.

How to write a good pull request description

Fernando Gallardo — Thu, 18 Jun 2026 16:00:00 +0000

A pull request without a description is a puzzle with missing pieces.

The reviewer has to reconstruct what you were trying to do, why you did it this way, and what could go wrong, from the code alone. That’s not a review, it’s archaeology. And it’s why so many PRs get approved with a “LGTM” that doesn’t mean anything.

A good PR description isn’t bureaucracy. It’s the thing that makes your change reviewable — and therefore mergeable — without three rounds of back-and-forth.

Why most PR descriptions fail

The most common PR descriptions look like this:

”Fix bug”
”Update user service”
”WIP”
”Changes per feedback”

These tell the reviewer nothing. They don’t explain what the bug was, what broke, what the fix does, or how to verify it works. The reviewer is starting from zero.

The second most common failure is the opposite: a description that’s just a list of every file changed, copy-pasted from the diff. That’s also useless, it describes what changed, not why.

A good description answers the questions a reviewer would ask if they could.

The goal is to make the review faster and the approval more confident.

What to include in a pull request

A PR description that actually helps has four components. None of them are long, a good description for a focused PR can be under 150 words. The point is structure, not volume.

1. What this change does (2-4 sentences)

Not a list of files. Not a commit log. A plain explanation of what problem this PR solves and what it does to solve it.

This PR adds rate limiting to the /auth/login endpoint. Witout it, the endpoint can be used for credential stuffing with no hrottling. The implementation uses a sliding window counter in Redis with a 60-second TTL.

2. Why this approach

If there were alternative implementations you considered and rejected, say so.

This prevents reviewers from suggesting alternatives you already evaluated, and it shows your reasoning.

We considered using an in-memory counter, but that doesn’t work across multiple instances. Redis was already in the stack, so the overhead is minimal.

3. How to test it

Specific steps. Not “run the tests”, which tests? Where? Under what conditions?

Start the service locally with docker compose up

Hit /auth/login more than 10 times in 60 seconds with any credentials

The 11th request should return 429

4. What’s out of scope

This one gets skipped most often, but it prevents the review from expanding into territory you didn’t intend to cover.

This PR doesn’t address rate limiting on other endpoints. that’s tracked in #412.

Pull request best practices for developers

Beyond the description itself, there are a few pull request best practices that consistently improve review quality:

Keep PRs focused. A PR that does one thing is easier to review than one that does three. If you’re fixing a bug and refactoring a module and updating a dependency, that’s three PRs, or at minimum, a description that clearly separates the three concerns.

Link to the issue or ticket. The PR description doesn’t need to contain all the context, it needs to point to where the context lives. A link to the relevant issue, Jira ticket, or design doc is worth more than a paragraph trying to summarize it.

Don’t self-review your own PR right after writing it. The gap between writing code and reviewing it needs to be longer than five minutes. Come back to it after a break, or ask for a review first and do your own pass after seeing the comments.

Add a screenshot or recording for UI changes. A reviewer who can see the before/after state will spot visual regressions that are invisible in a diff.

The security section most teams skip

There’s one section most PR templates don’t include: a note on security implications.

Not every PR needs this, a typo fix doesn’t. But any PR that touches authentication, authorization, input handling, file uploads, external APIs, or new dependencies should include a line or two about what the security surface is and how it’s handled.

This doesn’t need to be a formal threat model. It can be as simple as:

Security: This endpoint accepts file uploads. Files are validated for MIME type and size limit before being written to S3. No user-supplied file path is used.

Or:

Dependencies: Added jsonwebtoken@9.0.2. Checked against OSV, no known CVEs. Replaces the unmaintained jwt-simple package.

Teams that use automated security analysis in CI can use that output as a reference, if the scanner flagged something, the PR description should acknowledge it and explain how it was resolved. Platforms like Ixtli produce per-PR security summaries that make this easy to include without doing the research manually.

A template you can actually use

Here’s a minimal template that covers the essentials. Adapt it to your team’s conventions, the point isn’t to fill out every field for every PR, it’s to make the important fields habitual.

GitHub

## What

[1-3 sentences: what problem does this solve and how]

## Why this approach

[Optional: alternatives considered and why they were rejected]

## How to test

[Specific steps to verify the change works]

## Out of scope

[What this PR explicitly doesn't cover]

## Security notes

[Optional: relevant security surface, how it's handled, or "no security impact — [reason]"]

Keep it in a .github/pull_request_template.md file and GitHub will auto-populate it for every PR.

GitLab

Keep it in a .gitlab/merge_request_templates/Default.md

Example

my-project/
├── .gitlab/
│   └── merge_request_templates/
│       └── Default.md
├── src/
└── README.md

## What

Describe the change and the problem it solves.

## Why

Why was this implementation chosen?

## How to test

Steps to verify the change works.

## Risks

Potential side effects or areas that may be impacted.

## Security impact

- [ ] No security impact
- [ ] Authentication / Authorization
- [ ] Input validation
- [ ] Secrets / Credentials
- [ ] Data exposure
- [ ] Infrastructure / Configuration

Conclusion

A PR description is not documentation for posterity. It’s communication for the reviewer who has to understand your change in the next 20 minutes.

The investment is small — 10 to 15 minutes to write a description that gives your reviewer everything they need. The return is a review that’s faster, more accurate, and less likely to require three rounds of clarification.

If your team’s PRs consistently lack context, the easiest fix is a template in the repo. Add it this week. If you want to take the security side further

without making it a manual process, ixtli.app integrates directly into the PR workflow.

Cómo hacer una buena revisión de código

Fernando Gallardo — Thu, 18 Jun 2026 03:08:01 +0000

Revisar código es una de las actividades más subestimadas del desarrollo de software.

La mayoría de los equipos la tratan como un trámite, algo que hay que aprobar antes de mergear. El resultado es que los PRs se aprueban con un “LGTM” después de dos minutos de scroll, y los problemas reales pasan de largo.

Una revisión bien hecha no es leer línea por línea buscando typos. Es entender qué intenta hacer ese código, si lo hace de la manera correcta, y si introduce riesgos que no existían antes. Eso requiere un proceso, no un instinto.

Este artículo cubre cómo estructurar ese proceso: qué revisar, en qué orden, qué preguntas hacer, y cómo detectar problemas de seguridad sin ser un experto en ciberseguridad.

Empieza por el contexto, no por el código

El error más común en code review es abrir el diff y empezar a leer desde la primera línea modificada. Antes de ver una sola línea, necesitas entender qué problema resuelve este cambio.

Lee la descripción del PR. Si no hay descripción, o si dice “fixes bug”, ya encontraste el primer problema. Un PR sin contexto obliga al reviewer a reconstruir el razonamiento del autor desde cero, y eso aumenta la probabilidad de aprobar algo que no debería aprobarse.

Lo que un buen PR debe explicar:

Qué cambia no cómo, sino qué problema resuelve
Por qué este approach si hay alternativas que se descartaron, decirlo
Cómo probarlo, pasos para verificar que funciona
Qué no cubre, scope explícito evita confusiones

Si tienes esa información antes de ver el diff, tu revisión va a ser significativamente más efectiva.

Qué revisar y en qué orden

No toda línea de código merece el mismo nivel de atención. Un buen reviewer distribuye su energía de forma inteligente.

Primero: arquitectura y flujo de datos. ¿El cambio tiene sentido a nivel de diseño? ¿Agrega una dependencia innecesaria? ¿Rompe alguna abstracción existente? Esto es lo más difícil de cambiar después.

Segundo: lógica de negocio. ¿El código hace lo que dice que hace? ¿Los edge cases están cubiertos? ¿Qué pasa si el input viene vacío, nulo, o malformado?

Tercero: seguridad. Este punto merece su propia sección.

Cuarto: legibilidad y convenciones. Nombres de variables, estructura de funciones, comentarios. Importante, pero no el punto de partida.

La mayoría de los reviewers hacen esto al revés, empiezan por los detalles de estilo y llegan agotados a lo que realmente importa.

Cómo detectar problemas de seguridad en code review

Detectar vulnerabilidades durante un code review no requiere ser un especialista en seguridad. Requiere hacerse las preguntas correctas.

Hay patrones que aparecen consistentemente en PRs problemáticos:

Entradas sin validar. ¿Los datos que vienen del exterior (usuario, API, archivo) se usan directamente sin sanitizar? Cualquier lugar donde un string externo toca una query, un path de archivo, o una llamada a sistema es candidato a revisión.

Manejo de errores que expone información. Stack traces devueltos al cliente, mensajes de error con rutas internas, logs que incluyen tokens o passwords. Esto pasa más de lo que parece.

Dependencias nuevas. Cada npm install o pip install que aparec en el diff es una superficie de ataque potencial. ¿Se revisó el paquete? ¿Tiene CVE conocidos? ¿Cuántos mantenedores activos tiene?

Secrets hardcodeados. Claves API, tokens, URLs de bases de datos. Son más comunes de lo que cualquier equipo quiere admitir.

Algunos equipos integran análisis automatizado directamente en el flujo de revisión para que estos patrones se marquen antes de que el reviewer los vea. Herramientas como Ixtli, por ejemplo, analizan el diff completo del PR contra el grafo de dependencias del proyecto, no solo las líneas cambiadas, lo que hace que ciertos tipos de vulnerabilidades sean mucho más difíciles de pasar por alto.

Cómo dar feedback que sirva

El objetivo de un comentario en un code review no es demostrar que encontraste algo malo. Es que el código mejore.

Algunas reglas que hacen una diferencia real:

Sé específico. “Este código es confuso” no ayuda. “Esta función hace tres cosas distintas, considera extraer la lógica de validación a una función separada” sí ayuda.

Distingue entre bloqueante y sugerencia. No todo comentario debe impedir el merge.

Prefija con [bloqueante], [sugerencia] o [nitpick] para que el autor sepa qué es crítico y qué es opcional.

Pregunta antes de asumir. Si algo no se entiende, pregunta. “¿Por qué se usa setTimeout aquí en lugar de un event listener?” es mejor que asumir que es un error.

Aprueba cuando está listo. No sigas agregando comentarios menores una vez que los problemas reales están resueltos. El proceso de review también tiene un costo.

Checklist para code review

Antes de aprobar un PR, recorre estos puntos:

| Área | Pregunta |

|------|---------|

| Contexto | ¿El PR tiene descripción clara de qué resuelve? |

| Diseño | ¿El cambio tiene sentido arquitectónico? |

| Lógica | ¿Los edge cases están cubiertos? |

| Seguridad | ¿Hay entradas sin validar, secretos expuestos, o dependencias nuevas sin revisar? |

| Tests | ¿Los tests cubren los casos relevantes, no solo el happy path? |

| Deuda técnica | ¿El cambio deja el código en mejor estado del que lo encontró? |

No es una lista para leer rápido. Es una lista para detenerse en cada punto.

Conclusión

Una buena revisión de código no es más lenta que una mala, es más intencional.

La diferencia está en saber qué buscar y en qué orden.

Si tu equipo trata los PRs como trámites, el problema no es el código, es el proceso.

Empezar a usar un checklist consistente, pedir descripciones reales en cada PR, y separar los comentarios bloqueantes de las sugerencias son cambios que se pueden implementar esta semana sin herramientas adicionales.

Para la parte de seguridad, revisar manualmente cada dependencia nueva o cada input sin validar es costoso en tiempo. Vale la pena evaluar qué parte de ese trabajo puede automatizarse, ixtli.app está construido específicamente para ese slice del proceso.