Para garantizar un desarrollo seguro en el equipo offshore, ¿cuáles son las consideraciones a tener en cuenta en el SLA?
Conseguí esto como referencia: enlace
¿Alguien tiene plantillas y documentos de muestra para consultar?
Como dijo @Lucas, un abogado debe ser su primer punto de contacto, sin embargo, desde un nivel alto, puedo brindar orientación sobre las áreas a considerar. Estos son un pequeño subconjunto:
Y así sucesivamente ...
¡Consigue un abogado que sepa esto!
Excelente pregunta. Tratar los problemas de seguridad desde el principio: al encontrar un contratista, redactar un contrato, durante la definición de los requisitos y al definir la arquitectura, reducirá los costos de producción de software seguro para los desarrolladores y los riesgos y costos asociados para los clientes. Ganar-ganar.
Hay un gran escenario en el que las cosas pueden salir mal en estudio de caso hipotético de contrataciones de software seguro - OWASP .
Sugiero consultar el Anexo de Contrato de Software Seguro de OWASP como punto de partida para el tipo de idioma que desee para poner en su contrato. Esa página comienza con una rápida pregunta frecuente en la que se discuten preguntas espinosas como "¿Quién debería pagar por todas estas actividades?" Y cómo tratar con el código de terceros. Si su entorno de amenazas no es severo, y sus requisitos no son tan estrictos, puede relajarse un poco. O si está tratando con activos realmente valiosos y las amenazas son grandes, puede extenderlo.
Cubre estas áreas:
1. Introduction
2. Philosophy
3. Lifecycle Activities
4. Security Requirement Areas
5. Personnel And Organization
6. Development Environment
7. Libraries, Frameworks, And Products
8. Security Reviews
9. Security Issue Management
10. Assurance
11. Security Acceptance And Maintenance
De lo contrario, usted y su contratista podrían terminar gastando mucho dinero en abogados que debaten la aplicación legal de res ipsa loquitur .
IANAL, pero en base a mi experiencia en Y2K, donde con el software que cuidé hubo una gran cantidad de problemas, hay poco margen en la práctica para la restitución de los problemas. El mejor resultado para el cliente es resolver los problemas con el plena cooperación del proveedor. Los únicos que estarán mejor en tales disputas son los abogados.
Lo que esto significa en este contexto es que sus preocupaciones de seguridad se abordan mejor en su selección de un proveedor, lo que debe reiterarse en su contrato. Pero la existencia de requisitos en el contrato no reduce de ninguna manera su obligación de garantizar el cumplimiento del contrato antes y durante el desarrollo del servicio. Espere hasta después de que el servicio se despliegue antes de que descubra que el proveedor no tenía el código. En mi opinión, los controles de auditoría implementados hacen que sea su culpa, aunque el proveedor no esté cumpliendo con el contrato.
Pero con la mejor voluntad del mundo, las vulnerabilidades aún pueden introducirse en el código, por accidente o por diseño, por lo que sin duda merece la pena planificar esto en términos de respuesta a la resolución, definición del alcance de la responsabilidad y garantía de que el proveedor Poder realizar restitución en caso de culpabilidad. Dado que los costos potenciales resultantes de la vulnerabilidad del software pueden exceder en gran medida el costo del software en sí, no hay margen para (por ejemplo) usar el depósito en garantía.
De hecho, si observa el artículo, los puntos que hace sobre la seguridad (excepto las referencias a leyes específicas) se aplican a toda la funcionalidad del servicio.
A riesgo de aventurarse fuera del tema, en mi humilde opinión, la mejor solución es administrar la auditoría y la prueba del código (para todos los aspectos de la calidad) independientemente del proveedor, incluso si solo está replicando lo que dicen que ya están haciendo.
Yendo más allá, la seguridad del servicio también significa la disponibilidad continua. Tanto esto como el punto señalado en el párrafo anterior muestran un requisito claro de que tiene acceso al código fuente de la aplicación. Si bien la garantía financiera tiene muchos beneficios, en mi humilde opinión, la garantía del código fuente no sirve, en la práctica, a los intereses del cliente. NB: la propiedad de la propiedad intelectual no depende del acceso al código fuente, y específicamente al proporcionarle al cliente acceso al código fuente, no erosiona las responsabilidades de los clientes ni los derechos de propiedad intelectual de los proveedores.
Sin embargo, hay beneficios significativos para el cliente al poseer los derechos de autor sobre el código desarrollado, y donde hay cierta seguridad de la calidad, proporciona una posición de negociación útil para negociar contra la responsabilidad futura del desarrollador.
Lea otras preguntas en las etiquetas source-code legal code-review requirements outsourcing