►
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
Explanation
would
be
awesome,
yes,
so
why
don't?
We
start
with
a
demo
there
and
let's
see
how
many
of
those
questions
are
covered
as
part
of
the
demo.
So
as
of
today,
all
of
the
scanning
is
done
through
the
ci
cicd
pipeline.
Well,
really,
the
ci
pipeline
so
to
get
set
up,
a
user
comes
into
their
ci
dot.
Yaml
file
and
they'll
include
a
template
like
sas
or
secret
detection
or
desk
or
container
scanning.
A
Not
all
of
the
different
types
of
scanning
are
applicable
for,
like
container
images
really
container
scanning
container
scanning
analyzer
is
the
primary
one
that
would
be
applicable.
You
could
potentially
run
some
form
of
dependency
scan
against
it
as
well,
but
actually
most
of
those
findings
would
be
covered
by
the
container
scanning
scan
anyway.
So
we've
got
like
a
whole
list
of
different
scanners
that
we
have
in
gitlab.
The
takeaway
is,
there's
really
just
one
that
that's
pertinent
to
these
container
images
in
gitlab.
A
Those
show
up
in
a
few
different
places,
but
the
biggest
one.
That's
pertinent,
for
this
is
the
vulnerability
report
where,
as
of
right
now,
these
all
show
up
you
can
filter
by
status.
Severity
tool
activity:
we
have
lots
of
requests
for
lots,
more
filters
and
right
now,
this
ux
framework
doesn't
allow
us
to
add
a
whole
lot
of
additional
filters,
so
we're
in
the
process
of
reworking
that
and
designing
a
more
scalable
filtering
solution
that
actually
falls
under
a
different
team,
not
my
team,
but
it
still
is
relevant.
A
A
Usually
when
people
are
coming
in
here,
though
they're
starting
with
things
that
need
triage,
you
know
we
also
by
default,
show
things
that
have
been
confirmed
as
true
positive,
but
you
asked
about
like
actions
to
be
taken
in
here.
Most
of
the
time,
the
first
action
is
to
figure
out.
Is
this
a
true
positive
or
a
false?
Positive
is
oftentimes.
The
first
question
that
someone's
asking
themselves,
because,
especially
in
context
of
container
scanning
container
scanning,
doesn't
really
find
a
lot
of
false
positives,
like
the
vulnerability.
A
Is
actually
there
but
it's
another
question
of:
does
the
application
use
the
vulnerable
code,
and
so
does
it
actually
apply,
or
is
that
vulnerable
code
just
sitting
there
on
the
container
image?
And
it's
effectively,
you
know
dead
code
because
there's
no
way
that,
like
it,
never
gets
called
or
used
during
the
process.
So
normally
they
come
in.
They
start
with
things
that
being
triaged
and
they'll
go
through
and
say.
You
know:
okay!
Well,
here's
my
list!
This
is
the
high
severity.
A
I'm
going
to
dig
into
this
one
more
and
get
some
additional
details.
So
you
can
read
the
description
you
can
see
which
file
it
came
from
which
links
out
to
it.
You
can
kind
of
read
up
on
the
details
of
the
specifics
of
the
cve
and
so
typically
typically
they'll
go
through
here
and
they'll,
say
you
know
either
for
container
scanning
they'll
say
you
know.
This
is
a
library
that
never
is
used
or
we
don't
depend
on
it
or
even
we
use
that
library.
But
it's
in
a
piece
of
code
of
that
library.
A
That's
not
used
like.
Maybe
it's
a
vulnerability
with
regular
expressions
and
they
say:
well,
we
don't
do
anything
with
regular
expressions,
so
you
know
we're
using
other
parts
of
that
library,
but
not
this
piece
of
vulnerable
code,
and
so
then
they'll
dismiss
it
as
a
false
positive.
They
can
also.
You
know,
comment
on
it
to
explain
why
they're
dismissing
it
so
that
if
somebody
goes
back
later
and
questions
that
they've
got
a
documented
trail
of
why
they
dismissed
it
in
addition
to
the
vulnerability
report.
Well,
let
me
stop
there.
B
B
A
I
come
over
to
these
ones
are
actually
similar
to
the
ones
that
you
saw
in
design
because
again,
like
different
scanners
find
vulnerabilities
in
different
ways.
So,
like
secret
detection,
we
have
a
list
of
hard-coded
rules
that
we
look
for,
and
so
we
get
to
name
each
one
of
those
with
a
description,
that's
user
friendly
and
that
makes
sense
container
scanning.
A
All
it
really
is
is
a
big
database
comparison,
we're
creating
a
big
list
of
all
of
the
packages
that
are
in
the
image,
and
then
we
have
a
separate
database
that
says
these
packages
have
these
known,
vulnerabilities,
okay,
and
so
all
you're
really
doing
is
saying.
This
vulnerability
exists
in
this
package,
and
so
they
don't
all
come
with
descriptions.
It
would
be
a
rather
large
amount
of
work
to
go
out
and
create.
A
You
know
descriptions
for
all
of
those
like
really
these
get
pulled
from
like
common
databases
like
the
miter
database
or
the
national
vulnerability
database,
and
so
our
database
has
a
whole
bunch
of
different
databases
that
come
together
and
unfortunately,
in
here
there's
nothing,
that's
better
for
a
description.
You
know,
there's
no
title
for
these
there's.
There
is
this
actual
description,
but
that
can
actually
be
quite
long.
It's
not
really
suitable
for
a
title,
and
so
that
longer
form
description
is
what
we
show
here.
A
Typically,
I
think
our
description
itself
actually
will
come
from
this
mvd
database,
so
okay
cool,
so
in
this
particular
case,
it's
nice
and
short,
so
that
might
have
made
for
a
nice
title,
but
it
can
also
be
like
five
lines
long.
You
know
really
dense
text,
and
so
we
just
highlight
like
this
is
the
cve
that
was
found
in
this
particular
package.
A
So
you
know
we
have
a
whole
like
merge,
request
workflow
for
triaging
these
vulnerabilities
as
well,
so
that
helps
cover
anything,
that's
incoming,
but
normally
when
people
are
working
through
this,
this
is
for
their
main
branch.
Only
you
know
this
kind
of
a
workflow
is
for
those
things
that
have
come
up
over
time.
That
you
know
are
a
little
bit
less
expected.
So
it's
actually
very
common.
I
mean
these
databases
are
huge.
A
You
know
you
take
any
software
package
out
there
in
the
world
and
let
it
sit
for
three
months
and
there's
a
really
good
chance
that
there's
going
to
be
a
vulnerability
discovered
for
that
particular
package.
So
you
know
your
questions
about
like
how
common
is
it
to
have
vulnerabilities
in
it's
very
common.
You
know,
teams
are
it's
just
a
constant
chase
to
kind
of
keep
your
latest
tagged
image
up
to
date
so
that
it
doesn't
have
vulnerabilities,
but
any
image?
That's
older
than
say
three
months.
A
Where
are
we
using
this
particular
vulnerable
package?
Because
we
now
have
a
mandate
from
you
know
the
executive
group
or
the
ceo
or
just
you
know
it's
all
over
the
news.
So
we
have
to
make
sure
that
this
is
completely
cleaned
up,
and
you
know
maybe
we
have
other
vulnerabilities
out
there,
but
we,
this
is
like
top
priority
of
the
moment,
is
making
sure
that
this
particular
package
gets
updated.
A
So
we
also
have
our
dependency
list,
and
this
is
useful
also
for
like
compliance
purposes
too,
because
you
have
to
report
out
on
all
of
the
different
packages
that
are
included
upstream
dependencies
that
are
included
in
your
project,
and
so
this
shows
you
a
big
list
of
everything,
regardless
of
whether
it's
vulnerable
or
not.
So
like
this
one,
we
detected
a
vulnerability,
but
we're
also
listing
out
all
of
these
other
packages
with
their
associated
versions.
A
Even
if
they
don't
have
vulnerabilities
again
from
a
compliance
perspective.
Often
they
need
to
generate
a
s-bomb
or
software
build
of
materials
just
to
list
out
everything
that
they
got
and
where
it
came
from,
because
just
because
the
code
that
you
build
has
been
scanned
doesn't
necessarily
mean
that
all
of
the
dependencies
you're
pulling
in
are
safe,
even
if
they're
not
listed
in
like
the
national
vulnerability
database,
if
you're
just
pulling
a
package
from
some
random
obscure
site.
A
Obviously
that's
a
security
concern
in
and
of
itself,
because
you
know
if
it's
not
a
well-known,
well-maintained
source
that
can
open
holes
for
vulnerabilities
that
are
not
covered
or
not
reported.
So
you
know
it's
also
really
common
for
them
to
be
need
to
generate
this
broad
list
of
everything
that's
being
pulled
into
their
project
or
into
their
image.
A
So
those
are
really
the
two
pieces
of
functionality
that
we
show
on
the
project
level
and
the
ideal
state
would
be
to
show
all
of
these.
These
two
views
the
dependency
list
and
the
vulnerability
report
on
the
registry
as
well.
So
that's
the
demo.
Let
me
go
back
through
your
questions.
Let's
see
what
questions
yeah,
but
which
ones
did
I
not
cover
yet.
B
A
Yeah,
so
a
container
image
has
a
bunch
of
packages
installed
like
via
the
app
or
the
yum
package
manager
or
okay
apk,
depending
on
which
operating
system.
It
is,
if
you're
familiar
with
those
package
managers
at
all
yep
yep.
So
all
of
those
packages
that
are
installed
would
be
listed
out
in
that
dependency
list.
A
B
B
A
To
certify
and
say
you
know,
our
container
image
is
secure,
and
part
of
that
is
proving
that
you're
at
least
aware
of
all
of
the
things
that
are
installed
on
that
image,
because
yeah
you're
not
aware
of
it
like
step,
one
is
even
just
being
aware
of
what's
installed,
you
know,
let
alone
like
making
sure
that
the
upstream
sources
are
secure,
and
so
you
know
producing.
That
list
is
kind
of
like
the
most
basic
mvc
step
that
most
organizations
could
take
to
proving
that
they're
in
control
of
what's
installed
on
that
image.
B
B
Oh,
I
should
really
do
something
about
that,
and
but
it
kind
of
sounds
like
if
that
image
is
no
longer
really
being
used.
It's
not
a
big
deal
and
the
only
time
that
we
should
really
highly
signal.
The
vulnerabilities
are
for
images
that
are
in
use
at
the
moment,
and
is
that
kind
of
like
in
line?
Is
that
a
correct
understanding.
A
Use
you
really
have
to
be
in
the
production
environment
which
we
actually
just
released
a
feature
in
alpha
that
lets
us
do
container
image
scanning
in
a
production
environment
as
well.
I
think,
on
the
vulnerability
report,
you
saw
that
development,
vulnerabilities
and
operational
vulnerabilities
tab
that
operational
vulnerabilities
tab
is
everything
coming
back
from
their
production
environment,
so
we
actually
are
able
to
scan
and
report
on.
A
What's
in
use
quote
unquote
today,
but
part
of
locking
down
a
production,
kubernetes
environment,
you
know,
if
you're
really
securing
it
well,
you
will
put
a
rule
in
place
so
that
you
can
only
pull
images
into
that
kubernetes
environment
from
a
specific
registry,
and
then
the
attention
shifts
from
okay.
Let's
make
sure
everything
in
production
is
secure
to.
Let's
make
sure
everything
in
this
registry
is
secure,
so
that
there
is,
you
know,
there's
nothing
vulnerable
here
that
could
be
pulled
in
to
production.
A
B
Yeah,
I
I
get
what
you're
saying
I
guess
it's
just
how
much
precedent
should
it
take
on
the
ui,
because
I'm
imagining
if
every
single
thing
in
the
registry,
it's
got
a
red
badge
on
it.
It
might
be
quite
stressful.
But
if
my
organization
is
like
not
very
high
security
or
just
has
a
bunch
of
old
stuff
in
there,
it
could
be
quite
it
kind
of
like
you
don't
want
to
create
noise,
because
when
there
is
a
vulnerability
that
they
really
need
to
do
something
about,
we
want
them
to
pay
attention
to
it.
A
A
B
Yeah
we
have
this
design
concept
for
a
future
version.
That's
probably
not
going
to
align,
but
just
for
context
of
people
often
visit
the
ui
to
see
that
an
image
or
a
tag
published
correctly
and
at
the
moment
we
have
this
big
list
of
image
repositories
and
you
actually
need
to
click
in
to
see
the
tag
and
I'm
kind
of
thinking
like
if
we
have
this
section
for
like
recent
activity.
B
If
one
of
those
recent
ones
has
a
vulnerability,
you're,
probably
going
to
care
and
so
yeah
I'm
imagining
like
maybe
a
future
version,
we
could.
I
think,
people
mostly
care
about
the
tags
published
most
recently,
and
so
if
we
could
like
bubble
that
up
in
some
way,
but
obviously
that
wouldn't
be
for
the
mvc.
A
A
A
You
ask:
will
we
be
like
signaling
these
in
any
other
way,
so
eventually
we'd
like
to
have
some
sort
of
alerting
mechanism
for
new
vulnerabilities
that
are
discovered
and
that's
even
further
down
the
priority
list
than
this,
but
you
know
sending
them
an
email
notification
or
perhaps
even
a
notification
inside
of
gitlab,
we
actually
have
a
whole
security
alert
dashboard
that
we've
built
out
in
gitlab
as
well.
That
does
not
do
alerts
for
new
vulnerabilities
yet,
but
that's
the
vision
is
to
add
those
in.
A
A
B
A
A
Yeah,
so
big
one
is
merge
requests
because
this
deals
with
stuff.
That's
incoming!
That's
new!
You
know
here
we
highlight
we
did
vulnerabilities,
you
know,
and
this
actually
does
a
differential
comparison
on
the
incoming
branch
versus
the
target
branch.
Universe
is
the
main
branch,
so
these
would
be
new
ones
that
are
introduced.
You
see
it's
all
related
to
this
mariah
db
package
and
if
we
look
at
the
change,
you
know
we're
adding
in
this
new
mariah
db
package,
installing
it
into
their
container
image
and
that
one's
full
of
vulnerabilities.
A
So
you
know
this,
then
triggers
a
vulnerability
check.
It
requires
special
approval
from
a
member
of
the
security
team.
You
know,
whereas
otherwise
it
just
would
need
general
approval
from
like
another
developer,
but
this
actually
wants
it
over
to
the
security
team
to
review
and
sign
off
on
the
new
vulnerabilities
that
are
coming
in.
A
Not
yet
we're
introducing
a
new
security
tab
here
for
the
kubernetes
cluster
itself,
so
that
you
can
see
what
vulnerabilities
are
actually
exist
on
containers
that
are
running
in
production
in
this
kubernetes
cluster,
specifically
right.
Okay,
that
is
being
turned
on
as
we
speak,
it
just
isn't
quite
on
yet
it
looks
like.
B
Yeah
cool
cool
that
makes
sense,
I'm
just
thinking
about
how
to
represent
this
in
the
ui,
so
the
vulnerability
is
actually
attached
to
the
tag,
but
we
could
potentially
show
like
an
amalgamated
view
of
like
this
image.
Repository
has
five
tags
and
two
of
those
tags
have
vulnerabilities,
and
I
was
just
thinking
about
like
where,
where
what
is
the
information
actually
attached
to,
because
it
was
really
interesting.
B
Seeing
that
you
know
the
merge
request
is
a
single
thing
and
the
vulnerability
is
attached
to
the
merge
request,
and
it's
kind
of
I
feel
like
this.
Attaching
it
to
the
image
repository
level
is
actually
just
showing
which
tags
in
that
image
repository
have
which
vulnerabilities
is.
That
is
that
right.
A
A
Yeah
because
our
our
database
schema
doesn't
support
associating
it
with
a
specific
tag.
As
of
yet
and
that's
a
rather
large
change,
so
we're
only
going
to
scan
things
if
there
are
tagged
latest
for
the
first
iteration
and
then,
when
we
add
in
that
new
column,
anything
that's
already
there.
We
can
pre-fill
it
with
latest
and
then
we
can
start
scanning
other
tags
as
well,
but
we
don't
have
a
column
to
store
the
tag
name
as
of
yet
cool
that
makes
sense.
B
Yeah
yeah,
I
was
thinking
about
the
way
I
know
we'll
do
solution
validation,
but
I
was
thinking
the
tag.
Name
might
not
be
sufficient
if
we're
showing
an
amalgamated
view
of
all
image
tags
in
the
image
repository,
I'm
guessing
that
the
user
might
need
more
information,
because
these
names
are
often
like
a
commit
sha
and
they
might
want
to
see
like
when.
Was
it
uploaded
or
or
something
like
that?
Do
you
think
that
that
would
be
possible
to
show
in
the
list
of
vulnerabilities.
A
A
Yeah,
so
I
can
expand
this
out
and
I
can
click
on
any
one
of
these
and
it
pops
up
the
details
for
me
to
review,
and
I
can
create
a
linked
issue
for
this
same
thing.
With
back
there,
I
can
create
an
issue.
I
can
dismiss
the
vulnerability
or,
I
can
add
a
comment
and
dismiss
it.
So
we
have
some
quick
actions
there
in
mind
and
then
I
click
view
full
report
yeah.
I
forgot
to
mention
this.
This
actually
is
on
the
pipeline
view.
A
We
have
a
tab
called
security
for
each
pipeline.
That
gets
run
so
you
can
go
to
ci
cd
pipelines
and
then
there's
a
security
tab
and
again
you
know
you
can
filter
by
severity
and
tool
and
we
have
a
bunch
of
different.
You
know.
Actions
here
dismiss
vulnerability,
create
issue,
get
more
information,
same
thing
kind
of
this
bulk
select,
so
really
we
would
just
be.
Taking
this
same,
I
think
we've
worked
to
make
this
mostly
a
reusable
component
and
we
would
be
popping
it
in
under
a
security
tab
somewhere
in
the
registry.
B
Yeah,
so
I
can
imagine
the
security
tab,
so
I'm
in
the
container
registry.
I
click
on
one
of
the
image
repositories
that
has
a
security
tab
that
shows
all
the
vulnerabilities
for
all
the
tags.
Eventually,
I
know
not
for
the
mvc
and
then
has
these
kind
of
bulk
actions,
and
then
I
can
also
switch
back
to
the
list
of
all
the
image
tags
in
the
repository
click
on
a
tag
and
then
see
only
the
vulnerabilities
associated
with
that
tab
like
that,
could
be
the
like
future
state
of
it.
A
Out
of
all
of
my
whole
registry,
I
want
to
know
where
log4j
exists,
because
I've
been
tasked
with
a
mandate
to
purge.
You
know
make
sure
that
everything
is
off
log
for
j
2.0.2
and
go
up
to
2.0.3.
I
don't
remember
the
exact
versions
of
the
vulnerability,
but
I
need
to
like
that's
my
job
for
the
day
is
making
sure
that
log4j
is
gone
from
our
container
registry,
so
in
that
case
you
would
actually
want
something
at
this
top
level.
A
A
You
know
mostly
looking
for
criticals
and
some
at
highs
to
see,
like
you
said,
if
you
know,
for
anything,
that's
actually
being
used,
are
there
criticals
and
highs
in
those?
You
know,
images
that
are
used,
so
you
want
to
see
it
at
this
high
level,
but
then
you
also
want
to
drill
in
and
drill
in
and
drill
in
to
view
it
at
you
know
various
points.
B
Yeah,
that's
a
really
interesting
point.
I
don't
think
camilla
camilla's
yet
accounted
for
that
top
level.
Everything
in
the
container
registry
view,
and
but
I
do
see
that
actually
is
super
helpful
because
looking
at
the
designs,
it's
kind
of
like
each
thing's
had
many
vulnerabilities
and
that's
quite
a
lot
of
admin,
but
I
might
just
actually
care
about
the
critical
ones
for
the
entire
registry.
So
it
would
prevent
me
from
having
to
go
into
each
image
repository
and
that
might
be
like
the
most
useful
view.
A
B
Yeah
my
hunch
is
like
that
aggregate
view
is
probably
the
most
useful
one
and
because
yeah
there
are
quite
some
users
that
have
lots
and
lots
and
lots
of
image
repositories.
So
it
would
just
be
quite
a
lot
of
manual
admin
now,
knowing
now
understanding
that
this
is
going
to
be
quite
a
common
thing
and
that
it's
likely
that
every
every
image
repository
will
have
vulnerabilities
and
yeah
it's
kind
of
like.
I
actually
just
need
to
know.
B
A
If
we're
just
showing
aggregate
vulnerabilities
that
is
going
to
be
problematic,
I
mean
I
like
what
we're
doing
here.
You
know
in
the
merge
request,
one
critical
one
high
and
then
20
others.
I
mean
that's
generally
what
peop,
how
people
think
about
it
too
they're
like
okay,
how
many
criticals,
how
many
highs
and
then
everything
else,
just
sort
of
sort
of
gets
bucketed
into
this.
Like,
oh,
okay,
that's
nice!
You
know,
we've
got
different
vulnerabilities,
I'm
not
going
to
worry
about
them!.
B
Yeah,
I
love
that
actually
I'm
imagining
like
on
the
container
registry
page.
We
just
had
some
kind
of
in
the
top
of
the
page
or
something
we
had
something
similar
to
that,
and
then
you
can
view
all
of
them
for
in
aggregate
and
then
only
showing
on
the
list
of
the
individual
image
repositories.
If
the
image
repository
has
a
critical
or
high,
we
would
show
that
we
would
show
that
number
and
if
it
has
like
a
low,
maybe
we
don't
show
it
just
so.
The
user
can
kind
of
focus
on
what's
important.
A
Yeah
for
sure,
and
also
worth
noting,
like
on
this
vulnerability
report
page,
we
do
also
have
this
like
summary
of
how
many
vulnerabilities
for
each
this.
Actually
it's
a
little
bit
counter-intuitive
we're
working
through
the
design
on
this
having
a
lot
of
design
discussions
about
this
right
now
in
secure,
but
these
numbers
do
actually
update
when
you
change
these
down
here
as
well.
So
if
I
filter
just
by
critical,
you
see
all
those
go
away,
it
is
a
little.
A
B
Yeah,
I
feel
like
it's
a
bit
heavy,
because
the
point
of
the
container
registry
page
is
not
vulnerabilities,
but
I
think
a
similar
thing
to
what
you
showed
me
on
the
merge
request
would
be
awesome
just
like
a
count
of
the
most
important
ones
and
then
on
the
table
list,
showing
that
this
image
repository
has
got
a
critical.
You
need
to
investigate
it,
especially
if
it's
at
the
top
of
the
list,
because
it's
published
recently,
you
probably
care
about
that
yeah
and
yeah,
maybe
not
showing
it
on
every
single
image.
Repository.
A
B
Yeah
yeah,
that's
cool.
Oh
that's
really
helpful
to
understand
just
going
through
my
questions,
so
vulnerabilities
will
be
common.
I
saw
that
this
feature
will
be
released
in
six
to
12
months.
I
think
that
kind
of
resolves
my
question,
because
the
tag
list
is
a
unsorted
list
at
the
moment,
but
it
will
be
sortable
soon
and
and
yeah.
B
I
think
that's
really
important
for
this
work,
because
you
probably
care
most
about
the
ones
that
were
published
recently
and
at
the
moment
they
just
come
in
in
any
old
order
and
let's
see
the
risks
of
having
this
on
by
default.
Like
other
performance
concerns
any
I
I
would
love
to
have
features
enabled
by
default.
I
just
want
to
make
sure
that
it's
not
going
to
harm
the
user
experience
in
any
way.
A
A
We're
hoping
to
do
this
in
a
way
that
it
is
that
it
has
good
performance,
and
we
would
definitely
need
to
prove
that
out
before
we
switched
it
to
default
on.
So
we
believe
you
know
we
hypothesize
that
we've
got
a
good
engineering
solution
that
will
provide
decent
performance,
but
we're
not
going
to
really
know
that
for
certain
until
we
actually
go
down
the
path
of
implementing
it.
B
B
But
I
think
that
we
can
just
kind
of
figure
that
out
in
solution,
validation
and
maybe
adjusting
the
designs
that
I've
seen
to
highlight
the
severe
warnings
on
the
container
registry
like
main
page
just
so
that
the
main
point
of
that
page
is
like.
I
can
find
the
image
repository
that
I'm
looking
for
and
it's
and
if
there's
a
security
issue,
I
can
get
a
heads
up,
but
it's
not
like
the
main,
the
main
focus
of
the
page
yeah.
That
makes
sense.
A
B
A
And
yeah
and
many
of
these
users
are
going
to
be
like
if
they're
coming
over
to
a
security
tab,
they're,
probably
on
the
security
team.
You
know
familiar
already
with
our
vulnerability
list
that
we
have
in
gitlab,
because
most
security
teams
are
already
using
that.
So
as
long
as
we
keep
the
experience
consistent
between
the
two,
it's
not
going
to
be
entirely
new
for
them,
it'll
be
a
pretty
learning
curve.
B
A
We
believe
a
big
part
of
our
value
statement
is
shifting
security
left,
so
we
intentionally
make
this
visible
to
all
of
the
developers,
because
the
developers
are
the
ones
that
are
coding
it
up
and
they're
the
ones
ultimately
that
have
to
resolve
these
things.
So,
even
though
you've
got
a
security
team
going
through
and
triaging
them
and
commenting
on
them,
it
ultimately
gets
kicked
back
to
the
developers
anyway,
so
it
100
percent
makes
sense
for
them
to
see
it.
Really.
Anyone
with
developer
or
higher
permissions
is
able
to
see
anything
in
the
vulnerability
report.
B
B
A
Sure
that
you
know
you
wouldn't
want,
like
external
users
coming
in
and
dismissing
vulnerabilities,
for
example.
That
would
be
problematic.
In
fact
them
even
just
seeing
them
could
potentially
be
problematic
if
you're
ready
to
disclose
it
yeah,
but
that's
pretty
easy
to
gate
on.
You
know
with
the
licenses
that
we
have
cool
that
makes.