Adoptez l'approche DevSecOps grâce à Bitbucket Pipelines et Snyk Pipe

This tutorial outlines how to secure your build workflow on Bitbucket Pipelines with Snyk. An important step in securing your environment is to scan and analyze both your application and Linux-based container project for known vulnerabilities, which helps you identify and mitigate security vulnerabilities. The exercises in this tutorial will help secure your application and container by leveraging the Snyk Pipe for Bitbucket Pipelines to scan the application manifest file and the container base image for its dependencies.

The tutorial, How Snyk and Bitbucket Cloud enable DevSecOps, focused on application dependencies. However, by also scanning your container base image you can detect:

• The operating system (OS) packages installed and managed by the package manager
• Key binaries —layers that were not installed through the package manager

Based on these results, Snyk provides advice and guidance, including:

• Origins of the vulnerabilities in OS packages and key binaries
• Base image upgrade details or a recommendation to rebuild the image
• Dockerfile layer where the affected package was introduced
• Fixed-in version of the operating system and key binary packages

This example leverages the Snyk Scan pipe in the pipeline to perform a scan of the application. The source contains a complete, YAML definition of all supported variables, but only those included in this snippet are necessary for this purpose.

Here’s a closer look at a few of these:

1. SNYK_TOKEN is passed into the pipe as a repository variable previously defined in the [Bitbucket Configuration] module.

2. PROJECT_FOLDER is the folder where the project resides and normally defaults to. However, in this example, we set this to app/goof and pass this as an artifact to other steps in ther pipeline.

3. CODE_INSIGHTS_RESULTS defaults to false. However, since we want to create a Code Insight report with Snyk test results, set this to true.

4. SEVERITY_THRESHOLD reports on issues equal or higher to the provided level. The default is low. But in this case, we are interested only in high, so we defined this variable accordingly.

5. The DONT_BREAK_BUILD default is false, which is expected. Under normal circumstances, you would want to break the build if issues are found. However, for the purpose of this learning exercise, set this to true.

D'ici 2022, plus de 75 % des entreprises mondiales exécuteront des apps conteneurisées en production (Gartner). Parallèlement à l'adoption généralisée, une augmentation des vulnérabilités de conteneurs a été constatée, avec une multiplication par 4 des vulnérabilités de système d'exploitation en 2018. Pourtant, 80 % des développeurs affirment ne pas tester leurs images de conteneur pendant le développement. Soit parce qu'ils affirment que cette tâche ne relève pas de leur responsabilité, soit parce qu'ils sont habitués à ce que quelqu'un détecte les problèmes plus tard dans le processus. En conséquence, la mise à l'échelle de la sécurité des conteneurs se révèle un défi pour les entreprises à croissance rapide.

Il s'agit de créer l'image du conteneur et de la baliser, puis de tirer parti du pipe Snyk Scan dans le pipeline pour effectuer une analyse de l'image de conteneur. Conservez les mêmes valeurs pour CODE_INSIGHTS_RESULTS, SEVERITY_THRESHOLD et DONT_BREAK_BUILD. Cela transmet également quelques autres variables prises en charge. Celles-ci sont pertinentes pour le pipe Snyk afin de comprendre la demande d'analyse : une image de conteneur plutôt qu'une app. Il s'agit notamment de définir LANGUAGE sur docker, de déclarer la valeur IMAGE_NAME et de transmettre la variable de dépôt appropriée, ainsi que de définir la valeur de TARGET_FILE sur Dockerfile.

Votre pipeline analyse désormais l'image de conteneur à la recherche de vulnérabilités connues, ainsi que le code de votre app.

Découvrez plus d'intégrations pour Atlassian Open DevOps.