Descripción general

Datadog Code Security le ayuda a proteger y mantener el código propio y las bibliotecas de código abierto de sus aplicaciones desde el desarrollo hasta la producción.

Ofrece un conjunto de herramientas para ayudarle a proteger su código a lo largo del ciclo de vida de desarrollo de software:

• Análisis estático de código (SAST) utiliza un método de Static Application Security Testing para escanear sus repositorios en busca de problemas de seguridad y calidad en el código propio, proporcionando sugerencias de corrección para evitar que estos problemas lleguen a producción.
• Software Composition Analysis (SCA) detecta bibliotecas de código abierto vulnerables presentes en sus repositorios y que afectan a sus servicios en tiempo de ejecución, ayudándole a proteger y mantener su cadena de suministro de software.
• Análisis de código en tiempo de ejecución (IAST) utiliza un método de prueba de seguridad de aplicaciones interactivas para detectar vulnerabilidades que afectan a sus servicios en tiempo de ejecución.

Configure Code Security

Bibliotecas de código abierto

Datadog Software Composition Analysis detecta vulnerabilidades en bibliotecas y cataloga las dependencias dentro de su base de código y los servicios en ejecución.

Consulte Software Composition Analysis para configurar la detección de vulnerabilidades de bibliotecas estáticas y/o en tiempo de ejecución.

Código propio

Integraciones de herramientas para desarrolladores

Habilite comentarios de solicitudes de extracción

Datadog puede actuar como un revisor de código automático para marcar vulnerabilidades y violaciones de calidad en las solicitudes de extracción de GitHub. Para obtener más información, consulte GitHub Pull Requests.

Instale integraciones de IDE

Instale los complementos de IDE de Datadog para identificar problemas de Code Security directamente en su editor de código. Dependiendo de su IDE, los complementos admiten las siguientes capacidades:

• Análisis estático de código (SAST)
• Software Composition Analysis (SCA)
• Análisis de código en tiempo de ejecución (IAST)
• Secret Scanning
• Escaneo de Infraestructura como Código (IaC)

Personalice la configuración de su repositorio

En Code Security Settings, puede administrar qué repositorios tienen habilitados los comentarios de PR, así como personalizar la configuración de qué reglas de Análisis estático de código (SAST) se aplican en todos los repositorios o dentro de ellos. Para ver todas las reglas predeterminadas proporcionadas por Datadog, consulte SAST Rules.

Configure PR Gates

Datadog proporciona PR Gates como una capacidad de la plataforma para ayudarle a mantener y aplicar estándares de seguridad y calidad para los cambios introducidos en su base de código. Para obtener más información, consulte PR Gate setup.

Priorice las vulnerabilidades con contexto de tiempo de ejecución

Code Security ofrece vistas centradas en vulnerabilidades de todas las vulnerabilidades de bibliotecas y código detectadas tanto a partir del escaneo estático de repositorios como de la detección de servicios en tiempo de ejecución.

Explore vulnerabilidades

Para las vulnerabilidades de bibliotecas, cada fila en la tabla representa una vulnerabilidad específica que afecta a una versión de biblioteca. Dependiendo de si tiene habilitada la detección estática o en tiempo de ejecución, la columna Detected In muestra los repositorios y/o servicios específicos afectados por esta vulnerabilidad.

En el panel lateral para una vulnerabilidad de biblioteca individual en SCA, además de los detalles sobre la vulnerabilidad, Datadog muestra:

• Un Severity breakdown de la instancia de mayor gravedad de esta vulnerabilidad observada en sus repositorios y sus servicios. Para cada ubicación detectada de la vulnerabilidad en sus repositorios y/o servicios, Datadog ajusta el puntaje de gravedad base de la vulnerabilidad según factores ambientales. Para obtener más información, consulte Puntaje de gravedad de Datadog.
• Una Repositories tabla de todas las instancias donde se detectó la vulnerabilidad en sus repositorios. Para cada instancia, Datadog muestra si la dependencia está clasificada como directa o transitiva, el estado de remediación de la vulnerabilidad, así como los pasos de remediación específicos.
• Una Impacted Services tabla de todos los servicios en ejecución afectados por esta vulnerabilidad de biblioteca. Un servicio se ve afectado por una vulnerabilidad de biblioteca si la biblioteca se cargó en tiempo de ejecución y fue detectada por los SDK de aplicación de Datadog.

