Action Github Ostorlab

1. Générer une nouvelle clé API

Pour utiliser l'Action Github Ostorlab, la première étape consiste à générer une clé API. Pour ce faire, suivez simplement les étapes suivantes :

Accédez à report.ostorlab.co

Cliquez sur le bouton Menu

Cliquez sur Integrations/API pour développer

Cliquez sur API Keys

Cliquez sur New pour générer une nouvelle clé API

Copiez la clé API. Vous pouvez également ajouter un nom et une date d'expiration à votre clé.

N'oubliez pas de cliquer sur le bouton enregistrer pour sauvegarder votre clé.

2. Ajouter l'Action Github Ostorlab à votre workflow

Une fois que vous avez généré votre clé API, ajoutez-la aux GitHub Secrets. Assurez-vous que le nom correspond à secrets. dans le fichier YAML. Vous pouvez suivre les étapes dans la documentation Github au lien suivant pour des instructions plus détaillées.

L'étape suivante consiste à mettre à jour votre workflow pour ajouter une étape Ostorlab afin de déclencher le scan. Voici un exemple effectuant un scan rapide sur un APK Android et faisant échouer le pipeline si le niveau de risque du scan est supérieur à HIGH (c'est-à-dire CRITICAL).

on: [push]
jobs:
  ostorlab_test:
    runs-on: ubuntu-latest
    name: Test ostorlab ci actions.
    steps:
      - uses: actions/checkout@v4
      - name: build ostorlab.apk
        run: mv InsecureBankv2.apk ostorlab.apk
      - name: Launch Ostorlab scan
        id: start_scan
        uses: Ostorlab/ostorlab_actions@v2.1.0
        with:
          scan_profile: fast_scan # Précisez quel profil de scan utiliser pour le scan (vérifier la section scan).
          asset_type: android-apk # type d'actif à scanner.
          target: ostorlab.apk # chemin de la cible à scanner.
          scan_title: title_scan_ci # tapez un titre pour votre scan.
          ostorlab_api_key: ${{ secrets.ostorlab_api_key }} # votre clé api secrète.
          break_on_risk_rating: HIGH # Attendre les résultats du scan et forcer l'échec de l'action si le risque du scan est supérieur (ici : CRITICAL)
          max_wait_minutes: 30
      - name: Get scan id
        run: echo "Scan Created with id ${{ steps.start_scan.outputs.scan_id }} you can access the full report at https://report.ostorlab.co/scan/${{ steps.start_scan.outputs.scan_id }}/"

3. Scanner les Applications Web

En plus des applications mobiles, Ostorlab prend également en charge le scan des applications web via les workflows GitHub. Pour scanner des applications web, configurez votre workflow comme indiqué dans l'exemple ci-dessous :

on: [push]
jobs:
  ostorlab_web_scan:
    runs-on: ubuntu-latest
    name: Test ostorlab web scan.
    steps:
      - uses: actions/checkout@v4
      - name: Launch Ostorlab web scan
        id: start_scan
        uses: Ostorlab/ostorlab_actions@v2.1.0
        with:
          scan_profile: full_web_scan
          asset_type: link --url
          target: https://target1.ostorlab.co --url https://target2.ostorlab.co --url https://target3.ostorlab.co
          scan_title: web_scan_ci
          ostorlab_api_key: ${{ secrets.ostorlab_api_key }}
          break_on_risk_rating: HIGH
          max_wait_minutes: 60
      - name: Get scan id
        run: echo "Scan Created with id ${{ steps.start_scan.outputs.scan_id }} you can access the full report at https://report.ostorlab.co/scan/${{ steps.start_scan.outputs.scan_id }}/"

Pour le scan des applications web :

• Utilisez scan_profile: full_web_scan
• Définissez asset_type: link --url
• Listez vos URL cibles avec l'indicateur --url pour chaque URL supplémentaire

Les actions Github d'Ostorlab prennent les entrées suivantes :

scan_profile, qui est une option obligatoire précisant le profil de scan, qui peut être fast_scan pour une analyse statique rapide uniquement, full_scan pour une couverture complète statique, dynamique et backend, ou full_web_scan pour le scan d'applications web.

