►
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).
A
Thank
you,
sir
all
right
happy
wednesday,
so
hope
everybody's
having
a
good
week,
we'll
go
ahead
and
jump
into
the
announcements
and
then
to
go
towards
the
agenda
as
well.
So
all
the
announcements
reminder
family
and
friends.
Today
is
this
friday,
and
it's,
and
also
this
was
from
the
from
slack.
A
There
is
another
one
that
has
been
scheduled
in
june
and
the
link
is
available
towards
that
merge,
request
that
that
added
that
to
our
calendar,
so
things
to
look
forward
to
there
were
a
few
items
that
I
found
noteworthy
from
the
engineering
week
in
review
that
I
thought
were
worth
highlighting
in
this
particular
conversation.
A
First,
one
is
about
dog
fooding,
a
new
ci
feature,
and
it's
around
caching
multi-caching
and
since
we
for
the
analyzers
work
on
top
of
the
ci,
what's
underneath,
our
feet
is
worth
knowing
about,
and
so
this
is.
This
is
something
that's
worth
being
aware
of
and
watching
next
one
is
about
end-to-end
testing.
There's,
there's
a
new
automation,
toolkit,
that's
in
beta
and
as
you
for
the
git
lab
into
in
test.
So
being
aware
of
that
is
also
important
to
us.
A
The
next
two
are
from
security
number
one:
is
there
there's
a
inventory
of
dependencies
that
are
being
built,
so
this
is
something
that
we
should
be
aware
of,
that
is
being
built
out,
and
this
is
also
related
to
another
initiative.
That's
within
dapp
sec,
as
well
of
that
will
have
some
impacts
about
that,
could
have
impacts
about
how
we
do
dependency
updates
within
our
own
projects.
A
So
being
participant
in
this
for
this
process
is,
is
is
worthy
of
our
time
and
the
other
one
is
related
to
sentinel.
One
there's
been
some
configuration
changes
that
should
lessen
the
performance
impacts
on
all
of
on
all
of
us
within
engineering.
A
So
so
please
continue
to
speak
up
if
you're
impacted
by
sentinel
one
itself
and
and
be
aware
of
how
it
is
configured
and
the
last
one
is
is
worth
knowing
about,
and
that's
it's
it's
typically
a
not
a
good
idea
to
use
static
files
persisted
on
disks
that
has
a
shared
resource
between
between
multiple
multiple
features
and
so
there's
some
guidance
that
is
coming.
It
that's
been
added
to
the
docs
around
this
and
that's
the
note
from
sean.
That's
that's
highlighted
there.
A
Next,
something
we
celebrate
every
single
week
features
and
high
priority
bugs
closed
in
the
past
seven
days,
there's
been
quite
a
few.
So
if
you
want
more
information
about
what
was
closed
and
how
it
was
closed,
please
click
through
to
see
what
happened
there
and
thiago's.
Not
here
would
someone
like
to
play
to
to
be
to
speak
in
his
dead?
If
not,
I'm
happy
to
do
so.
B
I'll
I'll
take
it.
Please
join
me
in
welcoming
brian
williams
to
the
protect
container
security
group.
Brian
welcome.
C
Yeah
sure
so
I'm
joining
as
a
senior
back-end
engineer
on
the
protect
team
reporting
to
thiago
and
before
this
I
was
a
security
engineer
at
hev,
who
is
a
texas
grocery
company.
So
if
you
live
in
texas,
you
probably
know
them.
If
you
don't
you
probably
don't,
and
before
that,
I
was
doing
research
and
development
at
white
hat
security.
C
So
I've
been
a
cyber
security
professional
for
the
past
five
years
and
I
decided
that
I
wanted
to
change
to
engineering
and
I'm
really
excited
that
and
I'm
so
grateful
to
todd
and
everybody
else
on
the
team
for
giving
me
this
opportunity.
B
All
right,
let's
you
want
to
continue
on
number
five,
thomas
yeah.
A
Absolutely
so
there
is
a
there's,
a
tradition
that
is
coming
to
the
sec
section
from
our
friends
over
and
protect
and
threaten
sites
team
days.
So
that's
something
that
lindsay
is
is
mentioning
here,
we're
trying
to
figure
out
a
date
and
any
ideas
about
what
these
might
look
like.
So
there's
a
link
to
the
issue
kind
of
describing
more
about
what
it
is
and
also
trying
to
set
ideas.
So
this
is
certainly
something
that
looks
like
a
lot
of
fun.
C
A
So
please
contribute
to
this
and
neil
you
called
the
the
last
one
so
floors.
Your
sir.
E
Yeah
just
an
announcement,
so
we
had
a
live
learning
series
thing.
Yesterday
there
were
two
sessions.
They
were
both
bad
times
for
me,
so
I
had
to
watch
the
recording,
which
was
fine
by
me,
actually
worked
out.
While
I
was
watching
listening
to
it.
It
was
awesome,
it's
about
rest
ethic,
so
the
gentleman
who
wrote
time
off
it's
a
book
he
promoted
and
he
came
and
spoke
to
us
a
few
months
ago.
D
A
All
righty
I'm
going
to
go
ahead
and
get
us
into
the
agenda,
so
first
one
was
from
cam
I'll
go
ahead
and
speak
for
them.
There
was
a
feature
that
we
were
discussing
and
it's
either.
A
Last
week
the
last
week's
iteration
of
this
meeting
series
for
the
week
before
I
don't
remember,
which
and
haven't
had
a
chance
to
go
back
through
the
agenda
where
we're
looking
at
release,
evidence
and
so
cam
has
done
some
investigation
about
artifacts
and
so,
and
so
he's
got
a
note
here
about
artifacts
paths
and
also
to
the
report
type
json
file
that
we
typically
if
we
don't
have
that
within
our
within
our
gitlab
template.
A
Then
it
does
not
include,
then
that
is
not
included
in
the
release.
Evidence
feature
itself,
and
so
what
km
is
calling
out
is
that
this
particular
json
file
is
available
from
the
pipelines
page
anyway,
and
it's
not
a
privacy
concern,
because
so
authentication
and
authorization
requirements
do
apply
to
the
download
the
file
itself,
and
so
this
is
a.
This
is
quite
a
good
bit
of
investigation
from
cam
and
much
appreciated
any
questions
on
this
because
I've
fumbled
to
the
delivery.
A
D
D
A
D
A
All
right,
I'm
going
to
move
on
also
speaking
for
isaac,
so
severity
levels,
how
we
use
them
and
how
they're
defined
is
not
consistent,
and
so
that's
what
isaac
is
trying
to
get
at
with
this.
A
With
this
question
in
this
item
here,
we've
got
a
lot
of
different
tools
and
a
lot
of
different
ways
in
which
severity
is
defined.
Whether
and
and
it's
convenient
I'll
leave
I'll
speak
for
static
analysis
within
sas.
It's
in
it's
inconsistent.
It
depends
on
the
tooling.
So
this
is
a
big
topic
for
us,
and
so
how
can
we
go
about
standardizing
this?
A
A
The
code
quality
severity
levels
do
not
match
the
static
analysis,
severity
levels
that
we
have
within
our
vulnerability
filters,
and
so
rationalizing.
That
is
something
that
is
being
looked
at
within
ux,
and
my
question
is:
is
that
there's
something
there's
an
initiative
that
mark
put
in
from
vulnerability
mark
put
in
about
standardizing
on
cwes
or
some
other
related
framework
to
help
derive
severity?
A
F
So
I
I
had
some
initial
comments
on
the
merge
robust
that
I'll
summarize,
because
I
have
strong
opinions
about
this
from
past
discussions,
but
this
is
specifically
on
a
page
that
shows
a
table
of
mappings
between
the
underlying
analyzers
and
what's
what
textual
severity
we
apply,
which
is
something
like
high
if
the
if
this
work
is
around
quantifying,
what
high
severity
means.
F
I
I
mean.
I
think
that
there's
a
lot
of
value
in
saying,
typically
that
this
would
map
to
like
the
cdss
range,
but
it
feels
a
bit
disingenuous
to
say
that,
because,
if
something
like
the
php
security
audit
tool
only
provides
like
a
warning
and
an
error,
so
we
are
doing
a
very
loose
mapping
there
and
saying
that
providing
a
high
severity
from
this
tool
is
not
really
accurate.
Just
because
we
don't
have
a
better
resolution
there.
So
we
can
use
more
wishy-washy
language.
F
D
I
know
that
I've
been
discussing-
and
I
know
eventually
we
wanted
to
get
to
the
point
where
we
kind
of
allowed
people
to
have
their
own
slightly
customized
priority
instead
of
severity.
I
guess
I'll
just
call
it
priority
for
now
to
differentiate,
and
I
think
if
we
were
to
go
there,
we
could
do
a
mapping
project
like
andy
did
originally,
where
we
say
we're
going
to
by
default
map
x
to
y
here's
the
behind
the
scenes
for
everything
and
here's
our
rationale
for
it.
D
But
then
I
think
we
need
to
start
giving
people
the
ability
to
adjust
priority
based
on
their
own,
whatever
internal
policies
rules,
compliance
frameworks,
they're,
they're,
beholden
to
or
whatever.
So
if
we
say
these
cwes
map
to
whatever
and
these
you
know,
cvss
scores
mapped
to
whatever
they
could
adjust
that,
and
so
we
could
have
like
in
the
ideal
way
and
state
somebody
could
actually
click
on
it
and
see
like
the
tool
output
blah.
D
B
A
Isaac
has
done
us
the
courtesy
of
putting
an
nmr
together
that
tries
to
capture
what
it
means
to
be
critical,
high,
medium
low,
etc,
and
that's
probably
the
artifact,
by
which
we
start
this
conversation,
but
it'll
certainly
graduate
to
an
issue.
If
it's
not
one
that
we
already
have
the
one
that
I
the
candidate
that
comes
to
mind
for
me
is
the
cwes
the
secures
currency,
but
that
might
be.
I
may
be
guilty
of
overloading
that
initiative
with
this
idea
of
rationalizing
severity.
F
I
I
think
that's
definitely
the
case
here,
because
just
about
all
the
discussions
we're
having
are
on
there's
a
lot
to
discuss
about
severity.
I
think
that
just
to
refocus
the
discussion
on
the
mr
isaac
opened,
can
we
safely
say
that
when
we
report
a
high
severity,
it
means
this
specific
range
of
cvss
scores
like
that?
That's
essentially
what
we're
trying
to
solve
right
now,
which
is
not
what
we
should
do
with
severity
or
what
our
next
steps
there.
D
C
Sure
I
can
say
something
real,
quick.
One
thing
what
I
wrote
in
the
document
was
that
if
we
start
you
know
overriding
the
output
of
the
underlying
tool,
then
suddenly
we
have
to
consider
all
the
outputs
that
the
tool
might
give
us,
and
that
seems
like
a
lot
of
work
to
take
on
unless
we
like
make
the
end
user
responsible.
C
For
that
another
thing,
I'm
thinking
is,
I
haven't
written
in
document
yet,
but
should
this
be
tied
to
cbss
at
all,
because
cbss
is
highly
contextual
and
you
know
there's
all
the
different
parameters
and
it
it
highly
depends
on
the
context
of
the
vulnerability.
C
So
should
we
maybe
come
up
with
our
own
definition
that
doesn't
reference
cbss.
D
We
kind
of
already
dug
that
hole
and
are
stuck
in
it,
we're
already
doing
the
mapping
and
you're
right.
That's
it's
not
contextually,
aware,
which
is
where
a
lot
of
these
other
discussions
that
thomas
and
I
were
referencing
that
exist
in
the
backlog
have
stemmed
from
in
that
it
is
imprecise
for
various
customers.
So
we
need
a
secondary
mechanism
for
them
to
customize
it
to
their
situation.
A
C
G
Taylor,
do
you
want
to
speak
to
your
point
sure
yeah
I'll
use
this,
so
we
do
actually
bring
this
benchmark
tool
up
in
the
context
with
customers.
There
are
two
versions
of
it:
there's
one
that
has
vendor
names
on
it.
There's
one
that's
completely
anonymous.
We
used
the
anonymous
one
when
we
were
talking
with
customers.
G
I
personally
don't
like
showing
this
graph.
It's
got
too
many
caveats.
It's
one
java
spring
framework
comparison,
it's
very
limited
in
scope
and
it
kind
of
sends
the
wrong
message
to
customers.
We've
been
telling
customers
we're
not
afraid
for
you
to
compare
us
to
your
other
security
vendors,
we're
available
on
free,
go
created.com,
account,
add
your
code
and
run
it
and
compare
the
results.
That's
the
message
we've
been
sending.
So
unless
this
tool
gets
more
verbose
and
has
more
framework
support,
I
don't
think
it
makes
a
lot
of
sense
to
continue
maintaining.
G
A
Okay,
we're
up
on
time
I'm
going
to
call
out.
I
mean
just
there's
two
important
items
that
are
march
read
only
below
this
in
the
agenda,
one
related
to
ones
related
to
a
slack
channel
that
we
should
all
be
aware
of
exists
and
the
and
and
what
it
is
its
intended
use
is,
and
the
other
is
related
to
training
opportunities,
potential
training
opportunities
that
are
better
that
are
in
front
of
us
here
in
the
in
the
in
the
near
term.