Nicolas Engel

L’introduction au DevSecOps que j’avais rédigée dans mon précédent article, avait mis en avant la nécessité de collaboration entre les développeurs et les exploitants de la solution afin que les exigences de sécurité soit suivies de manière pérenne. En effet, la logique DevOps a raccourci les cycles de livraison afin d’éviter l’effet tunnel, période durant laquelle la conception technique ne permet plus aux utilisateurs d’avoir en visibilité la livraison de la solution. L’accélération des livraisons applicatives qui en résulte, conjuguée à l’augmentation des cyberattaques aboutit à la nécessité d’automatiser les processus de sécurité. Parmi ces derniers, la revue de sécurité du code est l’une des clés d’une démarche DevSecOps réussie.

SAST vs DAST

L’industrialisation des langages de développements et des frameworks associés ont vu une multitude d’outils se développer pour scanner le code en matière de sécurité. Ces outils de SAST (Static Application Security Testing) analysent le code source d’une application ou d’un service afin d’identifier les vulnérabilités de sécurité potentielles résultant de pratiques de développement non sécurisées.

La bonne pratique consiste à utiliser les outils de SAST durant la phase de codage et/ou la phase de test afin d’identifier les vulnérabilités tôt dans le processus de développement. De tels outils peuvent certes générer des faux positifs, mais les résultats sont cruciaux dans l’évaluation de la sécurité de l’application.

Comme leur nom l’indique, l’analyse de ces outils est avant tout statique. Elle pourrait être dynamique en créant des scénarios de test de bout en bout notamment pour tester des webservices. L’usage de DAST (Dynamic Application Security Testing) est comparable mais le besoin est différent et nécessite une plus grande maturité des équipes en matière de sécurité. Ceci est particulièrement vrai pour les équipes effectuant les tests applicatifs, qui doivent souvent rentrer dans le code pour écrire des tests dynamiques exploitant tout le potentiel des solutions DAST. L’enjeu ici n’est pas de faire un comparatif de chaque type de solution. Pour des raisons de simplicité, cet article se concentre sur les solutions SAST.

Panel de solutions envisageables

Comment choisir une solution SAST efficiente et adaptée à ses besoins ?

Il faut tout d’abord comprendre le processus DevOps au sein de l’entreprise pour y associer la composante de sécurité. Les outils d’hébergement du code, qui servent parfois à également déployer l’application conditionne grandement les usages. Citons ici la plateforme Github rachetée en 2018 par Microsoft et constituant de facto un standard de l’industrie pour l’hébergement du code applicatif, son analyse et ses outils de collaborations offerts aux développeurs.

Sur Github, de multiples SAST existent de manière gratuite, freemium (c’est-à-dire partiellement payante) ou bien entièrement payante.

Le tableau ci-dessus n’est pas exhaustif mais constitue un panel représentatif des solutions en 2022.

Parmi toutes ces solutions que j’ai pu tester, une solution sort du lot de part sa polyvalence, la qualité de ses rapports ainsi que le fait qu’elle soit gratuite en Novembre 2022. Il s’agit de ShiftLeftSecurity.

Focus sur ShiftLeftSecurity

Solution open-source sous GPL v3.0, ShiftleftSecurity possède de nombreux avantages parmi lesquels:

• La capacité de scanner plus d’une dizaine de langages dont Python, Java, Go ou encore Terraforme
• L’architecture (sous forme de container Docker) est bien pensée et industrialisable.
• La documentation est riche et à jour.
• Enfin, la génération de rapport se fait sous plusieurs formats Bash, HTML, Json ou encore SARIF (ce dernier format est particulièrement adapté pour un IDE tel que Visual Studio).

Le lancement d’un scanner en ligne de commande est facile:

sh <(curl https://slscan.sh)

La commande ci-dessus invoque simplement la commande docker run ci-dessous.

docker run --rm -e "WORKSPACE=${PWD}" -v $PWD:/app shiftleft/scan scan --build

La solution utilisant Docker est donc modulaire et scalable. Les résultats sont également bien formatés. Ci-dessous un exemple de résultat de scanner permet de s’en faire une meilleure idée.

Industrialisation du SAST sur Github

ShiftLeftSecurity est en réalité un meta-moteur de scanner de sécurité, qui permet d’orchestrer plusieurs analyses via un script qui industrialise la démarche.

Dans cette même veine d’industrialisation, il est possible de bénéficier des Github Actions – ces évènements permettant d’automatiser des tâches d’intégration continue / déploiement continu – pour automatiser le scanner de sécurité sur un répertoire de code.

Ci-dessous un exemple de Github Action lançant automatiquement le scan de sécurité après chaque pull-request et uploadant les rapports dans un répertoire AWS S3.

# This workflow integrates ShiftLeft Scan with GitHub's code scanning feature
# cf. https://slscan.io/en/latest/integrations/github-actions/.

name: SAST tool through Shiftleft

# This section configures the trigger for the workflow. 
on:
  pull_request:
    #branches: [ main ]

jobs:
  Scan-Build:
    name: Scan-Build
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v1

      - name: Perform ShiftLeft Scan
        uses: ShiftLeftSecurity/scan-action@master
        env:
          WORKSPACE: https://github.com/${{ github.repository }}/blob/${{ github.sha }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          SCAN_AUTO_BUILD: true 
        with:
          output: reports

      #Generate and commit the baseline file for your master/main branch scans. Subsequent feature branch scans would use only the new findings for breaking the builds. 
      #cf. https://docs.github.com/en/actions/learn-github-actions/contexts
      - name: Update scan baseline on main branch
        if: ${{ github.ref == 'refs/heads/main' }}
        run: |
          cp reports/.sastscan.baseline .
          git config --global user.name "scan+github-actions[bot]"
          git config --global user.email "scan+github-actions[bot]@users.noreply.github.com"
          git add .sastscan.baseline
          git commit -m "Update scan baseline"
          git push

      #Upload the generated reports on AWS S3 bucket
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_KEY_ID  }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: eu-west-1

      - name: Upload report on S3 Bucket
        run: |
          aws s3 cp reports/ s3://security/${{ github.repository }}/ --recursive

En synthèse, cet exemple d’automatisation de scanner de sécurité sous Github démontre bien la tendance actuelle visant à automatiser la sécurité dans le code. Si le principe peut paraitre très attractif, il faut toutefois souligner plusieurs éléments qui viennent minorer les impacts positifs d’une telle démarche:

• Premièrement, les scanners de sécurité (SAST) ont tendance à se professionnaliser et donc à devenir payant. Il n’est pas certain que l’emploi d’une solution telle que ShiftLeftSecurity reste gratuit sur le long terme.
• De plus, les rapports de sécurité générés doivent être analysés et corrigés par les développeurs. Ce qui nécessite une charge de travail qui, elle, ne peut être automatisée.

« L’automatisation : système simplifiant tellement le travail qu’on finira par avoir besoin d’un cerveau électronique pour se tourner les pouces. »

Noctuel