►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello,
everyone
welcome
to
cloud
native
live
where
we
dive
into
the
code
behind
cloud
native,
I'm
annie
talavastro
and
I'm
a
cncdf
ambassador
as
well
as
senior
product
marketing
manager
at
comunda,
and
I
will
be
your
host
tonight.
So
every
week
we
bring
a
new
set
of
presenters
to
showcase
how
to
work
with
cloud
native
technologies.
A
They
will
build
things,
they
will
break
things
and
they
will
answer
your
questions
so
join
us
every
wednesday
to
watch
live
this
week.
We
have
a
great
session
called
live
shifting
through
top
25
containers.
So
really
looking
forward
to
that-
and
another
exciting
thing
happening
this
week
is-
is
that
the
program
for
kubecon
europe
for
this
year
will
go
live,
so
I
highly
recommend
registering
and
getting
your
ticket
this
week
or
or
later
as
well.
A
Of
course,
we're
gonna
be
in
a
very
lovely
spain
this
time
around
and
as
always,
this
is
an
official
live
stream
of
the
cncf
and
and
as
such,
it
is
subject
to
the
cncf
code
of
conduct.
So
please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
that
code
of
conduct.
Basically,
please
be
respectful
of
all
of
your
fellow
participants
and
presenters.
A
B
Awesome,
thank
you
so
much
annie.
I
am
so
excited
to
be
here.
This
is
such
a
cool
topic,
so
I'm
going
to
start
it
by
showing
my
screen,
and
I
want
to
ask
the
audience
to
send
questions
like
the
whole
time.
This
is
meant
to
be
a
completely
interactive
session.
I
have
a
bunch
of
things
I
can
speak
on,
but
I
would
much
prefer
to
answer
your
questions
and
I'll
kind
of
start
with.
B
I'm
sure
many
of
you
have
heard
of
s-bombs
at
this
point.
It's
a
very
popular
topic
and
gripe
is
a
vulnerability
generator,
and
so
what
I
did
is
I
took
I
took
sift.
I
I
wrote
some
scripts
that
downloaded
155
containers
and
it
scanned
them
and
spit
out
s
bombs,
and
then
I
did
the
same
thing
with
gripe.
Where
I
scanned
the
containers
with
gripe-
and
I
put
it
on
elasticsearch-
I
used
to
work
at
elastic,
which
is
the
company
behind
elasticsearch
and
so
anytime.
I
see
data.
B
The
first
thing
I
think
of
is
what
can
I
do
with
this
data
inelastic
search-
and
this
was
an
amazing
opportunity
to
do
that,
and
so
we'll
kind
of
cover
a
couple
of
the
the
bits
of
data
here
we're
looking
at
so
155
containers
in
those
155
containers.
We
have
a
total
of
14
000
packages,
which
is
a
lot
of
packages,
and
this
is
part
of
the
fun
is
when
we
start
looking
at
this
data.
B
Just
in
aggregate
in
the
in
big
picture,
high
level
views,
we
can
start
asking
some
weird
questions:
10
types
of
packages,
there's
things
like
rpms,
devs,
apks,
node
packages,
all
that
kind
of
stuff
which
is
kind
of
a
small
number,
but
that's
okay,
that's
how
it
that's
just
how
it
works.
I
think
it
shows
that
an
enormous
number
of
these
container
images
use
very
similar
types
of
packages,
1.4
million
files,
which
I
love
it,
because
that
feels
like
a
huge
number
and
it
is.
B
But
when
you're
working
in
elasticsearch,
it's
super
small
like
to
give
you
an
idea.
This
is
all
running
in
my
basement
on
a
moderately
sized
computer
like
this.
Isn't
some
you
know
super
huge
cluster
or
something
like
that
which
makes
it
super
fun.
You
could
do
this
on
your
laptop,
which
is
which
is
amazing,
290
000,
unique
files.
So
what
what
one
of
the
things
I
did
is?
I
took
all
the
files
and
then
I
said
only
show
me
like
one
instance
of
each,
so
it's
only
290
000.
B
and
the
reason
we
go
from
1.4
million
to
290
000
is
a
lot
of
files,
have
the
same
name
like
etsy
password
right.
Almost
every
container
has
an
etsy
password
that
we
can
figure
out
how
many
of
them
do
in
a
little
bit.
If
we
want
and
then
the
bottom
line
is
we
hit
some
vulnerabilities
5934
vulnerabilities,
that's
a
lot
of
vulnerabilities,
that's
unique
vulnerabilities
again,
because
you
know
things,
containers
share
pieces
and,
and
so
there's
going
to
be
similar
packages.
B
All
over
and
aggregate
total
is
72
000
vulnerabilities,
which
sounds
like
a
lot
because
it
is,
and
then
the
other
thing
I
put
here
is:
let
me
hide
that
quick,
the
total
number
of
licenses
793
licenses
and,
of
course,
you're
going
to
say,
wait
a
minute.
There
is
not
793
types
of
licenses
and
you
are
correct.
B
There
are
not,
and
we
can
explain
why
that
is
in
a
little
bit:
okay,
okay,
so,
as
I
said
as
I
go
through
this
data
like
please
ask
questions
anything
that
pops
into
your
mind
like
write
it
in
the
chat
and
and
we'll
get
to
it,
because
this
is
this:
isn't
a
demo
in
the
regards
of
it's
very
canned.
This
is
data
and
we
can
do
anything
we
want
with
this
data,
which
is
what
makes
it
so
amazing
and
fun
all
right
all
right.
So,
let's
start!
B
Oh,
you
know
what
yeah
we'll
start
with
with
some
some
pictures
and
then
I'll
kind
of
talk
about
how
I
did
all
this
in
a
little
bit,
because
I
think
this
is
what
you're
here
for
right
is
the
eye
candy.
So
this
is
the
first
graph
I'd
like
to
show,
and
this
has
the
number
of
packages
in
a
container
and
this
this
is
not
a
mistake:
3
000
packages
in
a
container
called
rocket
chat.
We
have
silver
peas
and
we
can
expand
this
out.
A
A
First,
question
perfect,
and
oh
two
actually
already
so
mark
asks:
why
do
you
prefer
yield
key
over
prometheus
and
then
yeah?
Then
guess,
let's
get
to
the
next
question
after
you
answer
this
one?
Yes,.
B
Okay,
so
I
prefer
elk
because
I
worked
at
elastic,
so
I
know
it
really
really
well,
I
spent
four
years
and
change
at
elastic,
and
so
it's
just
because
I
know
I
know
the
tool
and
I
have
remarkably
little
startup
time.
There's
no
reason
you
couldn't
put
this
data
in
in
you
know
the
big
data
system
of
your
preference,
it's
just
this
is
what
I
know.
So
it's
what
I
use
and
the
second
question
is:
will
we
be
sharing
the
scripts?
B
Yes
absolutely
so
I
have
a
github
repo
here
and
this
this
link
will
be
pasted
somewhere,
I've
been
told
and
there
we
are
right
there.
This
is
all
public
everything
you're
looking
at
was
generated
out
of
this
repo.
These
scripts
are
hard
to
use.
So
if
you
want
to
do
this,
like
hit
me
up
on
twitter
or
something
I
can
help
you
out,
because
I
don't
expect
anyone
to
take
this
and
be
able
to
use
it
without
some
assistance,
this
is
we'll
say
heavily
geared
towards
me,
because
it
is
what
I
know
so
anyway.
B
Anyway,
let's
look
at
the
the
packages
right,
so
this
is
just
the
top
10
or
top
five,
and
let's
like
let's,
let's
make
this
big.
Let's
look
at
what
what
the
distribution
of
packages
in
containers
looks
like
if
we
make
it
absolutely
enormous
right,
and
so
here's,
where
we
end
up
with
our
great
big
ones-
and
you
can
see
it's
a
pretty
typical,
just
kind
of
distribution
that
you
see
anytime
you're,
dealing.
A
B
I
mean
elk,
obviously
it's
again
it's
what
I
know
and
honestly,
if
someone
else
wants
to
take
this
data
and
do
something
with
it
and
put
it
in
another
system
and
and
discover
new
things
like.
Let
me
know
I'm
I'm
all,
for
you
know
adding
scripts
and
and
expanding
this
as
much
as
we
can.
I
found
the
data
fascinating
when
I
started
doing
this.
B
It's
it's
one
of
those
projects
where,
when
you
take
a
bunch
of
data-
and
you
put
it
into
a
system,
you
don't
always
know
what
you're
going
to
find,
and
so
it's
kind
of
like
an
adventure
of.
Is
it
going
to
be
interesting?
Is
it
going
to
be
boring,
and
so
I
spent
probably
a
month
or
so
like
just
investigating
this
before
I
said
yes,
this
is
interesting.
B
This
is
definitely
worth
talking
about
so
okay,
so
these
are
just
the
number
of
packages
in
containers
right
that
by
itself
I
don't
think
is
particularly
interesting
other
than
knowing
there
are
some
containers
that
are
huge.
There
are
some
containers
that
are
small.
This
should
surprise
nobody
right.
So
I
I
have
some
slightly
more
interesting.
B
I
have.
I
really
like
this
one.
This
is
where
we
look
at
the
the
package
types
in
each
container
so
like
we
have
our
rocket
chat
right,
which
had
3000
in
some
odd
packages
in
it.
But
now
we
can
look
at
like
what
what
are
the
packages?
What
is
the
data
in
this,
and
we
can
see
like
npm-
is
almost
all
of
the
content
we're
seeing
in
that
that
container
image,
which
again
anyone
who's
done
a
lot
of
npm
development.
B
This
is
not
a
surprise
in
any
way,
just
because
the
when
you
do
an
npm
install,
you
know
there
are
dependencies
of
dependencies
of
dependencies
that
that
do
this,
and
so
you
know
we
can
look
at
that.
We
can
look.
We've
got
what
is
the
next
one?
Silver
peas,
a
lot
of
java
and
we've
got
our
colors
over
here
we
can.
We
can
kind
of
pick
out
what
they
are,
but
you
can
see
like,
obviously
in
the
top
containers,
they
appear
to
be
debian
containers
a
lot
of
debian
packages.
B
You
know
no
shocking
chalker
there
npm
the
things
that
use
npm
use
a
lot
of
npm
and
again
I
mean
that
doesn't
surprise
anyone.
I
think,
but
it's
interesting
to
look
at
this,
and
so
again
this
is
where
we
can
take
and
we
can
expand
this
out
and
look
at
all
the
containers
right
now
now
I
also
I
wanna,
I
wanna
stress
when
you
see
me
change
numbers
and
the
data
appears.
This
isn't
contrived
data.
I've
pre-populated
like
this
is
actually
happening
as
I'm
typing
it,
which
is
why
it's
so
much
fun
to
do
this.
B
When
you
can
get
instantaneous
answers
to
your
questions,
data
is
fun
to
explore
when
you
have
to
ask
a
question
and
wait
five
minutes,
the
data
is
not
fun
to
explore
and
I've
I've
been
in
many
of
these
situations
before
so
anyway.
Now
we
can
kind
of
get
a
look
where
we
see
you
know
there's
some
rpm
in
here.
You
know
not
a
huge
surprise.
We
got
php
which
holy
cow
php.
B
What
we
jenkins
go
modules,
gems,
apks,
python
and
again
we
can
see
like
java-
makes
up
an
enormous
amount
of
these
container
images.
Debian,
like
a
lot
of
these,
are
deviant
and
I
suspect,
that's
because
you've
got
debbie
in
containers.
You've
got
ubuntu
containers
and
they
make
up
the
base
image
of
an
enormous
amount
of
these
container
images,
but
I
think
there's
also
kind
of
a
piece
to
this.
To
think
about
is
when
you're,
using
something
like
alpine
to
build
your
containers.
B
Alpine
images
are
generally
small.
So
obviously
it's
not
going
to
look
as
impressive
on
a
graph,
whereas
some
of
these
other
base
images
are
a
little
bigger
things
like
you
know:
debian
ubuntu,
red
hat
fedora,
those
are
considerably
larger
container
images
which,
which
is
fine.
I'm
not
saying
there's
anything
wrong
with
that.
I
I'm
a
firm
believer
in
like
do
what
works.
I
don't
like
to
claim.
One
thing
is
better
than
the
other
necessarily
and
then
of
course,
npm
and
again
we
see
you
know.
B
The
top
containers
have
a
lot
of
node
modules,
no
big,
surprise
there,
all
right.
So
what
are
the
most
popular
packages
we
see
in
the
containers?
That's
kind
of
the
next
one.
I
think.
If
we
look
at
this
list,
it
should
shock
nobody.
A
tool
like
tar,
lots
of
people
use.
Tar
bash
is
a
shell.
Grep
said
gzip,
you
know
these
are
all
pretty
normal
packages.
You're
gonna,
see
and
again
we
can
kind
of
expand.
B
This
out,
I
forgot
to
close
signal:
let's
make
it
a
thousand
and
then
we'll
update
this,
and
we
can
see
again
we
have
a
similar
distribution.
We
can't
read
anything,
of
course,
which
is
part
of
the
fun,
but
we
can
kind
of
take
a
peek
at
what
some
of
these
are
right.
We've
got
up
here,
we're
in
the
thousands
and
we
drop
down
into
the
hundreds
pretty
quickly
and
right,
and
then
every
container
kind
of
does
its
own
thing.
I
don't
this
one
isn't,
I
think,
particularly
interesting
by
itself.
It's
just.
B
Now
we
did
just
overall
package
types-
I
I
like
this
graph
too,
because
instead
of
breaking
the
packages
apart
into
each
container,
we
just
look
at
the
raw
numbers
like
what
are
what
are
we
seeing
here,
and
I
believe
this
is
yeah.
This
is
all
of
them.
This
is
all
of
the
packages
we
see
now
it's
eat.
B
You
know
if
there's
something
it
doesn't
support
by
all
means,
get
involved
patches
submit
bugs
all
that
sort
of
thing,
because
obviously
the
the
most
popular
ones
are
the
ones
that
get
the
attention
here,
but
we
can
see
obviously
debian
packages
make
up
an
enormous
amount
of
what
we
see
and
again
just
because
the
base
images
are
a
lot
of
debian.
This
is
a
surprise
to
nobody
java.
You
know
we
saw
the
java
archives
again,
not
a
big
surprise,
known
modules
rpm.
B
I
guess
dependency
heavy
compared
to
some
of
the
other
languages,
like
obviously
node
is
very
unixy
like
that
of
various
lots
of
very
small
modules,
whereas
things
like
you
know,
python
is
more
about
kind
of
your
more
feature-rich
modules,
so
you'll
just
naturally
have
have
less
of
them.
I
think
is
the
way
to
look
at
that
all
right
license
types.
A
B
I
I
need
an
expansion
of
that.
So
actually
I
know
kurt.
I
do
a
podcast
together,
so
he's
probably
here
to
harass
me,
but
that's
fine.
I
mean,
of
course,
there's
differences.
I
I
guess
what
what
does
that
mean?
What
are
you
looking
for
for
the
differences
I
mean
like
the
sheer
numbers,
I
guess
we
can
just
explore
and
kirk
and
type
in
questions
like
here.
I
can
if
we
take
package
names
and
now
we
can
do
things
like
do.
I
have
base
image.
You
know
I
don't
know.
B
Let's
just
pick
on
container
name
is
debian.
Let's
just
pick
on
the
debian
containers,
I
don't.
Why
am
I
getting
nothing?
B
Oh
because
it's
debian
latest
isn't
it,
and
this
is
part
of
the
fun
too,
is
remembering
what
you
did
so
you
can
so
here.
If
we
look
at.
A
Yeah
we
have
a
clarification
from
kurt
like
are
they
on
par,
for
example,
with
base
images
or
is
one
significantly
better?
Yeah.
B
You
go
they're
literally
the
same
thing
I
mean
I'm,
not
I'm
not
that
surprised,
no
they're
about
the
same
size,
curt
I
mean,
as
we
can
see
it.
It's
functionally
the
same
thing,
no
surprise
there.
I
I
I
know
there
is
a
way
to
tell
which
base
image
something
uses
which
I
haven't
done.
We
can
try
to
do
that
later,
but
I
don't
want
to
go
down
this
rat
hole
yet
because
it's
going
to
take
me
a
few
minutes
to
figure
out
how
to
find
that
data.
B
So
I'm
not
going
to
do
that
at
the
moment.
That
funny
enough
seems
obvious
in
hindsight
that
I
should
have
done
this,
but
I
didn't,
but
it's
all
part
of
the
fun
all
right.
So
I
want
to
go
back
to
license
types,
and
I
want
to
show
something
off.
That's
really
weird
here.
So
these
are
the
top
10
licenses.
B
If
I
show
all
of
the
licenses
right
because
there's
like
700
and
change,
it's
kind
of
a
mess,
but
you
see
down
here
like
there's
a
lot
of
licenses
that
are
barely
used
right,
like
we
get
into
the
single
digit
territory
and
so
an
easier
way
to
do
this.
Is
we
take
that
we
just
reverse
it
right,
instead
of
showing
the
most
used,
we'll
show
the
least
used
licenses?
B
People
have
put
into
the
containers
in
this
case
I'm
logging,
whatever
the
package
says
its
license,
is
we're
not
doing
any
sort
of
normalization
on
this
data,
because
I
find
it
a
very
interesting
data
point
in
favor
of
normalizing
the
data.
If
you
look
at
like
the
spdx
sbom
format,
they
have
a
confined
list
of
licenses.
You're
allowed
to
use
it's
not
like
an
open
field.
You
have
to
pick
one
out
of
their
list,
and
this
is
why?
B
Because
if
we
look
at
this,
you
can
see
like
people
put
in
all
kinds
of
wild
stuff
in
these
licenses,
just
because
it's
what
people
do
right,
like
obviously
in
some
of
these,
you
can
pick
one
license
or
another
license
or
I
don't.
I
have
no
idea
what
unlimited
means
who
knows
right
so
this
is.
This
is
just
what
happens
with
with
licenses
right
is.
Is
there
are
many
many
open
source
licenses
and
it's
not
always
simple
to
pick
one.
B
I
think
we're
doing
a
slightly
better
job
in
many
instances
today
versus
maybe
what
we
did
in
the
past,
but
it
still
happens
right,
and
so
this
is
actually
something
the
open
source
community
probably
needs
to
address
at
some
point
it's
just
this.
I
don't
call
it
light.
It's
not
licensed
sprawl,
it's
just
license
correctness,
all
right
all
right.
So
let's
keep
going
here's
another
graph.
I
like
I
took
all
of
the
file
sizes
that
the
the
s-bomb
reported
and
we
can
look
at
this
and
say
this
is
a
ridiculous
graph
and
it
absolutely
is.
B
I
love
that
there's
one
pack,
one
file
or
six
files
that
are
a
hundred
and
six
megabytes
in
size
which
is
strange,
but
whatever
it
is,
what
it
is,
but
here's
where
we
can
actually
do
some
magic
with
elasticsearch
and
we
can
kind
of
start
looking
back
at
these
smaller
the
smaller
bits
of
data,
and
so
here's
where
we
start
getting.
We
can
see
like
right
now
we're
into
the
various
k,
and
we
can
see
here
there
are
50
000
files
that
are
zero
bytes
in
these
containers.
B
50
000
is
a
lot
of
files,
but
what
we
can
do
now
is.
We
can
obviously
pull
that
out.
So
we
can
say
we're
gonna,
say
size
is
not
zero
and
that'll
get
rid
of
our
zero.
So
now
we
can
look
and
it's
still
there.
Why
did
it?
Oh,
it's
a
long
story.
Why
it's
still
there,
but
well,
I'm
not
gonna
obsess
over
right.
Now
I
have
to
get
rid
of
all
this
other
stuff.
Yeah.
A
There's
another
the
audience
as
well,
so
there's
gilbert
asking:
did
you
search
for
a
specific
file
name
to
determine
the
license
type.
B
The
the
license
type
is
provided
by
the
package
managers.
The
way
sift
works
is
it
will
look
at
like,
for
example,
if
you
use
npm,
it
looks
at
your
packagelock.json
and
then
it
will
determine
the
license
type
from
the
installed
packages,
same
thing
from
like
the
rpm
database
and
all
of
that.
So
if
you
have
a
file
on
disk,
not
part
of
the
package
management
system
today,
that
is
not
reported
as
part
of
these
results.
A
Then
there
was
another
question
from
chris.
Actually
so
is
it
picking
up
some
links
as
zero.
B
Yeah
yeah,
it
is,
and
there's
just
a
lot
of
zero
byte
files.
It's
it's
shocking.
How
strange
some
of
this
data
can
be
and
okay,
I
need
hold
on.
Let's,
let's
fix
this:
let's
look
at
our
filter.
Let's
say
get
rid
of
this,
and
this
is
of
course
part
of
the
fun
of
giving
live
demos,
because
this
worked
correctly
when
I
did
it
the
other
day
and
now,
okay,
we
look
at
one
two,
let's
say
a
megabyte.
B
B
It's
because
I
remember
now
it's
because
of
the
way
the
histogram
is
being
reported
by
elasticsearch,
but
you
can
see
it's
mostly
small
files,
that's
just
kind
of
the
point
of
this
graph.
I
don't
want
to
obsess
over
it
because
it's
not
super
interesting,
but
it
amused
me
to
look
at
okay,
okay,
so
that
is
kind
of
what
I
put
together
around
the
packages
and
what
we
can
find
and
we
can
dig
into
some
more
stuff
in
a
little
bit
and
I
think
there's
before
we
move
on
to
the
vulnerabilities.
B
I
want
to
kind
of
explain
what
I've
done
here
and
how
this
all
works.
So
I've
got
a
terminal.
I
usually
don't
like
terminals,
but
this
is
the
project.
These
are
the
scripts
that
were
used
and
in
this
top
containers
json.
These
are
all
the
containers
that
are
included
in
this
data
set
right
and
then
we
query
docker
hub.
We
pull
them
down
and
then
we
do
our
business
and
what
happens
is
we?
B
We
have
to
run
this
thing
called
build
s-bomb,
which
just
runs
sift
over
the
containers
and
I'll
kind
of
give
you
an
example.
I've
got
a
little
little
demo
I
can
give
here
of
sift.
I
run
it
out
of
the
container
just
so
it's
easier
to
pick
up
the
the
latest
version.
You
know
versus
running
a
the
binary
on
my
system.
I,
like
I
like
containers
for
this,
but
if
we
just
run
it
you're
gonna
see
it
basically
will
take
a
container.
In
this
case.
B
I
pick
alpine
because
alpine's
really
small
and
then
it
just
spits
out
like
this
is
the
stuff
it
found
in
the
alpine
container
and
if
we
pick
a
big
container.
Obviously
the
list
is
enormous
and
there's
just
various
ways
to
kind
of
slice
and
dice.
This
there's
a
nice
output
format
sift.
Has
we
if
we
give
it
like
dash
o
json,
it
spits
out
a
bunch
of
json
data
in
its
own
format.
That's
called
sif
native,
and
then
this
is
what
I
took.
B
I
took
this
json
and
I
literally
put
that
into
elasticsearch
and
that's
where
all
of
that
package
information
came
from
and
then
likewise
there's
the
other
tool
gripe,
which
alpine
is
boring,
because
actually
here
I'll
just
run
it.
If
we
run
gripe
over
alpine,
the
alpine
data
is
boring
because
there's
no
vulnerabilities
right
now
in
the
alpine
base
image,
which
is
cool
but
not
exciting,
for
this
demo.
So
if
we
pick
on
something
like
debian
latest.
A
Perfect
and
then
there's
a
question
again,
which
is
by
the
way
amazing.
Thank
you
so
much
everyone
for
asking
somebody.
B
B
Okay,
so
this
isn't,
I
I
for
anyone
who
joined
kind
of
late
I'll,
explain
again
a
little
bit.
So
this
isn't
the
top
25
containers
I'll
pull
up.
My
dashboard,
where
we
show
my
data,
has
155
containers
in
it.
So
when
I
first
did
this,
what
I
did
was,
I
just
went
to
docker
hub
like,
and
I
took
oh
crap.
This
would
make
me
log
in
so
when
you
go
to
docker
hub
and
you
log
in
it
shows
you
the
container
images
in
a
list,
and
I
just
literally
went
down
the
list.
B
B
I
figured
out
the
api
call
to
ask
docker
hub
for
all
of
the
official
images,
so
this
creates
a
list
of
all
of
the
official
docker
images,
which
is
actually
it's
in
this
top
container.
It's
like
170
some,
but
some
of
the
container
like
a
scratch
container
is
empty.
You
can't
scan
that
there
are
a
couple
containers
that
were
s390
images
that
sif
didn't
like
and
rather
than
deal
with
it.
B
I
just
commented
it
out,
and
so
we
end
up
with
155
when
it's
all
said
and
done
instead
of
170
some,
but
that
is
where
that
is
where
these
are
the
like.
The
like,
if
you
type
docker,
pull
like
debian
right.
Normally,
you
type
docker
poll
like
like
what
namespace
slash
container
name,
but
the
docker
official
images
you
don't
do
that
for
and
these
are
all
of
the
docker
official
images
which
I
found
to
be
vastly
more
interesting
than
just
25.
So
I'm
glad
I
did
figure
that
out.
A
I'm
asking
kind
of
a
question
kind
of
not,
but
I
guess
loving
all
the
interaction
from
kurt
so
because
I'm
curious
because
in
docker
hub
debian
was
updated
nine
days
ago
and
ubuntu
six
days
ago.
So
in
theory
it
shouldn't
be
that
bad.
B
Well,
so
it's
kind
of
not
so
here.
Let
me,
let
me
run
a
debian
I'll
run
a
dev.
I
don't
want
to
obsess
over
scan
results
right
now,
because
that's
kind
of
a
whole
another
topic
we
could
discuss
for
for
days
and
days
on
end.
But
what
happens
in
a
lot
of
this
is
a
lot
of
these.
Don't
necessarily
have
fixes
right.
You
see
fixed
in
this
data
is
coming
from
the
debian
security,
their
advisory
database.
I
forget
what
they
have
a
fancy
name
for
it.
B
I
don't
remember,
but
in
like
in
a
lot
of
these
cases,
they
won't
fix
things
which
we're
all
familiar
with.
Sometimes
there
aren't
fixes
for
a
variety
of
reasons,
yet
just
because
obviously
upgrading
some
of
this
and
what
you
end
up
with,
is
like
these
severity
ratings
come
from
nvd
the
national
vulnerability
database,
they're
they're
always
wrong,
and
so
basically,
if
you
look
at
this,
there
are
no
fixes
available
for
these
particular
ids
and
it
looks
worse
than
it
is,
but
the
vast
majority
of
them
like
see
this
negligible.
B
This
is
where
debian
basically
said,
like
whatever
it's
not
really
a
problem,
we'll
fix
it
someday,
and
actually
I
have
a
graph
that
shows
this
in
fact,
now
that
you
mention
it
so,
okay,
I
think
I
answered
all
the
questions,
but
keep
them
coming.
I'm
loving
this!
This
is
super
fun.
So
let
me
let
me
show
that
okay,
I've
got
let
me
open
my
visualize
library
again
and
I
actually
have
vulnerability
severities.
This
is
where
we
can
kind
of
pick
on
this
right.
B
B
I
don't
want
to
get
into
why
that
is
right
now,
but
I
think
this
is
a
pretty
reasonable
representation
of
what
we're
looking
at
right,
a
lot
of
mediums,
not
a
big
shocker
there,
because
any
of
us
who
deal
with
vulnerabilities
on
a
regular
basis
knows
that
when
you
have
like
low
and
medium
findings,
those
are
usually
we'll
get
to
it
right.
I'm
busy
putting
out
the
fire
over
here
right
now
and
then
obviously
negligible
is
a
rating
sift
willis
or
I'm
sorry.
B
It's
a
rating
gripe
will
assign
to
a
vulnerability
when
it
knows
that
the
like
debian,
for
example,
has
basically
said
this
is
not
a
big
deal
and
so
obviously
there's
a
lot
of
those,
and
these
numbers
are
obviously
gigantic.
You
know
23
000,
21
000,
a
lot
of
highs,
11
000,
that
there's
a
reason
for
that
I'll
explain
in
a
little
bit
and
then
obviously,
though,
and
it's
good
that
critical
is
so
small
because
we
don't
want
critical
being
a
huge
number
and
then
there's
a
handful
of
unknowns.
B
Well,
a
handful
two
thousand
is
more
than
a
handful,
but
I
I
again,
I
don't
think
this
graph
should
shock
anyone
in
terms
of
what
the
distribution
looks
like.
Obviously
we
would
love
to
see
zero
in
all
these
slots,
but
that's
just
not
a
realistic
expectation.
So
if
you
need
to
see
vulnerabilities,
you
don't
want
to
see
lots
of
criticals
and
highs
right.
You
want
to
see
the
low
things,
and
that
is
what
we
see
with
this
data.
So
now
why
are
some
of
these
so
big?
And
this
is
where
this
graph
is
horrifying
right?
B
The
rails
container
has
7
000
vulnerabilities
in
it.
When
I
saw
this
graph,
my
first
thought
was
well,
that's
not
right.
There
must
be
a
bug
in
something
and
it
turns
out.
It
actually
is
right,
and
I
can
show
you
why
that
is.
If
we
look
at
the
rails
official
image,
it's
deprecated,
they
say
use
ruby
instead
and
it
hasn't
been
updated
in
like
five
years.
B
I
think
we
can
see
that
in
the
tags
here,
yeah
latest
rails
five
years
ago,
and
so
that's
where
I
think
by
itself
it's
easy
to
pick
on.
You
know
the
rails,
people
or
docker
or
whoever,
like
it's
hard
to
deprecate
things.
If
they
would
turn
this
off,
they
probably
break
a
lot
of
infrastructure.
Hopefully
it
doesn't
get
a
lot
of
updates
or
downloads.
I
don't
know,
I
don't
know
where
that
came
from,
but
but
anyway
anyway.
B
The
point
is
the
value
in
this
data
is
being
able
to
get
this
like
holistic
view
of
your
container
images
and
what's
happening
inside
of
them,
and
then
you
can
make
some
decisions.
You
can
say
things
like.
Okay,
I'm
using
this
rails
container.
I
didn't
know
it's
end
of
life.
I
obviously
need
to
do
something
about
this,
whereas
without
any
ability
to
scan
or
gain
insight
into
what's
happening
in
your
infrastructure.
You
know
you
might
be
blind
in
this
way
and
you
could
think.
Oh
everything's
great,
you
know
I
run
I
run.
B
A
Yeah
another
question
once
again:
thank
you
so
much
for
susmita
for
asking,
so
they
say
I
find
that
few
high
severity
vulnerabilities
as
bone
fix,
who
says,
won't
fix
the
vendor.
Yes,.
B
The
vendor
it's
the
vendor,
so
in
that
case
it's
deviant
and
so
the
I'll
I'll
give
a
quick
little
recap
of
why
that
is
so.
There
is
here.
I
can
just
pull
it
up:
there's
nv.nbd.nist.gov
right
and
they've
got
vulnerabilities,
they
score
and
whatever
I'll,
just
I'll,
just
pick
on
one
right
here:
okay,
so
they
they
take
these
vulnerabilities
and
then
they
assign
a
severity
to
it.
And
this
is
where
it's
9.8
critical,
it's
a
cvss
score
and
when,
when
nist
does
this
work,
they
take
a
worst
case
view
of
the
vulnerability.
B
So,
for
example,
one
of
the
things
you'll
see
a
lot
is
in
a
lot
of
glib
c.
Like
do.
I
still
have
this
up.
I
do
so
like
there's
g
lipsy
right,
which
is
the
core
c
library
of
like
every
linux
distribution.
Every
one
of
these
has
a
lib
c.
Most
of
them
have
the
same.
One
you'll
see
there's
some
findings
here
that,
like
debian,
said,
won't
fix,
and
so
we
can
grab
this
cve
right
here.
B
Whereas
debian
knows
what
they're
doing
with
it.
So
debian
can
say
I'm
going
to
decide.
This
is
won't
fix
now.
That,
of
course
creates
some
contention,
because
I've
had
many
organizations,
that'll
say:
oh,
we
only
trust
nvd
and
then
it's
like
well
there's
nothing.
I
can
do
because
deviant
didn't
update
it
and
again.
I
think
this
is
one
of
those
places
that
this
is
a
very
immature
space
still,
and
we
have
a
lot
of
work
to
do
to
understand
kind
of
what
does
all
this
mean?
B
B
What
is
going
on
here
and-
and
I
I
think,
that's
the
value
of
it
right-
it's
easy
to
talk
about
data
when
you're
looking
at
it
it's
hard
to
talk
about
some
of
these
concepts
when
they're,
just
these
ephemeral
things
floating
around
and
we
don't
totally
understand
it.
So
all
right
that
was
that
was
a
lot
of
explaining
and
if
anyone
wants
to
discuss
vulnerabilities,
I
love
discussing
them,
but
I
don't
want
to
obsess
over
it
right
now.
B
So
like
come,
find
me
on
twitter
hit
me
up
somewhere
else,
I'm
even
happy
to
do
another
live
stream
just
about
vulnerabilities,
because
it
is
a
super
interesting
topic,
but,
okay,
okay,
so
right,
we've
got
all
these
vulnerabilities
now
vulnerabilities
per
container.
Let's
I'm
gonna,
I'm
gonna
explode
this
one
again,
we'll
look
at
what
it
looks
like
kind
of
as
a
whole.
B
This
one
takes
a
little
longer.
Oh,
it
failed
on
me,
that's
funny.
Let's
make
it
a
little
smaller.
Alright,
this
is
just
a
top
hundred.
If
I
go
all
the
way,
it
obviously
didn't
like
that,
but
you
can
see
it.
It's
a
pretty
reasonable
distribution,
but
we
still
have
a
lot
of
these
containers
have
a
lot
of
vulnerabilities
in
them
right.
It's
a
significant
number,
we're
talking
hundreds
for
the
most
part
and
why
that
is
is
partially
what
we
just
talked
about
around
you
know.
B
B
You
never
touch
it
again
and
now
you've
got
a
bunch
of
vulnerabilities,
and
so
this
is
one
of
those
instances
where
I
hesitate
from
telling
people
to
obsess
over
individual
vulnerabilities,
but
use
graphs
like
this
as
a
way
to
just
kind
of
gauge
how
things
are
going.
If
your
vulnerability
graph
is
constantly
going
up
and
to
the
right,
like
you
probably
need
to
take
some
actions,
because
at
least
you
want
it
flat.
Ideally
you
want
it
going
down
and
again.
This
is
where,
when
we
have
the
data,
we
can
start
asking
questions.
B
One
of
the
things
I
want
to
do
next
is:
these
are
just
the
latest
containers
in
most
instances.
I
also
want
to
pull
in
historical
containers,
and
then
we
can
do
things
like
say:
okay,
like
what
does
the
vulnerability
graph
look
like
for
this
container
over
the
last
two
years,
and
then
we
can
start,
you
know
seeing
is
it
going
up?
Is
it
going
down
what's
going
on,
and
this
is
an
instance
where,
if
you
have
a
container
image,
that's
on.
A
Yes,
I
think
it's
not
just
me
so
we
are.
We
lost
sound,
no
worries,
though
I
think
we're
gonna
get
it
back.
Hopefully
soon
there
usually
is
a
way
to
fix
these
things
quite
fast.
B
I
think
my
network
shut
off.
I
just
got
a
whole
bunch
of
messages
to
all
right,
all
right,
we're
all
good.
Now.
B
C
B
I'm
sorry
about
that
everybody
all
right
where
where
was
I
okay,
we
did
container
vulnerability.
Okay,
here's
one
that
I
like
this
is
where
we
can
break
apart
the
vulnerability
by
severity
right.
We
just
talked
about
all
of
this
severity
information
and
where
it
came
from
and
what's
going
on
and
now
again
we
can.
We
can
split
apart
our
graph,
so
I
guess
one
other
note
I'll
add
the.
I
prefer
the
horizontal
graphs
because
they're
easy
to
read
as
humans.
We
don't
have
to
turn
our
heads.
B
B
We
know
there's
not
a
lot
of
critical
vulnerabilities
and
when
we
look
at
this
graph,
we
see
that
yes,
there
aren't
that
many
in
fact,
even
the
rails
package
or
the
rails
container,
which
is
by
far
the
the
worst
one.
You
know
we're
talking
medium
negligible,
there's
a
lot
of
high,
but
you
know
what
I
mean:
it's
not.
B
B
B
B
So
this
one
I
really
like
this
is
where
we
look
at,
we
can
count
the
we
we
take
like
the
the
type
of
package
versus
the
number
of
vulnerabilities
each
package
has,
and
so
in
this
case
we
can
see
that,
like
debian
packages
account
for
the
vast
majority
of
the
vulnerabilities
we
see
and
part
of
that
is
because
like
when
we
you
know
when
we
scan
just
the
latest,
updated
debian
image.
We
get
a
bunch
of
stuff
in
it.
B
Obviously,
and
then
there's
also
those
older
images
like
with
rails
that
account
for
some
of
this
and
then
you
can
see
like
if
we
we
can
take
out
debian
packages.
For
example,
when
we
look
at
some
of
these
graphs
and
that'll
that'll
change,
what
it
looks
like
and
then
obviously
java
archive
rpm,
no
surprise
npm
is
a
lot
lower
than
I
expected.
B
Oh
not
package
name,
I
need
type
type,
is
not
deb
okay,
so
we
do
that
and
now
this
is
going
to
filter
all
the
debian
right.
Debian
disappears
from
the
graph.
We
know
that
as
now,
what's
cool
is
we
can
do
this
thing?
We
call
pinning
where
I
just
pin
this
filter
so
now
all
of
the
visualizations
we
look
at
take
out
debian
packages.
So
now,
let's
look
at
vulnerabilities
by
container
with
no
debians
holy
cow.
It
changes
a
lot.
Doesn't
it
like?
B
Don't
get
me
wrong,
like
1
400
vulnerabilities
and
one
thing
is
still
a
lot
but
like
the
the
ruby,
the
rails
container
disappeared
and
that's
because
the
vast
majority
of
the
findings
are
from
the
debian
packages
now
granted
that's
five
years
of
debian
security
updates,
which
is
an
enormous
amount
of
security
updates.
Obviously,
as
we
know,
but
this
is
kind
of
where
some
of
this
data
gets
more
fun.
So
let's
go
back
and
look
at
our
vulnerabilities
by
package
name.
So
what
happens
now?
B
Oh
jackson,
databyte.
Anyone
who
does
any
java
knows
jackson
datavide
well,
but
once
we
take
out
you
know
we
can.
We
can
disable
this,
you
know
temporarily,
disable
it
for
a
minute,
and
now
we
see
we
get
all
of
the.
I
guess
linux
packages
back,
because
we
know
they're
coming
from
debian
in
this
case.
Like
that's
interesting
to
me
now
now
I
want
to
specify
this
does
not
mean
don't
use
deviant
or
ubuntu
as
your
base
images.
This
simply
means
in
the
data
set
I
have.
B
This
is
the
results.
You
need
to
look
at
the
containers
you're
using
as
well
as
the
vulnerabilities
in
them
to
make
your
own
determinations.
One
of
the
dangers
of
data
is
drawing
incorrect
conclusions
from
it,
and
so
I
want
to
be
abundantly
clear
about
that.
I
am
in
no
way
disparaging
debian.
All
of
my
containers.
I
use
use
a
debian
base
image.
I
do
not
stop
doing
that,
even
though
I
know
that
they
might
have
slightly
more
vulnerabilities
than
say
alpine,
it's
just
I'm
comfortable
with
what
they
do.
B
Excuse
me!
So
here's
where
we
can
look
at
the
severities
right
we've
got
this.
We
see
medium
high
critical,
not
a
lot
of
lows
anymore,
which
doesn't
surprise
me.
I
think
a
lot
of
the
low
and
negligible
are
coming
from
the
distributions
and
there's
kind
of
two
reasons
for
that.
One
is
that
the
distributions
are
busy
and
there
are
more
security
vulnerabilities
than
they
can
fix,
given
just
the
available
time
right.
So
obviously,
things
that
are
low
and
medium
are
going
to
get
fixed
less
often
as
they
should.
B
I
don't
want
debbie
in
fixing
low
things
when
there's
a
bunch
of
critical
vulnerabilities,
but
then
that
negligible
kind
of
goes
away,
because
if
we
look
here,
there's
no
negligible
in
this
list
and
the
reason
for
that
is
the
negligible
data
is
coming
from
debian.
When
we
take
debian
out
now,
we
don't
have
negligible
data,
so
we
don't
have
a
way
to
report
on.
B
Like
we
don't
know
if
an
npm
package
is
negligible,
you
know
using
that
definition,
because
that
information
just
isn't
provided
and
in
the
case
of
gripe,
it
is
using
publicly
available
data
whenever
possible
to
to
figure
all
this
out
all
right.
B
Let's
see
what
else
do
we
have
again
container
vulnerability
by
package
type?
Wait,
this
isn't
right!
Oh
no!
It
is
so
right
when
we
did
this
graph.
I
don't
think
I've
shown
this
one.
Yet
it's
I
apologize
it's.
This
gets
so
exciting
and
I
forget
which
one
of
these
I've
shown,
because
I
keep
going
out
of
order.
I
I
had
a
nice
order
for
myself
all
right.
So,
let's,
let's
disable
our
filter
and
we
can
see
again.
B
Unsurprisingly,
we
have
debian
packages,
make
up
the
vast
majority
of
these
right,
like
rails,
7000
of
the
vulnerabilities
are
from
debian,
so
almost
all
of
them
right
and
again.
This
is
just
because
some
of
these
containers
are
using
debian
images
that
haven't
been
updated
in
a
long
time
and
that's
why
we're
seeing
this
excuse
me.
So
now
we
yank
out
our
debians
again
the
dev
packages,
and
now
we
can
look
at
like
where
are
these
coming
from,
and
so
let's
expand
out
our
from
five
to
let's
say:
let's
try
does
that
work.
B
It
does
work
great.
So
now
we
can
take
a
look
at.
Where
are
the
vulnerabilities
coming
from
once?
We
start
filtering
out.
Some
of
the
things
we
know
are
slightly
less
important
or
less
interesting
in
our
case,
so
we
can
see
what
is
the
green?
The
green
is
java
right.
So
that's
right
there
I
mean
I'm
not
surprised.
B
I
think
java
and-
and
I
guess
debian
for
that
matter-
kind
of
suffer
from
a
similar
problem
of
when
you've
been
a
language
for
a
really
long
time,
there's
a
lot
of
history
and
so
there's
a
non-trivial
number
of
projects
that
will
pull
extremely
old
versions
of
a
package
because
they
just
work
and
my
job
isn't
to
keep
it
updated.
My
job
is
to
make
it
work,
and
so
that's
just
one
of
the
things
we
see
happen
in
these
instances,
and
so
I
think
that's
not
a
surprise
to
anybody.
B
B
Actually,
I
can
filter
them
out,
rpm
and
apk
if
we
kind
of
yank
those
out,
because
those
are
again
linux
distributions.
So
again,
you
know
not
a
big
surprise.
I
think
a
lot
of
java
archives
npm.
What
else
is
in
here
jenkins?
I
don't
know
where
that
came
from
gem.
Ruby
is
a
similar
situation
where
there's
just
a
lot
of
ruby
stuff:
okay,
okay,
let
me
undo
those,
let's
disable,
that
for
a
minute
and
let's
see
what
some
of
my
other
okay,
we
did
that
one:
okay.
B
B
Is
it
all
debs?
I
don't
know,
let's,
let's
oh
wait.
If
we
enable
debian
packages
or
no
now,
we
I'm
sorry,
we
disabled
debbie,
if
we
disable
debian,
we
rails
isn't
even
on
here.
Let's
see
if
I
can
pull
rails
back
in
there's
rails.
A
So
you
do
that
there
was
a
question
to
cncf
in
the
chat
as
well.
Hacker
asks
about
how
to
get
to
this
program
as
well.
I
think
you
can
email,
for
example,
online
programs
at
cncf.io
to
to
get
started
with
discussion
there,
but
amazing
that
our
session
today
is
is
such
a
hit
that
everyone
wants
to
get
on
as
well.
B
Awesome
awesome
so:
okay,
okay,
so
here's
where
now
what
is
going
on
go
away
right,
we've
got
rails,
almost
many
of
them
disappear
right
once
we
take
out
debbie
and
we
search
for
rails
and
there's
it's
my
my
elastic
foo
is
weak,
so
that
should
have
looked
different
but
anyway,
anyway,
all
right.
Let's
disable
that
again
right
and
we
can
look
at
all
of
the
let's.
Let's
expand
this
out,
let's
do
500
again,
which
should
hit
them
all
and
we
can
see
like
okay,
so
there's
some
unknowns.
B
We
get
unknowns
when
gripe
just
doesn't
know
what
to
do
right
and
that
happens
sometimes,
where
we
don't
know.
If
there's
a
fix,
we
don't
know,
there's
not
a
fix.
It's
just.
It
happens
right,
there's
just
incomplete
data,
and
this
is
an
instance
where
some
people
might
be
like.
Oh,
I
know,
and
why
even
talk
about
that
it
is.
B
B
But
then
the
amount
of
fixed,
like
these
are
vulnerabilities
that
you
could
make
go
away
in
many
instances,
just
by
running
like
an
apt-get
update,
apt-get
upgrade,
you
know
in
these
container
images
and
so
like
this
is
another
good
reason
when
you're
creating
your
container
images
like
install
the
updates
during
during
creation,
because
maybe
the
base
image
doesn't
have
them,
maybe
you're
not
using
a
latest
tag
for
a
base
image.
You
know,
there's
there's
many
arguments
about
pinning
versus
not
pinning
and
all
this
stuff.
So
it's
just
something
to
keep
in
mind.
Right
is.
B
When
you
look
at
data
like
this,
you
can
see
the
effect
that
installing
updates
can
have
and
and
obviously
again
this
is
everyone
needs
to
do
their
own
thing.
Everyone
needs
to
do
their
own
research,
because
what
works
for
me
might
not
work
for
you
and
I'm
very
happy
to
admit
that
all
right,
okay
cool,
so
we
got
through
most
of
this
stuff.
I've
got
a
handful
of
other
fun
little,
I
guess
just
bits
of
data
I
included
down
in
the
bottom.
B
One
of
the
ones
I
like
is
the
cvss
score
distributions.
This
is
where
we
talked
about
these
nvd
vulnerabilities
here,
and
this
is
the
cvss
scores.
B
Cvss
scores
are
basically
0
to
10,
10
being
the
worst
zero
being
not
a
security
vulnerability,
and
we
have
access
to
all
the
data,
and
so
one
of
the
things
I
did
was,
I
decided
like
what
does
it
look
like
if
we
graph
it
and
it's
a
bell
curve?
Distribution
like
it's
boring
like
it
is
what
it
is,
but
now
we
can
maybe
what
if
we
take
out
our
debian
packages,
it
doesn't
really
change.
You
know,
no
one!
No
one
is
surprised
by
this.
B
B
I
have
the
hash
of
all
the
files
that
are
part
of
this
data,
and
so
I
thought
what
happens
if
I,
how
many
hashes
are
the
same
right
and
like
this
is
an
instance
where
remember
those
zero
byte
files.
We
talked
about
so
zero
byte
files
all
have
the
same
hash
right
unsurprisingly,
because
they
have
the
same
data
in
them,
and
so
these
are
a
bunch
of
zero
byte
files
that
are
causing
this
weird
hash.
B
But
then
there's
other
things
like
like
what
is
there's
a
file
that
700
of
them
are
the
same,
and
so
this
is
actually
where,
like
we
can
pin
this
again
and
let's
go
look
at
what
this
is,
and
so
there's
this
thing
called
discover
in
kibana,
I'm
in
the
wrong
index.
So
we
can
look
here
like
what
is
this.
It
looks
like
it's
man
pages
right,
we're
getting
we're
getting
this
package
from
a
bunch
of
man
pages
now.
Why
are
some
of
the
man
pages
the
same,
even
though
they
have
different
names?
B
I
have
no
idea.
I
didn't
look
that
closely
at
it,
but,
like
this
is
some
of
the
just
weird
data
you
can.
You
can
find
when
you
look
at
all
this
like.
Why
are
they
the
same?
I
don't
know
all
right.
Let's
get
rid
of
this
get
rid
of
this.
Oh
and
it
should
also
be
said.
This
is
yeah.
These
are
the
file
hashes.
I
I
filtered
out
empty
and
empty
means,
there's
just
no
file
hash.
B
This
is
because
sift
is
pulling
the
file
hash
out
of
the
packaging
system,
and
if
the
packaging
system
doesn't
tell
it
a
file
hash,
it
doesn't
currently
generate
it.
Thank
goodness
because
it
would
take
forever
to
generate
this.
I
mean,
I
guess,
kind
of
an
interesting
data
point
like
that.
B
So
I've
got
my
my
repo
here
right
where
I
I
generated
all
these
s
bombs,
and
these
are
the
s-bombs
from
from
sift
and
you
can
see
like
some
of
them
are
of
substantial
size
like
54
megabytes
things
like
that,
if
we
do
it's
1.8
gigabytes
of
spam
content,
like
that's
a
lot
of
freaking
s,
bomb
content,
I
mean,
and
that's
just
150,
some
container
images
you
can
imagine.
If
you're
in
an
environment
with
thousands
or
millions
of
containers,
this
can
become
a
substantial
number.
So
it's
it's
just
one
of
the
interesting
data
points.
B
I
guess
that
I
found
amusing
and
then,
let's
see
the
other
one
I
liked
was.
I
took
all
the
package
versions
and
I
looked
at
what
they
had
in
common
and
this
one
here
was
another
one
of
those
like
what
the
heck
is
this,
and
I
I
don't
remember
anymore,
because
I
haven't
looked
at
it
in
a
while.
So
let's
pin
it
it's
pinned,
we
can
go
over
here
into
discover
and
take
a
peek,
and
that's
because
it
is
in
sbum
and
it
is
something
called
open
liberty,
it's
a
bunch
of
java
stuff.
B
It
looks
like
which
suggests
to
me
that
there
must
be
what
is
the
java
archive
java
archive
package
name
it.
It's
probably
one
of
those
instances
where
you
have
a
one
kind
of
java
source
archive
ends
up
generating
a
huge
number
of
jars
on
the
other
end
and
they'll
all
have
the
same
version,
and
so
in
fact
we
can.
Probably
I
haven't
done
this,
so
this
might
not
work.
If
we
look
at
our
visualize
library-
and
we
say,
if
we
do
packages
in
container
yeah,
we
can
see
there's
two
there's
two
containers.
B
It
looks
like
they
picked
this
up,
it's
webb
sphere
and
open
liberty,
which
is,
if
you
add
those
two
numbers
up.
It
should
be
pretty
close
to
what
we
had
so
yeah
like
this
is
one
of
those
fun
times
where
we
can
just
look
at
some
strange
data
and
say
like
what's
going
on.
I
have
no
idea,
and
I
love
it.
That's
what
makes
this
so
much
fun,
sometimes
to
look
at.
C
Am
I
autographs,
I
think
I
might
be
out
of
graphs?
No,
I'm
not.
I
know
we
got
that.
We
got
that
okay.
B
A
Dig
into
something
else,
that's
a
good
time
to
yes,
hey,
essentially
kind
of
final
call,
as
you
mentioned,
we
have
time
for
a
few
questions
perfectly
so.
A
I
think
there
hasn't
been
a
question
in
a
while
I'm
saying
a
few
minutes,
but
there
was
a
comment
from
weston
saying:
I
think
it
will
currently
end
up
being
unknown.
Anytime
greg
pulls
down
the
nvd
for
a
match.
A
while
ago.
That
was
the
last
yeah.
B
B
No,
this
is
this
is
just
a
lot
of
fun.
Like
I
said,
I've
got.
I've
got
this
repo
here.
If
anyone
wants
to
give
it
a
go
by
all
means,
you
know
he
asked
me
questions
hit
me
up.
You
can
find
me
on
twitter.
I
don't
know
if
there's
any
contact
details
in
the
in
like
the
notes
for
this
and
if
there's
not
I'm
not
hard
to
find
but
yeah
I'm
happy
to
help
anyone
out
with
this
stuff.
I
think
it's
a
lot
of
fun.
I've
got
some
other
repos.
B
A
There's
a
few
questions
now
well,
there's
doc.
The
lord
saying,
angkor
ciela
is
also
one
of
the
products
from
anchor
and
it
helped
build
ci
cd,
build
and
yeah.
That's.
A
Then
kurt
asks
is
greg
publishing
this
the
data
on
these
containers
publicly,
so
people
don't
have
to
grind
through
them
all
and
then
never
mind
in
that
repo.
Well,.
B
Well,
that's
so
actually
did
I
check
them
in.
I
think
I
did
check
them
in
no,
I
did
not.
I
did
not
check
them
in
because
there
is
a
lot
of
data
and
github
doesn't
like
a
lot
of
data.
So
no
I
mean,
in
the
context
of
that
question
like
gripe,
is
just
a
tool
and
it's
up
to
you
to
run
gripe
and
then
decide
what
to
do
with
the
output
like
in
my
case,
I
put
it
in
elasticsearch.
B
B
It
was
maybe
friday,
I
think,
is
the
last
time
I
updated
it,
and
so,
if
I
run
it
today,
the
results
are
going
to
be
drastically
different
because
the
s-bomb
content
from
friday
to
now
changes
and
obviously
when
you
have
a
ton
of
of
s-bomb
content,
you
keep
checking
it
into
github
github
yells
at
you.
If
you
use
too
much
space,
so
I
don't
want
to
do
that.
A
B
I
don't
know
of
anything
at
the
moment
that
makes
that
easy
to
do
I
mean
that
that's
one
of
the
the
things
I
want
to
do
with
like
this
particular
project
is
being
able
to
put
in
point
in
time
s
bomb
content
and
then
also
being
able
to
like
ascertain
some
differences,
but
yeah
yeah.
It's
that
that's
that's
a
good
question
and-
and
I
don't
think,
there's
an
amazing
answer
to
that
today.
It's,
but
again
this
is
a
very
immature
industry.
B
I
mean
we
talk
about
some
of
the
difficulties
with
vulnerabilities
and,
like
we've,
been
doing
vulnerabilities
for
20
years
and
we're
still
really
bad
at
it,
whereas
like
s-bombs
s-bombs
are
what
a
couple
years
old.
At
this
point
I
mean,
I
would
say,
it's
been
probably
the
last
6-12
months
that
it's
been
getting
significant
attention,
so
I
think
we're
good.
Like
there's
a
lot
of
interesting
things
happening
in
this
space.
I
mean
it's.
One
of
the
reasons
I
was
attracted
to
this
particular
project
is
like
this
is
really
interesting
data.
B
A
Perfect,
I
think
that's
about
it
for
the
time
that
we
have
today,
we
can
have
a
like
a
30.
Second
final
words
from
you.
If
you
want
to
shout
out
anything
or
so.
B
I
mean,
I
think
the
biggest
shout
out
is
just
like
get
involved.
You
know,
like
sift
and
gripe
our
open
source.
You
know,
there's
this
little
project,
there's
tons
of
open
source
happening
around
s,
bombs
and
vulnerabilities
and
there's
there's
so
many
ways
to
get
plugged
in.
I
assume,
if
you're
watching
me
do
this.
B
You
have
some
interest
in
some
way
with
this
data
or
s-bombs
or
vulnerabilities
or
whatever,
and
it's
a
ton
of
fun
and
there's
there's
so
much
room
in
this
this
space,
it's
it
it's
so
new
and
it's
so
exciting
to
be
working
on
something
brand
new.
Like
this,
it's
absolutely
lovely-
and
I
guess
just
thank
you.
Everyone
for
coming.
This
was
so
much
fun
to
put
together.
B
A
Perfect,
it's
been
absolutely
lovely
to
have
you,
and
so
let's
wrap
it
up
for
today.
Thank
you,
everyone
for
joining
the
latest
cloud
native
live
as
always.
It
was
great
to
have
the
session
here
about
life,
sifting
through
top
25
or
even
actually
more
in
the
session.
A
Yes
containers,
so
we
really
also
love
the
audience
interaction
today.
Thank
you
so
much
for
all
of
the
amazing
questions
and
comments
and
even
could
be
some
more
clarification,
and
so
that
was
really
lovely
to
see.
So
we
bring
you
the
latest
of
cloud
native
code
every
wednesday,
so
next
week
we
will
have
a
session
on
optimizing
istio
with
etf.