Desarrollo de software de outsourcing y su efecto en la seguridad

Yo diría que no hay nada per se que siempre lleve a que el software subcontratado sea menos seguro que un desarrollo interno, pero hay algunos factores comunes que en la práctica pueden llevar a que este sea el caso comúnmente

1. Preocupaciones de costos. Si un factor clave para ganar el trabajo es el bajo costo, es probable que aumente el riesgo de software inseguro. Cualquiera sea la forma en que lo haga, la seguridad del software cuesta dinero (las estimaciones iniciales de SDRC Microsofts SDL eran un 10% de gastos generales), por lo que cuando un tercero tiene que ser competitivo en cuanto a costos para ganar, los aspectos no funcionales del proyecto (por ejemplo, la seguridad) pueden verse afectados. Esto lleva al segundo punto.
2. No se describe adecuadamente el nivel de seguridad requerido en el contrato. Un problema general con la subcontratación es que el requisito debe quedar claro en el contrato. Es probable que las cosas que no están en el contrato no estén enfocadas (vea el punto 1). Es difícil especificar los requisitos exactos de seguridad en un contrato de software. Un lenguaje como "debería ser seguro" no es lo suficientemente prescriptivo para producir un buen resultado, y es probable que la empresa contratante y el proveedor externo tengan una idea muy diferente de lo que es "seguro".
3. "Mercado de limones". Además, tiene el problema general de que en el desarrollo seguro hay un mercado para los limones. Lo que significa esto es que es muy difícil para un comprador evaluar adecuadamente las prácticas de seguridad de una empresa de desarrollo. No hay realmente buenas calificaciones que puedan evaluarse y es poco probable que los compradores hagan el esfuerzo de evaluar manualmente el conocimiento de seguridad de los desarrolladores individuales.

Dicho todo esto, diría que es totalmente posible que una empresa de subcontratación produzca software más seguro que un equipo interno, la clave sería que la empresa compradora realmente priorice la seguridad de manera significativa durante la compra. proceso, realizar esfuerzos para evaluar los reclamos de las empresas licitadoras y tener buenos requisitos de seguridad descriptivos en el contrato.

Como regla general, un tercero involucra la seguridad. No significa que el producto (software u otro) no pueda ser seguro, pero agrega otro factor a la ecuación. Cosas a considerar:

1. Calidad del personal
2. La experiencia del tercero en la creación de software con un enfoque en la seguridad, es decir, la organización en su conjunto necesita el enfoque correcto, no solo los programadores
3. presupuesto
4. Disponibilidad de recursos internos para revisar el código y hacer un seguimiento del proyecto
5. Estipulaciones del contrato: si la seguridad es la prioridad que paga poner en requisitos mensurables para determinar el tercero entregado

Por nombrar solo algunos ...

Conclusión: es completamente posible obtener software seguro cuando se subcontrata, y cuando los programadores disponibles internamente no están a la altura del trabajo, no tiene muchas opciones. Sin embargo, en mi opinión, existe un riesgo adicional para siempre cuando se subcontrata que debe gestionarse adecuadamente para que funcione.

El nivel de seguridad que recibe del software está determinado casi en su totalidad por el talento y la experiencia de los desarrolladores de software, en lugar de la relación que tenga con ellos. Considere dos desarrolladores, llamémoslos A y B. A sabe cómo escribir el software de forma muy segura, y B no. Tanto A como B pueden ser contratados como empleados o como contratistas, y no hay razón para que escriban el software de manera diferente según el método que elija pagarles.

Dicho esto, aquí hay algunos factores potenciales que creo que podrían hacer una pequeña diferencia.

Pro Employee

• 3 meses después, el desarrollador se despierta en medio de la noche y se da cuenta de que tiene un error en el código, o que hay una mejor manera de hacer algo. Es más probable que el empleado tome medidas para solucionarlo que un contratista que ahora trabaja para otro cliente. (Aunque si el contratista considera que el problema es lo suficientemente importante, se esperaría al menos contactar al cliente).
• Si la riqueza personal de un empleado está directamente relacionada con el éxito de la empresa (como un propietario), tendrían un mayor incentivo para evitar desastres de seguridad, por lo que podrían gastar más energía para garantizar una mejor seguridad. (Por lo general, aunque es poco probable que los desarrolladores en el proyecto sean propietarios con suficiente capital para que esto importe, a menos que la empresa sea extremadamente pequeña).

Contratista profesional:

• Si la seguridad está bien definida en el alcance del proyecto, es posible que el contratista deba cumplir con el alcance para recibir el pago. A un empleado se le paga sin importar si hace el trabajo que se le pide que haga. (Podrían ser despedidos o despedidos, pero todavía se les pagaría por el trabajo hasta ese momento). En otras palabras, es más fácil que un empleado sea perezoso que un contratista.
• Es más probable que los contratistas / terceros hayan "hecho esto antes", ya que normalmente hacen proyectos más cortos que pueden ser similares a lo que usted está haciendo.

Nota final: la pregunta menciona específicamente a las agencias gubernamentales. Los empleados internos (que son desarrolladores de software) de organizaciones sin fines de lucro y agencias gubernamentales generalmente no tienen ninguna motivación financiera para el éxito de un proyecto, aparte del empleo continuo. Se podría argumentar que los contratistas y terceros en realidad tienen más incentivos financieros para tener éxito en este sentido. Por supuesto, hay otros incentivos más allá de los financieros, pero no los veo teniendo en cuenta la mentalidad del desarrollador con respecto a la seguridad.

Incluso cuando se contrata a desarrolladores externos altamente calificados y con buena reputación, la seguridad del código es una preocupación seria. Antes de firmar un contrato, asegúrese de especificar qué controles de seguridad y monitoreo se llevarán a cabo durante el ciclo de vida de la aplicación, y la responsabilidad del proveedor de outsourcing para corregir cualquier falla encontrada en una fecha posterior. Como las pruebas de seguridad son un ejercicio separado de las pruebas funcionales y operativas, debe quedar claro quién realizará estas pruebas y qué herramientas y métodos se utilizarán. Las pruebas deben cubrir todos los riesgos identificados en el contrato. Aunque el proveedor de outsourcing ejecutará sus propias pruebas de seguridad para verificar la robustez de su código, las pruebas con un tercero independiente especializado en seguridad de aplicaciones son esenciales para obtener una verificación y validación imparcial.

Hay tantas variables aquí. Hay buenos programadores y malos en todas partes. Si está buscando una respuesta simple a esto, no la obtendrá. No creo que obtendrás ninguna evidencia sólida que indique qué dirección tomar. Si está trabajando con un tercero de buena reputación, alguien que usted conozca es bueno. Como usted conoce su calidad de trabajo y sabe que utilizan buenas prácticas de codificación, puede tener una buena seguridad. Sí, puede limitar el riesgo de seguridad al utilizar terceros, pero saber quiénes son y cómo funcionan.