SARIF Expliqué : Intégrer les Résultats de Pentest dans Votre Pipeline CI/CD

Qu'est-ce que SARIF#

SARIF (Static Analysis Results Interchange Format) est un standard OASIS — actuellement à la version 2.1.0 — qui définit un schéma JSON pour la sortie des outils de sécurité et d'analyse. Son objectif est l'interopérabilité : une équipe qui exécute cinq outils de sécurité différents ne devrait pas avoir besoin de cinq parseurs différents.

Avant SARIF, chaque outil de sécurité avait son propre format de sortie. Intégrer un nouveau scanner dans votre pipeline impliquait d'écrire un parseur personnalisé, de normaliser les niveaux de sévérité entre différentes échelles, et de construire des tableaux de bord sur mesure. SARIF résout ce problème au niveau du format.

Les principales plateformes CI/CD supportent SARIF à des degrés variables. GitHub Code Scanning consomme SARIF nativement et affiche les findings sous forme d'annotations inline sur les pull requests, en suivant les problèmes ouverts et résolus d'un commit à l'autre. Azure DevOps prend en charge SARIF via l'extension SARIF SAST Scans Tab. Les Vulnerability Reports de GitLab Ultimate acceptent également l'import SARIF, avec quelques limitations sur le mapping de certains champs.

Structure d'un Fichier SARIF#

Un fichier SARIF est un document JSON avec un schéma défini. La structure de haut niveau :

{
  "$schema": "https://www.schemastore.org/sarif-2.1.0.json",
  "version": "2.1.0",
  "runs": [
    {
      "tool": {
        "driver": {
          "name": "BreachVex",
          "version": "1.0.0",
          "rules": [
            {
              "id": "BV-IDOR-001",
              "name": "InsecureDirectObjectReference",
              "shortDescription": {
                "text": "Broken Object Level Authorization"
              },
              "helpUri": "https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/",
              "properties": {
                "tags": ["security", "owasp-api-top-10"]
              }
            }
          ]
        }
      },
      "results": [
        {
          "ruleId": "BV-IDOR-001",
          "level": "error",
          "message": {
            "text": "IDOR on /api/users/{id}: User A's token retrieved User B's profile data."
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "https://app.example.com/api/users/8472"
                }
              }
            }
          ],
          "fingerprints": {
            "primaryLocationLineHash/v1": "a1b2c3d4e5f6"
          }
        }
      ]
    }
  ]
}

Champs clés :

• tool.driver.rules — définit le catalogue de règles, référencé par ruleId dans chaque finding
• results[].level — error, warning ou note (correspond à Critique/Élevé, Moyen, Faible sur la plupart des plateformes)
• results[].fingerprints — permet la déduplication entre les exécutions ; les findings avec des empreintes correspondantes sont traités comme le même problème
• locations — pour les outils DAST et pentest, il s'agit d'une URI plutôt que d'une ligne de fichier source

Intégration avec GitHub Code Scanning#

Une fois le fichier SARIF disponible, l'intégration dans GitHub ne nécessite que trois lignes de YAML GitHub Actions :

- name: Upload pentest results to GitHub Code Scanning
  uses: github/codeql-action/upload-sarif@v4
  with:
    sarif_file: results/breachvex-results.sarif
    category: pentest

permissions:
  security-events: write

Après l'upload, les findings apparaissent dans l'onglet Security > Code Scanning du dépôt. Ils sont liés au SHA du commit, ce qui vous permet de suivre quand un problème a été introduit et quand il a été résolu. Les vérifications de pull request échouent si de nouveaux findings de niveau error sont introduits.

Comment BreachVex Exporte en SARIF#

Chaque scan BreachVex produit un export SARIF 2.1.0 en complément des rapports PDF et JSON. La sortie SARIF inclut :

• Une entrée de règle par classe de vulnérabilité détectée (IDOR, SQLi, XSS, SSRF, SSTI, et autres)
• Le score CVSS au niveau du résultat dans properties — calculé de la même façon que notre calculateur CVSS v4.0 gratuit, pour vérifier la sévérité de n'importe quel finding à la main
• La requête HTTP et la réponse complètes du proof-of-exploit en tant que relatedLocations
• Des hachages d'empreintes pour la déduplication entre les exécutions de scan
• Les identifiants CWE et les tags de catégorie OWASP pour le filtrage dans les chaînes d'outils

La logique d'empreinte garantit que si une vulnérabilité est présente lors de l'exécution N et toujours présente lors de l'exécution N+1, GitHub Code Scanning la traite comme le même problème ouvert plutôt que de créer une alerte en double.

Pourquoi le Format Standardisé Importe#

La valeur concrète de SARIF n'est pas le format en lui-même — c'est ce que ce format rend possible. Lorsque tous vos outils de sécurité parlent le même langage, vous pouvez :

• Agréger les findings de SAST, DAST et outils de pentest dans un seul tableau de bord sans code de liaison personnalisé
• Suivre la remédiation dans le temps en utilisant la gestion des problèmes intégrée à la plateforme (états des alertes : ouvert, ignoré, corrigé)
• Bloquer les pull requests sur les nouveaux findings de niveau error dans tous les outils via un seul contrôle security-events
• Exporter les findings vers JIRA ou Linear via l'intégration webhook de la plateforme plutôt que de construire un connecteur personnalisé par outil

Pour les équipes qui exécutent plusieurs outils de sécurité sur plusieurs dépôts, SARIF élimine la taxe d'intégration qui incombe autrement à l'équipe d'ingénierie sécurité.