Türkçe
English
English (US)
Azərbaycanca
ქართული
العربية
Deutsch
Français
Nederlands
Português
Italiano
Polski
Čeština
Slovenčina
Magyar
Slovenščina
Hrvatski
Bosanski
Srpski
Македонски
Shqip
Ελληνικά
Română
Български
Русский
Українська
Svenska
Dansk
Norsk bokmål
Suomi
Íslenska
Eesti
Latviešu
Lietuvių
Қазақша
Oʻzbekcha
Кыргызча
Türkmençe
Монгол
日本語
한국어
Bahasa Indonesia
Bahasa Melayu
ไทย
Tiếng ViệtSeguridad
Esta página dice qué protegemos y qué no podemos proteger. Un relato de seguridad que se deja la segunda parte invita al lector a confundir una lista con una garantía.
El punto de partida
Publicar un paquete significa ejecutar código en el equipo de cada ingeniero que lo instale. Todas las decisiones de seguridad de este producto se han pesado antes contra una pregunta: ¿este cambio facilita publicar sin autorización?
Los paquetes van firmados (ECDSA P-256)
El fichero de firma viaja dentro del paquete. Firma un manifiesto con los resúmenes de los ficheros, la identidad del paquete y su versión — no un simple resumen del archivo.
Si solo se firmara el resumen, un archivo antiguo correctamente firmado podría aparecer bajo un número de versión nuevo: la firma se verificaría y el usuario instalaría como «actualización» una herramienta con una vulnerabilidad conocida.
La clave privada NO está en el servidor
El servidor solo verifica. La firma se hace en el equipo del propio editor, con una herramienta aparte.
Si la clave estuviera en el servidor, quien se apoderase de él podría alterar un paquete y volver a firmarlo — con lo que firmar no serviría de nada.
El cliente también verifica
El complemento instalado en el equipo del ingeniero comprueba la firma por su cuenta, y la lista de claves de confianza que utiliza no viene del servidor.
La firma existe precisamente porque no se puede creer al servidor bajo palabra. Traer la lista de confianza de ese mismo servidor anularía en silencio la suposición de partida.
Un registro de auditoría que no se puede borrar
Cada publicación, cada cambio de autorización y cada decisión de canal se escribe de forma permanente. No hay, a propósito, ninguna vía de modificación ni de borrado, y la limpieza por retención no lo toca.
«Cómo ha llegado aquí esta herramienta» se suele preguntar meses después. Ese día, un registro que se hubiera podido borrar es un registro que nunca existió.
Regla de los cuatro ojos, opcional
Promover una versión a un canal más amplio puede exigir la aprobación de un segundo administrador, y quien la solicita no puede aprobar su propia solicitud. Volver atrás no exige aprobación nunca.
Viene desactivada. En un equipo de tres personas, la barrera se convierte en semanas en un mensaje que se aprueba sin leerlo; un control que se cree protector sin serlo es peor que no tener ningún control.
Extraer un archivo es en sí una superficie de ataque
Los archivos subidos se comprueban contra rutas maliciosas (zip-slip) y bombas de descompresión, y el tamaño extraído está limitado.
Extraer un archivo parece inofensivo. Uno preparado a propósito puede escribir ficheros fuera de la carpeta de destino o llenar el disco del servidor.
Acceso sin contraseña
Los usuarios entran con un código de un solo uso enviado a su correo. La sesión va sobre un testigo de vida corta; el testigo de renovación no es visible nunca para el código del navegador.
Si no hay un depósito de contraseñas que gestionar, no hay una base de datos de contraseñas que se pueda filtrar. Y reutilizar un testigo de renovación ya revocado se trata como señal de robo: la sesión se cierra.
Puede ver lo que está instalando
La carpeta de instalación incluye una lista de materiales legible por máquina (SBOM CycloneDX) y los guiones de migración para los dos motores de base de datos.
Su equipo de sistemas debe poder revisar lo que va al servidor antes de que vaya. Cuando se publica una vulnerabilidad en una dependencia, «¿la tenemos?» pasa a ser una búsqueda de fichero.
Lo que no podemos proteger
Esto no son huecos, son límites. Se deducen de la estructura, y afirmar lo contrario sería faltar a la verdad.
- Dos administradores que actúan juntos. La regla de los cuatro ojos para a uno, no a dos.
- El administrador de sistemas del servidor. Para quien tiene acceso a la base de datos y al sistema de ficheros, ningún control a nivel de aplicación es un obstáculo.
- El equipo donde está la clave de firma. La clave no está en el servidor, pero está en alguna parte; si cae esa máquina, cae la firma.
- El comportamiento malicioso deliberadamente oculto. Nuestra inspección de paquetes es heurística y no afirmamos que vaya a detectar código que intenta esconderse.
- La fuga de datos. Una herramienta instalada se ejecuta con los permisos propios del ingeniero y puede leer todo lo que esos permisos alcancen. Eso lo limitan los controles del sistema operativo y de la red, no este producto.
- La seguridad de sus copias de respaldo. La copia de la base de datos está en sus manos, y todo lo que contiene vale exactamente lo mismo que el sistema en marcha.
Informar de una vulnerabilidad
Si ha encontrado una, escríbanos. Nos tomamos los avisos en serio, no dejamos a quien avisa fuera del proceso y le decimos cuándo sale la corrección.