\u00bfCu\u00e1nto tiempo dedican los desarrolladores a escribir c\u00f3digo?<\/h4>\n
Seg\u00fan reciente estudios<\/a>, los desarrolladores pasan m\u00e1s tiempo manteniendo, probando y asegurando el c\u00f3digo existente que escribiendo o mejorando el c\u00f3digo. Las vulnerabilidades de seguridad tienen la mala costumbre de aparecer durante el proceso de desarrollo de software, solo para aparecer despu\u00e9s de que se haya implementado una aplicaci\u00f3n. La parte decepcionante es que muchas de estas fallas y errores de seguridad podr\u00edan haberse resuelto en una etapa anterior y existen m\u00e9todos y herramientas adecuados para descubrirlos.<\/p>\n \u00bfCu\u00e1nto tiempo dedica un desarrollador a aprender a escribir un c\u00f3digo funcional? \u00bfY cu\u00e1nto se gasta en aprender sobre la seguridad del c\u00f3digo? \u00bfO aprender a no codificar?”<\/p>\n \u00bfNo ser\u00eda mejor erradicar el problema del sistema en lugar de tenerlo all\u00ed y luego tratar de detectar y detener un ataque en curso dirigido a \u00e9l?<\/p>\n Puede probar sus habilidades de codificaci\u00f3n segura con este breve <\/em>auto evaluaci\u00f3n.<\/em><\/a><\/p>\n Todo el mundo comete errores, incluso los desarrolladores. Los errores de software son inevitables y se aceptan como el “costo de hacer negocios” en este campo. <\/p>\n Dicho esto, cualquier error no corregido en el c\u00f3digo es vital para los atacantes. Si pueden encontrar al menos un error en un sistema que se pueda explotar de la manera correcta (es decir, una vulnerabilidad de software), pueden aprovechar esa vulnerabilidad para causar da\u00f1os masivos, potencialmente en la escala de decenas de millones de d\u00f3lares, como nosotros. ver a trav\u00e9s de casos muy publicitados que llegan a los titulares cada a\u00f1o.<\/p>\n E incluso cuando se trata de vulnerabilidades menos graves, solucionarlas puede resultar muy costoso, especialmente si se introduce una debilidad mucho antes en el SDLC debido a una falla de dise\u00f1o oa la falta de un requisito de seguridad.<\/p>\n Se supone que las herramientas de automatizaci\u00f3n y ciberseguridad reducen la carga de trabajo de los desarrolladores y el personal de seguridad de aplicaciones al escanear, detectar y mitigar las vulnerabilidades del software, sin embargo:<\/p>\n La desconexi\u00f3n de DevSec se refiere a la conocida tensi\u00f3n entre los equipos de desarrollo y los equipos de seguridad debido a prioridades diferentes (y a menudo conflictivas) cuando se trata de nuevas funciones y correcciones de errores.<\/p>\n Como resultado de esta fricci\u00f3n, 48% de los desarrolladores<\/a> terminan empujando regularmente el c\u00f3digo vulnerable a la producci\u00f3n. Las vulnerabilidades que se descubren m\u00e1s adelante en el ciclo de desarrollo a menudo no se mitigan o terminan creando costos adicionales, demoras y riesgos m\u00e1s adelante. Estas son las consecuencias del pensamiento a corto plazo: en \u00faltima instancia, ser\u00eda mejor solucionar el problema en la fuente en lugar de gastar tiempo y recursos en encontrar fallas en el c\u00f3digo m\u00e1s adelante en el ciclo de vida del desarrollo del software.<\/p>\n Otro error com\u00fan es centrarse \u00fanicamente en la seguridad de la cadena de suministro de software y solo abordar las vulnerabilidades conocidas en los productos y paquetes de software existentes que figuran en la famosa base de datos de vulnerabilidades y exposiciones comunes o en la base de datos nacional de vulnerabilidades.<\/p>\n Es esencial lidiar con las vulnerabilidades en los componentes de terceros, sus dependencias o el entorno operativo, pero esto no lo ayudar\u00e1 con las vulnerabilidades en su propio c\u00f3digo.<\/p>\n De manera similar, monitorear ataques potenciales a trav\u00e9s de sistemas de detecci\u00f3n de intrusos (IDS) o firewalls seguidos de una respuesta a incidentes es una buena idea, y OWASP Top 10 lo reconoce como una necesidad, pero estas actividades solo se ocupan de las consecuencias de los ataques cibern\u00e9ticos en lugar de la causa.<\/p>\n Su ciberseguridad es tan fuerte como su eslab\u00f3n m\u00e1s d\u00e9bil. El desarrollo de software no es un trabajo de l\u00ednea de montaje y, a pesar de todas las predicciones, no estar\u00e1 completamente automatizado en el corto plazo. Los programadores son solucionadores de problemas creativos que necesitan tomar cientos de decisiones cada d\u00eda mientras escriben c\u00f3digo, porque el desarrollo de software es un tipo de artesan\u00eda. <\/p>\n Cuando se trata de eso, si un fragmento de c\u00f3digo es seguro o no depende de las habilidades de los desarrolladores individuales. <\/b><\/p><\/blockquote>\n Los procesos, est\u00e1ndares y herramientas pueden ayudar a fomentar y reforzar las mejores pr\u00e1cticas, pero si un desarrollador no conoce un tipo particular de mala pr\u00e1ctica, es probable que siga cometiendo el mismo error (e introduciendo el mismo tipo de vulnerabilidad en el c\u00f3digo) una y otra vez.<\/p>\n El n\u00famero de vulnerabilidades descubiertas recientemente est\u00e1 aumentando y las amenazas que plantean los ciberagresores maliciosos se est\u00e1n volviendo cada vez m\u00e1s sofisticadas. La mayor\u00eda de las organizaciones comienzan a implementar un ciclo de vida de desarrollo seguro despu\u00e9s de un incidente, pero si nos pregunta cu\u00e1ndo debe comenzar, la respuesta, por supuesto, siempre ser\u00e1 cuanto antes, mejor.<\/p>\n Eso es porque cuando se trata de vulnerabilidades cr\u00edticas, incluso las horas pueden significar la diferencia entre un da\u00f1o no duradero y un desastre financiero. <\/p>\n Estos son nuestros mejores consejos para hacer exactamente eso:<\/p>\n 1 \u2014 Desplazamiento a la izquierda: ampliar la perspectiva de seguridad a las primeras fases de desarrollo <\/b><\/p>\n Confiar en la automatizaci\u00f3n de herramientas de seguridad estilo DevSecOps por s\u00ed sola no es suficiente, debe implementar un cambio cultural real. Las pruebas SAST, DAST o de penetraci\u00f3n se encuentran a la derecha en el SDLC; despl\u00e1cese hacia la izquierda hacia el comienzo del ciclo de vida del desarrollo de software para obtener una cobertura m\u00e1s completa.<\/p>\n 2 \u2014 Adoptar un enfoque de ciclo de vida de desarrollo seguro<\/b><\/p>\n MS SDL u OWASP SAMM, por ejemplo, proporcionar\u00e1n un marco para sus procesos y actuar\u00e1n como un buen punto de partida para su iniciativa de ciberseguridad.<\/p>\n 3 \u2014 Cubra todo su ecosistema de TI<\/b><\/p>\n Las vulnerabilidades de terceros representan un gran riesgo para la ciberseguridad de su empresa, pero sus propios desarrolladores tambi\u00e9n pueden estar introduciendo problemas en la aplicaci\u00f3n. Debe poder detectar y resolver vulnerabilidades en las instalaciones, en la nube y en entornos de terceros. <\/p>\n 4 \u2014 Pasar de la reacci\u00f3n a la prevenci\u00f3n<\/b><\/p>\n Agregue conceptos de programaci\u00f3n defensiva a sus pautas de codificaci\u00f3n. Robustez es lo que necesitas. La buena seguridad tiene que ver con la paranoia, despu\u00e9s de todo.<\/p>\n 5 \u2014 La mentalidad importa m\u00e1s que la tecnolog\u00eda<\/b><\/p>\n Los cortafuegos y los IDS no proteger\u00e1n su software de los piratas inform\u00e1ticos por s\u00ed mismos; simplemente se ocupan de las consecuencias de las vulnerabilidades ya existentes. Aborde el problema desde la ra\u00edz: la mentalidad de los desarrolladores y la responsabilidad personal.<\/p>\n 6 \u2014 Invertir en capacitaci\u00f3n de c\u00f3digo seguro<\/b><\/p>\n Busque uno que cubra una amplia gama de lenguajes de programaci\u00f3n y brinde una cobertura completa de est\u00e1ndares de codificaci\u00f3n seguros, bases de datos de vulnerabilidades y tipos de debilidades de software cr\u00edticas reconocidas en la industria. Los ejercicios pr\u00e1cticos de laboratorio en los entornos nativos de los desarrolladores son una gran ventaja para ponerlos al d\u00eda r\u00e1pidamente y cerrar esa molesta brecha entre saber y hacer.<\/p>\n El viaje de aprendizaje combinado de Cydrill<\/a> brinda capacitaci\u00f3n en codificaci\u00f3n segura proactiva y efectiva para desarrolladores de compa\u00f1\u00edas Fortune 500 en todo el mundo. Combinando formaci\u00f3n dirigida por un instructor, e-learning,<\/a> laboratorios pr\u00e1cticos y gamificaci\u00f3n, Cydrill proporciona un enfoque novedoso y eficaz para aprender a codificar de forma segura. <\/p>\n <\/p>\n<\/div>\nEl verdadero costo de los errores<\/h2>\n
\u00bfPor qu\u00e9 se est\u00e1 quedando corto el enfoque actual de la seguridad del software?<\/h2>\n
1 \u2014 Demasiada confianza en la tecnolog\u00eda (y no lo suficiente en los humanos)<\/h4>\n
\n
2 \u2014 La desconexi\u00f3n de DevSec<\/h4>\n
3 \u2014 Supervisar su cadena de suministro pero no su propio software<\/h4>\n
La soluci\u00f3n: convertir la codificaci\u00f3n segura en un deporte de equipo<\/h2>\n
![\"\"](\"https:\/\/teknomers.com\/es\/wp-content\/uploads\/2022\/09\/1662149051_813_El-ultimo-punto-ciego-de-seguridad-que-no-sabe-que.jpg\")
<\/div>\n6 consejos para potenciar la codificaci\u00f3n segura<\/h2>\n
\n<\/ol>\n
\n<\/ol>\n
\n<\/ol>\n
\n<\/ol>\n
\n<\/ol>\n
\n<\/ol>\n