Eyal Ben Moshe with DevOpsSpeakeasy at swampUP San Diego 2022

foreign

my very special friend one of the best

of Our Own

ayal

head of ecosystem Engineers engineering

and so you first of all you watched the

Keynotes and then you so Evgeni that was

right here all of them speaking about

how important the ecosystem engineering

is for Jeffrey and the men and the

ecosystem engineering is right here with

us and I would like to ask y’all about

a little bit more details about the

announcement that we heard in the

keynote today namely the frogbot and the

docker desktop extension yeah right so

we have been putting a lot of focus uh

recently and this something is gonna

effort that’s gonna continue around

shifting left providing tools for

developers to make sure their software

is secure because we think that you know

shifting left

um I mean I don’t need to talk about

shifting left and the importance of it

and but we also want to make this fun I

mean we we don’t want to provide tools

that will just be there we want to make

sure that developers are enjoying

to use these tools so frogbot for

example is a fun gitbot so you install

it on your git repository no matter all

of the major uh popular git vendors are

supported and once that is done every

pull request gets scanned and

starting from today

frogbot will also create pull requests

for you if you uh forgot to ask it to

scan or you didn’t trigger what does it

do what does it do let’s take a step

back okay so what what is the what is

the purpose what do you want to do so

you want to make sure that your code is

secured it doesn’t use vulnerable

dependencies that’s the code that’s the

the goal right so the idea is that once

you have dependencies and you declare

them in what in uh what are the

languages technologies that are

supported yeah so all all of the major

all the popular supported Maven Grillo

npm go

python uh what else nuget.net core

um

dependency managers package managers

whatever

I committed my code posted to GitHub and

then yeah so you created a pull request

right oh yeah yeah you created pull

request

um so that’s the way to push code and

then

um even before your pull request got

reviewed it is already scanned okay so

so so the idea is to alert the

maintainer or you about security

vulnerabilities before the code gets

into the repository right before the

pull request game merged exactly okay

got it now it works with jfog x-ray

behind the scenes and this is how it

gets kind of correct okay and I think

there are more of those like I think

Dependable there’s one name that is very

familiar in this space what are the

differences so

so frogpot does more than depend about

in the sense that you know depend about

practically is triggered after the pull

request is merged or after the damage is

done and and and and it’s okay it’s it’s

a good thing uh frogbot starting from

today does this also but

um what frogbo does is is is he’s trying

to alert you before before the merge

which is better once once the progress

is created before it’s reviewed or

emerged you can get this information

which is obviously very very important

yeah yeah and it’s also fun right it has

like gifts and emojis and then yeah this

kind of stuff so yeah yeah yeah yeah

yeah yeah and and you know even if

you’re if your request is clean and it’s

green it also you know adds a thumbs up

with a green Banner telling you all is

good and uh you can trigger it multiple

times so okay there are more commits

that are pushed then it will trigger it

and it will oh it it will only report

about new vulnerabilities added by this

four request so if there are things that

are already known there’s no need to

report them for a report request if I’m

already fixing stuff then no need to

report them so it really tries to be

like give you

the the right information what you need

and allow you to uh to fix it in time

that’s pretty awesome okay so that was

frogbot for you

as usual open doors fridge go ahead use

it yeah and be safer than before yes

yeah okay the other thing the docker

desktop essential I think we announced

it at the keynote at dockercon but uh

and uh we got a very

um it got a very nice place in the

dockercon lineup of Innovations but

obviously swamp up is another place to

talk about it because this is something

that your team did yeah so what what is

it why is there what was the story with

the desktop extension yeah so so think

about it like this you are a developer

you are creating Docker images it’s part

of your uh development uh this is what

you do and

now you have a tool that in a second

scans your your Docker image and tell

you whether it’s vulnerable or not and

you can do it yeah with inside Docker

desktop with an ice UI or if you’re just

a commandant guy just run the command

with jfox client we will scan it now the

it goes really deep it goes into the

image it analyzes everything and it can

find

I don’t know a specific Debian file

which is buried deep inside your Docker

image and let you and let you know about

it and allow you to take action

um you know and this is something that

we always been very proud that x-rayed

the server side does all this recursive

scanning but now you can actually take

it to the client and that’s the ultimate

you’ve left that you mentioned right so

you do it be before you even commit

anything upgradable request even

sooner than the Frog bug kicks in you

can have it and you you know that yeah I

probably shouldn’t use this image and

find another one instead yeah yeah

definitely I mean

um yeah we want to empower developers we

want to make them as independent as

possible we don’t want them to know

about issues when you know uh the the

code is already merged and committed and

the CI is running you know they can take

action immediately and you know the the

the faster the sooner you find issues

