teach/virli
1
0
Fork 0
Code Issues Pull requests Releases Activity

Fix orthograf and grammar thanks to grammalecte

Browse source
This commit is contained in:
nemunaire 2022-05-12 02:46:31 +02:00
parent 3d8dd24b78
commit aa925795d1
46 changed files with 121 additions and 121 deletions
Download patch file Download diff file Expand all files Collapse all files

6
tutorial/docker-internals/vulnerability-scan.md
View file

@ -12,7 +12,7 @@ l'effort de cloisonnement mis en place.
Mais doit-on pour autant s'arrêter là et considérer que nous avons réglé
l'ensemble des problématiques de sécurité liées aux conteneurs ?
Évidemment, non : une fois nos services lancés dans des conteneurs, il ne sont
Évidemment, non : une fois nos services lancés dans des conteneurs, ils ne sont
pas moins exposés aux bugs et autres failles applicatives ; qu'elles soient
dans notre code ou celui d'une bibliothèque, accessible par rebond, ...
@ -20,7 +20,7 @@ Il est donc primordial de ne pas laisser ses conteneurs à l'abandon une fois
leur image créée et envoyée en production. Nos conteneurs doivent être
regénérés sitôt que leur image de base est mise à jour (une mise à jour d'une
image telle que Debian, Ubuntu ou Redhat n'apparaît que pour cela) ou bien
lorsqu'un des programmes ou l'une des bibliothèques que l'on a installés
lorsqu'un des programmes ou l'une des bibliothèques que l'on a installées
ensuite est mise à jour.
Convaincu ? Cela sonne encore comme des bonnes pratiques difficiles à mettre en
@ -191,7 +191,7 @@ Total: 158 (UNKNOWN: 5, LOW: 19, MEDIUM: 64, HIGH: 61, CRITICAL: 9)
Les résultats sont un peu différents qu'avec `docker scan`, mais on constate
que l'image `mysql` contient vraiment de nombreuses vulnérabilités. Même si
elles ne sont heureusement pas forcément exploitable directement.
elles ne sont heureusement pas forcément exploitables directement.
Voyons maintenant s'il y a des différentes avec l'image `nemunaire/fic-admin` :