Desde la perspectiva del ciclo de vida del desarrollo de software (SDLC), la seguridad es el aspecto más crucial de las empresas, ya que las vulnerabilidades de seguridad plantean riesgos para las organizaciones grandes y orientadas al usuario. Como resultado, las empresas invierten mucho en hacer de la seguridad del software una prioridad.

Ser una empresa o un equipo centrado en la privacidad puede agregar beneficios excepcionales en su conjunto. Los clientes valoran las características de seguridad del software que la empresa está creando y mejorando tanto como la facilidad de uso. Pero lograr el hito requiere una consideración cuidadosa con implicaciones estrictas en las mejores prácticas y pautas de seguridad de SDLC.

El SDLC contiene puntos de control de seguridad para proteger la confidencialidad, disponibilidad e integridad del sistema general y los datos que contiene. El SDLC fusionado con el modelo de madurez del software OWASP (OWASP SAMM) puede ayudar a formular e implementar una hoja de ruta estratégica en toda la empresa para la seguridad de las aplicaciones.

¿Qué es la cadena de suministro de software?

La cadena de suministro de software es una disciplina que abarca equipos (tanto internos como externos), metodologías, herramientas y mejores prácticas para poner en marcha un artefacto de software desde el diseño hasta la implementación.

En los últimos tiempos, la mayoría de los servicios innovadores y disruptivos y las experiencias digitales se han desarrollado utilizando software de código abierto por parte de equipos remotos.

Las bibliotecas de código abierto atraen a los desarrolladores con sus características brillantes que les permiten impulsar el desarrollo al reducir el tiempo de comercialización y las implicaciones de costos.

Pero surgen fallas y complicaciones en el uso de software de código abierto debido a la falta de control sobre el código fuente y las versiones de funciones a lo largo del tiempo con parches, y conllevan el riesgo de ataques a la cadena de suministro de código abierto .

El código desarrollado de manera inadecuada con secretos codificados y una infraestructura de arquitectura flexible es propenso a sufrir ataques frecuentes.

Vulnerabilidades más populares

Las vulnerabilidades de software prevalecen en organizaciones de todos los niveles. Es más probable que las empresas en ciernes sean víctimas de este tipo de ataques, ya que se centran en traer nuevas funciones al mercado en plazos ajustados. Desafortunadamente, estas exposiciones no llegan a los titulares para concienciar a la comunidad tecnológica. Analicemos algunos de los incidentes históricos más generalizados e impactantes.

En un momento dado, la noticia de última hora del ataque contra SolarWinds sacudió al mundo de la tecnología. El evento se convirtió en un excelente ejemplo de los peligros de las prácticas de seguridad inadecuadas.

La catástrofe surgió cuando un interno no pudo establecer una contraseña compleja. Los atacantes se acomodaron en el sistema SolarWinds a través de una combinación de contraseña débil utilizando un método llamado rociado de contraseñas y lograron enviar malware a través de una puerta trasera a todas las empresas dependientes. El ataque a la cadena de suministro se basó en la identidad, lo que actualizó el servidor de actualizaciones de SolarWinds.

La aplicación de políticas de contraseñas seguras en el sistema con capas de seguridad adicionales, como MFA, podría haber evitado el desastre.

Un incidente similar ocurrió en la autoridad de certificación del gobierno de Vietnam. Los atacantes sortearon el firewall del sitio web e insertaron archivos de instalación adicionales en las aplicaciones de instalación de VGCA, que son aplicaciones orientadas al cliente ofrecidas por VGCA para la oferta de firma digital.

La actividad general fue exitosa porque los atacantes encontraron una brecha en el diseño del sitio web, ya que el diseño general tenía algunas fallas. El ataque de puerta trasera se pudo evitar con estrictas restricciones de firewall, controles de acceso y permisos privilegiados.

Para otro ejemplo de cómo las vulnerabilidades pueden paralizar un sistema, echemos un vistazo a Bitcoins. Los bitcoins pueden exponerse fácilmente y ser robados si el proveedor de servicios no cumple con las pautas de seguridad.

Copay, una billetera de Bitcoin, sufrió un ataque en la cadena de suministro cuando una aplicación móvil que aloja la billetera de Bitcoin tuvo un error. El error en la arquitectura se produjo a través de la vulnerabilidad del paquete de un administrador de paquetes de nodos (NPM) de la herramienta Javascript de código abierto. Esta versión con errores se hizo pública y permitió que el pirata informático modificara las aplicaciones para cargar el código refactorizado y obtener acceso a la biblioteca JS.