asset_type, une option obligatoire qui précise le type d'actif cible, par exemple, Android APK, iOS IPA, ou lien pour les applications web.

target, une option obligatoire. C'est le fichier cible à scanner ou l'URL pour les applications web.

scan_title, une option facultative. C'est un titre pour identifier votre scan.

ostorlab_api_key, une option obligatoire. Vous pouvez l'obtenir depuis le tableau de bord Ostorlab, dans Integrations/API puis API Keys.

break_on_risk_rating, une option facultative. Lorsqu'elle est définie, l'action attend la fin du scan et le pipeline échoue si le niveau de risque du scan est strictement supérieur à la valeur fournie : HIGH n'échoue que sur un scan CRITICAL. Sans cette option, l'action n'attend pas le résultat.

max_wait_minutes, une option facultative. C'est le temps d'attente maximum en minutes (par défaut : 20) lorsque break_on_risk_rating est défini. Si le scan n'est pas terminé à la fin de l'attente, l'étape échoue avec une erreur de délai d'attente.

extra, une option facultative. c'est un argument supplémentaire à passer au CLI Ostorlab. Un cas d'utilisation courant est le passage des identifiants de test de scan.

Vous pouvez fournir vos fichiers SBOM ou Lock pour améliorer l'analyse du scan. Pour ce faire, utilisez l'entrée extra pour passer le SBOM, par exemple pour ajouter un fichier package lock dot json, utilisez l'exemple suivant :

Ici vous pouvez voir la liste des fichiers supportés :

Ostorlab permet de réaliser des tests authentifiés avec un simple mot de passe de connexion ou des entrées personnalisées identifiées par un nom ou une étiquette et en passant la valeur. Pour passer les identifiants de test, puisque l'Action YAML de Github ne supporte pas le passage d'objets complexes, vous pouvez utiliser l'entrée extra pour passer les identifiants de test. Par exemple, pour ajouter un login & un mot de passe et des identifiants personnalisés avec des noms et des valeurs personnalisés, ajoutez l'entrée suivante :

En ce qui concerne la sortie de l'action, il est possible d'accéder au scan_id en utilisant la syntaxe suivante ${{ steps.STEP_ID.outputs.scan_id }}.

4. Utilisez l'application GitHub Ostorlab Security Scanner pour fournir des informations exploitables directement dans votre PR

L'application GitHub Ostorlab Security Scanner doit être utilisée conjointement avec un workflow GitHub Actions Ostorlab tel qu'expliqué aux étapes 1 et 2.

L'application GitHub Ostorlab Security Scanner est conçue pour aider les développeurs à améliorer la sécurité de leur code en fournissant des informations exploitables directement dans les Pull Requests. Elle intègre la sécurité dans le flux de travail de développement avec pour objectif principal d'identifier avec précision quel élément de code a introduit la vulnérabilité, fournir des informations exploitables et des suggestions de code que vous pouvez valider automatiquement. Ce document fournit des instructions sur la façon de configurer et d'utiliser l'application.

1. Ajouter l'application GitHub :

   1. Accédez à l'Application Ostorlab Security Scanner.
      
   2. Cliquez sur Add.
      
   3. Choisissez le compte où vous souhaitez installer l'application.
      
   4. Cliquez sur Install for free.
      

   5. Fournissez les permissions nécessaires :

      • Accès Read & Write aux pull requests.
      • Accès Metadata pour le dépôt.

      

   6. Cliquez sur Install pour finaliser la configuration.
      

2. Comment utiliser :

   1. L'étape suivante consiste à mettre à jour votre workflow pour ajouter une étape Ostorlab afin de déclencher le scan tel que décrit aux étapes 1 et 2.
      
   2. Créez une pull request intégrant le workflow mis à jour avec Ostorlab.
      
      Une fois le scan terminé, Ostorlab Security Scanner commentera automatiquement votre pull request, en indiquant précisément où la vulnérabilité a été introduite et en fournissant des extraits de code pour la correction.
      

5. Du scan au correctif vérifié

Pour empêcher les changements risqués d'atteindre une release, exécutez le scan en cinq étapes :

