►
From YouTube: Vulnerability Disclosures WG (March 7, 2022)
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).
B
I
have
posted
a
link
to
our
agenda
in
the
chat.
Please
mark
your
attendance
and,
if
you
have
any
opens
you'd
like
to
add
we'll
get
started
in
just
a
few
minutes.
Thank
you.
Everybody.
B
Get
started
in
just
one
more
minute:
I've
posted
a
link
to
our
agenda
in
the
chat.
Please
mark
your
attendance
and,
if
you
have
any
opens
you'd
like
to
share
with
the
group
just
one
minute.
B
All
right,
a
little
clock
on
the
wall
says
a
couple
minutes
after
the
hour
we
will
get
rolling.
I
will
post
the
agenda
one
last
time.
Anyone
has
any
additional
opens,
they
want
to
add.
Please
do
so
there
first
order
of
business,
as
is
tradition
here.
Do
we
have
any
new
friends
that
wanted
to
introduce
themselves
to
the
group.
C
I'll
reintroduce
myself,
since
I've
been
away
for
like
it,
feels
like
forever
come
back.
You've
been
here
for
years,
I'm
jory
berson,
I'm
a
program
director
for
the
linux
foundation
and
I
support
openssf.
I've
been
out
on
maternity
leave
since
this
end
of
december,
and
today
is
my
first
day
back.
So
I'm
excited
to
re-meet
everyone.
I
know
many
of
you,
but
please
feel
free
to
ping
me
in
slack.
If
there's
anything
that
you
need
or
any
suggestions
you
have
from
a
community
standpoint
for
open
ssf
but
hello,
everyone.
D
Hey,
I
think,
I'm
also
new
here,
so
I'm
oliver,
I
I'm
from
google
and
I
work
on
the
open
source,
vulnerabilities
or
osv
project,
so
this
might
be
the
second
time
I've
joined
this
working
group
meeting,
I'm
from
sydney,
australia.
So
unfortunately,
some
of
the
time
zones
are
a
bit
difficult
for
me
to
to
deal
with,
but
I'm
hoping
to
give
have
some
some
discussion
around
osv
today
as
well,
and
give
some
additional
background.
B
Excellent
welcome
back
oliver
yeah
sydney
is
an
interesting
place
in
the
global
time
zone.
Spectrum
glad
you
could
get
up
a
little
early
for
us
a
lot
early.
Any
other
new
friends
wanted
to
say
hello.
E
F
I
promise
to
maybe
be
the
last
one
hi
everyone,
my
name
is
madison
oliver.
I
work
on
the
advisory
database
team
at
github.
Kate
has
been
in
these
calls
before
and
I
know
xavier
has
as
well
and
I
previously
worked
with
the
circ
coordination
center.
Some
of
you
might
also
have
met
me
there.
B
All
right
before
we
jump
into
the
opens,
I
propose
to
the
group-
actually,
I
had
this
suggested
very
strongly
from
another
working
group,
but
we've
talked
about
it
a
little
bit
in
here
before
so
I
propose
to
the
group
that
our
next
project
we
collaborate
on
together
would
be
a
coordinated
vulnerability
disclosure
guide
for
open
source
projects,
but
this
time
instead
of
focusing
on
the
maintainers
like
we
did
the
original
guide.
This
time
we
focus
on
security
researchers.
B
We
have
a
couple
related
documents
to
this,
so
if
we
think
this
is
worthwhile
work,
this
could
be
what
our
next
little
effort
together
would
be
any
initial
thoughts
before
we
move
over
to
the
open
section.
B
I
do
want
to
give
oliver
some
time
today,
so
we'll
kind
of
defer
this.
If
the
group
thinks
this
is
interesting
but
to
work
on,
we
will
talk
about
that
after
our
two
opens.
A
I
would
like
to
hear
more
about
just
your
thoughts
and
especially
who
is
strongly
suggesting
it
and
how
we
will
be
able
to
help
them
and
they'll
be
able
to
help
us
in
creating
this
right.
B
All
right
so
we'll
circle
back
to
that.
Hopefully,
we'll
have
some
time.
I
yield
the
floor
to
vicky
talk
about
spdx.
A
Oh
hi
team:
this
is
going
to
be
a
super
quick
update.
A
few
calls
ago.
I
was
here
and
we
were
talking
about
you
know
people
had
questions
about
how
these
vulnerabilities
get
added
to
s-bombs.
I
happen
to
also
collaborate
over
on
the
spdx
side
and
they
are
starting
a
brand
new
vulnerabilities
group.
There
are
several
weeks
in
now,
but
it's
only
a
few
weeks.
It
started
right
about
the
same
time.
We
had
this
question.
A
A
I
am
working
with
the
head
of
the
spx
defects
working
group
to
have
him
show
up
and
give
us
a
lowdown
on
all
the
thoughts
that
there
are
to
think
but
he's
in
the
eu
and
has
children.
So
coordination
is
a
bit
sketchy
but
we're
working
on
it,
and
so
at
some
point,
thomas
will
show
up
and
give
us
the
brain
dump.
B
Thank
you
for
sharing,
appreciate
it.
We
look
forward
to
hearing
more
s-bomb,
if
only
I,
oh,
I
do
have
something
to
drink
and
drink
with
something
near
and
dear
to
many
of
our
hearts.
All
right.
Next
up,
oliver
has
joined
us
from
the
far
off
exotic
land
of
australia
to
talk
a
little
bit
about
osv
and
potential
collaboration
opportunities
between
that
group
and
this
group.
So
oliver
I
yield
the
floor
to
you,
sir.
D
Yeah,
thank
you
excited
to
meet
everyone
here.
I
just
have
literally
two
slides,
so
everybody
won't
be
too
boring
yeah,
so
I'm
not
very
familiar
with
zoom.
Does
everyone
see
my
my
screen
here?
Cool
cool?
Yes,
we
see
it
yeah,
awesome
yeah.
So
just
a
bit
of
background
on
what
osv
is
so
osv
is
a
bit
of
an
overloaded
term
these
days.
So
it
refers
to
both
this
schema
that
we've
worked
on
and
also
a
bunch
of
infrastructure.
D
We've
worked
with
github
here
as
well
on
adopting
a
set
of
changes
that
are
necessary
to
them
and,
as
a
result,
this
is
something
that
has
been
adopted
by
the
github
advisory
database.
It's
been
adopted
by
the
pipa,
the
python
packaging
advisory,
python
packaging,
the
pi
pi
package
repository
it's
been
adopted
by
russec.
It's
been
left
by
go
and
then
there's
another
project
called
gsd,
which
I'm
not
sure.
D
If
the
folks
here
are
familiar
with,
but
that's
another
effort
to
try
to
index
all
of
the
vulnerabilities
that
there
are
in
open
source
and
they've,
also
adopted
osv,
so
so
yeah
you
can
look
at
the
details
of
a
schemer.
I
have
a
link
here
to
the
github
repo.
D
So
the
idea
behind
the
schema
is
really
to
provide
something
that
is
both
easy
for
humans
and
machines
to
understand-
and
this
is
kind
of
came
out
of
our
frustrations
with
using
things
like
cve
in
the
past,
which
we
found
have
been
very
difficult
to
use
in
vulnerability
scanners,
because
given
a
cve,
it's
really
difficult
to
even
tell
what
package
it's
talking
about,
what
versions
it's
talking
about,
and
it
requires
a
lot
of
human
triage
and
natural
language
parsing
to
understand
what
the
heck
this
entry
is
talking
about.
D
So
we
have
this
format,
which
is
unemployment,
precise,
with
specifying
which
package
is
affected
and
the
exact
set
of
versions.
That
makes
it
easy
for
us
to
share
this
in
a
very
precise
manner,
for
vulnerability
scanners
to
consume,
that
without
any
ambiguity
as
well
and
also
making
a
coming
back
to
the
human
aspect,
I
want
to
make
sure
this
is
something
that
humans
can
read
easily.
So
it's
not
a
huge
xml
file.
You
have
to
pause
with
your
eyeballs,
it's
just
a
very
simple
json
format.
D
You
can
edit
it
as
a
human
as
well.
You
can
read
it
as
human
and
understand
straight
away
what
this
vulnerability
is
talking
about,
and
we've
also
been
working
with
other
standards
like
cve,
so
cv
5.0
is
an
up
and
coming
version
of
cve
and
we've
spoken
to
them
and
made
sure
to
for
them
to
adopt
some
of
the
the
versioning
specification
changes
such
that
osv.
The
way
we
specify
versions
is
compatible
with
cve
5.0.
It's
5.0
way
of
doing
this
yeah.
D
So
that's
a
schema
and
kind
of
complementary
to
that.
We
have
infrastructure.
Currently,
this
is
hosted
in
a
google
repo,
but
this
is
something
that
we
want
to
look
at
contributing
to
more
to
the
openssf
as
well.
So
it's
just
an
api
service
and
also
a
web
ui,
where
you
can
browse
through
all
of
our
vulnerabilities.
D
So
the
idea
is
that
this
is
just
an
aggregator
and
also
indexer,
so
we
index
will
take
every
vulnerability
we
find
that
are
encoded
in
osv
formats
and
we
index
them
by
the
commit
hash
or
package
urls
or
just
a
package
name
and
a
version
number.
So
we
have
some
example
queries
here,
so
you
can
query
by
a
package
url
with
a
version,
and
that
will
tell
you
about
all
of
the
vulnerabilities
that
affect
that
particular
package
or
that
version.
D
Similarly,
if
you
want
to
decompose
that
into
an
ecosystem
name
and
a
version,
you
can
do
it
as
well
or
if
the
vulnerability
contains
information
at
a
commit
level,
you
can
also
query
by
a
commit
hash
and
because
commit
hashes.
Are
we
considering
them
to
be
unique?
You
don't
need
a
patch
name
to
go
along
with
that.
I
see
a
question:
could
this
correlate
cv
to
file
hashes
rather
than
commit
hashes?
D
D
D
D
We're
missing
things
like
linux,
distros,
like
people
like
debbie
and
other
linux,
distros
publish
their
own
vulnerability
feed
and
want
to
make
sure
that
we
want
to
try
to
make
sure
that
all
of
these
different
ecosystems
publish
things
in
the
same
format
as
well,
because
I
think
right
now.
It's
all
everybody
has
their
own
kind
of
homegrown
formats
that
they're
publishing
in,
and
there
are
also
very
big
projects
like
kubernetes,
which
also
publishes
or
is
looking
to
publish
their
own
vulnerability.
Feed
and
again.
D
We
want
to
try
to
make
sure
everybody
is
using
the
same
format.
So
we
can
just
have
the
one
set
of
tooling
for
everybody
in
open
source
yeah.
So
we
have
the
api,
but
there
are
still
a
missing
piece
in
terms
of
touring.
D
So
essentially
what
we
want
the
end
state
we
want
is
a
kind
of
a
scanner
where
you
give
it
an
s-bom,
a
language
manifest
or
even
a
container
image,
and
then
you'll
be
able
to
scan
that
match
against
all
the
known
osvs
that
are
published
in
the
open
source,
ecosystems
and
and
then
also
other
tools
such
as
renovatebot
will
help
us
with
auto
updates
so
automatically
detecting
our
vulnerabilities
in
in
your
manifest
and
then
order
updating
them
and
then,
like
a
longer
term
goal
here,
is
figuring
out
what
kind
of
metadata
we
can
have
in
the
schema
to
avoid
false
positives,
so
simply
matching
on
package
name
package
version
could
lead
to
false
positives.
D
How
what
kind
of
metadata
can
we
encode
or
kind
of
push
for
in
these
vulnerability
entries
such
that
we
can
minimize
them
in
the
future,
like
things
like
function,
calls,
or
maybe
some
some
other
kind
of
metadata
that
we
can
use
to
to
achieve
that
yeah?
So
that
was
a
very,
very
quick
overview
of
the
background
and
having
a
future
work
we
have
in
mind.
I
would
love
to
hear
your
thoughts
on
potential
collaboration
here
or
any
general
feedback.
D
Yeah,
I
I
guess
everything
entirely
when
google
has
a
hiring
icon
on
the
an
icon.
B
So
you
mentioned
a
handful
of
languages,
oliver
and
then
here
on
this
slide,
you
men
mentioned
the
linux
distros,
which
is
a
incredibly
well
established,
large
community.
So
where
are
you
in
approaching
that.
D
B
Whether
it's
solar
designer
or
any
of
the
others
that
are
part
of
that
have
you
talked
with
any
of
those
large
suppliers
or
communities.
Yet.
D
Yeah,
so
some
people
involved
with
the
debian
kind
of
security
group
have
actually
reached
out
to
us.
So
there
is
a
link
I
can
send
out
the
slides
later,
but
we
have
a
link
here
where
people
from
debian
have
engaged
us
to
kind
of
express
the
interest.
B
That's
an
interesting
community
you're
going
to
probably
want
to
get
in
touch
with.
They
have
a
lot
of
very
different
opinions.
For
example,
red
hat
has
their
own
data
api.
I
believe
marcus
over
at
suse
also
does
so
it'll
be
interesting
to
kind
of
hurting
those
cats
together.
Vicky
has
a
question:
go
ahead,
vicky.
A
So
still
kind
of
wrap,
trying
to
wrap
my
head
around
this
entire
ecosystem,
around
vulnerability,
disclosure
and
and
all
the
moving
parts
in
there,
and
I'm
wondering
what
are
the
other
potential
options
for
this
functionality?
Are
there
other
projects
that
already
do
this,
and
if
so,
how
does
this?
Do
it
better
or
differently?.
D
So
I'm
not,
I
don't
think
there
is
any
free,
completely
free,
open
source
alternative
to
this
right
now
in
terms
of
infrastructure
and
also
the
format
but
yeah.
If
anyone
else
knows
any
feel
free
to
chime
in
here.
A
A
So
they
can
be
mixed
and
matched
with
other
people's
existing
infrastructure
and
perhaps
better
increase
the
adoption
of
osv
as
a
schema.
But
it
seems
to
me
if
there
are
already
schemas.
Why
do
another
one.
D
Yes,
this
goes
back
on
the
idea
of
so
so.
Yes,
we
have
all
these
different
standards
like
including
csafc's
and
a
cvrf,
but
we
we
couldn't
find
one
that
really
was
suitable
for
both.
D
I
think
I
talked
about
in
the
previous
slide,
so
that
was
kind
of
built
from
scratch
for
open
source
and
it's
easy
for
you
to
use
for
both
humans
and
machines,
so
like
being
easy
to
use
for
humans
in
terms
of
being
able
to
just
pass
an
entry
with
your
eyeballs
and
understand
what
it
is
like
not
having
to
pass
through
a
huge
json
or
a
huge
xml
file,
and
also
still
be
precise
enough
to
describe
vulnerabilities
in
open
source
yeah.
D
So
there
are
definitely
a
lot
of
commercial
service
providers
with
similar
information
and
and
what
we've
seen
is
that
everybody
has
their
own
format
like
so
prior
to
this
rustsec
has
their
own
format
and
also
github
has
had
their
own
format
and
a
bunch
of
other
gst
had
their
own
formats,
and
still,
I
think,
still
like
gitlab
has
their
own
format.
D
So
everybody
has
their
own
format
already
and
clearly
there
was
a
need
for
for
someone
to
define
a
new
format
that
fit
the
needs
of
all
of
these,
and
I
think
that's
where
the
value
of
osv
comes
in.
B
G
Reached
out
to
snick
first,
I
know
certain
companies,
including
snik,
for
example,
have
a
database,
but
their
database
is
private
slash.
You
know
their
data
is
freely
available
by
their
user
interface,
but
their
api
is
unavailable
unless
you
have
a
corporate
like
collaboration
with
them.
Is
there
any
work
with
osv
to
try
to
get
snicks
data
into
the
osv
formats
like
as
like,
with
a
partnership
with
google,
so
that
information
is
available
for
freely
to
the
rest
of
the
rest
of
the
ecosystem?.
D
We
have
tried
to
talk
to
snick
before,
but
I
I
don't
think
they've
we've
made
much
progress
there.
They
basically
ignored
us
when
we
brought
up
the
idea
of
making
their
database
fairly
available
yeah.
So
so
I
I
guess
the
the
motivation
behind
osv
is
that
we
really
see
vulnerability
management
from
databases
as
a
kind
of
a
more
of
a
distributed
effort.
D
Think
I
think
it's
beneficial
like
to
these
commercial
solutions
as
well.
So
what
we're
building
is
a
way
for
open
source
ecosystems
to
more
easily
share
audibility
information,
and
if
this
information
is
freely
available,
that
can
make
help
make
these
commercial
solutions
better
as
well,
because
they
can
use
the
same
tooling
to
to
improve
the
quality
of
their
own
database.
D
That
said,
I
think
it.
It
is
a
little
difficult
for
us
to
engage
with
them,
because
I
think
it's
quite
easy
for
them
to
perceive
osu
as
a
competitor
and
yeah.
We
haven't
made
much
progress
yet
with
talking
to
them.
H
Yeah,
I
think
your
point
is
interesting
that
the
and
it
goes
back
to,
I
think
it
was
vicky's
question
distinguishing
between
the
schema
and
the
infra
might
help
there,
where
a
lot
of
those
companies
could
clearly
benefit
from
a
more
consistent
schema
for
all
their
inputs.
H
We
might
find
very
willing
allies
and,
where
you
know,
google
or
the
open
ssf
might
run
competing
infra.
We
will
probably
not
find
as
much
collaboration.
B
Another
group
you
might
want
to
also
engage
with
be
the
form
of
incident
response
and
security
teams.
Those
are
vendor
pcerts.
So
while
they
are
not
necessarily
representative
of
open
source,
they
have
a
very
vested
interest
in
getting
this
data
out
consistently.
So
you
may
find
some
support
and
assistance
through
that
venue
as
well.
B
What
other
questions
or
comments
do
we
have
for
oliver?
Do
we
think
this
is
an
interesting
effort
that
would
benefit
our
stakeholders,
the
open
source,
maintainers
and
projects,
or
what
other
feedback
do
we
have.
A
I
would
like
sorry
this
is
vicky.
I
would
like
at
some
point
to
see
I
mean
if
we
decide
to
move
forward
and
with
whatever
moving
forward
means.
In
this
case,
I
would
love
to
see
some
more
examples
of
this.
You
know
kind
of
in
the
field
how
it
is
working
and
how
it's
integrating
with
all
these
other
things,
because
we've
got
github
and
podca
and
russet
and
gsd,
and
go
and
more.
What
did
those
actually
look
like
right
and
how?
A
What
sort
of
difference
is
it
making
now
and
what
difference
will
it
make
in
the
future
right
kind
of
the
bigger
picture
all
with
combined
with
the
boots
on
the
ground
view
right,
because
this
is
understandably
and
correctly
very
high
level
at
the
moment?
And
so,
if
we
go
further,
I
would
really
appreciate
a
deeper
dive.
D
Yes,
sir,
I
can
give
a
quick
overview,
but
I
guess,
if
you
look
at
the
schemer
github,
it
has
links
to
all
of
the
examples
that
are
currently
adopting
the
osv
schema
so,
for
example,
github
pipi
russet.
These
are
all
just
essentially
give
repos,
because
this
format
is
machine,
machine,
readable
and
human
readable.
The
idea
is
that
all
of
these
repos
essentially
kind
of
crowdsource
effort
from
that
community.
So,
for
example,
the
pipa
database
can
accept
pull
requests
from
anybody.
D
We'll
have
a
team
of
triages
that
will
triage
these
entries
and
add
them
to
the
database,
and
this
would
just
surface
as
pull
requests.
They
can
edit
stuff,
they
can
add
new
stuff
as
well,
and
I
believe
every
single
github
is
doing
a
similar
thing
and
I
guess
most
of
the
other
sources
right
now
are
very
similar
as
well.
So
a
lot
of
examples
are
linked
from
the
readme
in
the
github
repo
right
now.
D
Yes,
so
colonel,
I
saw
a
message
from
cyrob
so
colonel.
Actually
they
are
they
work
with
the
gsd
group.
So
let
me
just:
can
everybody
see
my
tab?
D
Yeah
cool,
so
yes,
there
is
another
effort
from
a
class
security
alliance
called
the
gsd
database
and
some
of
the
linux
kernel.
Maintainers
directly
have
a
relationship
with
the
gsd
group,
so
they
they
send
vulnerability
information
directly
to
gsd,
and
this
is
at
a
granularity
that
other
things
like
cves,
don't
have
so
they
have
exact,
commit
information
for
these
kernels.
D
Let
me
see
if
I
can
find
an
example.
There's
quite
a
few
things
in
here
yeah
here.
B
D
Yes,
yes,
so
upstream
kernel,
maintainers,
directly
request
gsd
to
populate
these
ids
and
entries.
As
you
can
see,
osv
is
one
of
the
formats
here,
and
this
is
everything
that
you
need
to
describe
in
osv.
So
it's
very
simple
to
pause
and
understand
and
very
precise
in
terms
of
specifying
which
commit
ranges
are
affected
and
which
ones,
and
what
osv
does
the
infrastructure
does?
D
Is
that
it
will
take
this
look
at
the
commit
hashes
or
index
on
the
commit
hashes
so
that
you
can
create
by
commit
and
I'll
also
look
at
the
git
tags
in
the
git
repository
to
correlate
them
to
actual
version
numbers.
So
if
you're
using
kernel,
512
and
512
is
included
in
this
range,
then
our
api
will
return
that
as
well.
B
Excellent
ann
has
a
question.
I
Yes,
I
am
wondering
oliver,
if
you
can,
just
at
a
high
level,
describe
the
relationship
between
osv
and
spdx,
because
I
think
that
was
one
of
the
questions
points
of
confusion.
That
kind
of
kicked
off
this
whole
desire
to
have
you
come
and
chat,
and
then
I
think
we're
gonna
have
someone
from
spdx
come
and
do
the
same.
D
Yeah
yeah
I'll,
be
honest,
like
we
haven't,
really
chatted
very
much
with
people
at
sbdx.
I
think
some
other
folks
working
on
osv,
I
think
russ
cox,
the
other
co-author
on
the
original
spec,
did
speak
with
someone
on
spdx
and
and
try
to
get
some
alignment
in
terms
of
how
we
describe
things.
D
But
I
do
think
there
is
a
lot
of
value
in
kind
of
talking
more
here
to
make
sure
we're
not
again
duplicating
our
work
and
that
or
at
least
that
we
are
aligned
in
terms
of
how
we
describe
vulnerabilities
or
defects.
I
know
we
have.
We
have
probably
trying
to
address
different
use
cases,
but
it'd
be
good
to
to
talk
more.
A
Now,
there's
an
spdx
defects
call
on
wednesday,
I
believe,
or
is
it
tomorrow?
I
had
to
remove
it
from
my
calendar
this
week.
Anyway,
you
can
check
out
spdx
defects
and
that's
the
group
that
will
have
these
conversations
and
I'll
try
and
dig
up
the
information
and
throw
it
in
the
chat
for
you.
So
you
don't
have
to
find
it.
B
So
a
couple
folks
point
out
outside
of
like
collaboration
with
this
working
group.
If
osv
is
interested
in
kind
of
more
formalizing,
their
relationship
with
the
open
source
security
foundation,
that
work
is
generally
done
through
the
tack
and.
B
Jory
ava,
myself
all,
can
assist
kind
of
making
a
connection
there
and
putting
proposal
through
if
you're
interested
in
kind
of
more
formally
engaging
where
actually
ava
is
heading
up
the
effort
to
codify
what
the
incubation
process
for
new
projects
and
stuff
is.
So,
if
that's
what
you
folks
are
looking
for
outside
of
a
individual
collaboration,
that's
another
path
for
you.
You
might
want
to
explore.
D
Yeah
they're
definitely
interested
in
exploring
that
path.
Yeah
like
if
you
could
point
me
towards
kind
of
next
steps
for
for
kind
of
pushing
that
forward.
I'd
be
very
happy
to
to
explore
that.
H
Email
to
you
and
I'll
just
add,
please
don't
expect
anything
immediately.
We
are
you
know
discussing
right
now
how
to
more
thoughtfully
document
and
design
that
process
moving
forward.
B
Do
you
have
team
members,
oliver
that
are
somewhere
in
north
america
time
zones.
D
We
do
yes
and
if
it
makes
sense
to,
we
can
get
them
to
attend
the
current
meeting
time
more
frequently,
that's
something!
Oh.
B
For
example
like
if
you're
going
to
talk
to
the
tac
yeah
that
happens
at
11
a.m,
eastern
on
every
other
tuesday.
So
we
probably
want
somebody
to
come
in
do
a
little
presentation
and
that
would
be
super
ridiculous
time
for
you,
yeah.
D
That'll
be
probably
like
3
a.m.
For
me,
or
something
yeah,
definitely
yeah.
There
are
other
people
on
the
team
who
can
help
represent
osu
excellent.
B
All
right,
well,
if
you
think
of
anything,
just
type
it
down
in
our
meeting,
notes
and
we'll
follow
up
after
the
fact
and
I'll
shoot.
You
a
note
oliver
about
engaging
with
attack
if
the
osv
is
interested
more
kind
of
formalized
outside
of
just
showing
up
here
and
sharing
ideas
and
collaborating.
B
All
right,
let
us
talk
about
our
possible
next
group
project,
a
cvd
guide,
helping
security
researchers
more
positively
engage
with
open
source
projects.
Osv
might
be
a
solution
or
help
contribute
to
that.
But
again,
is
that
something
that
this
group
is
interested
in
contributing
to.
I
think
we
have
a
great
starting
point
with
our
project
guide
and
also
the
two
pain
points
documents
we
worked
very
early
in
the
history
of
this
working
group
on.
G
B
See
and
that's
why
I'm
glad
jonathan's
here,
because
jonathan
has
a
good
perspective
from
the
security
research
side
of
things
to
help
us
better
understand
that
persona
a
little
better.
G
J
B
I
have
a
open
request
out
to
art
and
team
to
come
back
and
talk
about
vince
with
us.
I
mean
this
he's
not
lighter,
but
he
knows
a
lot
of
folks
over
there
so
potentially-
and
we
do
know
that
the
we've
talked
with
the
cve
board
a
couple
times.
If
we're
interested,
we
can
try
to
maybe
ask
them
back
for
a
future
call.
B
H
B
One
of
our
boggles
that
I
observed
from
the
foundation
is
we
don't
do
a
really
super
awesome
job
evangelizing
our
work
and
a
global
conference
like
black
hat
defcon
is
a
great
place
to
kind
of
showcase
this,
and
I
think
this
problem
in
particular.
It
is
a
big
friction
point
between
maintainers
and
researchers,
and
I
think,
if
we
can
add
some
value
in
that
space,
it
gives
us
a
great
platform
to
do
that.
I
see
that
who
had
their
hand
up
first
ann
or
jory.
B
I
I
Because
I
could
see
one
way
to
go
about
this,
I
mean
I
could
see
a
a
panel
of
interest.
I
You
know
here's
what
the
open
source
maintainer
experience
experiences
like,
because
I
imagine
chrome,
that's
kind
of
what
you're
trying
to
get
out
of
speaking
to
security
researchers
explaining
a
little
bit
more
about
who's
on
the
other
side
of
your
report
and
what
the
situations
are,
what
the
motivations
incentives
or
lack
thereof.
So
you
know,
I
think,
yeah,
maybe
ava.
You
were
just
saying
in
the
chat.
I
think
this
might
be
more
black
cat
e,
particularly
as
that
becomes
black.
I
That
conference
starts
to
look
a
little
bit
more
like
the
old,
the
rsa
audience,
and,
oh,
my
god
just
but
you
know
folks
will
be
there
think
with
open
source
on
the
brain.
So
then
you
can
submit
as
a
panel
and
if
you
can
get
the
paper
done
in
time.
That
is
fantastic.
If
not,
you
still
have
you
know
this
this
panel
to
share.
So
that
was
my
thought.
B
Oh
great
go
with
jory,
then
vicki
and
then
ava.
C
Just
on
the
events
front
and
I'll
also
note
that
I
think
that
there's
opportunities
for
our
working
group
to
to
present
this
at
the
open
source
summit
in
austin
at
the
end
of
june,
so
dates
wise.
If
that
were
something
and
security
is
going
to
be
a
big
focus
of
that
event,
I
think
we're
looking
at
actually
doing
a
specific
track
or
a
specific
series.
That's
open,
ssf
focused
so,
and
that
would
be
this.
It
would
be
super
rad
to
have
material
like
this
to
to
share
at
that
time.
B
A
You
know
yay
hi,
big,
plus
one
to
everything
and
set.
I
think
a
panel
is
a
really
great
idea.
I
do
think
that
open
source
summits
is
a
good
idea
as
well
for
different
reasons.
I
think
that
is
more
about
a
developer
focused
thing,
but
I'm
aside
from
this
being,
you
know
speaking
to
researchers
for
black
hat.
A
My
other
real
big
appeal
for
that
is
that
it
is
outside
of
the
linux
foundation,
echo
chamber,
right
and
really
speaking
to
people
who
are
not
normally
in
this
world
and
I
think,
there's
a
massive
amount
of
value
in
that,
especially
because
they're
researchers
and
then
we
can
hopefully
start
to
engage
them
in
what
we're
doing
so.
A
They
can
give
us
feedback
because
they
might
not
even
know
we're
here
right
now,
frankly
so
open
source
summit,
yay,
plus
one
for
the
developers,
black
hat
plus
one
for
the
other
side,
but
it
all
kind
of
implies
that
we
have
something
written
and
so
I've
not
gone
through
that
process.
Yet
I
don't
know
what
that
looks
like
here.
I'm
sure
we'll
figure
that
out
as
we
go
along-
and
I
shall
step
aside
now
for
eva.
H
My
comments
are
mostly
echo
what
has
just
been
said
to
add
to
that.
Having
been
to
several
infosec
conferences
of
various
flavors
and
stripes,
I
I
don't
feel
like
a
panel
presenting
this
group's
recommendations
aligns
with
the
typical
defcon
content.
It
could
come
off
the
wrong
way.
H
I
love
the
idea
of
having
the
paper
published
in
the
panel
of
the
black
hat
as
a
set
of
recommendations
from
the
open
source
community
to
the
security
research
community.
Saying
hey,
we
love
working
with
you
all.
We
want
to
get
to
work
better
with
you
all.
We
know
there
are
differences
here
and
how
we
approach
these
problems.
H
Here
we
are,
let's
talk,
I
think,
that's
a
great
approach
for
black
hat
and
rsa
frankly
having
having
spoken
from
a
different
security
developer
perspective
that
black
at
rsa
two
years
ago.
It
went
pretty
well
so
those
two
big
thumbs
up
to
getting
out
of
our
echo
chamber.
B
Thank
you
ava.
I
think
that's
an
excellent
way
to
phrase
it,
and
potentially
there's
also
opportunity
that
if
we
do
get
a
session
at
black
hat
to
present
the
formal
paper
and
kind
of
talk
start,
the
conversation
there's
always
opportunity
to
cross
the
street
over
to
defcon
and
talk
about
it
in
more
of
a
village
format
and
maybe
have
whiteboard
sessions
or
have
maintainers
and
researchers
kind
of
get
together
and
talk
through
some
of
the
pain
points.
So
I
think
there's
a
lot
of
upside
for
us
to
work
on
this.
B
B
All
right,
jonathan,
did
you
have
a
question
or
were
you
raising
your
hand,
you've
been
either.
G
B
Awesome
all
right,
so
how
about
this
I
propose
to
the
group.
Let
us
take
some
homework.
Let
us
think
about
what
types
of
objectives
we'd
like
to
achieve
with
the
paper.
You
know
how
what
what
would
maybe
area
topics
we
would
like
to
talk
about.
B
We
have
the
existing
cvd
doc
as
potentially
a
template.
We
have
the
two
pain
points
documents,
and
so
I
would
like
to
have
everyone
kind
of
think
about
the
project
reflect
on
it
and
come
back
in
two
weeks
with
some
thoughts
about.
B
I
think
we
need
to
have
x
or
y
in
the
paper
in
the
project
and
potentially
maybe
even
volunteering,
to
help
maybe
lead
that
section
getting
created
with
the
original
the
project
cvd
guide,
we
kind
of
broke
that
up
into
sections
and
we
had
little
section
heads
that
kind
of
helped
coordinate
that
particular
part
getting
done,
and
then
we
stitched
it
all
back
together
towards
the
end.
A
Oh,
thank
you.
This
is
one
of
two.
This
one
is
feeling
a
little
needy
right
now.
So
quick
question
about
timing.
As
far
as
the
cfp,
I
I
missed.
I
know
people
threw
some
dates
out
and
I
haven't
looked
at
the
notes
to
see
whether
anne
was
able
to
capture
them,
but
cfp
do
we
have
time
between?
Do
we
have
two
weeks
to
think
about
that
or
do
we
have
a
cfp?
That's
closing
in
like
a
week.
B
The
beauty
about
the
cfp
is,
the
paper
does
not
have
to
be
complete.
B
Back
into
the
actual
project,
if
we
want
to
spend
some
time
hammering
on
the
proposal
and
that's
something,
I'm
glad
to
start
a
document
and
share
it
with
the
group
and
yeah
april,
4th
is
our
target
april.
B
Hat
so
I
I
am
confident
we
can
get
the
proposal
put
together
as
long
as
we
have
the
fortitude.
We
want
to
dedicate
time
in
this
call
to
the
writing
and
correlation
over
the
next
couple
months.
A
Yeah,
I'm
totally
a
plus
yay,
plus
one
on
conference
driven
development.
I
just
wanted
to
make
sure
that
we
did
not
miss
the
the
window
with
our
waiting
for
two
weeks
to
talk
about
it
so
yeah
it
sounds
like
this
is
gonna
work
out
perfectly
for
timing.
B
Not
for
black
cat,
I
have
to
go
look
at
defcon,
but
I
will
take
the
action
item
that
I
will
start.
The
cfp.
Skeleton
share
it
with
the
group
and
as
we
are
as
we
get
more
details,
we
can
flesh
that
out,
but
the
skin
on
the
skeleton
so
to
speak.
Yeah
sounds
great.
B
All
right:
well,
why
don't
we
wrap
things
up
here
today?
Thank
you
for
oliver
for
getting
up
so
very
early
to
come.
Talk
to
us
look.
I.
G
Lord
he's
asking
that
question
now
I'm
running
into
the
other
hi
I
have
had
a
so
I
don't
know
if
this
is
constructive
or
useful,
or
anything
like
that.
But
I've
had
a
chaotic
day
of
trying
to
track
down
old
vulnerabilities
closures.
Is
this
a
story?
Can
I
share
a
quick
story?
Is
that
fine
with
everybody
it
could
be
story.
B
G
Right
perfect,
so
I
have
a
couple
of
open,
cve
open,
open
issues
with
cbe
in
general.
The
first
one
is.
I
have
an
open
set
of
issues
that
are
reported
to
google
back
in
you
know
a
year
ago,
and
they
still
don't
have
a
cd
number
assigned
to
them,
and
so
google
has
been,
as
a
has
been
a
very
slow
cna.
G
In
my
experience,
unfortunately,
and
so
the
the
like
one
of
the
things
that
you
are
ending
up
running
into,
is
the
researchers
like
it's
really
in
order
to
kick
off
all
the
automation
that
you
want,
like
all
the
infrastructure
that
you
want
to
get
like
a
vulnerability
disclosed
and
get
people
actually
handling
it
and
like
taking
care
of
it?
You
really
need
to
get
a
cve
number
so
because
of
various
different
issues
I'm
running
into
there.
You
know
they
won't
be.
I'm
blocked
on
that.
G
G
So
if
they,
if
they
sorry,
they
have
like
a
support
like
we
support
this
software
in
this
range,
and
then
I
disclosed
a
vulnerability
that
was
outside
of
that
range,
and
they
said
we
don't
issue
cds
for
that,
but
because
of
the
cna
rules,
they
have
declared
that
this
their
scope
is
all
software
published
by
vmware,
but
their
stated
their
stated
their
stated
policies.
They
don't
release
cves
for
things
that
are
outside
of
their
supported
scope,
and
so,
as
such,
you
can't
get
the
rules
are
under
the
cna
rules.
G
Is
you
can
have
another
cna
issue,
a
cde
for
somebody
else's
scope
if
it's
outside
of
the
scope
of
like
support
like
if
they
say
it's
in
the
supported
range
or
outside
the
supported
range?
So
I'm
running
into
that
issue
with
with
and
just
yeah
and
then
on
top
of
that,
just
trying
to
get
cd
numbers
in
other
places
is
complicated.
G
So,
as
a
result
of
all
this,
I
have
applied
to
become
a
cna
myself,
so
we'll
see
how
that
goes
as
a
as
a
process
it
trying
to
like
alleviate
some
of
these
project
problems
and
processes
that,
like
hey,
like,
I
can't
seem
to
get
anybody
to
issue
a
cd
for
me.
Maybe
if
I
didn't
do
it
myself
like
I
can
alleviate
some
of
the
stresses
and
pains
that
I'm
going
through.
So
we
will
see
how
that
process
goes,
and
I
will
keep
people
updated
on
that.
But
yeah.
B
G
B
I'm
loop
worthy
so
again
the
form
of
incident
response
and
security
teams.
That's
all
the
vendor
security
teams
in
the
industry,
because
different
vendors
view
it
differently.
Some
vendors
believe
a
bug
is
a
bug.
Is
a
bug
and
we'll
write
the
cve
up
to
note
something
is
out
of
support
and
try
to
help
encourage
people
to
move
away.
Other
people
have
different
perspectives
on
that.
B
We're
trying
to
as
an
industry
come
to
some
agreement
on
that,
and
then
that
could
be
a
good
conversation
between
first
minor
and
with
adding
your
perspective
in.
B
B
Let
me
ask.
We
actually
have
a
s.
A
p,
cert
sig
call
this
week
and
I
can
bring
that
up
there
with
them
and
see
where
else
is
happening.
I
don't
do
piece
as
much
anymore.
I
just
I
play
a
p-shirt
guy
on
tv.
I.
B
Security
and
incident
response:
it's
a
vendor
security
team,
okay,
so
that's
it's
kind
of
off
topic
for
this
call
yeah,
so
the
vmware,
the
oracle,
the
red
hat,
the
cisco.
The
intel
have
a
security
group
that
is
responsible
for
responding
to
reports
and
they
are
the
ones
that
are
typically
the
cnas
and
it's
been
a
a
long-standing
debate
amongst
vendors.
What
to
do
with
this.
A
G
K
Just
some
context
that
there
was
a
talk
in
the
recent
black
hat
europe
by
guys
at
whis
security
who
talked
about
the
the
challenges
around
vulnerabilities
that
are
related
to
cloud
service
providers
which
really
don't
publish
cvs.
They
just
fix
it
the
the
issue
in
the
back
end,
but
then
you
have
guys
that
sometimes
it
requires
users.
K
It
action
to
be
taken.
It's
not
enough
that
the
cloud
service
provider
fix
it
on
their
end
and
then
they
kind
of
send
an
email
out
to
folks
who
are
impacted
and
that
gets
missed
and
and
people
end
up
remaining
vulnerable.
So
they
talked
about.
You
can
find
the
recording
online
and
they're
trying
to
push
advance
an
initiative
to
have
some
kind
of
cloud
cv
database
which
different,
maybe
attributes,
for
example,
the
the
length
of
exposure.
For
example.
G
G
G
If,
if
hacker
one
and
bug
crowd
could
help
assist,
trying
to
get
something
like
that
off
the
ground
and
giving
that
they
have
like
the
vulnerability
information
that
you
know
encouraging
their
customers
to
potentially
provide
this
information
as
part
of
the
disclosure
and
stuff
like
that,
that
gets
published
on
the
hacker
one
feed
and
stuff
like
that.
B
And
that's
a
whole
other
community.
The
bug
bounty
community
of
interest
is
vendors
and
organizations
that
have
bug
bounty
programs.
I
haven't
heard
them
talking
as
much
about
this
because,
typically
with
a
bug
bounty
program,
it
is
documented
what
is
in
and
out
of
scope
and
isn't
necessarily
tied
directly
to
a
product
but
yeah.
G
I
I
mean
I,
I
agree
somewhat:
there
there's
the
complicated
nature
of
like
bug,
mounting
programs
considering,
like
you
know,
zoom,
for
example,
right
fund
money,
programs,
capturing
software,
and
it's
like
actually
that
company
ships
a
piece
of
end
user
software
right
and,
like
my
personal
opinion,
and
I
think
that
that's
the
kind
of
norm
is
that
there's
an
expectation
that
if
end
user
software
is
shipped
to
an
end
user
like
and
it
has
a
vulnerability
and
you
can't
just
fix
it
by
fixing
the
the
the
you
know:
server,
that's
hosting
the
pro
hosting
the
software.
G
B
As
I
mentioned,
I'll
talk
to
the
piecert
sig
thursday
and
I'll
bring
this
up
if
there's
a
area
that
people
are
able
to
participate
in
that
conversation
and
then
for
oliver,
I
will
make
a
love
connection
between
you
and
the
tac
so
that
we
can
see
how
that
might
proceed.
But
as
ava
mentioned,
that
the
formalization
is
still
in
flight,
so
that
might
not
I'll
get
the
connection
connection
together,
but
the
actual
to
progress,
maybe
a
little
bit
further
down
the
road
for
us.
B
All
right,
thank
you,
everybody,
please
think
about
our
researcher,
focused
cbd,
guide
and
something
like
end
of
support
or
documenting,
finding
out
how
to
find
out
what
the
support
for
a
project
is
might
be
something
interesting
to
put
in
there.
So
thank
you
all
we'll
talk
to
you
all
in
a
few
weeks
cheers
and
also
get
the
cfp
put
together.
So
a
straw
man.