Como empresa de software, cada vez recibe con más frecuencia un cuestionario de seguridad de un cliente que está sujeto a la Ley de Ciberseguridad. La misma obligación de diligencia debida que vincula a su cliente hacia usted, también le vincula a usted: evaluar cuáles de sus propios proveedores influyen en la seguridad de lo que construye y entrega. Una política de proveedores es la forma de hacer esa evaluación repetible, en lugar de tener que repensar cada vez en quién confía realmente.
Respuesta corta: comienza con un inventario de quién está en su cadena de desarrollo y en su software entregado, clasifica esos proveedores según el riesgo que representan, y establece por categoría qué requisitos les impone y cómo lo verifica. Ese inventario y esa clasificación juntos forman la política de proveedores.
Dos tipos de proveedores, un punto ciego
En el desarrollo de software, dos cadenas se entrelazan, y eso hace que una política de proveedores sea más compleja que en una empresa que solo compra bienes físicos.
La primera cadena es su cadena de desarrollo: el gestor de código fuente, la canalización de CI/CD, el entorno en la nube donde construye, las herramientas para pruebas e implementación. Un punto débil allí afecta en primer lugar a su propia operación empresarial.
La segunda cadena es lo que termina en su producto: bibliotecas de código abierto, API de terceros, componentes comprados. Un punto débil allí no solo lo afecta a usted, sino también a cada cliente que usa su software. Esa distinción es precisamente donde muchas políticas de proveedores se quedan cortas: la atención se enfoca en la primera cadena porque es visible en el trabajo diario, mientras que la segunda cadena a menudo solo se hace visible en el momento en que algo sale mal.
Inventariar: comience con lo que ya está en funcionamiento
Una política de proveedores no comienza con una plantilla, sino con una lista. Para el desarrollo de software, eso significa como mínimo: qué proveedores de nube utiliza, qué gestores de paquetes y registros extrae su proceso de construcción, qué API externas llama su producto, y cuál de esos actores puede acceder a código, secretos o datos de producción.
Para cada proveedor, la pregunta no es solo qué hacen, sino qué sucede si se desconectan o se ven comprometidos. Un gestor de paquetes del que provienen cientos de dependencias pesa diferente que un paquete de facturación que funciona independientemente de la cadena de desarrollo.
Clasificación de riesgos: no todos los proveedores merecen la misma atención
Después del inventario viene una clasificación, generalmente en dos o tres niveles. Los proveedores con acceso al código fuente, secretos o entornos de producción requieren los requisitos más estrictos: autenticación fuerte, registro, un punto de contacto fijo en caso de incidentes. Los proveedores que solo contribuyen indirectamente, como una herramienta de planificación de proyectos, requieren menos.
La Directiva y la ley nacional no prescriben una clasificación fija; los supervisores observan si las medidas son proporcionadas al riesgo. Eso significa que la clasificación que elija debe ser justificable: por qué este proveedor cae en la categoría pesada y ese otro no.
Lo que pregunta y lo que usted ya responde
Una política de proveedores funciona en dos direcciones. Hacia el exterior, la usa para hacer preguntas a sus propios proveedores: cómo manejan las vulnerabilidades, tienen un proceso de verificación múltiple, qué tan rápido le notifican un incidente. Hacia el interior, forma la base para lo que usted responde en los cuestionarios de sus clientes, porque un cliente que lo evalúa a menudo quiere saber si tiene su cadena bajo control.
Ambos lados están conectados: una política de proveedores que usted redacte solo para sí mismo generalmente no se alinea con las preguntas que recibe de los clientes. Si establece la política desde el principio teniendo en cuenta lo que un cliente solicita, no tendrá que reescribirla más adelante.
Documentar: de la política a la prueba
Una política que solo existe en un documento de texto es difícil de sustentar cuando un cliente o autoridad reguladora la cuestiona. Es más práctico mantener un registro vivo: para cada proveedor, la categoría de riesgo, la evaluación más reciente, la prueba como una declaración, un certificado o una respuesta a su propio cuestionario de seguridad, y quién dentro de su organización supervisa a ese proveedor.
Un registro de este tipo no necesita ser grande para ser útil. Para una empresa de software con un puñado de proveedores críticos, una tabla con unas pocas columnas suele ser suficiente, siempre que se mantenga actualizada cuando cambia un proveedor o se renueva un contrato.
¿Desea saber primero si su organización está sujeta a la obligación de diligencia debida por sí sola, o solo se ve afectada a través de sus clientes? realice la verificación gratuita en unas pocas preguntas y lea en la página con todos los temas cómo la evaluación de proveedores se relaciona con otras obligaciones. ¿Curioso acerca de dónde proviene la información en esta plataforma y cuán actual es? Eso se explica en la página sobre cómo funciona. Quien desee convertir el registro de proveedores en un dossier con pruebas y responsables, encontrará en la página de suscripciones lo que se necesita para eso.