Las gravedades se califican de la siguiente manera:

Explorar resultados por repositorio

Code Security también ofrece vistas centradas en el repositorio de los resultados de escaneos estáticos, lo que permite un filtrado granular en todas las ramas y confirmaciones para los repositorios escaneados.

Haga clic en un repositorio en la página Repositories para acceder a una vista más detallada donde puede personalizar la consulta de búsqueda por rama (con la rama predeterminada apareciendo primero) y por confirmación (comenzando con la más reciente).

Puede utilizar las siguientes facetas listas para usar para crear una consulta de búsqueda para identificar y resolver malas prácticas de codificación en la pestaña Code Quality o riesgos de seguridad en la pestaña Code Vulnerabilities.

Nombre de la faceta	Descripción
Estado del resultado	Filtra los resultados según el estado de finalización del análisis.
ID de la regla	Reglas específicas que activaron los hallazgos.
Nombre de la herramienta	Determina qué herramientas contribuyeron al análisis.
CWE (Enumeración de debilidades comunes)	Filtra los hallazgos por categorías de vulnerabilidad reconocidas.
Tiene correcciones	Filtra los problemas para los cuales hay correcciones sugeridas disponibles.
Mensaje de resultado	Contiene descripciones o mensajes concisos asociados con los hallazgos.
Descripción de la regla	Contiene la justificación detrás de cada regla.
Archivo fuente	Contiene los archivos donde se detectaron los problemas.
Versión de la herramienta	Filtra los resultados por la versión de las herramientas utilizadas.

Puede acceder a las correcciones sugeridas directamente desde los resultados para abordar vulnerabilidades de seguridad o mejorar las prácticas de calidad del código.

Puede utilizar las siguientes facetas listas para usar para crear una consulta de búsqueda para identificar y abordar riesgos de seguridad en bibliotecas de terceros en la pestaña Library Vulnerabilities o revisar su inventario de bibliotecas en la pestaña Library Catalog.

Nombre de la faceta	Descripción
Nombre de la dependencia	Identifica las bibliotecas por nombre.
Versión de la dependencia	Filtra por versiones específicas de bibliotecas.
Lenguaje	Ordena las bibliotecas por el lenguaje de programación.
Puntuación	Ordena la puntuación de riesgo o calidad de las dependencias.
Gravedad	Filtra las vulnerabilidades según su clasificación de gravedad.
Plataforma	Distingue las bibliotecas por la plataforma para la que están destinadas.

Puede acceder a los informes de vulnerabilidad y localizar los archivos fuente donde se descubrió la vulnerabilidad en sus proyectos, junto con información sobre los propietarios del código del archivo.

Notifique, remedie e informe

Code Security le ayuda a configurar flujos de trabajo para realizar un seguimiento y gestionar la remediación de los hallazgos:

• Configure reglas de notificación para notificar a su(s) equipo(s) sobre nuevos hallazgos a través de Slack, Jira, correo electrónico y más
• Realice un seguimiento de las vulnerabilidades por servicio y equipo en la página Code Security Summary.

Vincule los hallazgos a los servicios y equipos de Datadog

Datadog associates code and library scan results with Datadog services and teams to automatically route findings to the appropriate owners. This enables service-level visibility, ownership-based workflows, and faster remediation.

To determine the service where a vulnerability belongs, Datadog evaluates several mapping mechanisms in the order listed in this section.

Each vulnerability is mapped with one method only: if a mapping mechanism succeeds for a particular finding, Datadog does not attempt the remaining mechanisms for that finding.

Mapping using the Software Catalog (recommended)

Services in the Software Catalog identify their codebase content using the codeLocations field. This field is available in the Software Catalog [schema version v3][101] and allows a service to specify:

• a repository URL

apiVersion: v3
kind: service
metadata:
  name: billing-service
  owner: billing-team
