Focus sur une nouvelle fonctionnalité de la JFrog platform [French]

bonjour à tous déjà merci d’être là
juste après la pause repas
bienvenue à ce Lightning talk on va
parler sécurité et surtout sécurité
orienté container vu qu’on est au
burnettez CE community
donc l’idée ça va être se baser sur un
carré réel on va voir comment on peut
créer un flux d’evskops assez simple une
sécurité pour sécuriser un micro service
d’exemple cet exemple ça va être une API
graphql propulsé par un framework
Netflix et on va voir un petit peu ce
qui se passe dans toute la vie du projet
des premiers balbutiements du code et
des imports des dépendances jusqu’à la
création de l’image qu’on souhaite
déployer dans cluster cubernetes on va
voir aussi une des vulnérabilités
apportées par ce projet d’exemple en
fait exploiter pour voir pourquoi il
faut prendre un peu au sérieux la
sécurité
Ce code vous verrez le dernier slide en
fait est disponible sur sur GitHub c’est
une application d’exemple mais comme ça
l’idée c’est que vous puissiez aussi
scanner et puis jouer un petit peu avec
donc en images ça donne quoi en fait on
va prendre un flot assez classique ou le
développeur ou le Techlid bâtit un
nouveau socle pour son projet il va
choisir un framework une fois que son
pied aussi est il va faire la première
pour le request et l’ossature du projet
tout ça en fait ça va nous permettre de
construire notre première image docker
et c’est là qu’on va mettre en place la
sécurité gate OK et ce qui va nous
intéresser aujourd’hui c’est la petite
boucle de rétrolation analyse and fixe
ou à l’issue des résultats du scan on va
voir en fait comment on analyse les
remontées d’outils et comment on peut à
la fois sécuriser sans passer trop de
temps puisqu’à la fin faut quand même
délivrer des futurs métiers donc l’idée
c’est qu’on va voir un petit peu en
images pour que ça soit un petit peu
plus parlant ce que fait l’application
que vous allez retrouver donc c’est
c’est surtout le framework qui est
important le Framework est sur la droite
en tout cas sa documentation donc
pourquoi j’ai pris un framework Netflix
c’est pas pour faire du même droping en
fait c’est parce que c’est la
problématique en gros on veut trouver un
framework avec lequel on va être
productif et que ce framework elle est
insolite donc Netflix c’est un acteur
majeur du marché si on va sur le ripo
GitHub de ce projet on verra que c’est
pas un projet sur un point de table de
chez Netflix il en est assez version
majeure 6
et il a des commites quasiment
journaliers donc c’est un projet qui est
plutôt en bonne santé mais seulement
quand on l’importe si jamais on voulait
jeter un œil à l’import de dépendance
qu’on a vu là juste donc à l’intérieur
des dépendances Netflix et deux
dépendances du Spring Framework
sous-jacente ça amène déjà une trentaine
de vulnérabilités vous voyez que là ces
petits boucliers je les ai pas tous
dépliés il y en a des plus rouges que
d’autres on va s’intéresser à au rouge
foncé mais déjà de base un exemple aussi
simple que celui là où on va juste
requêter une base de données de série TV
fictive bah ça amène un joli sapin de
Noël mais comme on l’a vu on va comment
on va orienter la discussion container
on va considérer qu’on n’a pas fait
cette analyse ici même si là on aurait
pu choisir par exemple une autre version
du framework ou changer de techno pour
un autre écosystème si la sécurité était
au coeur du projet on va dire que
maintenant on va capsule dans l’image
docker et cette image docker je la scan
donc cette image docker quand je la
scanne c’est une image assez classique
c’est une image
mavone enfin où JDK hotspot 11 etc une
image j’ai des cas public je me retrouve
non plus avec 30 vulnérabilités mais
avec 127 ce qui est logique puisque on
va retrouver par exemple celle qui est
tout en haut qui vient du
frameworkspring donc je vais retrouver
toutes mes vulnérabilités qui viennent
du projet Java mais on voit que les
deuxièmes là les boucliers un petit peu
orange ça commence par Ubuntu quelque
chose celle là elles viennent du
conteneur docker ok donc le travail
après si je veux sécuriser tout ça
globalement c’est un travail de titan
parce que 127 vulnérabilité normalement
quand on clique dessus on a le détail
c’est assez pénible mais pas de chance
en fait dans ce tas de vulnérabilité il
y en a qui sont des faux positifs comme
on va le voir mais il y en a une assez
particulière qu’on appelle le
springshell et là vous voyez que ça
tourne en fait une fois qu’on a exploité
cette vulnérabilité on peut taper des
commandes shell dans l’URL une fois
qu’on a exploité ces deux commandes curl
et l’application répond toujours donc
c’est un hack un peu silencieux on a
vraiment envie de se prémunir de ce type
de hack d’accord et celui là il était
vraiment dans la liste et ça pour vous
donner une idée c’est du remod code
exécution c’est un des boucliers rouges
foncés donc comme on est là pour parler
en 10 minutes de comment en sécurise
déjà l’idée ça va être quand vous avez
une remontée d’outils c’est pas
atteignable de tout sécuriser mais de se
concentrer sur les plus préjudiciables
donc celle de niveau critique et sur les
127 vulnérabilités il y en a 15 16
d’accord de critiques maintenant nous
chez Jeffroy qu’on a aussi une autre
stats c’est que comme on se tient en
masse des containers
sur ces 127 vulnérabilités il y en a 80%
qui seront pas exploitables parce que le
conteneur il amène des vulnérabilités
mais quelque part il nous protège aussi
si j’ai un package couvre une socquette
sur un port que mon conteneur n’expose
pas de toute façon elle est pas
applicable si j’ai une faille qui
s’applique sur une version d’un JDK
données mais que mon image est le
propose une autre version la faille
n’est pas applicable et puis le
conteneur c’est le produit fini donc
dedans il y a tout on a des dépendances
qui vont peut-être sauter entre le
projet on va dire sur le poste du
développeur et le produit fini compilé
etc suivant les écosystèmes dans l’image
de coeur donc cette image elle va nous
permettre de faire le tri dans les
vulnérabilités et nous c’est ce qu’on
utilise et l’idée c’est que voilà sur
ces 15 16 vulnérabilités je peux avoir
un travail qui va être j’analyse chacune
d’elle et je vois si le code que je
produis que mes équipes produisent ou
que j’ai l’intention de produire parce
que ça c’est important aussi quand le
projet va grossir sera susceptible
d’ouvrir la porte pour réaliser un
exploit tel qu’on a vu
mais si on fait on combine ça avec une
analyse dans le produit brut dans
l’image du conteneur on va pouvoir
scanner le code first party pour dire
vulnérabilité par vulnérabilité de façon
automatique celle-là elle applicable et
là vous voyez que sur toutes ces
vulnérabilités en fait il y en avait
trois d’applicables donc une de
critiques donc c’est comme ça qu’on
réduit en fait une sorte d’entonnoir et
même si c’est la baisse practice de
fixer en fait à la fin de tous ces
boucliers rouges foncés parce que je
rappelle que les exploits ils sont à
date et que c’est pas parce qu’on n’est
pas applicable aujourd’hui que demain
avec du code produit ce serait pas
applicable ou qu’un autre exploit qui va
affecter d’autres portions du code pour
la même vulnérabilité ce sera pas trouvé
demain d’accord donc vaut mieux essayer
d’avoir le moins de critiques possible
mais déjà ça donne en fait un cadre et
une action directe celle-là celle qui
est tout en haut de la ligne on va la
fixer et ce que vous avez vu le webshell
comme ça on ferme la porte d’accord
donc ça c’est vraiment fondamental et
c’est c’est un outil qu’il faut avoir
donc là évidemment c’est la solution
gef-frog que je vous présente et vous
pourrez venir voir ça en détail sur le
sur le stand mais dans l’idée c’est
applicable à toute chaîne DevOps ok le
pattern reste le même il vous faut deux
types d’outils des outils qui scannent
en fait les vulnérabilités par les
dépendances et un outil plutôt d’analyse
de code qui va le croiser avec les
résultats et si possible dans le
conteneur parce que c’est le produit
brut d’accord en l’occurrence ensuite il
faut être capable de corriger donc faut
que le l’analyse vous dise pourquoi elle
a mis applicable et où est-ce qu’on a
trouvé la vulnérabilité c’est le cas là
c’est un peu ce qu’on a sous les yeux on
voit bien que la méthode en fait
vulnérable passe comme son nom l’indique
elle était vulnérable et ça c’est du
code qui arrive assez vite dès qu’on
veut faire un formulaire on peut avoir
un mapping des champs contenus dans le
requête HTTP vers un Java bean et là
voilà on se retrouve un peu
à détourner en fait le produit c’est à
dire que on veut juste maper des champs
mais avec une pelo de malicieuse Bou m
on va reconfigurer le tome 4 avec une
deuxième paie l’autre on va créer le
webshell que vous avez vu en action
voilà j’espère que ça vous a intéressé
et que ça vous a donné envie de voir un
peu plus les choses en détail vous
pouvez venir nous voir sur le stand de
jeffrog sachant que cette partie que je
vous ai présenté c’est la contexte à
l’analyse mais dans les conteneurs on
est capable de faire beaucoup plus de
choses comme par exemple détecter des
secrets aussi si vous avez été décrets
dans le sol la WS ou GPC des choses
qu’on peut
identifier ou si du code first party
publie des données en dehors de votre de
votre entreprise c’est aussi des choses
qu’on peut voir voilà il y a pas mal de
choses que je peux vous montrer merci
beaucoup
[Applaudissements]