►
B
A
A
B
A
A
C
C
C
B
A
C
A
Let's
first
off
do
some
introductions
and
then
we
will
dive
into
the
autofix,
so
I'm
Pro
I
am
the
facilitator
for
the
vulnerability
disclosure
working
group
and
other
nonsense
here
at
the
open,
ssf
Ben.
The
working
group
liaison
for
nearly
three
years
and
I'm
excited
to
have
the
opportunity
to
work
with
our
friends
overseas
and
get
some
better
inclusion
and
points
of
view
and
honestly
to
finally
get
a
chance
to
talk,
have
a
dialogue
with
the
osv
folks
I'm
like
super
excited.
So
you
want
to
introduce
yourselves.
D
C
C
B
C
C
C
C
To
this
working
group,
a
for
review,
I'll
put
this
I'll,
bring
it
up
here
in
the
meeting
notes:
a
full
review
proposal,
which
is
a
vulnerability
disclosure
policy
for
the
alpha
for
human
source,
security
Foundation
and
it's
basically
a
copy
and
paste
of
Google's
policy
plus
a
like
heavily
modified.
So
it's
like
it's
the
it's,
the
open
source,
security
foundations,
heavy
modification
of
Google's
product
zero
policy
at
a
high
level.
C
A
C
B
C
C
C
So
here's
how
to
not
get
banned
by
GitHub,
you
know
sort
of
sort
of
things
and
and
how
to
and
also
like
how
to
not
piss
off
maintainers.
So
that
meeting
is
within
your
time,
availability.
Potentially,
it
will
be
starting
next
week
on
at
4,
P.M
Eastern
on
Wednesdays
I.
Don't
know
if
that's
still
through
that
I
don't
know
if
that's
still
too
early
for.
D
A
C
Yeah,
it's
there
and
I
know
that
Google
has
engaged
in
some
I
know
somebody
from
Google
engaged
in
the
big
project
to
go
fix
like
Apache
struts,
across
open
source
and
and
so
this,
this
sort
of
work
is
not
something
that
Google
is
unfamiliar
with.
So
if
there's
someone
at
Google
that
is
interested
in
engaging
in
this
project
feel
free
to
send
it
over
them,
send
this
sake
over
their
way
and
there's
a
there's,
an
issue
for
it.
C
B
And
I'm
interested
in
just
learning
a
bit
more
about
it
and
obviously,
over
the
passage
of
time,
because
you
know
we
we're
thinking
about
what
sort
of
you
know
what
sort
of
end-to-end
vulnerability
management
stories
we
can.
We
can
sort
of
have
there
so,
and
this
sounds
like
it
dog
tails
into
that
quite
nicely.
So
I'm
interested
in
following
along.
A
And
our
modus
operandi
here
in
the
working
group
is
our
meeting
notes
are
all
in
a
Google
doc
and
those
are
typically
posted
they're
pinned
at
the
top
of
each
slack
channel.
So
if
you
navigate
to
a
different
working
group,
that's
typically
where
you
can
look
to
see
the
agenda
and
the
agenda
should
have
meeting
times.
Zoom
links
links
to
the
repo
mailing
list.
A
So
any
of
the
kind
of
the
details
around
that
group
are
typically
at
the
top
of
the
agenda,
which
is
posted
at
the
pinned
at
the
top
of
slack,
and
most
folks
will
use
a
gdoc
when
there's
a
heavy,
a
thing
that
needs
heavy
collaboration.
So
I
need
to
have
like
eight
people,
rewording
like
Jonathan's
policy,
for
example,
and
then
eventually,
once
it's
stable,
we
move
everything
into
a
markdown
file
in
a
GitHub
repo
and
then
everything's
managed
with
issues
and
PR's.
From
that
point
forward.
We're
once
we're
past
the
heavy
editing,
yeah.
A
A
Not
at
all
I
will
dump
a
link
to
our
repo,
which
is
at
the
top
of
the
agenda,
but
right
there
is
our
GitHub
repository.
So
the
the
goals
of
this
working
group
are
to
promote
coordinated
vulnerability,
disclosure
practices
within
the
open
source
ecosystem.
We
predominantly
have
done
that
through
participation
in
kind
of
Standards
bodies.
Commenting
we've
had
some
vigorous
dialogue
in
the
past
with
the
cve
board,
which
well
I'm
sure
sure
will
pick
back
up
eventually,
but
our
main
work
outputs
have
been
two
coordinated
vulnerability.
A
Our
second
guide
was
focused
on
security
researchers
on
how
they
can
better
interact
with
upstream
and
open
source
communities.
So
those
were
things
that
those
are
both
published
in
the
repo
we
have
osv.
You
know
Oliver
popped
in
many
times
back
in
the
past,
and
unfortunately,
things
have
drifted.
So
I'm
excited
to
have
an
opportunity
to
kind
of
re-engage
with
you
guys.
A
Our
current
projects
are
the
the
two
ideas
that
Jonathan
mentioned,
and
he
also
has
a
couple
other
issues
that
we
want
to
kind
of
deal
with
as
part
of
the
working
group,
but
we're
right
now,
working
on
a
CBD
guide
focused
on
open
source
consumers,
so
how
they
can
understand
how
Upstream
works
and
how
it
issues
get
fixed
and
how
they're
shared
back
and
forth
amongst
the
community
and
downstream.
So,
hopefully,
that's
just
kicking
off
and
that's
going
to
be
a
collaboration
with
the
end
user
working
group
who's.
A
You
know
they're
focused
on
consumers,
so
we're
going
to
be
collaborating
with
them
and
right
now
we're
in
kind
of
the
requirements
Gathering
phase
where
we
have
a
stub
of
a
document
and
we're
just
kind
of
filling
out
a
table
of
contents
and
then
from
there
we'll
kind
of
divide
up
the
labor-
and
you
know
Jonathan
might
go
write
something
about
you
know
where
Upstream
reports
vulnerabilities,
so
he
might
have
something
about
the
national
vulnerability
database
or
GS
gsv.
What's
bresser's
project.
A
So
is
that
something
maybe
Jonathan
might
write
that
and
I?
You
know
I
and
Jonathan
the
other
Jonathan
from
the
end
user
working
group.
They
will
kind
of
write
the
introduction
kind
of
coaching
consumers
on
things
to
look
for
how
to
you
know
you
should
use
scorecards
or
All-Star
for
evaluating
your
dependencies,
and
ideally
these
projects
have
the
ability
to
write
advisor
easy,
so
basically
we're
in
the
requirements,
Gathering
and
eventually
we'll
start
divving
up
the
work
to
get
the
document
written.
D
A
This
is
part
of
the
mobilization
plan
that
was
released
a
year
and
a
half
ago
by
the
foundation
where
they
said.
If
you
invest
in
these
10
areas
of
open
source
security,
you'll
be
able
to
kind
of
uplift
the
posture
of
the
whole
ecosystem
and
one
of
those
ideas
was
Staffing,
a
group
of
ir
professionals
that
would
help
facilitate
whatever
maintainers
or
security
researchers
needed.
A
So
if
a
researcher
needed
help
contacting
a
project,
that
group
would
help
facilitate
that,
if
a
main
a
project
needed
help
negotiating
timelines
or
working
with
a
researcher,
the
cert
potentially
could
help
out
with
that
or
if
they
need
help
writing
an
advisory
or
accessing
tools.
We
would
help
kind
of
make
those
connections
and
help
get
these
projects
set
out,
so
they
can
have
their
own
kind
of
vulnerability,
handling
process
themselves.
A
A
To
consider
for
funding,
so
I
was
in
a
call
earlier
today
with
the
governing
board,
trying
to
figure
out
how
the
hell,
all
that
works,
but
eventually
we'll
be
presenting
the
plan
to
the
governing
board
and
they'll,
be
potentially
funding
a
team
of
experts
that
will
be
doing
incident
response
for
upstream
and
then
we
might
go.
Ask
organizations
like
Google
or
Intel.
Could
you
help?
You
know
volunteer
somebody
from
your
p-cert
for
so
many
hours
a
month
or
for
the
year
whatever,
however,
it
works
out,
we're
still
kind
of
ironing
out
all
those
details.
A
And-
and
the
nice
thing
about
openssf
is
all
of
our
meetings
are
recorded
So.
If
you
miss
one
or
you
want
to
monitor
something
that
is
out
of
your
time
zone.
You
can
watch
all
the
videos
on
YouTube
and
again,
everyone
publishes
their
meeting
notes
so
that
you
can
be
able
to
kind
of
read
back
through,
and
everyone
should
have
slack
in
a
mailing
list
that
you
can
engage
with
the
community
there
kind
of
asynchronously
as
well.
B
A
C
A
A
D
So
yeah,
so
so,
as
you
know,
we've
been
working
on
the
osv
schema,
collaborating
with
GitHub,
firstly
on
this
and
select
parts
of
the
community
in
getting
the
OSP
schema
to
his
current
state,
and
it's
gotten
a
fair
bit
of
adoption
from
various
different
open
source
ecosystems.
So
GitHub
is
using
it.
We've
got
go,
we've
got
python
rust.
D
The
Global
Security
database
is
also
using
it
as
one
of
its
formats
and
I
think
there
is
a
lot
of
overlap
with
this
working
group,
so
so
we're
not
so
far
as
like
osv
so
far
doesn't
really
cover
the
disclosure.
The
early
disclosure
piece
of
the
kind
of
vulnerability
life
cycle,
like
it's
more
focused
around
organizing
vulnerability
data
in
a
consistent
and
usable
way
and
then
helping
the
downstream
users
make
use
of
that
in
in
a
in
an
automated
way.
D
Yeah.
So
there's
been
a
number
of
updates.
We've
also
worked
with
the
cve
board,
so
the
latest
cve
5.0
standard
actually
includes
this
new
version,
versioning
schema,
which
was
we
directly
proposed
to
them
and
they
accepted,
and
the
idea
is
that
it's
very
much
aligned
with
how
osv
does
it
so
that
there's
a
lot
of
great
overlap
in
terms
of
interrupt
when
it
comes
to
that,
and
hopefully
that's
the
dialogue,
we'll
continue
with
them.
I
know
you
mentioned:
you've
had
some
conversations
with
the
CV
board
in
the
past.
D
We're
also
trying
to
contact
them,
we're
finding
that
sometimes
they're
not
as
responsive
as
they'd
like
so
I,
do
want
to
know.
Yeah
I
think
there's
a
few
areas
of
collaboration
around
potential
helping
you
know,
promote
osv
as
a
schemer
for
open
source
and
also
potentially
re-engaging
with
the
cve
board
to
help
the
improvements
that
we're
driving
across
open
source
more
generally
push
that
back
into
cve
to
begin
with,
yeah
Andrew.
Anything
you
want
to
add
to
that.
B
You're
on
mute,
yeah
I
just
remember:
we
were
drawing
the
line
between
OSP
scheme
and
stuff
and
infrastop
I
guess
without
getting
too
bogged
down
infrastructure
stuff.
My
work
is
predominantly
on
trying
to
generate
osv
records
for
Relevant,
open
source,
related
cdes
and
so
I'm
I'm
sort
of
now
getting
into
the
into
the
rabbit
hole
of
CBE
data
quality.
A
A
D
A
B
Cbe
quality
working
group
now
and
and
also
with
the
you
know,
we're
using
the
NBD
as
our
as
our
source
of
Truth,
so
I'm
engaging
with
both
the
nvd
folks
and
trying
to
engage
with
the
quality
working
group
and
and
potentially
the
automation,
working
group
of
CV
as
well.
Nice,
and
just
overnight,
made
some
progress
on.
You
know:
gaining
access
to
those
working
groups,
okay,.
A
So
one
area
I
think
we
can
immediately
assist
with
is
a
member
of
the
CVB
board
is
one
of
my
peers
at
work.
Another
member
is
an
active
participant
in
many
of
the
working
groups,
so
art
Manion,
Katie
Noble,
is
my
co-worker.
Chandan
is
an
industry
friend,
so
we
have
a
lot
of
connections.
So
if
we
needed
to
broker
conversations
I'm
glad
to
help
facilitate
some
of
that
and
try
to
help
kind
of
remove
some
blockers
for
you
guys
and
connectivity.
B
As
to
how
these
operate,
but
I'm
hopeful
that
you
know
if
we
just
start
showing
up
in
some
of
these
pre-existing
forums
that,
rather
than
needing
to
have
a
whole
web
of,
you
know
private
dialogue
going
on
sort
of
separate
from
them.
We
can
just
do
things
in
in
those
working
group
sessions,
but
it's
good
to
know.
There's
some
back
channels
that
we
can
also
leverage.
D
A
A
D
Yeah
I
was
also
kind
of
curious
if
there
are
any
other
members
of
this
working
group
who
might
be
interested
in
collaborating
with
us
on
this
front.
This
idea
of
just
improving
data
quality
at
the
source
at
cbe's
level,
because
that's
something
that
we
are
really
trying
to
to
address
and
I'm
sure.
This
is
something
that
a
lot
of
people
have
run
into
in
the
past.
A
And
that,
and
so
like
talking
about
like
the
OSS
cert,
we're
looking
at
potentially
creating
or
highlighting
tools
so
that
maintainers
and
projects
can
have
a
more
frictionless
advisory
experience
so
that
it's
it's
very
simple
for
them
very
automated
as
much
as
possible,
and
then
we
want
to
plug
in
additional
things
like
potentially
we're
in
talks
right
now
with
open
Vex.
So
the
group
might
adopt
that
as
a
project
software
project
and
then
we
become
evangelists.
And
how
great
would
that
be?
Is
you
know?
As
a
developer
is
fixing
a
bug?
A
D
Yeah
I
mean
there's,
there's
a
lot
of
overlap
with
osv
on
that
front
as
well
like
we're
about
helping
make
sure
we
want
the
data
format
to
be
useful
for
Downstream
consumers
and
enable
tooling,
like
we're,
definitely
also
looking
at
openvx
and,
potentially,
you
know,
automatically
generating
Auto
Vex
based
on
say,
static
analysis
and
things
like
that
using
osv
as
well,
so
I
think
yeah.
There's
a
lot
of
places
that
I
think
we
should
definitely
be
talking
more
on
yeah.
B
B
Some
of
the
reference
description
strings
apparently
come
directly
from
CBE,
yeah
and
they're,
completely
inconsistent,
right
and,
and
so
I
I
got
directed
to
the
Quality
working
group.
Regarding
that,
because
I
I
sort
of
started
to
try
and
have
a
similar
dialogue
to
what
I
was
having
with
the
MBD
with
with
CD,
directly
and
and
that
kind
of
was
a
bit
more
random,
I
guess
and
so
and
then
then
I
learned
about
the
quality
working
group
and
was
sort
of
when
I
when
I
keep
something
that
had
died
over
the
holiday
period.
B
A
Think
that's
potentially
a
lot
of
value
that
if
we
get
the
right
folks,
together
and
again
figure
out
a
way
to
do
this
through
automation,
we
potentially
could
provide
a
solution,
so
the
maintainer
can
have
some
type
of
unique
identifier
that
is
able
to
be
consistently
used
as
it
moves
its
way.
Downstream.
A
I
was
reading,
some
are
Dan
Lawrence
from
chain
guard
did
an
article
today
and
it
was
really
insightful
where
he
was
trying
to
dig
into
some
npm,
widespread,
cve
and
basically
kind
of
boiled
down
to.
Like
the
part
of
the
thing
reason.
Part
of
the
problem
was
the
CPE
out
of
like
all
of
the
the
required
data
fields.
Almost
all
of
them
were
wild
cards.
It
was
all
star
and
he's
like
well.
This
is
completely
completely
effing
useless.
B
Procedurally
I
just
assumed
that
when
you're
slapping
a
CPE
string
on
a
CB
record
that
it
winds
up
in
the
dictionary-
and
that
doesn't
seem
to
be
the
case
right
so
that
was
the
first
problem.
I
was
playing.
The
second
problem
was,
just
you
know,
ambiguous
or
or
duplicate
the
different
CPU
strings
for
the
same
thing
and
again
that
that
that
that
said
to
me
on
first
principles
that
it
was
a
a
referential
Integrity
issue
between
the
the
CVS
and
the
dictionaries,
yeah
I.
B
You
know
that
the
next
one
is
to
just
I
just
want
to
learn
a
little
bit
better
about
what
what
their
process
currently
looks
like
because
you
know
from
where
I'm
sitting
it
looks
like
they
that
this
it's
just
a
case
of
doing
a
referential,
Integrity
check
and
I'm
sure,
there's
good
reasons.
Why?
That's
not
the
case
and
I'd
just
like
to
learn
a
bit
more
about
it.
Yeah.
A
C
A
B
Yeah,
the
other,
the
other
thing
I'm
interested
to
understand
is
how
the
CV
5.0
format
will
flow
down
into
the
nvd,
because
in
some
ways
that
addresses
this
whole
CPE
problem,
because
we
can
use
package,
identifiers
and
whatnot,
but
that's
obviously
a
big
change
to
the
way
the
MVD
operates
and
that
only
helps
with
with
open
source
related
cbes.
Not
you
know
that
they
have
a
bigger,
a
bigger
Universe
to
deal
with
than
just
open
source,
so
they
do.
A
B
A
A
A
On
EX,
like
with
our
open
Vex
calls,
we've
had
20
folks
on
those,
but
we'll
generally
kind
of
average
around
a
dozen
15
or
so
people
on
a
call
this
one,
where
we're
just
kind
of
kicking
off
trying
to
get
into
this
time
zone
I
need
to
kind
of
get
the
word
out.
I
thought
my,
but
my
former
colleagues
at
Red
Hat
product
security
were
going
to
show
up
Garth
and
Wade
and
everybody,
but
they
ditched
me
so
I'm
gonna
have
to
send
them
a
nasty
gram.
A
They
abandoned
me
but
I'm
trying
to
get
more
people,
and
we
had
the
gentleman
from
Japan
last
time
and
he
was
really
excited
so
again.
I
think
it's
just
we're
starting
to
build
this
segment
of
the
community
and
figuring
out
ways.
We
can
share
information
more
easily
and
be
better
collaborative,
very
cool.
Okay,
all
right!
Well,
if
neither
of
you
have
anything
else,
I'll,
let
you
guys
go
I,
appreciate
your
time
and
I'm
looking
forward
to
our
continued
work.