SARIF en un paragraphe
SARIF (Static Analysis Results Interchange Format) est un standard OASIS — actuellement en version 2.1.0 — pour représenter la sortie d'outils d'analyse statique dans un schéma JSON unique. Plutôt que chaque scanner invente son propre format de rapport, les outils qui parlent SARIF s'intègrent directement à GitHub Code Scanning, GitLab SAST, Azure DevOps et la plupart des tableaux de bord sécurité, sans parseur maison. Il regroupe les findings sous un tableau tool.driver.rules (métadonnées des règles) et un tableau results (chaque finding : ID de règle, sévérité, fichier, ligne, message).
Générer le rapport
Un seul flag, exécutable depuis n'importe quel runner CI ou votre propre machine :
./staticcodeaudit-linux-x86_64 /path/to/project --sarif --fail-on-highCela écrit deux fichiers à côté du rapport HTML habituel : un fichier SCA-SARIF-<timestamp>.sarif et le SCA-REPORT-<timestamp>.html habituel — l'export SARIF s'ajoute, il ne remplace rien. --fail-on-high est optionnel mais c'est ce qui fait réellement bloquer un pipeline : le process quitte avec le code 1 dès qu'un finding de sévérité HIGH est présent, 0 sinon.
Ce que contient réellement le fichier
Un exemple réel raccourci — un finding, produit en scannant un extrait vulnérable de deux lignes :
{
"$schema": "https://raw.githubusercontent.com/oasis-tcs/sarif-spec/main/sarif-2.1/schema/sarif-schema-2.1.0.json",
"version": "2.1.0",
"runs": [{
"tool": {
"driver": {
"name": "StaticCodeAudit",
"version": "1.0.0",
"informationUri": "https://codefixture.com",
"rules": [{
"id": "hardcoded_secret",
"name": "Hardcoded secret",
"fullDescription": { "text": "Plain text secrets in code can be exposed via Git repository." },
"defaultConfiguration": { "level": "error" }
}]
}
},
"results": [{
"ruleId": "hardcoded_secret",
"level": "error",
"message": { "text": "Plain text secrets in code can be exposed via Git repository." },
"locations": [{
"physicalLocation": {
"artifactLocation": { "uri": "app.py" },
"region": { "startLine": 6 }
}
}],
"fixes": [{ "description": { "text": "Use environment variables or system_configs in database." } }]
}]
}]
}Chaque result porte un chemin de fichier, un numéro de ligne, et — quand une remédiation est connue — une entrée fixes avec une suggestion en langage clair. GitHub Code Scanning affiche tout cela directement dans l'onglet Security, annoté sur la ligne exacte dans la vue diff.
SARIF ou SBOM — jamais les deux dans le même run
StaticCodeAudit exporte aussi un inventaire de dépendances au format CycloneDX 1.5 (--sbom), mais les deux exports sont mutuellement exclusifs par run — ils répondent à des questions différentes (vulnérabilités trouvées vs. dépendances existantes) et les mélanger dans un seul fichier rendrait les deux plus difficiles à exploiter correctement en aval. Demander les deux à la fois échoue immédiatement :
$ ./staticcodeaudit-linux-x86_64 /path/to/project --sarif --sbom
❌ --sarif and --sbom are mutually exclusive. Use one or the other.Lancez le scan deux fois en CI si vous avez besoin des deux artefacts — chaque run prend nettement moins d'une seconde sur une base de code petite à moyenne. Voir le guide export SBOM pour le volet inventaire de dépendances.
Le brancher sur GitHub Code Scanning
L'action officielle GitHub upload-sarif lit n'importe quel fichier SARIF 2.1.0, quel que soit l'outil qui l'a produit. Une étape de workflow minimale :
- name: Run StaticCodeAudit
run: ./staticcodeaudit-linux-x86_64 /path/to/project --sarif --fail-on-high
- name: Upload SARIF to GitHub Code Scanning
if: always()
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: docs/audit-reports/*.sarifif: always() est important ici : sans lui, un finding HIGH (qui fait quitter l'étape précédente avec le code 1) sauterait l'étape d'upload et vous ne verriez jamais les résultats dans l'onglet Security — vous sauriez juste que le pipeline a échoué, pas pourquoi.
Disponibilité
L'export SARIF est inclus à partir du palier Team (Team, Team Plus, Enterprise) ; le palier Solo exporte uniquement en HTML. Détail complet sur la page tarifs.
Questions fréquentes
Générer un rapport SARIF envoie-t-il quoi que ce soit sur le réseau ?
Non. Le fichier SARIF est écrit sur disque local, à côté du rapport HTML, à partir de données déjà calculées durant le scan local. StaticCodeAudit n'effectue aucun appel réseau sortant pendant un scan, vérifiable avec un moniteur réseau (tcpdump -i any -n) — générer un format d'export supplémentaire ne change rien à cela.
Puis-je utiliser le fichier SARIF avec GitLab ou une autre plateforme que GitHub ?
Oui — SARIF 2.1.0 est un standard OASIS générique, pas spécifique à GitHub. GitLab, Azure DevOps et la plupart des tableaux de bord sécurité qui supportent « import SARIF » acceptent le même fichier sans modification. L'exemple ci-dessus utilise l'action upload-sarif de GitHub car c'est la cible la plus courante, pas parce que le format y est lié.
Pourquoi --sarif --sbom échoue au lieu de produire les deux fichiers ?
C'est un choix de conception explicite, pas une fonctionnalité manquante : un fichier SARIF décrit des findings, un SBOM CycloneDX décrit un inventaire de dépendances — les fusionner en un seul export rendrait les deux plus difficiles à exploiter correctement en aval. Lancez le scan deux fois (ou dans deux jobs CI parallèles) si votre pipeline a besoin des deux artefacts sur le même commit.
Chaque finding inclut-il une suggestion fixes ?
Seulement là où StaticCodeAudit connaît un pattern de remédiation pour cette règle — l'exemple ci-dessus (hardcoded_secret) en a une, mais toutes les règles n'en embarquent pas encore une. En son absence, l'entrée results porte quand même l'emplacement et le message complets, juste sans le champ fixes.
Testez-le sur votre propre code
Ouvrez le rapport de démonstration en ligne — sans installation, sans inscription — ou lancez le binaire sur un petit projet et inspectez vous-même le fichier SARIF.
Ouvrir le rapport en ligne Télécharger le binaire de démo