A veces puede surgir una pequeña trampa en la forma en que los humanos entienden y procesan el lenguaje. Específicamente, a veces damos por sentado el significado de una palabra o frase. Con esto quiero decir que usamos un término que significa una cosa dada, solo para que aquellos que nos escuchan entiendan el término de una manera completamente diferente.
Esto es contraproducente cuando sucede en la comunicación diaria, pero puede ser peligroso en el contexto de disciplinas que impactan en el riesgo, como la seguridad cibernética, la garantía y la gobernanza. En estas situaciones, puede crear riesgo.
Menciono esto porque a menudo escuchamos formas de garantizar una “codificación segura” en organizaciones que crean y mantienen software como parte de su negocio, ya sea para uso interno o externo. Es importante porque, francamente, la mayoría de las empresas pertenecen a esta categoría hoy en día. Si bien es natural discutir los desafíos del riesgo de software de esta manera, creo que el término “codificación segura” presupone un contexto que hace que el estado final previsto sea realmente más difícil lograr, al menos cuando se toma literalmente.
Y no me refiero a esto sólo en un sentido semántico. Por ejemplo, diría que comprender por qué esa declaración es verdadera tiene un valor real, tangible y práctico. Habla de la causa raíz de por qué muchas organizaciones luchan con el riesgo de las aplicaciones y el software, y destaca los pasos prácticos que las organizaciones pueden tomar para mejorar. Con eso en mente, analicemos cuáles son los objetivos reales de reducción de riesgos de software y cuál es la mejor manera de lograrlos a medida que cumplimos con nuestros requisitos para desarrollar y publicar software de manera segura y resistente.
Seguridad en el desarrollo de software frente a reducción de riesgos
Lo primero que hay que desempacar es el estado final previsto de lo que queremos decir con “codificación segura”. En mi opinión, hay algunos objetivos diferentes y relacionados que generalmente se pretenden con este término. Primero, por “seguridad” en este contexto, la gente generalmente quiere decir dos cosas:
- Emplear arquitectura de aplicaciones y patrones de diseño que fomenten los principios de reducción de riesgos (p. ej., confidencialidad, integridad y disponibilidad)
- Crear software que sea resistente a los ataques (p. ej., a través de vías como vulnerabilidades y configuraciones incorrectas)
Ambas cosas son, por supuesto, increíblemente importantes. Dedique algún tiempo a hablar con los profesionales de la seguridad de las aplicaciones y ellos, con toda razón, le destacarán el famoso trabajo de Barry Boehm sobre la economía de encontrar y solucionar vulnerabilidades en las primeras etapas del proceso de desarrollo. Le explicarán correctamente el valor de herramientas como el modelado de amenazas de aplicaciones que se pueden utilizar para comprender qué y dónde se encuentran los problemas de diseño de seguridad en el software. La trampa es que estas cosas, por importantes que sean, no son la totalidad de lo que nos podría interesar cuando se trata de reducir el riesgo en el software. Por ejemplo, otras cosas que podrían interesarnos al menos por igual podrían incluir:
- Madurez – garantizar que los procesos sean maduros para que sean resistentes al desgaste de los empleados y para que los resultados sean consistentes
- Transparencia – garantizar la transparencia en la cadena de suministro de los componentes y bibliotecas de los que a su vez dependen nuestros productos (y ser capaz de proporcionar esa transparencia a los clientes)
- Cumplimiento – asegurarnos de que cumplimos con las diversas licencias (comerciales y de código abierto) que utilizamos en el desarrollo de nuestro software
- Simplicidad de diseño – ¿El diseño se presta a ser fácilmente entendido y evaluado?
Etcétera. De hecho, estas cosas son solo la punta del iceberg de las consideraciones que pueden tener un impacto en el riesgo del software como un asunto práctico. Podría incluir fácilmente cosas como: idoneidad para el propósito, rigor de diseño, compatibilidad, cobertura de pruebas, calidad del código, tiempo de comercialización y muchas otras cosas que afectan los riesgos asociados con la forma en que diseñamos, desarrollamos, probamos, implementamos, mantenemos, apoyar y, en última instancia, desmantelar nuestro software.
A través de este lente, la pregunta que deberíamos hacernos no es sobre “seguridad” en absoluto, sino sobre la reducción de riesgos (del cual la seguridad es un subconjunto, aunque uno grande e importante). Vincular las consideraciones de software solo a la seguridad reduce el conjunto de partes interesadas, reduce la responsabilidad y cambia la discusión. Por el contrario, mantener el enfoque en el riesgo significa que todos, incluso aquellos que están lejos del universo de desarrollo de software, tienen un papel vital que desempeñar.
El ciclo de vida del software
La segunda cosa sobre la que llamaría su atención es el elemento de “codificación” de la frase. Sí, la codificación es importante. Pero al igual que la “seguridad”, es solo una parte, aunque grande, del ciclo de vida involucrado en el desarrollo del software. Considere cómo se diseña normalmente el software y cuántos pasos diferentes están involucrados. Si bien los ciclos de vida de desarrollo de software individuales (SDLC) pueden describirlos de manera diferente, en un nivel alto es posible que tenga pasos, en abstracto de todos modos, similares a los siguientes:
- Identificación de la necesidad
- Ideación/Inicio
- Recopilación de requisitos
- Diseño
- Desarrollo
- Pruebas
- Despliegue
- Apoyo
- Mantenimiento
- Desmantelamiento
Esto es un montón de pasos. Y notará que cada uno de ellos podría dividirse en una miríada de subpasos individuales. Por ejemplo, un paso como “prueba” puede abarcar (según el SDLC en uso, el contexto, etc.): pruebas unitarias, pruebas funcionales, pruebas de regresión, pruebas de rendimiento, pruebas de seguridad y cualquier cantidad de otros elementos individuales. ¿Cuántos de estos implican simplemente “codificación” frente a cuántos no, pero son críticos para garantizar un producto sólido al final?
En otras palabras, hay una gran cantidad de formas posibles para que las partes interesadas involucradas en cualquier etapa de este proceso introduzcan o mitiguen los riesgos según los procesos que sigan, su capacitación, su conciencia y muchos otros factores. Esto significa que un programa consciente de los riesgos diseñado para reducir, administrar y mitigar los riesgos del software debe tenerlos en cuenta y, siempre que sea posible, reforzar aquellas acciones que favorezcan los resultados de la reducción de riesgos. El punto es que, si bien la codificación es posiblemente el paso más “visible” a lo largo del proceso de desarrollo y lanzamiento de software (al menos internamente), tampoco es el único lugar en el que debemos centrarnos.
Como era de esperar, los esfuerzos de administración de riesgos de su aplicación (o software, según el lenguaje preferido) deben incluir todo el ciclo de vida. Esto, por extensión, significa dos cosas: 1) que comprende y tiene en cuenta todo el ciclo de vida de manera holística, y 2) que amplía su planificación para incluir áreas fuera del desarrollo que, sin embargo, tienen un interés. Incluya y delegue personal de pruebas, analistas comerciales, gerentes de proyectos y productos, equipos de soporte, ventas, marketing, RR.
Como dije al principio, no se trata solo de la semántica (aunque reconozco que lo enmarqué de esa manera para ilustrar el punto). En cambio, se trata de comprender que el riesgo se ve afectado por la totalidad de los procesos que rodean el desarrollo de software y ese riesgo se extiende mucho más allá de lo que tradicionalmente tendemos a enfocar cuando observamos cosas como las vulnerabilidades.
¿Por qué no es solo semántica? Porque habla de algo más grande que es increíblemente importante. En Fines y mediosAldous Huxley dijo una vez que, “El fin no puede justificar los medios por la simple y evidente razón de que los medios empleados determinan la naturaleza de los fines producidos.Su punto fue que la forma en que hacemos algo determina, en gran medida, cuál será el estado final. Extendiendo eso al desarrollo de software, diría que los procesos de desarrollo desorganizados, inmaduros y “slapdash” producirán inexorablemente un software que está mal diseñado y peor implementado de lo que sería el caso si se siguiera un proceso más robusto y disciplinado. . Esto, a su vez, significa que apuntamos a objetivos más allá de la seguridad y adoptamos procesos más allá de la escritura de código.