datadog:
  codeLocations:
    - repositoryURL: https://github.com/org/myrepo.git

• one or more code paths inside that repository

apiVersion: v3
kind: service
metadata:
  name: billing-service
  owner: billing-team
datadog:
  codeLocations:
    - repositoryURL: https://github.com/org/myrepo.git
      paths:
        - path/to/service/code/**

If you want all the files in a repository to be associated with a service, you can use the glob ** as follows:

apiVersion: v3
kind: service
metadata:
  name: billing-service
  owner: billing-team
datadog:
  codeLocations:
    - repositoryURL: https://github.com/org/myrepo.git
      paths:
        - path/to/service/code/**
    - repositoryURL: https://github.com/org/billing-service.git
      paths:
        - "**"

The schema for this field is described in the [Software Catalog entity model][102].

Datadog goes through all Software Catalog definitions and checks whether the finding’s file path matches. For a finding to be mapped to a service through codeLocations, it must contain a file path.

Some findings might not contain a file path. In those cases, Datadog cannot evaluate codeLocations for that finding, and this mechanism is skipped.

Example (v3 schema)

apiVersion: v3
kind: service
metadata:
  name: billing-service
  owner: billing-team
datadog:
  codeLocations:
    - repositoryURL: https://github.com/org/myrepo.git
      paths:
        - path/to/service/code/**
    - repositoryURL: https://github.com/org/billing-service.git
      paths:
        - "**"

SAST finding

If a vulnerability appeared in github.com/org/myrepo at /src/billing/models/payment.py, then using the codeLocations for billing-service Datadog would add billing-service as an owning service. If your service defines an owner (see above), then Datadog links that team to the finding too. In this case, the finding would be linked to the billing-team.

SCA finding

If a library was declared in github.com/org/myrepo at /go.mod, then Datadog would not match it to billing-service.

Instead, if it was declared in github.com/org/billing-service at /go.mod, then Datadog would match it to billing-service due to the “**” catch-all glob. Consequently, Datadog would link the finding to the billing-team.

When the Software Catalog cannot determine the service

If the Software Catalog does not provide a match, either because the finding’s file path does not match any codeLocations, or because the service uses the v2.x schema, Datadog evaluates whether Error Tracking can identify the service associated with the code. Datadog uses only the last 30 days of Error Tracking data due to product [data-retention limits][103].

When Error Tracking processes stack traces, the traces often include file paths. For example, if an error occurs in: /foo/bar/baz.py, Datadog inspects the directory: /foo/bar. Datadog then checks whether the finding’s file path resides under that directory.

If the finding file is under the same directory:

• Datadog treats this as a strong indication that the vulnerability belongs to the same service.
• The finding inherits the service and team associated with that error in Error Tracking.

If this mapping succeeds, Datadog stops here.

Service inference from file paths or repository names

When neither of the above strategies can determine the service, Datadog inspects naming patterns in the repository and file paths.

Datadog evaluates whether:

• The file path contains identifiers matching a known service.
• The repository name corresponds to a service name.

When using the finding’s file path, Datadog performs a reverse search on each path segment until it finds a matching service or exhausts all options.

For example, if a finding occurs in github.com/org/checkout-service at /foo/bar/baz/main.go, Datadog takes the last path segment, main, and sees if any Software Catalog service uses that name. If there is a match, the finding is attributed to that service. If not, the process continues with baz, then bar, and so on.

When all options have been tried, Datadog checks whether the repository name, checkout-service, matches a Software Catalog service name. If no match is found, Datadog is unsuccessful at linking your finding using Software Catalog.

This mechanism ensures that findings receive meaningful service attribution when no explicit metadata exists.

Link findings to teams through Code Owners

If Datadog is able to link your finding to a service using the above strategies, then the team that owns that service (if defined) is associated with that finding automatically.

Regardless of whether Datadog successfully links a finding to a service (and a Datadog team), Datadog uses the CODEOWNERS information from your finding’s repository to link Datadog and GitHub teams to your findings.

Lecturas adicionales

Documentación, enlaces y artículos útiles adicionales:

Escriba código seguro con Datadog Code SecurityCENTRO DE APRENDIZAJE