►
From YouTube: Secure Brainstorming - Splitting Analyzers Common
Description
Brainstorming session on benefits and limitations to splitting the analyzers/common library into separate modules and reducing interdependencies between GL groups
- Agenda https://docs.google.com/document/d/179JL5RzbgSIz2XZewbYn79cuX7_vUtte_TcoLwUUC5o/edit#
- Issue https://gitlab.com/gitlab-org/gitlab/-/issues/211819
A
A
A
C
A
Just
give
like
a
two
minute
one,
because
someone
might
watch
this
recording
later,
so
we
have
a
library
called
common
that
we
use
among
all
of
the
sassed
analyzers.
The
dependency
scanning
analyzer
is
currently
clear
for
container
scanning,
and
that's
and
fuzzing
also
uses
this,
so
we
currently
have
quite
a
few
different
groups
using
a
common
library
that
is
not
really
a
library,
so
much
as
a
collection
of
separate
go
modules
that
are
used
together.
A
C
C
C
C
A
Is
to
mine,
we
don't
technically
have
to
do.
Excuse
me
what
we're
doing
we
could
properly
use
tags
which
we
don't
currently
that
would
basically
involve
making
a
git
tag
that
matches
the
path
of
the
sub
module
in
that
repository,
but
there's
still
a
lot
of
reasons
why
it
would
be
more
flexible
to
treat
them
separately.
C
A
So
one
reason
that
we
didn't
immediately
start
doing
that
when
we
experimented
with
it
was
because
we,
while
we
would
need
to
consider
versioning
separately,
have
separate
change
logs
for
each
sub
module,
there's
a
bit
and-
and
that
gets
just
a
bit
complex.
I
think
the
primary
reason
that
was
just
it
doesn't
seem
very
common
and
we're
not
super
familiar
with
that.
A
C
B
On
my
side,
I
haven't
heard
that
we
complain
that
dealing
with
multiple
repositories
is
is
painful.
We
have
to
create
too
many
measure
quests
at
the
same
time,
and
and
I'm
wondering
how
much
of
the
split
will
increase
that
that
pain
or
if
we
consider
that
all
those
different
models
would
be
dependent
enough
to
avoid
that,
and
I
think
it
would
be
then
a
good
situation
to
split
into
separate
separate
repositories.
B
Another
concept,
obviously,
is
that
we
are
kind
of
putting
ourselves
in
the
in
the
situation
of
a
mono
repo
that
I
know
was,
for
a
long
time
a
painful
situation
to
handle
with
gitlab,
even
if
it's
getting
better,
as
mentioned
by
fabian,
the
git
libraries
is
one
more
feature
that
doesn't
work
well
with
mono
repo
approach.
So.
A
Yeah,
I
think
I
think
that
there
are
like
a
lot
of
like
assumptions
that
we
have
with
the
way
that
projects
work
at
get
lab
or
like
on
the
product
too.
So,
if
we're
talking
about
ownership,
we
have
the
rule
set
module
that
we
just
added,
which
is
only
used
by
sas.
Currently,
it
could
be
used
for
other
analyzers,
but
assuming
that
it
stays
with
fast,
then
having
a
separate
project
does
things
like
gives
the
sas
team
a
dedicated
security
dashboard
for
any
vulnerabilities
that
come
up
in
modules
we
own?
C
C
C
Yeah,
okay,
I
wanted
to
to
comment
on
what
you
said
about
all
the
risks
of
having
too
many
repos
and
possibly
the
the
need
to
coordinate
magic
quests
when
it's
related.
Hopefully
we
don't
have
to
to
to
create
like
what
six
six
reports
right
from
the
beginning.
We
can
extract
what's
more
real
event,
I
would
start
with
the
issue,
which
is
a
bad
name
for
what
it
is.
It's
well
the
package
we
used
to
to
create
reports.
C
I
would
start
there
a
bit
like
an
experiment,
because
we
can
learn
from
that,
but
also
because
we
are,
we
are
sure
that
it's
not
connected
to
the
others.
We
are
sure
we
need
specific
versions
in
order
to
introduce
breaking
changes
in
this
particular
package,
and
then
we
might
identify
other
repos.
We
would
extract
later.
C
Yeah
one
note
on
on
this
path:
filter,
library
and
a
library
package-
that's
something
we
should
remove
in
the
future.
It's
not!
We
should
use
the
star
instead,
because
it's
what
we
use
for
the
rules
exists,
syntax,
so
that
there
are.
There
are
packages
we
should
remove
in
the
future.
But
there's
then
there's
no
need
to
extract
them
from
this
existing
common
repo.
They
can.
They
can
end
their
lives
there
and
no
need
yeah.
A
C
A
A
C
A
C
Yeah,
of
course,
this
this
one
could
be
specific
to
sas
and
then
scanning
until
we
we
no
longer
need
that
in
the
context
of
dividend
scanning,
because
and
by
the
way.
What
recently
you
we
introduce
rule
set
it's
needed
by
sas,
as
you
said,
before,
it's
not
needed
by
event
scanning,
but
we
had
to
review
the
code
nevertheless,
because
it's
in
the
command
command
package,
so
one
thing
and
also
introduced
our
small
regression
independent
scanning
by
the
way,
it's
not
not
a
big
deal,
but
all
that
could
have
been
avoided.
A
A
A
C
A
C
A
A
B
A
C
C
C
Location
for
these
repos,
these
new
repos
one
suggestion
was
to
use
sorry.
One
suggestion
was
to
use
to
put
them
under
analyzers,
but
I
much
prefer
having
a
specific
project
group
because
it
could
be
confusing
something.
Like
I
don't
know,
the
niger
slash
command
could
be
understood
as
an
analyzer
itself
named
command.
C
E
C
A
B
B
I
don't
know
how
much
this
is
an
issue
I
mean.
Obviously,
this
might
change
the
import
path
when
importing
the
package
in
in
another
analyzer.
So
this
might
still
have
implications
and
we
should
carefully
think
about
it.
I
agree
that
it
might
be
confusing
into
the
analyzers
sub
sub
group,
particularly
if
you
want
to
to
create
some
automations.
C
D
D
A
D
D
B
If
we
take
out
issue,
we
know
that
the
issue
is
a
shared
one,
so
this
new
repository
will
require
approval
from
all
the
groups.
Basically,
what's
left
in
command,
would
that
be
more
independent
or
would
there
still
be
their
shared
pc?
That
would
still
require
to
have
all
approvals
in
in
those
merchant
quests.
A
D
B
A
B
So
this
is
exactly
the
next
step
on
that
discussion
and
I'm
fine
with
that,
and
but
it
has
implication
because
it
means
we
are
acting.
The
fact
that,
even
if
we
are
all
producing
analyzer,
we
might
add
different
implementation
for
the
exact
same
purpose,
which
is
building
the
reports.
That
is
report
from
a
go
library.
B
B
So
we
have
a
given
set
of
maintainers
in
the
race
application
that
can
take
decision
about
any
place,
any
product
area
in
the
code
base,
and
if
something
is
done
wrong,
it
should
be
cut
by
tests.
So
I'd
argue
that
yes,
static.
Analysis
is
responsible
for
the
new
report
package
report
module
and
they
are
responsible
for
maintaining
it,
which
means
anytime.
We
are
doing
a
chain
there
that
we
break
something
for
any
other
category.
B
It
should
break
a
test,
but
it
should
work.
Even
if
you
are
the
only
team
responsible
in
maintaining
officially
that
package
and
may
be
responsible
for
moving
forward
on
its
on
this
roadmap,
why
it
doesn't
work
for
us
I
mean
it's
it's
kind
of
working
outside
for
all
the
rest
of
the
company
on
the
git
library's
application.
In
theory.
In
practice,
we
can
see
some
hiccups,
but
why
why
you
wouldn't
work
here.
A
Yeah,
I
think
that's
that's
really.
I
don't
know,
and
so
so
point
I
I
had
point
10
on
here
too,
which
was
I
just.
Should
we
consider
a
lack
of
schema
enforcement
to
be
a
concern
here
if
we
have,
if
we
just
added
a
job
that
checked
if
the
output
of
scanners
conformed
to
schemas
does
that
cover
us
or.
B
E
Oh,
I
was
just
going
to
say
I
mean
that
enforcing
that
scheme
I
mean
that's
something
that
should
be
fairly
easily
like
unit
testable
within
each
analyzer.
Right
I
mean
what
is
the
artifact
from
convert?
Does
that
match?
The
schema
right
I
mean
is
that
that's
all
we're
pretty
much
saying
that
we
need.
B
A
So
the
the
other
thing
that
I
I
don't
want
to
talk
about,
because
I
don't
think
there
are
enough
hours
this
week
to
discuss,
but
we
should
also
think
about
where
generic
security
reports
fits
into
this,
which
is
something
that
I
understand
from
what
I
understand.
We
do
not
have
to
conform
to
with
our
current
scanners
for
the
immediate
future,
but
I
I
fully
expect
that
to
have
a
greater
discussion,
but
that
does
mean
producing
a
similar
security
schema
format,
which
is
basically
what
issue
is
doing
somewhere
else.
B
E
Jumping
around
too
much
yeah
no
worries,
so
I
yeah
I
I
put
it
in
one
g.
So,
for
example
like,
like
the
the
rule
set
package
right
that
that
introduce
a
an
issue
because
we
had
like
we
added
this
ruleset
package,
which
we
also
had
to
update
the
command
package.
Because
of
that-
and
it
seems
to
me
that,
like
all
issue,
log
util
path,
filter,
crca,
cert
rule
set
search,
slash,
walk
table,
these
are
all
packages
that
do
not
kick
off
a
like.
E
These
are
all
packages
that
that
are
like
purely
just
a
library
right,
so
they
they
or
they
they
could
be.
I
guess
refactored
to
be
like
purely
just
a
library
and
not
necessarily
like
mutate
anything.
So
you
know
you
give
it
a
bunch
of
vulnerabilities.
It
dedupes
and
you
are
returned.
A
bunch
of
vulnerabilities
right
command
is,
is
the
thing
that
actually,
you
know,
runs
it's
more
of
a
framework
and
the
problem
was
command.
E
You
know
we
sas
introduced
rule
sets
which
is
specific
to
just
sassed
and
the
other
teams
don't
use
it
yet.
But
if,
like
fabian
said,
you
know,
he
had
a
comment
if,
if
sas
had
their
own
command,
that
we
that
we
owned
and
then
used
this
other
repo,
which
is
you
know,
we
might
call
it
library
or
whatever
that
has
issue
log
until
pretty
much
everything
besides
command
in
it,
then
the
other
teams
wouldn't
have
that
issue
and
to
me
this
seems
like
the
most.
E
I
don't
know
natural
break
point
where
we
are
it's
it's
kind
of
a
separation
of
concerns
where
one
is
a
purely
just
a
library.
The
other
is
kind
of
a
framework
that
teams
could
use,
and
you
know
I
mean
it's-
it's
a
lot
of
boilerplate
it.
I
also
you
know
it
could
be
that
maybe
we
don't
even
need
the
command
package
where
each
analyzer,
you
know,
defines
the
implementation
on
how
to
produce
a
report
right,
which
is
basically
what
we
do
with
some.
A
Yeah
so
so
I
think
that's
true
for
so,
and
I
was
trying
to
figure
out
who
exactly
is
using
these
different
ones.
So
I
think
that
that
that's
a
very
good
point,
because
it
is
absolutely
different
and
we
should
treat
command
differently
and
that's
probably
the
biggest
one
for
splitting,
but
I
think
that
the
I
think
that
issue
is
used
more
by
like,
like
fuzzing
uses,
issue
and
clar
uses
issue,
but
neither
of
those
use
the
run
command.
A
So
I
think
that,
like
those
two
it
help,
it
would
really
help
us
split
out
the
implementation.
If
you
have
each
group
provides
a
command
or
deals
with
their
own
method
of
execution,
but
there's
like
we
still
have
a
shared
issue
with
with
primarily
issue,
I
think
which
we
need
to
rename
drastically,
but
I
think
that
yeah,
I
completely
agree
that
command
would
probably
be
the
best
one
to
split
out
there.
B
The
bigger
we
diverge
from
others,
because,
fundamentally
doing
a
dynamic
analysis
is
not
the
same
as
doing
a
static
analysis
and
what
was
working
fine
in
the
past
to
be
very
consistent
in
the
way
we
start
an
analyzer,
for
example,
on
the
brand
by
using
this
same
run.
Common
package,
for
example,
might
no
longer
be
true
now,
and
maybe
this
is
the
little
part
of
the
implementation
when
we
could
just
give
freedom
to
every
analyzer
or
maybe
every
type
of
analyzer.
B
E
Yeah
I
mean
I,
I
think
I
that
I
totally
agree
with
that,
where
it's
the
implementation
of
how
you
get
a
report
is
kind
of
up
to
you,
but
that
report
needs
to
be
that.
That's
that's
the
thing
that's
shared
among
you
know
everything
it
needs
to
follow
the
schema
and
that
that
that's
why
it
you
know
they
suggested
splitting
out
the
the
command,
and
I
mean
because
this
is
already
happening
right.
It's
not
like
I
mean
there's,
there's
analyzers
and
there's
groups
that
that
don't
use
command
so
hey.
Oh.
E
B
E
Yeah
right
I
mean
by
splitting
out
command.
It's
not
we're
not
saying
that
you
need
to
use
this.
It's
it's
just
it's!
It's
removing
that
additional
point
of
you
know
shared
review,
because
that's
that's
what
has
caused.
I
mean
there
has
been
changes
in
command
recently,
and
I
think
you
know
that's
that's
the
second
most
touched
package
right,
and
so,
if
we
could
remove
that,
that
would
be
I
yeah
like.
That
would
be
good.
I
guess
my
thing
is
if,
if
we
all.
A
A
A
E
A
A
It's
it's
similar
to
our
plug-in
architecture.
Really.
So,
if
there's
expectations
that
common
says
all
analyzers
need
this
thing,
then
the
analyzers
can
provide
those
things,
but
I
think
that
the
biggest
the
biggest
issue-
and
this
is
the
this-
is
actually
the
point
I
wanted
to
raise
on
number
four.
When
we
were
talking
about.
A
Well,
we've
talked
about
this
in
the
past
and
zach.
Has
this
nice
ascii
diagram
here
the
thing
I've
always
struggled
with
on
the
the
framework
side
of
this
is,
I
don't
see
a
way
where
we
can
regroup
without
causing
even
more
technical
effort
to
bump
any
changes,
any
kind
of
midway
grouping
that
we
add
just
means
we're
going
to
have
at
least
one
more
step
when
we
have
to
bump
changes
across
repositories.
I
think.
E
Yeah,
I
kinda,
I
think,
I'm
I
wanna
that's
another
one
where
I'm
I'm
not
so
sure.
I
I
I
like
what
I
said
or
believe
you
know
want
to
move
forward
with
that.
I
I
think
what
what
I'm
more
in
favor
of,
is
kind
of
what
I
suggested
earlier
was
just
having
instead
of
sas
use,
the
common
command
have
sas
just
replace
a
common.
F
A
A
A
A
A
I
don't
know
if
what
we
have
so
far,
which
is
split
out
some
solely
owned
modules
and
then
look
at
bring
your
own
commands.
That's
definitely
something
we
should
look
into.
Is
that
enough
to
get
us?
Are
we
getting
any
benefit
out
of
those
two
changes?
I
think
b?
We
definitely
would
be,
but
I
don't
think
that
we
have
solved
the
main
issue
here,
which
is
issue.
E
E
I
can't
like
why
not
just
have
you
know,
for
example,
if
senior
detection
needs
a
specific
field,
that's
optional
within
the
common
schema,
and
that
goes
with
everything
else.
So
then
you
have
this
like
fully
flexible
schema,
there's
just
one
schema
that
can
fit
the
mold
for
multiple
report
types
and
that's
what
is
used
to
validate
on.
E
B
But
this
is.
This
is
a
good
question,
because
we
want
more
autonomy.
This
might
be
a
good
way
to
achieve
that,
but
this
also
means
you
will
enter
this
cascading
level
of
dependencies.
When
you
are,
you
have
your
analyzer.
That
depends
on
your
intermediary
layer,
and
this
layer
depends
on
the
common
report
or
issue
package.
A
F
B
But
how
do
you
define
what's
necessary
for
secret
detection
versus
what's
necessary
for
sex?
These
are
different
needs.
You
have
different
mandatory
properties
from
one
report
type
to
another,
so
what
you
said
could
work
well
with
a
unified
schema
so
that
you
will
have
just
one
schema
that
will
work
for
every
report
types.
B
Then
you
could
have
everything
into
one
layer
like
common
issue
package.
Just
one
schema
just
one
implementation
and
it
works
well.
This
is
not
the
case
right
now,
because,
right
now
you
can
say
I
need
every
er.
Each
vulnerability
needs
to
provide
the
location,
but
the
monitoring
properties
within
that
location
object
varies
depending
on
your
report
type
for
container
scanning.
You
need
to
provide
an
image
properly
for
sas.
You
need
a
file
path,
you
need
the
line,
number,
etc,
etc.
B
B
A
Sorry
we
can
do
something
similar
in
issue
that
we
do
in
our
schemas,
which
is
use
some
basic
inheritance.
So
we
have
an
issue
struct
and
then
we
have
a
sas
issue
struct
that
extends
issue
to
actually
get
us
a
bit
closer
there,
and
maybe
maybe
code
owners
is
the
solution
for
something
that
has
a
lot
of
like
mixed
dependency
there.
A
B
This
is
exactly
what
happens
on
the
right
side
with
the
processors
we
have
a
common
password
that
handle
all
the
generic
passing,
and
then
you
have
a
sas
specific
type
for
the
sas
location,
container,
scanning
location,
etc.
Extra.
So
if
we
can
do
that
in
go
yeah,
that
would
be
a
great
improvement
indeed,.
A
A
A
B
A
I
don't
know
if
we
see
a
need
for
sub
modules
at
this
point,
but
it
is
something
we
could
definitely
use.
If
we
still
need
to
keep
things
in
the
same
location,
I
think
it's
more
valuable
to.
I
think
it
would
be
valuable
if
we
want
to
split
issue
out
and
reference
issue
back
in
common,
but
I
don't
think
that
we
want
to
do
that
right
now.
Anything
we
talked
about
or
sorry
not
issue,
but
I
say
command.