El error podría haberse detectado y corregido con herramientas de análisis de vulnerabilidades en el control de versiones y canalización de implementación.

Piezas móviles para la gestión de la cadena de suministro de software

Un plan bien articulado que sigue una documentación sólida, ciberseguridad, remediación de riesgos y mejores prácticas de gestión elimina las vulnerabilidades potenciales y aumenta la seguridad de la cadena de suministro de software. Las organizaciones deben adaptar los principios de ingeniería "seguros por diseño" y una estrategia de cambio a la izquierda para establecer una cadena de herramientas integral de DevSecOps.

Etapa 1: Alfabetización de codificación segura

En primer lugar, las empresas deben adoptar programas exclusivos de aprendizaje y desarrollo sobre seguridad y gestión de riesgos. A medida que los equipos de desarrollo se apresuran a mejorar sus habilidades técnicas, un objetivo común que las empresas deben compartir es ayudar a los desarrolladores a convertirse en campeones de la seguridad.

Se necesitan evaluaciones de vulnerabilidad de aplicaciones y cursos de seguridad para mantener a los ingenieros alineados con los objetivos comerciales.

Etapa 2: Modelado de amenazas

Es esencial identificar los riesgos de seguridad mucho antes de que el desarrollo y las operaciones se pongan al día. Esta etapa garantiza que la estrategia general de diseño y desarrollo se alinee con los estándares de seguridad de la organización.

El modelado de amenazas presenta a las organizaciones un enfoque estructurado para identificar, analizar, evaluar y mitigar los riesgos en las primeras etapas de desarrollo. Los modelos de amenazas son prometedores con respecto a la seguridad al permitir que los desarrolladores y arquitectos piensen desde el punto de vista del atacante, lo que les permite planificar y diseñar un sistema seguro.

<?xml version="1.0" encoding="utf-8"?>
<KnowledgeBase xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <Manifest name="Basic threat modelling design" id="5d3b996b-bac2-8cf6-3b39-617bb67bf042" version="4.1.0.11" author="TwC MSEC" />
 <ThreatMetaData>
   <IsPriorityUsed>true</IsPriorityUsed>
   <IsStatusUsed>false</IsStatusUsed>
   <PropertiesMetaData>
     <ThreatMetaDatum>
       <Name>Title</Name>
       <Label>Title</Label>
       <HideFromUI>false</HideFromUI>
       <Values>
         <Value />
       </Values>
       <Id>5d3b996b-bac2-8cf6-3b39-617bb67bf042</Id>
       <AttributeType>0</AttributeType>
     </ThreatMetaDatum>
     <ThreatMetaDatum>
       <Name>UserThreatShortDescription</Name>
       <Label>Short Description</Label>
       <HideFromUI>true</HideFromUI>
       <Values>
         <Value>Threat modeling is critical and mandate phase in secure software development</Value>
       </Values>
       <Id>ac0f9ea8-aed5-4d95-4ce9-6787124d7b48</Id>
       <AttributeType>1</AttributeType>
     </ThreatMetaDatum>
     <ThreatMetaDatum>
       <Name>UserThreatDescription</Name>
       <Label>Description</Label>
       <HideFromUI>false</HideFromUI>
       <Values>
         <Value />
       </Values>
       <Id>5d3b996b-bac2-8cf6-3b39-617bb67bf042</Id>
       <AttributeType>0</AttributeType>
     </ThreatMetaDatum>
     <ThreatMetaDatum>
       <Name>Priority</Name>
       <Label>Priority</Label>
       <HideFromUI>true</HideFromUI>
       <Values>
         <Value>High</Value>
         <Value>Medium</Value>
         <Value>Low</Value>
       </Values>
       <Description>Priority</Description>
       <Id>ac0f9ea8-aed5-4d95-4ce9-617bb67bf042</Id>
       <AttributeType>1</AttributeType>
     </ThreatMetaDatum>
   </PropertiesMetaData>
 </ThreatMetaData>
 <GenericElements>
   <ElementType>
     <Name>Threat modeling Process</Name>
     <ID>GE.P</ID>
     <Description>General approach to define a threat model</Description>
     <ParentElement>ROOT</ParentElement>
     <Image>Image_ref</Image>
     <Hidden>false</Hidden>
     <Representation>Ellipse</Representation>
     <StrokeThickness>0</StrokeThickness>
     <ImageLocation>Centered</ImageLocation>
     <Attributes>
       <Attribute>
         <Id>002864b3-9a4e-4d21-8a4d-8aea1d2e3056</Id>
         <IsInherited>false</IsInherited>
         <IsOverrided>false</IsOverrided>
         <Name>codeType</Name>
         <DisplayName>Code Type</DisplayName>
         <Mode>Dynamic</Mode>
         <Type>List</Type>
         <Inheritance>Virtual</Inheritance>
         <AttributeValues>
           <Value>Not Selected</Value>
           <Value>Managed</Value>
           <Value>Unmanaged</Value>
         </AttributeValues>
       </Attribute>
     </Attributes>
   </ElementType>
 </StandardElements>
 </KnowledgeBase>

