►
From YouTube: Threat Insights Weekly Group Discussion
Description
Weekly meeting for the Secure:Threat Insights group.
A
B
A
C
A
One's
more
of
an
audit
right
and
I
think
the
outcome
of
the
second
issue.
Maybe
we
would
jump
right
to
that
one,
because
it's
a
little
bit
more
simple.
So
on
the
agenda
issue,
3b
auditor
user
can
access
all
vulnerability
management
features.
Matt
wrote
this
in
a
way
that
looks
to
me
more
like
an
audit.
I
had
considered
taking
this
on
myself,
but
I
haven't
had
the
bandwidth.
I
would
have
been
something
that
I
would
really
like
to
have.
You
know
gone
through
the
process
of,
but
instead
we're
gonna
put
it
through
our.
C
D
A
B
I
worked
on
something
similar.
I
think
it
was
on
this
milestone
on
or
the
previous
mouse
on.
The
auditor
user
could
dismiss
at
least
from
the
front
end.
They
could
dismiss
vulnerability
and
then
the
back
end
would
block
it
because
there
was
no
access,
but
it
was
pretty
straightforward.
The
implementation,
so
I
think
it's
going
to
be
the
same.
You'll
probably
have
a
few
places
where
a
user
can
admin.
The
vulnerability
so
should
be.
I
haven't
checked
the
the
issue
in
detail,
but
it
should
be
straightforward.
A
It
sounds
like
again
with
refinement.
We've
talked
about
how
it's
the
case,
where
one
person
might
think
something
is
very
straightforward
for
it,
and
the
other
person
sees
hidden
complications.
This
is
why
we
go
through
refinement,
so
let's
not
get
caught
up
in
solutioning
and
just
think
about
it
in
terms
of
planning
breakdown,
so
approaching
this
in
the
way
that
matt
wrote
it.
This
is
an
audit
right.
What
would
come
out
of
this
would
be
a
set
of
issues.
A
You
can
see
this
column
over
the
right
that
says
implementation
issue
right
so
once
the
status
is
verified.
If
that
status
isn't
what
we
expect,
we
create
an
implementation
issue.
So,
given
that,
do
you
think
that
this
can
go
past
planning
breakdown
and
move
on
to
refinement,
and
then,
if
not,
you
have
any
questions
about
it.
A
C
B
Yeah,
okay,
I
was
trying
to
immute
myself
so
the
okay,
this
table
on
the
right
side.
We
have
the
implementation
issue.
It
means
that
we
have
to
check
that
part
like
the
area
and
then,
for
instance,
if
I
look
at
at
the
table,
I
see
project
vulnerability,
report
the
functionality
and
then
current
status,
not
accessible
status
verified.
No,
so
we
we
verify
that
if
there
is
something,
if
there
is
the
expectation
is
not
met,
then
we
created
an
implementation
issue.
This
issue
is
about
that
right.
That's
correct!.
B
C
A
C
A
C
C
A
D
A
C
I,
for
I
I
no,
I
think
I
just
was
not
thinking
clear,
because
I
was
thinking.
Why
would
the
auditor
be
able
to
add
projects
to
a
user
security
dashboard?
It's
like
that's.
That
was
not
the
case.
The
otter
is
supposed
to
be
able
to
add
projects
to
the
auditor's
security
dashboard
to
do
read-only.
It's.
B
A
C
B
Yeah,
in
my
case
like
it,
would
be
nice
to
to
specify
the
the
expectation
as
soon
as
we
have
that.
Yes,
it's
good
for
refinement
or
actually
do.
We
need
to
refine
this
issue
because,
from
my
understanding
we
have
to
check
one
by
one
and
then
create
so
this
is
like
an
epic,
oh
yeah,
that's
what
we
mean
by
the
refinement,
create
the
implementation
issues.
Okay,.
D
A
Yeah,
that's
a
little
questionable
based
on
our
planning
instructions,
whether
we
mean
so
once.
In
my
opinion,
the
implementation
issues
are
created
during
planning
breakdown
right,
we
get
through
this
discussion
and
we
say:
okay,
we're
ready
to
break
it
down.
We
sign
it
up
to
dris
for
the
front
center
back
end.
If
it's
big
enough
and
it
needs
that
and
then
once
those
implementation
issues
are
created,
then
they
get
assigned
off
to
refinement.
So
I
consider
the
breakdown
of
implementation
issues,
part
of
planning
breakdown,
if
you
are
on
container
security
and
you're
working
with
sam.
A
He
moves
things
over
to
refinement
right
at
this
moment,
so
there's
kind
of
a
fuzzy
line
there,
but
we
get
the
general
idea
quick
question,
though
we
do
skip
refinement.
Can
you
guys
confirm
this?
This
is
something
that
can
be
done
by
anyone
front
end
or
back
end
right.
This
isn't
the
front
center
back
end
specific
audit
right.
C
A
D
A
And
I
don't
think
there
would
be
implementation
issues
to
your
point
savash.
You
know.
I
think
that
this
kind
of
skips
over
implementation
issues,
because
the
outcome
of
this
audit
would
be
implementation
issues.
It's
not
like
there's
going
to
be
a
a
breakdown
of
this
beyond
what
it
already
is
right.
Does
that
make.
B
B
A
Issue,
though,
right
the
work
of
this
issue,
when
you
pick
it
up-
and
you
say-
I'm
assigning
it
to
myself
and
I'm
working
on
it,
it
would
be
to
go
through
all
of
these
rows
on
this
table
and
say:
is
the
auditor
access
what
I
expect
it
to
be?
Yes,
okay,
move
on
no
create
an
implementation
issue,
and
that
would
be
the
implementation
issue
creation.
A
A
A
C
A
C
I
think
I
had
one
question
about
it
go
ahead,
but
I
I
think
it
got
answered
further
down,
but
like
so
when
we,
when
we
do
the
auto
resolve
like
we
like
it,
just
puts
in
there
as
auto
resolve
as
the
resolution
right
there's.
No
other
user
input
that
goes
is
going
to
go
in
because
we
were
talking
about
how
we
were
going
to
annotate
resolutions
at
one
point
too
right.
A
C
B
C
C
But
like
do
we
want
the
users
to
say:
hey,
oh,
hey,
yeah!
This
did
get
resolved
because
there
was
an
open
issue,
we're
going
to
automatically
close
any
issues
that
were
resolved
that
were
open
for
the
vulnerabilities
once
you
get
result
or
it
gets
resolved
because
it
might
be
resolved
from
another
issue.
C
C
Kind
of
see
an
answer
to
it
in
the
workflow
preferences
auto-resolving
into
auto-resolving.
A
vulnerability
with
an
open
issue
could
lead
to
a
communication
disconnect
between
the
person
working
planning,
the
work
on
the
vulnerability
and
the
vulnerability
itself.
We
should
work
to
understand.
Oh,
we
should
work
to
understand
the
desired
behavior
so
yeah,
so
we
have
to
figure
that
part
out.
That's
that's
part.
D
A
So
I
guess
I'm
suggesting
that
maybe
we
could
go
through
this
at
a
high
level,
but
if
you
guys
have
a
bunch
of
questions
on
the
requirements,
I
think
we
need
matt
here
I
mean
andy's
still
out
on
paternity
leave,
so
he
won't
be
here
to
answer
either.
Do
you
guys
think
it's
valuable
to
go
through
this
now
or
do
you
want
to
wait?
A
A
Agreement,
I
was,
I
was
saying
that
in
a
very
pointed
way
like
this
doesn't
make
it.
So,
let's
go
back
to
the
agenda,
then
I
I
added
one
item
under
other
discussions.
So,
as
you
guys
saw
in
our
select
channel,
we
have
completed
the
generic
security
report.
Schema
implementation,
I'm
very
excited
about
that
testing
is
hard.
Testing
is
hard
for
a
number
of
reasons,
one
because
we
don't
have
people
that
are
actually
actively
using
this
new
schema.
We
don't
have
good
data,
that's
coming.
That
represents
all
of
these
elements.
A
Thankfully
thiago
was
able
to
set
up
the
test
data.
I
just
saw
this
this
morning.
So
in
response
to
this
request
that
I
had
linked
to
here,
he
manipulated
the
scan
results
for
the
test
project
to
add
the
data.
I've
got
some
concerns
that
he's
adding
the
data
as
he
thinks
it
should
look,
not
how
you
know
I
feel
like.
Maybe
we
need
someone
from
the
scanner
teams,
I'm
not
sure
who
should
confirm
that
that
data
is
what
we
would
expect
to
get
from
a
scanner
that
implements
this.
A
But
thiago
is
very
knowledgeable
and
he's
read
through
this,
and
at
least
it
gives
us
something
to
test
with
which
leaves
left
me
with
the
outstanding
question
of
testing
the
ski,
the
validation
so
in
the
generic
security
airport
schema
an
issue
kind
of
got
snuck
in
around
schema
validation,
and
I
was
talking
to
matt
about
this
the
other
day.
I'm
not
sure
if
anyone
on
this
call
worked
on
that,
but
this
isn't
specific
to
just
the
generic
security
report
schema.
I
think
it's
doing
validation
at
a
larger
level.
The
json
schema
validation.
A
A
Okay,
so
I
think
we
might
have
to
leave
this
one
for
now
as
well.
So
this
is
a
good
opportunity
for
me
to
say
good
job
everybody.
I
mean
it's
really
exciting
that
we've
made
it
through
this,
hopefully
it'll
get
used.
I
know
it's
already
being
used
by
some
of
the
scanner
teams.
Certain
elements,
so
I
think
the
das
team
is
starting
to
use
the
the
diff
view
or
the
like.
The
named
list
data
type,
but
the
the
vision
is,
is
that
third-party
scanners
can
be
introduced
very
easily.
A
The
hope
is
is
that
other
gitlab
scanners
will
adhere
more
to
using
this
as
well.
I
had
a
question
around
metrics.
I
don't
know.
Maybe
this
is
a
question
you
guys
can
answer
for
me.
Do
we
get
any
data
out
of
the
box
just
from
api
calls?
Could
I
mean?
Is
it
possible
to
look
at
at
any
data
as
a
result
of
like
how
often
this
validation
is
failing
or
anything
without
instrumenting?
It.
B
C
A
C
D
A
C
D
B
A
Than
just
bombing
and
it's
going
to
handle
that
gracefully,
like
you
said
so,
there
might
be
some
some
instrumentation
in
the
code
just
to
log
and
capture
that
information,
in
addition
to
the
work
in
the
grafana
or
or
wherever
to
query
it,
okay,
cool
perfect!
Thank
you
very
much.
Matt
has
the
last
agenda
item
here
and
he's
not
here.
Sebastian
you've
already
responded.
Do
you
want
to
go
ahead
and
verbalize
this
for
the
call.