Tabla de contenido:
- Contratación de codificadores de respaldo
- Revisiones de código de conducta
- Evitar codificadores maliciosos
Video: 5 Negocios Digitales Fáciles que yo Empezaría en 2020 (todos se pueden empezar desde casa) (Noviembre 2024)
El 19 de julio de 2019, el programador por contrato David Tinley se declaró culpable de los cargos de haber dañado intencionalmente computadoras pertenecientes a Siemens Corporation. Según los documentos presentados en el caso, Tinley plantó bombas lógicas en el código que estaba desarrollando para Siemens en su ubicación de Monroeville, Pensilvania. Esas bombas lógicas, que eran secciones de código que fueron programadas para crear interrupciones semanas o meses después de que se terminara un proyecto, tenían la intención de garantizar que Tinsley tuviera un flujo constante de ingresos por tener que solucionar los problemas que se suponían que eran errores. Cuando lo llamaron para solucionar un problema, Tinsley simplemente cambió la fecha de la bomba lógica para que estallara nuevamente más tarde.
Contratación de codificadores de respaldo
Entonces, ¿por qué te cuento todo esto? Después de todo, las posibilidades de que contrates a un programador que deliberadamente ponga bombas lógicas en tu código personalizado no son grandes. Y aunque esas posibilidades no son cero, hay muchas otras cosas que pueden salir mal cuando alguien escribe código para su organización.
"¿Qué pasa si esa persona se va o cae muerta?" pregunta Jack Gold, analista principal de J. Gold Associates. Gold sugiere que cuando contratas a alguien para hacer un desarrollo, siempre necesitas una copia de seguridad. Después de todo, el código personalizado es su código. No hay un tercero al que pueda recurrir si algo sale mal, a menos que lo planee. También sugirió que hay algunas otras medidas que las empresas deben seguir para protegerse durante el proceso de desarrollo, entre las que se encuentran las revisiones obligatorias de códigos.
"Una revisión de código es probablemente la mejor manera de averiguar qué hay en su código", dijo Alan Zeichick, analista principal de Camden Associates, "incluyendo cosas como bombas lógicas, vulnerabilidades de seguridad o errores estúpidos".
"Hay otras razones para hacer revisiones de código", agregó Zeichick. "Ayuda a su equipo de desarrollo a comprender mejor cómo funciona el desarrollo, ayuda a los programadores junior a comprender mejor. Las revisiones de código también son buenas para ayudar al gerente del equipo a controlar la calidad del equipo de desarrollo y obtener una estimación de cuánto tiempo Tomará terminar el trabajo.
Revisiones de código de conducta
Zeichick dijo que hay un par de formas de realizar revisiones de código. "Puede tener un equipo donde haya dos personas trabajando en él o puede reunirse en una sala de conferencias para revisar el código".
Los equipos en los que cada miembro revisa el código de otra persona están creciendo en popularidad a medida que los programadores se vuelven más difíciles de encontrar. Pero en organizaciones más grandes, las reuniones periódicas para revisar el código siguen siendo útiles porque luego varios pares de ojos pueden ayudar en el proceso de revisión. Zeichick dijo que incluso los programadores más experimentados deberían revisar su código.
Entonces, ¿por qué Siemens permitió que Tinley fuera durante todos esos años sin una revisión del código? Según los comentarios de su abogado durante el juicio, Tinley consideró que su código era exclusivo y lo usó como una excusa para no revisar su código.
No está claro por qué se permitió que esto sucediera, pero tanto Zeichick como Gold señalan que un requisito para las revisiones de código debe ser parte de cualquier contrato entre una empresa y un equipo de programación independiente. Gold sugiere que el contrato no solo mencione las revisiones de códigos sino que especifique cómo y cuándo tienen lugar.
Zeichick señaló que algunas grandes tiendas de desarrollo pueden hacer sus propias revisiones de código, lo que dijo tiene sentido. "Las mejores personas para hacer la revisión del código son las personas del equipo de desarrollo", dijo.
Evitar codificadores maliciosos
Las revisiones de códigos han existido casi desde siempre. Cuando administraba un equipo de programadores para una gran instalación gubernamental, revisábamos líneas de COBOL que adormecían la mente todos los viernes por la tarde. Si bien era tedioso, con frecuencia encontramos descuidos, errores, referencias extraviadas u otros errores de codificación. El hecho es que todos cometemos errores, y una revisión sensata mejora el código para todos.
Desafortunadamente, los programadores a veces resienten las revisiones de código, creyendo que son una pérdida de tiempo. Otros dicen que no quieren que las personas adivinen su código. Pero el hecho de negarse a permitir que se revise el código debería ser una señal de alerta. Si está pagando que se escriba el código, entonces su contrato puede incluir razonablemente un requisito para las revisiones. Negarse a hacerlo es motivo de despido.
Desafortunadamente, encontrar buenos programadores es difícil en estos días. La demanda es alta y, en algunos casos, los programadores contratados sienten que pueden especificar que no tienen que someterse a una revisión de su código, incluso si su contacto dice que lo será.
La mejor manera de evitar tales problemas es, primero, pedir y luego llamar a referencias para trabajos anteriores. En segundo lugar, hacer cumplir las revisiones de código desde el primer día. De esa manera, se convierten en un hábito, y los programadores que se niegan a tener revisiones pueden ser descartados inmediatamente, antes de que se vuelvan críticos para el proceso de desarrollo.
- Qué hacer cuando ha sido pirateado Qué hacer cuando ha sido pirateado
- 6 cosas que no se deben hacer después de una violación de datos 6 cosas que no se deben hacer después de una violación de datos
- Florida City pagará $ 600, 000 a los piratas informáticos después del ataque de ransomware Florida City pagará $ 600, 000 a los piratas informáticos después del ataque de ransomware
Desafortunadamente, los riesgos en el proceso de desarrollo pueden ser grandes. Gold señala que un programador poco ético puede insertar puertas traseras en su código, encontrar formas de robar los datos de sus clientes o propiedad intelectual, o pasar datos críticos a otra compañía o potencia extranjera.
La forma de evitar esto es administrar continuamente, revisar el producto de trabajo de su personal de programación y revisar el código antes de que su sistema de administración de código lo acepte.