El código debe ser obligatorio para la revisión del código por parte de pares. La habilitación de revisiones directas y por correo electrónico permite a los equipos de desarrollo detectar errores y defectos durante la etapa inicial del desarrollo.

Los retrasos y las fallas de vulnerabilidad pueden llegar al código incluso con consideraciones cuidadosas y esfuerzos manuales. Los errores más comunes incluyen si faltan construcciones de programación, el código general cumple con los estándares de seguridad y el código pasa las verificaciones de pelusa y sugerencias de tipo.

Las revisiones de código asistidas por herramientas son menos propensas a errores y evitan riesgos de vulnerabilidad. GitHub puede demostrar ser una herramienta confiable y eficiente para auditorías de código y revisiones de código sobre la marcha, con el control de versiones como una ventaja adicional.

Etapa 4: escaneo a través de herramientas automatizadas

La automatización de la revisión del código antes de fusionarse con el maestro es de suma importancia. Si no se superan las comprobaciones predefinidas, se resaltan los problemas en el código y se activa un circuito de retroalimentación para que los desarrolladores refactoricen y aseguren la base de código general.

WhiteSource para desarrolladores, Codacy y Codecov son herramientas de revisión automatizadas disponibles a través del mercado de GitHub para integrarse rápidamente en su base de código y cumplir con los requisitos de la pila tecnológica. Estas herramientas utilizan el enfoque de desplazamiento a la izquierda para escanear e indexar código abierto de todos los GitHub Repos existentes.

Etapa 5: escaneo de código estático y pruebas de seguridad

Automatizar la depuración y las revisiones del código mientras se salta la ejecución a través de canalizaciones puede ser fructífero durante las etapas de desarrollo e implementación. Las herramientas avanzadas de automatización de canalizaciones, como Jenkins, están cargadas con una amplia gama de complementos de revisión de código.

Los complementos de revisión de código estático como FindBugs realizan la revisión y el análisis del código mediante la ejecución de controles y lógica predefinidos, y devuelven un archivo de salida. Jenkins puede analizar el archivo de salida del trabajo, resaltar los errores y enumerar las advertencias encontradas siguiendo un enfoque de arriba hacia abajo en el nivel de código del directorio y presentando gráficamente un resumen detallado del análisis general.

Ejemplo de código:

trigger:
 branches:
   include:
   - feature
   - main
 paths:
   include:
   - src/*
   - tests/*

pool:
 Image: 'centos/latest'

jobs:
- job: codereview
 displayName: review and report

 steps:

 - checkout: self
   lfs: true

 - task: UsePythonVersion@0
   displayName: 'Set Python version to 3.9'
   inputs:
     versionSpec: '3.9'

 - script: pip3 install --user -r requirements.txt
   displayName: 'Installing required dependencies'

 - script: |
     python -m behave --junitxml=./validation_test-checks.xml
   displayName: 'Running behave tests'

 - task: PublishBehaveResults@1
   displayName: 'bumping out behave test results'
   condition: passOrFail()
   inputs:
     testResultsFiles: '**/validation_test-*.xml'
     testRunTitle: 'Publish behave test results for Python $(python.version)'

Las vulnerabilidades de la cadena de suministro de software son bestias inevitables. Cuando se ignoran, pueden derribar todo un sistema y afectar tanto al negocio como a la reputación. El SDLC abarca numerosas técnicas y conjuntos de herramientas para hacer de la seguridad un hito principal en el viaje del software.

La fase de desarrollo general debe seguir las etapas destacadas anteriormente, comenzando por la alfabetización en seguridad, el modelado de amenazas, la revisión de código entre pares, las verificaciones de código automatizadas y el escaneo de código estático y las pruebas de seguridad.

De Infosec Writeups: Cada día surgen muchas cosas en Infosec con las que es difícil mantenerse al día. ¡ Únase a nuestro boletín semanal para obtener las últimas tendencias de Infosec en forma de 5 artículos, 4 subprocesos, 3 videos, 2 repositorios y herramientas de GitHub y 1 alerta de trabajo GRATIS!