the the less expensive the fixes so

what’s

I mean I I I’m I would like to know that

the code that I’m creating is is is

secure I don’t want you know someone to

go back to me and tell hey now create a

fix and and you know I can tell you

we’re using it ever since uh we got this

released we’re using it every time and

uh and and it’s fun I mean no

security vulnerabilities from the CI and

you know RCI is also secured with x-ray

uh saves a lot of time and and also fun

I mean you know just

and and um

you know and so so basically you you can

choose you can do it from the comment

line from Docker desktop from your IDE

um whenever and you’re in control and

you know about the problem before

actually you know the security fox

jumping on you and making stuff yeah uh

yeah this is cool there is one more

project that I would like to mention

probably maybe as a teaser and that’s

you know where I’m going my favorite

it’s the one that is most important for

me forever from a lot of what Jeffrey is

doing and that’s obviously the building

for oh yeah yeah so build info we’ve

been talking about the importance of

metadata on artifacts for for years as

long as Jeff frog exists like for

starting 2018 yeah and that was always

the biggest differentiator of jeffro

from any other

um binary management tool right we spoke

about how more than it is we spoke about

how powerful it is because you can do so

many things without it but in the end of

the day the way of expressing this

metadata and the way of consuming this

metadata is broader than just a

dependency management right it starts

earlier in the process and it actually

goes all the way to run time after

distribution and what’s not and what I

mean by that let’s say we annotated our

artifacts with the best metadata out

there but if this metadata is not used

in runtime it actually loses some of the

of the of the value and we were looking

were

um some kind of a standard

to use in order to express all this

metadata but I guess we are we found

ourselves in a position that probably

maybe we should be those who actually

tell us the industry what they need and

then guide the industry towards a

standard in artifact metadata right and

uh it’s it’s not an easy thing to do

because it should be open it should be

extended extensible but also from the

other side it should be meaningful right

not just you know pair of key value that

everybody do whatever they like but

something more structural yeah so it’s a

very tough problem to solve and um I

wanted to ask you if you see somewhere

down the road maybe next Swamp up

um how jeffro can take the lead in

breaking the ground with this open

extensible but also comprehensive

standard for artifact metadata yeah

definitely so we we um we are starting

uh to take build info and and and

um you know make it more visible and uh

and more accessible and uh the the what

we started doing is and you know and

it’s just build info is something that

we have for for a long time and it’s

been

um like an integral part of artifactory

uh our jfro clients use it generated but

it’s it’s we wanted to take it out or or

to separate the code so that it’s more

accessible and this is something that we

started doing so if you go to uh

github.com jfrog we’ll find there a

project uh named build info go

now this building for go uh gradually uh

include we are moving all the logic of

build info into it and I can tell you

that right now 80 percent is there I

think that with the exception of nuget

and net core everything is there and

they’re gonna move there too so you can

actually take now this

um this uh this repository this this

Library

and you can there’s also an executable

that we are generating for it and you

can create build info for any project

and you don’t even need artifactory for

it so so with jfrog CLI which work with

artifactory and x-ray they will they

also use the same code to generate the

building for they are dependent or

built-in for go but now that we have it

separated now it’s more accessible

and now developers and others can start

using this one of the uh I think

important use cases is actually creating

a bill of materials for your releases so

you know now with

um

with you know the industry realizing

that the software supply chain is so

sensitive and so important it is

important I mean it is good that you

know every release includes the the this

bill of material and build info is a

very good format for it and then and you

can also sign it and then people can see

exactly what the build includes

um and and so so that’s one use case

um I can tell you that jfrog x-ray also

uses build info in order to scan because

if you want to tell x-rays can a build

then you can generate build info and

then x-ray textile build info it

realizes exactly what the builds

included because build info is is very

accurate

and it provides you feedback about about

um about the status of of your build so

many use cases for for build info and um

and um yeah I recommend everyone to go

check check out this project try running

it provide us feedback if you have any

ideas feel free it’s an open source

project everyone is welcome to

contribute and work with us I think we

have a naming problem both in the

building for partner and Go part it’s

not only building for it’s metadata

about the collection of artifacts that

is usually filled together and this

hence the name but the idea is that it’s

really an information about the

collection of artifacts then the

information is very

diverse and it can be anything uh you

know already a lot of stuff right the

the fingerprinting and the permissions

and how it was built by whom who

deployed it right all this all this

history and obviously the goal part is

just the language that the library is

built on which also not very relevant

right

and itself yeah and what we want to ask

you is that you really

mentioned now is a great time to get

your feedback to um to make sure that

when it’s released it actually does the

right thing for you

with that yeah thank you very much it’s

been a pleasure yeah thank you thank you