security - trabajar - ¿Es un profesional independiente responsable de un código pobre que heredó de otra persona?
razones para trabajar para otra persona (7)
Como profesional independiente, heredé muchos proyectos web personalizados poco desarrollados. La mayoría de estos proyectos no protegen contra la inyección de XSS y SQL. En algunos de estos proyectos, he sido el único desarrollador por más de 1 año. Cuando los clientes me piden que agregue nuevas funciones, lo hago sin hacer cambios significativos en la arquitectura del sistema subyacente.
Entonces, por ejemplo, si un cliente me pide que construya una página de registro con un presupuesto limitado, lo hago reutilizando los objetos de acceso a datos del sistema que no impiden la inyección SQL, y renderizo las páginas con los objetos de vista del sistema que no desinfectar el código para XSS.
Si en un momento posterior, un hacker explota estas brechas de seguridad en la página de registro, ¿soy responsable? Nunca me pidieron que volviera a escribir los objetos de acceso a los datos del sistema o los objetos de la vista. Y debido a que el cliente tiene un presupuesto limitado, no me pagarán para escribir un nuevo DAO o Ver para el sistema. Entonces, ¿automáticamente será mi culpa el día que decida heredar un proyecto tan desastroso?
¿Y qué pasa si hay otras partes de un sistema que rara vez toqué? Es posible que haya ingresado para cambiar parte del texto en las vistas, o haya agregado una nueva declaración if en el controlador. Una vez que he "tocado" algo, ¿significa que soy responsable de todo el módulo hasta que me retire del proyecto?
Spec It Out
Cuando trabaja independientemente, siempre debe proporcionarle al cliente una especificación de trabajo completamente detallada desglosada en las secciones más pequeñas que puede administrar y sus requisitos de horas estimadas para cada sección.
Si nota problemas flagrantes en su base de código actual que estaría dispuesto a corregir, cree una estimación secundaria especificada de ciertas cosas que cree que podría corregir y asegúrese de incluir por qué es importante solucionar los problemas.
En el mejor de los casos
En el mejor de los casos, obtiene un trabajo adicional y el cliente obtiene una aplicación mejorada.
Peor de los casos
En el peor de los casos, su cliente declina su presupuesto para corregir los errores / huecos de seguridad existentes o la inflamación del código. Este no es un mal escenario en el que hayas despejado tus pasivos en caso de que algo salga mal en el futuro. También le da una buena indicación de no seguir trabajando para el cliente, ya que claramente no tiene ninguna preocupación por la seguridad o la calidad del trabajo. Solo alégrate cuando hayas terminado el proyecto.
Al asumir el control de un nuevo proyecto, dejaría en claro al cliente que no soy responsable de los errores en la fuente original, a menos que también me quieran pagar el tiempo necesario para hacer una revisión completa del código. Para protegerse, asegúrese de guardar una copia del código original tal como lo recibió.
Aquí hay dos preguntas separadas:
¿Cómo te proteges en esta situación?
Asegúrese de tener una copia del código original y use un buen sistema de control de origen, de modo que si surgen preguntas, puede ilustrar claramente que no se trata de un código que escribió, sino que estaba presente antes de comenzar.
¿Cómo le va bien al cliente en esta situación?
Pregúntele al cliente por adelantado qué tipo de análisis le gustaría que haga: posibles mejoras del código, soluciones de seguridad, etc. Piense en las categorías que puede darles para dar una buena idea de lo que va a revisar y de qué tipo de cosas que podrías encontrar potencialmente
¿Por qué por adelantado? Porque de lo contrario obtendrás el síndrome mecánico del automóvil, donde tomas tu automóvil, y el mecánico dice "Ah, por cierto, encontramos este problema aquí" y te sientes incómodo porque no estás seguro de si es real o no. . Pero si le pides al mecánico que lo revise en todas partes, al menos te sentirás más cómodo si encuentra algo.
Del mismo modo, si obtienes la autorización inicial para buscar cosas como esta, puedes hacer una lista y mostrarles el código e ilustrar los problemas, y te ves como un profesional haciendo análisis en lugar de un mecánico fangoso tratando de hacer una dinero extra para trabajo cuestionable.
Creo que debes hacer que tu cliente esté al tanto de la situación. Hágales saber qué riesgos existen en el sistema actual que están ejecutando, cuánto costará repararlo y cuáles son los riesgos si no lo hacen.
No creo que pueda ser responsable (pero no soy abogado, comuníquese con uno si existe un problema legal muy apremiante) por problemas preexistentes SI hace que el cliente sepa que usted es consciente de ellos.
¿Cómo se maneja esto en otras situaciones? Si un ingeniero se encuentra con algo muy mal construido pero solo se le da un presupuesto por un pequeño ajuste o arreglo, ¿sigue siendo responsable de todos los otros problemas?
Cuénteles acerca de cualquier problema que vea, e incluya una estimación de las horas involucradas para solucionarlos. Ponlo por escrito, y has puesto el balón en la cancha. No pueden responsabilizarte por su propia falta de atención a tus advertencias.
Permítanme agregar que si pudiera solucionar muchos de estos problemas en 15 minutos o menos, lo haría, solo como una cuestión de orgullo personal en mi trabajo.
Cuando trabajo por cuenta propia, hago el trabajo que me pagan / solicito y asesorar sobre el trabajo que creo que debe hacerse.
Así es como me acerco a la mayoría de lo que hago. Haré exactamente lo que me piden, pero como profesional casi siempre ofrezco mi opinión sobre la situación.
Ciertamente no diría que usted es directamente responsable de ello, pero no sería muy profesional no decir nada al respecto.
Ah, y no estoy sugiriendo que tengas que moverte a través de toda la base de código para encontrar posibles problemas ... solo que si los encuentras en lo que estás haciendo, no los tires debajo de la alfombra.
No puedo responder desde una perspectiva legal; eso dependerá de la ley escrita y de la jurisprudencia en su jurisdicción. Sin embargo, desde un punto de vista ético, lo mínimo que debe hacer es identificar los defectos y su posible impacto en sus clientes. Dales una idea de lo que podría pasar si esas vulnerabilidades fueran explotadas.