►
From YouTube: Threat Management Team: Office Hours
Description
Open office hours for topics related to Threat Management groups - Secure:Threat Insights & Protect:Container Security
A
B
C
B
I'm
working
lately
with
the
abstract
team
on
integrating
more
general
abilities
in
the
dashboard,
meaning
we
want
to
have
the
dashboard
of
a
single
source
of
truth
for
everything
that
comes
to
vulnerability
management,
which
is
extremely
good
news
for
dog
footing
as
much
as
we
can.
The
only
problem
is
we
can't
import
or
integrate
vulnerabilities
outside
of
what
the
analyzers
are
reporting.
So
we
started
to
develop
a
fake
analyzer
that
would
import
some
vulnerabilities
directly
into
the
into
the
dashboard.
B
It's
kind
of
working
we're
eating
a
lot
of
words
in
that
process
and
the
last
one
was
this
morning.
So
I
wanted
to
make
sure
that
you
had
that
in
mind,
because
that
was
absolutely
not
of
use
for
me
and
I've
been
there
for
almost
three
years.
So
that's
a
bit
disturbing,
you
know,
so
we
have
this.
Yes,.
A
So
this
is
the
process
that
you
and
I
have
been
talking
about
on
our
one-on-ones
or
you're
kind
of
faking
they're,
not
faking
the
results
but
you're
forcing
these
results
to
show
up
in
the
dashboard
by
creating
the
json
results
that
look
like
our
normal
scanners,
but
they
just
get
taken
in
we
I
know
in
our
roadmap,
we've
got
the
issue
around
creating
manually,
creating
a
vulnerability
based
on
my
conversations
for
you,
I'm
not
sure
if
that
meets
the
need,
though,
because
it's
one
issue
at
a
time.
B
Yeah,
so
that
that's
the
first
one
it's
it's
not
great,
because
it's
really
hard
to
do
working
sports
with
that,
and
the
second
point
that
is
not
going
to
work
for
us
is
the
the
approval
process.
There
is
absolutely
no
control
on
who
can
create
vulnerabilities
and
there
is
no
review.
There
is
nothing
like
this.
The
problem
is,
if
you
start
creating
a
vulnerability
with
this
ui
and
there
is
no
edit
name.
I
would
like
to
remind
you
that
there
is
no
edit
inside
for
now.
B
So
if
you
do
any
mistake
in
that
process,
then
it's
it's
there.
In
the
dashboard
sitting
there
we
can't
really
remove
reliabilities,
because
there's
nothing
in
the
ui,
nothing
in
the
api.
For
that
you
can't
edit.
You
can't
update
this
vendor
again,
so
we
don't
have
the
ability
to
have
a
second
pair
of
eye,
maybe
by
sharing
the
screen
that
that
seems
very
inefficient.
B
So
we
came
up
with
this
idea
of
having
vulnerabilities
as
yaml
files
directly
where
we
define
what
we
want.
There
are
two.
Let
me
make
my
from
bigger,
maybe
two
fields
that
are
going
to
disappear
this
week.
This
category
is
going
to
be
removed
because
it's
completely
redundant
with
the
category
of
the
report
and
the
cd
as
well.
It's
apparently
deprecated,
but
not
that
much.
B
Actually,
if
you
don't
have
a
unique
string
in
this
field,
if
you
dismiss
one
of
the
vulnerabilities
right,
all
the
properties
with
the
same
cve
are
going
to
be
dismissed,
dismissed
as
well.
B
B
Exactly
but
as
of
today,
that's
that's
the
case,
so
I
need
to
change
that
and
I
want
to
generate
something
for
the
users
instead,
so
hey
great
good
to
see
you.
Where
was
I
oh.
B
Yeah
absolutely
so
this
is
this
is
where
we
are
and
with
that
we
we
have
a
complete
process
where
we
can
completely
go
through
all
the
layers
of
of
a
workflow
meaning.
If
I
want
to
add
a
new
vulnerability,
I
need
to
add
a
new
file
in
this
repo.
I
can't
merge
that
into
master
without
the
approval
of
someone
else
in
the
team,
so
that
means
I
have
always
the
second
pair
of
eyes,
and
I
have
someone
else
pressing
the
merge
button.
So
the
process
is
auditable.
B
It's
trackable,
it's
approvable,
it's
everythingable
that
you
can
imagine.
So
that's
that's
a
bit
more
adapted
to
our
to
our
needs
in
the
at
least
in
the
abstract
team,
and
the
result
is
obviously
that
in
the
dashboard
you
have,
technology
is
imported,
like
any
other
vulnerability
generated
by
any
other
analyzer.
A
I'm
sorry
how
much
development
work
would
help
with
this
bulk
import
process
that
you've
been
spearheading
for
absec.
You
know
the
you're
saying
that
there's
problems
with
it
that
you're
working
through,
where
can
threat
insights,
help
you.
B
The
problem
that
I
have
today
so
there
is
just
let
me
share
one
bug
that
I
just
discovered
before
this
meeting.
You
know-
and
I
know
the
the
chief
bug
officer
this
company,
the
cbo-
that's
funny
see
here
in
this
pipeline.
I
don't
have
any
even
a
bit
reported,
that's
actually
because
they
are
dismissed
and
that's
the
bug
that
we
were
talking
about.
I
have
dismissed
this
one
last
week
at
5
39
and
if
you
take
a
look
at
this
one
which
is
different,
I
haven't
done
anything.
B
A
A
B
C
A
It's
kind
of
the
opposite
of
what
you're
describing
for,
though,
where
things
are
tied
together
by
one
identifier,
so
you
make
a
change
to
one
thing
and
it
impacts
this
other
thing
over
here.
These
should
have
the
same
identifiers,
so
they
don't
have
that
relationship
that
you're
expecting.
So
they
must
not.
Do
you
have
a
have
you
create?
I
know
you,
we
ask
you
this
all
the
time,
and
I
appreciate
that
you
do
create
such
good
issues
for
us.
Have
you
created
a
bug
for
anyone
to
dig
into.
A
I
would
volunteer
to
help
out,
but
you're
gonna
put
such
better
information
in
it
than
I
could
so
you
know
I
I
think
this
is
one
that
we
need
to
triage
and
actually
look
at
the
data
records.
I
get
a
little
bit
lost
in,
what's
getting
impacted
by
the
improvements
that
the
back-end
team
is
making
for
fingerprinting
and
what's
not.
B
A
One
action
that
I'm
going
to
take
out
of
what
you
just
said
philippe,
is
to
follow
up
with
the
the
need
for
the
bulk
import
and
the
edit
and
make
sure
that
we
have
issues
created
that
we
can
collaborate
on
and
I
can
work
with
matt
if
we
don't
I'll
make
sure
that
we
do
have
them
somewhere,
and
you
haven't
seen
them
that
I
have
mentioned
you
quick
question
about
the
edit,
though,
do
you
see
that
it
would
be
okay
or
appropriate
to
allow
people
to
edit
most
of
the
details?
Or
is
there
a
point?
A
B
B
Membership
would
be
able
to
interact
with
these
vulnerabilities
and
we
absolutely
don't
want
that
in
the
abstract
team.
So
that
means
for
us.
If
anyone
goes
to
the
gitlab
dashboard
and
decide
to
start
these
music
things,
we
absolutely
won't
notice.
I
think
we
were
we're
going
to
be
completely
blind,
so
we're
trying
to
avoid
all
the
interactions
that
would
not
be
in
the
pipeline,
so
that
would
not
be
part
of
the
classic
workflow
with
I'm
changing
something
I
need
someone
to
review.
B
I
need
someone
to
approve,
and
then
it's
merged-
or
at
least
it's
committed
somewhere.
So
for
us
the
best-
and
I
know
that's
not
exactly
the
direction
that
you're
taking,
but
the
best
would
be
to
have
the
ability
to
change
that
directly
from
the
file
so
not
having
an
ability
to
edit
that's
not
directly
from
the
ui.
But
if
I
change
something
here
and
I
decide
that
it's
not
the
right
cv
here,
it's
not
one
two,
three
four,
it's
one
two
three
five.
A
B
C
B
Is
to
have
everything
approved
and
merged
at
this
point.
So
if
I
change
something
in
here,
I
can't
push
that
to
master
directly,
because
I
need
someone
else
to
approve
this
change.
So
we
are
in
this
process
of
reviewing
approving
committing
again
and
we
need
to
go
through
all
these
layers
to
be
compliant
and
we're
absolutely
not
compliant
as
of
today,
because
again,
if
you
just
if
it's
a
point
and
click-
and
I
can
just
edit
the
file
and
or
or
just
click
on
the
vulnerability
in
the
in
the
dashboard.
A
B
It
could
be
something
else
but
see,
for
example,
if
I
click
on
the
vulnerability
and
I'm
I'm
the
developer
in
this
project.
If
I
can
change
the
severity
here
from
something
critical
to
something
low
or
maybe
even
unknown,
that
could
go
really
under
the
radar
and
we
would
have
no
id
in
the
absent
team.
That's
that
is
I'm
sorry
for
the
strong
warning,
but
that's
unacceptable
for
us.
B
B
There
could
be
someone
in
the
process
interfering
with
that
and
we've
seen
that
in
the
past
we've
seen
that
people
even
outside
of
engineering
were
just
demoing,
the
dashboard,
the
gitlab
dashboard,
and
they
were
randomly
clicking
on
issues
and
dismissing
them.
We
have
no
idea
and
there's
no
track.
I
I
created.
B
B
An
issue
I
did
track
security
tracker
there's
an
issue.
I
can
complete
that.
A
B
I
had
some
other
topics
with
my
don't
worry
more
than
enough
to
talk
with
matt,
so
any
any
questions
or
any
comments
on
on
this
before
you
move
on
to
the
next.
A
You
guys
asked
all
mine
wayne:
do
you
have
any
okay
right?
Thank
you.
I.
I
know
that
a
lot
of
this
feels
like
you're
having
to
repeat
yourself
philippe
you
know.
A
lot
of
your
observations
span,
various
problems
that
we're
aware
of,
and
it's
hard
to
make
sure
that
we're
not
missing
new
areas
that
we
need
to
make
sure
that
we're
putting
attention
to
by
glossing
over
some
of
the
like.
Well,
hey,
that's
just
fingerprinting!
B
Just
to
make
sure
so
you're
aware
of
that
to
wrap
up
on
this
topic,
so
we're
using
the
common
library
to
generate
the
reports,
which
is
apparently
atrocious.
B
If
you
listen
to
the
secure
team,
I
have
no
idea
why,
but
I
understand
this
morning
because
the
I
thought
the
common
library
was
the
single
source
of
proofs
and
that's
not
actually
the
case.
The
json
schemas
are
defining
what
they
call
the
common
format.
So
that
was
confusing
to
me
and
again,
I've
been
kicked
out
for
a
while.
So
imagine
someone
that
is
coming
from
the
outside.
B
That
means
we
don't
have
a
library
that
user
could
use
to
could
integrate
or
could
import
to
generate
reports
with
git
lab.
They
have
to
deal
with
the
json
schemas
and
that's
it.
So
that's
that's
an
okay
limitation,
but
you
need
to
be
aware
of
that,
and
I
was
absolutely
not
aware
of
that.
A
C
B
That
is
what
defines
exactly
what
is
the
the
expected
format
for
the
reports,
so
you
have
here
everything.
So
if
you
want
to
do
something
with
das,
for
example,
it's
all
defined
in
there
and
you
have
to
follow
these
requirements
in
order
to
generate
a
report
that
will
be
passed
and
integrated
into
the
db.
B
So
there
is
no
api.
There
is
no,
when
I
say
api,
it's
not
a
web
endpoint,
it's
an
api
from
the
code
like
in
go
or
python
or
not.
Yes,
we
have
something
that
is
close
enough
called
the
common
format
which
is
go
defining.
What
is
a
report,
so
that's
exactly
what
I'm
using,
because
that's
a
great
way
for
me.
B
B
You
need
to
have
a
category.
You
need
to
have
a
name.
You
have
to
description,
you
have
this
cv
field
and
you
can
see
it's
deprecated
here,
the
famous
cv,
the
infamous
cv
field.
That
is
there
so
by
using
that
I
can
compile
what
I'm
doing
so.
I
know
that
it's
going
to
work,
but
it's
only
covering
sas
and
dependency
scanning,
and
I
was
not
aware
of
that.
A
A
B
A
B
Yeah
I'll
do
my
best
to
take
a
look
at
that.
I
need
to
find.
A
And
maybe
it's
not
an
action
for
you
felipe
I
mean
I
have
to
wonder
if
you
know
some
of
this,
like,
like
you,
said,
you're
falling
in
line
with
existing
report
schemes,
you're
just
kind
of
you're,
fitting
your
square
peg
into
a
round
pole
trying
to
use
existing
report
schemas.
Maybe
the
individual
scanner
teams
would
be
able
to
also
give
that
verification.
You
know
those
are
the
fields
that
you
need,
or
the
report
fields
that
you
need
they'd
be
able
to
help
us
call
out
when
something's
not
represented
yeah.
Definitely,
no.
B
Sure,
let's
move
on,
if
you
would,
because
we
just
have
a
couple
of
minutes
to
cover
my
second
point
on
make
sure
that
we
at
least
cover.
C
C
A
B
A
A
B
First
part
could
be
important
for
you
because
I
just
helped
that
was
last
week,
some
customers
not
directly
with
the
help
of
some
solutions,
architects.
They
were
dealing
with
exactly
these
kind
of
issues.
They
were
trying
to
create
new
analyzers
and
things
to
import
their
vulnerabilities
and
they
went
exactly
in
the
same
traps
as
I
went
to
the
last
weeks.
B
B
So
my
next
point
there's
no
question
in
there,
but
it's
or
so
far
awareness
we're
going
to
stop
what
we
call
the
security
champions
program
and
I'm
sorry
I
choose.
I
should
have
linked
the
issue.
A
A
A
C
A
For
transparency
and
for
transparency,
that
other
issue
was
the
one
where
the
mr
widget
was
displaying
the
word
new,
which
had
always
been
there,
but
we
highlighted
it
by
adding
colors
to
the
criticality
of
those.
So
your
issue,
what
you
would
the
issue
you're
referring
to
is
close,
is
simply
because
we
removed
the
word
new,
which
we
all
know
isn't
necessarily
solving
the
problem.
It's
just
trying
to
be
less
misleading.
A
And
again,
I
don't
think
the
intention
was
never
to
come
back
to
because
we
have
a
lot
of
other
issues
around
identifying
when
a
vulnerability
is
new
or
not
so.
B
Yeah,
but
I
was
not
sure
that
everyone,
the
good
of
the
view
of
the
problems,
at
least
the
the
blocking
problems
that
we're
seeing
with.
Oh
I'm,
still
sharing
my
screen.
A
Yeah
and
then
correct
me
if
I'm
wrong
felipe
the
way
I
interpreted
this
issue
of
blockers
that
you
created
it's
it's
a
matter
of
matt
looking
through
these
or
you
know
myself
and
thiago
and
matt
looking
through
these
and
identifying
that
the
blockers
are
either
covered
in
another
issue
or
creating
new
issues
to
resolve
them.
This
is
sort
of
a
catch-all
so
far.
B
B
B
We
should
be
able
again
in
the
deterministic
way
to
say
you're
introducing
something
that
is
going
to
be
prominent
right
now,
it's
not
the
case,
because
if
you
wait
too
long,
the
analyzers
are
going
to
be
updated
and
you
are
going
to
get
new
results.
These
new
results
are
going
to
appear
on
the
merch.
B
The
merge
request,
security
widget
is
new,
so
that
means
you
are
introducing
them,
which
is
what
is
confusing
literally
everyone,
and
that's
why
it's
mostly
ignored
today,
because
we
have
these
false
positives
showing
up
in
this
in
this
widget.
So
that's
that's
a
problem,
but
the
blocker
for
us
is
if
we
start
the
security
champions
program.
The
the
goal
of
this
program
we're
aiming
to
reduce
the
number
of
vulnerabilities
that
will
reach
master.
The
the
whole
idea
is
to
ease
the
the
workload
and
the
upsetting.
B
So
we
want
to
have
a
way
to
ensure
that
we
are
not
making
the
situation
worse
than
it
is
by
blocking
very
early
these
vulnerabilities.
That's
why
we
want
to
have
in
every
single
development
team
a
counterpart
of
the
appsec
team
that
will
be
responsible
for
blocking
at
the
merge
request
level,
everything
that
could
reach
master.
B
We
have
the
security
approvals
in
the
merge
request
already,
but
if
we
enable
them,
if
we
start
using
them,
they
will
block
all
the
time
because
of
these
new
findings
like
suddenly,
we
add
something
in
the
gymnasium
db,
it's
something
that
will
show
us
critical
boom.
All
the
merge
requests
today
that
were
created
will
show
you
that
you
have
introduced
something
new,
because
in
yesterday
it
was
not
detected
and
we're
going
to
block
the
merch
because
of
that,
so
how
the
security
champion
will
deal
with
that.
We
have
no
idea.
B
A
C
B
That's
actually
the
role
of
the
app
section,
so
you
have
the
developers
interacting
at
the
merge
quest
level.
They
will
interact
with
this
merge
request,
security,
widget
and
the
security
gates
and
everything
so,
for
example,
this
new
advisory
in
the
jaindismdb
that
I'm
using
as
an
example,
it's
going
to
show
up
in
the
dashboard,
because
in
in
the
pipeline
in
master,
we
have
at
least
one
pipeline
per
day.
B
So
it's
going
to
show
up
in
the
dashboard
and
we
have
an
app
sec
engineer
going
through
the
dashboard
every
day,
going
to
all
the
issues,
one
by
one,
making
sure
that
there
are
triads
and
they
are
fixed
if
it's
something
critical
in
a
timely
manner.
So
that's
why
we
have
this
two
two-step
process,
but
right
now
we
just
do
the
second
step.
B
B
It
or
not,
with
these
approvals
yeah
instead
of
having
100
critical
findings
in
the
dashboard,
we
could
have
just
10..
That's
the
world
point,
because
the
upset
team
is
not
stretching
as
we're
not
growing
as
fast
as
the
the
development
team
is
growing
and
we
have
a
ratio
between
the
number
of
appsec
engineers
and
the
number
of
of
developers
in
the
company
that
is
actually
not
going
in
the
right
direction.
The
trend
is,
is
not
great.
B
We
have
more
and
more
developers
for
less
and
less
absent
engineers,
so
that
means
at
some
points.
We
won't
be
able
to
deal
with
all
different
abilities
that
we
have
in
the
dashboard.
We
need
to
find
ways
to
make
the
work
of
the
upset
team
more
efficient
and
really
focus
on
what
matters
and
that
could
be
avoided.
You
know
if
it's
a
bit
like
we're,
pushing
just
changes
without
any
unit
test,
because
we
know
that
we
have
a
quality
team
and
they
will
catch
up.
They
will
catch
up
everything
anyway.
A
You
know
some
of
the
items
that
you
have
listed
here.
I
know
that
we've
been
discussing
quite
a
bit
are
very
familiar
to
me.
I'm
curious
about
this
bottom
line
around
analyzers,
not
returning
deterministic
results
and
really
that
should
be
something
that
you
know.
The
scanner
teams
are
focused
on
and
not
threat
insights,
because
I
don't
know
how
we
have
any
control
over
that.
A
B
A
A
And
I
don't
think
we
want
to
start
like
faking
it
on
anyone.
You
know
we
don't
want
to
start
to
obfuscate
anything
from
the
user,
that's
resulting
from
data
from
the
dashboards.
You
know
to
make
it
look
more
manageable
or
anything
like
that.
So
you
know
those
really
need
to
be
addressed
at
the
root
of
the
problem,
and
I
just
wanted
to
make
sure
that
this
wasn't.
A
You
know
with
a
catch-all
issue
like
this,
that
this
wasn't
the
the
only
place
that
you
and
I
knew
it
wasn't,
but
thanks
for
confirming,
so
I
know
that
matt
has
already
given
you
a
good
amount
of
feedback
on
these
items.
Philippe,
and
I
appreciate
you
sharing
them
with
us
in
greater
detail.
So
I
understand
more
wayne
or
greg.
Do
you
guys
have
any
questions
or
observations
about
that.
D
I
I
do
on
this
one
so
with
the
analyzers
not
returning
deterministic
results.
I
found
network
issues
really
any
any
issues
anywhere
in
the
stack
can
affect
it,
but
also
like
well
I'll
give
an
example.
I
I
ran
an
authenticated
desk
scan
on
a
self-managed
gitlab
instance,
and
I
found
I
kept
having
to
raise
the
timeout
higher
and
higher
and
higher,
and
then
it
would
just
take
forever
and
I
went
in
and
it
turns
out,
the
problem
was,
I
gave
admin
credentials
and
it
kept
turning
on
the
two-factor
authentication
requirement.
D
So
it
would
just
like
das
would
have
that
and
then
it
would
hit
the
login
page
and
it
would
try
and
get
in
again
and
then
it
would
hit
the
login
page,
and
so
I
had
to
like
manually
go
in
while
it
was
hammering
on
this
self-managed
instance
and
disable
like
two-factor
authentication
requirement,
and
there
were
other
things
too,
where
it
would,
it
would
just
get
stuck
in
a
loop
in
certain
scenarios
with
full
scan
and
authentication
of
any
type.
D
It
could
change
something
that
causes
it
to
get
in
a
loop,
but
I
also
found
that
the
end
results
were
mostly
false.
Positives
like
it
was,
it
was
a
lot
of
stuff
that
did
not
actually
seem
to
represent
legit
vulnerabilities,
and
I
did
pass
that
on
to
seth
and,
I
think
cameron,
and
they
they
put
it
in
a
dashboard
and
nothing
came
out
of
it.
So
yeah,
that's
my
insight
on
that.
Usually.
B
That
is
that's.
It
is
a
big
piece
of
cake
for
that
you
can
there.
There
are
two
other
issues
that
you
are
having
with.
You
will
probably
stammering
on
upon
that.
If
you
use
a
gitlab
instance,
the
first.
C
B
We
are
sometimes
generating
some
objects
with
a
random
id.
Imagine
the
to-do
list.
For
example,
if
you
have
dust
running
on
this,
it's
going
to
create
new
to-do's.
If
the
ids
of
the
two-days
are
not
one
two
three
four,
then
it's
going
to
generate
a
new
finding
for
every
new
to-do
that
is
not
compliant.
That
is
vulnerable
to
something
that's
a
new
location.
So
that's
a
new
finding.
So
every
time
you
run
dust,
you
have
more
results
in
the
dashboard,
so
you're
just
going
to
stack
up
everything.
B
The
other
problem
that
we
have
is,
for
example,
and
that's
that's
one
of
the
limitations
of
the
chromecast
implementation.
If
you
have
a
header
problem,
for
example,
there
is
a
problem
with
the
csp
either
missing,
or
that
is
invited.
B
B
A
So
I'm
sure
that
the
secure
team
is
going
to
watch
the
video
of
this
and
take
all
sorts
of
good
information
away
from
it,
but
unfortunately
it
feels
like
we've
ventured
into
an
area
that
we
don't
have
a
lot
of
ownership
over
or
control
over.
So
I
want
to
make
sure
that
you
know
in
the
places
where
we
can
make
improvements
that
we're
aware
of
them.
A
So
I
I
definitely
see
from
this
issue
that
you've
linked
to
here,
philippe
that
there
are
some
of
those
items,
and
I
know
that,
like
I
said
with
the
previous
item,
I
will
confirm
with
matt
that
we
have
issues
that
are
tracking
them
and
that
I
know
your
conversation
with
him
will
continue
on
any
areas
that
he's
not
totally
clear
on.
As
far
as
the
difference
in
point
and
time
goes
in
the
non-productive
way,
I
don't
know
if
we've
gotten
into
that
too
much.
A
Could
you
talk
a
little
bit
more
about
what
your
I
know.
I
know
people
talked
about
like
having
regularly
scheduled
scans
that
keep
these
up
to
date.
Can
you
talk
more
about
what
your
thoughts
are
here?
Fleet.
A
How
we
handle
keeping
these
up
to
date,
like
is
it
a
matter
of
I?
I
guess
I
just
don't
know
what
the
action
here
is.
A
I'm
looking
at
your
issue
and
I'm
looking
at
your
top
bullet
point.
The
reports
are
generated
at
different
points
in
time
and
in
a
non-producable
way
I
mean:
does
this
go
back
to
the
non-deterministic
results,
just
based
on
the
non-productive
way.
B
A
C
A
B
Exactly
and
if
I
run
the
scan
again
in
three
weeks,
I
should
have
the
same
results
which
is
not
guaranteed
today,
because
again
we
are
we're
pulling
the
the
new
organizers
all
the
time,
with
new
rules
and
even
sas
could
be
improved
and
detect
new
things,
and
that
will
show
up
in
the
merge
request
security
widget
as
new,
which
is
not
the
case.
It's
not
new.
It's
just
that
we
are
using
different
root.
Sets.
A
B
A
B
B
A
A
I
apologize
that
I
haven't
been
taking
good
notes.
I
feel
like
it's
taking
all
of
my
energy
right
now
to
comprehend.
All
of
this
information
that
philippe
is
sharing
my
plan
is
to
go
back
through
the
recording
of
this
and
add
some
notes
to
the
document
so
olivier
if
you're
interested
in
my
summary
of
things
or
my
take
on
things
you
can
check
that
later.
But
we
will
share
the
recording
of
this
as
well.
B
A
On
that
note
now
that
olivia's
here
was
there
anything
else.
Olivia's
got
an
item,
you
can
verbalize
as
you're
typing
or
we
can
wait
it's
up
to
you.
E
Yeah,
I'm
sorry
I
wanted
to
join
earlier,
but
I
was
focusing
on
something
else
and
I
tried
to
add
this
threat
management
calendar,
but
it's
still
a
pain
to
try
to
find.
I.
E
B
A
It's
not
in
the
protect
stage
calendar
it's
just
in
the
threat
management
sub
department,
it
might
be
in
the
protect.
Did
I
put
it
everywhere?
Oh,
I
can
add
it
there.
If
I
didn't,
I
should
do
that.
I
should
put
it
in
the
protect
stage
calendar.
I
just
put
it
in
the
threat
management
sub
department
calendar
so
I'll
copy
it
over.
A
E
Okay,
so
in
in
the
meantime,
I
would
like
what
I
I
was
looking
to
share
here,
because
this
is
a
river
event
for
protect
and
threat
management.
E
So
this
is
an
issue
I'm
just
starting
to
share
with
all
the
secure
engineering
managers.
It's
again
it's
a
long-term
topic
being
divided
multiple
times,
but
I
have
a
feeling
that
some
of
the
things
are
like
they're
moving
slowly.
It's
like
we're,
leaving
people
in
muddy
orders,
and
sometimes
some
changes
happen-
that
kind
of
change
the
direction
that
we
head
toward,
but
it's
not
clearly
defined
somewhere.
I
know
we're
still
struggling
to
find
a
good
place
for
technical
documentation
and
some
of
our
guidelines.
E
Our
end
books
might
not
always
be
up
to
date,
at
least
in
securing
position.
That
is,
I
don't
want
to
stop,
while
the
others,
but
at
least
for
me,
I'm
still
having
some
backlog
on
that.
So
the
main
problem
we
have
here
is
a
lot
of
things
that
have
been
sought
with
regard
to
our
development
coding,
wildlife
and
architectures.
E
With
everything
touching,
the
security
analyzer
has
been
defined
at
the
time
we
are
just
one
team
and
what
it
kept
working.
This
way
until
now,
where
we
are
reaching
a
point
where
it's
spanning
across
two
stages
and
two
sub
departments-
and
we
are
constantly-
you
have
been
going
away
and
also
they
tried
to
to
go
through
that
exercise
of
trying
to
better
delineate
the
boundaries
between
the
different
stages,
but
even
within
six
years
itself,
between
the
different
static
and
analysis
teams.
E
E
Assuming
I
mean,
I
don't
know
how
much
we're
involved
into
this
part,
because
it's
mostly
more
backhand
than
front
end
but
yeah
you
will
come.
This
is
just
to
clarify.
This
is
really
about
the
analyzers
tools
and
type
that
the
engine
generating
the
reports
report
content.
This
has
nothing
to
do
with
all
the
variety
management
stuff
and
how
we
are
trying
to
unify
those
different
data
in
in
the
ui
and
the
rarity
management
process.
E
A
Just
a
heads
up
we're
not
part
of
the
at
the
gitlab.org
secure
managers
group.
So
I'm
glad
that
you,
you
mentioned
tiago
directly
in
this.
E
A
No,
no,
it's
okay
and
I,
I
think,
there's
similar
conversations
to
be
had
around
front
end
consistency
and
you
know
I'll
work
with
neil
on
that.
E
C
I
saw
the
issue
and
I
haven't
looked
into
in
much
detail
yet,
but
I
think
I
think
it's
a
great
question.
I
want
to
see
where,
since
tiago's
been
looking
into
it,
I'd
like
to
see
where
he
lands
on
it,
which
he
hasn't,
I
don't
he's
not
seen
it
yet
but
appreciate
olivier
bringing
it
up.
So
we
can
discuss.
A
E
But
if
we
maintain
this
goal
to
have
consistency
in
the
way
we're
using
the
feature
from
a
user
perspective,
that's
perfect,
because
this
is
really
what
we're
looking
for,
because
we
want
this
seamless
experience,
whatever
the
the
security
features
you're
using
if
it's
sas
or
container
scanning,
you
want
them
to
fit
and
behave
the
same
way
being
configured
slightly
the
same
way.
I'd
say
in
the
ui
and
manage
the
rarity
being
managed
the
same
way
in
dui
too.
So.
A
I
would
encourage
you
I'm
curious
how
much
he
was
trying
to
solve
that
same
problem
with
the
creation
of
that
generic
schema,
and
I
know
that
it
was
posed
a
lot
under
sort
of
supporting
third-party
scanners.
But
I
think
the
same
concept
applies
to
our
own
internal
scanners
as
well,
about
adhering
to
a
very
flexible,
yet
well-defined
schema.
I
know
I've
been
looking
at
it
mostly
from
the
front
end
because
it
really
does
help
with
the
display
of
this
information,
but
I'm
not
sure
how
much
of
this
overlaps
with
the
topic
that
you're
presenting
here.
E
Extreme
and
one
boundary
of
it,
the
way
I'm
seeing
this
issue
is
that
today,
we've
defined
boundaries
where
you
have
freedom
or
where
you
need
to
be
consistent,
and
the
thing
is
here:
we
need
to
shift
that
to
a
different
location
and
the
json
schema
is
one
boundary
when
it
comes
to
deal
with
the
output.
So
today,
each
team
has
some
freedom
in
the
way
they
are
generating
the
the
data
and
the
consistency
is
starting
at
the
time
they
are
conforming
with
the
json
schema.
E
The
other
aspect
is
on
the
x
opposite
side,
which
is
dealing
with
the
input
which
is
currently
what
we
have
is
the
command
library
and
the
bundle
template
are
defining
how
the
are
triggering
this
job
or
your
configuration,
how
you
configure
all
those
tools
already
right
now.
Some
of
these
analyzers
have
some
consistency,
some
of
them
don't.
So
that's
why
I
won't
make
sure
and
make
clear
that
this
is
no
longer
necessary
how
we
do
that.
D
So
we
are
at
time,
but
to
top
it
off,
I
do
think
there
is
an
argument
for
consistency
in
terms
of
support
as
well.
I
think
that,
like,
on
the
one
hand,
autonomy
we
can
ship
these
improvements
to
scanners
quicker.
We
can
update
the
rule,
sets
more
quickly.
We
can
ship
the
most
recent
scanner
to
our
customers,
but
when
it
comes
down
to
support-
and
I'm
I'm
doing
a
like
sec
section-
training
module
where
I
go
over
all
the
things,
one
piece
that
keeps
coming
up
is
when
you're
troubleshooting
a
scanner
problem.
D
If
that's
pulling
latest
scanner
images
and
things
like
that-
and
there
is
inconsistency
across
the
group-
it
does
kind
of
make
it
more
difficult.
If,
if
all
the
analyzers
were
to
update
on
a
scheduled
release,
schedule
or
something
where
it
was
consistent,
it
could
make
troubleshooting
a
bit
easier.
But
I
think
for
efficiency,
just
having
autonomy
is
the
best.
E
Yeah,
that's
a
very
good
point
and
I
think
what
you
you
need
maybe
to
to
push
for
in
the
future,
is
to
try
to,
for
example,
maintain
that
level
of
consistency
in
the
way
you
can
debug
or
troubleshoot.
A
good
example
is
whatever
the
type
of
analyzer
you're
dealing
with.
If
you
have
a
problem
and
you
want
debug
output,
you
should
have
just
the
same
variable
to
configure
not
three
or
four
different
ones.
I
think
we've
did
great
so
far.
E
For
example,
the
offline
environment
are
the
the
custom
bundle
certificates,
but
it
was,
but
this
is
where
I
think
it
really
matters
to
keep
that
consistency.
Whatever
the
way
it's
been
implemented
behind
that.
A
A
Sorry
threat,
insights
and
container
security,
so
we
can
reevaluate
that
cadence
and
whether
it
makes
sense
to
have
all
of
the
two
group
topics
and
one
office
hours,
but
thank
you
philippe
and
greg
olivier
for
joining
and
wayne
bye
wayne,
and
I
will
share
the
recording.
Was
there
anything
that
was
shared
today?
If
you
were
doing
some
screen
sharing
and
you
were
showing
some
dashboard
stuff,
I
want
to
make
sure
that,
were
you
sharing
anything
that
I
can't
put
a
video
out
on.
A
Excellent
okay
just
wanted
to
make
sure
so
I'll
share
this
out
on
unfiltered
and,
like
I
said,
I'm
gonna
try
and
go
back
through
and
add
some
notes.
I'm.