Présentation

Datadog Software Composition Analysis (SCA) analyse vos dépôts à la recherche de bibliothèques open source et détecte les vulnérabilités de sécurité connues avant que vous ne passiez en production.

Pour commencer

1. Ouvrez les paramètres de Code Security.
2. Dans Activate scanning for your repositories, cliquez sur Manage Repositories.
3. Choisissez où exécuter les analyses SCA (Datadog-hosted ou CI pipelines).
4. Suivez les instructions de configuration pour votre fournisseur de code source.

Langages et manifestes de dépendances pris en charge

Datadog SCA analyse les bibliothèques dans les langages suivants en utilisant des manifestes de dépendances (tels que des fichiers de verrouillage et d’autres fichiers de manifeste pris en charge) pour identifier les dépendances vulnérables.

Remarque : Si un fichier packages.lock.json et un fichier .csproj sont tous deux présents, le packages.lock.json prévaut et permet une résolution de version plus précise.

Analyse sans fichier de verrouillage

Datadog SCA analyse les fichiers manifestes uniquement lorsqu’aucun fichier de verrouillage pris en charge n’est détecté. Lorsqu’un fichier de verrouillage est présent, il a priorité et le manifeste n’est pas analysé.

Sections prises en charge :

• package.json : dependencies, devDependencies et optionalDependencies
• pyproject.toml : PEP 621 dependencies et optional-dependencies, PEP 735 dependency-groups, ainsi que les sections de dépendances de Poetry

Sélectionnez l’emplacement d’exécution des analyses SCA statiques

Par défaut, les analyses s’exécutent lorsque vous validez des modifications qui mettent à jour les manifestes de dépendances ou les fichiers de verrouillage pris en charge dans un dépôt activé. Vous pouvez également exécuter SCA dans vos pipelines CI ; les jobs CI sont pris en charge pour les événements push.

Analyser avec l’analyse hébergée par Datadog

Vous pouvez exécuter les analyses SCA statiques de Datadog directement sur l’infrastructure Datadog. Les types de référentiels pris en charge incluent :

• GitHub (à l’exclusion des dépôts qui utilisent Git Large File Storage)
• GitLab.com et GitLab Self-Managed
• Azure DevOps
• Bitbucket Cloud

Pour commencer, accédez à la page Code Security.

Analyser dans les pipelines CI

Datadog Software Composition Analysis s’exécute dans vos pipelines CI à l’aide de l’datadog-ci CLI.

Si votre projet Java inclut directement des fichiers JAR tiers dans le dépôt au lieu d’utiliser un manifeste Maven ou Gradle, consultez Analyser les répertoires JAR Java.

Sélectionnez votre fournisseur de gestion de code source

Quel que soit le mode d’analyse utilisé, connectez votre fournisseur de gestion de code source pour activer les fonctionnalités natives telles que les extraits de code en ligne et les commentaires de pull request. Datadog SCA prend en charge tous les fournisseurs et offre une prise en charge native pour GitHub, GitLab, Azure DevOps et Bitbucket Cloud Premium.

Liez les résultats aux services et équipes 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 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.

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.

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.

Téléverser un SBOM tiers vers Datadog

Datadog recommande d’utiliser le générateur SBOM Datadog, mais il est également possible d’ingérer un SBOM tiers.

Vous pouvez téléverser des SBOM générés par d’autres outils s’ils répondent à ces exigences :

• Schéma JSON CycloneDX 1.4, 1.5 ou 1.6 valide
• Tous les composants ont le type library
• Tous les composants ont un attribut purl valide

Les fichiers SBOM tiers sont téléversés vers Datadog à l’aide de la commande datadog-ci.

Vous trouverez des arguments optionnels et d’autres informations dans le datadog-ci README.

Vous pouvez utiliser la commande suivante pour téléverser votre SBOM tiers. Assurez-vous que les variables d’environnement DD_API_KEY, DD_APP_KEY et DD_SITE sont définies respectivement sur votre clé d’API, votre clé d’application et votre site Datadog.

datadog-ci sbom upload /path/to/third-party-sbom.json

Filtrer par vulnérabilités atteignables

Datadog propose une analyse statique de la facilité d’accès pour aider les équipes à évaluer si les chemins de code vulnérables dans les dépendances sont référencés au sein de leur code applicatif. Cette fonctionnalité permet une priorisation plus efficace en identifiant les vulnérabilités qui sont statiquement inatteignables et qui présentent donc un risque immédiat minimal.

Cette fonctionnalité n’est prise en charge que lors de l’utilisation du générateur SBOM Datadog avec le flag --reachability activé ou lors de l’exécution d’analyses via l’infrastructure hébergée par Datadog.

L’analyse de la facilité d’accès est disponible exclusivement pour les projets Java et s’applique uniquement à un ensemble défini d’avis de sécurité approuvés. Les vulnérabilités non incluses dans cet ensemble sont exclues de l’évaluation de la facilité d’accès.

Conservation des données

Datadog conserve les résultats conformément à nos Périodes de conservation des données . Datadog ne stocke ni ne conserve le code source des clients .

Pour aller plus loin