►
From YouTube: Kubernetes SIG Security Tooling 20210817
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
B
Maybe
I
can
start
if
you
can
hear
me
yeah
yeah,
so
my
name
is:
I
go
team
in
particular,
I
work
at
deepgo,
which
starts
to
deliver
static
analysis
tools
for
to
go
and
I'll,
be
today
I'll,
be
presenting
the
work
on
goal,
vulnerability
scanning.
A
All
right
cool
welcome
here.
We
are
definitely
excited
to
learn
more
from
you
and
thank
you
very
nike
for
being
the
liaison
for
sec
security
and
bringing
him
here.
A
Welcome
ravinder,
so
just
quick
brief
idea,
I
would
say,
is
our
goal
here:
is
create
and
enhance
and
improve
any
tooling,
that's
related
to
kubernetes
security,
so
that
would
mean
some
stuff
that
we
drive
ourselves.
Some
things
that
other
sigs
are
doing
and
other
working
groups
are
doing.
We
will
help
them
improve
it,
we'll
help
them
move
it
faster,
we'll
help
review
it.
So
that's
that's
really
our
goal
and
no
project
or
suggestion
or
idea,
is
a
bad
idea.
So
if
you
have
any
ideas
and
want
to
propose
anything
in
future,
that's
always
welcome.
D
Hey,
I'm
navarro
I'm
journey
security
meeting
for
the
first
time,
but
in
the
community
for.
A
Well,
welcome
to
have
you
here
like
many
folks
from
sikh
release.
I'm
sure
know
you
and
other
sigs
as
well
great
to
have
you
here.
Give
us
feedback
also
how
we
are
running
the
meeting.
You
know,
because
I
know
you've
been
around
so
you've
seen
and
been
in
more
meetings
led
more
meetings
than
me
at
least
so
happy
to
hear
from
you
later
on
any
feedback.
You
have.
E
Hi
everyone-
this
is
pritish
samal
from
india,
I'm
pretty
new
to
the
communities
community
and
I've
joined
the
community
one
month
back
so
yeah,
I'm
exploring
all
the
subparts.
That's
there
in
the
community
happy
to
be
here.
A
F
What's
going
on,
I'm
tommy
I've
been
following
security
for
probably
around
six
months,
dropping
into
meetings
every
now,
and
then
this
is
the
first
one
and
sig
tooling,
but
excited
to
see
what's
going
on
here
and
meet
y'all.
A
A
A
A
So
we
have
been
meeting
once
a
month
since
I
believe
february,
and
what
I
realized
now
that
we
have
had
a
few
sessions
is.
There
is
a
lot
of
content
and
desire
from
the
community
to
share
demos
or
deep
dives
into
work
that
we
do
and
work
that
is
relevant
for
us.
A
So
one
of
the
suggestions
I
wanted
to
share
with
everyone
get
feedback
was
what,
if
we
created
two
different
types
of
meetings
that
happen
every
first
and
third
week
of
the
month,
so
the
first
week
of
the
month
meeting
would
be,
for
example,
a
working
session
where
we
make
decisions.
We
look
at
the
issues.
We
do
any
triage
of
the
issues
or
if
anyone
needs
help
in
nailing
down
the
specifics
of
pr
or
reviews.
A
We
work
on
those
and
come
out
with
next
steps
on
what
needs
to
be
done
so
that
the
progress
of
the
projects
that
already
are
going
on
will
continue
to
happen,
and
the
second
meeting
would
be
more
like
today's
meeting,
where
it's
a
demo
from
somebody
who
is
either
part
of
the
sick
or
somebody
who
is
a
guest
and
wants
to
share
something
that
might
be
relevant
to
kubernetes
security,
and
that
can
be
probably
more
beneficial
for
folks
who
may
not
have
time
or
desire
to
contribute
regularly
to
sick,
but
just
want
to
learn
and
our
new
contributors.
A
So
that
way
people
can
pick
and
choose
between
those
two
meetings.
If
you
want
to
join
both
always
welcome,
if
you
want
to
join
one
based
on
your
interest
and
your
desire
of
what
you
want
to
do
in
the
community,
you
can
pick
either
of
them
any
any
thoughts
on
that
bad
idea.
Good
idea,
suggestions
to
change,
I
think
it
sounds
like
a.
A
Okay,
I
see
a
thumbs
up
from
patrick
and
british
cool
or
enzavita.
Okay
great.
I
think
we
have
enough
consensus
from
using
lazy
consensus,
I
suppose-
and
so
we'll
go
with
that
I'll
share
with
a
tabby
about
this
discussion
and
what
we
decided
to
do.
A
A
So
any
of
you
who
have
ideas
we'll
find
some
place
to
start
creating
sort
of
a
list
of
talks
that
people
want
to
propose,
and
maybe
we
can
put
your
name
and
the
title
there
if
you
want
to
propose
anything
and
we'll
go
with
fifo
in
terms
of
who
gets
to
share
it
first
and
then,
after
that,
we'll
see
how
it
goes
for
a
couple
months
or
three
months
or
so,
and
based
on
that
we'll
do
some
quick
retrospective
in
one
of
the
meetings
see
if
we
want
to
modify
and
then
go
from
there
all
right.
A
So
with
that,
I
will
give
the
give
this
back
to
zonimer,
and
when
I
go
for
it,
I
would
only
suggest
is
considering.
There
are
some
new
contributors
also
today,
maybe
give
some
background
on
the
tool
and
the
intent
and
the
wise
watts
before
we
jump
into
the
house,
so
that
everyone
will
be
able
to
keep
up
with
this
content.
B
B
Okay,
let
me
just
go
to
the
very
beginning.
Okay
again,
my
name
is
vladimir.
I
work
at
google.
I
work
for
the
go
team.
In
particular,
I
work
for
the
deepgo
team
that
tries
to
deliver
static
analysis
tools
to
go
to
help
with
security
and
privacy
issues.
So
this
talk
is
on
goal
vulnerability
scanning
and
you
know
please
feel
free
to
to
stop
me
at
any
point
and
ask
any
questions.
B
So
let
me
just
jump
right
into
it.
What
is
our
objective?
Our
objective
is
to
deliver
scanning
of
a
goal
program
dependencies
for
known
vulnerabilities
and
the
motivation
for
this
is
rather
known,
but
let
me
just
go
through
it
again.
This
is
really
a
critical
part
of
software
supply
and
security
practice.
You
know
people
really
want
to
make
sure
that
you
know
dependencies.
They
are
reporting
they're
healthy,
because
otherwise,
if
they
are
importing
vulnerabilities,
they're
coding
going
to
be
vulnerable
too.
B
So
this
in
itself
is
a
pretty
good
motivation.
Why
would
we
do
that?
But
again
you
know
if
somebody
else
has
already
done
it,
then
why
would
we
do
it
too
right?
So
if
you
look
at
the
existing
tools,
for
you
know
scanning
program
dependencies
for
gold,
there
exists
all
such
a
snake
nancy.
I
think
that
github
recently
also
introduced
something
the
what
it
really
do.
Is
they
try
to
detect?
B
Are
you
importing
in
your
project,
a
package
that
has
some
you
know
vulnerable
symbols
or
maybe
you're
somewhere
you're
mentioning
a
vulnerable
symbol,
so
when
we
looked
a
little
bit
into
deeper
into
this
and
talked
with
some
folks,
so
we
realized
that
very
often
this
is
going
to
produce.
You
know
false
alarms,
oh
and
it's
kind
of
hard
to
understand
and
try
findings.
B
So
let
me
just
go
through
a
very,
very,
very
simple
example
to
drive
this
point
further.
So,
for
instance,
suppose
I
had
this.
This
is
very,
very
elusive
program.
We
have
the
main
package
and
then
we
are
importing
a
package
p
and
calling
function
g
right,
so
this
function
itself
is
safe,
but
f
has
a
known
vulnerability
right.
If
you
look
at
this
program,
you
know
you
know
we're
really
not
using
f
we're,
not
calling
it
so
in
principle,
our
code
is
not
vulnerable
because
we're
not
using
the
vulnerable
function.
B
A
Ahead,
can
I
ask
a
question:
what
happens
if
and
sorry,
if
you're
going
to
cover
this
later,
if
function,
f
is
called
in
function?
G.
B
Right
in
that
case
it
is
reachable
right
and
then
you
know
you
really
are
using
f.
You
know,
so
your
code
does
become
vulnerable.
In
that
case,
you
know
we
should
report
this,
but
did
here
you
know,
I
think
I
should
have
made
this
more
clear.
The
assumption
is
that
you
know:
f
is
not
being
called
directly
by
the
user
or
by
g
itself.
A
B
Right,
so
that's
a
good
question
I
mean
haven't
still
got
into
the,
how
we
do
it,
but
I
can
give
you
a
very
answer,
so
we
don't
go
at
that
level
of
granularity
right,
but
this
is
an
excellent
point.
Is
that
you
know
this
is
very
hard.
You
know
to
catch
such
vulnerabilities,
because
you
know
analysis.
Static,
really
needs
to
figure
out
conditions
which
is
generally
very
very
hard.
B
So
even
if
we
have
a
false
alarm,
I
think
it
would
be
really
helpful
for
the
people
to
understand
what
is
going
on,
so
they
can
make
so
they
can
essentially
assess
the
impact
of
this
vulnerability.
This
is
like
a
very
similar
example.
Is
here
it's
a
little
bit
different
than
you
suggested,
but
suppose
that
you
know
in
a
project.
B
We
are
just
importing
a
parse
library
with
a
known
vulnerable
function,
parse
right,
but
we
are
always
calling
it
on
a
fixed
input,
and
we
know
that
this
you
know
a
vulnerable
function
behaves
very
well
on
this
fixed
input.
So
maybe
you
know,
although
this
vulnerability
is
exercise,
we
know
that
there
is
no
real
impact
right.
So
you
know
so
you
know
showing
people
in
the
code
how
this
vulnerability
is
exercise
helps
you
really
try
defining
it
and
assess
impact
with
current
tools.
B
You
really
don't
get
that
because
they
just
say:
hey
you're,
importing
a
package,
that's
vulnerable
and
that's
it
okay.
So
how
do
we
address
it?
So
what
do
we
do
in
a
very
nutshell?
So,
first
of
all,
we
have
a
vulnerability
database,
so
I
need
to
mention
that
first,
this
is
actually
been
developed
by
go
security
folks.
They
have
developed
the
format
for
vulnerabilities
in
go
a
protocol
for
sharing
these
vulnerabilities
clients
and
they
have
even
created
an
initial
database.
That's
available
on
the
link
here.
B
So,
of
course,
you
know
we
also
have
the
program.
So
what
we
do
is
for
every
vulnerability
that
is
important.
We
actually
try
to
find
like
a
witness
execution
that
shows
hey.
You
know
you're,
actually
using
in
a
vulnerable
function
or
method.
So
how
do
we
do
that?
So,
first
of
all,
we
build
a
call
graph
of
the
whole
program,
and
here
in
in
this
graph
you
know
the
nodes
are
really
the
functions.
B
So
what
we
do?
We
start
from
the
entry
points
and
you
know
just
for
you
know.
Currently,
entry
points
are
like
init
main
exported
methods
and
functions,
and
we
traverse
the
call
graph
and
once
we
find
a
symbol
like
a
call
to
another
function,
some
vulnerability
that
is
being
mentioned
in
a
database.
We
report
this
to
the
user.
So
essentially
we
say
hey,
you
know
you
have
some
vulnerability,
you
show
a
trace
here.
Tracy
show
it
upside
down
means
the
entry
point
is
f3,
then
in
f3
calling
f
f5.
B
Eventually,
you
call
f
y
and
inside
of
fy
you're
using
this
some
vulnerability,
you're
calling
it-
and
here
is
information
on
this
vulnerability.
So
in
general
it
really.
The
features
that
we
want
from
golden
volt
check
is
to
actually
give
us
a
stronger
signal
of
whether
or
not
something
has
been
used
and
a
and
something
that
users
can
really.
You
know
use
to
try
as
the
findings
quicker.
So
in
general,
the
really
the
main
features
of
won't
check
our
tool
for
scanning
the
penalties
of
go
is.
B
We
are
really
searching
for
call
stacks
for
every
important
vulnerability
that
show
that
you
know
this
vulnerability
is
actually
reachable
in
the
code
and
we
start
from
the
entry
points.
We
traverse
the
call
graph
just
for
people
who
are
interested.
We
actually
build
this
call
graph
with
a
very
new
caller
of
analysis
that
we
have
implemented
vta,
it's
very
known
in
the
research
community.
B
It's
available
experimentally
at
the
as
a
as
a
vta
package
in
the
call
graph
module
and
one
one
thing
I
really
want
to
point
out
is
that
we
don't
look
for
all
call
stacks,
because
otherwise
you
know
we
will
search
indefinitely.
We
really
try
to
find
representative
call
stacks.
So,
basically,
since
we
are
not
pat
sensitive
and
similar,
we
don't
really,
you
know,
look
for.
You
know,
calls
like
that,
involve
recursion,
and
we
really
want
to
try.
You
know
as
simple
call
sex
as
possible.
B
Again
coleslaw
can
really
serve
as
witnesses
for
use
of
vulnerability
and
again.
The
point
is
we
really
want
to
help
you
with
the
triage,
the
vulnerability
use,
so
the
gold
ball
check
as
a
tool
also
supports,
detecting
only
if
you
know
a
package
that
has
some
vulnerability
has
been
imported.
The
reason
for
this
is
because
we,
you
know
we
want
to
allow
users
that
maybe
are
already
familiar
with
other
tools
and
also
you
know
call
graph
computation
takes
time.
B
So
for
somebody
you
know
some
folks
that
want
to
have
a
you
know
fast,
very
conservative
check.
This
would
be
the
way
to
go
and
also
for
for
for
cases
where
there
is
no
source
code.
We
also
provide
a
search
over
our
binary,
so
essentially
in
the
binary.
We
extract
the
code,
the
all
the
link
symbols,
and
we
just
make
sure
that
you
know
they
do
or
do
not
appear
in
the
vulnerability
database.
B
B
We
can't
do
that
right,
but
the
point
of
golden
check
is
that
we
should
not
report
findings
for
moral
vulnerabilities,
this
state
of
the
art,
so
we're
really
trying
to
refine
state
of
the
art,
and
even
in
the
case,
when
we
have
a
false
alarm,
a
call
stack
that
we
communicate
to
the
people
should
help
them
to
try
is
the
finding
and
essentially
answer
hey
you
know:
is
this
really
a
vulnerability
in
my
code
or
not?
Let
me
just
say
I
think
it
has
some
questions,
a
vulnerability
database.
B
Right
so
so
vulnerability
database.
This
is
like
a
this
is
a
separate
or
a
very
related
project.
We
would
go
where
idea
was
to
standardize
vulnerability,
reporting
for
gold
so
and
it
consists
of
an
actual
database,
but
it's
really
more
than
that.
It's
also
the
schema.
It's
also
the
the
protocol
for
exchanging
information,
and
you
know,
go
security
folks
have
implemented
the
initial
database.
B
The
database
is,
is
json
based,
it's
not
really
sql
per
se,
and
I
guess
the
bigger
point
here
to
make
is
that
it's
not
fixed
right.
So
you
know
you
can
have
your
own
ability
database
that
satisfies
this
format
and
the
protocol
you
can
plug
it
into
the
google
check
tool.
So
the
government
check
tool
is
not
doesn't
have
like
a
you
know,
fixed
database
that
it
queries.
B
A
I
hope
that
answered
the
question.
One
more
question
I
have
was
sometimes
in
go
mod.
There
are
no
tagged
versions
for
an
imported
module
and
then,
as
a
result
of
that,
you
end
up
using
a
commit
hash
of
it
to
import
it
import
a
specific
level
in
the
history
commit
history
instead
of
tagging
that
particular
commit.
A
In
that
case,
what
happens
if
you
probably
already
know
this
more
than
me,
the
version
shows
up
as
zero
zero
zero
and
as
a
result
of
that,
what
we
found
in
the
past
is
if
vulnerability
scanner
is
looking
for
a
version
check
where
it
says
this
vulnerability
was
detected
in
this
version,
170
and
fixed
in
171,
and
it
see
0
0
0.
It
thinks
that
it
is
actually
vulnerable,
and
then
it
comes
up
with
a
false
positive
report,
even
though
170,
even
though
the
commit
is
actually
after
170
or
171,.
B
A
Right
we,
I
can
go
deeper
offline
also,
but
just
we
can.
We
can
try
this
one
more
time,
so
the
commit
hash
when
used
to
import
basically
creates
a
fake
version
which
is
v000,
even
though
the
commit
is
after
170
tag.
So
as
a
result
of
that,
when
the
scanner
is
test
checking
against
the
version
of
the
imported
dependency,
it
will
find
zero
zero
zero.
So
it
will
think
it
is
actually
zero
zero
zero,
even
though
it
is
after
tag,
one
seven,
zero.
B
Right
so
so,
actually
we
haven't
seen
those
cases,
but
you
know
this
is
good.
You
mentioned
this.
It
doesn't
seem
like
something
that
we
shouldn't
be
able
to
support
so
and,
as
a
matter
of
fact,
you
know
if,
if
you
have
examples
of
that,
you
know
that
would
be
great.
I
mean
one
part
of
this.
You
know
presentation
is
to
really
you
know,
show
you
know.
What
are
we
trying
to
do?
We
go,
go,
won't
check
and
also
get
feedback.
Really
so
I
mean
that's
great,
so
we
haven't.
B
I
would
just
say
that
we
haven't
really
hit
those
cases,
yet
we're
really
using
the
the
golang
samware
package,
for
you
know,
checking
the
the
package
versions.
But
if
this
really
is
a
problem
then
then
probably
we
should,
you
know
deal
with
it
outside
of
that
package
itself.
A
B
Yeah
that
that's
that's,
that's
great,
okay,
so
I
let
me
maybe
try,
unless
you
want
to
share
it
right
now:
oh
no!
No!
We
can
do
it
later,
keep
going!
Okay!
Let
me
try
to
just
run
the
tool.
Okay,
can
everybody
see
this.
B
B
Well,
so
let
me
just
first
of
all:
this
is
how
we,
how
we're
going
to
call
actually
I'm
going
to
use
the
for
bose
mode
for
now,
and
so
we
are
running
a
goldblum
check
here
on
kubernetes,
I
have
explicitly
chosen
the
version
15.11
because
we
know
it
has
some
vulnerability
issues,
at
least
with
respect
to
the
database
we
are
using.
I
have
ran
it
also,
this
on
the
one
of
the
newest
versions
of
kubernetes,
all
looks
fine.
So
what
I'm
saying
go,
go
and
check
here.
B
You
know
I'm
giving
this
a
go
pad
and
saying:
hey,
just
analyze,
everything
in
the
project,
so
I'm
going
to
kick
it.
So
I
have
to
be
honest.
This
is
going
to
take
some
time
because
kubernetes
is
really
massive
and
we're
really
trying
to
you
know,
build
a
call
graph
of
the
whole
program.
B
So,
while
I'm
doing
that,
I
can
go
just
go
quickly
back
and
just
explain,
you
know
what
are
we
doing
under
the
hood
so
for
folks
might
be
interested
in
how
much
time
it
takes
so
for
a
you
know
for
a
command
like
this.
So,
first
of
all,
you
know
we
load
all
kubernetes
packages.
B
This
is
around
15
seconds.
We
convert
this
to
the
ssa
in
a
single
static
assignment
form,
because
that's
how
we
do
our
analysis
on
top
of
so
this
is
just
like.
You
know,
quickly,
seven
seconds
we
reload
the
whole
remote
database,
which
is
15
seconds
without
any
caching.
If
you,
if
you
enable
caching,
you
know
this-
this
is
almost
instantaneous,
then,
after
that
we
create
a
call
graph.
B
So
this
is
really
the
crux
of
everything
you
know
for
us
really,
building
a
precise
call
graph
is
what
drives
the
precision
of
the
tool,
so
he
in
this
instance
for
kubernetes
it
takes
one
and
one
and
a
half
minutes.
This
is,
without
you
know,
major
engineering.
You
know
that
pertains
to
optimization,
so
this
can
be,
but
the
reason
why
this
is
actually
takes
so
much
because
we
run
the
colgate
construction
twice,
so
we
so
we
improve
it
in
every
iteration.
B
So
it's
even
more
accurate
and
the
other
thing
to
have
in
mind
is
that
you
know.
So.
This
is
a
dependency
scanning,
so
we
can't
just
take
you
know:
kubernetes
source
code.
We
need
to
take
kubernetes
source
code
and
all
of
its
transit
dependencies,
so
this
actually
becomes
an
enormous,
enormous
program
that
we
need
to.
You
know
create
a
call
graph
for
so
after
that
you
know,
we
just
traverse
the
call
graph
in
search
for
the
symbols
that
are
defined
in
a
database.
B
So
what's
the
what
my
demo
is
going
to
show
very
quickly,
hopefully,
if
you
know
nothing
breaks
down
today,
I
I
really
don't
think
you
should,
but
we're
going
to
be
showing
findings
for
only
three
vulnerabilities,
so
basically
we're
going
to
have
three
different
vulnerabilities
and
we're
going
to
show
call
stacks
for
them,
and
but
if
you
just
run
this
in
an
imports
mode
and
say
hey
just
try
to
find
you
know,
packages
that
are
imported
and
have
vulnerabilities,
they
will
have
12..
B
So
you
see
that
there's
a
there's,
a
significant
difference
for
for
nine
of
those
packages
that
we
actually
import.
We
can't
find
any
call
stack
exhibiting
use
of
any
of
these
vulnerable
symbols,
so
I
think
we
probably
have
a
little
bit
more
time
before
this.
B
This
this
finishes.
Actually,
oh,
actually,
it's
already
done.
Okay,
so
let
me
just
explain
the
output,
so
this
looks
very
cluttered.
It's
not
surprising,
you
know
probably
need
a
little
bit
more
work
on
user
interface
and
again
any
feedback
would
be
greatly
appreciated.
B
So
let
me
just
go
step
by
step
and
just
explain:
you
know
what
is
the
output
here
so,
for
instance,
I'm
going
to
highlight
it
this
way,
you,
let
me
know
if
you
can't
see
it
or
something
is
not
clear,
so
we're
going
to
show
one
call
stack
for
a
package
on
crypto
ssh
and
the
vulnerability
that's
describing
this
on
on
this
link
and
we're
showing
only
one
call
stack
that
we
found
you
know
by
default.
B
You
know,
if
you
put
like
an
all
flag,
you
can
get
all
call
stacks
so,
and
this
is
a
trace.
So
when
a
trace
says,
like
hey,
well,
consider
the
entry
point,
you
know
kubernetes
package,
ssh,
encode,
ssh
key
at
this
location,
but
inside
you're,
actually
making
a
call
to
ssh
package
of
crypto
new
public
key
at
a
version
that
is
known
to
be
vulnerable.
B
So
now,
if
you
actually
go
and
you
follow
the
the
locations
in
the
code,
you
can
really
see
step
by
step.
You
know
what
is
going
on
and
actually
I'm
going
to
take
you
through
one
of
these
examples
in
just
a
bit
a
little
bit
more,
you
know.
Another
like
a
very
rather
simple
trace
is,
is
the
same
for
open
containers
lip
container
for
go
as
a
linux.
B
B
I
think
this
is
jsonpatch
or
github
mnfx.
If
I'm
pronouncing
this
correctly.
So
you
can
see
here
that
this
trace
that
we
are
showing
is
actually
longer,
so
it's
a
little
bit
more
involved,
but
there
is
a
thing
that
I
want
to
point
out
here
and
I'm
going
to
highlight
it,
which
is
approximately
result.
So
what
is
it
saying
is
that
well
we
have
a
call
to
jsonpatch
container
ad,
but
this
is
a
dynamic
call
and
our
tool
resolved
it
to
partial
array.ad
right.
B
B
A
A
Point
it
to
zero
zero
zero
one.
One
more
thing
was
who
don't
know
what
everyone
else
is
thinking
for
me,
at
least
when
I'm
looking
at
a
vulnerability
scan
I
need
I
would.
The
main
thing
I
look
at
is
for
cve
numbers
in
the
report.
So
if,
if
it's
not
found,
then
I'm
like
trying
to
find
out
where
it
is
and
okay,
maybe
others
have
other
opinion.
This
is
just
my
personal
opinion.
B
Right,
I
think
that
that's
fine,
so
essentially,
this
is
just
a,
I
think,
a
yaml
file.
Let
me
just
try
to
open
it
very
quickly.
I
think.
Typically,
the
vulnerability
format
also
should
include
cv
information
yeah,
for
instance.
Let
me
just
try
to
make
this
bigger,
so
you
will
see
that
cv
is.
Is
this
one.
B
So
if
you
follow
the
link,
you
know
you
get
all,
but
it's
good
to
hear
that
you
know
you
would
like
to
see
cv
something
to
communicate
it
earlier
rather
than
later.
Okay,
that's
very
good!
That's
very
good
yeah!
So
so
this
information
that
you
know
goldman
vulnerability
database
contains
it
has
all
the
information
on
cvs
the
actual
packages
when
was
introduced
when
when
was
it
fixed
and
things
of
that
nature,
but
it's
very
good
to
know.
B
Thank
you
that
you
know
there
are
instances
where
this
you
know
just
hash
commit
zero
zero
zero.
So
we,
ideally
we
really
shouldn't
include
this.
Okay,
that's
very
good
so,
but
this
is
sort
of
somehow
the
larger
point
is
to
really
focus
on.
What
are
we
showing
and
what
are
we
finding?
You
know
getting
the
vulnerability
database
right
and
version
checking
is
seems
honestly
like
an
easier
problem
to
solve
right.
At
least
I
hope
so
so
also.
B
What
I
want
to
point
out
is
that
for
for
packages
that
are
actually
for
vulnerabilities,
like
say,
text,
transform
that
are
important,
we're
also
going
to
say
a
message:
hey!
Your
package
has
been
imported,
but
really
you
know,
no
vulnerable.
Symbol
is
actually
reachable
from
the
entry
points,
so
just
to
get
the
extra
information
for
people
that
might
get
confused
hey.
Why
do
I
have
so
much
bindings
with
say
a
snake,
but
I
don't
have
so
much
with
global
check.
So
this
is
just
additional
information
provided.
B
Okay,
if
you
don't
so,
let
me
just
go
briefly
to
the
presentation
and
I
can
just
go
very
quickly.
Go
through
you
know
through
one
of
these
you
know
jason
patch,
tracy,.
A
On
the
tracing
would
be
if
it
could
look
more
like
a
yaml
file
with
a
waterfall.
I
know
people
hate
the
apples
in
cuban
natives,
but
basically,
if
it
has
some
level
of
indentation
where
it
knows
what
the
parent
is
and
then
the
children,
it
might
be
helpful
to
read
it
from
purely
scan
reporting
perspective.
B
Absolutely
so
so
you
know
honestly,
you
know
so
golden
check
is
still
rather
in
an
experimental
phase.
So
the
reason
why
we
really
haven't
like
fixed
on
the
output
is
because
you
know
we
actually
want
to
talk
with
people
first
so
clearly
for
us.
Html
reporting
was
one
option
because
you
can
easily
follow
the
links
to
your
local
files
and
which
kind
of
makes
it
simpler.
But
but
I
agree,
you
know
even
at
the
even
at
the
level
of
just
command
line.
A
B
I
mean
100
agree
and
by
the
way,
the
tool
itself
also,
you
know,
has
a
json
flag,
so
you
can
actually
take
the
result
in
the
findings
and
just
you
know
you
can
pre,
you
know
post-process
it
or
do
whatever
you
like
with
it.
You
know,
and
the
libraries
that
we
are
trying
to
propose
and
get
out
will
essentially
have
we'll
basically
have
the
data
structures
fixed
and
publicly
discussed.
Does
it
have
a
question.
B
Right
exactly
so
so
since.
F
A
Everyone
who
watches
the
recording
so
ravinder
is
saying
in
this
case.
We
should
be
more
accurate
to
report
vulnerabilities
else.
We
will
be
in
false
sense
of
security
as
we
are
going
to
use
a
module
which
has
a
vulnerability,
but
we
don't
use
a
vulnerable
function
and
not
reporting
not
sure
if
I'm
getting
it
right.
Quite.
B
Right,
so
I
think
it
really
depends.
What
is
the
use
case?
If
I
understand
the
question
correctly,
I
think,
for
people
that
really
want
to
be
like
extra
extra
extra
secure,
they
can
just
run
the
imports
mode
right
because
the
import
somebody
is
going
to
say
well,
whenever
you're
importing
a
package
that
has
some
vulnerability,
you
know
I'm
going
to
flag
it
so
for
people
that
that
want
this
level
of
security,
so
to
speak,
really
be
extra
conservative.
B
They
can
use
that
mode,
and
this
is
one
of
the
reasons
why
we
also
want
to
provide
it
not
to
mention,
because
it
is
faster,
but
for
folks
that
actually
really
want
to
see
hey.
You
know
I
might
use
a
in
a
vulnerable
package,
but
I'm
not
really
using
any
of
its
symbols.
You
know
my
code.
If
you
look
at
my
the
entry
points
on
my
code,
my
mains,
my
inits,
my
libraries,
you
can't
really
reach
any
of
these
functions
so
so
for
people
like
that,
we
actually
want
to
provide
this
provider's
features.
B
So
the
soundness
here
is,
of
course,
always
pretty
much
subject
to
the
vulnerability
database.
If
the
vulnerability
database
is
is
correct,
we
should
give
correct
results,
so
we
so
we
are
really
not
under
approximate
one
or
two.
You
know
two.
There
are
two
distinctions
here.
Currently
we
really
don't
go
through
reflect
and
unsafe
for
cgos
for
now.
A
So
seagull
anything
that's
using
c
go
and
if
there
is
a
one
between
the
c
linked
package
or
function
that
won't
be
detected
today,
no.
B
Yeah,
so,
okay,
so
we
have
just
a
few
more
minutes.
So
let
me
just
briefly
go
to
this
example,
so
you
know
I
won't
really
spend
too
much
time
on
this
I'll
go
rather
quickly.
This
is
again
just
showing
you
know,
you
know
the
the
trace
in
a
little
bit
more
better.
You
know
fashion.
So
again,
you
know
we
started
with
a
patch
method
as
an
entry,
and
you
know
the
tool
we
realized.
Okay,
we
have
a
call
to
apply
object.
B
Okay,
have
a
question
provide
a
link
to
powerpoint?
Yes,
I
can
I'll
add
it
to
the
agenda.
Yes,
I
will
add
the
the
presentation
say:
oh,
you
can
take
a
look
at
it,
so
the
tool
says:
okay,
we
calling
apply
of
patch
object
and
then
we
can
follow
these
links
and
at
some
point
you
know
we're
going
to
come
to
this
function.
Add
of
patch
and
then
our
tool
is
going
to
say.
Hey
look.
You
know
here
at
this
interface
call.
B
You
know
we
are
resolving
it
to
a
partial
area
that
add
of
jsonpatch.
So
you
know
just
for
people
look
a
little
bit
more
interested.
How
do
we
do
that?
How
does
that
call
graph
analysis
figure
this
out?
Well,
actually,
you
can
see
that
there
is
a
find
object,
called
a
line
468
that
produces
this
con.
So
the
call
graph
analysis
is
actually
you
know,
it
hasn't,
has
a
flavor
of
data
flow,
so
it
will
actually
go
inside,
find
object.
B
You
know
here
you
know
I'm
kind
of
short
on
the
code.
It
will
see
that
this
function
find
object,
returns
a
doc
as
the
first
argument,
and
this
doc
is
also
set
in
this
next
into
array,
and
if
you
go
inside
a
next
inter
area,
you'll
see
that
it
returns
partial
array
so
essentially
into
every
returns,
partial
area
and
then
in
a
find
object,
returns,
partial
area
and
that's
how
analysis
tells
you
hey
you're,
using
partial
area
that
add,
and
that
is
actually
vulnerable.
B
So
that's
it.
I
won't
go.
You
know
more
into
this
I'll
leave
some.
You
know
some
time
for
if
you
have
any
questions
again,
you
know
we
have
some
instructions
on
how
to
install
and
use
global
check.
I
will
also
link
it
in
the
in
the
presentation
itself.
So
you
know
you
can
play
with
it,
because
this
is
really.
The
main
purpose
of
this
is
to
introduce
your
goal
check
on
a
very
high
level.
Get
feedback
already
get
got
some
excellent
advices
about
false
positives
and
the
output.
B
But
you
know
if
you
have
any
ideas
of
what
should
be
in
the
interface
with
the
with
the
tool
itself.
What
should
we
change?
What
should
we
add,
for
instance,
should
we
add
html
reporting?
Should
we
also
provide
information?
How
call
graph
analysis
figures
things
out,
or
this
is
maybe
too
much
for
the
user?
B
Should
the
user
have
the
really
the
control
of
specific
okay?
What
are
the
entry
points
of
my
my
packages?
You
know,
should
incorporate
feedback
to
the
tool
itself.
Anything
anything
really
anything
is
is
greatly
valuable
and
at
the
very
end
you
know.
Okay,
you
know
the
the
true
positive,
false
positive
rate.
You
know
the
rate
of
false
around
what
is
really
an
exact,
acceptable
rate.
You
know,
any
feedback
is
greatly
appreciated.
B
You
can
send
it
either
to
me
or
to
the
to
the
deep
development
mail
that
are
listed
here
and
again.
You
know.
Google
check
exists
as
a
as
a
you
know,
as
a
command
is
in
experimental
mode,
so,
basically
you
can
play
with
it
right
out
of
the
bat
so,
and
it
will
be.
You
know
great
if
you
know
people
that
are
really
interested
to
try
it
out.
A
A
couple
couple
of
questions
in
terms
of
reaching
out
to
the
team
is
that
for
domain
google.com.
B
A
A
One
thing
I'll
also
do
because
this
this
happens
with
me
also,
I
end
up
coming
up
with
questions
or
thoughts
about
the
demos
after
the
demo
is
over
so
I'll
create
a
slack
thread
on
the
channel
about
this
and
folks
who
watch
the
demo
or
the
recordings
if
they
have
feedback
I'll
request
them
to
put
it
there.
So
you'll
have
everything
in
one
place.
F
A
Yeah,
we
definitely
learned
a
lot.
This
is
very
interesting
work
to
see
and
coming
from
the
go
team.
We
definitely
hope
that
it
will
be
eventually
natively
supported
as
anything
else
in
go.
B
Right
that
is
our
intention,
like
I
said
it's
still
rather
experimental.
We
we're
trying
to
you
know.
Finally,
you
know
publish
some
of
the
libraries
out,
but
you
know
we.
We
essentially
really
need
feedback
at
this
point.
You
know
we
really
want
users
to
play
with
it
and
say
hey.
This
is
what
I
don't
like.
This
is
what
it
should
be.
Maybe
change-
or
maybe
you
should
add
this
feature
so
essentially
we're
really
at
this
stage.
A
Got
it?
Okay,
okay,
cool
thanks
everyone
for
joining
as
well,
and
giving
good
feedback
and
listening
to
zwanimer.
I
hope
this
was
useful
for
you.
We.