SAST · SCA · Secretos · Revisión manual · OWASP Code Review · ASVS
Auditoría de código fuente
SAST + SCA + detección de secretos + revisión manual experta sobre tu repositorio. Lo que el escáner ve y lo que solo ve un humano: lógica de autorización, criptografía aplicada, configuración por entorno, supply chain, IaC. Cada hallazgo con archivo:línea, snippet corregido y, cuando aplica, pull request propuesto listo para revisar.
Resumen ejecutivo
La auditoría de código fuente encuentra lo que la auditoría externa (web, API) no puede ver: lógica defectuosa que se ejecuta pero parece funcional, criptografía mal usada que cifra correctamente con primitivas débiles, secretos hardcoded olvidados en el historial Git, dependencias vulnerables que el escáner SCA marca como críticas pero que en tu contexto no son explotables, configuración por entorno que abre puertas sin que se note.
Proyectos típicos en Hard2bit cierran entre 10 y 60 días laborables según volumen. Combinamos SAST, SCA y detección de secretos automatizada con revisión manual experta en el stack del cliente. Cada hallazgo viene con archivo:línea, snippet corregido y, en muchos casos, pull request propuesto. Apto para sostener auditoría PCI DSS, ISO 27001, ENS, NIS2 y DORA.
SAST + manual = profundidad real
El escáner amplifica cobertura; el humano valida y encuentra lo que solo se ve entendiendo el dominio. Sin uno de los dos, la auditoría se queda corta.
Auditor-ready
Informe diseñado para pasar auditoría externa: PCI QSA (req. 6.2.3/6.2.4), ISO certifier, ENS, NIS2, DORA, exigencias de cliente enterprise.
Remediación práctica
Cuando es trivial, traemos pull request propuesto. Cuando es estructural, recomendación detallada con código de ejemplo. No solo descripciones genéricas.
Qué cubrimos en una auditoría de código
La base metodológica es OWASP Code Review Guide v2. Añadimos verificación ASVS L2/L3, controles específicos del sector y un patrón propio de revisión por capas que abarca código de aplicación, infraestructura como código (IaC), pipelines de CI/CD y dependencias.
Autenticación y sesión
Implementación de login, MFA, recuperación de contraseña, gestión de tokens (JWT/OAuth), expiración, regeneración, lockout, almacenamiento seguro de credenciales (bcrypt/argon2 con cost factor).
Autorización y control de acceso
Verificación de permisos en cada endpoint y operación, RBAC/ABAC bien implementado, IDOR a nivel de código, multi-tenant: que el filtro por tenant esté en cada consulta sin excepciones.
Entrada de usuario y salida
Validación de entrada, prepared statements (no concatenación SQL), encoding correcto al renderizar (anti-XSS), parseo seguro de XML/JSON/YAML, sanitización de uploads, anti-deserialization.
Criptografía aplicada
Algoritmos modernos (no MD5/SHA1/DES), generación segura de aleatorios (no Math.random), gestión de IVs/nonces, padding correcto, almacenamiento de claves separado del código.
Lógica de negocio
Validaciones que viven en el lugar correcto (no solo cliente), aprobaciones con verificación de privilegios, condiciones de carrera, idempotencia en operaciones financieras, manipulación de precios/totales/status.
Gestión de secretos
Detección de secretos en código y todo el historial Git, no solo HEAD. Verificación de validez actual cuando es posible. Recomendación de rotación con timeline.
Dependencias y supply chain
SCA con SBOM, análisis de explotabilidad real de CVEs en tu contexto, dependencias transitivas, riesgo de paquetes de bajo mantenimiento, ataques typosquatting npm/PyPI, integridad de lockfiles.
Infrastructure as Code
Terraform/CloudFormation/Bicep: configuraciones inseguras (buckets públicos, security groups abiertos, encriptación desactivada), drift entre IaC y estado real, secretos en estado.
CI/CD pipelines
GitHub Actions/GitLab CI/Jenkins: permisos de tokens, secrets manager, escape de workflows, ejecución de código de PRs externos, supply chain de imágenes Docker base.
Logging y auditoría
Que se logueen eventos de seguridad relevantes (login, cambios de privilegios, acceso a datos sensibles), que NO se loguee información sensible (PII, tokens, contraseñas).
Configuración por entorno
Diferencias dev/staging/prod, debug activado en prod, headers de seguridad ausentes según entorno, CORS abierto en dev replicado en prod por error.
AI/LLM en código
Si el código consume LLMs: prompt injection, leaks de datos en system prompts, validación de outputs antes de ejecución, secretos pasados al LLM sin filtrar.
Anatomía de un hallazgo crítico
Patrón técnico real anonimizado: secreto hardcoded en repositorio público de empresa mediana, con derivadas: validez confirmada, ventana de exposición de 18 meses, procedimiento de rotación urgente.
Descubrimiento
API key de pasarela de pago en src/config/stripe.ts
Gitleaks detectó el patrón en línea 14 del fichero src/config/stripe.ts:
const STRIPE_KEY = "sk_live_...". Revisión del historial Git
mostró que el commit que introdujo el secreto fue de hace 18 meses. La sustitución
posterior por process.env.STRIPE_KEY no eliminó el secreto del
historial. Repositorio era privado pero accesible para 23 empleados activos, 4
ex-empleados y un proveedor externo.
Severidad
CVSS 4.0 = 9.6 + ventana de 18 meses
Verificación pasiva confirmó que la clave seguía siendo válida y con permisos de producción. Impacto potencial: emisión de cobros, refunds, acceso a histórico de transacciones, posible enumeración de clientes. Ventana de exposición de 18 meses con 28 personas con acceso al repositorio en algún momento de ese período. Riesgo regulatorio adicional: si los 4 ex-empleados conservaron clon local, exposición indefinida.
Evidencia
Documentación trazable
Captura del fichero en commit original, del commit que pretendió eliminarlo (mostrando que solo cambió el código actual, no el historial), del output de Gitleaks con fingerprint del secreto, y de la verificación de validez (sin extraer datos, solo comprobando que el endpoint de info de cuenta respondía 200 OK). Listado de identidades con acceso al repositorio en la ventana.
Remediación
Rotación urgente + limpieza histórica
Inmediato (2 horas): rotación de clave en pasarela, despliegue con nueva clave vía
secrets manager. Medio plazo (1 día): purga del historial Git con
git filter-repo, force-push, notificación a todos los
colaboradores para re-clonar. Largo plazo: pre-commit hooks con Gitleaks en todas
las máquinas de desarrollo, escaneo en CI bloqueante, política de gestión de
secretos documentada y formación a desarrollo.
Caso técnico anonimizado basado en patrones reales. Sector y nombres alterados; el patrón técnico y el procedimiento de remediación mantienen fidelidad al original. Sin NDAs públicos, sin nombre de cliente.
Cuándo encaja y cuándo no
Encaja muy bien
Cuándo merece la pena
- Producto SaaS, software propio, fintech, healthtech, software factory
- Aplicación con módulo de pago, datos especiales o flujos críticos
- Auditor exige evidencia (PCI DSS, ISO 27001, ENS Alta, NIS2, DORA, cliente enterprise)
- Cambio de equipo de desarrollo: heredar con baseline conocido
- Post-incidente sospechoso de origen en código
- Tras una auditoría web/API con muchos hallazgos: para encontrar la raíz
- Antes de migrar a cloud o entrar en mercados regulados
Encaja menos
Cuándo no es lo primero
- Producto basado mayoritariamente en servicios SaaS de terceros (poca lógica propia)
- Código en refactor mayor: cualquier hallazgo cambia en pocas semanas
- Si solo necesitas validar comportamiento externo: auditoría web o API son más eficientes
- Necesidad inmediata de respuesta tras incidente: primero respuesta a incidentes; auditoría después
- Equipo de desarrollo aún sin práctica de revisión de código: empezar implantando proceso interno antes que auditar
Cómo lo entregamos
Cuatro fases reales. La diferencia con un proveedor de SAST estándar es que el cliente recibe hallazgos con contexto y, donde es viable, código corregido propuesto.
1. Walkthrough y setup (1-3 días)
Sesión con tech lead o senior dev. Entendemos arquitectura, módulos críticos, lenguajes, frameworks, modelo de despliegue. Acordamos modo de acceso al código (clon local con NDA, VDI cliente, aislamiento físico). Configuramos SAST/SCA/secretos adaptado al stack y ejecutamos primera pasada automatizada.
2. Revisión manual experta (60-75% del tiempo)
Auditor con experiencia en el stack revisa los hallazgos del SAST (filtrando falsos positivos), audita manualmente los módulos críticos (autenticación, autorización, criptografía, integraciones, IaC), valida lógica de negocio con el código en mano. Hallazgos críticos se notifican en el momento, no se guardan.
3. Documentación y propuesta de PRs
Cada hallazgo con archivo:línea, snippet original, snippet corregido, CVSS 4.0, impacto, condiciones de explotación. Para hallazgos cuya remediación es trivial preparamos PR propuesto en la rama feature/security-audit-fixes que el equipo de desarrollo puede revisar y aplicar directamente.
4. Cierre y revalidación
Sesión de 90 minutos con tech lead y senior devs para discutir hallazgos, plan de remediación, priorización real. Si se contrata revalidación, segunda pasada a las 4-8 semanas verificando que las correcciones funcionan, con carta de verificación firmada para auditor externo.
Qué incluye el paquete documental
1. Informe técnico
Cada hallazgo con archivo:línea, snippet original, snippet corregido, CVSS 4.0, impacto, condiciones de explotación, recomendación detallada.
2. Informe ejecutivo
2-3 páginas sin jerga técnica para dirección. Hallazgos en términos de negocio, riesgo agregado, plan de acción.
3. Matriz priorizada
Hallazgos ordenados por riesgo real: severidad + exposición + explotabilidad + esfuerzo. Lista accionable para sprint planning.
4. Pull requests propuestos
Para hallazgos triviales (60-70%): PR ya escrito en rama feature/security-audit-fixes listo para revisar y mergear. Acelera remediación.
5. SBOM + reporte SCA
Inventario completo de dependencias con SBOM en formato CycloneDX/SPDX, CVEs por dependencia con análisis de explotabilidad.
6. Repositorio de evidencias
ZIP firmado con timestamps, output de herramientas SAST/SCA/secretos, screenshots, logs de la auditoría. Apto para auditor externo.
Adaptación por sector
SaaS B2B y software factory
Foco en multi-tenant, autorización a nivel de objeto en código, secretos, dependencias, IaC. Compatible con SOC 2 si aplica. Producto típico necesita reportar evidencia a clientes enterprise.
Fintech y entidades financieras
PCI DSS 6.2.3/6.2.4 si toca CDE, DORA art. 24-27. Foco intensivo en criptografía (hashes de contraseñas, cifrado de PII, gestión de claves), flujos de pago, prevención de fraude, race conditions en transferencias.
Healthtech
RGPD art. 9 (datos especiales), integraciones HL7/FHIR. Foco en autorización por rol médico, audit logging completo de accesos a historia clínica, cifrado de datos en reposo y tránsito, retención y borrado seguro.
AAPP y servicios públicos
ENS según categorización. Foco en cumplimiento, accesibilidad (WCAG), identidad con Cl@ve, almacenamiento y borrado conforme a legislación, trazabilidad para auditor administrativo.
Retail y e-commerce
PCI DSS si toca pagos. Foco en lógica de carrito y precios (manipulación), prevención de fraude, abuso de cupones, race conditions de stock, integraciones con pasarelas de pago.
Software embebido / IoT con backend
Foco en firmware y backend asociado: gestión segura de OTA, autenticación de dispositivos, cifrado de comunicaciones, almacenamiento seguro de claves en dispositivo, validación server-side.
Encaje regulatorio
| Marco | Referencia | Qué exige y cómo lo cubrimos |
|---|---|---|
| PCI DSS v4.0.1 | Req. 6.2.3 y 6.2.4 | Revisión de código de aplicaciones que toquen el CDE antes de producción y tras cambios significativos. Apta para PCI QSA. |
| ISO 27001:2022 | A.8.29 / A.8.28 | Testing de seguridad en el ciclo de desarrollo + principio de codificación segura. Evidencia trazable para certificación. |
| ENS (Alta) | op.exp.2 / op.exp.5 | Análisis de vulnerabilidades en el ciclo y pruebas técnicas periódicas. Apta para auditoría ENS. |
| NIS2 | Art. 21.2.f | Políticas y procedimientos para evaluar la eficacia de las medidas. Periodicidad documentada y trazabilidad. |
| DORA | Art. 9 + 24-27 | Gestión de riesgo TIC en aplicaciones y programa de pruebas de resiliencia digital. Apta para supervisor financiero. |
| Executive Order 14028 (SBOM) | Mandato federal USA / NIS2 / DORA | SBOM en CycloneDX/SPDX para clientes que vendan a sector público USA o entidades reguladas EU. |
| RGPD | Art. 32.1.d | Verificación regular de la eficacia de medidas técnicas. Especialmente relevante si hay datos especiales (art. 9). |
Lo que solemos hacer y otros no
Pull requests propuestos
Para hallazgos triviales (60-70%) traemos PR ya escrito listo para revisar. Acelera la remediación de semanas a horas.
Historia Git completa para secretos
Muchos auditores escanean solo HEAD. Nosotros revisamos el historial completo: el 70% de secretos vivos están en commits antiguos que el equipo asumió 'eliminados'.
Verificación de validez de secretos
Cuando es viable y ético, comprobamos pasivamente si el secreto sigue activo. Cambia la prioridad de remediación drásticamente.
Análisis de explotabilidad de CVEs
No solo listamos CVEs de Snyk o Dependabot. Verificamos si el path vulnerable se invoca desde tu código. 30-50% son no explotables en contexto.
Revisión de IaC
Terraform, CloudFormation, Bicep: aquí se filtran buckets públicos, security groups abiertos, secretos en estado. Muchos auditores se centran solo en código de aplicación.
Auditor con stack del cliente
Auditor que sabe Java audita Java. Auditor que sabe Go audita Go. No asignamos un auditor que solo entiende patrones genéricos a un proyecto en Rust.
Objeciones que escuchamos y cómo las contestamos
«Ya pasamos Sonar/Snyk en CI, no necesitamos auditoría»
Sonar y Snyk son herramientas excelentes para amplitud y para frenar regresiones, pero ni una ni otra encuentran lógica defectuosa, mal uso de criptografía en contexto, o secretos en historia Git que estos escáneres no recorren. Una auditoría manual experta complementa, no sustituye, esa capa automatizada.
«Nuestro código es muy específico, no lo van a entender»
El walkthrough técnico inicial está pensado precisamente para eso. Si tras el walkthrough el auditor cree que el stack está fuera de su zona de confianza, te lo decimos honestamente y derivamos o renunciamos al proyecto. No aceptamos auditorías que no podamos hacer bien.
«El código es nuestro activo más sensible»
Trabajamos con NDA estándar, clon local en estaciones cifradas (sin nube), y certificado de borrado al cierre. Para entornos especialmente sensibles ofrecemos modo VDI en infraestructura cliente o aislamiento físico onsite. El código nunca se reutiliza.
«Es caro. Una auditoría puntual no escala»
Por eso entregamos PRs propuestos donde podemos: convertimos hallazgos en código aplicable. Y siempre proponemos al cierre cómo integrar lo aprendido en CI (reglas Semgrep custom, política de revisión, formación al equipo). La auditoría no es solo un informe, es transferencia de conocimiento.
«Tenemos millones de líneas, ¿auditáis todo?»
No. Auditamos lo crítico con profundidad y aplicamos SAST/SCA a todo. En proyectos grandes la propuesta es: revisión manual exhaustiva de módulos de autenticación, autorización, criptografía, pagos, integraciones; SAST/SCA sobre el resto; análisis selectivo de zonas que el SAST marque como alta densidad de riesgos.
«Si encontráis muchas cosas, ¿es bueno o malo?»
Es lo esperado y es bueno. Una auditoría que no encuentra nada en un proyecto real significa cobertura insuficiente o auditor que no entiende el dominio. Lo importante es: ¿los hallazgos son accionables? ¿la remediación es viable? ¿el riesgo real es proporcionado al esfuerzo de arreglarlo?
Cómo medimos calidad de nuestras auditorías de código
Seis indicadores internos benchmarkados contra histórico propio. Se comparten en sesión de cierre.
Líneas/día auditor
Productividad. Demasiadas LOC/día indica revisión superficial; demasiado pocas, ineficiencia.
Ratio falsos positivos SAST
Porcentaje de hits del escáner que descartamos tras revisión manual. Objetivo: <40% (entregamos hallazgos verificados, no output crudo).
Cobertura ASVS
Porcentaje de controles ASVS L2/L3 verificados en el código. Objetivo: 100% en módulos críticos.
PRs propuestos / hallazgos triviales
Porcentaje de hallazgos cuya remediación es trivial donde aportamos PR. Objetivo: >65%.
Tiempo de notificación crítico
Horas desde detección de hallazgo crítico hasta notificación al cliente. Objetivo: <8 horas laborables.
Tasa de revalidación cerrada
Porcentaje de hallazgos que el cliente cierra realmente en revalidación. Indicador de calidad de recomendaciones.
Errores habituales al contratar una auditoría de código
- Pedir 'pasar Sonar' y llamarlo auditoría. Es un primer filtro automatizado, no una revisión. Sin manual, te pierdes la lógica de negocio y la criptografía mal aplicada.
- No auditar el historial Git para secretos. El 70% de secretos vivos están en commits antiguos que el equipo asumió eliminados.
- Aceptar lista de CVEs sin análisis de explotabilidad. 30-50% de CVEs reportadas por SCA no son explotables en contexto; perder tiempo remediándolas es coste sin retorno.
- Ignorar IaC. Buckets públicos, security groups abiertos, claves expuestas en Terraform state son hallazgos típicos que no aparecen en código de aplicación.
- Confiar solo en el auditor genérico. Auditar Java con auditor que solo conoce Python deja huecos enormes. Pide perfil del auditor antes de firmar.
- No revalidar tras remediación. Sin segunda pasada, el informe no sirve para auditor externo.
- Dejar la auditoría para el final del release. Encontrar hallazgos críticos a una semana de salir a producción rompe el roadmap. Mejor anticipar.
- No integrar lo aprendido en CI. Sin reglas Semgrep custom + política de revisión, los mismos errores volverán en el siguiente release.
Glosario rápido de la jerga de code audit
SAST
Static Application Security Testing. Análisis estático del código sin ejecutarlo. Detecta patrones inseguros conocidos.
SCA
Software Composition Analysis. Análisis de dependencias y librerías de terceros. Detecta CVEs y problemas de licencia.
SBOM
Software Bill of Materials. Inventario de componentes del software. CycloneDX y SPDX son los formatos estándar.
DAST
Dynamic Application Security Testing. Análisis dinámico (sobre la app corriendo). Complementario a SAST.
OWASP Code Review Guide
Guía OWASP de referencia para revisión de código. Versión 2 publicada en 2017, en revisión continua.
OWASP ASVS
Application Security Verification Standard. Niveles L1, L2, L3 según criticidad.
Secrets scanning
Detección automatizada de secretos hardcoded en código y archivos de configuración. Herramientas: TruffleHog, Gitleaks, Semgrep.
Pre-commit hooks
Scripts que se ejecutan antes de cada commit local. Útiles para bloquear secretos y errores típicos antes de que entren al repo.
IaC
Infrastructure as Code. Terraform, CloudFormation, Bicep, Pulumi. Audita configuraciones de infraestructura como si fueran código.
Supply chain attack
Compromiso de una dependencia de terceros que se propaga a quien la usa. Casos recientes: npm easy-day-js, Codecov, SolarWinds.
Pull request
Solicitud de fusión de cambios en un repo Git. Punto natural para code review y para los PRs propuestos por auditoría.
Falso positivo
Hallazgo del escáner que tras análisis humano resulta no ser explotable o no aplica. La revisión manual los filtra.
Servicios relacionados en Hard2bit
Pentesting
Servicio madre. Auditoría de código es la disciplina white-box dentro del pentesting enterprise.
Ver →
Auditoría aplicaciones web
Complementaria. Web prueba comportamiento desde fuera; código prueba la implementación interna. Combinadas, cobertura completa.
Ver →
Auditoría de seguridad API
Si tu API es central, combinar con auditoría de código del backend que la sirve.
Ver →
Identidades no humanas
Donde más secretos hardcoded encontramos: tokens, API keys, certificados embebidos en código.
Ver →
Gestión riesgo terceros
Cadena de suministro de software es riesgo de terceros: programa para gestionarlo.
Ver →
Superficie de ataque
Vigilancia continua: detectar nuevos repositorios públicos expuestos, secretos filtrados, exposición tras releases.
Ver →
Auditoría integral
Cuando el alcance incluye también infraestructura, identidad, cloud y procesos: un único proyecto.
Ver →
Gestión de vulnerabilidades
Las CVEs detectadas en dependencias se gestionan en el programa de gestión de vulnerabilidades del cliente.
Ver →
Respuesta a incidentes
Si la auditoría revela compromiso activo (backdoor, secreto filtrado en uso), escalado a respuesta.
Ver →
Preguntas frecuentes
¿Qué diferencia hay entre SAST automatizado y auditoría de código manual?
SAST (Static Application Security Testing) escanea el código en busca de patrones conocidos: uso inseguro de funciones, configuraciones débiles, librerías vulnerables, secretos hardcoded con formato detectable. Es rápido, barato y se integra en CI/CD, pero genera muchos falsos positivos y se le escapan los fallos de lógica que requieren entender el dominio. La auditoría manual aporta lo que ningún escáner ve: lógica de autorización mal diseñada, condiciones de carrera, suposiciones de confianza implícita entre componentes, mal uso de criptografía que el escáner clasifica como verde, abuso de flujos legítimos. La combinación de ambos enfoques es lo estándar: SAST para amplitud, humano para profundidad.
¿Qué herramientas y metodología seguís?
Combinamos varias capas. SAST con SonarQube/Semgrep/CodeQL adaptado al stack del cliente. Análisis de composición de software (SCA) con Snyk/OSV-Scanner/Trivy para dependencias y SBOM. Detección de secretos con TruffleHog/Gitleaks. Sobre eso aplicamos OWASP Code Review Guide v2 como base metodológica, OWASP ASVS L2/L3 para verificación, y un patrón de revisión propio que cubre autenticación, autorización, gestión de sesión, criptografía aplicada, entrada de usuario, salida (XSS), integraciones con terceros, configuración por entorno, IaC (Terraform/CloudFormation/Bicep), CI/CD y supply chain. El equipo se forma con ingenieros con experiencia en desarrollo en el stack del cliente, no solo auditores de seguridad genéricos.
¿Cuánto dura una auditoría de código y cuánto cuesta?
Depende mucho del tamaño y complejidad. Un repositorio mediano (40-80 mil líneas de código, un stack, un equipo de desarrollo) se audita en 10-20 días laborables con 1-2 auditores. Coste orientativo: 12.000-28.000 euros. Monorepos grandes (200+ mil líneas, varios servicios, IaC, varios lenguajes) se mueven en 30-60 días y 40-90 mil euros. Antes de presupuestar pedimos acceso al repositorio para hacer un inventario inicial: lenguajes, frameworks, dependencias, complejidad ciclomática orientativa. Sin eso, cualquier número es inventado.
¿Necesitáis acceso completo al código? ¿Cómo se gestiona la confidencialidad?
Sí, acceso de lectura al repositorio. Trabajamos preferentemente sobre clon local del código en estaciones cifradas con NDA firmado, sin subir nada a la nube. Si el cliente prefiere que trabajemos sobre su entorno (clientless via VDI corporativo, repositorio interno con acceso temporal), también es viable. El código nunca se comparte con terceros, no se reutiliza en otras auditorías y se borra de nuestras estaciones al cierre del proyecto con certificado de borrado firmado. Para entornos especialmente sensibles (defensa, infraestructura crítica) podemos trabajar en aislamiento físico en cliente.
¿Auditáis solo lenguajes mainstream o también nicho?
Auditamos el stack que use el cliente. Mainstream: Java, .NET, Python, Node.js/TypeScript, Go, Ruby, PHP, Kotlin, Swift. Frontend: React, Vue, Angular, Svelte. Backend: Spring, ASP.NET, Django, FastAPI, Express, NestJS, Laravel. IaC: Terraform, CloudFormation, Bicep, Pulumi. Más específicos: Rust, Elixir, Scala, Clojure, COBOL legacy en banca. Si el cliente trabaja con stacks muy verticales (lenguajes propietarios, embebidos en industria), evaluamos en walkthrough si tiene sentido nuestro equipo o conviene un partner especializado. Nunca aceptamos un proyecto con stack que no manejemos para no defraudar.
¿Qué entregables damos al final del proyecto?
Cuatro piezas. Informe técnico con cada hallazgo (archivo:línea, snippet original, snippet corregido, severidad CVSS 4.0, contexto de explotación). Informe ejecutivo de 2-3 páginas. Matriz priorizada por riesgo real (no solo CVSS: considera exposición, explotabilidad y esfuerzo de remediación). Pull requests propuestos en GitHub/GitLab/Bitbucket para los hallazgos críticos cuya remediación es trivial (estimamos 60-70% de los hallazgos). Sesión de cierre con desarrollo. Si se contrata revalidación, segunda pasada que verifica las correcciones y emite carta de verificación apta para auditor externo.
¿Sirve como evidencia para PCI DSS, ISO 27001, ENS o NIS2?
Sí. PCI DSS v4 (req. 6.2.3 y 6.2.4) exige revisión de código de aplicaciones que toquen el CDE, antes de pasar a producción y tras cambios significativos. ISO 27001:2022 (A.8.29) requiere testing de seguridad en el ciclo de desarrollo, donde la revisión de código es uno de los componentes. ENS Alta (op.exp.2 y op.exp.5) exige análisis de vulnerabilidades en el ciclo. NIS2 (art. 21.2.f) requiere políticas y procedimientos para evaluar la eficacia de las medidas. DORA (art. 9 y 24-27) cubre testing de resiliencia. El informe se entrega listo para sostener auditoría externa.
¿Encontráis secretos hardcoded? Es muy frecuente.
Casi siempre. Combinamos Gitleaks/TruffleHog sobre todo el historial Git (no solo el HEAD) con revisión manual en patrones que los escáneres pasan por alto: secretos en comentarios, base64 codificados, fragmentados en varias constantes, en archivos .json/.yaml/.properties no escaneados por defecto. Los secretos encontrados se reportan con dos cosas adicionales que pocos auditores hacen: confirmación de si el secreto sigue siendo válido (con verificación pasiva del provider correspondiente cuando es posible y ético), y procedimiento de rotación con la huella temporal del secreto en repo para que el cliente pueda calcular ventana de exposición.
¿Qué hacéis con dependencias vulnerables? ¿Es solo listar CVEs?
No, eso es lo que hace un escáner SCA básico y lo que el cliente puede ver gratis con Dependabot o Renovate. Lo que aportamos es priorización por riesgo real, no por CVSS teórico: ¿la dependencia se usa o está como transitiva inactiva? ¿Hay path explotable desde el código del cliente o el componente vulnerable solo se invoca en contextos seguros? ¿Existe parche estable o solo workaround? ¿Hay versión sustituta sin breaking changes? El cliente recibe la lista priorizada por exposición real más recomendación de actualización: en general, 30-50% de las CVEs reportadas por SCA en proyectos reales no son explotables en el contexto concreto.
¿Cómo arrancamos un proyecto en Hard2bit?
Llamada de 30 minutos para entender el repositorio, el stack, el modelo de despliegue, el momento del ciclo (release, post-incidente, exigencia regulatoria) y el objetivo. Si tiene sentido, walkthrough técnico de 1-2 horas con un desarrollador para entender arquitectura, flujos críticos y zonas de mayor riesgo. Con eso emitimos propuesta firme en 48-72 horas: alcance, ventana, equipo asignado, entregables y precio cerrado. Sin compromisos hasta la firma. Si tras el walkthrough creemos que el proyecto necesita partir en fases o que conviene combinar con auditoría web/API, lo decimos honestamente.
¿Tu código necesita una auditoría seria?
Llamada de 30 minutos para entender el repositorio, el stack y el objetivo. Si tiene sentido, propuesta firme en 48-72 horas. Sin compromisos hasta la firma. NDA estándar previo al primer acceso al código.