►
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
Cool
thanks
everyone
for
coming
together
this
morning.
I
just
wanted
to
have
a
sync
up
discussion
on
where
to
show
vulnerabilities
that
are
not
tied
to
projects,
especially
before
andy
goes
out
on
parental
leave.
A
I
know
we
had
discussed
this
earlier
in
maybe
it
was
like
at
the
end
of
last
year
when
kyle
was
still
with
us
and
we
sort
of
came
to
a
soft
decision
of
using
tabs,
but
I
don't
know
that
that'll
address
all
use
cases,
and
I
just
wanted
to
kick
that
off
again
because
we're
actually
getting
pretty
close
to
actually
working
in
this
area
so
we're
you
know
wanting
to
make
sure
that
we're
if
we
do
end
up
contributing
towards
this,
because
I
know
it's
pretty
far
out
matt
on
your
priorities.
A
You
know
we
want
to
make
sure
that
it
still
is
consistent
with
your
direction
and
with
where
you
want
things
to
go
in
the
threat
inside
space.
Just
to
get
things
kicked
off
and
to
describe
the
problem
that
we
have.
A
You
know
we're
going
to
need
to
be
able
to
scan
images
and
get
labs
registry.
At
some
point,
we
also
need
the
ability
to
scan
containers
that
are
running
in
production
and
each
of
those
have
their
own
challenges
with
them
scanning
images
and
get
labs
registry.
The
nice
thing
about
that
is
at
least
there
is
a
gitlab
object
that
they're
tied
to
which
would
would
be
the
container
image
in
the
registry.
A
They
may
or
may
not
also
be
associated
with
a
project
they
may
or
may
not
also
be
associated
with
an
environment,
one
or
more
environments
or
clusters,
but
at
least
there's
always
one
object
to
anchor
off
of
for
that
talking
about
scanning
containers
in
production
that
could
be
any
production,
kubernetes
cluster.
So
there's
no
guarantee
that
that
maps
back
to
any
object
at
all
that
we
have
inside
of
gitlab.
They
may
have
set
up
a
cluster
in
get
lab
either
at
the
project
group
or
I
don't
know
if
it's
the
instance.
A
I
think
it's
the
workspace
level
essentially,
but
it
could
map
back
to
one
of
those
clusters
it
could
map
back
to
an
environment
if
they
have
that
created
in
gitlab.
It
could
map
back.
You
know,
because
it
maps
back
to
an
environment.
You
could
basically
assume
the
project
that
it's
associated
with,
but
again
none
of
that
is
a
guarantee.
It
could
just
be
a
cluster
that
has
nothing
else
to
do
with
git
lab
that's
out
there
and
so
that's
sort
of
the
problem.
A
A
I
don't
have
answers
just
you
know,
wanted
to
kick
off
the
discussion
and
the
goal
of
this
meeting
would
be
to
at
least
come
with
to
some
sort
of
like
notional
consensus
about
where
we
want
to
solve
this,
so
that
you
know
when
andy
goes
out
on
parental
leave.
Annabelle
can
continue
working
and
at
least
have
it
somewhat
aligned
with
the
threat
insights.
B
A
Yeah,
so
that
is
a
good
point
and
that
may
be
a
way
to
type
back
to
the
project
it
would
be
associated
with
it
would
be
created
using
our
policy
editor
and
our
policy
editor
will
eventually
be
available
at
the
project
group
and
workspace
level,
but
they
would
be
creating,
say,
a
project
level
policy
that
says
you
know
on
a
weekly
basis
on
sunday
at
midnight.
A
I
want
to
kick
off
a
scan
against
all
the
pods,
all
the
containers
in
this
cluster
and
then
kind
of
fill
that
in
it's
the
same
thing
with
das
too
right
like
you,
can
actually
use
das
today.
If
you
configure
it
right
to
scan
a
production
website,
but
it
it's
initiated
from
the
context
of
a
project.
So
we
could
associate
it
back
to
that
project
where
it
was
configured
from
or
the
group
or
the
workspace
in
the
future.
B
Yeah,
I
don't
know
from
a
like
a
visibility
perspective,
if
that's
necessarily
the
best,
but
I
do
like
that,
as
maybe
at
least
a
starting
point
to
explore,
since
there
has
to
be
an
anchor
right
like
it
has
to
start
from
a
somewhere
for
a
thing
like
dast,
where
really
you
know
to
your
point,
you're
just
pointing
a
tool
that
anywhere.
If
you
choose
to
abuse
it,
you
could
point
it
at
a
website.
You
do
not
own.
B
B
C
And
building
off
of
that
with
regards
to
desk,
so
not
only
can
you
point
that
scanner
to
whatever
url
that
you
might
not
necessarily
own
but
for
on-demand
scans.
We
also
are
starting
to
associate
them
with
a
branch
that
you
can
choose
and
there's
nothing
actually
tying
the
two
together.
So
if
you
point
it
at
like
staging-
and
you
say
it's,
this
is
the
code.
That's
on
the
staging
branch.
There's
no
way
to
prove
that!
B
Don't
like
that,
one,
because
people
are
going
to
come
and
blame
me,
and
I
won't
say
andy
thiago
for
that
one.
Why
aren't
these
results
really
in
the
branch?
That's
a
great
point,
though,
is
we
want
to
make
sure
that
there's
a
a
very
clear
line
between
whatever
is
found
and
the
source
of
that
problem.
D
D
A
Yeah,
it
seems
like
we're
already
in
that
mess
a
bit
today,
because
we
have
everything
at
the
project
level,
so
each
product
project
shows
its
own
subset.
I
mean
what
you're
describing
sounds
like
rolling
everything
up
to
a
workspace
level,
single
dashboard
view
where
you
have
one
place
to
go
to
see
everything.
D
And
we're
probably
going
to
be
getting
there
with
the
security
center
right,
because
that's
everything
that
will
display
everything
that
the
at
the
user
level
they
have
purview
over
in
their
gitlab
instance
or
workspace,
so
that
that
could
be
an
alternative
down
the
road,
but
even
like
groups
and
projects
that
kind
of
treat
them
the
same
as
the
single
source
of
truth,
just
depending
on
which,
however
level
you
take,
it
should
be
where
vulnerabilities
are
tracked
and
triaged
from.
D
A
I'm
saying
what,
if
what,
if
all
clusters
and
all
environments
were
just
opted
in
and
it
rolled
I
mean
so
like
projects
aside,
put
that
aside
for
a
minute
right.
Maybe
this
is
a
different
page
or
a
different
tab
or
whatever
right,
but
rather
than
opting
things
in
what,
if
all
of
those
just
rolled
up
there,
and
you
couldn't
see
it
at
the
project
level,
you
couldn't
see
the
group
level,
but
there
was
one
dashboard
at
the
workspace
level
on
the
security
center.
A
That
just
showed
everything
in
this
case
everything
that's
not
correlated
with
the
project,
so
everything
in
production
or
everything
from
your
registry.
I
don't
know
I'm
just
throwing
that
out
there
to
explore
it
as
an
option.
D
I
I
don't
think,
that's
a,
I
don't
think,
that's
like
a
bad
path
at
all.
I
think
it
potentially
solves
a
lot
of
cases.
The
only
thing
that
we
would
want
to
consider
is
that
permission
or
view
level
if
the
user
like
what
determines
the
user
to
have
access
to
view
vulnerabilities
of
a
cluster
versus
a
project
like
if
I'm
not
associated
with
a
project,
I
can't
even
add
it
to
that
dashboard.
A
I
wonder
so
all
of
these
vulnerabilities,
the
one
thing
that
they
will
all
be
associated
with,
is
either
a
scan
or
a
policy
like
there's
something
that
initiated
the
scan
to
kick
it
off
right
and
there
are.
We
know
which
individuals
have
permission
to
view
that
scan
and
which
individuals
have
permissions
to
edit
that
scam.
So
we
might
be
able
to
kind
of
cue
off
of
that
and
say
you
know.
If
you
are
one
of
the
individuals
who
set
this
thing
up,
then
you
have
rights
to
view
the
vulnerability.
A
If
you
you
know,
if
you're
on
the
project
and
you
could
view
the
scan,
then
you
have
rights
to
view
it.
If
you
were
on
the
project,
it
had
rights
to
actually
edit
that
scan
and
configure
it.
Then
you
probably
have
rights
to
dismiss
the
vulnerability
as
well
and
interact
with
the
vulnerability
in
that
way.
So
that
might
be
one
potential
solution.
A
D
Yeah,
I
think
the
only
thing
that
gets
complicated
is
that
the
group,
whatever
happens
at
the
group
level,
just
because
that
vulnerability
report
is
probably
one
of
the
only
ones
that
is
like
project
specific,
like
looking
at
projects
within
we're
filtering
for
without
doing
too
much
heavy
lifting
at
the
group
level.
D
D
It's
kind
of
how
sysdig
works
or
many
of
these
similar
type
vendors
is
they
kind
of
operate
at
a
level,
above
all
the
projects
and
pipelines
and
everything
that
they
have
going
on,
because
they're
bolted
on.
B
We
have
a
lot
of
improvements
that
we
can
make
in
terms
of
and
we'll
say,
difficulty
getting
a
common
nomenclature
for
what
we
want
to
call
a
thing,
a
scanner
found
at
a
particular
location
or
a
context
right.
So
if
we're
able
to
start
identifying
these
vulnerabilities,
what
we've
got
the
problem
right
now
in
just
the
you
know
the
code
scanning
side.
If
I
find
something
in
an
mr,
I
don't
really
have
a
lot
of
smarts
to
say
where
that
thing
also
exists.
We're
only
doing
these
sort
of
dumb
comparisons
between
you
know.
B
We
found
a
fingerprint
for
a
thing
in
branch
a,
and
it
also
is
in
branch
b.
It's
probably
the
same
thing,
but
it's
not
it's
not
doing
things
like
saying.
Well,
it's
also
in
all
these
other
branches,
or
this
is
where
it
came
from,
like
there's
no
sort
of
that
tracer
bullet
and
I'm
a
little
worried
that
if
we
start
doing
all
these
container
scannings
we're
going
to
find
a
lot
of
vulnerabilities.
B
But
it's
going
to
be
very
difficult
to
tie
that
back.
To
say
you
know
here
is
where
the
actual
problem
is
and
right,
because
what,
if
I
have
cloned
a
particular
container
image
10
times
over
and
it
was
that
original
source,
one
where
I
introduced
a
vulnerability,
but
I've
only
discovered
it
way
out
here
right.
So
it's
we're
going
to
have
that
same
problem
of
duplicate
findings
which
are
really
the
same
vulnerability
which
have
the
same
root
cause.
A
Yeah,
it
is
tricky
I
mean
I
think,
for
a
first
mvc
or
going
from
an
iterative
perspective
if
we
do
use
tabs
or
a
different
page
or
some
way
separate
out.
What's
in
production
versus
not
like
at
least
we're
not
having
duplicate
findings
in
the
same
list,
so
you
know,
I
think,
that's
going
to
be
an
acceptable
mvc,
but
you're
right,
like
the
next
thing
we're
going
to
want
to
do
after
that
is
say:
okay,
you
know
this
exists
in
production.
A
Does
this
also
exist
in
my
source
code,
or
do
I
just
need
to
deploy
my
latest
code
and
that
would
solve
the
problem
right?
So
that's
kind
of
the
next
question
is:
how
do
I
fix
it
and
if
we're
not
able
to
do
that
duplicate
matching,
then
you
know
that's
going
to
limit
our
ability
there.
I
think
there
is
still
value,
even
if
we
do
have
duplicates
but
yeah.
That
is
a
good
challenge
to
keep
in
mind
that
we're
going
to
want
to
address
as
a
follow-on.
B
I'm
wondering
if
it
changes
at
all
to
the
way
that
we
would
potentially
approach
this.
If
and
the
things
that
we're
looking
for.
When
we
talk
about
environments,
I
mean
environments
are
really
what
just
a
combination
of
container
images
plus
deployed
application
code,
plus
anything
like
a
helm,
chart
sort
of
the
infrastructure's
code
piece
associated
with
it.
B
I
wonder
if
we
try
to
make
sure
that
we're
looking
at
things
a
little
bit
more
discreetly.
This
is
almost
kind
of
getting
into
the
asset
management
side
of
things
right
like
if
we're.
Actually,
if
we
start
to
think
about
it
as
an
asset
based
approach,
then
you
can
start
doing
things
like
fingerprinting.
A
A
It
is
more
of
an
an
edge
case,
but
you
know
it's
possible
that
an
attacker
gains
control
of
a
container
and
then
they
go
install
their
own
packages,
and
so
that
would
not
have
come
from
a
home
chart
right.
So
the
tricky
thing
is
like
the
only
thing
that
we
can
really
tie
it
back
to
is,
if,
if
we
want
to
go
with
like
an
asset
based
or
an
entity
based
approach,
the
asset
would
be
this
container
running
in
this
production
cluster.
A
B
I
guess,
though,
from
a
like
a
what
what
went
into
the
container
perspective,
though
it
had
to
come
from
a
particular
docker
image
or
something
right
like
there's,
there
is
a
source
of
it
and
then
yeah
I
mean
you're
right.
If
somebody
is
installing
packages
nefariously
inside
of
the
container,
maybe
that
is
starter
getting
into
like
a
kind
of
a
different
use
case,
because
it's
a
vulnerability,
but
that's
more
like
an
active
attack,
which
I
think
would
come
more
from
your
eventing
and
alert
management
system.
B
A
A
Yeah
there
certainly
are
other
ways
of
detecting
that
attack
in
production.
I
mean
what
you're,
describing
though
it
really
map.
You
know
the
other
piece
of
that
maps
back
to
an
image,
because
it
is
it's
always
spawned
from
an
image,
is
what
spawns
a
container.
So
we
can
map
it
back
to
an
image
that
image
may
or
may
not
be
in
our
gitlab
registry,
but
we
can
at
least
map
it
back
to
an
image
right
in
an
image
version,
an
image
tag.
B
So
with
that,
if
we
did
something
like
that
at
the
workspace
level,
is
that
high
enough
does
that
have
enough
curve
like
it
does
the
does
the
get
lab
registry
cover
or
other
way
around
sorry?
Does
the
workspace
level
would
that
cover
anything
in
the
git
lab
registry
and
potentially
anything
at
a
group
or
a
project
level.
A
Yeah
I
mean,
I
think
workspace
would
cover
it,
because
we're
talking
about
things
that
may
not
be
associated
with
any
group
or
project
at
all
other
than
the
fact
that
that's
where
you
wrote
the
policy
to
initiate
the
scan
because
again
like
I
could
just
have
a
cluster
out
there
and
only
thing
tying
it
to
gitlab-
is
the
fact
that
I
have
a
policy
that
says:
go
scan
that
cluster
right,
and
so
in
that
case
those
images
are
not
in
the
gitlab
registry.
A
The
code
isn't
even
in
gitlab,
like
I'm
just
scanning
this
cluster
and
getting
some
finding.
You
know
some
vulnerability
results,
and
so
it
seems
to
me
like
something
at
that
level.
The
workspace
level
would
make
the
most
sense,
but
I
can
also
see
the
argument
of
like,
if
I've
configured
a
policy
at
the
project
level
that
I
may
want
to
see
those
vulnerabilities
there
at
the
project
level
as
well.
A
So
I'm
not
sure.
Maybe
we
do
both
you
know
and
just
roll
those
up
to
the
workspace
level,
but
also
show
it.
If
it
was
a
project
level
policy,
then
maybe
we
show
it
in
at
the
project
level
as
well.
D
I
think
I
think
where
we
show
it
depends
on
where
the
user
wants
to
fix
it.
So
when
you're
thinking
of
tragic
vulnerability,
you
create
an
issue
from
it
that
vulnerability,
typically
associated
with
a
project.
So
the
issue
you
create
goes
right
into
the
project
that
you're
going
to
do
the
work
against
that
vulnerability.
A
The
only
way
to
know
that
would
be
for
them
to
tell
us
like
we're,
not
going
to
be
able
to
infer
it
off
of
anything
other
than
like.
I
said:
where
did
they
create
the
policies
so
sort
of
we
like,
I
said
we
could
make
the
assumption
that
hey,
if
they're
in
the
product,
the
gitlab
project,
and
they
make
a
policy
there,
then
the
assumption
is
that
they're
going
to
be
fixing
it
in
the
gitlab
project.
D
A
For
container
scanning,
like
when
we're
scanning
as
part
of
the
pipeline
job,
it's
gonna
be
pretty
like
they
technically
could
scan
an
external
container,
but
that's
an
uncommon
way
for
people
to
use
it
that
way,
it's
usually
fixed
in
the
project,
but
they
certainly
it's
the
same
problem
as
das,
like
you
can
point
the
container
scanning
engine
at
any
container
in
any
registry
anywhere,
and
it
could
have
nothing
to
do
whatsoever
with
your
project
if
you
wanted
it
to
be
that
way.
B
Who
did
the
thing
because
andy
you
made
a
great
point
like
I
didn't
really
think
about
that.
But
if
I'm
doing
stuff
at
the
workspace
level,
that's
all
about
visibility
and
being
able
to
drill
in
quickly.
But
if
I've
got
this
whole
management
layer
up
at
the
top.
How
do
I
assign
work
down
from
that
like?
How
do
I
make
issues
in
mrs
from
the
workspace
level?
I'm
still
going
to
have
to
go
down
and
pick
a
project
to
do
that
in
and
that's
going
to
be
a
lot
tougher.
D
Yeah
I
mean
there's
always
I
think
this
is
a
prime
candidate
for
problem
validation,
because
there's
there's
so
many
things
that
could
come
out
of
this.
That
could
be
really
useful,
like
maybe
there's
a
whole
new
asset
management
and
response
page
on
the
security
center,
or
you
know
maybe
there's
settings
that
allow
you
to
point
at
whatever
is
being
scanned
in
the
cluster
and
say
I
want
to
associate
results
with
a
project
or
I
want
to
be
able
to
create
issues
automatically
from
this
project.
So
I
think,
there's
a
lot
to
suss
out.
D
I
think
matt,
that's
another
point
you
were
making
is
like
it's
like.
I
just
picked
a
place
because,
like
that's
like
the
best
project,
I
could
guess
so.
I
think.
B
D
B
Go
ahead,
I'm
worried
too
that
we're
also
being
very
get
lab-centric
about
this
right
now,
because
we're
working
in
the
confines
of
the
tool
we've
got.
I
would
venture
sam
that
there's
a
non-zero
chance
that
a
problem
validation
will
uncover
hey.
Like
that's
awesome,
we
can
do
all
the
stuff
with
inside
gitlab.
I
don't
care
about
all
these
projects
and
issues.
Things
build
me,
security
person,
an
area,
and
let
me
do
the
following
things
that
just
don't
exist
in
gitlab
today.
A
Right
yeah,
I
I
can
definitely
see
that
right
where
the
thing
we
know
today
is
that
users,
you
know
and
may
just
be
reviewing
some
of
the
research
we've
already
done,
but
we
know
that
a
large
number
of
our
customers
are
out
buying
external
solutions
to
do
production
container
scanning,
and
some
of
these
solutions
are
very
broad.
They
have
a
huge
feature
set
and
oftentimes.
What
I
see
is
the
customer
is
only
using
the
production
container
scanning
element
of
that
entire
huge
security
solution
right,
so
there
definitely
is
a
need
for
it.
A
Obviously,
if
it's
an
external
solution
today,
it's
not
being
associated
back
to
any
sort
of
project
or
group
or
anything
of
that
nature.
It's
just
saying
you
know
tell
me
what
cluster
to
scan
and
it
goes
and
scans
it,
and
it
comes
back
with
the
results
so
you're
right
like
we
may
be
overthinking
all
of
this
a
little
bit
like
when
we
compare
it
to
current
solutions,
they're
just
going
out
and
scanning
whatever
cluster
you
tell
them
to
scan
and
giving
you
the
findings,
maybe
that's
a
better
place
to
start
for
an
mvc.
B
It
may
be
too,
I
it
kind
of
feels
like
over
time,
the
bigger
that
gitlab
as
an
application,
gets
the
more
likely
we're
going
to
start
ending
up
with
these
highly
specialized
features.
That
technically
can
integrate
and
use
other
parts
of
git
lab,
but
that
people
won't
want
to
because
it
serves
their
need
and
that's
all
they
need
to
use
for
it
right
yeah.
This
could
be
one
of
them.
It
feels
like
if
we're
like
we're,
building
a
pretty
hefty
security
death
star
and
the
more
functionality
we
build
out
the
more
specialized.
B
A
Yeah,
absolutely
all
right.
Well,
we've
got
two
minutes
left
technically.
I
guess
we're
three
minutes
over,
but
I
just
want
to
make
sure
that
annabelle
and
I
are
not
blocked.
You
know
especially
andy
with
you
going
out
here
on
parental
leave.
Soon
you
know
I
know
matt
you
had
expressed
concerns
before
about
showing
them.
In
the
same
view,
you
know
you
wanted
to
see
them
in
a
separate
view
of
some
sort,
whether
it
was
a
tab
or
a
different
page.
A
B
Up
in
my
head,
no,
I
think
just
making
it
clear
to
the
user.
What
they're,
looking
at
and
getting
people
to
the
right
context
is
is
just
kind
of
the
main,
the
main
objective
we
had
something
very
similar
with
fuzz
testing,
where
they
were
sort
of
building
out
this
whole
parallel
experience
and
at
the
end
of
the
day
it
was.
It
was
like
that
either
needs
to
be
completely
separate,
or
you
know,
a
fuzzing
vulnerability
is
just
an
unknown
put
it
in
the
in
the
existing
context.
So
I
do
like
the
tabbed
approach.
D
Architecturally,
it
makes
sense
too,
because
this
is
how
the
industry
will
think
you
know:
there's
there's
code,
there's
assets
so
having
tabs
separated
by
that.
I
think
follows
existing
architecture.
A
All
right:
well,
thanks
for
your
time
today,
I
know
we're
up
on
it.
Yeah
thanks
for
the
sync
up.
We're
gonna
be
diving
into
this
in
the
near
future.
As
you
know,
this
is
starting
to
become
a
higher
priority
on
our
end,
cool
awesome
thanks.