Étape	Ce qui s'exécute
1. Scanner chaque pull request	L'action s'exécute à chaque pull request : un Fast Scan pour un build mobile, ou un Full Web Scan pour une application web.
2. Conditionner au risque	Le build échoue lorsque la note de risque du scan est strictement supérieure à break_on_risk_rating.
3. Envoyer les tickets vers Jira ou Linear	Les vulnérabilités deviennent des tickets Ostorlab, synchronisés avec Jira ou Linear.
4. Vérifier le correctif	Un scan ultérieur marque un ticket corrigé comme FIXED VERIFIED ou le rouvre. Un Single Vulnerability Assessment reteste une vulnérabilité.
5. Évaluation approfondie avant la release	Un Deep Agentic Scan s'exécute avant la release, et non à chaque pull request.

Scanner chaque pull request et conditionner au risque

Exécutez le workflow sur les pull requests : définissez on: pull_request au lieu de on: [push]. break_on_risk_rating fait échouer le build lorsque la note de risque du scan est strictement supérieure à la valeur définie, et max_wait_minutes limite l'attente (20 minutes par défaut). Pour choisir un seuil, consultez Évaluation des risques pour la signification de chaque note.

Envoyer les tickets vers Jira ou Linear

Ostorlab crée automatiquement un ticket pour chaque problème de sécurité nouvellement détecté, et agrège les occurrences ultérieures de la même vulnérabilité dans le même ticket. Pour envoyer ces tickets vers l'outil de suivi de votre équipe, activez la création automatique de tickets dans l'intégration Jira ou Linear. Les deux nécessitent un abonnement entreprise. Dans chaque intégration, choisissez les notes de risque des tickets à synchroniser : seuls les tickets ayant ces notes parviennent à Jira ou à Linear.

Vérifier le correctif

Lorsqu'un développeur livre un correctif, marquez le ticket comme corrigé. Un scan ultérieur qui exécute les mêmes tests vérifie alors le correctif : si la vulnérabilité est absente, le ticket est automatiquement marqué FIXED VERIFIED ; sinon, le même ticket est rouvert. Les tickets marqués comme exception ou comme faux positif restent inchangés. Consultez Cycle de vie des tickets.

Pour retester une vulnérabilité sans relancer un scan complet, lancez un Single Vulnerability Assessment directement depuis le ticket signalé. Il prend généralement de 2 à 10 minutes.

Contrôles continus et évaluations approfondies

Les contrôles continus s'exécutent à chaque pull request ou selon une planification et se terminent en quelques minutes. Les évaluations approfondies s'exécutent avant une release, durent de 1 à 3 heures et valident les chaînes d'attaque et la logique métier par une preuve de concept. Consultez Comparatif des types de scan.

Scan	Quand l'exécuter	Durée typique	Ce qu'il couvre	Fournisseur d'IA
Fast Scan (contrôle continu)	À chaque pull request, en CI	1 à 5 minutes	Analyse statique	Aucun
Full Scan (contrôle continu)	Selon une planification	15 à 45 minutes	Tests statiques, dynamiques et backend	Aucun
Deep Agentic Scan (évaluation approfondie)	Avant une release	1 à 3 heures	Pentest par agent IA : chaînes d'attaque, logique métier, vulnérabilités validées par une preuve de concept	Cyber Models ou votre propre clé (BYOK)

• Full Scans planifiés : créez une règle de surveillance avec une planification CRON, ou une règle CONTINUOUS qui scanne lorsque l'actif change, et sélectionnez Full Scan. Consultez Créer une règle de surveillance.
• Deep Agentic Scan avant release : lancez-le depuis Scanning > New Scan dans la plateforme. Consultez Mobile Deep Agentic Scan ou Web Deep Agentic Scan. Il nécessite un fournisseur d'IA : Cyber Models ou votre propre clé (BYOK). Ses résultats sont produits par des agents IA, sans validation humaine.

Ce guide a décrit comment ajouter l'Action GitHub Ostorlab à un workflow, scanner des applications web, utiliser l'Application GitHub Ostorlab Security Scanner et exécuter un pipeline de release, du scan au correctif vérifié.