►
From YouTube: Vulnerability Disclosures WG (February 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).
A
B
Rob
did
you
were
you
going
to
say
that
you
knew
people
at
the
see
the
cbe
process,
or
was
it
somebody
else.
B
A
I
am
humming,
ricky,
don't
lose
my
number.
E
F
Hey
rob
if
I
had
a
topic
for
a
discussion
that
I
hello
that
I
was
hoping
to
chat
about
today.
Where's
a
good
place
for
me
to
add
that.
A
F
A
Three
after
the
hour,
let's
get
rolling
hello,
everybody
and
welcome
to
the
february
7th
edition
of
the
open,
ssf's
vulnerability,
disclosures
working
group,
I'm
krobe
and
I'm
here
to
be
our
meeting
facilitator.
Do
we
have
anyone
that
is.
This
is
their
first
time
attending
that
wanted
to
introduce
themselves
and
say
hello
to
all
your
new
friends.
G
Yes,
I
would
like
to
hello,
I'm
kayla
undercoughler.
I
work
with
hacker
one,
and
I
am
the
team
lead
for
the
internet,
bug
bounty,
so
hello.
F
A
Well,
excellent:
well,
welcome
caleb
glad
to
have
you.
Anyone
else
is
their
first
time.
They
wanted
to
say
hello
to
all
your
new
friends.
D
Yeah
pretty
late,
but
these
are
my
time
like
actually.
B
I
don't
know
if
I'd
introduce
myself
last
week.
Two
weeks
ago,
I
don't
know,
I
took
a
step
away
from
a
long
time
was.
Did
I
say
hello
last
time
last
week
or
is
that
a
different
meeting
that
I
said
hello
in
might
have
been
the
other
meeting?
Okay,
hi,
my
name
is
jonathan
laichu.
I
have
been
away
from
the
osf
for
a
couple
several
months
now,
I'm
so
I'm
back
again,
I'm
no
longer
with
bradle.
B
I
am
doing
a
full-time,
I'm
full-time
software
security
researcher
and
I
was
awarded
the
dan
kaminski
fellowship,
so
I
will
be
spending
the
next
year
doing
open
source
security,
research,
finding
open
source
security
vulnerabilities
and
generating
thousands
of
pull
requests
to
fix,
open
source
security,
vulnerabilities
across
github
and
other
places.
So
that's
my
that's
my
year
ahead
of
me:
cool
welcome
back.
H
I
am
new
to
this
group
at
least
hi
everyone.
My
name
is
madison
oliver.
I
work
at
github
on
the
advisory
database
working
on
the
curation
side
of
it.
I
was
previously
at
the
start-
coordination
center.
I
know
some
of
you
from
my
work
there.
A
E
Really
fast
hi,
I
think
this
is
my
first
to
this
call.
I
don't
know
I've
got
so
many
calls
on
my
calendar.
Time
has
no
meaning
it's
the
pandemic,
so
hi,
I'm
vm
bursur,
but
we're
all
friends
here.
You
can
call
me
vicky.
I
am
at
wipro
I'm
director
and
senior
strategy
advisor
for
open
source
and
we
are
really
looking
forward
to
throwing
a
lot
of
people
and
helping
a
lot
of
stuff
with
the
security.
I
A
J
Sure
well,
and
maybe
we
should
move
these
around
because
I
don't
know
if
this
is.
However,
you
want
to
use
the
time
crib,
I
think,
for
a
while.
This
group
has
been
batting
around.
You
know,
there's
so
many
things
we
could
do
next
after
we
did
the
cv
d-guide.
What
is
the
most
valuable
thing
to
the
maintainer
community
that
we
could
do
and
I
think
we
for
a
little
while
we're
thinking?
Oh
maybe
alpha
omega,
was
doing
something
with
maintainer
feedback
or
input.
We'll
wait.
So
we
don't.
J
You
know,
survey
fatigue
double
up
or
something
like
that.
I
think
my
understanding
and
I
see
we
have
michael
scovetta,
so
maybe
you
can
correct
us
is
that
that
that
pathway
is
not
happening,
or
at
least
not
maybe
happening
as
soon
as
we
would
like
it.
So
I
was
trying
to
figure
out,
you
know:
do
people
do
we
just
try
and
at
least
get
some
signals
for
reaching
out
through
projects
we're
all
connected
with?
I
put
out
something
on
twitter,
so
you
know
super
scientific.
J
I
I
would
love
that
signal,
so
yes,
I
I
think
in
general
I
would
rather,
I
don't
want
to
do
anything
within
alpha
omega.
That
is
better
done
within
a
working
group,
so
even
to
the
point
I'll
talk
about
it
in
a
little
bit,
but
just
the
vulnerability
response
process
from
particularly
omega's
perspective,
whatever
I
can
do
to
like
leverage
other
things
to
make
that
happen.
Better
is
I
I
don't
want
to
reinvent
anything
like
if
I,
if
I
can
avoid
it.
I
So
yes,
certainly
knowing
how
knowing
the
pain
points
that
maintainers
feel
today
around
vulnerability,
disclosure
and
and
whatnot,
I
yeah
I
that
would
be.
That
would
be
terrific.
A
I
will
say
in
a
this
is
obviously
my
favorite
working
group
out
of
the
foundation,
but
in
my
favorite
group
in
the
foundation,
the
developer,
best
practices
working
group.
We
did
a
project
around
the
end
of
the
year
around
giving
out
multi-factor
tokens
and
through
that
exercise
we
contacted
a
lot
of
different
projects
and
maintainers.
So
let
me
circle
back
to
david
david
wheeler.
He
was
kind
of
leading
the
charge
and
let
me
see
if
we
have
any
open
kind
of
door
openings.
A
All
right:
well,
let's
put
that
in
the
back
of
everyone's
mind,
think
ruminate,
that
for
the
next
week
or
two,
and
maybe
we'll
have
some
ideas,
if
you
have
anything,
feels
feel
free
to
leverage
our
mailing
list
immediately,
there's
the
slack
and
then
you
always.
We
have
the
agenda
ready.
You
can
just
tag
things
in
there
for
next
time.
I
So
for
for
omega,
specifically
we're
going
to
be
finding
when
we
find
a
vulnerability,
we
want
to
be
able
to
report
it.
We
want
to
report
it.
You
know
confidentially
and
all
that
stuff
we're
just
getting
started.
So
you
know
we're
trying
to
think
in
advance
of
at
the
point
where
we
need
to
be
efficient
in
how
we
disclose.
I
The
question
I
have
is:
what
would
the
best
methodology
be
for
finding
the
maintainer
contacting
them,
giving
them
enough
information
so
that
they
can
start
with
themselves?
You
know
start
looking
at
the
you
know,
report
or
whatever,
whatever
we
generate,
but
also
be
available
for
back
and
for
the
inevitable
back
and
forth
at
very,
I
don't
think
we
need
to
be
so
high
scale
that
everything
needs
to
be
automated.
I
I
also
don't
think
that's
the
right
engagement
model
and
it
doesn't
feel
good
as
a
maintainer
to
just
have
things
kind
of
chucked
over
the
wall
at
you,
but
I've
been
we've
been
thinking
about
and
full
disclosure
I
mean
we've
been
thinking
about
like
is
there
a
place
for
lfx
security
here?
Is
this
something
that
would
be
better
for
a
you
know,
hacker
one
kind
of
engagement?
Is
it
github?
Is
it
we
have
to
build
something
ourself
or
is
email,
just
fine?
I
If
it's
email
well,
because
we're
these
are
all
going
to
be
critical
zero
days?
Do
we,
you
know
what
should
we
do
in
terms
of
you
know,
public
keys
and
and
how
do
we
find
them
and
and
how
do
we
like?
We
immediately
go
down
this
rabbit,
hole
of
of
of
pain,
and
so
the
purpose
of
this
is,
you
know,
I'm
sure
you
all
have
thought
about
these
things
a
lot
deeper
than
I
have
so
I
would
love
to
learn
from
you
and
hopefully
make
it
better.
Six
months
from
now.
J
Yeah,
I
would
love
to
hear
more
about
your
pain,
presuming
that
you
know
you.
Let's
say
that,
or
I
guess
my
first
time
would
be
to
you
know:
go
through
whatever
security
disclosure
policies
the
projects
have.
So
I'm
curious
in
that
lens.
Are
you
talking?
Are
you
anticipating
that
projects
are
not
going
to
have
disclosure
policies?
Are
you
anticipating
that
you
know
they
might
not
be
as
responsive
as
you
like,
and
so
you
need
to
kind
of
decide.
Your
own
policy
of
this
is
when
we
publicly
release
something.
I
I
Some
projects
will
be
very
responsive
but
require
a
lot
of
engagement
on
our
side
and,
if
there's
a
more
efficient
way,
I
don't
want
to
say
I
just
want
to
outsource
the
problem
someplace
else,
but
I
want
the
I
want
it
to
be
done
most
efficiently
globally,
which
may
mean
us
not
us
doing
less,
or
it
may
mean
that
we
have
to
do
it
all,
in
which
case
we
just
need
to
plan.
For
you
know
this
many
people
doing
it
as
opposed
to
this
many
people.
J
J
I
I
don't
know:
what's
going
to
be
considered
in
scope
and
out
of
scope
for
them
right,
so
so
for
omega,
if
you
just
think
of
it
as
a
giant
black
box,
that
runs
lots
of
tools
and,
let's
just
say
it
has
magic
in
it
that
generates
high
quality
findings
that
still
need
to
be
triaged,
but
they'll
come
out
and
they'll
come
to
someone
representing
the
omega
project,
so
paid
staff.
Let's
just
call
them
they'll
look
at
it.
They'll
say
yep
this.
This
is
a
totally
legit
issue.
I
I
So
these
will
be
projects
with
which
we
have
no
prior
relationship
with
we'll
be
looking
up.
The
maintainer
on
you
know,
wherever
we
can
find
it
the
same
as
anybody
else.
A
B
Hi,
my
name
is
jonathan.
I've
had
this
exact
problem
and
I've
been
trying
to
solve
this
exact
problem
for
a
long
time,
and
this
actually
dovetails
perfectly
into
the
like
exact
topic
that
I
have
listed
below
yours,
which
is
how
I
do
my
disclosure
process,
and
so
I
have
to
get
a
bro.
B
The
problem
that
I
keep
running
into
is
twofold:
one
can't
reach
maintainers
two.
How
do
I
keep
track
of
all
the
disclosures
that
I
have
going
on
at
the
same
time,
because
I
get
a
lot
going
like
I
currently
have
you
know
six,
eight,
something
disclosures
going
right
now
and
I've
been
two
weeks
in
three
weeks
into
the
dan
minsky
fellowship
right.
Like
you
know
I,
and
so
how
do
I
do
that?
B
How
do
I
enforce
consistently
a
90-day
disclosure
timeline
and
so
the
process
that
I've
been
going
and
also
I
I
have
done
the
the
process
of
like
okay,
this
group
has
email
disclosure.
This
group
has
hacker
one.
This
group
has
bug
crowd.
This
bug
group
has
like
you
know,
and
this
you
know.
Google
projects
have
monorail
right.
It
is.
B
It
is
a
plethora
of
different
platforms
you
can
disclose
via
and
it
is
a
a
nightmare
to
keep
track
of
all
the
different
disclosure
channels
that
you
have
and
also
all
the
timelines
you
have
for
disclosing
via
all
those
channels,
especially
with
somebody
with
adhd-
and
you
know,
yadda
yadda
right
like
so
so
my
answer
was
to
say:
I'm
done
dealing
with
all
these
different
various
disclosure
channels.
B
I
will
disclose
that
there
is
a
vulnerability
by
a
hacker
one
bug
crowd,
email
whatever,
but
I
will
tell
the
maintainers
or
the
companies
or
organizations
that
I'm
reporting
to
hey.
I
have
a
vulnerability.
Give
me
your
github
usernames.
I
will
add
them
to
a
github
security
advisory
that
I
have
created
against
my
repository,
because
I
can't
create
github
security
advisories.
Yet
against
other
projects.
B
I
have
just
pissed
off
the
apache
foundation
with
this
process.
They
are
not
happy
with
me,
I
they
are.
They
are
saying
to
me:
well,
no,
we
receive
we
receive
our
vulnerability
reports
by
email.
Please
send
us
to
us
via
email,
and
my
response
was:
please
send
me
the
github
usernames
of
the
people
you'd
like
to
have
involved
in
this
advisory.
B
I've
had
conversations
the
other
group
that's
doing
this
in
a
similar
way
is
hunter
dev.
They
send
a
magic
link
out
and
they
say
here's
the
report.
You
want
to
see
the
details
of
the
vulnerability
here.
It
is
you
don't
accept
it.
It
goes
public
90
days,
so
it's
not
perfect,
but
when
you
get
to
the
scale
of
vulnerability
disclosure
that
you're
looking
like
you're
looking
to
potentially
build
a
lab
right
of
people,
the
github
security
lab
has
gone.
The
route
of
we
will
disclose.
B
Whatever
way
the
maintainers
have
chosen
and
likes
told
us
to
disclose
via,
I
don't
have
the
name
github
behind
me,
I'm
just
an
individual
and
I
also
need
to
keep
track
of
these
things.
So
you
know
it's
all.
That's
my
experience.
I'm
happy
to
share
more,
like
you
know
why
I
got
here
the
questions
that
you
may
have
stuff
like
that,
but
you
know
that's
where
I'm
at
currently
and
I
have
a
whole
reason
like
if
you
look
at
my
readme,
that
I
posted
in
the
chat
there's
like
a.
A
All
right,
ava
was
next.
I
I
thought
those
were
some
pretty
good
points.
Mine
is
probability
short.
I
think
I've
shared
this
with
michael
before,
but
I
want
to
bounce
about
everyone
else,
who's
on
the
call
that
if
this
lab
or
the
omega
project
does
successfully
get
a
bunch
of
tooling
that
can
find
these
vulnerabilities
in
mass.
I
think
one
of
the
responsible
things
to
do
is
build
a
gas
pedal
in.
I
B
Speak
to
that
too,
in
terms
of
so
I'm
using
tokul
to
find
security
vulnerabilities
across
open
source
right
and
I'm
I'm
writing
these
poke
series
and
then
I'm
looking
at
thousands
of
projects
that
are
potentially
vulnerable.
Hundreds
of
thousands
of
projects
that
are
vulnerable-
and
you
have
to
that
point
pick
okay,
like
is
this
a
is
this
somebody's
one-off
project,
or
is
this
important
enough
to
actually
report
to,
and
so
there
is
a
self-selection
sort
of
self-filtering
that
has
to
go
on
there.
B
I'm
usually
using
like
information
like
star
count
or
you
know,
does
this
thing
show
up
on
google
when
you
look
for
it
stuff
like
that,
but
primarily
star
count,
because
github
doesn't
render
like
the
criticality
store
on
the
project
when
you're
looking
at
it
on
github?
Yet
so
you
know
what
I
forget
of
is
get
on.
Criticality
store
into
the
user
interface
would
be
really
nice.
J
A
commenter
you're
meant,
I
love
the
metaphor
of
a
gas
puddle
because
that's
kind
of
where
my
my
thinking
was
going
as
well,
because
if
we
go
back
to
you
know,
kind
of
the
mission
of
the
open
ssf
is
about
improvement
of
the
security
of
all
these
packages.
So
I
think
we
have
to
keep
that
bigger
mission
at
forefront
and
not
scope.
It
too
too
far
down
to
be.
J
What
would
I
do
if
I
was
acting
in
my
capacity
as
an
individual
security
researcher,
because
that
research
is
not
the
end
of
our
mission,
and
so
I'm
thinking
you
know
there
probably
needs
to
be
some
kind
of
bigger
part
of
this
vulnerability
disclosure
angle
of
okay,
so
project
does
you
know
we
have
a
report
for
them?
They
don't
have
a
security
policy.
The
next
step
for
omega
should,
from
my
perspective,
should
not
be
to
figure
out
well
we're
gonna.
J
J
Branch
of
you
know
what
happens
when
a
project
is
unresponsive,
because
the
goal
being
you
know,
improvement
of
the
package
if
they
are
unresponsive,
that
is
a
unmaintained
package
and
that
kind
of
seems,
like
you
know,
do
people
feel
like
that
should
be
forked
and
kept
in
a
parallel
branch.
Until
someone
can
resolve
and
re-merge
or
you
know,
yeah,
those
are
just
kind
of
where
some
of
the
things
where
my
mind
was
going
and
taking
that
gas,
puddle
and
being
like
okay,
we,
you
know,
we
have
five.
J
I
don't
know
projects
backed
up
who
have
not
been
responsive.
We
need
to
not
keep
pumping
out
research.
We
need
to
pump
out
education.
I
I
I
think
that
totally
makes
sense
for
for
projects
that
are
willing
to
accept
help,
and
I
hope
that
the
vast
majority
of
them
are
the
best
practices.
Working
group
is
working
on
a
kind
of
leave
behind
packet
that
would
go
with
any
disclosure
via
omega,
which
would
include
things
like
hey.
We
notice
you
don't
have
a
security
response
like
process
like
here
are
some
templates
and
here's
the
cvd
guide
and
things
like
that
for
the
ones
that
genuinely
just
don't
answer
the
phone.
I
I
agree
we
have
to
do
something.
It
may
depend
a
lot
on
the
context.
I
also
don't
want
to
turn
open
ssf
into
the
adopters
of
unwanted
projects
at
scale
I
mean
we
just.
We
would
blow
up
trying
to
trying
to
do
that.
You
know,
but
at
the
same
time
having
and
this
this
might
get
a
little
controversial,
but
having
an
opinion
that
this
project
is
unmaintained
and
they
do
not
respond
to
security
vulnerabilities.
I
That's
going
to
go
long.
Reports
is
an
interesting
data
point
and
I
feel
uncomfortable
going
that
way,
mostly
as
my
role
as
I
work
at
microsoft
and
that
the
the
optics
of
that
at
like,
if
not
for
nothing
else,
the
optics
of
that
are
terrible,
but
I
think
that
from
a
consumer
of
open
source,
I
do
want
to
know
which
projects
I
use
that
are
either
officially
unmaintained
or
de
facto
and
maintained.
I
So
I
I
don't
know
how
to
resolve
that.
So.
J
One,
I
think
one
lesson
you
can
borrow
from
security
research.
Is,
you
know
when
people
decide
to
share
something
publicly
about
you
know
they
do
frequently
list
like
here
are
all
the
attempts
I
made
to
contact
this
group
and
not
in
a
you
know,
shaming
way
or
anything,
but
just
to
make
it
clear
that,
like
I,
my
preference
was
coordinated
disclosure
and
I
wasn't
able
to
do
it
this
time
around.
A
I
have
a
couple
perspectives
I'll
share.
Firstly,
as
a
member
of
the
great
mfa
giveaway
our
great
mfa
distribution.
A
A
Everyone
wants
to
be
engaged
differently
and
you
know
and
keyed
in
on
it.
Our
mission
is
to
help
open
source
maintainers
the
open
source
ecosystem
improve
their
security.
So
wherever
we
can,
we
should
try
to
reach
the
developer
where
they
are,
whether
that
is
a
mailing.
J
A
It
is
a
twitter
account,
a
github
issue,
whatever
that
is,
and
that
that's.
I
would
strongly
encourage
everyone,
and,
I
think,
that's
the
advice
we
have
in
our
cbd
guide
that
this
group
put
together
is
that
you
know
follow
that
project's
desired
path,
because
developers
have
their
own
tooling,
their
own
processes,
their
own
infrastructure.
So
if
we
can
get
information
in
a
format
that
is
easily
digestible
for
them,
you're
more
likely
to
get
that
output.
A
A
second
perspective
is,
I
had
the
pleasure
to
work
at
a
small
company
called
red
hat
that
has
been
doing
open
source
security
for
25
years
and
how
that
organization
operates.
A
Is
they
have
a
list
that
team
tracked
as
of
last
year
over
400
000
different
packages,
projects,
components
that
are
part
of
that
portfolio
and
they
knew
how
to
get
in
touch
with,
or
at
least
where
to
send
a
signal
out
to
each
one
of
those
different
projects,
and
it
takes
a
lot
of
work.
A
They
have
a
significant
amount
of
people,
and
that's
kind
of
all
they
do
is
coordinate
with
these
different
projects,
but
to
where
that
worked
out
is
by
understanding
where
all
those
folks
were
kind
of
what
projects
they're
on
you're
able
to
build
that
rapport,
so
that
you
could
potentially
get
past
the
no
one
answered
the
combined
inbox,
because
I
know
that
kayla
is
the
maintainer
for
project
blah,
I'm
going
to
reach
her
through
back
channels
or
that
you
know
that
there
are
secret
behind
scenes,
mailing
lists
where
these
developers
or
teams
function,
and
it's
just
it's
a
lot
of
relationship
building
and
it
just
it
takes
hard
work
to
track
this
down
to
write
down
who
the
right
people
are,
what
the
right
method
to
get
to
them
is.
A
You
know
some.
Some
of
the
teams
I
contacted
with
the
mfa
thing.
They
wanted
a
jira
issue
which
was
annoying
because
I
had
to
get
provisioned
into
their
jira.
And
now
I
get
all
the
jira
ticket
updates,
but
it
creates
a
lot
of
noise,
but
it
it's
worthwhile
because
you
can
build
that
relationship
and
then
you
have
the
opportunity
to
provide
those
learnings
like
hey.
We
noticed
you
don't
have
a
security
policy,
here's
a
great
template.
A
B
Can
I
ask
you
a
question
about
that?
Were
you
using
was
that
just
for
trying
to
track
down
who
the
who
the
maintainers
of
red
hat
software
were
of
all
saw
like
all
open
source
software?
Was
that
that
master
list.
A
The
red
hat
product
security
team
has
a
list
of
all
components
that
are
part
of
that
red
hat
portfolio,
so
that
is
their
artifact.
They
maintain
internally
or
the
great
mfa
distribution.
We
leverage
the
efforts
of
not
my
favorite
open
source
project,
but
a
good
project.
The
open
ssf's
securing
critical
projects
group
they
have
a
list
of
their
quotes,
the
most
important
projects
top
200.
E
So
something
I
think
we
might
want
to
consider
then
sorry,
this
is
vicky
from
wipro
is
kind
of
for
better
or
worse.
I
think
it
it's
valuable
to
borrow
a
concept
from
more
of
the
enterprise
space,
which
is
to
kind
of
have
account
managers
essentially
right,
because
the
personal
touch
does
matter.
E
Each
of
these
groups
does
have
different
different
touch
points
that
make
sense,
and
you
know,
keeping
in
touch
with
them,
and
I
think
this
is
a
valuable
way
for
people
to
be
able
to
contribute
is
to
be
able
to
essentially
take
on
here's.
Your
here
are
your
accounts,
these
four
or
five.
However,
many
accounts
that
make
sense
to,
but
I
think
that's
a
really
valuable
way
that
we
can
potentially
contribute
and
to
share
the
load,
because
this
is
going
to
be
a
considerable
load.
E
E
That's
really
a
great
deal
of
work
that
can
burn
somebody
out
very
quickly
and
so
having
a
mechanism
to
not
only
split
up
the
list,
but
also
to
assign
it
and
to
have
a
kind
of
a
succession
plan
for
handing
it
off
to
people.
I
think
that
can
be
very
good
for
allowing
us
to
continue
this
well
to
have
the
continuity
that
we're
going
to
need
in
order
to
maintain
this
cda
cde
communication
across
the
projects
that
we
select
and
that's
something
I
think
we
should
look
at.
E
As
I
know,
that's
looking
at
tooling
and
implementation
rather
than
actually
the
philosophical.
You
know
theoretical
side
of
things,
but
it's
certainly
something
that
I
think
we
should
be
considering
and
it
can
help
to
bring
in
a
lot
of
people
who
want
to
contribute
and
want
to
feel
like.
I
am
helping
with
open
source
security
go
me,
but
this
is
a
way
where
they
can
legitimately
make
a
difference,
and
we
can
have
a
method
and
a
process
for
that.
A
Is
we
had
talked
a
very
long
time
ago
to
the
best
facial
hair
in
vulnerability
disclosure
art
mania
and
they
cert
cc
was
toiling
away
at
a
tool
they
wanted
to
open
source
vince
we
had
had
them
come,
do
a
couple
presentations
to
us
and
that
was
kind
of
a
platform
bug
bounty
platform
agnostic
way
to
try
to
get
all
the
stakeholders
together
for
a
particular
vulnerability
disclosure
and
allow
the
researcher
and
the
reported
to
team
kind
of
control
who's
in
the
reading
list
and
when
and
how
updates
are
shared.
A
A
That's
a
possible
opportunity
for
the
foundation
is
to
take
on
assistance
with
developing
that
tool
and
helping
maintain
it
and
evangelizing
it
as
a
neutral
place
that
people
can
go
to
to
help
share
communications
around
disclosures
and
if
you
know,
if
it
hopped
out
to
a
bug,
crowd
or
a
hacker
one.
Fine,
but
we're
not
necessarily
constrained
to
some
of
those
other
things
that
sometimes
are
distasteful
to
maintainers.
G
No,
I
actually
think
I'm
the
platform
part
of
it
is,
is
really
important
to
be
able
to
have
all
the
stakeholders
all
together
in
one
place,
to
be
able
to
discuss
whatever
your
you
know
whether
it's
a
vulnerability
report
or
anything
anything
else
really.
So
I
was
just
gonna
also
add
from
the
internet
bug
bounty
perspective
when
I've
been
doing
all
the
reach
outs
for
inviting
projects
to
participate
in
the
ibb.
G
It's
kind
of
that
same
thing
of
I'm
emailing.
The
teams
with
like
you
know,
you
would
think
it's
it's
a
happy
story,
I'm
inviting
them
to
partake
in
in
this.
As
you
know,
as
a
project,
and
it's
definitely,
you
get
mixed
mixed
feedback
coming
back
from
any
sort
of
even
response
at
all.
One
of
the
things
that
I've
started
to
do
is
I
always,
of
course,
we
kind
of
keep
the
kind
of
staple
enrollment
rule
of
you
have
to
have
a
disclosure
channel
for
ibb
participation.
G
For
obvious
reasons,
there
has
to
be
something
already
in
place,
and
so
I
anytime
I'm
inviting
a
project.
I
immediately
go
for
what
is
their
disclosure
channel
and
then
I'll
send
out
that
first
communication
to
the
to
the
group
at
large.
G
If
I
know
that
there's
a
really
active
maintainer,
which
is
one
of
the
pluses
also
of
when
we
have
projects
who
are
on
platform
for
at
hacker,
one
like
they
have
their
their
their
program
on
the
platform,
it's
easier
because
we
know
who
the
active
maintainers
are,
who
are
receiving
those
submissions
and
then
the
ones
who
are
engaging.
G
So
it's
a
little
easier
to
reach
out
to
folks
when
you
know
who
is
engaging
on
the
maintainer
side,
and
so
I
I
go
to
github
a
lot
for
that
as
well.
For
other
projects
like
I
look
for
who
are
the
names
that
keep
popping
up
here?
G
So
that's
been
some
of
my
strategies
for
reaching
out
to
groups,
but
even
without
like
at
this
point,
I
think
I've
reached
out
to
you
know
we're
in
early
early
stages,
but
I've
reached
out
to
over
35-
and
I
probably
have
about
you-
know
50
percent
response
rate
which
isn't
bad
pretty
good,
yeah
yeah,
it's
not
bad,
and
certainly
not.
Everyone
has
been
interested
in
participating,
which
is
also
very
fair
back
to
that.
G
Every
project
you
know,
has
their
own
flavor
of
things,
but
I
certainly
see
the
value
in
having
some
sort
of
shared
communication.
G
Platform
opportunity
whatever,
when
you
actually
disclose
the
vulnerability
in
the
first
place,
because
then
everybody
can
can
be
in
the
same
place,
so
whether
that's
something
that
would
be
built
or
I
mean
I
know
this
sounds
a
little
bit
silly
coming
from
someone
who
works
at
hackerwood,
you're,
probably
like.
Of
course
you
think
that's
a
great
idea,
but
I
totally
see
the
value
of
having
everyone
be
able
to
come
to
one
place.
G
So
even
if
it's
that
you're
reaching
out
to
these
projects
through
their
disclosure
channels
but
kind
of
like
what
was
brought
up
earlier,
reaching
out
saying
hey,
we
found
this
vulnerability
come
here
so
that
we
can
discuss
it
with
all
the
stakeholders
present.
I
can
see
the
value
in
that,
although
I
could
also
see
the
pushback
from
projects
so.
B
Statement
and
another
comment
for
michael
so
two
things
that
as
you're
building
out
this
process,
two
things
that
you
do
need
to
consider.
You
don't
need
to
do,
but
you
know,
is,
if
you're
establishing
a
lab
or
group
of
people
to
do
this
sort
of
that
stuff
figuring
out
what
you're
going
to
have
for
a
disclosure
policy
around
like
timeline,
like
you
know,
are
you
going
to
have
an
enforced
90-day
disclosure
timeline?
If
not
45,
you
know,
45
is
pretty
standard,
certain
places,
90
other
places.
B
Right
and
so
you
like
get
headlong
into
and
so
then,
instead
of
a
disclosure
you're
having
a
conversation
of
hey,
I've
got
a
vulnerability,
I'm
not
disclosing
here,
because
your
policy,
you
know
how
do
you
want
to
handle
this
like,
and
so
that's
another
reason
why
I've
kind
of
said
you
know
I'm
not
doing
disclosure
of
vulnerabilities
anymore
by
a
bug,
crowd
or
hacker
one,
because
you're
you
keep
getting
corn
swaggled
into
these
vulnerabilities.
These
non-disclosure
agreements
that
you
weren't
expecting
to
be
a
part
of,
and
so
yeah.
B
That's
that's
that's
something
to
keep
in
mind
as
part
of
like,
and
so
certain
like.
I
think
that
hunter.dev,
for
example,
those
guys
say
if
the
company
uses
hacker
one
we
don't.
We
won't
engage
with
that
like
we
won't.
We
won't
because
we're.
We
know
that
there
are
policies
and
legal
stuff
that
gets
in
the
way
of
our
us,
exposing
to
those
channels
and
stuff
like
that.
So.
I
B
Really
have
non-controversial
yeah
if
you
want
a
really
good
set
of
justifications
to
back
that
up
google's
project
zero
has
an
faq
and
they
have
a
really
detailed
write-up
of
why
they
made
the
decision
to
do
90
days,
yeah
and
or
at
least
why
they
have
a
disclosure
policy,
not
necessarily
90
days.
90
days
was
kind
of
driven
by
microsoft,
because
you
guys
have
a
like
your
release
cycle
is.
It
gives
three
release
cycles
to
get
it
out,
but
yeah.
J
Oh
yeah,
sorry,
I
was
looking
for
that
project.
Zero
write
up.
No,
I
got
lost
my
training
thoughts,
oh
jonathan,
what
you're
saying
about
corporate
programs
and
reward
programs,
not
understanding
the
difference
between
open
source
and
their
proprietary
program
software
and
trying
to
shovel
things
through
the
same
program.
J
I
would
actually
really
love
to
educate
security
groups
and
ospos
about
the
difference
between
those
two
and
why
the
the
vrp
you
have
set
up
for
your
proprietary
software
may
not
be
appropriate
for
your
open
source
stuff
that
you
have
released
at
one
point
in
time,
and
you
know
in
terms
of
like
why
I
so
desperately
want
this.
J
What
should
the
openstack
do
for
maintainers
list
is
because
I
would
love
to
just
jump
on
that,
but
that
might
not
be
the
most
impactful
thing
we
can
do
you
know,
but
be
it
through
other
linux
foundation,
groups
or
something.
I
just
think.
I
frequently
see
that
pathway
where
somebody's
trying
to
report
something
has
a
ton
of
maintainers
at
a
certain
corporation.
They
shovel
it
through
their
corporate
program
and
their
terms
are
not
appropriate
for
open
source
software.
It's.
B
I
I
would
stretch
it
to
be
even
wider
than
that.
Any
piece
of
software
that
is
shipped
to
customers
that
you
are
not
it's
not
just
corporately
run-
should
have
a
cve
associated
with
it
right.
If
you
are
shipping
a
piece
of
software,
even
if
it
is
closed
source
right,
you
are
shipping
that
to
end
customers,
then
it
should
have
a
cv
associated
with
it.
Right,
for
example,
I
was
the
one
that
found
this
vulnerability
in
zoom
zoom
had
a
non-disclosure
agreement
on
their
on
their
on
their
thing.
B
That
was
the
kind
of
vulnerability
that,
because
it
went
public,
there's
a
long
story
around
this,
but
apple
was
able
to
patch
millions
of
macs
to
remove
a
remote
code,
execution
vulnerability,
but
that
only
happened
because
I
disclosed
the
vulnerability
publicly
right.
It's
not
just
about
open
source,
it's
about.
There
is
software
being
shipped
to
customers
and
there
should
be
cvs
associated
with
that.
B
I
Yeah,
I
I'm
I'm,
I
will
we'll
think
next
next
time
this
meeting
happens
I'll
bring
my
partner
in
crime
michael
windsor
aboard
so
we'll
we'll
kind
of
continue
and
iterate
on
this
over
time.
I
think
what
I'm
gonna
do
initially
is
an
initial
staffing
for
omega.
I'm
gonna.
I
think
we
had
half
of
a
devro
function.
I
Initially,
I
might
bump
that
to
a
full
dev
row,
because
even
if
we
wind
up
finding
you
know
it
whether
it's
vince
or
a
hunter
dev
style
thing
or
something
else,
we
still
need
someone
on
our
side
to
kind
of
own
this
and
be
passionate
about
it,
and
I
feel
like
the
security
researcher,
finding
the
phones.
I
It
may
not
be
the
best
use
of
their
time
or
interest
to
kind
of
double
them
up
with
the
coordinated
process
that
perhaps
that's
a
different.
You
know
it's
just
a
different
person
who
have
different
interests
and
all
that
and
that
might
be
more
effective,
but
at
minimum
to
have
like
to
know
that
we're
serious
about
it
by
having
like
someone
like
that
is
their
day.
Job.
B
So
to
point
on
that,
one
of
the
things
that
I've
learned
is
have
the
person
whoever's
writing
the
vulnerability
up,
write
it
for
public
consumption
yeah,
because
then
it's
written
once
not
twice.
I
learned
that
the
hard
way
there's
also
a
component.
I
think
that
this
is
important
too,
is
that
there,
when
vulnerability
disclosure
gets
involved,
you
end
up
with
egos
flying
around
a
little
bit
right.
There's,
there's
a
part
of
ego
and
like
not,
and
so
separating
it
may
help
dampen.
A
F
In
hours,
awesome,
hey
everyone
a
long
time
listener.
First
time
caller.
So
we
we,
we
have
a
release
coming
up
that
required
us
to
choose
a
format
for
vulnerability
data.
We
went
with
osv
for
that
format
and
how
we're
gonna
structure
it.
I
have
heard
through
the
grapevine
that
spdx
is
considering
their
own
format
when
they
release
their
v3
I'm.
This
is
like
a
telephone
game,
so
someone
is
on
this
call
from
spdx.
F
E
Is
vicky
again,
I
do
have
thoughts
mostly
because
I
do
participate
in
spdx,
but
I
do
not
participate
in
spdx
technical,
which
is
all
where
all
these
specification
conversations
are
happening.
I
just
sort
of
lurk
there
because
I
don't
have
these
cycles
to
go
and
catch
all
the
backstory
on
it.
I
do
know
that,
yes,
you
are
very
correct.
They
are
considering
this.
I
do
not
know
where
it
is
in
the
list
as
far
as
it
happening
in
3.0
or
what
it
will
look
like
in
3.0.
E
So
I
can,
if
you
need,
I
can
certainly
set
up
introductions
to
people
who
can
give
you
that
information,
but
right
now,
if
you
have
to
choose
vulnerability,
formatting
go
with
what
we
have,
because
3.0
is
not
going
to
be
coming
out
for
a
while.
I
do
know
that
it
is
very
much
in
the
deep
down
in
the
weeds
conversation
level
of
things,
so
we're
we're
not
going
to
be
seeing
3.0
in
the
next
month,
two
months,
three
months,
four
months
so
it'll
be
a
while.
E
So
if
you
need
to
do
vulnerability,
reporting
use
the
format
we
have
the
one
that's
available
and
then
you
know
spdx.
I
know
we'll
probably
have
to
flex
around
that
to
make
things
work
or
I'm
sure
there
will
be
some
sort
of
interchange
format
when
that's
necessary,
but
for
now
use
what
you
got
because
vulnerabilities
are
too
poor
important
to
ignore.
F
Yeah
last
one
to
that
vicki
just
want
to
follow
up
on
one
thing:
you
said
which
was
use
the
one
we
have.
Are
you
referring
to
osv
when
you
say
that
or
is
there
a
different
format
that
comes
to
mind
as
like
the
automatic
choice.
E
I
don't
have
a
horse
in
that
race,
so
I'm
not
gonna,
give
any
recommendations
one
way
or
another.
My
spdx
friends
would
like
me
to
recommend
some
sort
of
spd
exe
ness,
but
you
know
use
what
you're
most
familiar
with
and
what's
going
to
be
easiest
for
the
team
to
get
information
out
there
as
long
as
it's
a
standardized
format
that
is
complete
enough
for
you
to
get
your
job
done.
Is
that
osb
great?
E
You
said
if
it's
something
else
that
you
know,
if
you
know
cyclone
dx
or
something
has
something
then
use
that,
but
I
have
to
confess
I
don't
know
enough
about
that
side
of
it
to
be
able
to
make
recommendations.
Yet
give
me
a
couple
of
months.
F
Same
thanks
so
much
vicky
did
any
other
folks
have
thoughts
on
vulnerability
formats,
or
are
you
putting
your
thumb
on
the
scale
of
one
certain
format
versus
another.
F
D
So
I'm
we're
using
osv,
but
I
have
to
say
that
I'm
not
that
familiar
with
spdx,
yet
we're
we're
also
taking
a
look
at
it,
but
currently
we're
using
osv
where
we're
building
a
vulnerability
database
with
data
coming
from
all
kinds
of
sources,
nvd
and
those
we
are
the
main
ones
and
then
proprietary
data
that
we
are
adding
as
enrichment.
D
D
So
maybe
it
will
be
nice
I'll.
Try
to
I'm
also
a
part
of
that
group,
so
I'll,
try
maybe
to
ping
them
to
come
present
it
here.
But
in
a
nutshell,
the
aim
of
the
project
is
to
eliminate
the
gatekeepers.
It
refers
to
the
ego
aspect
that
was
mentioned
earlier,
as
well
kind
of
something
like
everyone
that
thinks
something
is
wrong.
D
Security
wise
can
can
submit
the
gsd
entry,
basically
a
vulnerability,
and
then,
if
it's
later
revoked
or
you
know
the
vendor,
then
it's
it's.
It's
all
on
github,
but
but
so
you
can
invalidate
it
later,
but
but
off
the
bat
you
can
put
an
entry
there's
like
a
like
a
form
that
you
fill
out.
There's
kind
of.
D
Basic
syntax
around
it
and
they
are
also
using
currently
osv
as
their
go
to
format
so
yeah.
That's
my
justice.
A
I'll
highlight
kate
that
within
the
vendor
community
in
the
industry,
they
will
back
the
the
csaf
format.
So
a
lot
of
industry
piece
product
security
teams
will
use
csaf
and
participate
there.
So
that's
another
thing
you'll
want
to
consider
depending
on
who
the
audience
is
going
to
be
it's
an
older
it.
It
started
off
as
cvr
and
then
transformed
a
couple
years
ago
to
csaf
so,
depending
on
what
community
you're
trying
to
reach
out
to
and
a
lot
of
times,
commercial
scanners
are
keying
in
off
that
data.
A
So
if
you
are
looking
to
help
service
that
community
at
all,
that's
another
thing
to
consider.
F
B
I
just
was
clear
so
like
I'm
not
familiar
with
a
lot
of
these
formats.
Are
all
these
formulas
based
upon
or
leveraging
cve
as
an
under
the
hood
identifier,
or
is
that
not
not
the
case
in
a
lot
of
these?
I'm
just
like
I'm
just
I'm
new
in
this
area?
So
I'm
curious
and
poking
and
asking
that
question
that
context.
A
A
For
example,
like
the
cloud
security
alliance
has
spun
off
their
own
vulnerability,
identifier
as
well,
and
it's
supposed
to
be
complementary
to
cve,
but
it
is
potentially
different.
I
know
that
some
asian
countries
run
their
own
cve
like
numbering
authorities,
so
you
just
you
need
to
be
careful.
Cve
is
the
most
broadly
adopted
identifier.
D
Yeah
that
just
maybe
to
to
elaborate
on
on
that
point,
so
the
the
gsdb
is
or
just
is
supposed
to
have
like
name
spaces.
So
you
have
a
name
spaces
that
it's
basically
the
cv,
data,
for
example,
and
you
can
have
a
namespace
that
is
some
kind
of
even
a
proprietary
scanner
can
add
its
take
on
the
vulnerability
and
the
the
the
idea
is
that
you,
you
have
all
of
the
data
of
the
vulnerability
from
various
places
in
one
place
and
then
as
a
security
researcher
or
developer.
D
You
have
all
the
data
in
front
of
you
and
then
you
can
decide
what
you
want
to
take
out
of
it,
but
so,
and
each
namespace
can
can
maintain
its
from
the.
If,
if
you
have
an
osv
namespace,
it
will
have
the
the
osv
format
and
if
different
names
can
have
different
formats.
F
A
And
as
a
working
group
that
is
part
of
the
open
source
security
foundation,
if
we
have
strong
opinions,
we
think
something
that
adds
a
lot
to
maintainers
and
the
open
source
ecosystem.
We
can
help
evangelize
and
get
behind
any
particular
standard
or
some
type
of
rosetta
stone
that
was
able
to
jump
between
them.
F
It
does
seem
like,
in
terms
of
you,
know,
interoperability.
It
would
be
helpful
if
we
had
a
position
on
which
format
we
advocated,
for
it
can
really
only
help
the
industry
if
we're
all
speaking
the
same
language.
F
That's
that's
really
why
we
chose
to
do
a
little
extra
work
to
have
our
upcoming
release
formatted
in
osb
to
be
sort
of
part
of
that
solution.
I
obviously
don't
work
with
osb
or
I'm
associated
with
them.
So
that's
I
have
no
horse
in
that
race,
but
that
does
seem
to
be
the
the
horse
at
the
head
of
the
pack.
This
metaphor
is
really
falling
down,
but
maybe
that's
something
we
want
to
talk
about
in
a
future
session.
A
E
I
think
that's
a
really
valuable
thing
to
consider
in
future
versions,
at
least
or
future
calls
at
least
looking
at
the
available
options
and
reviewing
them,
and
you
know
at
least
looking
at
the
ones
that
might
be
very
good
ideas
or
alternatives
for
us
to
recommend,
because
I
think
that
recommendation
working
with
as
many
different
companies
as
I
do
they're
all
looking
for
a
recommendation
right,
and
so
we
are
the
group
that
is
best
positioned
to
make
an
informed
decision
as
to
what
is
or
is
not
going
to
work.
E
So
if
anyone
ever
needs
me
to
bring
someone
in
from
the
spdx
side
who
is
actually
knowledgeable
on
that
crap,
please
just
raise
the
red
flag
and
I'll
do
that.
I
am
not
that
person,
I'm
just
the
connector
in
that
particular
case
has
nist
put
out
any
recommendations.
F
F
A
So
I
put
an
entry
under
the
last
item
in
the
agenda
under
meeting
notes.
If
I
could
get
some
helpers
volunteer
to
help
lead
the
discussion
or
bring
in
subject
matter
experts
around
the
different
formats,
that
would
be
super
groovy
and
we
will
get
that
set
up.
We
can
do
a
little
advertising
on
the
mailing
list
and
slack
and
whatnot
to
try
to
make
sure
we
get
people
that
are
interested
show
up.
That
might
not
otherwise
be
able
to
make
the
call.