►
From YouTube: OpenSSF Vulnerability Disclosures WG (July 13, 2022)
A
B
A
A
A
B
B
A
A
All
right,
if
anyone
has
any
opens,
please
note
them
in
the
document.
I
want
to
give
everybody
a
quick
update
for
those
of
you
that
may
or
may
not
be
aware.
This
working
group
decided
to
adopt
the
open,
ssf's
mobilization
plan
stream
5,
which
is
the
open
source
security
incident
response
team,
the
oss
cert.
A
We
kicked
off
weekly
sig
meetings,
two
weeks
passed
and
this
week
was
our
second
meeting.
So
if
anyone
is
interested
to
join
those
efforts,
those
will
be
tuesdays
at
9
00
a.m.
Eastern
standard
time
we
got
our
very
own
git
repo,
it
cost
hundreds
of
dollars
to
do
and
I'll
get
us
set
up
with
a
mailing
list
for
that
group
if
anyone's
interested,
they
can
subscribe
to
that
and
we'll
also
have
a
slack
channel,
and
please
bear
with
me
because
I'm
a
one-man
show
here.
A
A
All
right:
well,
then,
let
us
continue
our
ongoing
editorial
efforts.
I
will
throw
a
document
at
you
in
the
zoom
chat.
This
is
a
document.
We've
been
collaborating
on
for
a
little
bit.
This
is
our
current
project.
This
is
a
cvd
guide
for
how
finders
can
better
interact
with
open
source
projects
and
maintainers.
A
C
A
If
I
could
point
your
attention
to
what
is
an
open
source,
maintainer
section,
it's
at
the
bottom
of
page
two
and
on
to
page
three,
do
we
have
do?
We
feel
we
need
to
do
any
further
definition
for
a
security
researcher,
about
kind
of
who
an
open
source
maintainer
is
and
what
their
jam?
What
they're
all
about.
A
A
All
right,
if
there's
no
questions
about
what
a
maintainer
is,
if
you
want
to
go
down
to
what
are
open
source
maintainers
motivations,
if
anyone
has
any
feedback
on
additional
motivations,
I
provided
a
link
to
the
foundation's
2020
maintain
a
contributor
survey,
which
is
an
excellent
report.
That
talked
a
lot
about
different
reasons
why
people
contribute
open
source,
but
if
we
had
any
more,
we
wanted
to
highlight
for
researchers.
That
would
be
very
useful
to
put
here
any
comments.
There.
B
No
I've
been
doing
this
too
long
honey.
I'm
not
going
to
buy
that
line.
No,
would
it
be
possible
to
like
give
us
a
short
list
of
the
things
you
would
like
us
to
review,
and
then
we
take
a
couple
minutes
all
to
read
it
because
I
suspect,
what's
happening
is
everyone's
like
yeah,
that's
fine,
but
none
of
us
have
read
it
in
a
week
or
more.
B
A
A
A
A
E
E
We
can
also
maybe
carve
out
a
bit
around
full
disclosure
because
eve
you
know
full,
but
I
think
there's
flavors
of
that.
There's
releasing
a
very
high
level
advisory
versus
releasing
a
detailed
advisory
with
a
working
proof
of
concept
exploit
code,
so
maybe
carving
some
nuance
there,
because
I
think
that
even
under
all
of
these
categories,
even
though
different
categories
are
better
choices
than
others,
you
know,
in
my
opinion,
even
within
a
category
you
might
be
able
to
make
a
safer
for
the
internet.
Choice
versus
a
less
paid
for
the
internet.
Choice.
A
E
A
I
I
don't
care
okay,
whatever
you're
comfortable
with
okay,
if
you're
gonna,
if
you're
going
to
change
a
section,
I
would
suggest
I
would
prefer
we
suggest,
but
if
we're
adding
something
new,
we're
all
looking
at
it
right
now,
we
can
kind
of
adjudicate
that
right
here
in
the
call
so
feel
free
to
edit
but
yeah.
If
you're
going
to
modify
somebody's
existing
work,
please
suggest
for
now.
Okay,.
B
Make
strong
recommendations
on
the
directions
and
also
tell
people
why
certain
things
aren't
necessarily
good
for
the
greater
good?
Yes,
you
can
sell
these
things,
for
instance,
but
here's
why
it's
a
really
bad
idea,
aside
from
being
just
ethically
questionable.
So
that
would
be
really
lovely
to
add
that
in
here
and
as
my
editor
likes
to
remind
me,
you're
the
author,
it's
okay
to
have
opinions,
and
I
think
in
particular
for
this
document.
It's
advisable
for
us
to
have
opinions.
A
And
remember
we're
we
are.
This
document
is
representing
open
source
maintainers
and
projects,
so
we're
trying
to
help
educate
those
researchers
to
work
better
with
us
in
those
communities,
so
we're
trying
to
help.
You
know
help
those
two
communities
get
together.
So
that's
kind
of
the
perspective
with
which
we
should
view
this.
C
A
E
It's
probably
good
for
us
to
comment
on
norms,
though,
like
I
agree
that
it's
a
good
idea
to
share
the
broader
like
ecosystem,
so
people
are
aware,
but
like
at
least
in
my
opinion,
and
please
feel
free
to
disagree
with
me.
Everyone
on
this
call
on
this,
but
it
feels
like
cv,
is
pretty
much
a
norm
and,
if
someone's
looking
for
you
know
a
guide
into
how
things
are
done,
I
think
it's
fair
for
us
to
say.
Like
you
know,
this
is
what's
typically
happening
so
that
they
have
that
as
like
a
prototype.
A
G
There
are
also
you
know:
the
the
commercial
scanners
usually
have
their
like
internal
identifier,
like
for
black,
like
bdsa
black,
like
security
advisory,
etc,
which
they
have
like
it
could
be
that
you
have
like
an
internal
id
for
that
scanner
and
the
cv
id.
But
sometimes
you
have
only
like
the
internal
id,
and
it's
sometimes
like
for
configurations.
G
You
know
configuration,
I
wouldn't
say
vulnerabilities,
but
yeah.
There
is
some
artistic
freedom
to
the
to
the
vendors
and
also
there's
something
that
that
is
there's
a
discussion
around
cloud
providers
and
how
they
manage
their
vulnerabilities
because
they
don't
really
publish
tvs
they
just
they
just
you
know,
fix
whatever
needs,
fixing
and
and
there's
no
record
of
that
anywhere.
Basically,
so
that's
also
something
that
you
might
want
to
mention
somehow.
A
A
Yeah,
I'm
not.
We
definitely
should
research
that
and
verify
some
that
before
we
would
put
anything
commit
to
a
formal
document,
but
that
is
again,
I
think
again
we're
trying
to
help
coach
finders
to
have
a
very
frictionless
experience,
but
we
should
note
that
there
will
be
when
you're
approaching
there
will
be
differences
when
you
approach
a
commercial
vendor
versus
a
free
and
open
source,
maintainer
versus
a
cloud
service
provider.
Potentially
the
experience
and
process
might
be
different.
H
A
A
A
That
is
all
actually
they're
part
of
this
free
group.
I
don't
know
that
they
show
up
very
often,
but
that
is
actually
the
osv
folks
are
part
of
this
working
group.
So
it's
something
we
should
mention,
and
it
is
they've
done
a
lot
of
work
with
the
next
iteration
of
cve
to
kind
of
harmonize
that
work.
I
A
A
A
A
A
A
A
I
I
A
So
I
think
that's
a
very
good
point.
Let
me
I'll,
I'm
gonna
put
a
comment
here
just
so
we
don't
forget
it
and
then
we'll
find
an
appropriate
place
to
put
that
in
the
document,
but
I
think
that's
good
feedback
to
provide
that
you
can
become
a
nuisance
and
kind
of
work
against
your
goals
of
getting
things
fixed
quickly
by
making
a
lot
of
hubbub.
I
A
J
As
the
you
know
like,
basically
starting
with,
as
the
disclosure
also
informs
an
attacker
attackers,
that
a
vulnerability
exists
and
basically
end
it
with
like
a
this,
is
kind
of
why
you
shouldn't
take
that
as
a
first
step
versus
you
know,
and
I'm
happy
to
put
it
in
suggestion
mode
as
well,
to
put
that
in
there.
If
you
could.
H
A
A
K
A
A
I
believe
is
that
correct,
and
just
so
everyone
knows
we
did
david
wheeler
talked
with
the
folks
at
the
lf.
We
do
have
technical
editors
that
when
we're
done
they'll
or
we'll
be
able
to
go
through
this
and
kind
of
help,
proof
and
catch
things
like
a
versus,
and
maybe
I
can
get
them
to
apply
this
style
guide.
B
J
Yeah
the
kind
of
my
or
my
suggestion
or
the
the
as
public,
like
my
edits
to
that
second
sentence,
I
mean,
I
think
it's
important
to
include
the.
Why
that's
in
there,
which
is
you
know
it's
informing
attackers
that
there's
a
vulnerability
without
a
fix.
I
think
that's
important,
so
maybe
even
meshing
the
two
sentences,
because
yeah
definitely
don't
want
any
redundancy.
D
A
A
B
A
It's
always
hard
writing
a
document
with
20
people
watching
but
yeah.
The
intention
is-
and
this
won't
be
the
last
time
we
do
this
we'll
have
it
looks
like
we've
got
several
sections
that
need
some
augmenting
to
go,
so
we
will
procedurally
continue
to
do
exercises
like
this
and
then
we'll
do
homework
for
everybody.
A
Please
read
the
document
in
totality
and
we'll
catch
run-ons
and
typos
and
stuff,
and
then
we'll
send
it
over
to
the
editor
for
publication,
which
our
desired
publication
is
black
hat,
although
we
don't
have
a
presentation
slot
that
bounds
that
so,
if
we're
late,
we
can
still
as
long
as
we're
targeting
august.
I
think
that's
acceptable.
A
E
A
Possibly
we
also
have
thinking
within
the
foundation.
We
will
be
having
a
town
hall
in
probably
september
now
it
looks
like
so
if
we
should
be
done
by
then,
if
parts
of
the
group
wanted
to
come
present
like
for
five
minutes
or
so
during
that
town
hall,
we
could
present
this
artifact
and
that's
another
way
that
we
could
advertise
it
and
that'll
go
out
through
twitter
and
linkedin
and
youtube
it'll.
Be
a
video,
so
that'll
be
a
way
to
kind
of
get
that
the
word
out.
B
B
A
We
definitely
should
speak
about
it
because
there
will
be
differences,
possibly
you'll
get
a,
hopefully
more
disciplined
experience
with
a
vendor
that
they'll
have
a
process
and
tools,
whereas
the
project
may
not
have
those
capabilities
or
access
to
those
resources,
so
maybe
go
a
little
different.
We
should
definitely
mention
that.
C
A
E
Jennifer
communicating
expectations
in
advance-
I
think,
can
be
important.
So
we
talk
about,
for
example,
having
a
disclosure
policy
of
one's
own,
and
you
know
some
people
have
seven
days.
Some
people
have
90
days
and
everything
in
between,
like
one
thing
that
I
try
to
do
with
our
researchers
is
ensure
that
when
we
talk
to
whoever
that
in
that
first
contact,
we
share
our
disclosure
policy,
but
like
setting
an
expectation
in
the
communications
for
your
awareness,
we'll
be
releasing
this
advisory
in
30
days.
E
A
A
A
F
I
mean
I'm
just
wondering,
like
I
guess,
questioning
whether
or
not
whether
or
not
in
many
cases
that
would
even
apply
it
depends
on.
If
there's
like
a
terms
of
service
in
the
place
that
it's
being
you
know,
the
report
is
being
disclosed
or
the
issues
being
disclosed,
so
it
might
like,
including
it
might
be,
implying
that
there
would
be
that
there
would
be
some
validity
to
it,
but
it
would
depend
on.
You
know
where
that
said
and
how
that
said.
A
F
I
don't
know,
what's
everybody
and
what's
everybody's
thoughts
on
just
that
section
in
general
like
or
the
advice
of
having
having
your
own
terms,
I
mean,
I
think
I
think
that
could
be
framed
as
just
communicating
like
what
you
expect
as
a
finder
versus
like
having
terms
and
conditions
as
a
finder.
I
think
that's
the
distinction
I'm
trying
to
make.
E
Yeah,
it's
a
good
point
that
you're
raising
crystal
because,
like
it
introduces
a
lot
of
complexity
like
if
a
vendor
or
a
project
has
a
set
of
terms
and
then
you,
as
a
researcher
like
write
up
your
own
terms,
and
maybe
the
terms
are
like
you'll
buy
me
a
hot
air
balloon.
If
I
like,
drop
zero
days
on
you
like
to
what
extent
is
that
is
that
enforceable
or
meaningful-
and
I
wonder
like,
should
we
be
and-
and
this
is
a
truly
an
open
question-
not
a
rhetorical
one?
E
Should
we
be
recommending
people
have
their
own
disclosure
policy
like
as
a
company
right
like
so
I'm
I'm
here
at
ncc
group?
We
have
our
policy
because
we
do
a
lot
of
it
and
we're
trying
to
keep
consistency
across
researchers
but
like
as
an
individual.
Does
that
make
sense,
and
like
is
that
I
don't
know,
I
wonder
if
on
on
one
hand,
it's
valuable
to
clearly
state
your
expectations
and
to
keep
them
consistent
across
time
and
across
entities.
E
A
A
Maybe
we
change
that
to
and
we
talk
about
what
are
your
goals
up
above,
but
maybe
we
should
state.
You
know
the
researcher.
You
should
come
into
this
relationship
with
you
know
and
state
what
your
expectations
are.
I'm
presenting
at
a
conference
or
I'm
publishing
this
getting
my
phd,
which
I
have
to
defend
it
on
this
date.
So
I
think
the
researcher
definitely
needs
to
come
in
and
state
kind
of
what
the
constraints
of
this
disclosure
are
from
their
perspective.
A
C
F
No,
you
know
I'm
not
a
lawyer,
but
I
don't
think
there's
any
people
standing
there,
and
so
I
didn't
want
to
set
that
expectation
with
researchers
and
and
then
for
them
to
run
into
like
a
problem
because
of
it
and
end
up
in
like
a
weird
sticky
legal
situation.
Potentially
so
I
love
the
idea
of
framing
it
as
setting
your
expectations,
but
not
calling
it
a
policy.
L
Just
to
add
on
to
that,
because
I
was
working
with
jonathan
when
you
wrote
that
policy
is
definitely
a
strong
word.
What
he
really
meant
here
is
setting
clear
expectations,
specifically
around
deadlines
from
the
start,
so
he
as
somebody
who
is
disclosing
a
number
of
vulnerabilities
and
is
maybe
a
bit
more
mature
and
their
vulnerability
disclosure
process
than
somebody
who
is
very
new
to
this-
has
his
own
predefined
set.
What
he
calls
a
policy
himself
that
he
shares
in
each
disclosure,
so
maybe
a
good
way
throughout
this
document
that
we
can
think
about.
L
This,
too,
is
that
there's
there's
a
varying
range
of
maturity.
I
think
expected
from
researchers
if
this
is
the
only
vulnerability
they
have
found
and
are
likely
to
find-
and
maybe
they're
never
going
to
do
this
again,
there
really
is
no
use
to
them,
setting
up
something,
quite
as
formal
as
a
policy
which
I
agree
is
maybe
not
the
right
word
for
what
jonathan
I
think
meant
by
this,
but
for
those
that
are
regularly
doing
this,
that
could
be
useful.
So
maybe
maybe
throughout
this
the
way
that
I've
been
thinking
of
this
document
is.
L
We
share
all
of
the
options
available
to
a
researcher
and
from
that
they
will
choose
what
matches
their
level
of
maturity,
basically
like
laying
out
all
of
the
options
that
are
available
for
them.
So
this
is
maybe
one
of
them
I'll
I'll,
be
it
maybe
overkill
in
some
circumstances,
so
we
can
maybe
rephrase
it
appropriately.
A
Before
I
move
on
to
jennifer
thinking
about
other
work,
I've
done
within
standards
and
whatnot
would
we
be
served
by
potentially
tiering
these
as
levels
of
maturity
or
providing
some
type
of
scale
saying
a
very
mature
experienced
researcher
might
have
might
actually
have
a
legal
document,
but
somebody
starting
off
isn't
do
we
want
to
either
in
this
document
or
as
some
side
piece
talk
about
how
this
isn't
necessarily
you're,
not
gonna.
Do
everything
it'll
be
kind
of
potentially
layers
and
or
levels?
Is
that
probably
would
like
to
go.
E
E
That's
something
you're
more
likely
to
see
in
an
experienced
researcher,
but
if
we're
setting
a
guide
of
what
we
want
people
to
do,
I
think
saying
that,
like
setting
expectations
up
front
is
something
that
you
should
aim
to
do.
So
I
wonder,
if
like
we
might
want
to
revisit
the
debate
of
presenting
all
of
these
options
as
equal,
because
I
don't
think
necessarily
that
they
are
and
that
we
do
have
an
opportunity
here
to
really
shape
the
direction
of
of
the
way
people
behave
in
this
space
towards
something
that
is.
E
I
don't.
I
don't
think
that
the
balance
of
power
in
vulnerability
disclosure
is
necessarily
advantageous
for
the
researcher
in
in
a
lot
of
cases
right
and
the
idea
that
you
would
create
a
legal
or
a
legally
contentious
document.
That,
then,
could
be.
You
know
battled
out
between
you
and
a
big
vendor
with
a
big
legal
team.
E
I
mean
that
strikes
me
first
of
all,
as
potentially
dangerous
for
the
researcher
and
second
of
all,
maybe
antithetical
to
what
we're
trying
to
achieve,
which
is
working
together
to
make
the
internet
safer
as
much
as
we
can,
instead
of
like
in
inviting
a
bunch
of
lawyers.
So
I
and
I'm
not
saying
that
it
doesn't
make
sense
to
ever
involve
lawyers,
but
I
guess
what
I'm
saying
is
moving
this
into
the
grounds
of
like
inspecting
legal
agreements
and
opening
that
up
is
like
more
of
a
normal
thing
as
a
part
of
this
process.
E
A
B
B
What
we
really
want
to
do
is
tell
researchers
how
to
communicate
best
and
most
easily
with
open
source
maintainers
right.
Well,
why
don't?
We
set
up
essentially
a
template
type
thing:
here's
the
sorts
of
things
that
an
open
source
maintainer
will
expect
to
see,
or
they
would
like
to
see
here's
how
you
can
make
their
life
more
easy,
and
I
I
take
this
idea
from
you-
know,
frankly,
open
source.
You
go
to
an
issue.
You
can
have
a
template
there
for
an
issue.
B
Here's
the
things
we
as
a
project
would
like
you
to
to
add,
or,
if
you're
going
to
add
a
a
pip
right.
You
want
to
change
something
in
python.
They
have
a
template
for
that,
so
set
up
the
the
guardrails.
What
are
the
guardrails
that
we
want
them
to
operate
within,
so
everyone
has
life
just
a
lot
easier
frankly,
and
that's
what
we're
looking
for
to
help
as
jennifer
points
out
multiple
times
where
our
end
goal
is
to
help
secure
the
internet
right?
A
That
was
actually
a
point
vicki
we
had
mentioned
earlier
in
the
document.
Wouldn't
it
be
great
if
we
had
an
appendix
of
definitions,
so
that's
that's
one
missing
area
and
the
second
missing
area
is
templates,
which
we
actually
did
on
the
original
maintainer
guide.
We
have
a
stock
security,
md
file
and
a
stock
intake
template.
So
I
think
we
absolutely
need
to
do
that
here
and
provide
researchers.
Here
is
a
a
more
effective
way.
You
can
report
vulnerability
by
having
these
four
data
elements
in
your
report
or
whatever.
A
E
A
Agreed
and
potentially
stylistically
we
may
want
to
change
the
document
that
when
we
have
an
opinion,
we
will
label
it
recommendation
and
then,
when
there
are
other
options
we
can
put
alternatives.
Potentially
we
could
stylistically
have
a
little
box
like
if
you
remember
the
old
for
dummies
books,
you
had
the
little
guy
pop
up,
saying
here's
a
tip
pro
tip,
so
we
could
actually
stylistically
have
something.
This
is
our
recommended.
This
is
the
good
practice
we
endorse,
and
here
are
some
alternative
choices.