clair cicd

clair

Clair, publié par Coreos en novembre 16, est un outil très efficace pour analyser statiquement les images Docker pour déterminer les vulnérabilités connues dans les images. Intégration de Clair dans un pipeline CI / CD:

1. est complexe (croyez que c'est en partie un défi de documentation)
2. Crée des problèmes de performances (la construction de la base de données de Postgres requise Clair est lente)
3. En soi, il est insuffisant d'un point de vue d'évaluation des risques car une fois les vulnérabilités identifiées, il y a un manque de directives normatives sur la façon d'agir sur les vulnérabilités identifiées

Ce dépôt a été créé pour relever les défis ci-dessus.

Arrière-plan

Les racines de ce repo se concentrent sur les croyances suivantes:

• Lorsqu'il est inséré dans un pipeline CI / CD, Clair peut être une base très efficace pour automatiser l'évaluation des risques des vulnérabilités d'image Docker
• Les services doivent être exécutés dans des conteneurs Docker et donc les pipelines CI / CD doivent être axés sur la génération automatisée, l'évaluation et finalement le déploiement d'images Docker
• La compréhension et l'évaluation du profil de risque des services sont importants, c'est-à-dire. La sécurité est importante
• Les images Docker ne doivent pas être poussées à un registre Docker jusqu'à ce que leur profil de risque soit compris (celle-ci est importante)
• Les pipelines CI / CD devraient être rapides. À quelle vitesse? Idéalement <5 minutes entre le code de code et le déploiement automatisé commence
• Il devrait y avoir une division claire des responsabilités entre ceux qui créent une image Docker (ingénieur de services) et ceux qui déterminent le risque de vulnérabilités dans une image Docker (analyste de sécurité)
• Le processus d'évaluation des risques devrait générer des preuves qui peuvent être utilisées pour comprendre la décision d'évaluation des risques

Participants clés

• Ingénieur de service - Responsable de la mise en œuvre d'un service emballé dans une image Docker
• Analyste de sécurité - Responsable de la définition de listes blanches qui sont consommées par clair_cicd pour influencer les décisions d'évaluation des risques d'image Docker

Comment utiliser

Commencer

Pour commencer à utiliser clair-cicd , un ingénieur de service insère une seule ligne de code dans le pipeline CI d'un service. La ligne de code unique exécute le script de shell Assess-Image-Risk.sh. Une partie de la responsabilité du pipeline CI est de construire l'image Docker, puis de pousser cette image Docker vers un registre Docker. La ligne unique de code clair-cicd devrait apparaître après la construction et le test de l'image Docker, mais avant que l'image Docker ne soit poussée vers un registre Docker.

Dans ce cas simple, Assess-Image-Risk.sh renvoie un statut de sortie zéro si l'image Docker ne contient aucune vulnérabilité connue au-dessus d'une gravité moyenne. Si l'image Docker contient des vulnérabilités connues avec une gravité supérieure à un moyen, Assess-Image-Risk.sh renvoie un statut de sortie non nul et que la construction échoue, c'est-à-dire. La construction doit échouer avant que l'image Docker ne soit poussée à un registre Docker.

L'exemple illustre ce qui est décrit pour l'image Alpine: 3.4 Docker.

 ~ > curl -s -L 
  https://raw.githubusercontent.com/simonsdave/clair-cicd/master/bin/assess-image-risk.sh | 
  bash -s -- alpine:3.4
~ > echo $?
0
~ > 

Comprendre la décision d'évaluation des risques

Pour comprendre comment assess-image-risk.sh prend sa décision d'évaluation des risques, essayez en utilisant le drapeau -v .

 ~ > curl -s -L 
  https://raw.githubusercontent.com/simonsdave/clair-cicd/master/bin/assess-image-risk.sh | 
  bash -s -- -v alpine:3.4
2020-01-12 16:43:35 pulling clair database image ' simonsdave/clair-cicd-database:latest '
2020-01-12 16:44:17 successfully pulled clair database image
2020-01-12 16:44:17 starting clair database container ' clair-db-c1dbb5f93ae98755 '
2020-01-12 16:44:23 waiting for database server in container ' clair-db-c1dbb5f93ae98755 ' to start ...........................
2020-01-12 16:44:54 successfully started clair database container
2020-01-12 16:44:54 clair configuration in ' /var/folders/7x/rr443kj575s8zz54jrbrp4jc0000gn/T/tmp.ElAlhGNl '
2020-01-12 16:44:59 pulling clair image ' simonsdave/clair-cicd-clair:latest '
2020-01-12 16:45:13 successfully pulled clair image ' simonsdave/clair-cicd-clair:latest '
2020-01-12 16:45:13 starting clair container ' clair-e9573ae537134fa0 '
2020-01-12 16:45:15 successfully started clair container ' clair-e9573ae537134fa0 '
2020-01-12 16:45:15 saving docker image ' alpine:3.4 ' to ' /tmp/tmp.IaNHCH '
2020-01-12 16:45:16 successfully saved docker image ' alpine:3.4 '
2020-01-12 16:45:16 starting to create clair layers
2020-01-12 16:45:16 creating clair layer ' 378cb6b4a17e08c366cebd813d218f60889848387fa61a56ac054ca027a4890d '
2020-01-12 16:45:16 successfully created clair layer ' 378cb6b4a17e08c366cebd813d218f60889848387fa61a56ac054ca027a4890d '
2020-01-12 16:45:16 done creating clair layers
2020-01-12 16:45:16 starting to get vulnerabilities for clair layers
2020-01-12 16:45:16 saving vulnerabilities to directory ' /tmp/tmp.MDncHN '
2020-01-12 16:45:16 getting vulnerabilities for layer ' 378cb6b4a17e08c366cebd813d218f60889848387fa61a56ac054ca027a4890d '
2020-01-12 16:45:16 successfully got vulnerabilities for layer ' 378cb6b4a17e08c366cebd813d218f60889848387fa61a56ac054ca027a4890d '
2020-01-12 16:45:16 done getting vulnerabilities for clair layers
2020-01-12 21:45:17 INFO io:89 Looking for vulnerabilities in directory ' /tmp/tmp.MDncHN '
2020-01-12 21:45:17 INFO io:95 Found 1 files with vulnerabilities in directory ' /tmp/tmp.MDncHN '
2020-01-12 21:45:17 INFO io:104 Looking for vulnerabilities in ' /tmp/tmp.MDncHN/378cb6b4a17e08c366cebd813d218f60889848387fa61a56ac054ca027a4890d.json '
2020-01-12 21:45:17 INFO io:122 Found 0 vulnerabilities in ' /tmp/tmp.MDncHN/378cb6b4a17e08c366cebd813d218f60889848387fa61a56ac054ca027a4890d.json '
2020-01-12 21:45:17 INFO io:133 Found 0 vulnerabilities in 1 files in directory ' /tmp/tmp.MDncHN '
2020-01-12 21:45:17 INFO assessor:19 Assessment starts
2020-01-12 21:45:17 INFO assessor:26 Assessment ends - pass
~ > echo $?
0
~ > 

Ajout d'une liste blanche de vulnérabilité

Dans les exemples ci-dessus, une liste blanche de vulnérabilité par défaut a été utilisée. Lorsqu'elle est spécifiée en tant que Doc JSON, cette liste blanche serait:

{
  "ignoreSevertiesAtOrBelow" : " medium "
}

Par défaut, Assess-Image-Risk.sh renvoie un statut de sortie non nul si des vulnérabilités sont identifiées dans l'image avec une gravité supérieure à un milieu. Le support est dérivé de la liste blanche de vulnérabilité par défaut.

L'exemple ci-dessous illustre comment spécifier une liste blanche de vulnérabilité et avec une gravité autre que le milieu. Remarquez l'utilisation du préfixe json:// pour indiquer qu'il s'agit d'une liste blanche en ligne.

 ~ > curl -s -L 
  https://raw.githubusercontent.com/simonsdave/clair-cicd/master/bin/assess-image-risk.sh | 
  bash -s -- -v --whitelist ' json://{"ignoreSevertiesAtOrBelow": "negligible"} ' ubuntu:18.04
2020-01-12 16:46:56 pulling clair database image ' simonsdave/clair-cicd-database:latest '
2020-01-12 16:46:58 successfully pulled clair database image
2020-01-12 16:46:58 starting clair database container ' clair-db-3b0811925f7e8bc2 '
2020-01-12 16:46:59 waiting for database server in container ' clair-db-3b0811925f7e8bc2 ' to start .............................
2020-01-12 16:47:32 successfully started clair database container
2020-01-12 16:47:32 clair configuration in ' /var/folders/7x/rr443kj575s8zz54jrbrp4jc0000gn/T/tmp.BXCs3Giy '
2020-01-12 16:47:34 pulling clair image ' simonsdave/clair-cicd-clair:latest '
2020-01-12 16:47:36 successfully pulled clair image ' simonsdave/clair-cicd-clair:latest '
2020-01-12 16:47:36 starting clair container ' clair-fc579c71e7daba57 '
2020-01-12 16:47:38 successfully started clair container ' clair-fc579c71e7daba57 '
2020-01-12 16:47:38 saving docker image ' ubuntu:18.04 ' to ' /tmp/tmp.lPDhNd '
2020-01-12 16:47:43 successfully saved docker image ' ubuntu:18.04 '
2020-01-12 16:47:43 starting to create clair layers
2020-01-12 16:47:43 creating clair layer ' cc59b0ca1cf21d77c81a98138703008daa167b1ab1a115849d498dba64e738dd '
2020-01-12 16:47:43 successfully created clair layer ' cc59b0ca1cf21d77c81a98138703008daa167b1ab1a115849d498dba64e738dd '
2020-01-12 16:47:43 creating clair layer ' 27a911bb510bf1e9458437f0f44216fd38fd08c462ed7aa026d91aab8c054e54 '
2020-01-12 16:47:44 successfully created clair layer ' 27a911bb510bf1e9458437f0f44216fd38fd08c462ed7aa026d91aab8c054e54 '
2020-01-12 16:47:44 creating clair layer ' d80735acaa72040a0a98ca3ae6891f9abb4e2f5d627b4099c4fefdc3ce1e696e '
2020-01-12 16:47:44 successfully created clair layer ' d80735acaa72040a0a98ca3ae6891f9abb4e2f5d627b4099c4fefdc3ce1e696e '
2020-01-12 16:47:44 creating clair layer ' 1ee34a985f7aef86436a5519f5ad83f866a74c7d9a0c22e47c4213ee9cb64e6d '
2020-01-12 16:47:44 successfully created clair layer ' 1ee34a985f7aef86436a5519f5ad83f866a74c7d9a0c22e47c4213ee9cb64e6d '
2020-01-12 16:47:44 done creating clair layers
2020-01-12 16:47:44 starting to get vulnerabilities for clair layers
2020-01-12 16:47:44 saving vulnerabilities to directory ' /tmp/tmp.dkfgmI '
2020-01-12 16:47:44 getting vulnerabilities for layer ' cc59b0ca1cf21d77c81a98138703008daa167b1ab1a115849d498dba64e738dd '
2020-01-12 16:47:44 successfully got vulnerabilities for layer ' cc59b0ca1cf21d77c81a98138703008daa167b1ab1a115849d498dba64e738dd '
2020-01-12 16:47:44 getting vulnerabilities for layer ' 27a911bb510bf1e9458437f0f44216fd38fd08c462ed7aa026d91aab8c054e54 '
2020-01-12 16:47:44 successfully got vulnerabilities for layer ' 27a911bb510bf1e9458437f0f44216fd38fd08c462ed7aa026d91aab8c054e54 '
2020-01-12 16:47:44 getting vulnerabilities for layer ' d80735acaa72040a0a98ca3ae6891f9abb4e2f5d627b4099c4fefdc3ce1e696e '
2020-01-12 16:47:44 successfully got vulnerabilities for layer ' d80735acaa72040a0a98ca3ae6891f9abb4e2f5d627b4099c4fefdc3ce1e696e '
2020-01-12 16:47:44 getting vulnerabilities for layer ' 1ee34a985f7aef86436a5519f5ad83f866a74c7d9a0c22e47c4213ee9cb64e6d '
2020-01-12 16:47:44 successfully got vulnerabilities for layer ' 1ee34a985f7aef86436a5519f5ad83f866a74c7d9a0c22e47c4213ee9cb64e6d '
2020-01-12 16:47:44 done getting vulnerabilities for clair layers
2020-01-12 21:47:45 INFO io:89 Looking for vulnerabilities in directory ' /tmp/tmp.dkfgmI '
2020-01-12 21:47:45 INFO io:95 Found 4 files with vulnerabilities in directory ' /tmp/tmp.dkfgmI '
2020-01-12 21:47:45 INFO io:104 Looking for vulnerabilities in ' /tmp/tmp.dkfgmI/27a911bb510bf1e9458437f0f44216fd38fd08c462ed7aa026d91aab8c054e54.json '
2020-01-12 21:47:45 INFO io:122 Found 33 vulnerabilities in ' /tmp/tmp.dkfgmI/27a911bb510bf1e9458437f0f44216fd38fd08c462ed7aa026d91aab8c054e54.json '
2020-01-12 21:47:45 INFO io:104 Looking for vulnerabilities in ' /tmp/tmp.dkfgmI/cc59b0ca1cf21d77c81a98138703008daa167b1ab1a115849d498dba64e738dd.json '
2020-01-12 21:47:45 INFO io:122 Found 33 vulnerabilities in ' /tmp/tmp.dkfgmI/cc59b0ca1cf21d77c81a98138703008daa167b1ab1a115849d498dba64e738dd.json '
2020-01-12 21:47:45 INFO io:104 Looking for vulnerabilities in ' /tmp/tmp.dkfgmI/1ee34a985f7aef86436a5519f5ad83f866a74c7d9a0c22e47c4213ee9cb64e6d.json '
2020-01-12 21:47:45 INFO io:122 Found 33 vulnerabilities in ' /tmp/tmp.dkfgmI/1ee34a985f7aef86436a5519f5ad83f866a74c7d9a0c22e47c4213ee9cb64e6d.json '
2020-01-12 21:47:45 INFO io:104 Looking for vulnerabilities in ' /tmp/tmp.dkfgmI/d80735acaa72040a0a98ca3ae6891f9abb4e2f5d627b4099c4fefdc3ce1e696e.json '
2020-01-12 21:47:45 INFO io:122 Found 33 vulnerabilities in ' /tmp/tmp.dkfgmI/d80735acaa72040a0a98ca3ae6891f9abb4e2f5d627b4099c4fefdc3ce1e696e.json '
2020-01-12 21:47:45 INFO io:133 Found 33 vulnerabilities in 4 files in directory ' /tmp/tmp.dkfgmI '
2020-01-12 21:47:45 INFO assessor:19 Assessment starts
2020-01-12 21:47:45 INFO assessor:34 Assessing vulnerability CVE-2018-11236 - start
2020-01-12 21:47:45 INFO assessor:52 Vulnerability CVE-2018-11236 @ severity medium greater than whitelist severity @ negligible - fail
2020-01-12 21:47:45 INFO assessor:36 Assessing vulnerability CVE-2018-11236 - finish
2020-01-12 21:47:45 INFO assessor:23 Assessment ends - fail
~ > echo $?
1
~ >

Ce qui précède est un exemple de liste blanche en ligne. Il est également possible de spécifier une liste blanche dans un fichier. L'exemple ci-dessous illustre l'utilisation. Remarque Utilisation du file:// Préfixe pour indiquer que la liste blanche est contenue dans un fichier.

 ~ > cat whitelist.json
{
  " ignoreSevertiesAtOrBelow " : " medium "
}
~ > curl -s -L 
  https://raw.githubusercontent.com/simonsdave/clair-cicd/master/bin/assess-image-risk.sh | 
  bash -s -- -v --whitelist file://whitelist.json alpine:3.4
2020-01-12 16:48:41 pulling clair database image ' simonsdave/clair-cicd-database:latest '
2020-01-12 16:48:42 successfully pulled clair database image
2020-01-12 16:48:42 starting clair database container ' clair-db-191152e37b864e4b '
2020-01-12 16:48:43 waiting for database server in container ' clair-db-191152e37b864e4b ' to start .............................
2020-01-12 16:49:16 successfully started clair database container
2020-01-12 16:49:16 clair configuration in ' /var/folders/7x/rr443kj575s8zz54jrbrp4jc0000gn/T/tmp.GdlBNmiG '
2020-01-12 16:49:19 pulling clair image ' simonsdave/clair-cicd-clair:latest '
2020-01-12 16:49:20 successfully pulled clair image ' simonsdave/clair-cicd-clair:latest '
2020-01-12 16:49:20 starting clair container ' clair-747d1c50606fba7e '
2020-01-12 16:49:21 successfully started clair container ' clair-747d1c50606fba7e '
2020-01-12 16:49:22 saving docker image ' alpine:3.4 ' to ' /tmp/tmp.Eldkbe '
2020-01-12 16:49:23 successfully saved docker image ' alpine:3.4 '
2020-01-12 16:49:23 starting to create clair layers
2020-01-12 16:49:23 creating clair layer ' 378cb6b4a17e08c366cebd813d218f60889848387fa61a56ac054ca027a4890d '
2020-01-12 16:49:23 successfully created clair layer ' 378cb6b4a17e08c366cebd813d218f60889848387fa61a56ac054ca027a4890d '
2020-01-12 16:49:23 done creating clair layers
2020-01-12 16:49:23 starting to get vulnerabilities for clair layers
2020-01-12 16:49:23 saving vulnerabilities to directory ' /tmp/tmp.pCOhlL '
2020-01-12 16:49:23 getting vulnerabilities for layer ' 378cb6b4a17e08c366cebd813d218f60889848387fa61a56ac054ca027a4890d '
2020-01-12 16:49:23 successfully got vulnerabilities for layer ' 378cb6b4a17e08c366cebd813d218f60889848387fa61a56ac054ca027a4890d '
2020-01-12 16:49:23 done getting vulnerabilities for clair layers
2020-01-12 21:49:23 INFO io:89 Looking for vulnerabilities in directory ' /tmp/tmp.pCOhlL '
2020-01-12 21:49:23 INFO io:95 Found 1 files with vulnerabilities in directory ' /tmp/tmp.pCOhlL '
2020-01-12 21:49:23 INFO io:104 Looking for vulnerabilities in ' /tmp/tmp.pCOhlL/378cb6b4a17e08c366cebd813d218f60889848387fa61a56ac054ca027a4890d.json '
2020-01-12 21:49:23 INFO io:122 Found 0 vulnerabilities in ' /tmp/tmp.pCOhlL/378cb6b4a17e08c366cebd813d218f60889848387fa61a56ac054ca027a4890d.json '
2020-01-12 21:49:23 INFO io:133 Found 0 vulnerabilities in 1 files in directory ' /tmp/tmp.pCOhlL '
2020-01-12 21:49:23 INFO assessor:19 Assessment starts
2020-01-12 21:49:23 INFO assessor:26 Assessment ends - pass
~ > echo $?
0
~ >

Des vulnérabilités spécifiques peuvent également être listes blanches. L'exemple ci-dessous illustre cette capacité. Si vous ajoutez le drapeau -v (verbeux) pour assess-image-risk.sh Vous voyez exactement comment les vulnérabilités de liste blanche ont un impact sur l'évaluation des risques avec des déclarations comme Vulnerability CVE-2019-13627 in whitelist - pass

 ~ > curl -s -L 
  https://raw.githubusercontent.com/simonsdave/clair-cicd/master/bin/assess-image-risk.sh | 
  bash -s -- --whitelist ' json://{"ignoreSevertiesAtOrBelow":"low"} ' ubuntu:18.04
~ > echo $?
1
~ > cat whitelist.json
{
  " ignoreSevertiesAtOrBelow " : " low " ,
  " vulnerabilities " : [
    { " cveId " : " CVE-2018-20839 " , " rationale " : " reason #1 " },
    { " cveId " : " CVE-2019-5188 " , " rationale " : " reason #2 " },
    { " cveId " : " CVE-2018-11236 " , " rationale " : " reason #3 " },
    { " cveId " : " CVE-2019-13627 " , " rationale " : " reason #4 " },
    { " cveId " : " CVE-2019-13050 " , " rationale " : " reason #5 " },
    { " cveId " : " CVE-2018-11237 " , " rationale " : " reason #6 " },
    { " cveId " : " CVE-2018-19591 " , " rationale " : " reason #7 " }
  ]
}
~ > curl -s -L 
  https://raw.githubusercontent.com/simonsdave/clair-cicd/master/bin/assess-image-risk.sh | 
  bash -s -- --whitelist ' file://whitelist.json ' ubuntu:18.04
~ > echo $?
0
~ >

Ito Whitelists Il vaut la peine de voir le numéro 7 qui dit:

Lors de la spécification de la liste blanche pour assess-image-risk.sh avec l'argument de la ligne de commande --whitelist , devrait prendre en charge le schéma https:// en plus du schéma json:// , file:// . Pourquoi est-ce important? Idéalement, les listes blanches doivent être maintenues par un analyste de sécurité et non un ingénieur de service. Cela signifie que les listes blanches devraient être maintenues dans un autre dépôt avec un processus de gestion du changement approprié. Les schémas json:// et file:// sont très bien pour maintenir les listes blanches dans le même référentiel est le code de service. Cependant, il serait préférable de maintenir les listes blanches dans un dépôt qui est lue pour les ingénieurs de service et modifiable uniquement par les analystes de sécurité qui pourraient appliquer des processus de gestion des changements appropriés sont utilisés pour apporter des modifications (avis de code, branches de fonctionnalités, etc.).

Comment cela fonctionne + exigences / hypothèses

Il y a 3 pièces mobiles:

1. Assess-Image-Risk.sh est un script bash qui fait le travail lourd pour coordonner l'interaction des 2 autres pièces mobiles
2. La base de données de vulnérabilité de Clair qui est emballée à l'intérieur de l'image Docker Simonsdave / Clair-Database - Un travail Circleci Cron est utilisé pour reconstruire Simonsdave / Clair-Database 3 jours par semaine pour s'assurer que la base de données de vulnérabilité est en cours
3. Un ensemble de scripts d'évaluation des risques Python et bash emballés dans l'image Docker Simonsdave / Clair-Cicd-Clair qui est basée sur l'image Docker Quay.io/coreos/Clair qui emballe Clair

D'après les échantillons au début de ce doc, vous verrez l'approche de la dernière version de Assess-Image-Risk.sh en une coquille de bash de course locale. Assess-Image-Risk.sh tourne ensuite un conteneur à l'aide de la Database Simonsdave / Clair. Un autre conteneur est ensuite exécuté à l'aide de Simonsdave / Clair-CICD-Clair avec le conteneur Simonsdave / Clair-CICD-Clair pour parler avec le conteneur Simonsdave / Clair-Database. Une fois que le conteneur Simonsdave / Clair-Cicd-Clair est en cours d'exécution, Assess-Image-Risk.sh Docker Exec de Script qui fait l'évaluation réelle des risques.

Armé de la compréhension du fonctionnement de clair-cicd vous apprécierez que la capacité d'exécuter Assess-Image-Risk.sh est ce qui définit les exigences pour l'environnement d'exécution. Assess-Image-Risk.sh est un script bash utilisé pour lancer le processus d'évaluation des risques et en tant que tel, c'est ce script qui définit la majeure partie des hypothèses / exigences pour clair-cicd - le script utilise Docker, SED et OpenSSL, donc tout cela doit être disponible dans l'environnement exécutant clair-cicd

Références

• 12 mai '22 - Identifier les vulnérabilités connues dans l'image Docker à l'aide de Clair
• 1 nov '20 - Une introduction pratique à la sécurité des conteneurs
• 5 août '20 - Comment faire la gestion de la vulnérabilité avec Docker et CI / CD
• 20 mai '20 - scanners de sécurité pour Python et Docker: du code aux dépendances
• 29 janvier 20 - Qu'est-ce que DevSecops et en quoi est-il différent de DevOps?
• 26 décembre 19 - Coreos Clair - Partie 2: Installation et intégration
• 4 octobre 19 - Coreos Clair - Partie 1: Analyse d'image du conteneur
• 1 octobre 18 - Compliance de cuisson dans votre pipeline CI / CD
• 11 Sep '18 - Qu'est-ce que DevSecops?
• 20 juin '18 - Où dans le cycle DevOps faites-vous la sécurité?
• 8 mai '18 - DevSecops: 7 habitudes de fortes organisations de sécurité
• 18 avril '18 - Le Cloudcast # 343 - Analyse de vulnérabilité des conteneurs
• 21 février 18 - L'outil de test de conformité automatisé accélère DevSecops
• 20 février 18 - 6 Exigences pour atteindre les devsecops
• 22 janvier 18 - DevOps and Security: Comment surmonter les défis culturels et se transformer en vraie DevSecops
• 15 janvier 18 - Pourquoi DevseCops compte pour les dirigeants informatiques
• 27 nov '17 - Qu'est-ce que la gestion de la vulnérabilité? Processus et logiciels pour hiérarchiser les menaces
• 23 octobre 17 - Les dix commandements de cybersécurité
• 9 octobre 17 - 10 couches de sécurité des conteneurs Linux
• 5 octobre 17 - Comment maintenir la sécurité lors du déploiement de DevOps
• 26 janvier 17 - DevOps et séparation des tâches
• 26 juil '16 - injecter la sécurité dans la livraison continue
• 5 juin '16 - <- déplacer la sécurité vers la gauche
• Cinq secrets et deux «gotchas» communs de la numérisation de la vulnérabilité