►
From YouTube: Vulnerability Disclosures WG (December 14, 2020)
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
Hey
cool
so
welcome
to
you
all:
it's
the
open
source
security
foundation,
vulnerability,
disclosures
working
group
meeting
and
today
is
december
14th.
So
we
have
a
few.
We
have
a
few
topics
here
that
are
here
in
the
agenda
and
I
think
there's
one
that
florencia
wants
to
talk
about,
that.
I
didn't
add
the
agenda,
but
I
hope
we
can
find
the
time
to
cover
that,
because
I
think
florence
you
mentioned
that
the
the
next
meeting
that's
in
two
weeks,
is
not
a
good
fit.
A
So
let's
try
to
make
sure
that
we
have
some
time
at
the
end
to
to
cover
that
as
well.
If
I
remember
correctly,
the
last
time
we
met,
we
decided
to
kind
of
split
into
a
couple
of
subgroups
and
tackle
the
problem
of
documenting
use
cases
for
a
couple
of
different
personas.
A
I
and
I've
been
kind
of
watching
that
in
those
two
weeks,
and
I
think
that
we
made
a
lot
of
progress
there,
so
I
would
want
to
like
circle
back
to
and
to
that
towards
the
very
end.
A
But
I
also
remember
that
one
of
the
one
of
the
personas
we
concluded
we
didn't
know
too
much
about
or
we
didn't
have,
representatives
of
was
the
sort
of
tool
scanner
vendor,
and
to
this
end
we
have
jason
today
and
wrist
to
tell
us
more
about
this
part
of
the
story,
because
I
think
it's
as
we
said
at
least
the
last
time
we
discussed
vulnerability
disclosures
from
the
perspective
mainly
of
the
security
researcher
in
the
maintainer,
but
we
haven't
actually
dug
into
okay.
A
Now
that
we
disclose
something.
What
happens
with
with
this
information
who
collects
it?
Is
that
information
all
they
need?
I
have
a
hunch
that
you
know
most
tool,
scanning
vendors
kind
of
need
to
enrich
that
information
even
further
yeah
and
let's,
I
really
hope
to
have
more
discussions
about
workflows
and
personas
and
actors
in
in
that
ecosystem.
A
B
Yeah
sure,
can
you
give
me
permission
to
share
the
screen.
I
think
you
have
to
hand
it
over.
It's
not
like
yeah,
absolutely.
B
Yeah
I
got
it
and
just
so
everyone's
aware
I
have,
I
don't
know
if
it's
emerged
yet,
but
I
have
a
pending
pr
to
add
this
slide
deck
to
the
documentation.
Folder,
so
folks
will
be
able
to
get
it
off
of
github
after
after
the
call.
B
Yeah
no
problem,
so
thanks
a
lot
for
giving
me
a
couple
minutes
to
to
present
our
perspective.
B
Today,
I'm
not
going
to
go
into
a
lot
of
different
background
myself,
the
interest
time
I
I
basically
run
our
threat
management
portfolio
so
a
lot
of
our
different
software
regarding
security,
I
run
the
technical
direction
of
it,
but
you
know,
because
of
because
of
that,
where
I
sit,
I've
actually
kind
of
at
one
point
or
another
played
almost
all
of
the
different
roles
in
these
personas,
both
as
a
open
source,
maintainer
software
developer,
somebody
who's
managing
the
people
who
are
developing
the
software
and
also
the
vendor,
who
has
to
receive
the
patches
from
the
other
different
people,
the
other
open
source
projects,
we've
kind
of
sat
through
through
all
of
it.
B
So
we
have
a
pretty
good
perspective.
I
think
on
on
some
of
the
different
personas
that
are
at
play
here:
definitely
not
all
of
them
as
I'll
get
into,
but
I
think
we
have
a
good
sampling-
and
I
want
to
thank
there's
a
few
different
folks
in
the
working
group
who
contributed
to
the
deck
as
well
definitely
see
rob
and
some
others.
So
I
want
to
thank
them.
B
So
I'm
going
to
be
pretty
quick
here.
The
way
that
I
approach
this
to
kind
of
structure,
the
conversation
is
I'm
taking,
basically
what
we
call
an
ib,
this
design,
thinking
approach
and
really
what
it
revolves
around.
Is
this
idea
of
breaking
your
problem
set
into
the
different
personas
that
we
have
to
deal
with
the
problem
and
then
trying
to
unpack
their
needs?
Their
wants
their
desires,
so
we
can
have
a
better
idea
of
what
we're
trying
to
solve,
and
it's
really
all
about
this
challenge
here.
You
know
I
love
this
meme.
B
You're
gonna
see
something
completely
different
and
it's
not
until
you
turn
the
lights
on
and
everybody
sees
you
know
all
that
everyone
was
right,
but
you
really
have
to
put
everything
together
if
you
want
to
get
the
whole
picture
of
what
you're
actually
looking
at,
and
I
think
this
problem
sets
like
very
much
like
that.
You
know:
there's
all
these
different
personas
involved
in
the
vulnerability
disclosure
process
in
open
source
and
we've
really
got
to
kind
of
take
a
look
at
everyone's
different
point
of
view.
B
If
you
want
to
decompress
the
entire
end-to-end
problem
here
again
this
this
whole
idea,
it's
called
design
thinking
and
it
it.
It's
basically
around
this
idea
that
you
want
to
empathize
with
the
different
target
audiences.
You
have
and
then
figure
out
what
they
want
to
achieve
and
then
really
quickly,
iterate
and
brainstorm
on
solutions
to
their
specific
problems,
and
it
kind
of
helps.
B
You
take
yourself
out
of
your
own
perspective
and
kind
of
inject
you
into
some
other
people's
perspective,
what
they
have
to
deal
with
in
their
daily
life,
which
isn't
necessarily
always
the
same
as
what
you
have
to
deal
with
so
personas
that
I'm
going
to
get
into
what
what
is
a
persona,
a
persona?
Is
it's
a
fictional
character
that
you
try
to
create
based
on
your
research
of
the
different
problem?
B
Sets
that
you're
trying
to
tackle,
and
it's
you're
supposed
to
create
personas
that
represent
the
different
types
of
users
that
are
going
to
either
use
your
service
or
your
software
or,
in
our
case,
the
different
types
of
personas
that
are
involved
in
vulnerability
management
in
the
entire
and
then
life
cycle,
and
the
purpose
of
that
is
to
help
you.
You
know
step
outside
of
yourself
and
recognize
the
different
people
of
different
needs,
different
expectations,
and
they
can
help
you
kind
of
identify
with
the
different
problem
sets.
B
The
different
groups
have
so
without
further
ado
I'll
get
into
some
of
the
different
personas
that
that
I
believe
we
have
to
deal
with
again.
I'm
not
saying
that
you
know
this
is
the
bi
end,
all
there's,
probably
more
that
we've
forgotten,
but
I
I
do
think
it's
a
good
starting
point
and
you
know
hopefully
go
a
good
place
to
open
up
a
good
discussion.
B
B
She
wants
it
to
reflect
positively
on
on
her
own
eminence
as
a
developer.
What
do
I
mean
by
that?
Basically,
she
wants
a
project
to
have
quality
code
right.
What
are
her
pain
points
as
a
developer
maintainer?
She
may
not
be
compensated
at
all
to
work
on
this
project.
Maybe
she
is
maybe
she's
not
we
don't
know
she
there.
They
have
a
lack
of
supporting
resources
and
the
priorities
of
the
community
that
are
consuming
their
code.
B
They
may
not
align
with
their
own
priorities
or
even
their
goals,
right
they're,
trying
to
advance
their
project
they're,
trying
to
take
it
in
certain
directions.
The
people
who
consume
the
project
may
think
that
it
should
go
in
a
different
direction,
but
it
doesn't
necessarily
align
with
their
own
and
that's
certainly
true,
very
often
when
you're
talking
about
security,
you
know
I
I
actually
just
there
was
somebody
posted
up
a
interesting
survey
there
on
the
weekend.
B
I
don't
think
it
was
tied
to
open
ssf,
but
it
you
know
it
said
that
most
open
source
developers
thought
felt
like
doing.
Cyber
security
was
a
death
march
and
it
was
like
a
soul-draining
activity.
B
So
that
really
just
goes
to
the
last
point
there
that
the
priorities
of
of
the
community
may
not
align
with
the
actual
develop
priorities
next
persona-
and
this
is
where
things
I
think
start
to
get
interesting-
is
the
vulnerability
researchers.
So
this
is
abby
and
they're
the
ones
that
run
penetration
tests.
They
try
to
find
the
vulnerabilities
in
software.
I
think
we
all
understand
this
one
fairly
well
as
well.
B
Their
needs
are,
they
want
to
discover
vulnerabilities
before
threat
actors
and
they
want
recognition
and
credit
for
discovering
vulnerabilities
and
that's
really
a
large
motivating
factor
for
this
person,
because
it's
really
how
they
measure
success
and
how
they
grow
their
career
is
receiving
that
credit.
So
it
is
important.
B
Their
pain
points
tend
to
be
unknowns,
caused
by
projects
that
don't
have
these
well-published
disclosure
policies.
So
when
you
find
a
new
vulnerability
in
a
project-
and
you
don't
know
where
to
report
it-
and
you
don't
know-
and
the
person
that
you
do
report
it
to
or
individuals,
they're,
not
responsive,
that's
a
very
large
pain
point
and
it
leads
to
the
third
problem
here.
You
know
when
a
when
a
researcher
has
a
vulnerability
and
they
find
out
that
their
vulnerability
is
exploiting
the
wild
before
they've
been
able
to
publish
their
findings.
B
That's
really
a
worst
case
scenario
for
them,
and
that's
why
you
know
they
tend
to
push
to
to
have
that
publication
be
done
as
soon
as
possible,
because
the
threat
actors
aren't
waiting
the
the
threat
actors,
don't
care
about
disclosure
policies
and
if
they
found
it,
then
somebody
else
could
probably
find
it
as
well.
B
B
And
what
finn
does
is
they
detect
vulnerabilities
that
exist
both
inside
the
client
environment
as
well
as
perhaps
outside
the
client
environment
by
scanning
remotely
and
fit?
You
know
if
I
had
to
name
vendor
names
here.
Finn
is
like
a
callus,
a
tenable
nest,
a
white
source
snick,
and
they
you
know
their
needs.
Are
they
really
want
notice
of
the
new
vulnerabilities
as
they're
discovered
and
disclosed
as
fast
as
possible?
B
B
Then
you've
got
cherry,
so
cherry
is
a
software
developer,
that's
consuming
open
source
code,
so
she
could
be.
You
know,
name
any
fortune.
1000
software,
vendor
and
they're
building
software
to
solve
for
customers
use
cases,
and
they
want
to
be
able
to
use
best
of
breed
open
source
libraries
to
streamline
their
development,
and
they
really
just
want
us.
They
want
to
develop
that
secure
and
high
quality
software.
B
Their
large
pain
point
is
it's
very
difficult
to
know
how
to
secure
these
libraries
and
when
open
source
libraries
have
new
vulnerabilities,
it's
difficult
to
be
informed
of
them,
because
there
again
it
ties
back
to
that
that
central
repository
and
and
lack
thereof,.
B
Finally,
the
second
last
person
we
have
here
is
jacob
and
they're
the
line
of
business
over
owner
out
of
company.
So
basically
cherry
builds
software
and
jacob
is
consuming
that
software.
B
So
this
is
this:
jacob
is
kind
of
the
end
of
the
line
he
he's
the
person
actually
running
the
software
that's
vulnerable
and
what
he's
most
interested
in
is
having
the
software
that
he
runs
for
his
company
runs
stably
and
that
it's
reliable
and
that
it's
secure
and
he
has
to
maintain
that
security
posture
is
mandated
by
a
ciso
biso
and
his
pain
is
that
you
know
the
beso
and
cso
are
escalating.
B
Looking
for
software
to
be
patched
and
his
vendor
doesn't
have
a
patch,
and
you
know
he
also
learns
about
vulnerabilities
before
his
vendors
even
have
a
disclosure
for
the
patch
and
people.
You
know
sometimes
folks
may
wonder
how
can
that
ever
be
the
case,
and
it's
actually
extremely
common.
It's
extremely
common
for
an
end
customer
to
find
out
about
a
vulnerability
before
even
the
vendor
that
has
the
vulnerability
knows
about
it
and
it's
because
of
the
open
source
supply
chain
right.
So
what
will
happen
is
a
vulnerability.
B
A
high
impact
vulnerability
will
hit
the
newswire
or
finn
will
find
a
vulnerability
in
the
environment
that
the
software
vendor
has
not
yet
patched
and
has
not
yet
created
a
disclosure
for,
because
that's
in
a
dependent
library
somewhere
in
the
software.
B
B
The
last
persona
is
basically
what
we
call
the
provider
persona
and
I
initially
forgot
this
one.
B
B
So
this
this
would
be
the
ubuntu,
the
red
hats
of
the
world,
also
the
azures
the
aws,
and
they
need
to
be
able
to
interact
with
upstream
communities.
They
want
to
be
able
to
remediate
those
vulnerabilities
quickly
and
get
them
addressed,
and
their
pain
points
tend
to
revolve
around
again
this
this
this
unknowns
caused
by
projects
that
don't
have
these
well-published
and
public
vulnerability
disclosure
policies.
B
So
there
is
a
nuanced
difference
between
this
persona
and
the
and
the
cherry
persona
in
that
you
know,
cherry
cherry
is
trying
is
building
software
for
solution
and
then
providing
it
to
jacob
she's,
not
just
she's,
not
repackaging
and
redeploying
the
open
source
code.
She
you
know
basically
jacob
is
not
consuming
the
open
source
code
as
the
primary
function,
whereas
if
jacob
is
consuming
from
may
he
probably
is
so
there
there's
a
there's
a
large,
well,
there's
a
subtle
difference
between
those
two
use
cases
that
I
think
create
very
distinct
personas.
B
So
I
don't
know
if
I
want
to
pause
there
for
any
questions,
but
basically
those
are
the
layout
of
the
personas
that
I've
identified
and
now
I'm
going
to
get
into
a
real
real
world
scenario
of
these
and
play
it
all
through
for
you.
So
before
I
do
that.
Does
anyone
have
any
questions?
Let's
pause.
B
D
E
Super
used,
thank
you,
hey
and
jason
teresa
is
great
as
well.
I'd
also
add
the
personas
are
fantastic,
but
one
one
thing
also
to
keep
in
mind
in
all
of
this
is
not
all
those
personas
get
much
of
a
say
in
purchasing
decisions,
and
often
the
purchasing
decision
is
what
drives
a
lot.
So
it's
just
something
to
keep
in
mind.
B
Definitely
yep,
in
fact,
none
of
them
the
only
the
only
one,
the
only
one
here
who,
maybe
has
a
say,
is
jacob,
but
even
jacob
is
probably
not
the
guy
who
purchased
this
thing,
he's
just
the
guy
who's
responsible.
For
being
sure
it
works
right.
You
know
this
is
another
interesting
new.
It's
a
very
good
point
right.
B
A
Yeah,
I
I
think
one
of
the
call
to
actions
after
this
meeting
is
to
like
move
those
persona
descriptions
which
I
also
think
are
excellent
to
our
github
repository
and
then
I
think
we
can
try
to
either
enhance
them
or
add
missing
ones.
So
I'll
make
sure
we
follow
up
on
that.
B
Yeah
for
sure
these
probably
each
need
their
own
document.
I
don't
think
we
want
to
collaborate
on
the
slide
deck,
but
yeah.
It's
a
great
point.
B
So
I
I
took
all
those
personas
and
I
basically
created
a
real
world
scenario,
and
so
it's
a
fictional
scenario,
but
it's
the
typical
scenario
that
I
have
experience
with.
So
the
snare.
It's
pretty
simple,
really
so.
You've
got
this
open
source
library
and
I
just
made
up
silly
names
for
these,
so
open
source
software
library,
the
hot
library
it's
become
very
popular
in
the
industry.
B
So
it's
a
critical
library,
but
it's
not
necessarily
strongly
backed
by
by
any
one
organization,
an
enterprise
software
vendor,
in
this
case,
killer
software,
so
they've
integrated
the
hot
library
into
the
latest
version
of
their
product
and
then
customers
all
over
the
world,
use
this
killer
software
to
run
their
day-to-day
operations.
So
you
know
it's
it's
a
huge
enterprise
software
package,
then
all
of
a
sudden,
a
high
severity
vulnerability
is
discovered
in
this,
this
hot
library.
So
how
does
that
all
play
out?
B
So
if
you
the
way
that
this
diagram
works
is
you
know,
each
persona
has
a
vertical
and
the
timeline
basically
goes
from
top
to
bottom
and
things
that
are
around
the
same.
Horizontal
line
are
happening
more
or
less
in
parallel
or
potentially
in
parallel.
So
what
you'll
see
over
here
is
on
the
left.
You've
got
alice,
they've
developed
this,
this
hot
library
right
and
then
abby
discovers
this
vulnerability
in
hot
library.
B
They
then
disclose
it
back
to
alice
the
developer.
At
that
point,
one
of
two
different
things
could
happen
so
either.
B
They'll
then
publish
the
vulnerability
with
a
patch
on
their
github
repo,
presumably
somewhere
may
or
may
not
have
a
patch.
It
may
just
be
publish
the
the
code
at
that
point
this
this
side,
this
part
of
the
process,
is
more
or
less
completed,
but
then
what
happens?
Is
we
go
into
the
next
phase
of
the
process
here,
where
now
that
there
now
that
there
is
a
public
disclosure
of
this
vulnerability
either
via
one
of
those
two
mechanisms,
it's
now
being
consumed
by
the
vulnerability,
databases,
nvd
and
x4
security
focus,
et
cetera,
et
cetera?
B
So
finn
now
has
picked
up
the
fact
that
this
vulnerability
exists
and
they
start
looking
for
it.
They
start
detecting
this
vulnerability
in
ci,
cd
pipelines
inside
endpoints
inside
the
network,
and
now
that
they're
fun
now
that
they're,
detecting
the
vulnerability
cherry
who's.
This
so
there's
one
of
two
different
paths
you
can
take
here,
and
this
is
where
it
starts
to
get
very
complicated.
B
Actually,
you'll
see
this
blue
arrow
that
goes
across
and
that's
that's
because,
as
soon
as
finn
finds
out
about
the
vulnerability,
jacob
now
knows
about
the
vulnerability
as
well,
and
it
can
completely
bypass
cherry,
and
it
often
does-
and
that's
that's
what
I'm
trying
to
call
out
here
with
this.
This
big
loopy
arrow
to
point
that
out
is
the
fact
that
cherry
actually
often
finds
out
about
whoops
sorry,
what
is
going
on
here?
B
Yeah
sorry
cherry
actually
finds
out
about
vulnerabilities
from
her
own
customer,
and-
and
this
is
something
that
you
know
if
you're
not
deeply
involved
in
this,
you
might
find
this
surprising,
but
you,
this
is
actually
extremely
common,
that
a
customer
will
basically
go
to
their
vendor
and
say:
when
are
you
gonna
have
a
patch
for
x
and
that's
almost
it's
it's
either
before
or
at
the
exact
same
time
that
vendor
x
is
basically
running
around
trying
to
figure
out
what
this.
This
vulnerability
is.
B
At
that
point,
the
vendor
basically
there's
two
different
things
that
they
do.
They.
They
publish
the
fact
that
they
have
that
vulnerability,
and
then
they
release
a
patch
with
the
fix
to
the
vulnerability.
These
two
things
they
usually
happen
at
the
exact
same
time.
So
in
this
in
this
diagram
here,
it's
showing
that
they
publish
the
vulnerability
and
then
release
the
patch
later,
but
the
reality
is
that
these
usually
tend
to
happen,
either
at
the
same
time
or
extremely
close
to
each
other.
B
The
the
vendor
tends
to
not
want
not
publish
a
vulnerability
without
a
fix
if
they
don't
have
to
the
other
interesting
side
of
this.
Is
you
know
when
you
look
at
jacob's
vertical,
so
they're
going
back
and
forth
with
their
vendor.
B
I'm
trying
to
find
out
when
they're
going
to
get
this
patch
and
then
there's
often
a
mitigation
that
happens
before
so
the
vendor
will
tell
jacob
okay,
we
don't
have
the
patch
yet
because
we
haven't
heard
you
know
there
actually
isn't
one
available
yet,
but
if
you
go
and
deploy
this
compensating
control,
you
won't
be.
You
know,
the
vulnerabilities
impact
will
be
severely
reduced
and
that
might
be
disabling
a
feature
it
might
be
turning
off
a
service.
Maybe
it's
blocking
a
port.
Maybe
it's
you
know
changing
some
credentials
temporarily,
etc.
B
The
compensating
controls
will
be
a
lot
of
different
things,
but
basically
you
know
they'll
tell
their
customer
what
to
do
to
mitigate
the
vulnerability
before
the
patch
will
actually
get
out.
B
So
that's
pretty
much
it
for
this
flow
and
and
I'll
pause
there.
If
there's
any
more
questions
on
this,
and
then
I
just
have
one
more.
G
Slide
thoughts,
questions.
What
do
you
think
the
biggest
culprit
is
for
cherry
fighting
after
jacob?
Do
you
think
it
may
be
a
lack
of.
B
B
So
the
reason
that
that
happens
is
because
you
know
when
you
think
about
so
abby,
finds
this
vulnerability
right
and
then
lets
the
software
developer
know
about
it,
regardless
of
if
it
takes
the
path
in
the
left
or
the
right
when
it
there.
There
is
no
communication
to
cherry
about
that
vulnerability
until
it's
been
disclosed
oops.
B
B
So
she
doesn't
know
about
the
vulnerability
until
it's
already
been
patched
and
disclosed
right
and
then,
as
soon
as
that
happens,
everybody
finds
out
about
it.
Finn
finds
out
and
cherry
finds
out
and
jacob
finds
out
all
the
same
time
right,
because
the
way
that
it
works
and
what
what
will
often
happen
is
so
everybody
will
find
it
at
the
same
time,
but
cherry's
doing
a
lot
of
things
and
and
jacob
who's
pr.
You
know
it's
his
primary
job
to
making
sure
that
the
solution
is
secure.
So
this
is
the
top
of
his
priority
list.
B
He'll
come
to
cherry
and
say
I
just
found.
I
just
you
know,
got
a
news
flash
about
this
vulnerability
in
package
xyz
that
you're
providing
me
when
is
it
going
to
be
fixed
and
the
response
will
be.
You
know,
okay,
we'll
get
back
to
you
with
that
four
hours
and
then,
during
that
four
hour
window,
that
cherry
will
be
trying
to
figure
out
when
she
can
get
it
patched
because
building
a
patch
for
that
vulnerability.
You
know
it
can
take
a
long
time.
It's
it's.
It's
often
not
simple
and
cut
and
dry.
G
What
I,
what
I
sort
of
understood,
was
that,
when
abby
and
alice
are
communicating
about
the
vulnerability
disclosure
that
news
of
the
patch
gets
to
jacob
before
he
gets
to
cherry.
B
B
Yeah
all
right
jason.
I
think
this
is
a
great
jumping
off
point.
I
think
there's
some
nuance
and
complexity
between
the
alice
and
abby
that
we're
missing
yep.
B
B
If
it's,
if
it's
a
lar
right,
if
it's
a
severe
vulnerability,
then
there's
going
to
be
a
whole
other
row
in
here
and
there
I
don't
think
there
is
one
finder
persona,
there's
a
lot
of
different
motivations
and
reasonings
and
paths
into
that
pink
box
that
I
think
we
would
need
to
either
have
multiple
personas
or
augment
your
abi
persona
with
those
kind
of
different
perspectives
of
just
you
know,
you
have
academics,
security,
researchers,
you
have
national
security
folks,
you
have
customers
and
providers
all
kind
of
contribute
into
that
box
on
some
level.
A
Yeah
like
when
I
was
when
I
was
looking
at
it
like,
I
immediately
like
recalled
that
vince
conversation
we
had
the
other
day
or
other
like
embargo
kind
of
periods
for
vulnerabilities,
but
I
I
think
the
assumption
here
is
that
the
like,
either
the
project,
is
popular
enough
or
the
user
base
or
the
there
are
this
sufficient
number
of
cherries
in
the
world
that
coordinated
action
is
just
not
feasible,
but
but
I
think
we
we
don't
have
to
like.
A
I
think
we
can
have
like
multiple
different
workflows
that
are
typical
under
some
circumstances
right,
so
we
don't
have
to,
I
think,
focus
on
just
one
workflow
to
kind
of
have
all
the
personas
in
it
and
all
the
possible
circumstances
like,
for
example,
like
there
is,
as
you
mentioned
like,
there
are
academics.
That
typically
result,
I
think
in
large-scale
disclosure,
because
they
typically
like
analyze.
You
know
a
bunch
of
different
projects
and
those
disclosures
tend
to
be
like
large-scale
as
well.
Okay,
but
overall,
like
this
is
fantastic.
B
Yeah,
and
so
it's
a
good
point-
merson
there
right
like
I,
I
think,
one
of
the
large
one
of
the
differences
between
this
scenario
and
and
this
this
2b
scenario
by
the
way,
so
that
that
I
think
we
need
to
play
out
that
hasn't
been
laid
out.
Yet
the
one
with
the
provider
right.
One
of
the
large
differences
is
the
sheer
number
of
of
cherries
versus
maize
right.
B
So
you
know,
if
you
have
to
look
at
if
you're,
trying
to
coordinate
disclosure
among
among
distribution,
maintainers,
right
and
providers,
you
know
you've
got.
You
know
ten
five
to
ten
large
ones
to
coordinate
amongst,
whereas
when
you're
talking
about
the
cherries
you're
talking
about
thousands,
thousands
of
extremely
major
vendors
you'd
have
to
deal
with
right.
It
gets.
It
gets
logistically
extremely
extremely
complicated
if
you're
trying
to
coordinate
that.
B
So
yeah
this
is
this
sorry
go
ahead.
Well,
I
think,
with
your
cherry
pain
points,
this
working
group
can
actively
help
create
some
recommendations
and
tools
and
documentation
to
help
coach
the
consumer
end,
and
I
think
the
developer
best
practices
group
that
I'm
a
part
of
can
help
with
the
first
two
kind
of
personas
and
help
provide
open
source
developers,
tools
and
methodologies
and
help
them
get
set
up
for
success
so
that
that
interaction
with
the
finder
can
become
more
productive.
C
B
So
this
is
pretty
much
all
I
had
so
I
did
have
that
scenario.
Number
two
I'd
like
to
play
out
at
some
point
to
create
a
kind
of
flow
like
that,
but
we
weren't
really
able
to
get
that
done
for
today,
but.
A
Cool
that
was
that
was
perfect.
I
think
like
the
next
step,
for
us
here
is
I'll.
Definitely
like
merge
the
pr
with
the
slide
deck,
so
it's
available
for
everyone
and
we'll
reference
it
from
the
meaning
notes.
A
But
I
think
the
next
immediate
step
is
extracting
the
information
about
personas
and
storing
them
as
individual
markdown
documents
in
the
in
in
our
github
repo,
because
that
and
thanks
to
like
nicole
for
that
idea,
then
it
will
allow
us
to
build
other
artifacts
for
use
cases
and
the
table
that
kind
of
maps
all
this
together.
A
That
crystal
has
put
together
and
we're
going
to
be
able
to,
like
you
know,
cross-reference
the
use
cases
personas
and
perhaps
even
like
the
misalignment
between
those
things,
and
I
think
that's
going
to
be
that's
going
to
be
awesome.
So
thanks,
jason,
so
I'll
pencil
you
in
for
for
the
28th.
A
If
you're
up
for
that
and
we
can
explore,
we
can
explore
the
second
flow
and
we
also
have
risk.
I
wanted
to
tell
us
more
about
how
white
source
consumes
the
vulnerability
disclosed,
vulnerability,
information
so
risk.
Take
it
away.
E
E
E
I
think
anybody
new
to
this
area
is
generally
surprised
by
how
messy
the
raw
data
is
in
this
area,
partly
because
maybe
a
lot
of
us
underestimate
how
complex
it
is.
Sometimes
it's
not
just
like
a
one-to-one
mapping
between
a
vulnerability
and
a
package,
for
example,
and
then
you
have
multiple
fixed
in
streams
and
things
like
that
and
then
in
general.
I
think
it's
there's
a
lot
to
be
improved
in
terms
of
how
well
structured
and
semantic
that
is,
but
basically
there's
a
manual
verification
of
that
initial
past
data.
E
What
we
do
goes
a
little
bit
beyond
the
general,
so
we
do
identification
of
the
fixed
in
commits
as
well
in
the
original
source
code
keeping
in
mind.
This
is
open
source
we're
talking
about,
so
we
can
do
that.
We
then
do
an
identification
and
fingerprinting
of
affected
components
and
files,
so
essentially
identify
the
commit
where
it
was
fixed
and
we
identify
or
fingerprint
the
affected
files
before
they
were
fixed.
E
And
then
we
do
a
verification.
Ourself,
like
a
sandy
check
of
the
fixed
inversions,
that
we
got
from
sort
of
step,
one
and
two
versus
what
we
have
identified
in
the
components.
It
is
uncommon,
but
not
rare
that
the
fixed
inversion
can
actually
be
wrong.
Sometimes
you
know
someone
prepared
the
cve
description
saying
a
certain
version
was
going
to
be
fixed
in
it's
actually
a
patch
after
it,
and
things
like
that
or
people
didn't
correctly
patch,
a
stream,
and
things
like
that
so
anyway.
E
This
first
step
is
really
a
bit
of
human
verification
of
the
data.
E
E
The
higher
latency
approach,
which
is
used
in
some
areas,
is
the
next
time
somebody
does
a
scan
of
their
projects.
Then
they'll
get
new
results,
you
know
so
yesterday
they
scanned
and
there
wasn't
a
vulnerability
and
then
today
there's
a
scheduled,
scan
and
there's
your
vulnerability,
but
this
is,
I
call
it
high
latency.
E
What
we
do
and
recommend
is
a
lower
latency
approach,
and
that
is
that
when
those
new
entries
come
into
a
database,
there
is
an
immediate
cross-reference
between
your
knowledge
of
what
the
project's
already
had.
You
know
so
who's
using
this
package,
this
version-
and
so
at
that
point
you
know
immediately
who's
affected
and
then
the
alerts
go
out.
So
this
is
why
so,
this
is
us,
I
guess,
as
sort
of
as
finn,
and
this
is
why
cherry
and
jake
can
get
alerts
essentially
simultaneously.
E
Let's
say
that
they
have
both
existing
scans
in
the
database.
With
packages
versions,
fingerprints,
there's
a
match
to
both
of
them.
They
both
get
alerted
but
as
mentioned
by
jason,
sometimes
cherry
might
have
faster,
better
alerts
and
that's
why
she'll
see
it
before
jacob?
Oh
sorry,
the
other
way
around
jacob
might
have
better
than
cherry.
E
E
The
industry
trend
in
software
development
is
towards
using
you
know,
deterministic
builds
with
versions
and
lock
files
checksums
that
type
of
stuff,
and
that's
good,
and
especially
good
for
security,
because
it
means
you
know
exactly
what's
going
in
to
the
sausage,
but
also
package
lock
files
with
fixed
inversions.
It
makes
for
very
easy
identification
and
fixing.
So
you
know
if
you
can
exactly
identify
what
versions
going
into
the
software,
and
then
you
can
exactly
identify
affected
version
ranges.
That's
a
pretty
easy
matching.
E
We
observed
in
2019
that
that
around
85
percent
of
nvd
disclosures
for
open
source
were
disclosed
with
a
fixed-in
version
already,
meaning
that
actually
industries
got
very
good
at
you
know,
fixing
it
releasing
and
then
disclosing,
which
means
that
the
the
answer
is,
you
know,
update
it's
not
like.
You
have
a
vulnerability
and
there's
nothing
really.
You
can
do
unless
you
monkey
patch
it
you
actually
can
update.
E
In
many
cases,
however,
not
all
package
managers
support
this
type
of
deterministic
build
so
also
again,
as
jason
mentioned,
open
source
might
be
shipped
inside
commercial
software
like
a
docker
image,
with
no
possible
manifest.
So
if
you're,
only
relying
on
you
know
very
well
documented
manifests,
you
will
miss
things
so
scanning
file,
fingerprints
and
then
comparing
that,
against
you
know,
a
database
of
known
open
source
fingerprints.
E
In
terms
of
tooling
in
the
software
development
life
cycle,
probably
the
people
in
this
group
understand
this,
but
a
lot
of
people
do
not
outside
so
vulnerabilities
are
rarely
introduced
in
merge,
request,
pull
request.
This
is
one
of
the
greatest
misunderstandings,
people
kind
of
think
like
hey.
If
we
just
shift
security
left
far
enough,
we
can
fix
security
and
that's
not
how
it
works.
E
You
know,
juice
out
of
the
lemon
in
terms
of
pre-production
checks
commits
and
scans
we're
already
getting
the
point
where
people
have
reached
almost
an
optimum.
For
that,
like
I
said
this,
as
people
coming
in
the
disclosure
part
probably
understand
that.
Well,
that
vulnerabilities
are
discovered
in
things
you
already
have,
but
the
majority
industry
believes
like
we
just
got
to
stop
developers
putting
vulnerabilities
in
our
software
and
that's
just
not
how
it
works.
F
E
E
E
F
E
H
E
But
by
the
way
your
point
is
not
nitpicking,
it
is
actually
very
correct
because
I
mean
there
is
one
day
people
will
get
better
at
also
scanning
open
source
code
themselves.
You
know
the
same
way:
jacob
beats
cherry
to
to
the
vulnerability
at
times.
E
E
There
are
many
types
of
security
like
secrets
and
you
could
even
say
fuzzing
stuff.
Firewall
rules,
there's
many
areas
of
security
where
your
goal
should
be
zero.
You
know,
let's
have
zero
in
production.
You
know
zero
secrets.
Zero,
firewall
mistakes
zero
this,
but
to
aim
for
zero,
open
source
security
problems
in
production
is
misunderstanding.
The
problem.
F
F
E
E
Like
you
know,
if
I
was
an
engineering
manager,
you
know,
and
people
had
secrets
or
other
problems
in
production,
you'd
say
well.
How
did
that
get
there?
How
do
we
get
better
at
not
getting
them
in
but
for
open
source
security?
You
have
to
be
realistic.
E
One
other
thing:
vulnerability,
usage
analysis,
so
one
of
the
reasons
why
we
also
do
this
manual,
verification
of
files
and
components
that
are
affected
is
because
it
allows
us
to
do
effective
usage
analysis.
So
with
eua
project
code
can
be
loaded,
so
jacob's
code
can
be
loaded,
so
I
keep
getting
mixed
up.
Yes,
jacob's
code
can
be
loaded
and
ast.
Passing
can
basically
tell
you
which
bits
of
that
tree
can
be
reached
and
which
bits
are
unreachable.
E
Open
source
vulnerabilities
are
often
in
transitive
dependencies,
and
you
know
something
like
lowdash
might
have
100
functions
and
a
library
that
uses
lowdash
may
only
use
five
of
them
and
that
keeps
coming
up
vulnerabilities
in
the
other
95..
E
The
reality
is,
if
you're
alerted
to
a
transitive,
low,
dash
vulnerability
or
even
a
direct
low-dash
vulnerability
for
a
function,
you
never
call.
That
is
a
false
positive.
So,
in
our
observations,
as
with
customer
use,
80
of
raw
vulnerability
alerts
are
for
unreachable
code
and
open
source
dependencies,
which
means
today,
ballpark
80
of
vulnerability.
Alerting
is
false,
positives,
minimum.
B
This
is
one
this
one
in
particular,
is
one
of
the
ones
I've
been
trying
to
raise.
The
importance
of
the
s-bomb
groups
like
how
important
it
is
to
have
like
to
me
an
s-bomb
should
have
that
information
in
it
like
I'm
using
this
vulnerability,
and
these
are
the
entry
points
I'm
using
in
it,
because
that
this
happens.
This
is,
I
agree
with
that
number.
It's
it's
huge
yeah.
E
It's
really
big,
it
could
be
bigger,
we
don't
want
to
be
accused
of
exaggerating,
but
we
find
a
minimum
80.
all
right,
a
couple
more
left.
Actually
this
is,
I
think,
the
last
one-
and
one
thing
I
wanted
to
point
out
is
there:
are
people
have
differing
priorities
and
I'd
say
in
a
way
it's
a
little
bit
shifting
priorities
as
well
like
from
altenew
in
terms
of
accuracy
versus
speed
trade-offs.
E
So
before,
like
in
the
old
days
when
white
source
was
first
in
the
security
game,
vulnerability
data
was
much
more
messy
and
less
well
just
structured
and
described
than
it
is
today,
so
human
verification
was
essential
to
preventing
false
positives.
E
Basically,
there
was
a
point
where
you
know:
security
users
were
the
prime
users
of
this
type
of
software,
and
if
you
were
constantly,
if
you
tried
just
doing
like
fuzzy
matching
of
disclosures
and
stuff,
you
would
send
a
lot
of
nonsense
their
way,
so
that
human
verification
step
that
we
have
was
a
necessity
in
the
early
days
and
as
I
mentioned,
there's
some
advantages
to
it
right
now
as
well,
but
this
is
shifting
a
little
bit
and
we're
finding
enterprise
users
in
particular.
E
Don't
want
slow
positives
and
relate
a
little
bit
again
to
json,
slides
about,
like
the
vendor,
being
told
by
the
enterprise
and
things
like
that.
It's
a
little
bit
of
like
an
arms
race.
These
days
where
people
want
to
know
as
soon
as
possible
and
even
compare
in
terms
of
minutes
and
things
like
that.
To
some
extent
it's
unjustified
in
other
ways.
It's
it's.
It
is
justified.
E
There
is
a
term
I
love
to
say
about
open
source
security,
which
is
the
enemy,
always
gets
a
vote.
So
you
can't
just
sort
of
choose
like
well
I'm
busy
this
week
or
I'm
going
to
opt
out
of
this
because
I
just
don't
want
to
because
they're
disclosed.
So
even
if
the
enemy
hadn't
discovered
the
same
problem
that
the
researcher
did
once
it's
disclosed,
the
vote
of
the
enemy
is
I'm
going
to
probe
and
scan,
and
things
like
that.
E
So
from
our
point
of
view
as
the
fin
in
that
one,
we
now,
you
know
internally
have
the
concept
of
trusted
feeds.
So
there
are
certain
feeds
that
are
much
better
structured
and
we
know
already
have
had
human
triaging
in
it,
and
so
for
those
we
have
the
option
to
kind
of
expedite
those
for
real-time
matching
like
like
alert
before
human
verification,
and
that's
because
the
the
accuracy
is
good
enough
that
that
the
potential
for
false
positives
is
not
a
concern
to
our
users,
who
would
prefer
to
get
alerted
right
away.
A
A
I
like
this
is
just
me
thinking
out
loud,
but
I
think
it
would
be
super
interesting
to
maybe
release
this
as
an
open,
ssf
kind
of
white
paper
because
risk
you
might
be
right
that
there
are
a
lot
of
people
kind
of
have
like
an
intuition
that,
like
it's
a,
I
don't
know
like
a
winnable
game
right,
I
was
reading
a
sam's
article
on
vulnerability
management
once
that
started.
Something
like
this.
A
You
can't
win
at
this
so
like
you
need
to
kind
of
know
what
you're
doing
and
what
to
expect
right,
and
I,
I
think,
there's
even
based
on
this
discussion
we
had
in
this
meeting
today.
It
sounds
like
there's
a
lot
of
nuance
right.
You
know
personas
workflows
like
what
do
we
expect?
When
do
we
discover
vulnerabilities?
How
far
left
can
we
go
and
how
much
do
we
really
need
to
leave
right
in
the
process
to
be
able
to
manage
that.
E
Yeah
one
other
thing
I'd
add
is
that
with
the
shifting
left,
that's
happened
in
the
last
two
to
three
years
that
it
does
mean
that
developers
become
more
responsible
for
handling
the
alerts.
That
also
means
that
the
false
positives
you
know
they
they
hurt
a
lot
more.
I
mean
a
security
professional
might
realize
that's
just
part
of
the
game.
That's
just
how
it
works
is
you
know,
evaluate
prioritize,
can't
fix
everything,
but
developers
get
sense.
E
Stuff
saying
this
is
a
high
priority
critical
priority,
and
then
they
dig
into
it
and
discover
that
you
know
it's.
It's
not
being
touched,
the
the
prioritization
of
reachable
versus
unreachable.
It
can
even
have
like
a
double-sided
too,
because,
for
example,
you
know
people.
You
know
people
report
to
me
on
some
of
my
projects,
vulnerabilities
that
they've
found
through
their
scanning
or
whatever,
and
they
might
be
like.
E
I
literally
had
one
it's
a
bit
more
complicated
but
there's
literally
a
dev
dependency
of
a
dev
dependency
and
yeah
and
people.
You
know
report
that
so
sometimes,
even
if
you
know
that
it
is
like
ineffective
or
unreachable
you,
you
may
get
so
many
of
your
jacobs,
alerting
you
to
it
that
you
still
want
to
get
rid
of
it.
A
Yeah
and
and
honestly,
like
you
as
an
open
source
developer
depending
on
the
package
manager,
have
relatively
few
options
like
suppress
those
issues,
because
this
this
is
typically
raised
not
by
your
package
manager,
is
raised
by
your
scanning
tools
and
if
you
have
an
open
source
project,
there's
a
fat
chance
that
it
will
pop
up
in
scans
and
a
number
of
different
scanning
tools
that
your
cherries
are
using.
Yeah
and
not
you
as
a
developer.
So.
E
That's
a
I've
seen
cases
where
people
are
just
harassing
open
source
maintainers,
because
npm
audit
has
reported
and
they're
like
it's
your
fault,
it's
your
fault,
you
got
to
fix
it
and
it's
like
completely
like
I
said
you
know,
unreachable
ineffective,
but
you
know
people
are
like
angry
because
they're
saying
I
can't
deploy
to
production
because
we
have
a
rule
that
says:
npm
audit
fails,
you
know,
fail
the
pipeline
things
like
that
and.
B
B
So
there
will
be
there
will
be
entire
classes
of
of
software
that
are
regulated,
that
that
cannot
be
deployed
with
xyz
vulnerable
packages
and
because
the
scan
says
that
it's
vulnerable,
even
though
the
code
is
unreachable
because
we
don't
have
any
kind
of
an
audit
trail
or
supply
chain,
s-bomb,
that's
reliable
right.
You
have
nothing
to
fall
back
on
right.
It's
not
good
enough
to
just
stand.
B
It's
not
good
enough
to
just
say
it's
not
reachable.
You
have
to
be
able
to
prove
it
right,
yeah
and
that's
where
the
onus
responsibility
falls
upon
that
development
team
or
that
product
manager
that
is
leveraging
these
free
and
open
source
pieces
of
code
to
have
some
level
of
investment
into
that,
not
just
to
say
it's
that
upstream
developers
responsibility
sure,
but
they
get
no
compensation.
Aside
from
it's
fun,
it's
part-time
thing.
I
thought
it's
really
awesome
idea
so
again
trying
to
harangue
the
upstream
developer
is
not
a
worthwhile
endeavor.
B
F
F
If
I
could
quickly
jump
in,
I
mean
if
I'm
the
open
source
developer,
that
says:
hey
fix
it
and
I'm
going
to
oh
what
contract
did
I
sign
with
you?
Oh
none.
How
much
are
you
paying
me?
Nothing?
Okay,
very
cute!
You
may
go
on
with
your
life.
Please
stop
bothering
me.
I
think
a
lot
of
developers
do
actually
respond
and
I'm
grateful
to
them,
but
you
know
there's
only
so
much
time
in
the
day.
F
I
will
counter,
though,
that
I've
seen
the
other
direction
where
the
vulnerability,
something
is
claimed
to
be
a
vulnerability
tools,
claim
it's
a
vulnerability.
I
think
the
its4
paper
had
a
great
example
of
this.
You
know
they
were
sure
that
it
couldn't
be
exploited
a
year
later.
Oh,
look,
there's
the
exploit.
F
A
Yeah,
that's
that's
true.
That's
true!
Okay
risk!
Thank
you
there's.
Definitely,
I
think
a
lot
too
a
lot
to
to
thank
and
like
thanks
from
you
know,
I
think
the
good
discussions
and
a
few
good
points
florencio
here.
I
think
you
wanted
to
add
to
that,
because
I
think
you
you
started
to
tackle
this
topic
in
one
of
the
other
working
groups.
So
if
we
have
a
few
more
minutes,
then
I'll
definitely
be
super
willing
to.
Let
florence
here
tell
us
more
about
his
initiative.
I
Yeah,
the
the
initiative
is
about
is
related
to
to
this.
What
a
open
source
project
says
is
that
they
receive
a
lot
of
feedback
about
vulnerabilities.
It's
about
the
the
reporting
of
a
vulnerability
from
a
researcher
to
the
open
source
project,
maintainer
and
sometimes
project
maintainers
receive
like
dumps
of
scanning
tools,
a
damp
of
a
fuser
tool
or
just
a
findings
of
different
different
tools.
So
this
this
initiative
was
aimed
to
to
develop
a
maybe
yes
little
projects
aim
to
to
work
on.
I
Communicating
to
the
community
how
to
better
report
vulnerabilities,
for
example,
publishing
a
checklist
of
things
that
you
got.
You
can
do
before
reporting
up
a
vulnerability
like,
for
example,
saying
if
you
can
develop
a
patch,
that's
the
the
best
thing
you
can
do.
Maybe
you
cannot
develop
or
contribute
with
a
patch,
but
maybe
you
can
send
a
reproducer
if
you
cannot
send
a
reproducer.
Maybe
you
can
point
where
is
the?
Where
is
the
vulnerability
in
the
in
the
code
in
the
in
the
code?
I
But
please
don't
send
just
a
the
result
of
a
scanning
tool
of
a
far
or
a
faster
to
the
project
maintainers
because
they
have
like
all.
We
have
a
limited
quantity
of
time
to
invest
and-
and
it
is
better
to
invest
it
on
really
fixing
the
vulnerabilities
and
not
reaching
them
or
or
working
on
discarding
the
vulnerability.
I
H
I
think,
and
anyone
else
feel
free
to
chime
in,
but
we
were
trying
to
at
least
initially
not
necessarily
create
any
new
formats
for
anything,
but
we
were
going
to
try
and
reference
ones
that
were
out
there
and
suggest
them.
So
if
you're
like
a,
I
wasn't
100
clear:
were
you
recommending
creating
a
brand
new
template
or
were
you
recommending
kind
of
pointing
to
templates.
I
A
I
I
think
this
might
be
one
of
those
topics
where
it
actually
spans
multiple
different
working
groups
in
areas
to
me,
there's
definitely
an
element
of
promoting
a
good
security
policy.
That
explains,
you
know
what
goes
into
a
good
vulnerability
report,
but
you
know
good
best
practices
and
tooling.
Definitely
I
see
some
overlap
there
as
well.
A
I
also
realize
that
probably
doesn't
make
it
any
easier
to
kind
of
get
traction
on
the
on
this
initiative.
So
sorry
for
that,
but
I
think
like
if
you
could
create
an
issue
in
this
working
groups-
github
repo.
I
think
that
would
be
a
good
place
to
discuss
like
what
falls
within
our
scope
and
where
we
could,
where
we
could
make
progress.
A
Perfect
cool
amazing,
so
we've
ran
over
a
little
bit,
but
that
was
that
was
great.
So
the
next
step
is
what
I'm
gonna
do.
Is
I'm
gonna
extract
the
persona's
information
and
work
shamelessly
just
steal
them
from
jason's
presentation
and
start
markdown
documents,
and
then
we
will
collect
the
use
cases
that
are
right
now,
flaunting
around
in
those
three
or
four
three
or
four
google
docs
and
well
we'll
grant
you
we're
gonna,
take
it,
take
it
from
there
or
open
steel
or
open
source.
A
That's
thanks
for
the
comment.
Okay
and
our
next
meeting
last
one
this
year
is
gonna,
be
on
december
28th.
So
all
going
to
be
collating
the
agenda
really
soon
yeah.
Thank
you.
That
was
that
was
another
very
good
meeting.
Thank
you
all.
Take
care.