►
From YouTube: OpenSSF Vulnerability Disclosures WG (February 8, 2023)
A
A
C
D
E
A
A
A
If
anyone
has
any
opens,
add
them
to
the
open
section
we'll
get
to
those
after
we
March
through
our
agenda.
First
and
foremost,
we
talked
with
attack
yesterday
and
they
agreed
to
formally
provide
us
feedback
and
commitment
to
provide
feedback
and
Counsel
on
the
open
source
security
incident,
Response
Team
plan.
So
hopefully
they
will
start
getting
that
to
us
in
the
next
week
or
two
so
that
we
can
have
a
direction
on.
You
know
what
our
next
steps
are
and
ultimately
present
that
plan
to
the
governing
board
for
funding.
A
All
right
also
hot
off
the
presses.
Yesterday,
at
the
tack,
it
was
announced
that
there
will
be
an
open
ssf
day
at
the
open
source,
Summit
North
America,
which
will
be
held
in
Vancouver
British
Columbia
Canada
later
this
year
in
May.
So
they
will
be
having
a
call
for
papers
out
there
shortly.
So,
if
you
missed
the
first
cfp
for
the
larger
ossna
conference,
we'll
have
an
opportunity
to
present
Focus
things
around
the
open
ssf
during
open
ssf
day,
and
you
might
see
the
Hat
in
action.
A
In
our
next
exciting
piece
of
news,
the
working
group
agreed
that
we
were
going
to
have
monthly
APAC
friendly
time
zone
meeting,
so
we
had
our
first
one,
the
26th
of
January
and
unfortunately,
there
was
light
attendance.
We
had
two
gentlemen
join
us
I
found
out
later
that
it
was
a
public
holiday
in
Australia,
sad
trombone
where's,
my
sad
trombone,
so
hopefully,
in
going
forward
we'll
make
a
little
bit
more
noise
and
make
announcements
that
we're
having
to
call
so
we
get
better
participation
and
I
know
for
a
fact.
A
We're
going
to
have
a
handful
of
folks
from
Australia
hopping
on
the
call
next
time
so
spread
the
word
to
anyone
that'll
be
available
later
in
the
day,
U.S
kind
of
early
morning,
Australia
Japan
and
probably
very
early
India
yeah.
We
would
like
to
see
that
to
kind
of
grow
into
a
Vibrant
Community,
because
the
osv
team
actually
is
out
of
Australia
we'd
like
to
get
better
engaged
with
the
osv
team.
The
open
source
vulnerability
schema
folks,
any
questions
about
that.
The
notes
are
below
you
can
see
what
we
talked
about.
A
A
A
Those
of
you
that
showed
up
today
to
talk
about
vex,
sorry,
the
Vex
folks
had
a
conflict
or
the
open
chain
guys
had
a
conflict
and
they
can't
make
it
today.
But
we
will
talk
pick
up
a
conversation
again
at
our
next
call
on
the
23rd
of
February
they'll,
be
talking
about
the
open,
Vex
specification
and
about
their
the
software
and
their
project
and
about
Vex
in
general.
So
if
you
have
questions
about
the
vulnerability,
exchange,
format
and
I,
think
it's
going
to
be
a
very
interesting
conversation.
A
All
right
now,
next
on
the
docket,
we
have
a
Litany
of
proposed
projects
that
the
group
has
expressed
interest
in
working
on
and
I'm
curious.
If
we
might
be
able
to
pick
one
or
two
and
potentially
start
some
forward
momentum
on
them,
I'll
list
them
off,
and
then
we
can
talk
about
them
individually
or
if
people
have
an
interest
in
them,
please
feel
free
to
raise
your
hand
and
shout
out
first
off.
A
It
was
suggested
that
while
we
have
some
awesome
cvd
guides,
if
a
maintainer
or
a
project
is
in
the
middle
of
an
active
incident
or
they
have
a
report,
they
don't
know
what
to
do.
It
might
be
useful
to
create
some
incident
response
playbooks
for
them
some
kind
of
pre-canned
steps
that
anyone
could
use
and
integrate
into
their
existing
workflows.
So
that
was
issue
113.
A
A
In
that
same
call,
we
had
a
similar
talk
about
enabling
the
guides
we
currently
have,
and
another
idea
was
to
actually
create
some
tooling
automation.
The
things
like
GitHub
actions
to
help
enable
specific
tasks
within
the
CBD
guides.
So
that's
for
those
members
that
are
more
technically
inclined
that,
like
to
code,
there's
some
opportunity
there
to
create
some
code
to
support
the
cvd
guides
and
provide
tooling
or
scripts
to
either
maintainers
projects
or
even
Finders,
and
that
is
issue
116..
A
Issue,
121
was
hey.
Somebody
realized.
We
have
a
lot
of
really
good
stuff,
but
we
don't
talk
about
it
very
often.
So
there
is
the
call
to
try
to
get
people
to
start
to
evangelize
this
and
Market
those
ideas,
whether
it's
talking
to
conferences
leveraging
social
media.
We
have
an
upcoming,
open,
ssf,
Town
Hall.
That
is
another
opportunity
where
we
could
share
the
word
about
the
guides
with
the
people
that
might
find
them
useful,
but
there's
issue
121
was
trying
to
focus
attention
to
moving
that
forward.
A
little
bit.
A
A
And
then
issue
123
is:
there
has
been
a
subgroup
created
for
to
try
to
assemble
people
to
discuss
how
finders
can
share
good
practice
or
techniques,
or
just
kind
of
talk
about
the
automation
of
vulnerability
reporting,
and
you
know
what
to
do
if
you,
if
you
have
an
unresponsive,
maintainer
kind
of
topics
related
to
cvd
from
like
a
finder
perspective
and
that's
issue
123.,
so
those
are
the
current
suggested
projects.
What
does
the
group
think?
Is
anyone
really
super
excited
about
any
one
of
them?
Did
we
miss
anything?
Is
there
something
else?
F
I
would
say
it's
not
it's!
The
the
final
one
about
automation
is
more
about
automation,
a
vulnerability,
finding
reporting
and
disclosing
and
less
about
unresponsive.
Maintainers.
Okay!
So
yes,
I
just
sent
a
there's,
a
new
working
group,
Channel
sub
channel.
It's
a
sub
subworking
group.
If
you're
looking
to
join
it,
it's
the
working
group
underscore
vulnerability,
underscore
disclosures
underscore
autofix
I
will
share
a
link
to
that
in
the
regular
channel
and
there's
a
doodle
poll.
A
And
that
doodle
link
is
in
the
open
section
there
for
anyone
interested
in
participating
in
that
group,
and
we
can
have
multiple
efforts
going
on
at
the
same
time.
Nothing
wrong
with
that.
But
would
be
interesting
to
see
the
group.
What
you're
interested
in
collaborating
on
and
sharing
back
with
the
larger
group.
E
A
We
don't
need
to
vote
necessarily.
These
are
all
ideas
that
members
have
submitted.
So
if
you're
interested
in
participating
in
any
of
them,
you
could
express
that
here
or
you
could
go
right
on
to
any
of
those
issues
and
comment
I'd
like
to
party
with
y'all,
and
we
will
potentially
set
up
focused
meetings
for
those
or
we
can
dedicate
time
during
this
call.
If
there's
enough,
if
enough
of
this
group
is
interested,
we
can
spend
time
on.
You
know
writing
a
new
guide,
for
example,.
F
I
am
intending
to
so
for
the
autofix
group.
That's
got
its
own
channel
and
its
own
discussion.
You
know
there
was
a
big
thread
on
that
topic.
Around
maintainers
are
not
necessarily
thrilled
by
automated
polar
price
generation,
or
there
are
certain
maintainers
that
are
not
not
necessarily
thrilled.
So
that's
doesn't
necessarily,
since
that's
already
got
a
breakout
working
group
I
invite
anybody
who
wants
to
join
that
one
hop
on
that
one.
The.
C
F
Thing,
that's
more
actionable
for
me
in
this
particular
case,
is
I
as
a
person
working
under
Alpha
Omega,
which
is
a
sub-project
to
the
open
source
security.
Foundation
I
need
a
disclosure
policy,
that's
kind
of
signed
off
by
other
people
for
how
to
do
disclosure
vulnerabilities
that
that,
from
the
work
that
you
know,
yes
me
and
I
are
doing,
and
so
this
is
the
issue
122.,
there's.
D
F
Topic
that
should
be
discussed
about
like
incoming
vulnerability
reports,
but
this
issue
that
I
opened
is
mostly
regarding
outgoing
vulnerability
reports
for
vulnerabilities
that
are
discovered
by
myself
and
or
anybody
else.
That's
representing
the
open
source
security
Foundation,
potentially
like
the
Alpha
Project.
If
they
you
know,
they
may
need
a
disclosure
policy,
so
I
have
a
disclosure
policy
that
I've
been
using
for
for
quite
a
while,
but
I'm
looking
for
you
know,
I
probably
need
to
take
that
and
condense
it
into.
A
A
F
F
F
A
G
This
is
doesn't
something
we've
been
discussing
with
in
the
alpha
maker
project
or
kind
of
Bravo
Central
Repository
Jonathan's,
helping
guide
best
practices
for
that
within
internally.
But
the
idea
is
to
use
the
GitHub
security
advisories
and
then,
as
far
as
the
automation
side,
the
triage
portal,
which
is
on
the
Omega
engineering
side
as
the
goal
to
automate
most
of
these
steps
and
keep
that
kind
of
restricted
foreign.
D
They
seem
to
be
around
generalizing
or
categorizing
issues
which
are
pertinent
to
a
web
technology
or,
let's
say
a
programming
language
model
or
a
pattern
that
is
followed
across.
But
when
it
comes
to
threat,
modeling
of
a
blockchain
technology
itself,
it
has
some
specialization
included
in
it
right
so
in
terms
of
design
or
the
threat.
Modeling
covers
those
aspects
as
well,
which
are
which
are
not
generically
spoken
about
in
any
disclosures.
D
So
how
do
we
come
up
with
a
a
process
or
a
standard
that
allows
us
to
include
those
design
factors
into
whatever
we
report
right?
So
that's
one
that
was
one
of
the
topic
that
got
discussed
a
lot
I'm
sure
like
from
hyperledger
Foundation.
We
should
be
able
to
add
value
into
it,
but
it's
I
mean
it's
also
a
good
topic
to
discuss,
if
possible,.
F
D
So,
let's
say
a
typical
project:
I'll
say
there
is
a
Java
library
that
has
some
vulnerability
and
when
the
disclosure
is
reported,
we
go
10
towards
saying
that
hey
this
function
is
written
in
a
particular
way.
It
allows
us
to
expose
certain
things
so
allows
us
to
pack
into
the
system
through
these
means,
and
it
probably
needs
a
fix
right
or
and
when
you
start
talking
about
a
blockchain
Technologies
threat
modeling.
D
D
So
the
vulnerability
may
not
be
in
terms
of
the
coding
practice,
but
in
maybe
in
terms
of
let's
say
if
this
gets
deployed
in
a
particular
fashion
or
like
this
kind
of
parameter,
if
done
through
these
configurations,
it's
possible
for
us
to
expose
certain
information
which,
which
is
not
right,
and
these
are
kind
of
issues
that
we
wanted
to
bring
up
right.
So
it's
mostly
also
around.
How
do
we
avoid
art
folk
happening
across
in
a
blockchain
network
through
a
coordinated
effort
across
multiple
parties?
And
that's
where
the
discussion
stemmed
out
or
originated.
F
F
I
still
am
having
a
hard
time
understanding
what
the
question
or
the
problem
so
so
the
problem
is:
is
it
the
impact
of
disclosing
a
vulnerability
with
respect
to
the
impact?
Because,
because
it's
using
blockchain
technology,
like
the
impact,
is
hard
like
it's
hard
to
fix
a
vulnerability
and
the
impact
can
be
that
like
money
gets
stolen
or
is
there
something
else
that
I'm
misunderstanding
here.
D
Sure
so
I
know
I
need
your
help
to
pitch
in
feel
free
to
jump
in.
It's
I'll
keep
the
money
aspect
away
because
most
of
the
technology
that
reveal
that
the
hyperledger
foundation
are
all
Consortium
based
or
more
I
mean
which
are
non-crypto
currency
related
blockchains
right.
The
cryptocurrency
is
just
one
aspect,
one
application
that
somebody
can
build
using
these
Technologies.
But
okay,
let's
say:
if
I
can
give
you
an
example.
D
D
A
Cvss
has
the
current
temporal
aspects
of
the
vulnerability
that
the
analyst
can
rate
and
that
is
designed
for
a
a
consumer
or
a
downstream
user
to
be
able
to
provide
additional
characteristics.
So
if,
in
your
example,
Integrity
is
very
important,
so
anything
that
would
have
an
Integrity
of
a
high
impact,
you
would
want
to
flag
and
bump
up
the
severity
on
so
CVSs
today
and
in
the
the
4.0
version.
Has
some
mechanics
in
there
to
tweak
the
initial
score
to
be
able
to
provide
that
severe
more
important
severity?
A
You
know
based
off
of
our
perspective.
You
know
this
is
more
important,
so
like
in
a
bank.
If
there
was
an
open,
SSL
Error
on
the
online
banking
platform,
they
would
could
be
able
to
go
in
there
with
the
current
mechanics
to
say,
State
based
off
of
our
threat
profile
and
our
appetite.
This
type
of
problem
immediately
gets
higher
severity
score,
but
that's
yeah.
Typically,
like
you
mentioned
a
room
you're
going
to
need
to
have
more
homework
and
understand
kind
of
what
the
threat
model
is.
What
the
specific
concerns
are.
A
So
if
you
can
blanketly
say
anything
that
affects
Integrity
is
automatically
High,
then
you'd
need
to
adjust
that
in
the
temporal
scoring
that
that
could
be
some
guidance
you
could
provide.
But
and
then
things
like,
we
talked
about
Vex.
That's
another
aspect
where,
in
the
future
you
potentially
could
say
we
are
affected
or
not
affected
and
that's
just
additional
vulnerability
information
for
the
the
risk
analyst
to
evaluate,
as
they
are
trying
to
understand
how
they
want
to
react.
A
And
then
you
have
like
the
exploitability.
That's
that's
another
way,
if
something's
being
actively
exploited,
there
are
other
metrics
that
you
can
provide
to
show
we're
aware
of
active
exploits.
So
therefore,
even
though
this
was
initially
a
low
rated
issue,
it's
immediately
critical
because
we
know
it's
being
weaponized
and
automated.
D
A
Please
yeah:
we
have
a
mailing
list.
If
you
want
to
ask
questions
or
have
a
dialogue
with
the
group,
we
also
have
our
slack
Channel,
which
I
mentioned,
has
the
90-day
Time
Bomb.
But
if
we
want
to,
if
this
is
a
topic
of
Interest,
we're
easily
can
make
a
discussion
and
have
that
threaded
discussion
within
our
GitHub.
A
G
F
A
All
right,
we
have
a
lot
of
proposals,
so
please
take
a
moment
to
read
through
them
after
we
close
this
call
and
consider
participating
in
them
express
your
commentary
on
the
issue.
As
Jonathan
mentioned,
for
the
autofix,
there
will
be
a
doodle
poll
very
soon,
and
you
know
thank
you
to
our
new
friends,
hopefully
you're
able
to
come
back
when
we're
a
little
bit
more
talkative
next
week
and
two
weeks
we'll
talk
about
Vex
again.
So
thanks
everybody
enjoy
the
rest
of
your
days
and
we
will
adjourn.
Thank
you.