►
From YouTube: Vulnerability Disclosures WG (October 26, 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
Okay,
hello:
this
is
the
open
source
security
foundation.
Vulnerability.
Disclosures
working
group
meeting
today
is
october,
26
2020,
and
let
me
pull
up
the
agenda
doc
here
really
quickly,
so
you
can
see
what's
in
what's
in
stock
today,
so
I
didn't
put
it,
but
some
helpful
person
left
a
note
ensure
that
the
meeting
is
being
recorded,
for
which
I
thank
you
and
I
haven't
seen
it
before
so,
but
the
meeting
is
being
recorded
so
so
we
should
be
good.
A
I
and
our
usual
opening
section
is
welcome
welcoming
new
team
members.
So
is
there
anyone
who's
pure
for
the
first
time?
Unfortunately,
I
missed,
I
missed
the
previous
meeting
and
it
wasn't
recorded.
So
I
don't
know
who
has
been
here
the
last
time.
I
definitely
see
a
few
familiar
faces
from
past
meetings.
B
A
So,
what's.
B
What's
your
interest
in
this
group
and
welcome
so
yeah,
I'm
working
the
product
management
group
of
white
source,
so
we
spend
most
of
our
time
with
open
source
dependencies
and
particular
vulnerabilities,
and
I
joined
white
source
after
building
a
open
source
dependency,
automation,
tool
called
renovatebot.
A
That's
that's
cool,
that's
cool!
To
have
you
it's
actually,
I
think,
there's
a
lot
of
overlap
between
your
work
and
what
we're
trying
to
do
here
so
welcome
once
again.
Anyone
else
that
I
haven't
seen
before.
C
I
joined
the
last
meeting,
but
this
one
I
guess
I'm
a
member
now
of
the
group.
My
name
is
martin.
I
work
for
red
hat
product
security,
I'm
a
software
engineer,
and
so
I
work
on
on
the
tools
that
produce
some
of
our
security
data
and
then
support
some
of
the
internal
workflow
workflows
of
the
product
security
team,
and
my
main
interest
in
this
group
is
not
just
the
definition,
I
guess
and
use
of
standards
to
share
security
data,
and
I
have
a
bit
of
experience
with
that.
A
Oh
and
there's
actually
there's
actually
a
topic
later
on
in
on
on
the
agenda
that
I
think
we
could
use
their
expertise
and
and
input
on
okay.
So,
as
usual
I'll
start
with
some
governance
and
organization
topics.
So
after
it's
it's,
actually
you
can
blame
it
all
of
me.
It
was
on
my
to-do
list
for
a
long
long
time
and
I
put
together
a
doodle
poll
to
allow
us
to
find
a
better
meeting
time.
A
So,
if
you
haven't
already,
I
know
that
some
of
you
already
responded,
but
if
you
haven't
like
take
the
time
to,
let
us
know
which
times
work
best
for
you
and
after
after
some
time
of
no
new
responses
coming
in
I'll
use
this
doodle
to
suggest
either
a
totally
new
time
for
for
our
working
group
meetings
or
maybe
like
two
candidate
times
that
we
could
alternate
between
to
accommodate
people
from
from
different
time
zones,
if,
like
just
the
distribution
of
answers,
is
gonna
be
like
bimodal,
but
there
are
going
to
be
two
outstanding
times
that
work
for
for
many
folks.
A
We
might.
We
might
do
it
like
that.
I
know
that
of
a
few
kind
of
successful
working
groups
in
the
industry,
that
kind
of
use
that-
and
I
think
it's
it's
cool-
to
accommodate
people
from
from
different
time
zones.
I
don't
think
we've
had
like,
for
example,
the
problem
of
like
people
from
apac
wanting
to
attend
people
from
europe
and
people
from
america's
trying
to
attend.
A
I
think
this
group
is
mostly
europe
and
americas,
but
if
we
could
open
ourselves
to
maybe
people
from
apac
who
would
want
to
attend
them,
then
why
not
one
other
thing
that
we
haven't
discussed
is
like
the
the
cadence
of
those
meetings
because,
like
historically,
we
have
inherited
the
cadence
of
every
third
week
from
the
open
source
security
coalition
days.
A
If
this
doesn't
work
for
us,
it
would
be
lovely
to
for
you
to
state
that
you
can
put
a
comment
on
this
github
issue:
number
63
or
post,
like
your
preference
on
on
the
email
list,
so
maybe
I'll
as
an
action
item
for
myself
I'll
start
that
thread
somewhere.
If
because,
like
time
time
times
demeaning
is
one
thing
with
cadences
is
is
also
important.
A
Does
that
make
sense,
or
does
anyone
have
a
strong
opinion?
They
do
want
a
voice
right
now.
D
I'll
just
add
for
you,
martin,
that
I've
there
have
been
many
meetings
like
this,
not
this
one,
obviously,
but
I've
not
been
able
to
attend
due
to
various
standing
conflicts.
So
I
think,
having
alternating
times
is
lovely
because
there's
always
going
to
be
somebody.
We
miss.
A
Right
right,
definitely,
okay,
so
I'm
gonna,
I'm
gonna
definitely
take
that
into
consideration,
because
I
I
like
took
a
preview
on
the
on
the
poll
results.
There
are
definitely
there's
definitely
more
than
one
time
slot
that
works
for
a
lot
of
people,
so
I
think
I
think
we
should
be
able
to
do
that,
and
perhaps
that
way,
we're
gonna
be
able
to
have
like
a
more
frequent
cadence
of
meetings
as
well,
which
which
I
think
would
be
would
be
pretty
cool.
E
And
just
a
thought
on
that
one,
I
don't
think
we
want
to
wait
too
long
to
decide
on
those
dates,
because
I
know
I
picked
what's
currently
free
for
me
and
once
I
get
to
about
one
to
two
weeks
out
from
a
particular
week,
it
starts
to
fill
because,
unfortunately,
my
life
is
very
full
of
meetings.
A
Oh,
I
I,
I
think
that
I
think
that's
a
common.
I
don't
want
to
call
it
a
problem,
but
I
think
I
think
that's
a
common
phenomenon.
Okay,
so
would
it
make
sense
for
us
to
time
box
this
say
by
I'll
wait
for
the
results
until
the
end
of
this
week,
basically
and
then
try
to
announce
a
new
time,
essentially
so
that
we
have
clarity
starting
next
week.
A
Okay,
cool!
That's!
That's!
That's
a
very
good
outcome!
Thank
you,
alrighty
and
as
for,
if
you're,
okay,
we
can
move
to
to
other
topics
or
is
there
anything
else
that
I
haven't
thought
about
for
like
the
meeting
times
and
cadence
and
stuff.
F
I
just
said
one
comment:
I
had
my
hand
up
in
the
zoom.
I
don't
know
if
we're
using
that
the
just
to
echo
in
the
the
last
comment
I
so
alternating
meanings,
perfect
sounds
good.
My
only
ask
would
be
when
we
schedule
the
meetings.
A
Oh
okay,
so
our
approach
here
was
like
a
little
bit
different
in
that
all
the
meetings
are
on
the
community
calendar
so
like
we
could
do
two
things.
I
could
add
you
to
that
invite
or
you
could
copy
that
invite
to
your
calendar.
I.
A
Yeah
because
those
that
are
in
the
community
calendar
are
set
up
like
in
perpetuity,
so
they
they're
just
there,
but
maybe,
as
we're
gonna
adjust
the
time
anyways
I
can
actually.
I
need
to
check
because
I
think,
when
I
add
a
meeting
to
the
community
calendar,
I
can
invite
people
as
well,
which
would
kind
of
solve
both
cases.
A
A
Thank
you,
okay,
so
for
today,
actually
we
I
want
to
talk
about
two
things
and
recently
we've
had
apr,
and
I
think
you
you
had
a
discussion
with
that
rob
led
about
like
what
is
it
that
we
want
to
this
working
group
to
to
be
concerned
with,
and
one
of
the
first
items
that
is
there
on
that
list
is
that
we
identify
and
try
to
address
security
pain
points
for
different
parties
involved
in
open
source
security
and
based
on
the
different
discussions
and
presentations
that
we
had
in
past
meetings.
A
We,
I
think
we
we
focused
on
like
maintainers
consumers
of
open
source
and
security
researchers
as
the
main
kind
of
actors
in
in
this
ecosystems
that
that
we're
interested
in
so
this
is.
This
is
a
topic
that
I
think
could
generate
a
lot
of
our
like
the
agenda
for
for
for
our
future
meetings
and
activities,
and
the
other
topic
is
a
slightly
more
tactical
in
nature.
A
In
that
previously,
we
have
come
up
with
a
vulnerability
description
like
metadata
format
in
json,
and
we
had
a
use
case
for
that
that
was
centered
around
like
automation
of
a
workflow
between
hackerone
and
github,
and
this
is
where
we
want
to
wanted
to
apply
that.
A
But
martin
brought
up
a
very
good
question
like
if
this
is
the
best
use
of
our
time,
because
there
are
a
number
of
competing
competing
or
complementary
standards
that
we
could
potentially
use
to
address
the
same
the
same
goal.
A
So
if
we
could
like
do
a
little
bit
of
discussion
if
we
want
to
continue
working
on
that
schema
or
if
this
is
something
we
totally
want
to
drop
and
put
our
collective
efforts
in
making
sure
that
the
existing
standards
are
better
suited
to
the
pain
points,
we're
trying
to
address
for
different
actors
in
in
the
ecosystem
in
the
community,
that
would
that
would
be.
That
would
be
awesome.
Does
this
sound
like
a
good
plan
for
today,
yep,
okay,
call
you!
Yes,
yes,.
A
Alrighty
so,
based
on
your
experience
like
what
are
the
main
security
pain
points
for
I
don't
know
if
we
have
people
here
who
are
going
to
represent
the
maintainer
community,
I
think
we
do
and
for
consumers,
or,
I
think,
we're
kind
of
missing
a
bit
of
the
security
research
kind
of
perspective.
But
maybe
we
can.
E
I
can
speak,
I
can
speak
to
security
researchers
partially.
My
side
project
is,
I
think
I
mentioned
this
last
time,
but
you
weren't
here
the
internet
of
dong's
project,
which
we
collect
vulnerabilities
and
do
research
on
adult
devices
and
report
them
to
the
people
who
are
maintaining
the
software
and
it
is
a
mess.
So
I
can
definitely
talk
to
that
part
of
it.
A
Okay,
awesome,
so
what
kind
of
problems
do
you?
How
do
you
kind
of
see
there
that
we
could
potentially
like
either
try
to
address
or
try
to
come
up
with,
maybe
not
a
solution,
but
we
can
engage
other
groups
of
like
industry,
working
groups
and
and
standard
bodies
and
stuff
and
stuff
like
that.
A
E
Think
kind
of
referencing
the
second
point
in
the
first
point,
without
us
having
to
necessarily
do
any
design
work,
because
I'm
not
sure
that
we
want
to
do
that
today.
I
think
part
of
something
that
I
hear
from
a
lot
of
people
in
the
bug.
Bounty
groups
that
I'm
in
is
they
don't
exactly
know
what
information
is
going
to
be
needed
or
useful,
so
you'll
go
to
a
website
and
you'll
see
that
there's
a
security.text
to
the
website
or
something
there's
certain
things.
E
E
E
I
don't
know
I
submitted
into
this
black
box
and
occasionally
they
asked
me
later
to
talk
to
them,
so
I
think
just
being
able
to
provide
guidance
on
here's,
what
you
should
provide
them.
Here's
what
you
should
expect
to
happen
next,
here's
what
you
should
be
ready
for
and
here's
the
standards
you
can
look
at
because
it's
going
to
vary
by
company,
but
here's
the
top
four
standards
or
whatever.
A
Right
so
that
sounds
a
lot
like
you
know,
managing
or
fostering
like
more
standardization
for
vulnerability
disclosure
programs
because,
like
I
think
like
correct
me,
if
I'm
wrong,
but
if
someone
I
would
assume
like
starts
a
bug
bounty,
they
kind
of
should
have
like
higher
level
of
maturity,
and
hopefully
they
flash
those
things
out,
for
you
know
vulnerability
management
for
sorry
vulnerability.
Disclosure
programs
like
if
someone
just
puts
out
a
security,
txt
file
and
an
email
inbox
with
a
pgp
key.
A
You
really
can't
have
that
feeling
that
you're
submitting
into
a
black
box,
like
I
I
hate
to
like
call
people
out
but
read,
do
you
like?
Do
you
offer
some?
I
don't
like
templates
or
things
like
that
for
programs
on
hacker
one
that
kind
of
help
them
get
started
in
in
this
direction.
H
Yeah
I
mean
we,
you
know,
as
people
are
launching
programs,
we
help
them.
Well,
we
talk
to
them
about.
What's
going
to
be
the
scope
of?
What's
you
know
their
program,
whether
it
be
a
vdp
or
bug,
bunny
program,
vdp
being
just
a
purely
vulnerability
disclosure
program,
and
then
we
have
templates
and
that
put
together.
Okay,
what
are
the
things
that
you're
interested
in?
H
What
are
the
things
you
don't
want
interest
in
and
kind
of
what
that
process
looks
like,
and
then
you
know
the
platform
itself
offers
a
lot
of
information
on
the
like
the
time
to
certain
things,
time
to
triage
time
to
bounty.
If
it's
about
any
program
so
try
to
give
some
transparency
to
the
to
the
researchers
that
they're
submitting
stuff
you
know.
H
Obviously
the
the
the
big
thing
here
is
that
communication
is
the
one
of
the
most
important
things
is
just
making
sure
that
you're
setting
expectations
with
both
sides
and
that
you
know,
you're
updating
those
expectations
if
things
change-
and
so
I
think,
that's
yeah-
we
this
this
comes
up
all
the
time.
H
E
And
then,
from
my
side
of
things,
the
hacker
one
like
templates
are
very
handy,
like
people
who
participate
in
that
are
a
lot
less
confused
and
concerned.
So
what
y'all
are
doing
is
definitely
useful.
I
But
I
for
an
open
source
community
though
they
may
not
be
using
hacker
one
right.
They
may
not
be
offering
a
bug
bounty
and
I
think
you
know
having
it
using
a
template
for
a
bdp
can
come
from
the
iso
standards.
Two
nine
one,
four,
seven,
three
one
one
one!
You
can
also
look
at
first.org,
there's
the
pcert
sig.
I
That's
created
the
the
pcr
framework
as
a
guide,
but
I
think
the
key
is
that
for
every
open
source
project
of
some
weight
that
can
handle
it
right
should
have
a
vdp
where
they
talk
about.
You
know,
what's
expected
how
you
know
how
to
work
with
us
and
what
information
is
needed.
You
know
I
can't
you
know
I
couldn't
agree
more
to
call.
I
think,
that's
a
big
mess
for
a
lot
of
places
to
not
have
that.
I
You
know
that
kind
of
transparency,
and
even
then
it's
it's
going
to
be
an
evolution,
for
whatever
project
is
implementing
that
they're
going
to
have
to
recognize
that
it's
not
a
one
and
done
you.
Don't
just
publish
something
and
you're
finished
you're,
going
to
learn
from
the
researchers
you're
engaging.
A
Yeah,
I'm
so
so
I
you
know,
I'm
wondering
because,
like
a
lot
of
more
mature
projects,
especially
with
corporate
participants,
are
perfectly
capable
and
resourced
to
do
that,
but
there's
a
lot
there's
a
lot
of
open
source
communities
that
they
don't
know
where
to
start
and
b.
I
don't
even
know
like
how
such
a
program
might
look
like,
because
it's
it's
it's
not
their
speciality,
all
right,
they're,
they're
experts
in
writing,
like
you
know,
web
frameworks
or
whatever,
whatever
else
but
they're,
not
necessarily
expert
on
handling
security
vulnerabilities.
A
So
I'm
I'm
wondering
if
what
we
could
do
as
a
working
group
to
kind
of
help,
those
communities
that
don't
have
access
to
that
expertise
and
infrastructure.
I
Well,
I
sorry
didn't
interrupt
that
on
that
week,
but
I
think
it
makes
a
lot
of
sense
that
for
us
to
help
come
up
with
that
framework
and
we
can
benefit
from
what's
been
done
in
maybe
a
closed
source
community.
So
just
just
so
everybody
knows
right.
I'm
josh!
I
work
at
intel
and
I
run
their
pcr
team
bug
downing
program
and
I
we
have
challenges
right
now
between
us
and
the
open
source
community
right,
there's
a
lot
of
our
our
products
with
that.
I
That
may
be
closed
source
that
depend
on
open
source
components
and
we're.
Maybe
you
know
we're
developing
our
communication
strategy
back
and
forth
and
what
is
the
best
way
to
handle
those
vulnerabilities
that
that
have
you
know
and
are
affected
by
the
open
source
community
or
affect
the
open
source
community,
and
I
think
this
is
where
you
know
we
can
benefit
each
other,
those
that
have
experience
in
open
source
and
those
that
spend
time
in
closed
source.
I
How
do
we
work
together
better
and
what
structure
do
we
set
up
to
communicate
and
I
think
you're
starting
it
right
by
focusing
on
the
pain
points
for
the
different
areas?
You
know
the
one
other
area
might
be
to
add
is
closed.
Source
communities
or
vendors
to
this
is
as
a
a
stakeholder.
Maybe.
A
Yes,
so
so
in
the
past,
I
I'm
helped
one
of
like
I
have
tried
to
help
the
node.js
community
and
the
openjs
foundation
to
kind
of
make
sure
that
projects
either
have
like
they're
for
projects
that
are
under
some
governance,
like
that,
there
are
clear
expectations
that
you
will.
That
project
should
have
a
security
policy.
The
security
policy
should
have
things
like
how
to
report
a
vulnerability,
but
on
the
other
hand,
there
is
some
help
in
terms
of
okay.
A
You
put
a
security
policy
out
there,
but
if
someone
actually
emails
you
with
a
vulnerability
disclosure
like
what
do
you
do,
that
you
discourage
people
from
putting
that
in
the
public
bug
trucker
and
like
you,
communicate
with
with
them
later
on
work
and
work
on
a
disclosure?
A
So
I
wonder
if,
if
this
is
something
where
we
could
plan
on
like
having
working
on
a
deliverable
of
some
sort,
that
would
be
like
a
starting
starter
pack
for
open
source
projects
that
they
could
adopt
and
it's
like.
Okay,
we
have
an
open
source
project
and
it's
been
fairly
successful.
We
don't
yet
know
how
to
do
security,
but
we
heard
it's
important.
So
how
do
we
start
and
then
open
source
security
foundation?
Being
this
vendor
neutral
organization?
A
H
G
So
one
point
that
that
is
also
worth
considering
is
to
try
consolidate
documentation
and
also
help
point
a
little
better,
because
there
are
things
like
the
embarg.
The
oss
security
embargo
list
called
the
linux
distro
list,
which
can
sort
of
short-circuit
a
lot
of
the
processes
getting
patches
to
distributions.
G
But
if
you're
not
aware
of
the
of
the
mailing
list,
you're
not
that
likely
to
go
to
the
list
and
that
sort
of
also
sometimes
makes
this
a
bit
confusing.
How
do
you
do
embargoed
vulnerabilities
properly?
How
should
you
manage
it
and
how?
What
are
the
distributions
or
the
different
linux
distributions
approach
to
handling
embargoes
as
well
so
sort
of
explaining
that
portion
of
learn
build
disclosure
can
also
help
get
patches
to
the
correct
places.
A
Well,
that
that
that's
a
fair
point
that
we
even
address
like
okay,
if
you,
if
you're
a
project,
if
you
think
you
need
to
engage
in
like
a
coordinated
disclosure
like
yeah,
who
you
reach
out
to
what
are
your
options
like
how
embargoes
work
and
stuff
like
that.
G
Yeah
and
I
think
just
handing
out
that
information
helps
a
lot
to
to
projects
that
are
in
distributions
or
are
packaged,
but
are
not
sure
how
to
approach
the
problem.
So
that
will
also
be
maybe
a
bit
just
not
be
that
much
work,
but
will
help
the
community
fairly
easily.
I
think.
A
Cool,
so
so
we
kind
of
moved
slowly
from
from
security,
researchers
to
the
maintainer
community
and-
and
I
think
like
this
is
this-
is
probably
the
largest
like
the
larger
crowd.
The
consumers
are
probably
the
largest
crowd,
but
definitely
the
crowd
of
maintainers
is
larger
than
the
security
research
community.
I
think
so
I
and
I
and
I
think
in
in
this
group.
A
We
really
have
like
everyone
in
between
like
people
who
have
just
put
out
like
a
hobby
project
put
in
github,
and
it
became
success
all
the
way
up
to
like
commercial.
You
know
multi-billion
dollar
companies
that
either
are
built
on
open
source
as
a
business
model
or,
as
josh
mentioned,
have
like
a
significant
or
non-trivial
open
source
footprint
so
like
at
this
point,
I
think
I'm
not
even
sure
like
which,
which
group
on
the
spectrum
we
could
even
try
to
address.
J
Most
of
the
pain
points
that
are
described
under
the
security
researchers
could
be
met
could
be
improved
with
without
recommendations
to
maintainers,
because
what
the
researchers
have
as
a
problem
is
that
the
maintainers
don't
know
often
how
to
run
like
a
successful
disclosure
program.
So
I
think
those
the
pain
points
of
the
one
and
the
pain
points
of
the
other
are
very
interconnected.
I
That's
a
good
point,
and
I
I
would
say
that
I
mean
you,
you
would
address
the
stakeholders.
I
think,
if
you
started
by
a
top
down
perspective,
look
at
it
from
the
point
of
view
that
okay,
you've
got
an
open
source
project.
How
do
you
handle
security
vulnerabilities
now,
and
this
is
the
step-by-step
down
the
line
right?
These
are
all
the
things
that
you
need
to
have
in
place
in
order
to
to
handle
security
vulnerabilities
and
to
address
the
stakeholders
needs
like,
for
example,
you
know
having
a
vdp.
How
do
you
craft
that?
I
What
infrastructure
do
you
need
in
place
to
handle
security
vulnerabilities?
Do
you
need
to
be
a
cna?
Should
you
be
a
cna?
What
other
ways
can
you
get
cdes?
What's
coordinated
disclosure,
and
how
do
you
handle
that?
You
know
what
makes
it
unique
for
open
source?
I
know
I'm
rattling
off
a
lot,
but
it's
and
you
can
create
this
framework
that
would
address
all
of
this.
It's
again.
What
we
did
in
the
piecert
sig
is
to
create
a
similar
framework
for
p
certs,
but
you
we
could
overlay
some
of
that
into
this
space.
I
F
I
think
we
have
to
acknowledge
as
well,
though,
that
you
know
I
I
believe
you
know
part
of
our
mission
right
is
to
solve
for
this
problem
set
in
open
source,
where
there
will
be
mission-critical
projects
where
there
are
one
maintainer
who's
doing
this
part
time,
and
they
are
not
going
to
create
a
sig
they're
not
going
to
do
any
of
that
stuff.
So
you
know
they're
they're,
probably
not.
They
may
not
even
be
interested
in
in
addressing
the
vulnerabilities
right
or
not
have
that
in
their
the
top
of
their
priority
list.
That's.
F
F
A
Discussion
like
that
there
is
a
there
is
a
piece
of
code,
and
if
this
piece
of
code,
while
being
important
for
it's
downstream
consumers
like
is
it
set
up
in
a
way
that's
sustainable,
going
forward
and
security
is
a
part
of
it.
Whereas
I
think
this
working
group
like
it's,
it's
focused
on
vulnerability,
disclosure,
or
at
least
that's
how
that
has
been
like
our
initial,
our
initial
chart,
and
the
name
of
the
group
suggests
that
we
want
to
deal
with
like
the
mechanics
of
like
okay.
How
do
you
submit?
A
How
do
you
disclose
who
he
is
close
to
and
how
and
I'm
like
setting
up
like
this-
is
just
me
thinking
out
loud.
So
I'm
super
happy
to
have
that
discussion
continue,
but
I
think
like
if
we
focus
on
like
solving
the,
how
do
we
help
the
entire
open
source
ecosystem
to
set
themselves
up
in
a
way
that
allows
them
to
get
to
a
point
where
it's
able
to
deal
with
security
reports?
It
doesn't
perhaps
not
necessarily
what
we
have
started
with
in
mind
if.
A
That's
a
that's
a
that's
a
good
thing
for
us
to
pick
up.
I'm
super
happy
to
to
to
talk
some
more
about
this.
I
think
it
might
be
good.
F
No,
I'm
sorry
I
was
just
gonna
say
I
agree
with
what
you're
saying
entirely.
I
just
think
we
have
to
keep
it
in
the
back
of
our
heads
as
well,
though,
that
you
know
we
have
to
make
sure
we
don't
create
unrealistic
burden.
Sorry
go
ahead.
E
It
might
be
good
to
have
maybe
maturity
markers
like
if
you're,
if
you've
ended
up
here
and
you're,
just
looking
for
the
simplest
fastest
way,
the
the
most
manual
simplest
fastest
way
to
handle
a
security
report
that
you've
got
here's
our
recommended
frameworks
that
are
out
there
that
you
should
look
at,
and
you
know
here's
a
quick
checklist
of
the
processes
you
should
follow.
If
you're
more
mature.
G
So
to
try
expand,
maybe
a
little
bit
on
it,
but
we
could
try
assume
the
person
that
looks
up
these
resources.
Resources
are
interested
handling,
vulnerability,
disclosures
and
that
we're
not
trying
to
make
maintainers
interested,
but
we
should
maybe
assume
they
are
interested
from
the
get-go.
So
you
sort
of
narrow
down
the
scope
a
little
bit,
so
you
can
try
and
cater
to
the
maintainers
that
are
interested
and
when
we
have
managed
that
part
we
can
maybe
see.
G
I
I
think
that's
I
think
it's
the
both
of
those
are
good
approaches.
I
think
if
we
have
a
way
for
people
to
understand
that
you
know
there's
pros
and
cons
to
implementing
this,
I
mean
there's
weight
to
it,
but
if
you-
and
if
you
don't
do
it,
you
know
you
may
have
to
deal
with
certain
challenges
around
disclosure-
you
don't
have
a
system
in
place,
not
that
it's
a
bad
thing.
It's
just
the
fact
of
life
that
you
know
there
may
be.
There
may
be
procedural
challenges
for
you.
I
You
know
by
not
having
an
established
system
in
place
to
handle
these.
Then
you
may
not
be
able
to
at
the
right
time
in
your
maturity
to
be
able
to
handle
that.
But,
as
you
grow
as
the
community
grows
or
the
project
grows,
you
want
to
definitely
be
able
to
give
them
insight
into
how
to
how
to
grow
into
that
into
the
space.
A
Yeah,
and-
and-
and
with
with
that
in
mind,
I
think
like
that's
just
maybe
you
might
think
maybe-
and
I
would
definitely
love
to
hear
your
opinion
about
this.
But
I
think
if
we
were
to
make
a
dent,
then
I
think
trying
to
help
like
the
broad
group
do
the
minimum
right
thing.
It's
probably
have
a
larger
impact
rather
than
trying
to
perfect
what
the
large
organizations
do,
because,
like
I'm
still
trying
to,
I
can
learn
from
this
discussion.
A
What
is
it
that
we
focus
on
as
a
working
group,
and
I
think
there's
a
lot
that
we
could
do
in
like
like,
for
example,
to
to
use
that
example
of
something
we
have
on
the
agenda
for
for
later
for
later
today
is
that
we
could
have,
like
a
very
you
know,
informed
discussion
about
trying
to
unify
all
those
vulnerability
and
advisory
automation,
standards,
and
but
I
a
hunch
that
would
help
primarily
like
larger,
more
mature
projects,
and
that
is
a
perfectly
legitimate
area
of
focus.
A
But
on
the
other
side
of
the
spectrum,
we
could
also
try
to
focus
like
on
on
projects
that
don't
have
anything
today
and
would
be
better
off
having
something
like
just
a
security
policy
build
some
awareness
around
like
what
are
the
best
practices
for
even
accepting
the
vulnerability
report.
How
to
you
know,
keep
it
private
until
disclosure
and
and
basic
stuff
like
that.
A
But
then
again
we
were
getting
back
to
the
idea
that
there
is
a
spectrum,
and
we
have
you
know
probably
finite
time
and
resources
here
and
the
questions.
What
do
we
focus
on
which
really
boils
down
to
like?
What
do
you
feel
is
the
impact
we
could
make
and
should
apply
our
resources
to.
E
I
think
I
forget
who
mentioned
it
earlier,
but
start
with
the
assumption
that
there's
somebody
who's
interested
in
doing
this
and
they've
ended
up
here,
because
they
don't
currently
have
a
process
and
have
that
be
like
our
first
goal
and
if
we
can
solve
for
the
person
who's
already
interested
and
wants
to
do
a
thing,
but
doesn't
know
what
to
do
and
give
them
something
to
work
with.
We
can
then
keep
working
up
the
maturity
ladder
ourselves
later,
but
we
could
just
start
at
the
bottom
and
then
go
up.
A
So
maybe
that's
a
a
separate
discussion
to
be
had
if
we
were
to
address
that
concern
like
what
we,
what
kind
of
deliverables
would
we
would
we
think
about,
so
that
that
that
would
be
an
action
item
for
me
to
start
a
separate
discussion
on
github
or
on
the
mailing
list,
is
how
do
we?
How
do
we?
How
do
we
get
that
going?
So
we
have
spoken
relatively
little
about
consumers
so
for
for
consumers?
A
What
I,
what
I'm
thinking
is
that,
like
facilitating
you,
know
cvs
and
getting
that
process
more
efficient,
for
everybody
is
probably
something
that
I
think
was
permeating
through
a
lot
of
our
discussions
lately
that
that
we
there
is
nothing
that
we
should
actually
like,
reinvent
or
redesign,
but
making
the
current
system
easier
to
engage
with
easier
to
consume
information.
K
One
other
consideration:
I'd
throw
out
from
a
consumer
standpoint
is
around
this
conversation
of
software
bill
of
materials
and
really
having
an
inventory
of
the
downstream
libraries
that
are
used.
Maybe
you
consume
electron
and
understanding
all
of
the
other
dependencies
that
you
come
that
come
with
that
and
being
able
to
have.
You
know
that
mythical
single
pane
of
glass,
view
of
all
vulnerabilities
affecting
all
of
your
downstream
dependencies
would
be.
I
don't
know,
that's
maybe
outside
the
scope
of
this
working
group,
but
from
an
open
source,
consumer
consumption
standpoint.
That's
a
big
challenge.
G
So
what
I
I
think,
enabling
consumers
of
security
security
disclosures
is
actually
to
try
standardize
on
the
data
formats
that
we
propose
a
push
forward.
I've
talked
with
marcus
from
susa
and
I
was
just
asking
if
they
provide
an
api
for
their
secure
advice
series
and
they
said
no,
because
they
there's
simply
no
standardized
json
schema
that
people
standardize
on.
So
I
think,
trying
to
figure
out
the
sort
of
the
last
point
in
the
agenda
which
json
schemas
or
which
data
formats
or
do
we
want
to
try
push
forward.
G
The
standards
helps
sort
of
can
push
the
consumers
forward
in
positive
direction
and
it's
probably
the
one
of
the
largest
hurdles
of
consuming
vulnerability.
Disclosures
currently.
C
I
will
also
add
that
a
lot
of
these
open
source
projects
don't
realize
that
they
are
producing
something
that
others
are
consuming.
I
I
write
a
couple
of
tools
that
try
to
intake
vulnerability
data
and
we
have
like
block
parsers
in
there
and
scraping
html,
and
you
know
diffing
websites
just
to
get
that
information.
C
So,
oh,
I
think
the
focus
of
this
group
should
also
be
teaching
the
projects
that
hey.
You
know.
Others
are
interested
in
this
information,
so
you
should
publish
it
in
a
machine,
readable
format.
A
So
so
this
kind
of
boils
like
feeds
back
into
the
discussion.
We
just
had
about
maintainers
that
they
seem
to
be
in
the
group
of
they
want
to
do
something
not
necessarily
know
how
to
do
it
well,
and
this
would
be
how
to
publish
vulnerability
information
so
that
it's
not
just
readable
to
humans,
but
also
available
for,
like
software
consum
consumption,
would
make
a
dent
as
well
in
that
like
if
we
could
promote
if
we
could
promote
that-
and
maybe
that's
actually
a
good
segue
into
the
other
topic.
A
So
how
do
we?
How
would
we
go
about
doing
that
is?
Is
this
something
that
we
would
solve
by
proposing
a
data
format
and
promoting
that
and
putting
like
os
the
open
source
security
foundation
weight
behind
it
or
is?
A
Does
it
make
more
sense
to
make
sure
that
other
industry
formats
or
standards
are
applicable
and
work
well
for
those
kinds
of
scenarios
in
open
source.
E
At
least
a
link
to
it,
but
I
personally
would
love
to
instead
help
aggregate
what
standards
are
out
there
and
then
be
able
to
say
we
recommend
this
one
and
this
one
because
they
seem
to
be
most
complete,
but
there
here's
here's,
the
five
that
are
out
here
and
popular.
We
recommend
this
one
because
it's
most
complete
and
then
maybe
we
could
talk
to
that
group
and
make
recommendations,
but
I
think
we
should
avoid
creating
any
kind
of
new
standards.
E
G
I
agree
so
yeah,
so
we
we
sort
of
had
this
discussion
last
meeting
with,
I
forgot
his
name,
martin,
which
explained
the
os's
advisory
schema,
and
then
we
also
sort
of
went
to
went
through
that
part.
G
So
what
I,
what
I
think
would
help
sort
of
like
also
people
that
provides
data,
schemas
and
consumers
is
to
say
these
are
the
standards,
and
these
are
the
sources
that
is
currently
using
it
as
both
as
examples
and
sort
of
to
underline
that
there
are
people
using
it
and
not
just
be
recommending
something.
G
So
I
do
think
it's
it's
better
to
not
do
anything
yourself,
but
to
try
ensure
that
the
metra
cv
automation
group
is
successful
and
that
we,
and
that
we
also
can
try
and
ensure
that
the
uis's
advisory
schema
is
applicable
to
all
the
users
use
cases
that
we
can
come
up.
A
With
so
so
is
there
because
the
the
way
I'm
kind
of
reading
this
is
that
there
are
two
things
to
be
done:
a
getting
back
to
this
education
bit.
We
educate
open
source
maintainers
if
you're
publishing
a
security
advisory.
A
Here's
how
you
do
that
so
that
it's
consumable
by
others
in
a
standardized
way,
and
then
we
work
with
with
all
the
different
industry
kind
of
standardization
bodies
and
working
groups
to
identify
the
standards
that
could
fit
the
bill
and
make
sure
they
are.
A
Easily
used
in
in
the
open
source
context,
and
even
if
and
I
think
this
is
a
comment
that
was
posted
under
this
github
issue,
even
if
the
format
itself
is
complex
because
the
the
domain
of
vulnerability,
security
and
disclosures
is
complex,
so
the
data
form
at
that
needs
to
fit
a
number
of
different
use
cases
probably
going
to
be
complex
as
well.
A
So
the
question
is,
if
we
just
educate
and
promote
and
make
sure
and
work
with
the
standard
groups
to
address,
use,
open
source
use
cases,
or
do
we
also
kind
of
maybe
work
on
some
tools
to
make
work
with
those
data
formats
easier
if
those
data
formats
are
like
do
not
come
with
any
sort
of
tooling
themselves,
which
I
I'm
assuming
might
be
might
be
the
case.
So
we
only
have
a
data
form,
but
we
don't
have
an
easy
way
of
generating
them,
not
not
an
easy
way
of
consuming
them.
G
So
well,
while
they
were
talking,
I
just
realized
that
we're
sort
of
now
conflating
two
kinds
of
maintainers,
both
people
that
maintain
open
source
software
and
then
maintainers
as
in
people
that
provide
advisories.
G
So
I
think
we
should
maybe
add
a
fourth
stakeholder
which
which
is
sort
of
like
maintainer
consumer
security,
researchers,
but
also
providers,
because
that's
sort
of
a
separate
role
where
you
don't
necessarily
maintain
software.
But
you
provide
security,
vulnerability,
reports
to
people
and
that's
sort
of
what
cargo
you
can
fill
at
all:
npm
arch,
linux,
red
hat,
opensuse
they're,
not
only
maintainers,
but
also
providing
advisories
that
maybe
helps
the
discussion
a
little
bit
pointing
out
that
we
need
to
educate
providers
to
not
only
maintainers.
A
No,
I
I
think
that
makes
a
lot
of
sense
in
that,
sometimes
in
perhaps
for
smaller
projects
like
people
who,
like
issue
the
say,
vulnerability,
reports
and
security.
Advisories
are
the
same
people
that
the
same
people
or
organizations
that
actually
maintain
the
software,
but
it
doesn't
necessarily
have
to
be
that
case.
Actually,
actually
it's
it's
not
even
the
case
for
the
node.js
and
the
npm
community.
So
there
are
a
number
of
different
number
of
different
kind
of
parties
involved
in
that
ecosystem
and
npm
is
just
one
of
them.
A
Some
of
the
movements
were
some
of
them
commercial,
so
yeah,
that's
definitely
that's
a
that's.
A
very
good
call-out.
H
Yeah
I
mean
I,
I
especially
agree
with
that
one
just
because
of
like
if
the
tooling
itself
supported
it,
you
know
npm
bundler
things
like
that.
If
it's
supported
understanding
that
there's
vulnerabilities
in
the
things
that
are
being
installed,
it
can
at
least
warn
the
you
know
the
developer
when
they're
installing
things
like
hey.
This
has
a
vulnerability
you
should
check
in
on
this.
So
I
think,
that's
very
important
part
of
kind
of
the
vulnerability
disclosure
ecosystem
to
make
sure
that
there's
very
good
integrations
with
those
tools.
L
To
the
consumers,
I
would
also
add
one
more
stakeholder,
so
people
that
vendor
libraries
or
code
from
other
web
streams,
so
a
bunch
of
go
projects
nowadays,
they've
been
there
a
lot
of
stuff.
Sometimes
they
are
not
even
using
and
it's
really
hard
to
track
down,
especially
for
us,
downstream
and
yeah.
We
need
to
have
a
way
to
notify
those
other
upstream
maintainers
that
they
are
consuming,
something
that's
broken
or
have
a
security
issue.
You
know.
A
Yes,
so
that
gets
us
back
to
the
whole
software,
build
materials
of
kind
of
discussion
and-
and
that's
actually,
I
think,
a
good
question
to
ask
if
software
build
materials
is
something
that
should
be
in
somehow
in
scope
of
this
group,
because
I
think
it's
a
it's
a
prerequisite
for
vulnerability
management.
But
I'm
I'm
wondering
and
there's
definitely
an
overlap
between
disclosures
and
managing
your
build
materials.
E
So
just
piping
into
someone
who
has
to
occasionally
deal
with
s-bomb
because
for
git
lab
we
write
a
dependency
scanning
tool.
That
is
its
own
very,
very
large
topic.
So
as
much
as
I
feel
like
that
does
need
a
group
to
address
it.
I'm
not
sure
that
we
could
bite
that
off
as
part
of
this
group
without
being
completely
subsumed
by
having
to
deal
with
all
the
intricacies
there.
I
Yeah
you're,
absolutely
right,
nicole.
In
fact
what
the
digital
bill
of
materials
group,
though,
is
set
up
to
deal
with
this,
so
that's
run
out
of
the
linux
foundation.
I
don't
think
it's
part
of
ossf,
but
it's
it's
called
dbom
digital
bill
of
materials.
A
Yeah,
but
we
could
we
could.
We
could
definitely
make
sure
that
whatever
we
propose
in
and
whatever
we
work
on
in
the
vulnerability
disclosure
space
is
sort
of
in
sync,
with
with
other
s-bomber
d-bomb
can
efforts
in
the
industry,
so
we
don't
create
something.
That's
unconsumable.
F
Yeah
there's
a
very
significant
s-bomb
work
in
the
industry,
already
that's
being
led
by
the
end
by
ntia
and
there's
there's
two
or
three
different
formats
that
are
being
shuffled.
It's
a
very
it,
as
others
have
said
it.
It
is
a
very
it's
a
huge
beast
in
and
of
its
own
right,
but
there's
a
substantial
working
group.
That's
already
working
on
that.
A
Yeah,
I
think
I
think
in
in
one
of
the
previous
meetings
we've
had
some
discussions
about
about
this
already,
but
this
is
definitely
one
of
the
things
where
I
think
we
should
make
sure
that
we're
following,
rather
than
we
lead
right,
just
just
to
stay
in
line
with
where
the
industry
is
moving.
A
So
we
have
about
five
minutes
to
go.
What
do
you
think
are
like
one
or
two
topics
that
we
should
like
focus
on
in
going
forward
after
after
this.
A
Meeting
so
should
we
have,
should
we
think
about
some
deliverables,
maybe
around
having
like
a
list
of
again,
but
this
time
like
not
in
a
meeting
but
documented
of
all
the
different
standards,
and
how
do
we
see
them
fit
the
open
source
security
kind
of
disclosure
ecosystem
to
even
advise
like
okay,
if
you
want
to
do
it
today,
even
if
we
were
not
to
change
the
state
of
the
industry
today
and
not
do
something
and
just
make
a
recommendation,
what
would
we
recommend?
D
D
E
So
eva
had
posted,
and
I
think
it
was
a
good
idea
to
also
polish
up
our
list
of
who
we
think
the
stakeholders
are,
and
you
know,
kind
of
crisp
up
those
pain
points.
So
I
think,
potentially
starting
a
place
where
we
believe
the
stakeholders
list
is
going
to
end
up
and
working
on
that
and
then
starting
a
list
of
and
I'm
gonna.
I
don't
know
what
the
correct
terminology
is.
E
But
what
if
we
started
like
a
list
of
here's
all
the
standards
and
working
groups,
we
know
of
for
these
different
areas
and
like
basically
just
have
it
blank
and
we
all
start
filling
in
what
we
know.
And
then
maybe
we
push
it
out
to
our
networks
and
have
other
people
toss
in
additional
ones
and
so
don't
even
get
into.
Where
does
this
fit
just
literally
get
into?
I
Even
defining
what
the
problem
is
we're
trying
to
solve
here,
you
know
crisping
that
up
so
that
we,
you
know
that
all
that
threads
together
and
then
figure
out.
How
do
we
solve
that
by
you
know
what
documentation
we
might
create
or
framework
or
whatnot
yeah?
Maybe
it's
something
a
lot
simpler
than
all
that.
A
Yeah,
I
I
think
that
that
would
be
brilliant
to
have
that
sort
of
that's
a
sort
of
an
overview,
so
it
could
start
as
a
as
a
markdown
document
here
in
this
in
this
working
groups
repository
that
we
could
make
in
pr
and
then
we
could
continue
that
discussion.
A
You
know
in
a
pr,
so
I
can
take
an
action
item
to
like
collate
the
collate,
the
standards
and
organizations
that
have
been
mentioned
already
and
then
we
could.
We
could
take
it
from
there
and
then
see
if
there's
anything
that
is
missing
and
if
we,
you
know,
have
touch
points
and
do
we
know
people
that
are
participating
in
in
those
organizations
and
try
to
recap
that
work
in
the
next
working
group
meeting.
A
Okay,
we
have,
we
have
one
minute
to
go.
That
was
that
was
an
amazing
discussion
and
I
I
enjoyed
it
a
lot
and
I
think
we
we
have
a
plan
going
forward.
Is
there
anything
else
that
we
that
I
missed,
or
you
should
be
talking
about?
A
Thank
you
for
wrangling
all
this.
Oh,
I
haven't
I'm
just
I'm
just
talking
ahead.
So
thank
you
all
for
participating
and
I
don't
know
who's
taking
all
those
amazing
notes.
But
you
have
my
maternal
gratitude.
A
Okay,
we're
at
the
help
of
the
hour
I'll
upload
the
recording
to
youtube
I
and
I'll.
Let
you
know
when
it's
up
and
I'll
post
the
note
I'll
transform
those
notes
into
a
markdown
document
and
repository
as
well.
Thank
you
all.
Take
care.