►
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).
B
Yeah
real
quick,
some
feedback
on
configuring
analyzers
because
I
have
been
fighting,
especially
with
the
gosek
one.
Lately
we
are
the
warcross
project
that
was
in
its
own
repo
and
then
we
move
that
to
be
inside
the
calabrese,
so
get
lab
is
becoming
a
kind
of
model
repo
now
and
it
was
extremely
ted
used
to
just
re-enabled
the
sas
analyzer.
B
So
if
you
don't
do
anything
that
gives
you
a
runtime
of
approximately
10
minutes
extra
for
just
analyzing,
something
that
you
will
ignore
in
the
end
and
so
there's
an
option
in
the
go
second
in
gosek
that
they
go
secondary.
So
there's
an
option
in
the
underlying
to
to
be
able
to
ignore
some
path,
but
there's
nothing
exposing
these
kind
of
parameters
in
the
analyzer.
B
So
I
got
stuck-
and
I
was
super
frustrated
to
see
that
the
two
is
doing
more
than
the
analyzer
and
there's
no
way
to
to
bypass
that.
I
found
a
walk
around
because
yeah
good
say,
for
some
reason
is
ignoring
some
very
specific
folders,
so
I
ended
up
putting
the
cache
in
these
folders
so
that
it
would
be
ignored,
but
yeah
just
wanted
to
say
that
if
we
could
have
more
control
on
the
tools
that
are
underneath,
that
would
be
easier
for
us
and
I
saw
taylor
yes,
terrorists
there.
I.
C
Yeah,
so
a
couple
things
here,
we
are
planning
to
support
the
like
no
detect
pattern.
This
is
something
we're
looking
at
the
problem
right
now
is
that
the
syntax
for
that
across
all
of
our
tools
is
different,
so
we
haven't
exposed
it
because
of
that
complexity,
as
we
migrate
to
semgrep
we're
planning
to
standardize
on
that.
C
The
other
piece
that
we're
doing
is
we're
going
to
change
our
post
filters
to
pre-filters
so
that,
where
anything
that
is
excluded
is
actually
not
going
to
get
the
analyzer
run
on
it
so
kind
of
handling
running
the
analyzers
on
specific
files
in
two
places,
both
in
the
code
level
with
ignore
comments
and
then
allowing
you
to
actually
not
trigger
the
analyzer
with
pre-filters.
B
A
Yeah,
so
I
think
philippe
and-
and
I
don't
know
dominic-
maybe
as
well
you're
generally
aware
of
the
challenges
we've
got
with
getting
a
couple
of
our
packages.
Upgraded
we've
got
some
vulnerabilities
in
them
that
you
know
a
key
set
of
our
customers
are
pushing
back
on
and
wanting
to
make
sure
that
they're
not
present.
We
actually
have
mitigations
in
place
for
some
of
those
vulnerabilities,
but
nonetheless
the
vulnerabilities
are
still
there.
A
D
We
don't
really
have
a
process
and
a
big
part
of
the
problem
is
that
it's
very
hard
to
find
and
with
security,
it's
probably
a
little
easier,
but
for
gitlab
in
general.
It's
very
tough
to
find
owners
for
gems
for
dependencies
in
general,
and
sometimes
we
in
appsec
will
just
if
it's
just
a
version,
bounce
crazy,
we'll
do
it,
but
with
the
big
one,
that's
causing
issues
right
now
I
forgot
the
name
of
the
on
me
off
or
something
like
that
migrating
to
version
2
is
just
like.
We
can't
do
this.
D
It
requires
a
lot
of
expertise,
and
so
those
are
those
trends
we
we
we
have
a
hard
time
finding
an
owner
one
and
two
prioritizing
it
like,
especially
again.
In
that
case
this
has
been
mitigated
and
non-issue
for
six
years,
so
no
one's
going
to
be
like.
Yes,
let's
do
this,
instead
of
what
the
customers
want.
D
So
so,
yes,
the
short
answer
is
no
there's
no
process
with
the
kind
of
crisis
going
on
we'll
need
one
and
yeah
finding
owners
will
be
the
big
deal,
I
think,
and
having
other
people
than
us
monitoring.
The
dashboards
is
going
to
be
the
report,
I
should
say
still
call
it.
Dashboard
will
be
something
that
that
needs
to
happen,
because
we're
10.
A
D
E
That's
actually
a
question
I
have
for
you.
I
know
at
least
on
my
team.
We
proactively
look
for
criticals
and
highs
if
it's
not
a
critical
or
high
honestly,
we
we
don't
give
a-
I
you
know
like
we'll
flip
through
them,
but
in
most
cases
it's
probably
a
dev
dependency
or
transitive
or
whatever,
but
do
other
teams
not
do
that
and
if
they
don't
do
that,
should
we
start
applying
pressure,
because
right
now
in
product
there
is
within
the
priority
list
in
for
dev,
issues
should
be
taken
into
consideration.
E
Severe
bugs
should
be
taken
into
consideration.
Hacker
one
issue
should
be
taken
into
consideration.
Do
we
need
to
talk
like?
Does
this
security
department?
Not
we
here
need
to
talk
to
like
the
product
department
meeting
like
a
nude
etc
and
be
like
this
needs
to
be
a
thing
you
all
are
doing,
because
it
sounds
like
somewhere.
It's
slipping
through
the
cracks.
D
Yeah
for
sure
I
think
most
of
the
smaller
ish
projects,
the
independent
product
should
say
like
giggling
runner,
the
devs
will
look
at
the
the
reports
every
now
and
then
and
yes,
if
there's
a
critical
hype,
they'll
probably
address
it.
Most
of
the
issues
come
from
the
the
big
rails
repository
just
everyone
opens.
The
page
sees
70
000
issues
and
then
runs
away.
So
that's
our
big
issue
right
now,
but
yes,
there
definitely
needs
to
be
some
sort
of
shifting
kind
of
right
now.
D
I
think
officially
attack
kind
of
owns
looking
at
those
reports
and
then
creating
the
issue
and
paying
the
devs
and
getting
it
prioritized,
but
it
should
be
more
proactive
and,
I
believe,
there's
there
are
talks
with
product,
but
I'm
not
in
in
those
meetings
yeah.
It
is
being
talked
about
frequently
at
least
internally,
and
I
hope
it's
moving
outside
of
our
department,
that
the
managers
who
are
not
here
today
could
talk
more
to
this.
E
See
I
guess
we
can
follow
up
next
week
because
I
think,
obviously,
everything
that's
older
will
come
up
whenever
certain
customers
bring
it
up.
Like
you
said
with
the
six-year-old
one,
you
know
that's
kind
of
that's
been
mitigated,
but
I
think
it
would
be
interesting
if
you
know
we
worked
with
product
and
came
up
with
something
similar
to
that
little
triage
bot
that
at
least
harasses
me
on
a
weekly
basis,
or
maybe
it
harasses
product
and
says
these
were
the
new
ones
in
the
past
seven
days.
E
D
D
C
A
I'm
happy
to
take
this
discussion
into
an
issue
and
open
an
issue,
so
we
can
look
at
it
some
more,
but
you
know
just
looking
at
the
challenges
we're
having
with
that
customer
base.
Currently,
I'm
sure
this
is
not
the
last
time
this
is
going
to
come
up
and
if
there's
any
way,
we
can
get
out
ahead
of
it
proactively.
That
would
be
best.
So
the
sooner
we
start
working
on
that
process,
the
better
we're
going
to
be
anyway.
D
Yeah
and
I
think
dependency
scanning
fines
are
by
far
the
most
reliable
finds
from
the
scanning
like
if
the
version
is
not
good.
The
fine
is
the
true
positive.
So
so
we
can
have
automation
on
that
and
have
it
like
not
drown
and
alert
fatigue
like
when
you're
pink,
because
the
dependency
is
too
old.
It
is
actually
too
old.
So
I
think
there's
definitely
something
we
can
do
here.
E
We
do
have
two
backlog
items
for
at
least
identifying
dev
dependencies
versus-
not
that's,
probably
not
coming,
unfortunately,
for
six
months,
but
I
am
hoping
that
that
right
now
we
get
told
we
have
a
lot
of
false
positives,
but
really
what
they
mean
is
it's
stuff
we
don't
care
about,
and
so
I'm
hoping,
if
we
start
being
able
to
notate.
This
is
a
dev
dependency
right
in
that
info
bit
that
at
least
people
would
start
being
like
okay.
B
A
nice
side
note
just
to
voice
my
comments.
Where
is
it?
I
lost
it.
We
started
a
discussion
there.
It
is
I'm
highlighting
that
in
the
agenda
to
include
the
security
in
the
calculation
of
our
budgets,
and
the
goal
of
that
is
obviously
to
shift
that
as
much
as
we
can
because,
as
the
munich
said,
we
kind
of
declared
like
bankruptcy
on
the
vulnerability
reports.
There's
no
way
we
can
enter
this
amount
of
data
and
we
will
have
to
involve
developers
at
some
point.
D
I
know
I
just
remember
this
andrew
he
was
the
absent,
stable
counterpart
for
forgot,
the
name
of
the
group,
the
people
handling
the
customers
repository.
I
think
it's
growth
he's
working
on
a
process
with
them
to
to
integrate
it
as
part
of
their
workflow
to
look
at
the
repository
so
we're
starting
at
the
at
the
vulnerable.
D
A
All
right
anything
else
on
this
one.
Hopefully
do
you
want
to
make
number
three.
B
Yeah,
it's
actually
directly
linked
to
that,
and
I
just
want
to
that's
just
a
reminder
because
I'm
I'm
pretty
sure
direct
you're
fully
aware
of
the
of
the
issue.
Already
we
have
disabled
dust
it
also
in
the
same
idea
of
rebooting
completely
the
liberty
management
gitlab,
because
we
are
more
than
stuck
on
that.
We
asked
already
to
the
to
infra
to
completely
wipe
out
all
the
results
for
the
gitlab
project.
B
But
this
is
not
the
only
project
so
that
we
would
lower
considerably
the
number
of
vulnerabilities
that
we
have
to
manage
and
we
will
re-enable
dust
only
when
we
are
sure
that
we
are
not
going
to
bring
back
again
like
5
or
6k
every
week,
and
so
that
means
we
need
to
upgrade
to
that
too,
because
this
is
where
we
do
the
where
the
the
results
are
aggregated
expect.
We
have
a
lot
better
results,
but
we
do.
B
We
definitely
need
your
help
to
set
up
that,
because
last
time
it
took
us
something
like
eight
weeks
to
achieve
this,
and
I'm
not
sure
that
we
have
eight
weeks
again
this
time
considering
the
size
of
the
team.
F
Yeah,
no,
that
that
makes
sense.
I
saw
that
seth
did
respond
in
the
issue
and
nikhil
has
been
working
through
some
of
the
the
problems.
I
think
I
would
say
to
cess
point
in
the
issue.
F
I
think
that
it
makes
sense
for
nikhil
to
try
to
set
it
up
as
much
as
possible
himself
with
our
help,
rather
than
us
just
going
in
and
doing
it
that
way.
He
knows
everything
about
the
the
configuration
and
is
aware
of
you
know
what
he
needs
to
do
and
can
offer
input
to
us.
But
that
being
said
anytime,
he
does
run
into
any
issues.
F
I
would
just
say
that
pinging,
the
team
in
slack
or
posting
on
that
issue
and
asking
for
some
help
we'd
be
more
than
happy
to
work
through
any
specific
issues
that
he
has.
B
Bit
afraid
of
starting
at
this
gigantic
gigantic
diagonal
task.
Sorry,
without
any
support,
because
you
would
be
completely
focused
on
the
rapid
action.
But
I
understand
that's
not
the
case.
You
would
have
some
some
engineers
available.
So
that's
cool.
F
Yeah
yeah,
we
will
have
to
help
out
with
something
like
that.
The
rapid
action,
I
think,
doesn't
affect
us
quite
as
much
as
it
does
some
of
the
other
groups.
B
That's
great
thanks
all
right,
let's
be
right,
respectful
of
time.
I
will
move
on
to
the
next
point.
If
there
is
anything
else,
exactly
in
the
same
vein
again,.
F
B
Have
just
too
many
findings
in
this
vulnerability
reports.
There's
a
link
here
that
I'm
highlighting
in
the
agenda.
We
already
asked
infra
to
completely
wipe
out
the
results.
You
can
see
that
this
issue
was
open
july
13..
We
are
august
12,
so
that's
exactly
a
month
from
now
we're
still
at
the
same
point.
B
That
is
absolutely
scary
to
me,
because
every
time
we
will
do
a
mistake,
we
will
enable
an
analyzer
that
will
completely
float
out
of
the
pattern
we
bought.
We
know
it's
lost.
We
will
have
to
wait
weeks
to
have
something
manageable
again
and
that's
that's
not
something
we
can
afford
in
absence,
so
we
will
need
a
way
to
get
more
control
on
the
venables
and
obviously,
if
we
can't
be
maintenance
of
all
the
projects
around
there.
There
are
some
projects
where
I
don't
even
have
access
so
need
to
find
a
solution.
B
I
don't
I'm
not
asking
for
a
secretary
role
per
se,
but
I
don't
know
some
something
in
the
settings
where
we
would
have
more
control
than
the
others
to
be
able
to
do
that.
That's
going
to
be
very
blocking
for
us
really
soon
as
we
are
adding
more
projects
and
we
are
enabling
more
secure
analyzers.
We
are
generating
more
and
more
wizards.
B
We
know
that
as
soon
as
we
dismiss
something
it's
going
in
this
huge
bucket,
it
hasn't
made
millions
of
vulnerabilities
and
we
won't
be
able
to
weed
out
what
is
really
something
in
there
that
we
dismissed,
because
we
decided
to
do
this
and
it
seems
very
efficient,
inefficient
to
just
ignore
mass
ignore
something
which,
in
the
red
data
we
right
away,
must
ignore
it.
It's
not.
D
No
actually,
because
if
we
dismiss
a
true
positive,
the
next
scan
will
not
recreate
it
because
we
have
dismissed
it
well.
If
we
delete
the
next
clean
scan
with
fewer
analyzers
and
all
that
we'll
bring
that
back
up,
and
then
we
can
see
it
because
if
we
just
dismiss
everything,
the
the
actual
positives
are
going
to
be
lost
forever.
I
think.
G
B
For
us
for
a
good
reason,
because
we're
trying
to
reboot
our
very
limited
management
program-
and
that
starts
with
metrics-
that
we
don't
have
right
now.
So
if
we
start
doing
mass
updates
we're
going
to
completely
screw
up
all
the
metrics
that
we
have,
we
want
to
be
able
to
measure
exactly
what
we
are
doing.
B
If
something
is
resolved,
that
means
we
took
an
action
and
it's
resolved,
and
we
did
the
right
thing
if
we
dismiss
something:
that's
because
it's
a
force
positive
and
that's
going
to
impact
the
first
positive
rate
that
we
want
to
measure.
We
want
to
stop
measuring.
We
want
to
stop
building
something
around
data.
E
But
the
thing
is,
if
it
recreates
a
new
record
after
a
certain
date,
you
can
just
ignore
everything
before
the
date.
The
script
stopped,
because
if
you
delete
you'd,
essentially
be
starting
over
at
date
x,
let's
just
say
august
20th.
So
if
you
just
only
look
at
things
going
august,
20th,
wouldn't
it
also
have
similar,
like
this
popped
up
as
a
new
item
again
or
this
popped
up
as
refound
again.
D
F
B
I
I'd
like
to
share
that
experience
with.
We
had
the
case
for
confirming
verification
was
secret,
analyzer
or
sas
on
the
project
where
the
pipeline
was
reporting
very
few
results
and
when
it
was
merged
into
master,
it
was
thousands
of
results
because
master
has
a
different
configuration
and
the
analyzer
started
to
scan
cache
files
and
some
other
things
that
were
not
in
the
branch.
For
some
reason-
and
there
was
nothing
I
can
do
to
fix
that
it
was
there,
it's
it's,
not
it's
all
right.
There
is
nothing
I
can
do
and
we're
stuck
now.
E
D
Maybe
having
a
a
new
dismissal
reason
like
we
have
small
fix
and
false
positive
and
what
not,
just
like
a
technical
issue
set
up
issue,
just
one
that
we
could
exclude
from
the
metrics
like
it
wasn't
a
a
bad
scanner.
Finding
was
a
configuration
issue,
and
now
we
have
10
000
issues.
We
won't
even
look
at
and
we
want
to
remove
like
some
sort
of
different
dismissal
label.
B
B
B
B
G
Dominic
tier
commented
earlier
about
the
dismissal
types
we
do
have
that
that's
actually
something
that
was
in
progress,
and
then
we
hit
a
piece
of
technical
debt.
We
put
a
link
in
there
and
basically
we
have
one
or
two
large
pieces
of
technical
debt.
We
need
to
address
to
unlock
a
few
feature
pieces
and
those
have
now
been
de-prioritized
for
the
rapid
action,
the
database
ecomp
and
several
other
things
that
people
are
screaming
about.
So
all
this
stuff
is
there.
It's
just
been
shifted
out
till
I
don't
know
probably
november
at
the
earliest.
A
A
Can
carry
those
two
next
time
and
or
handle
them
async.