En este artículo vamos a repasar una lista básica de ejemplos de malas practicas del código, que resultan en debilidad para nuestra aplicación o directamente en muchos casos exponen vulnerabilidades fácilmente explotables por parte de un atacante.
-
-
Cálculo de líneas por hora en una auditoría de código SAST
Mi aplicación tiene 20.000 LoC, líneas de código, ¿Cuánto se tarda en auditar?: Con respecto a una revisión de código, ya sea una auditoria de código (SAST), desde ciberseguridad, o una revisión de código atendiendo al control de calidad de este. Siempre surge una duda recurrente, en la estimación / dimensionamiento del trabajo a realizar.
-
Infografías: «Lista de tips para llevar a cabo correctamente una auditoría de código o prueba SAST» y «Pasos de una SAST, static application security testing»
"Lista de tips para llevar a cabo correctamente una auditoría de código o prueba SAST" y "Pasos de una SAST, static application security testing"
-
9 Pasos de una static application security testing (SAST)
La pruebas de seguridad de aplicaciones de tipo estático, auditoría de código o static application security testing (SAST), se utilizan para proteger la seguridad del software y los sistemas donde este funciona, al revisar el código fuente del software para identificar el origen de las vulnerabilidades.
-
Habilidades requeridas / deseadas para llevar a cabo una auditoría de código (SAST)
A continuación se exponen las habilidades a fortalecer, deseadas en el analista o auditor a la hora de realizar una auditoría de código. Para llevar a cabo una static application security testing (SAST), es decir, una revisión de código desde el punto de vista de la seguridad.
-
Los diferentes stakeholders, interesados / participantes en un desarrollo de software seguro (DevSecOps)
Los diferentes roles y las diferentes responsabilidades que ocasiona un proyecto de desarrollo de software siempre son causa de malentendidos e incertidumbre. Es común que en un desarrollo pequeño una única persona lleve a cabo varios roles y responsabilidades, y en un proyecto grande sin embargo exista suficiente personal para diferenciar específicamente cada rol, esto es una muy buena practica que produce mucho beneficio al proyecto.
-
Modelo de amenazas STRIDE y modelo de evaluación de riesgos DREAD
El modelo de amenazas STRIDE ofrece una interesante división a seis sobre las categorías de estas. Puede emplearse en la identificación y categorización de amenazas de seguridad informática, y es muy práctico dentro del desarrollo seguro como marco de pensamiento en el descubrimiento de vulnerabilidades.
-
Requisitos de seguridad en software: Security Requirement Engineering (SRE)
En el desarrollo de software es un habitual la especificación de requisitos, para describir como debe comportarse el software. Dentro de esta descripción donde se pueden distinguir dos niveles: el funcional y el organico, también deben estar disponibles los requisitos que concretamente atienden a la seguridad.
-
Desarrollo de software seguro S-SDLC
Desarrollo seguro, ese gran desconocido! En este articulo vamos a ver como el control de seguridad en el desarrollo de software no reinventa la rueda y se adapta a la perfección al ciclo de vida tradicional.
