►
From YouTube: OpenSSF Vulnerability Disclosures WG (May 4, 2022)
A
A
A
E
A
A
G
A
I
posted
a
link
to
our
agenda,
go
ahead
and
put
that
in
the
open
section.
We
would
love
to
talk
about
that.
I
have
a
couple
business
things
to
work
on
and
then
we'll
jump
to
the
opens,
and
then
hopefully
we
can
work
on
our
cbd
guide.
Very
excited.
Okay,
thank
you.
You're
welcome,
sir
all
right
everybody
today
may
the
fourth
be
with
you
all.
This
is
the
may
4th
edition
of
the
best
working
group
within
the
open,
ssf,
the
vulnerability
disclosures
working
group.
G
Usually
I
work
in
the
security
in
the
identified
security
threat
working
group
and
in
this
period
we
are
working
on
alpha
project,
the
half
omega
project
and
also
on
the
security
insight
project,
and
I
would
like
to
present
it
to
you,
because
I
am
moving
and
jumping
from
different
working
group
to
present
of
this
project,
because
it
is
important
to
be
aligned,
especially
because
there
are
a
lot
of
communication
risks.
So
I
am
here
for
this
reason.
A
All
right,
so
a
couple
points
of
order
before
we
jump
into
the
presentation,
I
would
ask
everyone,
especially
our
friends
that
might
be
either
in
or
adjacent
or
interested
in
going
to
europe
to
please
consider
submitting
abstracts
to
the
open
source
summit
in
europe.
We
have
the
north
america
summit
going
on
in
june,
and
this
is
kind
of
the
sister
brother
offering
of
that.
A
I
would
like
to
table
the
conversation
on
the
charter.
We've
had
a
lot
of
talks
at
the
tac
level
about
it
and
I
think
we're
close
to
having
a
more
unified
approach
and
really
the
big
sticking
point
is
that
the
tse
wording
about
how
things
are
approved
at
the
working
group
level.
So
if
anyone
has
an
objection,
let
me
know
otherwise.
Please
continue
to
provide
your
feedback
in
that
issue
and
I'll.
Let
you
all
report
back
from
what
the
attack
has
to
say
once
they're
done
tackifying,
it.
D
A
G
G
So
this
yamalphi
would
like
to
give
information
useful
for
bot
for
the
researcher,
for
the
developers
and
also
for
the
maintainer
to
give
more
information
and
contact
to
the
community,
and
there
is
a
an
important
part
related
to
the
vulnerability
reporting,
and
I
think
that
is
important
or
it
can
be
related
to
your
topic
to
the
this
working
group.
So
I
have
added
some
voice,
some
properties
in
the
prop
in
the
big
property,
vulnerability
reporting,
where
there
are
security
contacts
linked
to
the
security
policy.
G
If
there
is
a
back
bounty,
if
the
project
pay
for
vulnerabilities,
how
or
where
reporting
relativity
is
and
which
kind
of
vulnerabilities
a
particular
project
can
a
chapter
I
mean
you
can
accept
everything,
but
maybe
you
want
to
vocalize
or
you
want
to
prioritize
some
report
instead
of
other
one
and-
and
I
would
like
just
your
feedback
about
this-
I
can
show
the
screen
or
you
can
find
it
in
the
link,
but
maybe
it
is
better
if
I
shut
the
screen.
Wait.
A
second.
G
G
This
is
I
mean
this
is
a
collection
of
link
information.
So
technically
we
are
not.
This
is
not
a
security
policy.
This
is
just
a
file
that
scanner
and
people
can
read
quickly
like
the
security.txt
to
find
the
information
that
they
are
looking
for.
At
the
same
time,
for
example,
I
have
some
dupes
people,
especially
develop
developer,
ask
the
easy
way
to
communicate
with
the
security
researcher.
What
are
the
vulnerabilities
that
they
want
to
receive,
but
at
the
moment
I
haven't
found
a
good
taxonomy,
so
I've
used
the
obas
top
10.
G
And
it
is,
I
want
just
to
present
to
this
working
group
to
receive
medi
feedback
to
give
visibility
to
this
project
project,
because
I
think
it
would
be
a
sort
of
standard.
It
would
be
a
standard,
so
it
is
important
that
we
are
aligning,
especially
on
the
first
version,
because,
yes,
we
can
improve
it,
but
at
the
same
time
it
is
important
to
have
yes
a
good
alignment
before
the
launching,
and
that
is
so.
I
don't
know
if
you
have
any
feedback
for
me.
I
don't
know.
G
If
you
have,
you
can
suggest
me
a
better
taxonomy
for
the
in-scope
out
of
scope.
It's
not
easy
to
define
what
is
in
scope
without
scoff
and
autoscope.
I
know
I
have
tried
to
find
something
that
is
sort
of
metic
and
always
part
of
them
is
very
used,
but
I
have
added
also
the
other
boys
so
and
it
it
doesn't
it
doesn't.
G
I
mean
I
think
that
researchers
should
read.
Also
the
security
policy.
There
is
the
link
in
the
schema
to
other
security
policy,
so
it's
not
just
something
that
you
can
use
without
reading
the
security,
dot
md
or
the
security
page,
but
it
is
something
that
scanner
can
collect.
For
example,
you
can
create
database
if
projects
start
to
use
it.
So
the
goal
is
to
improve
the
visibility
and
give
a
sort
of
security.txt.
G
A
A
G
It
is
a
good
question
and
I
have
prepared
the
presentation
for
the
cf
and
c
group.
I
don't
remember
the
name
of
the
moment,
sorry
and
because
these
are
common
questions,
so
the
reason
why
we
need
this
is
because
we
have
a
lot
of
standards
that
are
different
and
we
have
seen,
for
example,
using
the
scorecard
that
their
patch
foundation
that
have
good
standard,
but
just
for
the
organization
that
ever
tweeted
about
this
problem.
So
this
security
score
cards.
G
G
So
this
file
would
like
to
solve
this
problem
because
we
want
to
offer
a
standard
for
repo
that
are
independent
by
the
platform
so
github
and
similar
that
you
don't
need
to
force
you
to
move
your
documentation
because
you
just
need
to
add
the
link
in
the
yammer.
So
you
have
the
security
policy
in
your
website.
G
You
don't
need
to
rewrite
and
the
security
and
the
in
every
report
that
you
have
you
just
need
to
add
a
link
to
this
file
that
can
be
the
same
or
very
similar
for
every
project
that
you
have.
If
you
are
an
organization
or
a
foundation,
if
you
have
just
a
single
big,
open
source
project,
you
can
just
create
follow
this
and
there
are
two
risks.
The
first
one
is
the
another
standard
that
we
add
and
we
continue
to
add
standard.
So
this
is
a
problem
and
we
need
to
try
to
avoid
this.
G
This
scenario-
and
I
suggest
two
things-
I
think
that
open
source
open
ssf
is
in
a
good
position.
We
have
a
lot
of
big
companies
that
work
or
contribute
directly
to
opera
ssf.
We
have
the
scorecard
that's
very
popular
and
we
have
some
open
source
project
in
our
foundation,
of
course,
and
there
are
a
lot
of
open
source
projects
that
follow
this
project.
So
one
suggestion
is
to
coordinate
internally
and
with
the
alpha
omega
project
that
I
have
a
big
list
of
bib
open
source
projects
that
are
in
touch
with
openssf.
G
So
the
plan
is
to
coordinate
our
effort
to
implement
this
file,
especially
for
alpha
projectors
or
important
open
source
project.
They
open,
ssf
repo,
just
like
the
scorecard
and
if
we
are
able
to
convince
also
important
officers
project
by
google,
microsoft,
other
companies
that
are
involved
within
openssf,
because
in
this
way,
if
we
have
a
big
project
that
start
to
use
it,
other
projects
should
follow
us
and
if
we
can
have
any,
of
course,
a
good
com.
Yes,
it's
not
so
easy.
You
are
right,
but
there
are
other
two
points.
G
Also
security.60
is
not
implemented
in
every
open
in
every
website,
but
they
there
is
an
official
lfc.
It
is
a
sort
of
standard
for
security
people
and
it
it
requires
time.
But
now
we
have
scanner
that
try
to
look
for
that
file
and
people
are
in
yeah.
If
a
person
know
these
the
file,
usually
they
try
to
add
it,
usually
not
everyone,
but
more
you.
If
you
are
bigger,
if
you
have
an
important
website,
you
try
to
add
these
two
to
be
compliant
or
to
follow
a
best
practice.
G
That
is
easy,
but
at
the
same
time,
having
big
impact.
So
the
risk
about
missing
or
poor
adoption,
it
is
real,
but
at
the
same
time
I
think
that
open
ssf
is
in
the
right
position,
because
at
the
moment
we
have
now
enough
information
about
open
source
project,
because
every
open
source
project
can
be
in
different
platforms.
So
you
need
to
have
different
api
and
different
logic
for
every
platform.
G
Every
project
add
file
in
a
different
way,
so
we
have
some
project
that
have
the
security
and
the
other
project
that
have
a
link
to
the
website.
Other
projects
that
have
just
a
page
in
a
repo
in
the
organization
so
and
it
is
difficult
to
collect
and
information
with
this
file,
we
can
create
a
standard
to
collect
information
and
create
database,
and
it
is
also
human
readable.
So
it
is
easy
for
a
single
person
to
read
it.
G
The
most
important
part
is
coordinate
people
before
the
launch,
so
this
means
that
openfsf
should
communicate
at
the
moment.
I
in
my
task
I
can
show
you
I
think,
wait.
I
don't
know.
If
I
need
to
interrupt
that.
Okay,
you
can
see
slack
nope.
Yes,
yes,
perfect!
Okay,
here
there
are
some
action
items.
You
can
find
is
also
in
the
meeting
notes
from
my
working
group
so
identify
security
threats.
There
is
a
invited
mark
cox
to
to
this
channel
to
present
the
project.
G
He
worked
with
the
alphaphone
with
the
apache
foundation
and
involved
alpha
omega.
So
I
am
jumping
in
a
different
meeting
now
to
in
a
different
working
group
to
explain
this
process,
so
we
need
to
coordinate
with
the
security
scorecard
to
to
be
sure
that
the
securities
escort
can
try
to
evaluate
this
file,
maybe
not
every
voice,
but
the
important
voice
communicate
with
the
alpha
omega.
So
maybe
we
can
convince
people
from
an
important
project
to
add
this
to
a
big
operations
project.
G
Then
there
is
also
the
new
dashboard
that
we
are.
We
have
deprecated
the
metric
dashboard,
but
we
are
working
a
new
dashboard
and
probably
the
dashboard
can
collect
information
directly
from
this
file.
If
we
implement
it,
it
is
a
it
should
be
a
standard,
so
I
know
that
it
will
require
time.
It's
not
just
launch
it
and
we
have
done
it
is
launching
a
talk
to
conference
present
to
people
open
pr
in
the
open
source
project.
G
But
this
is
all
all
risks
that
I
ever
considered
already
and
the
reason
why
I
think
that
open
openssf
is
the
right
place
is
because
we
can
contact
a
lot
of
people
quickly
and
easily
more
or
less
and
to
present
our
project,
and
in
addition,
this
friday,
I
have
a
meeting
with
red
dot
people,
for
example.
For
the
same
reason,
I
want
to
convince
that
to
adopt
the
standard.
G
So
if
we
start
in
this
way,
probably
if
there
are
enough
stakeholder
or
popular
project
that
follow
has
it
doesn't
mean
that
every
project
followed
this
standard,
of
course,
but
if
you
start
to
became
important
in
the
operations
community,
maybe
someone
can
suggest
you
to
add
this
file.
I
know
it's
required
time.
It's
not
easy
it.
It
can
fail.
I
have
considered
this.
It
is
the
in-depth
in
their
failure
risk.
G
A
C
D
No,
that's:
okay,
no
problem,
so
I'm
just
going
to
push
more
communication
onto
your
stack
there.
Luigi
one
of
the
things
that
open,
ssf
is
going
to
be
looking
at
or
potentially
looking
at
in
the
coming
years
is
helping
to
promote
the
the
use
of
s-bombs,
and
at
the
moment
it
looks
like
they're
trending,
towards
while
being
inclusive
of
all
s-bomb
formats.
D
D
D
There
is
specifically
one
called
defects,
which
is
about
essentially
vulnerability
disclosures,
but
but
in
spdx
there's
also
the
technical
work
working
group
community,
we
don't
call
them
working
groups
in
spx,
but
there's
a
the
technical
community
and
the
technical
community
is
working
on
the
specification,
and
so
that
would
be
very
helpful
for
your
group
here.
There's
also
another
group
that
just
started
that
is
canonicalization.
D
So
those
three,
I
think,
could
be
very
helpful
for
you
and
this
project
to
engage
with
to
get
additional
adoption
and
also
feedback
on
this.
On
this
thing,
just
because
I
know,
there's
been
a
great
deal
of
thought
happening
all
over
the
place
for
actually
on
this
topic,
but
in
spdx
they've
got
people
from
mitre
they've
got
people
from
nist
they've
got.
You
know
people
who
really
do
a
lot
of
work
around
this,
who
could
be
very
helpful
to
provide
feedback
on
all
the
work
that
you
all
have
done
there?
You.
G
Go
okay,
if
you
can
send
me
on
slack
links,
so
I
can
start
to
contact
them
it
is.
It
will
be
great.
So
thank
you
for
this
point,
because
I
know
that
there
are
a
lot
of
people
that
have
tried
to
standardize
this
kind
of
information
in
a
file
and
something
similar
and
people
have
already
tied.
So
I've
considered
that
people
already
tied
to
other
sort
of
standard,
but
for
some
reason
not
every
open
source
project
or
organization
follow
their
own
approach.
G
So
the
point
is
to
try
to
create
a
real
communication
standard
with
people,
and
I
well.
One
of
one
important
point
in
my
opinion
is
to
maintain
it
easy,
so
usually
highs
or
processor
or
standard,
especially
company
standard
or
industrial
standard
are
not
so
easy
for
open
source
that
are
popular
but
maintained
by
just
by
people.
G
So
I
am
trying
to
to
adapt
to
the
semi-approach
of
security.txt
a
file
that
is
easy,
and
so
people
can
can
implement
easy.
Also
for
big
projects
that
are
just
open
source
projects
that
have
no
company,
no
particular
sponsor,
but
they
are
very
popular
so,
but
it
is
important
that
they
can
be
aligned
with
a
lot
of
people,
because
I
think
this
is
a
one
of
the
most
important
things.
G
But
yes,
please,
if
you
can
share
the
link
with
this
community,
it
is
important
because
I
am
already
jumping
to
different
security,
community
or
projects
to
to
say
just
to
hey.
We
have
this
project,
maybe
we
can
align
it.
I
have
received
a
request
about
bomb
and
technically
this
project
was
a
burden
also,
for
this
reason
it
is
probably
not
still.
I
don't
know
how
to
define
this,
but
it's
not
total,
complete
or
100
good
or
something
similar,
because
it
is
the
first
version
and
at
the
moment
we
will
we.
G
G
B
No,
that
that
that's
correct
no,
I
was
just
going
to
ask
more
about
you
know
you're,
saying
that
a
big
goal
is
that
things
are
machine
readable,
which
implies
that
there
is
going
to
be
another
platform
or
abstraction.
I
would
spend
some
time
thinking
about
who
that
user
is
and
why
they
need
that
abstraction.
B
What
they're
getting
out
of
it,
I
think
actually,
the
folks,
vicki
and
crow
were
pointing
to
would
have
some
really
good
insight,
it's
sort
of
like
solving
a
problem
by
adding
another
layer,
and
sometimes
there's
good
reason
to
do
that.
But
you
really
really
want
to
make
sure
that
that's
you
know
going
to
leave
things
in
a
productive
place,
not
just
accidentally
remove
communication
directly
to
projects.
G
G
It
is
not
so
easy
to
create
security,
dashboard
data
there
that
are
not
based
on
api
service,
so
we
can
collect
the
number
of
star
for
a
repo
or
we
can
collect
number
of
fork,
but
we
cannot
collect
some
information
related
to
link
for
the
policy
link
for
the
contribution
or
in
scope
out
of
scope
for
vulnerability,
report,
security,
contact
or
link
to
the
pen
testing,
because
maybe
the
link
to
the
pen
test
wrapper
for
an
open
source
project
is
in
the
website
and
not
in
the
repo
that
is
stand.
It
is
quite
common.
G
This
fight
can,
if,
of
course,
there
is
the
enough
adoption
by
the
open
source
community
can
help
scanner
to
start
to
create
database
real
database.
That
can
help
also
people
to
compare
projects
understand.
Where
are
the
information
find
them
easily
and
it
can
help
a
company
with
the
compliance
for
sure,
but
it
cannot
also
developer
to
evaluate
the
project,
for
example,
if
I
know
that
an
open
source
project
that
I
am
using
have
had
a
penetration
test
by
a
third
party
company,
I
can
read
the
penetration
test.
G
G
Of
course,
it
is
not
a
project
that
requires
two
months
and
we
have
done
it
require
a
lot
of
time,
because
it
would
be
another
layer
for
sure
and
also
standard.
So
I
am
quite
sure
that
if
the
rfc
for
security.xt
require
five
years,
I
don't
think
that
this
project
can
be
done
in
less
time.
So
from
that
perspective,
I
don't
expect
a
good
result
in
a
short
time.
It
is
a
marathon
in
my
opinion,
but
if
there
are,
there
is
open
surface.
G
There
are
a
lot
of
big
open
source
projects
involved
if
new,
open
source
projects
follow
this
approach,
and
if
companies
start
to
follow
this,
if
scanners
start
to
to
look
for
this
file,
I
think
that
we
can
start
to
have
a
good
database
about
open
source
project,
not
just
on
github,
not
just
related
to
git
lab,
but
also
open
source
project
that
are
just
mirror
along
it,
but
just
for
visibility.
They
have
the
real
repo
on
their
own
infrastructure,
for
example,
for
example.
So
this
file
can
be
a
standalone.
G
D
A
H
H
There
is
a
common
technique
for
publishing
documents
that
need
to
be
widely
available
and
it
uses
the
dot
well-known
path
under
a
under
a
domain.
Basically,
at
the
root
level,
that's
not
exactly
the
same
as
what
you're
doing
here,
which
is
in
a
in
the
inside
of
a
repo,
but
I
think
that
it's
kind
of
you
know
very,
very
similar
and
probably
benefit
from
looking
for
commonalities,
that
it
could
shape.
G
Yes,
this
is
an
important
quest
in
my
opinion.
At
the
moment,
we,
in
my
opinion,
we
have
this
problem
with
the
report
with
the
open
source
project
because,
for
example,
there
are
no.
There
are
a
lot
of
standard,
for
example,
but
stupid,
for
example,
people
some
people
put
the
documentation
in
the
doc
folder
order
in
the
docs
folder.
G
So
if
I
need
to
try
to
find
the
standard,
where
puts
this
file-
probably
I
say
just
the
main
repo
folder,
because
in
this
way
I
don't
need
to
define
a
new
standard,
will
add
a
new
standard
and
every
project
ever
apple
in
their
own
infrastructure,
on
github
or
where
they
want.
But
if
you
have
an
open
source
project,
you
need
to
have
a
repo,
so
it
the
main
folder
of
the
apple
x
is
for
sure.
A
well
known
you
are
uri
cannot
exist
if
you
don't
have
a
website.
G
A
Okay,
we
provided
he
provided
links
to
his
slack
channel.
So
if
you
have
comments,
please
provide
those
directly
there
luigi
I'll
point
you
to
our
two
resources:
we
have
the
cbd
guide
for
open
source
maintainers
and
that
what
might
be
a
great
place
for
you
to
review
and
think
about
how
your
project
might
be
integrated
into
that,
and
then
we
are
right
after
this
going
to
be
talking
about
the
cvd
guide
for
security
researchers,
which
again
would
be
a
another
place.
You
would
want
to
think
about
how
your
efforts
integrate
with.
G
Yes,
thank
you.
Yes,
yes
sure,
and
thank
you
for
the
feedback
they
are
great
and
especially
because
at
the
moment
my
main
problem
probably
is
the
communication,
because
the
standard
can
be
improved
and
they
people
can
just
stop
npr,
but
in
convince
people
to
adopt
a
new
standard
is
probably
the
most
point
of
failure
of
this
project.
So
thank
you
for
all
the
good
link
and
I
suppose
there
is
a
way
to
download
the
zoom
chat.
Yes,
there
is
okay
and
okay.
Thank
you.
A
A
A
E
Give
you
some
insights,
we
definitely
weren't
done.
I
think
that
that
I
mean
I
was
working
on
it
with.
Oh,
my
god,
your
name.
Excuse
me.
Please
please,
please!
Thank
you.
Sorry,
I'm
I'm!
It's
I'm
I'm
recovering
from
a
cold,
so
we
weren't
done.
I
think
that
last
we
spoke,
we
were
both
like
our
brains
are
fried
and
we're
done
for
the
day,
but
we
got
some
stuff
in
here
that
was
yeah
some
stuff
in
here
there
was
some
discussion
of
like
various
different
topics,
including
like
hey,
like.
E
Is
it
okay,
that
we
are
being
like
we're,
not
necessarily
encouraging
full
disclosure
but
making
sure
that
people
are
aware
of
that
as
a
as
a
mechanism
for
handling
vulnerabilities?
If
all
else
fails
and
like
it's
kind
of
communicating
what
full
disclosure
looks
like
and
why
it's
important-
and
you
know
why
disclosure
in
general
is
important.
I
A
E
It's
not
in
the
list
yet
I
do
question
the
value
of
doing
so
when
the
maintainer
is
very
like
staunch
that
they're
not
either
not
gonna
fix
it
or
like
that,
you
know.
Whatever
else
also
cert
doesn't
want
to
take
like
cert
is
good
for
multi-vendor
stuff.
So
if
it's
single
vendor
they
don't
necessarily
really
want
to
get
involved
because
they
don't,
they
only
have
so
many
resources
right.
That's
kind
of
what
you
said:
madison.
J
Yes,
I'll
chime
in
a
little
bit
speak
being
at
cert
cc.
We
do
take
like
lots
of
single
vendor
cases.
The
truth
is
most
cases
that
come
in
aren't
multivendor,
so
when
they
do
come
in,
we
definitely
take
them,
but
a
lot
of
our
cases
are
single
vendor
and
we
have
also
had
cases
where
reporters
come
to
us
saying
you
know
we
can't
we
can't
work
with
within
the
bug.
Bounty
con
finds
a
company
x,
company
y
company
z.
J
I
Yeah
sort
of
the
way
that
I've
been
thinking
about
this
document
is
that
we
can
just
present
all
of
the
options
for
reporters,
so
they're
aware
just
of
everything
I
think
that
is
maybe
would
be
the
most
useful
for
reporters,
so
just
including
everything
so
they're
aware
something
adding
this
is
totally
fine.
We
just
haven't
gotten
there
yet.
E
K
Yeah
we,
this
is
kayla
we
crystal
and
I
posted.
We
were
working
on
it
last
last,
two
weeks
yeah,
so
we
posted
our
our
bit
down
at
the
bottom.
So
I
definitely
think
looking
through
what
we
have
today
that
we're
going
to
need
to
re-structure
and
reorganize.
It's
a
bit
repetitive,
because
we
were
kind
of
working
in
a
silo.
K
I
think
especially
some
of
the
language
we're
using
vulnerability
disclosure
policy
flush
program,
a
lot
and
I'm
perfectly
perfectly
happy
changing
that
to
cvd.
If
we
wanted
to
say
that,
because
you
know
vdp's
already
included
as
another
name,
and
so
it's
a
little
repetitive
based
on
like
that
section,
compared
to
what's
already
there,
so
I'm
totally
good
with
us
like
restructuring
it
moving
it
higher
up,
maybe
just
taking
the
bug,
bounty
parts
and
anything
that
might
be
unique
about
the
bdp
part
but
yeah
it's
in
there.
The.
A
E
Right,
regardless
of
it
being
a
bdp
or
a
bug,
money
program,
one
of
the
things
that
this
sort
of
larger
issues
that
I've
seen
with
as
soon
as
you
end
up
with
a
vendor
under
black
hat
or
sorry
wow,
my
brain,
I'm
still
under
a
hacker
one
or
bug
crowd,
is
that
most
of
those
organizations
and
companies,
even
if
you're
like
dealing
with
a
vdp,
will
have
a
non-disclosure
policy
on
their
bdp
and,
like.
I
know
that.
E
That's
not
like
I've
spoken
to
alex
rice
and
I've
spoken
to
keith
john
ellis
and
they're
both
like
well,
that's
not
the
way
it's
supposed
to
be
and
I'm
like.
Well,
it
doesn't
really
matter
the
way
it's
supposed
to
be
it's
the
way
it
actually
is,
and
so
I
don't
know
if,
like
the
differentiation
between
vdp
and
bug,
binding
program,
really
matters
more.
K
Yeah,
we
talked
a
lot
about
that
and
I
certainly
would
love
the
the
thoughts
of
the
group
here.
So
the
position
that
crystal
and
I
took
while
writing
this
is
that
this
is
this:
is
a
document
written
for
a
community
interacting
with
the
open
source
community,
so
community,
interacting
with
the
community,
and
we
took
the
approach
that
first
off
a
vdp
should
not
should
not
include
a
non-disclosure
clause.
K
Yeah
yeah,
so
their
awareness
right
so
kind
of
like
what
you
guys
were
saying
earlier.
We
want
the
reporter
to
be
aware
that
there
should
not
be
a
non-disclosure
clause
in
a
vdp
right
in
the
bug
bounty
section-
and
this
is
something
I'd
also
I'd
love
to
talk
about
really
is
the
aspect
of
we
still
kind
of
had
this
perspective
of
it's
open
source.
K
There
shouldn't
be
a
non-disclosure
clause
even
for
a
bug,
bounty
program,
but
obviously
then
we
start
talking
about
you
know
there
are
vendors
who
support
open
source
software,
so
it
can
get
more
complicated.
So
the
way
we
put
it
in
the
language
for
for
totally
up
for
debate
right,
but
the
way
we
included
it
as
a
call
out
for
this
awareness
of
non-disclosure
applause
or
agreements.
K
Or
you
know,
any
of
those
topics
is
that
if
you
are
working,
if
you
are
reporting
a
vulnerability
on
a
piece
of
open
source
software
that
might
belong
to
or
be
supported
by
a
I
don't
know,
if
private's
the
right
word
but
commercial
entity,
there
might
be
more
district
disclosure
guidelines
or
disclosure
process,
and
just
for
the
awareness
for
them
to
be
aware
of
that.
But
I
think
that
that's,
that
is
kind
of
a
topic
that
is,
I
don't
know
if
we
have
an
opinion
of
that
on
that.
E
A
L
L
A
B
B
B
We
should
probably
also
separately,
as
this
group
have
a
discussion
about
open
source
projects
using
embargoes,
because
that
gets
really
sticky-
and
I
know
you
know
kind
of
the
position
we
took
when
we
were
writing
google's
guide
was
that
it
is
so
rare
that
you,
I
think,
there's
a
tendency
to
treat
it
as
a
default,
and
we
took
the
position
that
the
project
that
needs
that
is
incredibly
rare.
Your
default
should
be
that
you
do
not
need
an
embargo.
B
L
Yeah
happy
to
take
that
one,
I
I
don't
ever
see
it
in
open
source,
I'm
sure
that
it
exists
somewhere,
but
I
haven't
seen
it.
So
that's
why
I
was
hesitant
to
make
a
huge
section
in
there.
I
do
see
it
in
commercial
projects,
but
in
open
source,
like
I
couldn't
think
of
a
single
example
to
be
honest,
so
that
was
that
was
kind
of
why
we
didn't
make
it
a
large
section.
K
K
This
is
the
second
wave
you
know
and
they're
very
specific
about
at
what
stage
the
researcher
could
be
rewarded
through
the
bug
bounty
program,
and
so
just
one
of
the
things
that
we
operate,
that
the
way
that
I
we
operate
for
ibb
is
that
we
just
we
respect
the
wishes
of
the
project,
but
I
don't
have.
I
don't
have
any
examples
from
any
of
the
ibb
projects
or
the
projects
enrolled
in
ibb
that
have
an
nda
looped
in
that
I
know
of
because
we
we
publicly
disclose
everything
rewarded
through
ibb.
E
Jonathan,
I
really
against
this
a
bit.
It
sounds
like
that
that
model
is
paying
researchers
for
their
silence
up
to
a
certain
point,
like
you're,
basically
like
financially
you're,
creating
a
financial
incentive
to
keep
the
researcher
from
disclosing,
which
I
really
struggle
with
in
the
bug
money
space,
because
that's
where
a
lot
of
you
know
that's
what
that
seems
like
the
model.
The
bug
bounty
like
ecosystem
has.
E
Is
this
this
goal
of
paying
researchers
to
not
air
companies
dirty
laundry
right
and,
and
the
downside
of
that
is
that
it
disincentivizes
disclosure
of
vulnerabilities
that
are
important
in
critical
software,
and
so
that's
why
I've
kind
of
you
know.
Whenever
I
encounter
that
I
try.
I
basically
say
no,
I'm
not
going
to
agree
to
your
terms
in
that
area,
but
you
know.
So
what
are
the
and
is?
Is
that
is
there
for
these
organizations
that
are
had
to
have
these
embargoes?
E
L
I
wanted
to
clarify
something
kayla
you're
saying
as
part
of
ibb
that
the
report
must
be
disclosed
publicly
before
it
can
be
awarded,
so
that's
sort
of
like
intrinsically
part
of
it
that
it
is
disclosed.
That's
correct,
all
right!
Okay,
yes,
so
I
think
maybe
there
was
a
misunderstanding
there,
like,
I
think.
K
There's:
okay,
a
timeline,
there's
definitely
a
timeline
so
so
like.
I
think
I
think
zen
project
is
one
of
our
our
hypervisors
and
hypervisors
one
of
our
bigger
ones.
That
has
a
very,
very
descript
process,
publicly
available.
Anyone
can
follow
along
with
the
stages,
so
they
have
a
timeline
involved.
K
K
K
A
yeah
it's
a
longer
timeline,
but
as
far
as
anyone
specifically
like
choosing
to
not
disclose
something,
it's
just
not
something
I
see
in
with
the
open
source
products
I
work
with,
but
again
also
I'm
not.
I
am
not
the
voice
of,
but
I
am
not
the
official
authority
here.
This
is
just
talking
about
my
experience,
working
with
open
source
projects
and
the
internet,
bug
bounty
and
the
and
the
content
that
I've
seen,
and
that
was
one
of
the
things
that
crystal
and
I
kept
restating.
K
As
we
were
writing
this
is
the
audience
of
this
guide
is
binders,
who
have
discovered
vulnerabilities
within
open
source
projects,
open
source
software
who
were
engaging
with
open
source
maintainers
and,
like
crystal
said,
that's
why
we
didn't
want
to
go
into
a
big
topic
of
a
lot
about
a
lot
about
ndas,
because
I
guess
just
the
perspective
is
that
it
shouldn't
be
an
emphasis
in
the
world
of
open
source.
It
doesn't
really
jive
with
the
open
source
theme.
E
E
Yeah
all
right,
actually,
I
have
no
say
here
I
mean
well
yeah,
so
the
first
vulnerability
was
in
a
project
that
was
owned
by
hotels.com,
which
is
owned
by
expedia,
and
I
emailed
expedia
about
the
vulnerability
and
report
it
to
them.
And
of
course
you
get
an
automated
email
back
saying
hey
by
the
way.
Thank
you
for
sending
us
this
email,
but
we
didn't
actually
see
your
email.
E
I
would
just
prefer
to
stick
to
email.
One
of
the
things
that
tavis
ormandy
has
said
on
twitter
previously.
Is
that,
like
you
know,
I'm
not
gonna,
you
know
I
won't
disclose
via
bug
budding
programs
or
hacker
one
or
something
like
that.
He
basically
says
if
there's
not
an
email
like
get
me
an
email
to
somebody.
E
E
Can
I
get
approval
to
disclose
it
to
you
guys
and
not
be
under
these
terms
and
then
subsequently
had
to
again,
then
they
said
yes
open
another
ticket
with
the
vulnerability
details
and
it'll
be
bound
by
this
agreement
that
we've
made
beforehand
right,
there's
a
lot
of
extra
effort
and
time
and
energy
that
has
to
go
into
like
getting
the
agreement
that
it's
not
going
to
be
bound.
You
can't
just
get
to
the
disclosure
of
the
vulnerability
state
you
have
to
go
through
the.
E
I
also
try
to
fight
you
about
the
policy
you
have
beforehand
before
I
can
even
give
you
the
information
about
the
vulnerability
and
that's
I
don't
have
a
good
solution
to
that,
but
I
think
that
the
making
people
aware
and
telling
them
hey.
You
should
be
aware
of
what
you're
agreeing
to
when
you're
like
so
that
you
are
making
an
informed
decision
in
that
department
is,
is
should
be
part
of
this
document.
I
don't
know
how
to
tell
that
story.
E
Well,
I
don't
know
how
to
tell
that
story
that
doesn't
like
scare
people
away
or
doesn't
like
make
this
document
like
super
long,
but
I
do
think
that's
an
important
part
of
the
story
that
needs
to
get
told
that
it
needs
to
get
communicated
to
people
and
warn
them
about
that.
They
should
be
doing
that
sort
of
due
diligence
ahead
of
time.
A
So,
there's
a
nuance:
there,
jonathan,
with
your
stories,
you're
reporting
to
commercial
entities
that
supply
these
open
source
packages
and
in
our
the
nomenclature
of
our
personas,
those
would
be
maintainer,
slash
suppliers
and
that's
a
little
bit
different
focus
or
instruction
than
what
we're
hoping
for
here.
You
know
again
not.
A
E
A
A
So
we
can
provide
some
instruction
there,
but
it's
a
slightly
different
target
audience
and
we're
trying
to
help
the
intention
here,
be
it
there's
a
finder
that
discovers
a
vulnerability
and
they
are
having
a
opportunity
reporting
it,
and
maybe
they
can't
find
a
contact.
Maybe
they
do
get
stonewalled.
A
E
I
don't
think
there's
any
I
mean
assuming
the
software
is
still
open
source
right.
I
I
mean
in
both
cases
these
were
pieces
of
open
source
software
that
were
shipped
to
end
users
that
were
not
directly
like
they
were
not
customers
of
netflix
right.
This
is
software.
That
netflix
is
publishing,
because
it's
a
utility
thing
that
they've
written
that
other
people
can
consume
right
and
regardless
of
who
owns
the
software,
you've
found
a
vulnerability
in
an
open
source
piece
of
software.
So
I
don't
necessarily
know
that.
A
H
C
D
Here's
how
you
can
communicate
around
open
source,
here's
how
you
can
do
our
retention
policies
with
open
source,
but
they
have
existing
policies
they
have
to
carve
out.
It
sounds
like
this
might
be
something
we
need
to
advise
entities
on
in
the
future
for
a
thing
and
so
we're
making
more
work
for
ourselves.
But
that's
okay,
that's
good,
because
it
will
make
less
work
for
ourselves
in
the
long
run.
I
think
it's
a
great
idea.
A
And
you
know:
we've
already
provided
instruction
and
we
can
update
that
instruction
for
maintainers.
Maybe
the
maintainers
need
to
think
more
about
what
their
long-term
support
is.
You
know
what
they
will
and
won't
do
around
these
types
of
reports,
so
we
can
try
to
influence
on
both
ends
so
that
when
researchers
do
discover
something
it's
a
more
it's
a
more
frictionless
experience.
A
A
All
right,
I
want
to
thank
everybody
that
spent
some
time
over
the
last
few
weeks
on
this
document.
You
know
madison,
kayla,
jonathan
and
crystal
and
everybody
else.
Please
continue
to
contribute
your
thoughts
and
we
will
meet
again
in
a
few
weeks
to
talk
some
more
about
this.
I'm
really
excited
about
our
progress.
Thank
you.
Everybody,
great
work
and
good
conversation.