GitHub Actions

Vue d'ensemble

L'action GitHub Auxilh/secuprobe-scan-action intègre SecuProbe à votre pipeline CI/CD. Elle lance un scan de sécurité à chaque pull request ou déploiement, attend le résultat, fait échouer le job quand une faille atteint la sévérité choisie, envoie le rapport SARIF vers l'onglet Security et tient à jour un commentaire unique sur la pull request.

Prérequis

1. Un compte SecuProbe. Le plan Free comprend 10 scans par API ; l'envoi vers l'onglet Security et le commentaire de pull request commencent au plan Starter.
2. Une clé d'API avec les périmètres scans:create et scans:read, créée dans Paramètres → API.
3. La clé stockée comme secret du dépôt GitHub sous le nom SECUPROBE_API_KEY.
4. Le domaine à scanner, ajouté à votre compte et validé. Une clé d'API ne peut scanner qu'un domaine validé de son propre compte.

Utilisation de base

# .github/workflows/security.yml
name: Security Scan

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read
  pull-requests: write      # pull request comment
  security-events: write    # SARIF upload to the Security tab

jobs:
  secuprobe:
    runs-on: ubuntu-latest
    steps:
      - name: Run SecuProbe Scan
        uses: Auxilh/secuprobe-scan-action@v1.1.0
        with:
          api_key: ${{ secrets.SECUPROBE_API_KEY }}
          url: https://staging.your-app.com
          fail-on: high

Paramètres d'entrée

Valeurs de sortie

Utilisation avancée

Donnez un identifiant à l'étape pour réutiliser ses sorties plus loin dans le job, par exemple pour afficher le score ou le nombre de nouvelles failles. Le paramètre timeout augmente l'attente maximale quand vous scannez une grande application.

- name: Run SecuProbe Scan
  id: scan
  uses: Auxilh/secuprobe-scan-action@v1.1.0
  with:
    api_key: ${{ secrets.SECUPROBE_API_KEY }}
    url: ${{ vars.STAGING_URL }}
    fail-on: medium
    timeout: '900'
    sarif_artifact: src/app.ts

- name: Print scan result
  if: always()
  run: |
    echo "SecuScore: ${{ steps.scan.outputs.secu_score }}"
    echo "New findings: ${{ steps.scan.outputs.new_findings }}"
    echo "Report: ${{ steps.scan.outputs.report_url }}"

Seuil d'échec

L'entrée fail-on fixe la sévérité à partir de laquelle le job échoue : critical, high, medium, low, ou none pour seulement rapporter. L'étape se termine avec un code non nul dès qu'une faille atteint ce niveau. Les failles que vous avez marquées risque accepté ou faux positif dans SecuProbe, et celles qui n'ont pas pu être confirmées, ne font pas échouer le job.

Onglet Security

L'action télécharge le scan au format SARIF 2.1.0 et l'envoie au code scanning de GitHub : les failles apparaissent dans l'onglet Security avec leur sévérité et leur CWE. Donnez au job la permission security-events: write. GitHub rattache chaque alerte à un fichier du dépôt : choisissez-le avec sarif_artifact. Le rapport ne contient aucune preuve de requête ou de réponse, qui reste dans SecuProbe.

Commentaire de pull request

Sur une pull request, l'action publie un seul commentaire et le met à jour à chaque exécution au lieu d'en ajouter un nouveau. Il liste les failles apparues depuis le scan précédent, celles qui ont été corrigées, et renvoie vers le rapport complet. Donnez au job la permission pull-requests: write, ou passez comment à false pour le désactiver.

Résumé du job GitHub

L'action écrit un résumé dans la page du job GitHub Actions avec le SecuScore, le nombre de failles par gravité et un lien vers le rapport complet. Les relecteurs voient le résultat sans quitter la pull request.

Bonnes pratiques

• Scannez un environnement de préproduction fidèle à la production et validez une fois la propriété de ce domaine : l'action ne peut scanner qu'un domaine validé.
• Commencez avec fail-on à critical, puis abaissez le seuil à high une fois les failles existantes corrigées.
• N'écrivez jamais la clé d'API dans le fichier de workflow. Stockez-la comme secret et renouvelez-la depuis les paramètres SecuProbe si elle est exposée.
• Lancez le scan sur les pull requests et les déploiements, et gardez une planification nocturne pour ce qui change hors de votre code, comme un certificat ou une CVE nouvellement publiée.