►
From YouTube: OpenSSF Vulnerability Disclosures (June 28, 2023)
Description
Meeting minutes: https://docs.google.com/document/d/1jzqhW9SK9QRA39fQz0RiAkvpRWB0xztt1TAFJEseTlA
Repo: https://github.com/ossf/wg-vulnerability-disclosures
A
A
B
B
A
C
C
D
A
A
A
B
A
A
A
Vex
and
csaf
I've
talked
with
puerco
over
with
the
openvex
spec
and
CTL
and
we're
as
a
Sig
going
to
participate,
but
I
would
encourage
anyone
else
interested
to
hear
kind
of
state
of
the
art
of
Vex
and
csap
advisories
sign
up
for
the
summit
and
you'll
get
details
in
the
near
future
about
kind
of
how
they're
going
to
conduct
that.
But
anyone
that's
curious
about
Vex,
especially
might
be
something
interesting
to
monitor.
I'll,
be
there
any
questions
about
Vex,
Summit.
A
Anyone
that
has
kind
of
a
horse
in
the
game
of
coordinated
vulnerability,
disclosure
would
get
together
and
it
would
be
a
multi-day
conference
and
they're
looking
at
sometime
in
the
first
quarter
that
they
would
probably
be
holding
this
and
I
had
shot
a
note
out
to
the
slack
Channel
and
I
got
some
folks
that
expressed
interest
again.
That's
something
I
personally
will
probably
be
participating
in
and
I
would
invite
this
working
group.
If
we
see
value
in
kind
of
listening
to
and
collaborating
with
all
these
different
groups.
A
You
know
folks
like
Oasis,
that
own
csaf
or
first
that
runs
a
CVSs
I'm
sure
miter
will
be
there
like
the
nvd
folks.
So,
if
anyone's
interested
in
kind
of
talking
about
this
and
participating,
let
me
know
I'll
kind
of
keep
a
soft
list
of
names
and
then,
as
I
get
more
form
as
it
gets.
More
formal
I
will
share
specifics
with
everybody
so
that
you
can
see
if
you
want
to
clear
your
calendars
to
participate
in
Volcan
any
questions
or
comments
about
that.
A
A
All
right,
then,
my
final
item
is
it
also
rare
related
note.
Mr
Wheeler
was
approached
by
our
friends
at
nist.
They
are
considering
creating
an
nvd
Consortium,
so
a
group
of
people
that
they
could
get
feedback
on
the
national
vulnerability
database
about
vulnerability,
disclosure
and
kind
of
vulnerability.
Advisories
there
will
be
publication
in
the
U.S
federal
register,
which
is
an
or
a
thing
that
the
US
government
publishes
updates
around
activities,
so
I
already
expressed
through
David
that
this
working
group
probably
would
love
to
be
considered.
A
I'm
going
to
specifically
reach
out
to
my
friends
at
osv,
we'll
talk
Thursday
evening,
I,
hope
and
then
the
open
Vex
people
were
agreeable
and
are
interested
in
participating,
and
this
would
be
a
way.
Ideally,
we
can
help
influence
them
to
be
more
friendly
towards
open
source
needs.
Our
open
source
perspective
kind
of
the
the
velocity
and
speed
that
we
operate
on
and
kind
of,
our
methods
like
using
git
repositories
and
that
type
of
stuff,
so
I
think
it's
a
good
opportunity
to
collaborate
and
again
anyone
interested
as
that.
A
D
The
chairs
of
the
group
have
to
be
elected
and
confirmed
by
the
technical
committee
as
a
whole,
which
is
going
to
be
in
a
couple
weeks
here.
So
hopefully
that
will
be
good,
but
the
meeting
commenced
without
the
chairs
anyway
was
organized
this
week
to
discuss
that
and
discuss
like
you
know
restarting
this,
and
what
are
the
agenda
topics
and
things
that
we
want
to
tackle
kind
of.
First,
one
of
those
things
was
vulnerability:
disclosure,
so
I.
D
Don't
really
have
an
agenda
here
for
this
group,
I
kind
of
just
wanted
to
throw
it
out
there
and
see
I,
don't
know
any
thoughts
on
that.
You
know.
I
know
this.
This
is
open,
ssf,
we're
talking
about
open
source
software,
but
of
course
the
software
is
built
on
programming
languages
and,
if
programming
languages
themselves
introduce
a
vulnerability
that
you
know
has
a
huge
impact.
D
So
you
know
the
scope
of
work
for
the
task
group
is
also
developing
best
practices
for
developing
secure
programs
written
in
JavaScript
and
things
like
that.
But
there
are
a
lot
of
interesting
questions
around
vulnerability,
disclosure
that
are
specific
to
like
when
they
appear
in
a
programming
language
or
when
they
appear
in
you
know
the
language
is
constantly
evolving
right.
D
New
proposals
are
coming
in,
and
implementations
are
happening
and
browsers
vendors
and
things
like
that
and
nodes
start
to
implement
new
features
at
what's
called
stage
three
and
so
like,
while,
which
is
by
stage
three,
a
proposal
should
be
relatively
flushed
out
and
the
spec
should
be
relatively
unchanging,
except
for
like
extreme
things.
But
at
any
of
these
points
you
could
have
vulnerability.
D
So
there
are
a
lot
of
questions
around
that.
How
does
that
work?
What's
the
visibility
like
for
that,
because
tc39,
it's
not
anybody
can
be
in
there,
but
the
bar
is
relatively
low.
Any
company
that
is
wants
to
become
an
echo
member
or
a
prospective
member
can
be
in
there.
So
there's
also
questions
about
okay,
who
is
the
group
of
people
that
would
see
potential
vulnerabilities
right
now?
There
is
no
policy
right
which
is
not
good.
D
I
I,
don't
expect
the
volume
of
these
things
to
be
high,
but
it's
something
that
we
need
answers
on,
so
I
I,
don't
know
I'll
leave
it
at
that.
Like
I
said,
I
don't
have
any
agenda:
I,
don't
I
know
that
everybody's
doing
work
and
all
kinds
of
other
things,
and
don't
necessarily
need
to
be
worried
about
this.
But
I
don't
know
thoughts,
comments.
E
D
Github
was
in
the
process
of
joining
ecma
when
they
were
acquired
by
Microsoft,
and
so
the
folks
that
were
representing
GitHub
are
now
on
the
Microsoft
delegate
team.
So
some
of
your
colleagues
are
in
tc39
I,
don't
remember
which
ones
might
be
participating
in
the
task
group,
but
the
the
anybody
who
wants
to
be
in
the
task
group
that
says
39
could
be
participating.
E
A
A
And
I
think
definitely
there's.
This
group
has
some
good
materials
that
we
could
help
share
with
that
Community
to
help
them
get
set
up,
helping
them
develop
a
policy
help
kind
of
talk
about
how
different
ecosystems
and
projects
manage
volume,
intake
and
coordination
we'd
definitely
be
glad
to
kind
of
share
our
learnings
on
us.
You
know
a
science
tangential
note.
We
probably
maybe
you
and
I,
should
talk
to
David
wheeler
and
maybe
also
consult
from
the
best
practices
working
group
that
I
think
there's
potentially
things
in
there.
A
We
can
also
help
share
with
that
community
that
some
artifacts
that
they
might
want
to
consider
creating
for
their
contributors
and
collaborators.
You
know
to
help.
Do
things
securely
and
tailor
them
for
JavaScript,
yeah
I
think
there's
a
lot
of
opportunity
to
partner
up
and
collaborate
any
other
thoughts
from
the
group
here.
A
A
A
B
So
a
little
bit
of
a
story
on
this
one
external
energy
processing
is
a
very
old
vulnerability.
It's
been
well
documented,
well
understood
it's
basically,
a
vulnerable
I
mean
kind
of
the
vulnerability
at
its
root
originates
back
with
the
XML
part
with
the
XML
standard,
because
the
XML
standard
itself
allows
for
when
parsing
XML
documents
to
access
arbitrary
resources
on
the
file
system
and
from
external
resources,
which
leads
to
vulnerability
such
as
file.
B
You
can.
You
can
use
this
as
an
attacker
to
exfiltrate
the
contents
of
files
from
the
file
system
or
use
it
as
a
get
based,
server-side,
request,
forgery
and
then
build
your
own
URL
and
then
Excel.
The
contents
of
the
you
know
resource
via
either
DNS
or
or
a
get
request
to
an
attacker
server
or
whatever
yada
yada
yada
anyways.
B
So
this
vulnerability
is
built
into
the
Java
standard
Library
by
default,
and
I
last
year
posed
a
question
to
the
Oracle
jdk
team
stating
hey
like
you
know.
This
is
a
pretty
well
known
vulnerability.
It's
documented
in
all
these.
You
know
documentation
that
you
stated
like
how
to
protect
yourself
against
xxc
yada
yada
yada,
but
has
there
ever
been
a
cve
assigned
to
this
and
in
general,
the
answer
that
I
got
from
Oracle
and
a
bunch
of
other
party?
You
know
oracle
primarily
was
no.
B
There
is
not
yes,
this
is
a
yes.
This
is
a
known
issue.
No,
we
don't
consider
it
a
security
vulnerability.
It's
a
it's
a
bug
that
we
should
fix
and
address
by
the
Jep
process,
and
you
know
we
will
reach
out
to
you
when
we've
created
a
Jep
for
this
to
to
actually
remediate
this
that
you
know
remediate
this
so
that
it's
you
know
secure
by
default
and
so
I've
waited
a
year
ish
and
have
yet
to
hear
back
from
Oracle
about
a
Jep
actually
being
issued,
and
so
I
said.
B
B
B
So
obviously
you
know
like
attempted
to
to
convince
them
to
to
issue
CBE,
and
then
you
know
leverage
some
of
the
rules
in
the
cve
rulebook
to
communicate
that
as
well
and
the
the
cve
board
looked
at
the
case
and
came
back
this
today
and
said
we
will
not
be
issuing
a
cve
for
this
vulnerability
in
accordance
with
the
agreement
with
Oracle
on
this
case,
which
is
kind
of
annoying
so
I'm.
This
is
mostly
just
Story
Time
with
Jonathan
and
also
like
I,
don't
I,
don't
it
I
I?
B
Thoughts
on
apis
being
vulnerable
in
their
default
configuration
requiring
opt
out
to
be
secure.
I
guess
that's!
That's
the
general,
like
I'm
of
the
opinion
that
if
an
API
is
insecure
by
default
and
lets,
you
shoot
yourself
on
the
foot
using
it
in
the
way
that
it
was
designed.
It
should
be
considered
a
vulnerability
and
it
should
be
something
you
should
opt
into
the
vulnerable
Behavior,
not
out
of
vulnerable
Behavior.
A
A
All
evolve
and
grow
we're
starting
to
learn
and
adapt.
So
I
think
this
potentially
could
be
a
great
topic.
If
we
actually
do
see
Volcan
be
a
thing.
I
think
this
could
be
a
great
like
birds
of
a
feather
or
a
panel
discussion
and
start
that
conversation
about
you
know
how
do
we
modernize
and
kind
of
keep
that
secure
by
default
attitude?
You
know
that,
and
you
know
I.
A
There
are
other
means
to
share
vulnerability
if
you,
if
it's
that
severe
but
I,
think
we
might
want
to
try
to
influence
behavior,
and
you
know,
opportunities
where
we
ever
have
these
forums
like
Volcan
or
other
areas.
I
think
it'd
be
a
great
opportunity
to
get
people
together
and
start
to
debate
and
have
that
conversation?
How
do
we
make
things
more
modernized
shift
our
perspective
to
be
more
customer
sensitive.
You
know
the
user
sensitive
right.
B
And
that
was
kind
of
the
idea
that
I
was
trying
to
push
here
is
like
hey
I
know.
This
is
an
ancient
vulnerability.
I
get
that
it's.
You
know
it
was
written
when
it
was
written,
and
maybe
we
can't
fix
it
immediately,
but
we
should
still
be
assigning
a
cve
number,
so
the
fault
kind
of
gets
laying
at
the
feet
of
whoever
was
the
cause
of
the
vulnerability.
B
Instead
of
blaming
all
the
end
users
for
not
implementing
it
correctly,
so
I
get
what
you're
saying
about
it
being
a
a
vulnerability
stuck
in
time
sure,
but
I
was
hoping
that
the
cve
board
would
be
able
to
see
the
the
the
times
have
changed
around
our
perspective
around
vulnerabilities
and
be
willing
to
consider
it
consider
assigning
a
cve
number
in
the
light
of
of
our
kind
of
current
understanding
of
the
way
the
world
should
be.
Ideally
I,
don't
know
as
two.
C
Yeah
I
mean
I,
guess
it
was
kind
of
get
into
like
it
almost
goes
to
a
philosophical
question:
what's
the
purpose
of
a
CV
in
the
first
place
right,
if,
if
you're
gonna
create
a
cve
that
we
know
will
never
be
fixed,
why
do
we
create
the
cve
right?
Because
the
so
the
only
way
that
the
cve
could
be
fixed
would
be
you'd
have
to
do
a
Java,
major
rev,
so
you'd
have
to
do
a
Java
2.
right.
C
I
mean
yeah
I
mean
the
reality
is
like
crowbe
was
saying
like
there's
Untold
software
that
depends
on
the
behavior
as
written
and
like
this
isn't
a
configuration
that,
like
you,
change
in
a
file,
you
have
to
actually
change
it
in
code.
It's
configuration,
that's
second
code,
so
yes,
it's
a
configuration,
but
it's
a
it's
a
behavior
in
the
library,
that's
the
standard
library
and
it's
part
of
a
standard
and
in
order
to
change
that
standard
you
you
have
to
it's
a
breaking
change
right.
C
C
C
What
what's
the
you
know,
because
what's
gonna
end
up
happening
now,
it's
just
a
vulnerability
that
shows
up
when
everybody's
scan
all
the
time
and
then
people
who
don't
understand
it
are
going
to
be
constantly
pushing
people
to
fix
things
that
they
can't
fix
and
all
this
Jazz
right
so
does
it
actually
move
things
forward.
That'd
be
my
question.
B
A
G
G
My
clean,
perfect,
deep
vision
of
how
cve
should
work,
which
is
also
my
opinion
and
reality,
aren't
exactly
the
same
thing.
So
right,
I
I
do
appreciate
you
know,
what's
the
value
of
a
CD,
if
no
one's
going
to
do
anything
but
I
still
fundamentally
come
down
on
the
side
of
what
I
put
in
chat
and
I've.
Had
this
discussion
or
disagreement
with
many
many
vendors
over
the
years
and
the
CV
and
much
of
the
CV
program
right
cve
is
the
catalog
it's
the
identifier.
G
It
is
completely
independent
of
their
being
a
fix
or
who
has
to
fix
it
in
in
some
sense
and
I
I,
don't
think
anything,
but
that
is
a
safe
way
to
really
base.
You
know
foundationalize,
if
you
will
CDE
I,
realize
in
practice
right
they
showed
up
on
the
scan.
You
have
to
fix
it
or
not.
You
got
to
clear
your
board
of
the
Reds,
get
them
to
Green
Microsoft.
Very
specifically-
and
this
is
public
right-
had
tied
cves
to
fixes
not
the
vulnerability.
G
This
caused
a
lot
of
trouble,
so
I
I'll
start
with
that.
I
missed
the
beginning
and
I.
Don't
I
happily
will
read
more
John
Johnson
or
talk
to
you,
but
yeah
there
could
be.
You
know
there
very
very
well
can
be
a
technical
or
philosophical
debate
on.
Is
this
a
vulnerability
or
not
I
don't
mean
to
challenge
you
on
it
or
have
that
debate
right
this
minute
and
then
sort
of
cve
rules
wise?
G
The
rules
are
in
fact,
being
revised
and
again
sort
of
for
the
good
of
the
cve
program
and
the
planet.
Yes,
Oracle
owns
Java.
They
have
a
right
of
first
refusal.
All
right.
Other
CNAs
have
the
option
if
Oracle
chooses
not
to
assign,
including
as
you
found
out,
Jonathan
right,
the
miter,
the
the
sea.
Let
me
say
the
right
words
here:
the
cve
program,
CNA
of
Last
Resort,
which
I
think
is
probably
where
your
request
ended
up.
They
went
and
talked
to
Oracle
had
a
discussion
decided,
decided
something.
G
It's
always
a
different
discussion
having
the
idea
out
there
than
not
having
been
having
hours
of
discussion
about.
Why
should
we
have
an
ID
we're
talking
about
a
thing?
It's
that
thing
like
you
said
about
that
Java
thing:
let's
just
put
the
ID
on
it
and
then
have
the
discussion
about
who
should
fix
it.
Should
we
fix
it?
Is
it
a
breaking
fix?
G
B
Over
the
argument
that
I
made
is
that,
according
to
the
CNA
rules,
a
parent
that
supplies
software
cannot
override
h
a
a
a
a
downstream
consumer
that
also
ships
that
software
in
terms
of
the
decision
of
it
being
a
vulnerability.
And
so
my
claim
was
that
you
know
basically
challenging
them
on
the
rule.
B
The
rules
basis
of
the
scene,
CNA
system
that,
because
I
as
an
open
source
maintainer,
because,
according
to
the
CNA
like
training
documentation,
they
they
declare
what
a
a
product
owner
is
and
a
product
owner
over
a
product
can
be
the
person
that
makes
the
thing,
but
also
anybody
who
takes
that
software
and
redistributes
it
and
because
I'm
an
open
source
maintainer
and
have
redistributed
versions
of
the
jdk
in
products
that
I
have
so
have
have
made.
I
can
claim
that,
because
of
that,
I
am
a
main.
B
F
B
G
G
No,
no,
no,
the
I
might
get
the
term
slightly
wrong
here.
There's
not
I,
don't
believe
it
came
to
the
board.
Typically,
the
board
does
not
just
the
board
very
rarely
discusses
individual
issues
like
that
assignment
issues.
The
last
one
I
can
remember
was
if
you
played
loud
Janet,
Jackson
movie
out
of
a
sufficiently
powered
subwoofer,
the
hard
drive
would
Skip
and
be
bricked,
and
we
had
a
big
discussion
about
right.
The
physical
world
defeats
the
electronic
world
every
time.
G
If
you
have
to
get
into
that
debate
that
might
go
in
the
rules.
Okay,
so
there
is
a
piece
of
the
cve
program
called
the
CNA
of
Last
Resort.
It
is
technically
minor,
folks
running
it,
yes,
and
that
role
of
the
program
is
who
spoke
to
Oracle
and
probably
to
you
and
who
you
were
ended
up.
So
that's
not
the
cve
board
itself,
that
is
the
assigner
of
Last
Resort,.
E
B
G
Is
the
Council
of
roots,
perhaps
yes,
that
one
or
yeah
again
I
I
am
here
to
sincerely
represent
the
CDU
program,
I'm,
not
a
blind
salesperson
for
it.
There
is
some
culture
bureaucracy,
overhead
that
is
historical
and
it
is
what
it
is,
and
there
are
we're
trying
to
make
things
not
so
bureaucratic,
but
it's
a
slow
process.
B
Up
offline
I'm,
happy
I'm,
happy
online,
but
yeah
yeah,
but
I
am
I.
Am
this
I
think
that,
like
how
this
thing
is
how
the
CV
system
is
structured
is
generally
a
valuable
conversation
for
this.
Is
it
intimately
tied
with
vulnerability
disclosure
anyway?
So
but
yes,
I'll,
send
you
my
accountability
and
we
can
chat
out
afterwards
offline,
so
okay,
yeah,
but.
A
A
E
B
I
agreed
I
just
want
to
address
the
Jason
Kurtz's
responsive.
So
if
a
cve-
oh
wait,
if
it
is
it's
not
also
cve
is
it
is
the
cwe
invalid.
So
cwes
are
common
weakness.
Enumerations
and
those
are
not
cves
and
a
weakness
is
not
a
vulnerability.
I
had
this
debate
I
there
is
a
cwe,
for
example,
of
using
outdated
dependencies,
and
so
I
was
of
the
mindset
that,
like
hey
CBE
board,
shouldn't
there's
be.
B
In
their
outdated
dependencies,
and
so
there's
a
lot
of
things
that
just
never
get
a
CV
number,
because
the
CNAs
are
like
not
our
problem
anymore
and
so
end.
Users
never
get
told
that
they
need
to
update,
because
the
cve
system
is
the
thing
that
feeds
the
engine
and
the
Machine
of
dependency,
updating
and
dependabot
and
renovate,
and
all
that
stuff.
A
G
A
It's
related
to
your
API
conversation,
Jonathan,
that
this
is
there's
a
new
method
of
development.
Open
source
is
a
very
prevalent
model
and
dependency
management
is
a
constant
challenge.
So
I
think
it's
something
you
know
we
need
to
look
at
as
an
ecosystem
and
kind
of
reflect
on
how
we
might
try
to
do
a
little
better
and
maybe
cve
isn't
the
right
mechanism.
Maybe
there's
something
else,
but
you
know
it's.
We
should
definitely
start
to
have
that
conversation
and
make
people
aware
and
get
very
smart
people
in
the
room
to
start
solutioning.