►
Description
A discussion mostly centred around https://gitlab.com/gitlab-org/gitlab/-/issues/327141
Chat notes:
00:05:51 Lindsay Kerr - FE EM, Secure & Protect: Apologies for being late, long running 1:1. Thanks for scheduling this Olivier.
00:10:09 Thomas Woodham - Engineering Manager, Secure: https://gitlab.com/gitlab-org/gitlab/-/issues/327141#note_572714485
00:15:44 Thiago Figueiro - BE Mgr., Threat Management: https://gitlab.com/groups/gitlab-org/-/epics/5709#scope
00:28:01 Lindsay Kerr - FE EM, Secure & Protect: https://gitlab.com/gitlab-org/gitlab/-/issues/10272
00:33:43 Thiago Figueiro - BE Mgr., Threat Management: Time check
00:33:47 Thiago Figueiro - BE Mgr., Threat Management: 7 minutes
A
And
I
think
that
why
this
is
technically
true,
because
currently
we
release
the
tools
as
docker
images
that
can
be
used
independently.
They
have
never
been
part
of
the
product
goal
to
sell
them
and
to
release
them
has
standalone
products.
The
only
reason
why
they
exist
is
to
provide
this
information
into
the
gitlab
race
application,
because
we
want
to
provide
users
a
single
application
to
achieve
all
devops
workflows
deficit
customer
pro,
so
maybe
part
of
the
misunderstanding
around.
A
C
C
Now
the
benefit
that
my
team
has
is.
I
can
call
up
thiago
and
be
like
hey.
Can
you
add
this
thing
and
we
can
get
that
in
there
a
little
faster,
but
I
don't
conceptually.
I
think
those
external
vendors
should
be
able
to
integrate
just
as
easily
as
the
das
team
or
the
sas
team,
or
one
of
the
other
teams.
D
Would
I
think
this
is
this
thread
is
coming
from
is
from
this
thread,
and
I
think
specifically
this
note.
I
I
think
mimet
introduced
this
idea
and
we're
accepting
the
premise
regardless,
but
licensing
and
putting
licensing
aside.
Yes,
it's
technically
possible
to
run
them
independently,
but
it
is
against
the,
but
it's
not
what
we're
going
to
build,
and
so
I
I
think
we
can
set
that
aside,
but
there
is
there's
some
education
about
what
we're
building
contractually
what
people
can't
do
that
probably
needs
to
occur.
B
Conversation
piggybacking
on
a
bit
on
what
seth
was
saying
in
terms
of
sorry
lindsey,
any
comments,
no
on
what
seth
was
saying
about
setting
direction.
My
feeling,
since
since
we
started
having
to
to
work
with
the
with
the
schemers,
is
that
some
groups
have
done
more
than
others
in
that
area.
I
know
the
cam
and
fabian
they
take
a
a
special
interest
to
it.
B
So
my
interesting
in
this
part
of
part
of
the
part
of
the
goals
of
the
parent
epic
to
this
issue.
This
issue
came
from
parent
epic,
where
it
says
that
threatening
sites
should
be
the
owner
of
those
analyzer
schemas,
because
if
every
analyzer
is
contributing
with
reports
with
findings
to
the
vulnerability,
vulnerability
management
system
threat,
insights
is
the
group
that
touches
all
of
the
other
groups.
Right
and
and
by
definition,
we
should
have
more
visibility
into
what's
happening
across
all
the
analyzers.
B
It
does
not
mean
that
threatened
sites
is
in
an
ivory
tower
making
decisions
about.
You
know
what
goes
and
what
doesn't
go
in
the
analyzer,
but
it
does
mean
that
we'll
take
a
a
a
much
stronger
position
into
into
pushing
and
making
things
forward.
We
haven't
done
this
type
of
work
before
so.
The
the
the
playing
rules
are
not
quite
there
yet,
particularly
around
deprecation
notices
to
users.
B
How
much
influence
we
can
we
can
exit
on
on
groups.
So
if
we,
if
we
do
something
deprecate,
deprecator
field
and
say,
did
you
need
to
remove
it?
We
have
to
communicate
this
to
all
the
analyzer
groups
and
third
parties,
and
how
long
do
we
give
them
and
what
happens
when
they
don't
do
or
don't
have
time
to
do?
Do
we
break
their
integration?
B
So
all
these
things
are
coming
up
now
and
this
particular
issue
is
sort
of
the
crux
of
that,
because
it's
defining.
How
do
we
version
these
schemers
and
and
what
are
the
ground
rules
here?
Are
we
allowed
to
break
them
whenever
we
want
them,
or
do
we
introduce
how
many
versions
of
backwoods
compatibility
do
we
keep?
B
B
A
It
just
happened
that
by
the
time
we
grow
up,
we
grew
and
transitioned
the
gravity
management
system
into
a
separate
group.
I
think
we
have
not
correctly
under
over
that
historical
knowledge,
and
since
we
don't
have
tons
of
collaboration
between
this
group,
it's
super
difficult
to
get
this
understanding
about
what
has
been
done
in
the
past
in
the
analyzers
and
what
is
our
goal.
A
A
I
came
with
some
proposals
that
I
was
not
able
to
propo
to
to
suggest
into
the
the
staff
meeting
because
we're
running
out
of
time-
and
it
may
need
some
more
discussion
but
nicole
is
trying
to
push
for
those
things
too,
like
having
some
dedicated
people
in
your
team
tiago,
so
that
they
are
only
focusing
on
those
shirts
and
short
topics,
and
those
people
would
get
knowledge
from
each
group,
because
I
think
this
is
mandatory.
This
is
another
key
aspect
of
the
distribution.
A
There
is
that
there
is
a
strong
opinion
that
the
data,
the
schema
format,
has
to
be
driven
by
vms,
because
it's
serving
the
viennas
and
yes,
this
is
true,
but
the
vms
is
also
leaving
because
of
the
data
that
the
security
scanners
providing
provided.
So
there
is
a
very
tight
coupling
that
I
don't
see
how
we
can
get
around.
I
mean
it's
it's
something
that
has
always
to
be
done
in
collaboration
between
this,
these
two
main
areas
and
having
people
that
have
knowledge
about
both
sides.
I
think
it's
the
best
solution
for
this.
C
So
I
I
just
had
a
clarifying
question
when
you're
talking
about
one
schema,
are
you
talking
about
eliminating
right
now,
we've
got
like
a
dash
assassed
a,
but
they
technically
kind
of
come
from
a
schema.
Just
with
addition,
like
I
don't
know,
if
you're
talking
about
like
one
that
would
eliminate
those
distinctions.
B
I
think
I
think
olivia
is
talking
about
the
specific
proposal
from
mavet,
because
he
said
there
are
two
sets
of
schema,
one
that
serves
integration
with
vms
and
that,
if
you
as
an
analyzer,
whether
third
party
or
git,
lab,
want
to
want
gitlab
to
ingest,
you
need
to
to
comply
with
that
schema
and
then
there's
a
separate
set
of
schema
and
each
analyzer
is
free
to
do
their
own.
And
that's
what
I
understood
for
from
the
leader
that
I
read.
I
haven't
read
the
full
thing,
but
it
sounds
like
what
mammoth
was
trying
to
do.
B
There
is
create
a
create,
a
a
framework
where
a
framework
where
hey
vms
can
keep
doing
its
features
and
creating
new
things
and
and
making
that
available
as
a
service
to
to
analyzers,
and
they
can
join
in
into
new
features,
at
least
the
non-mandatory
ones
and
at
the
same
time,
allow
analyzers
to
do
their
own
thing.
But
I'm
I'm
a
little
bit
with
the
olivier
with
olivier
and
this
one
that
I
don't.
If
we
don't
have
an
intent
of
releasing
analyzers
as
ten
long
products.
B
C
Yeah
I
mean
the
other
thing
is
like
when
I
think
about
what
gitlab
is
the
tighter.
We
couple
these
things,
the
more
value
there
is
for
a
customer,
because
it's
like
a
seamless
experience
of
like
hey.
I
ran
this.
I
ran
this
analyzer.
It
shows
up
in
my
dashboard,
and
I
can
you
know
I
would
love
to
be
able
to
say
on
the
vulnerability,
dashboard
change,
my
configuration
and
that
flows
right
back
into
my
schema
into
my
analyzer,
and
then
I
rerun
it
like
tight
coupling
actually
creates
more
value
for
our
customers.
C
If
the
das,
analyzer
or
ca
analyzer
is
no
different
than
you
know,
an
ibm
one
or
whatever
it's
like
well
where's
the
where's,
the
integration,
then
I'm
getting
a
lot
of
value
from
from
git
lab.
So
you
know,
I
think,
the
the
the
closer
we
can
work
together.
I
think
the
more
value
we
can
create.
We
just
need
to
create
a
good
separation
so
that
we're
we're
efficient
and
everyone
can
move
forward
independently
without
stepping
on
each
other's.
B
B
B
Specifically,
basically,
you
can
point
that
scanner
to
anywhere,
and
we
can
do
that
with
the
we're
going
to
be
able
to
do
that
very
soon.
We
contain
a
live
scanning,
which
means,
if
you
have
containers,
running
vulnerable
images,
you're
going
to
have
a
bunch
of
findings
that
are
duplicate
not
only
across
the
containers.
B
Instance
containers
themselves,
but
also
with
the
results
from
an
image
scanning,
but
maybe
also
from
the
dependency
scanning,
but
also
maybe
from
from
some
static
analysis
right
so
being
able
to
to
see
to
have
a
common
denominator
across
all
that
they
can
say
hey.
These
are
actually
all
one
and
the
same.
If
you
fix
this
one
here,
all
these
will
be
fixed.
I
think
it's
very
valuable
for
customers.
A
So
we
just
try
to
discuss
the
time
we
can,
but
it's
not
an
efficient
process
and
since
defining
a
given
set
of
people
to
work
on.
That
is
super
hard
to
achieve
right
now,
due
to
the
amount
of
people
that
we
have
and
the
hiring
budget
we
have.
I
think
that
that
if
we
want
to
move
forward
for
the
next
six
months
or
so
before,
we
we
can
hire
more
people.
A
The
working
group
sounds
to
me
to
be
the
very
best
approach
to
do
that,
having
a
working
group
that
will
focus
on
those
main
items
about
integration
working
at
the
schema
of
the
versioning,
because
there
is
a
tight
coupling
by
nature,
but
we
can
probably
come
up
with
a
framework
that
will
give
each
of
this
team
part
of
the
flexibility
they
need.
The
first
step
you
made
in
that
direction
to
me
is
the
generic
fields
that
the
extra
field-
sorry-
I
don't
recall
that
name
but
details
the
detail.
Thank
you.
A
B
A
But
if
tomorrow
you
have
an
api,
we
could
drop
our
temporary
reports
and
use
the
api,
and-
and
it's
not,
it
doesn't
make
sense
to
me
to
maintain
multiple
entry
points.
We
should
just
as
said
says,
and
we
should
all
be
like
ibm
or
any
surprise.
We
provide
reliability,
data
information
into
the
very
same
system
and
whatever
the
brand
name
we
put
on
those
analyzers,
they
should
have
the
exact
same
capabilities.
A
So
to
me,
the
working
group
should
define
that
how
we
version
things,
how
we
can
define
the
the
support
range
between
the
race
version
and
the
different
tool,
whether
it's
heat,
lab,
analyzer
or
third
parties.
What
is
the
deprecation?
Have
the
the
notification
delays
and
seeing
that
that's
really
defining
how
we
can
work
on
a
sustainable
way
for
the
long
term?
B
Yeah,
it's
when
you
put
it
like
that,
it
it
it's
funny,
because
we
could
end
up
trojan
horsing
the
the
the
direction
from
threatening
sites.
If
we
do
a
good
job
on
the
graphql
api
on
the
mutation
to
insert
vulnerabilities
via
an
api
and
analyzes
starting
using
that,
then
we'll
just
be
playing
by
the
existing
rules
for
graphql
deprecation,
they're
already
in
place
right
and
and
then
my
combo
point
will
go
well.
These
jason
schemas
are
not
being
used
by
anyone
else.
B
Do
we
still
need
them,
but
I'm
not
opposed
to
the
to
the
to
the
idea
of
a
working
group
to
to
get
us
past
that
I
don't
think
I
don't
think
we'll
be
in
a
position
a
year
from
now
where
we
exclusively
using
an
api
for
injection.
I
think
those
schemers
will
be
here
for
for
for
longer
than
that,
maybe
not
longer
than
two
years,
but
certainly
longer
than
a
year.
Does
anyone
have
a
different
gut
feeling
about
that.
B
D
A
The
initial
concern
was
our
understanding
within
the
engineering
about
the
product
goal,
what
we
are
trying
to
build.
What
is
our
vision-
and
this
was
right,
but
the
few
first
sentences
that
I
mentioned
that
were
said
in
that
discussion
in
the
issue
where
analyzers
and
gravity
management
system
were
two
different
products
and
that
the
solution,
the
proposal
that
we're
starting
to
be
the
technical
solution
that
we're
starting
to
be
discussed
in
that
issue,
we're
assuming
that
there
are
different
products.
B
Two
at
least
olivier,
doesn't
oppose
threatening
sites
owning
that.
However,
the
main
concern
continues
to
be
what
cameron
has
raised
a
couple
weeks
ago,
which
can
the
analyzer's
team
still
do
that
their
job
still
deliver
their
features.
If,
if
threats
incites,
that
is,
is
is
the
honor
and,
and
that
doesn't
even
mean
just
because
threatening
sites
doesn't
want
it
or
or
it
it's,
because
threatening
sites
has
a
different
vision.
B
It's
also
resource
wise
right.
Those
threatening
sites
have
the
the
people
power
to
respond
to
inquiries
in
in
a
timely
manner,
to
execute
them
or
to
review
proposals
to
enable
all
the
team.
Other
teams
to
to
like
everybody
can
contribute
right,
but
if
threatening
sites
is
the
owner
at
least
threatened
sites
will
need
to
validate
that
I
can
against
the
roadmap
against
what's
coming
up
and
if
you're
gonna
allow
the
other
analyzer
groups
to
go
yeah
go
in.
C
C
A
It's
definitely
a
bit
harder,
but
being
in
this
situation
a
bit,
we
have
the
dependency
scanning
because
we
are
building
the
dependency
list,
maybe
later
as
a
software
bit
of
material,
so
based
on
the
same
initial
set
of
data.
We
are
building
something
else,
but
I
think
this
is
really
what
the
generic
schema
had
as
an
instant
and
which
is
great
about
that
is
variability
management
category
has
to
define
the
minimum
set
of
information.
A
They
require
to
provide
the
management
of
the
morality,
whatever
is
a
kind
so
every-
and
this
is
how
we
build-
and
this
is
maybe
where
I
think
we
need
to
discuss
more
with
training
science,
because
this
is
what
the
initial
intent,
what
we
call
the
common
report,
which
is
now
called
the
security
report.
I
don't
recall,
what's
called
in
the
schemas,
but
this
is
exactly
that.
What
is
the
common
denominator
between
all
the
different
types
of
variabilities?
So
you
can
see
that
that
we
have
multiple
schemas,
but
in
the
other
word
it's
like.
A
We
just
have
one
schema.
That
said,
this
is
how
venerab
issued
like
should
look
like,
but
if
you
are,
if
this
is
a
dust
vulnerability,
it
has
its
extra
requirements.
If
this
is
a
dependency
scanning
one,
it
has
its
destroy
requirements,
but
this
is
how
we
did
it
so
far,
but
we
can
do
it
differently
and
we
could
have
just
have
one
schema.
A
Let's
say
what
gravity
is
and
then
everything
additional
is
not
strongly
type
based
on
the
the
type
of
analysis
report
type,
but
it
could
be
just
specific
to
some
specific
attributes
that
enable
features-
and
maybe
you
also
have
to
improve
with
more
flexibility.
But
this
is
what
I
think
it
would
be
great
to
have
a
working
group,
because
we
could
have
people
from
each
team
building
this
system
with
training
site
by
sharing
this
common
vision.
B
B
It's
pretty
much
understood
it's
it's
right
it.
The
question
is:
how
do
we
build
on
top
of
that
and
with
that
we've
got
five
minutes,
and
where
do
we
go
from
here?
What
do
we
want
to
do
next?
Do
we
want
to
let
that
that
issue
evolve
naturally,
for
for
a
a
week
or
so
or
do
we
want
to
start
thinking
of
a
working
group.
E
E
Second,
this
exact
issue
has
been
solved
by
many
companies
several
times
over
and
I
can't
help
but
think
that
we
can
glean
information
from
how
other
security
companies
have
solved.
For
this.
I
I
know
for
a
fact
that
there
are
generic
apis
out
there,
so
that
anybody
can
pump
anything
into
a
reporting
structure
and-
and
if
you
want
examples,
I'm
happy
to
chat
with
you
offline
about
those.
E
E
You
know
whether
we
call
details
or
what
have
you.
I
think
that
that
will
largely
satisfy
and
also
keep
in
mind
right
now.
We
have
a
set
amount
of
analyzers.
I
I
promise
you
as
we
move
forward.
There
will
be
more
and
more
analyzers
added,
so
we
absolutely
need
to
be
future
proofing.
This
and
thinking
about
this
in
a
very
generic
way
about
how
we
can
pump
this
information
into
the
the
reporting
structure
and
and
with
that
I'll
stop
and
apologies.
Like
I
said
I
was
trying
to
stay
quiet.
E
I
I
look
at.
I
look
at
the
issue
and
I
see
that
it
is
a
novella
which
also
has
me
extremely
worried,
because
that
that
means
that
there's
a
lot
of
unorchestrated
thought
in
this.
I
almost
wonder
if
it
would
be
better
to
to
scrap
it
and
start
a
new
issue
or
start
something
clean.
But
again
I
will
whatever
the
group
here
decides.
I'm
good
with.
C
I
think
part
of
the
length
is
back
to
thomas's.
Question
is
like
what
are
we
solving
this
issue
of
solving?
How
do
we
work
together?
How
do
we
do
the
the
schemas?
You
know
what
is
the
product
direction,
we're
trying
to
solve
all
of
those,
and
I
think
we
may
want
to
just
order
those
it's
like,
let's
figure
out
what
the
product
direction
is.
Are
these
separate
products?
Are
they
ever
going
to
be
released
independently?
C
D
D
D
Recording
all
right
fabulous,
it's
now,
so
it
now
it's
durable
all.
Right
from
my
point
of
view,
there
are
two
major
sources
of
volatility
that
I
have
to
cope
with.
One
is
how
we
report
this
information
it
it
while
it
may
be
somewhat
stable.
Now
it
has
been
volatile
and
the
evidence
of
that
is
we're
on
version
14
after
eight
or
nine
months.
D
So-
and
I
know
that
past
performance
is
not
a
guarantee
of
future
of
future
performance
as
well.
The
other
source
of
volatility
is
what
these
analyzers
can
detect
themselves
so
and
and
that's
a
data
problem,
so
what
we
can
detect.
What
rules
we
need
to
embed
into
the
product
is
going
to
determine
the
release
cadence
of
any
analyzer
that
I
have,
and
each
of
these
are
released
and
they're
released
independently.
A
D
D
D
The
second
item
that
I
have
is
that,
if
the
schema
version,
support
of
our
are
so
are
declared
by
or
declared
in
rails,
as
far
as
we're
doing
a
hard
validation,
whatever
is
reported
with
whatever
is
reported
within
this.
Whatever
is
accepted
by
the
rails
platform
needs
to
be
durable
and
I
would
argue
it
needs
to
be
durable
on
a
major
gitlab
major
to
major
cadence.
D
So
that
would
be
a
major
major
change
if
we
needed
to
flip
that
and
that's
going
to
take
a
lot
of
effort
and
something
we're
not
prepared
to
accept
at
the
moment,
those
that
was
the
point
of
view
that
I
had.
I
I
don't
have
solutions,
but
I
do
have
constraints
that
I
would
like
to
see
put
into
it
and
hopefully
that
helps
or
we'll
see.
A
A
The
the
usual
support
range
that
we
want,
which
is
the
last
three
major
or
something
like
that,
and
so
definitely
if,
if
the
gravity
management
system
needs
to
make
some
changes,
that
is
impacting
us
and
we
have
to
update
to
stay
compatible
with
the
upcoming
version
of
github.
This
definitely
is
a
breaking
change
that
happens
in
two
major
release
or
a
special
enhancement
that
we
have
to
make
to
anybody.
D
B
D
A
I
really
like
the
the
suggestion
from
this
about
making
sure
we
are
highlighting
the
engineering
vision
based
on
the
product
goals
in
summer
engineering
book
like
analyzer,
are
not
a
standalone
product.
Their
only
reason
of
living
is
to
provide
that
information
to
the
raised
backend
so
that
it's
clear
and
maybe
educate
all
the
team
members
to
make
sure
that
this
is
known
as
a
fact
when
they
are
thinking
about
engineering,
our
systems,
and
I
think
this
is
what
my
main
concern.
When
writing
the
point
in
the
staff
staffing.
A
B
Issue
second
action
point:
if
I
may
ask
tom
thomas
that
you
add
summarize
your
your
three
points
in
that
issue,
to
add
to
the
novella
and
and
third
but
not
least,
todd
since
he
asked
about
actions.
Is
I've
made
mammoth
the
dri
for
this
and
he
does
not
have
capacity.
So
I
need
to
find
him
the
capacity
or
I
need
to
find
a
new
dri
that
has
the
capacity
so
I'll
I'll.
Take
that.