►
From YouTube: OpenSSF Vulnerability Disclosures WG (July 27, 2022)
A
A
C
A
A
A
A
A
A
A
Now
this
is
currently
down
at
the
bottom
and
I
closed
the
sidebar,
which
would
make
this
easy.
Hangout
guard
me
all
right,
so
we
do
have
a
glossary
here.
I
went
through
the
document
this
week,
one
of
these
days-
and
I
found
a
bunch
of
jargon
and
acronyms,
and
I
just
put
them
in
a
file-
threw
them
through
sort
dash
you
and
then
plopped
them
here
with
a
cut
and
paste.
A
A
D
A
A
A
Another
thing
that
I
added
this
week
is
the
bibliography
where
pretty
much
I
just
went
through
the
entire
document,
and
I
found
every
single
link
that
was
referenced
and
I
just
plunked
them
all
into
this
area.
This
needs
to
be
cleaned
up
and
put
into
some
sort
of
reasonable
format.
So
it's
not
just
links,
but
it's
actual
text.
A
A
A
Well,
some
of
us
still
print
these
things
from
time
to
time.
I
I'm
not
looking
at
the
agenda
it's
on
the
other
tab.
I
will
jump
to
that
in
a
minute,
but
first
I
wanted
to
point
out
that
there
was
a
call
for
templates
to
make
it
easier
because
everybody
hates
a
blank
page
right
and
there
were
two
templates
that
we
had
previously
created
for
the
earlier
for
the
maintainer
disclosure
guide
I
linked
to
them
here
in
the
template
section.
A
Versions
that
will
be
appropriate
for
finders
rather
than
maintainers,
or
at
least
see
whether
the
maintainer
one
will
qualify.
Is
it
good
as
is,
do
we
need
a
new
version
for
finders
rather
than
simply
maintainers,
and
it's
fine?
If
we
do
totally
cool
files
are
free,
so
we
can
just
create
a
new
file
and
link
to
it.
Also,
while
we're
here,
what
other
templates
do,
we
think
might
make
sense
for
people
to
for
us
to
create.
D
A
D
B
A
D
My
one
fear
my
one
fear
about
this
is
if
we
end
up
having
somewhat
of
a
very
complicated,
even
guide,
to
browse,
if
you
want
to
handle
like
cvd
like,
I
think
it
makes
sense
to
have
like
a
something
for
personal
disclosures,
but,
like
this
guide
is
already
like
already
14
pages
long
right.
If
I
was
to
embark
and
do
this
like
by
myself,
I
would
probably
not
even
rate
past
the
first
two
pages.
B
B
In
my
experience
is
actually
kind
of
interesting
because
you
kind
of
find
both
people
you
find
like,
like
I
have
a
friend
of
mine
who
sends
a
lot
of
this
to
purcell
and
they
want,
like
his
bosses,
want
an
executive
summary
but
then
like
on
the
other
side,
you
have
other
projects
like
astro
with
fred
who
used
to
work
at
google,
who
wants
to
know
all
of
this
stuff
and
will
try
to
read
all
14
pages.
So
I
think
you
have
like
both.
You
have
people
on
both
like
size
of
the
aisle.
A
A
C
Something
else
that
we
had
talked
about
that
maybe
we
could
do
sort
of
the
way
that
I've
been
thinking
about.
This,
too,
is
laying
out
all
of
the
options
available
for
a
reporter,
and
maybe
we
can
even
give
some
more
feedback
in
like
levels
of
maturity
like
I
wouldn't
expect
a
brand
new
reporter
to
go
out
and
make
their
own
personal
vulnerability
disclosure
policy
themselves,
but
if
they're
actively
reporting
this
repeatedly,
that
might
be
helpful
for
them.
C
So
maybe,
if
we
like
organize
the
information
into
not
really
maturity
levels,
because
I
don't
think
it
needs
to
be
like
that
that
defined,
but
that
could
be
helpful.
So,
if
you're,
a
newer
reporter
you're,
really
just
looking
at
like
the
high
level,
most
basics
and
something
else
that
we
had
talked
about
before
that
we
haven't
yet
done
either
is
we
can
explicitly
call
out
in
various
sections
like
this
is
what
the
openssf
recommends.
C
D
C
Yeah
yeah,
I'm
just
thinking
like
that
that
might
even
be
useful
to
surface
like
along
the
way
like
throughout
the
whole
document.
That
way,
if
somebody
wants
to
just
scan
through
it,
they
can
just
look
at
you
know:
open
ssf
recommended
actions
for
each
section.
Basically,
that
might
be,
and
then
from
that
you
could
make
a
really
easy
one.
Pager.
B
B
A
E
E
You
know
you're
you're,
typically
working
with
you
know
engineers
and
volunteers,
and
it's
maybe
much
less
that
business
side
you
might
get
when
you're
working
with
a
commercial
organization
submitting
vulnerabilities
so
just
kind
of
insert
a
little
bit
of
the
human
elements
of
look
have
patience,
they're
volunteers,
their
schedules
are
different.
It
might
not.
E
You
know,
work
out
exactly
as
you're
expecting
timeline,
wise
and
and
the
same
as
referencing
the
the
maintainer
doc
saying
look
and
it's
the
same
for
the
maintainers
they're
recognizing
that
they're
working
with
security
researchers-
and
you
know,
there's
human
elements
for
all
of
this,
and
I
think
I
forget
exactly
where
it
was.
I
think
it's
certainly
where
the
section
was.
I
was
going
to
try
to
work
on
that.
A
Yeah,
it
probably
makes
sense,
there's
a
section
near
the
top,
which
is
covering
I'm
showing
you
on
the
screen
here
right
now,
who
is
an
open
source
maintainer?
What
are
their
motivations
and
then
set
it
a
quick
section
right
there,
because
this
is
right
at
the
top
of
the
document,
and
it
really
helps
to
set
the
mindset
and
you
set
the
expectations
right
up
front:
yeah
you're,
not
working
with
a
corporation.
These
are
individuals,
so
don't
be
a
big
jerk
face.
E
D
D
E
I
think
a
vulnerability
report
submission
template
would
be
important,
so
I
was
going
to
look
around
to
see
if
we
we
have
any.
I
know
we
do
like.
I
know
I
could.
I
could
get
one
also.
If
anyone
else
has
any
that
are
I
mean,
do
we
do?
We
have
one
in
the
maintainer
guide,
like
what
a
vulnerability
report
should
look
like
a
submission.
A
E
A
E
Think
a
submission,
a
submission
template
like
this
is
what
you
should,
and
I
know
we
kind
of
talk
about
it
within
the
document
as
well.
It's
already
written
in
there,
but
this
is
what
your
submission
you
know.
Speaking
to
the
researchers.
This
is
what
your
submission
should
include.
You
know
it
should
have
the
variability
description
it
should
have.
You
know
whatever
details
should
be
there
so
yeah
an
example
would
be
good.
There.
E
C
No,
that
makes
sense,
I
was
going
to
say
we,
the
security
labs
team
at
github
often
takes
on
the
role
of
the
reporter,
because
they're
doing
a
lot
of
vulnerability.
Analysis
work,
so
they
have
guides
internally
that
have
been
shared
with
me
that
I
keep
meaning
to
put
here
too.
So,
I'm
happy
to
once.
We
have
francis's
starting
point.
Add
to
that
too,
if
needed.
A
A
D
A
No,
not
400.,
no,
because
I'd
imagine
this
is
going
to
be
if
it
ever
hits.
10
templates.
I
would
be
really
surprised
if
you
look
at
the
maintainer
guide,
their
templates
there's
only,
I
think,
a
max
of
like
five
or
so,
and
these
three
have
almost
exactly
the
same
content
inside
of
them,
I'm
not
even
going
to
click
through
because
they're
all
the
same.
Actually
I
will
click
the
wrong
one,
because
they're
all
the
same.
A
C
Let
me
check
oh
yeah,
so
we
were
talking
about
specific
vulnerability
identifiers
and
in
this
we're
going
to
recommend
and
say
that
folks
should
get
a
cbe
id.
The
other
thought
was
that
there
are
a
number
of
other
identifiers
floating
around
the
security
ecosystem.
Maybe
it
would
be
help.
It
would
be
helpful
to
define
those
two
for
reporters,
because
they're
likely
to
experience
those
and
the
question
that
we
have
then
I'm
pretty
sure
from
about
two
weeks
ago
is
there
was
a
thought
that
reporters
might
be
able
to
get
an
osv
identifier.
C
A
A
C
E
Yeah-
and
I
think
part
of
the
conversation
was
also
just
that
education
for
researchers-
that
in
some
cases
you
might
work
with
a
project
that
doesn't
isn't
going
to
want
to
use.
Maybe
any
of
the
above,
and
just
that
awareness
that
all
you
might
get
is
a
security
advisory
or
a
ghsa
or
something,
and
that
might
just
be
it.
There
might
not
be
anything
on
top
of
that.
C
A
A
A
A
A
A
E
Was
also
thinking
vicky,
I
had
a
I
had
a
comment
in
that
section.
I
think
it's
who
our
oss
maintainers
or
one
of
those
ones
so
right
in
that
area
where,
if
in
within
this
whole,
explain
the
difference
between
those
two
types
of
open
source
you
might
interact
with
also
just
in
general,
you
could
also
interact
with
a
a
two-person
open
source
shop
or
a
distro
list.
A
D
D
A
A
E
I
think
I
think
one
thing,
and
here
was
definite
some
of
the
definitions
that
we
have,
because
you
know
this
is
a
it's
a
combination,
right
of
of
of
experiences.
I
think
all
of
us
putting
contributing
here.
Maybe
if
we
are
able
to
find
a
standard,
I
don't
know
if
cert
has
actual
like
definitions
of
what
these
are
versus.
E
Some
of
the
definitions,
we've
kind
of
put
into
this
already
because
crystal
and
I
were
looking
through
some
of
these
and
we
were
like
well
full
disclosure
in
our
day-to-day
experience.
Full
disclosure
just
means
disclosing
the
entirety
of
the
report,
not
necessarily
what
we
have
full
disclosure
defined
as
or
for
as
far
as,
like
you
know
doing
that
as
a
last
resort.
A
E
Yeah,
I
can
definitely
take
a
look
at
some
of
the
references,
I'm
not
sure.
I'm
not
sure
I
want
to
be
the
ones
writing
definitions
for
these.
I
like
that
they're
already
there,
but
if
I
can
find
the
resources
that
we
all
can
agree
upon
and
and
reference
those
I'm
happy
to
I'm
happy
to
collect
some
of
those,
and
I
know
some
of
that
works
going
into
the
glossary
already.
C
A
A
A
C
Yeah
one
thing
that
I
just
thought
of,
because
you
just
said
two
weeks:
I
myself
am
not
traveling
to
defcon
or
black
hat,
but
I
imagine
many
people
in
this
group.
Maybe
so
our
next
meeting
in
two
weeks
takes
place
then
I'm
not.
That
might
be
something
we
want
to
review,
maybe
cancel
or
move,
as
I
imagine
many
people
that
are
in
this
group
will
be
attending.
E
I'm
also
thinking
through
this
section
here,
because
a
lot
of
it
is
coming
from
the
and
I
I
I
doubt
we're
going
to
be
able
to
answer
this
on
the
spot
here,
but
some
of
these
sections
might
not
even
apply
and
might
not
even
you
know,
rank
high
enough
as
we're
prioritizing
what
we
want
to
include
and
what
what
might
be
a
little
extra?
How
do
we
vote
on
that.
E
Would
we
even
want
to
write
something
like
that
in
the
researcher
guide
like
you'd
have
to
reframe
it
for
the
researcher,
and
then
we
have
to
assess
if
we
even
want
to
keep
it
in
the
guide?
Is
there
do
we
have
a
process?
Maybe
of
assessing
this
first
stop
and
saying?
What
do
we
want
to
keep
in
here
and
then
rewrite
it?
For
the
researchers
perspective.
A
I
don't
think
we
officially
have
a
process,
although
I
certainly
applaud
the
optimism
of
asking
whether
we
do,
I
think
probably
the
best
way
to
approach
it
at.
This
point
is
if
someone
would
like
to
volunteer
kayla
to
to
take
a
first
pass
at
this,
maybe
doing
it
in
suggest
mode,
first
or
maybe
going
through
and
like
if
there's
something
you
think
doesn't
belong
because
you're
right
it.
E
Okay,
I'm
happy
to
take.
I
like,
I
love,
suggest
mode,
because
then
it
can
just
be
accepted
or
denied.
So
I'm
happy
to
go
through
this
and
suggest
mode
and
just
kind
of
kayla's
thoughts
on
whether
or
not
we
should
keep
this
for
refraining
or
not,
because
I
think
otherwise
someone's
going
to
put
a
lot
of
work
into
translating
this
for
the
researcher
and
then
we
might
take
a
look
at
something
and
be
like
shouldn't
even
stay.
So
I'm
happy
to
suggest
mode
here.
A
Excellent
pro
is
going
to
be
so
proud
of
us
all
right,
review,
brainstorming
ideas
on
p12,
and,
what's
that
that's
another
meeting
notification
that
I
can
ignore.
Oh
all,
right!
No,
you
know
I'm
closing
this
tab.
I
keep
clicking
it.
I
should
all
right
p12,
I'm
sorry
what
was
the
subject?
Brainstorming
ideas
on
p12.
A
A
A
A
D
A
E
Well,
it's!
It
is
a
little
bit
referenced.
I
think
we
could
take
a
look
and
let's
see
if
it's
enough
or
not
like
on
page
five
there's
some
suggested
text
that
says
you
know,
or
example,
exploit
include
it
after
you've
established
a
secure
channel.
So
we
have
some
stuff,
but
I
don't
think
it
has
its
own
section.
D
We're
gonna,
I
don't
think,
you're
wrong.
I
was
just
gonna
say
that
there
is
some
resources
about
documented
processes
around
like
box
and
exploits
in
general.
Like
I
know,
project
zero
has
somewhat
of
a
public
thing
about
like
providing
exploits
roughly
30
days
after
disclosure
just
to
give
time.
This
is
something
we
could
piggyback
on
and
reuse.
A
A
A
D
D
A
A
C
We
just
like,
at
a
very
high
level,
say
in
the
and
having
your
own
personal
vulnerability.
Disclosure
policy.
Part
of
that
is
picking
your
own
timeline,
so
we
don't
give
a
recommendation
for
numbers
in
there
by
any
means
or
specific
dates,
but
just
that's
that's
referenced
in
there,
but
it's
it's
clearly
not
done.
I
imagine
that's
why.
E
A
A
D
A
E
Section
yeah
yeah:
we
can
go
ahead
and
this
was
actually
one
of
the
last.
I
think
the
last
item
to
discuss
on
specifically
for
this
as
well.
We
can
erase
vulnerability
disclosures
policy
content
all
the
way
through
the
end
of
the
I
can
do
it,
I'm
happy
to
erase
it,
but
that
was
the
section
that
crystal
and
I
worked
on
and
we
I
took
all
that
and
crunched
it
into
a
format
that
would
fit
above.
A
A
So
we've
got
a
lot
of
action
items
for
people.
If
you
don't
have
action,
items
feel
free
to
dive
in
and
help
on
the
document.
Anyway,
I
also
will
email
the
group
here.
We
go
in
two
weeks
to
see
whether
we
will
be
meeting
because
of
defcon
and
the
like
and
huge
props
to
madison
for
pointing
that
out
all
right.
Anything
else.