►
From YouTube: OpenSSF Vulnerability Disclosures WG (January 25, 2022)
A
A
B
Back
at
Red
Hat
I
used
to
have
I
was.
It
was
rough
for
us
because
most
of
the
team
was
either
in
Europe
or
like
Australia
India.
So
like
North,
America
hours
were
pretty
quiet
unless
I
was
talking
to
engineering.
But
if
I
needed
to
talk
to
my
team
I
had
to
get
up
at
you
know:
butt
crack
30
or
stay
up
till
yeah
middle
of
night.
C
D
A
A
B
Good
times,
hello,
everybody
we
are
just
Gathering,
we'll
get
started
a
few
minutes
after
the
hour.
If
you
could
please
sign
in
to
the
agenda
and
Mark,
any
items
that
you
would
like
to
talk
about
today
is
opens
that'd,
be
groovy
and
again
a
couple
minutes
after
the
hour
we'll
get
started.
B
B
B
D
I'm
actually
I'm
at
later,
at
the
big,
this
miter
Workshop
thing
so
I'm
a
we'll,
follow
up
and
find
a
time
to
chat,
I'm,
always
happy
to
chat
with
you.
Craig
thank.
B
You,
sir
well,
it
is
three
after
the
hour.
I
would
like
to
welcome
everybody
to
the
January
25th
edition
of
the
vulnerability
disclosures
working
group.
I
posted
a
link
to
our
agenda
in
the
zoom
chat.
If
you
could
Mark
your
attendance
and
if
you
have
any
opens,
you
would
like
to
chat
about,
we
will
get
started,
as
is
tradition
with
all
of
our
working
groups.
We
would
like
to
allow
any
new
friends
to
the
group
to
introduce
themselves
and
say
hello.
Am
I
want
to
do
that.
E
My
name's
Dan
I'm
excited
to
join.
This
is
my
first
time
but
I'm
here
to
talk
a
little
bit
about
Vex.
If
folks
are
interested
I.
D
I'm
Alan
Friedman
from
Sissa
I'm,
the
guy
who
doesn't
shut
up
about
s-bomb
I
until
I
sort
of
dragged
art
in
to
do
a
lot
of
the
actual
work.
I
was
the
originator
of
Vex
and
super
excited
that
folks,
like
Dan,
are
picking
up
and
running
with
it
and
I
work
in
the
vulnerability
disclosure
wing
of
cisa.
So
we
kind
of
try
to
help
on
a
lot
of
the
space
awesome.
F
Sure
I'll
go
ahead.
If
that's
okay,
please
I'm
heart
I,
actually
work
for
the
Linux
Foundation
I
work
on
a
different
part
of
the
Linux
Foundation,
but
you
know
we're.
Obviously
you
know
I
work
mostly
on
the
hyperledger
foundation.
At
this
point.
Okay
and
we're
looking
at
you
know
rolling
out
some
kind
of
mandatory
vulnerability
disclosure
policy
for
all
of
our
projects,
so
so
I
thought
I'd
swing
by
and
you
know
hope
to
collaborate
with
you
all
welcome.
B
B
Thank
you,
Nathan
I
appreciate
it.
Everyone's
welcome
to
try
to
assist,
but
it's
just
it's
very
use.
I
was
stunned.
How
many
people
will
come
in
and
ask
me
questions
because
they
weren't
able
to
attend
the
call,
but
they
look
at
our
notes
and
the
video
call
and
they'll
follow
up.
So
it's
it's
important
for
those
that
can't
attend.
Thank
you
all
right.
B
If
you
have
any
opens,
please
add
them
to
the
open
section,
got
a
couple
points
of
business
to
talk
about
before
we
jump
into
our
main
conversation
today,
which
will
be
about
vex.
B
Firstly,
the
open
source,
cert
Sig.
We
submitted
our
plan
to
the
TAC
for
review
and
comments
and
hopefully
approval
and
then
moving
it
up
to
the
governing
board.
So
far,
the
TAC
has
successfully
avoided
adding
any
commentary
or
feedback
as
they
get
around
to
giving
us
feedback
on
the
OSS.
Cert
I
will
report
back
here
with
how
things
are
going
there.
B
All
right
and
then
any
of
you
that
are
so
inclined
we
will
be
kicking
off
a
were
we
spawning
off
a
new
instance
of
this
meeting.
The
last
Thursday
of
every
month,
we'll
be
doing
a
call
focused
in
for
APAC,
primarily
Australia
that'll
start
tomorrow.
B
Unfortunately,
I'm
told
that
tomorrow
is
a
national
holiday
in
Australia,
so
I
don't
think
we
have
a
lot
of
attendance,
but
it's
on
the
calendar
and
we're
going
to
get
started
so
we'll
be
better
engaging
with
those
folks
and
primarily
the
osv
folks
are
I
believe
located
in
Australia.
B
So
I
think
they
want
to
have
an
opportunity
to
engage
more
with
us,
so
keep
an
eye
out
you'll
be
able
to
watch
the
videos
for
those
calls
and
also
see
the
notes,
if
you're
not
able
to
stay
up
very
late
for
our
friends
in
Europe
and
that'll,
get
kicked
off
tomorrow
and
it'll
be
monthly.
Last
Thursday
of
the
month.
Any
questions
about
the
APAC
call.
B
It
will
be
6
p.m.
Eastern.
B
So
not
super
late
for
U.S
North,
East
Coast,
right
in
the
middle
of
the
day
for
Pacific,
but
that
gets
us
into
early
morning
for
our
friends
in
Australia.
B
All
right
again,
if
you
have
any
additional
opens
to
talk
about
after
our
main
course,
please
add
them
to
the
open
sections.
For
now.
I
will
yield
the
floor
to
our
friend
Dan
from
chain
guard.
Who
is
here
to
talk
about
some
efforts
around
a
technology
called
Vex
that
are
should
be
of
particular
interest
to
those
of
us
here
and
kind
of
talk
about
some
potential
collaboration
going
forward.
So
Dan
I
will
yield
the
floor
to
you,
sir.
E
Awesome,
thank
you
so
much
yeah.
So
this
is
my
first
time
here
so
I'm,
not
I,
don't
want
to
talk
up
or
down
to
folks
incorrectly
but
but
I
know.
A
lot
of
us
are
involved
in
the
vulnerability.
Space
are
most
folks
pretty
familiar
with
the
idea
of
X
or
what
a
quick
intro
be
helpful.
E
All
right
cool,
so
yeah,
basically,
a
lot
of
us
who
have
either
been
on
the
receiving
or
giving
end
of
vulnerability
scans
to
Dev
teams
have
seen
this
workflow,
where
it's
important,
that
support
is
not
vulnerable
or
is
minimally
vulnerable
or
not
showing
too
many
results
that
could
lead
to
liability
or
actual
exploitation.
And
today
a
lot
of
those
workflows
are
pretty
painful,
because
scanners
aren't
perfect
and
there
can
be
a
lot
of
false
positives.
E
In
particular,
I
have
been
on
both
ends
of
the
pain,
that's
associated
with
that
and
it
sucks
so
and
it
sucks
one
because
it's
just
spoil
some.
It
takes
a
lot
of
time
to
look
into
every
single
item
that
you
want
to
take
it
seriously.
If
someone's
saying
you're
shipping
vulnerable
software,
you
want
to
take
that
seriously
and
Patch
it
if
there's
something
to
patch,
but
sometimes
there's
not,
and
sometimes
there's
no
action
actually
needed,
and
so
that
workflow
can
take
time.
E
And,
of
course,
if
you
are
actually
vulnerable
to
something
like
at
the
end
of
the
list
and
you've
taken
time
to
get
there,
then
that's
no
good,
because
now
you're
you're,
it
would
be
great
if
you
didn't
have
to
be
exposed
for
that
long
and
so
today,
I
think
the
the
favorite
or
not
so
favorite
tools
for
for
solving
this
problem
are
things
like
spreadsheets,
where
you
can
say
hey
here:
here's
what
our
scanner
said.
We
were
fortunate
enough
to
be
able
to
export
it
as
CSV.
E
So
here
you
go
and
and
then
you
have
to
respond
back
on
the
spreadsheet
or
whatever
it
is,
and
so
the
whole
idea
with
with
Vex
and
and
Dr
Allen
can
correct
me
if
I've
messed
any
of
this
up.
But
but
the
general
idea
is:
wouldn't
it
be
great
if
there
was
a
machine
readable
way
to
encode
information
about
kind
of
an
assessment
of
the
scan
results,
so
you
can
say
in
terms
of
the
scan
results.
E
Some
of
these
are
not
accurate
or
or
they're
accurate
in
the
theoretical
sense,
where
they
don't
apply
to
the
situation
for
the
software
artifact,
because
X
reason,
or
why
reason,
and
so
this
idea
has
been
around
to
my
knowledge
for
at
least
a
couple
of
years
now
and
I
think
as
people
excited
but
also
I.
Think
a
lot
of
folks
are
hoping
this
will
take
off
like
this.
E
Will
this
will
finally
be
a
thing
that
folks
start
to
realize
to
benefit
from,
and
so
what
I'm
here
today
to
talk
about?
Is
this
thing
called
open
Vex,
which
is
a
a
new
thing
we're
about
to
to
launch
more
broadly,
but
it's
a
an
open
source,
Community
project
and
I'll
I'll
share
my
screen
and
show
some
stuff
in
a
second,
but
basically
the
idea
is
that
some
really
great
folks
have
come
together
recently
through
the
sizza
working
group
to
decide
what
really
should
Vex
be.
E
What
are
important
aspects
of
data
to
capture
in
this
like
creation
and
consumption
of
Vex
data
and
so
open
Vex
is
sort
of
the
idea
that
we
want
to
meet
those
those
those
standards
that
this
group
just
agreed
on,
and
we
want
to
do
so
in
a
minimal
way.
That's
that
has
the
best
chance
we
can.
We
can
think
of,
to
have
to
take
off
so
so
we
want
to
make
sure
that
there's
tooling
ready
to
go
for
it.
E
It's
easy
to
implement
on
if
you're
producing,
Vex
data,
you
have
a
great
time
with
it.
If
you're
consuming
a
Vex
data,
you
have
a
great
time
with
it.
That's
really
the
whole
idea
of
the
openvex
spec
is
something
that's
really
quickly
to
really
quick
to
implement
something
that
makes
sense
to
people,
something
that
does
the
job
and
does
does.
You
know
gives
us
a
fighting
chance
of
producing
more
accurate
net
effects
of
vulnerability
scanning,
so
I'll
pause
there.
D
So
excuse
me:
Dan
can
I
jump
in
just
for
a
little
bit
from
Sis's
perspective
on
this,
because
I
one
I
think
openvex
is
is
a
fun
idea.
D
One
of
the
things
sisa
has
been
aligned
with
something
called
csaf
the
common
skit
advisory
framework.
It
is
much
clergier
than
the
lightweight
thing
that
Dan
is
proposing,
but
I
do
want
to
flag
the
common
security
advisory
framework
as
part
of
a
bigger
vulnerability
model
where
we're
trying
to
get
organizations
that
release
security
advisories
to
do
so
in
a
goddamn,
it's
2023.
D
How
are
all
this
stuff,
still
human
readables,
and
so
that
is
the
I
totally
acknowledge
that
csaf
has
real
usability
issues
and
even
the
tooling,
for
it
is
wildly
mature,
but
that
is
sort
of
where
sort
of
in
the
ecosystem
landscape.
What's
it
out
there
today
and
I.
Think
Dan's
gonna
do
a
great
job
of
explaining
why,
right
from
a
just
a
Vex
perspective,
not
a
security
advisory
perspective,
open
open
effects
would
be
good.
So
sorry,
I
just
wanted
to
give
that
context
of
what
else
is
out
there.
Yeah.
E
No,
that's
totally
fair.
That
was
good
to
call
I,
don't
want
to
admit
what
else
is
out
there.
Openvx
is
not
the
first
game
in
town,
but
but
I
want
to
kind
of
talk
about
yeah
what
it
is
and
what
we
think
is
different
about
it.
So
I
appreciate
that
cool.
Let
me
share
my
screen
here.
H
Additional
information
that
would
at
least
just
be
helpful
for
me,
because
I've
been
in
lots
of
these
sorts
of
conversations,
is
it's
helpful
to
know
to
who
is
using
this
or
how
they
intend
to
use
it.
So
if
you
can
share
any
of
that
for
for
anything,
Vex
related
or
even
CSF
related,
that's
also
just
helpful
context
to
have.
A
Yeah
I'll
add
my
two
cents
and
say
well
I'm
curious
about
it's:
how
how
what
how
the
engine
makes
a
determination
about
what's
exploitable
versus
you
know
about
the
likelihood
or
the
impact
or
what's
exploitable
and
given
those
parameters
that
you
outlined,
what
makes
it
different
than
something
like
HP
web
inspect
when
it
comes
to
doing
wasses
or
or
you
know,
API
scan
when
it
comes
to,
like
you
know
what
me
and
you
you'll
pump
out
vulnerabilities
and
yeah.
A
D
D
We
use
the
language
of
affected
right
if
you
want
to
start
a
fight,
a
black
hat,
just
sort
of
saying:
what's
the
definition
of
exploitable
right,
and
so
we
use
the
term
affected,
which
is:
does
the
downstream
user
have
to
do
literally
anything
and
and
that
sort
of
the
the
boundary
Mark?
So
even
if
it's
check
a
config
hey
when
we
told
when
we
sold
you
this,
we
told
you
not
to
plug
this
into
the
internet.
You
weren't
an
idiot
were
you
that
still
counts
as
being
affected
by
a
vulnerability.
A
No
I
mean
no,
that
that's
that's.
You
gave
a
you,
gave
a
perfect
thing
and
I've
been
involved
in
those
conversations
when
somebody
says
what
does
it
mean
to
be
exploited,
I've
been
involved
in
those
conversations,
I
mean
I,
just
grabbed
popcorn
I
stopped
talking,
I
grabbed
popcorn,
those
conversations
getting
energetic
the
other
thing,
the
other
I
guess
red
herring,
chat,
GPT
I'll
leave
that
on
the
floor
right.
A
So
you
take
the
next
taking
that
information,
somebody
pops
it
into
some
some
type
of
AI
engine
and
then
now
what
right,
I
I
don't
know
I'm,
leaving
that
on
the
floor,
because
that's
the
big
conversation
today
right
so
taking
that
information
popping
in
ask
a
question
see
what
happens
see
what
Falls
up
right.
Those
are
just
things
I'm
curious
about
as
I
as
I
hear
as
I
hear
Dan
talk,
because
I
think
this
is
exciting.
A
You
know
exactly
what
we
need
automation-wise,
but
I
want
to
make
sure
that
we're
not
taking
one
thing,
creating
something
else
that
does
similar
things
to
what
those
things
do
over
there.
Now
we
have
another
tool
that
we
have
to
interpret
and
can
only
verify
through
more
work.
E
I
think
those
are
fair
points
and
I'll
walk
through
what
we
have
going
on
in
concrete
implementation,
and
then
we
can
talk
to
like
do.
We
think
that
we'll
address
this
or
not
yes,
I
had
to
I
had
to
drop
in
and
launch
back
because
of
the
rookie
mistake
of
opening
Zoom
for
the
first
time
without
the
Mac
OS
permission,
so
I
am
now
I've
learned
that
for
the
15th
time
now
so
here
we
go.
E
All
right,
can
you
all
see
all
right,
great,
so
yeah,
so
this
is
basically
what
we
have
so
far
like
I
said
this
is
just
about
to
launch
we're,
putting
it
together,
but
we're
we're
starting
out
in
the
open
too.
So
this
is
the
this
is
its
own
GitHub
work.
So
this
is
a
thing
our
work
for
chain
guard,
but
the
idea
with
open
Vex
is
it's
not
a
chain
guard
own
thing?
It's
a
thing!
E
That's
a
a
joint
venture
with
folks
that
are
interested
in
helping
us
with
this
experiment
of
a
way
to
make
the
ex
popular
to
Allen's
Point.
Not
the
first
attempt
at
this,
but
I
think
that
there
are
some
unique
traits
of
how
we're
doing
this.
That
I
think
will
be
appealing
and
and
give
it
a
new
Edge.
So
I
want
to
talk
to
you
what
those
are
so
if
you're
interested
the
first
thing
is,
is
if
you
want
to
follow
along.
This
is
github.com,
openvex
and
you'll.
E
See
this
the
other
exciting
things
we're
already
starting
to
see,
support
from
other
organizations,
so
I
think
just
12
hours
ago
we
merged
a
PR
that
adds
more
maintainers
to
the
group.
So
we
now
have
five
folks
that
are
behind
this
myself
in
chain
guard.
E
My
colleague
puerco
from
chain
guard
Brandon
long,
who
I
think
is
on
the
call
Alex
Goodman
from
Angkor
and
wrote
a
stretch
from
VMware,
so
we're
pretty
excited
to
kind
of
get
this
off
the
ground
and
really
start
sharing
this
more
broadly
from
the
get-go
I.
E
Think
a
lot
of
good
will
come
from
that,
because
it's
it's
important
that
this
is
just
not
you
know
not
just
solving
one
Niche
use
case
and
then
the
last
thing
I'll
show
GitHub
wise
is
just
kind
of
what
what
is
open,
Vex
Beyond,
just
a
a
folder
with
projects
in
it.
So
the
actual
project
so
far
are
really
centered
around
a
few
things.
So
number
one.
E
It's
a
specification
so
there's
an
actual
definition
of
how
to
take
the
minimum
requirements
from
the
the
sisa
group
and
encode
those
and,
in
our
case
it's
in
Json.
So
you
can
look
at
this
Json
spec
and
see
exactly
what
what
we
mean
by
Fields.
A
lot
of
this
is
directly
informed
from
that
working
group,
but
you'll
be
able
to
see.
E
Let's
see
if
we
go
here,
you'll
be
able
to
see
a
more
verbose
explanation
of
what
each
piece
of
the
spec
looks
like,
and
here's
also
an
example
right
off
the
bat
of
how
minimal
we
mean
by
minimal
so
to
get
this
Vex
conversation
started
to
Allen's
point:
it's
it's
a
this
is
a
communication
exchange
mechanism,
we're
talking
about
Json
objects
that
look
like
this,
so
just
to
give
it
a
concrete
picture.
E
E
That's
the
language
that's
used,
and
so
there's
kind
of
a
tuple,
so
to
speak
of
three
things:
there's
the
vulnerability,
there's
the
actual
package
or
component
or
container
image
or
whatever
it
is
that
you're
commenting
on
and
then
you're
saying
is
it
are,
do
these
things
go
together
or
not
and
and
the
intent
is
that
you
take
this
information
and
then
overlay
it
on
top
of
other
information
like
like
vulnerability
scans
in
particular,
so
you
can,
you
might
have
a
vulnerability
scan
that
did
a
broad
spectrum
hit
against
a
container
image
and
it
says
you
have
75
000
vulnerabilities.
E
The
idea
is
that
you
can
start
to
take
information
like
this
and
say:
well,
we
looked
at
specific
ones
already
and
we've
concluded
that
these
do
not
apply,
and
the
idea
is
that,
if
you,
if
you,
if
you
put
these
together,
you
can
then
produce
incrementally
better
net
effects
for
humans
to
look
at
where
they're
they're,
seeing
some
of
these
that
have
already
been
investigated,
removed
from
the
data
set,
and
you
can
also
go
the
other
way.
E
You
can
say:
hey,
there's
a
unique
situation
here,
that
scanners
missed
and,
and
they
need
to
be
supplemented
with
more
information.
You
can.
You
can
go
both
ways
here
and
the
reason
is
because
there's
there's
this
status
field,
so
there's
four
possible
Vex
statuses
that
we'll
see
there's
affected
not
affected,
fixed
and
then
under
investigation.
E
So
this
is
the
the
basic
look
of
it
like
I,
said:
here's
the
spec,
if
you're
interested
in
terms
of
what
else
open
Vex
is
besides
the
spec
there's
the
beginnings
of
of
the
tooling
that's
going
to
make
the
spec
more
than
just
an
idea.
So
we
have.
We
started
out
with
a
a
go
implementation.
E
A
lot
of
a
lot
of
the
projects
in
our
space
in
particular,
are
are
using
go,
and
so
we
wanted
to
really
make
sure
it
was
easy
to
start
somewhere
and
go
seem
like
a
reasonable
first
spot,
a
reasonable
ecosystem
to
start
with.
So
we
have
a
library
where
it's
very
easy
to
to
produce
Vex
documents
and
then
to
also
parsevex
documents
from
someone
else
and
start
making
sense
and
applying
them
to
your
workflow.
E
That's
just
the
library,
though,
what
we
also
have
is
this
kind
of
Flagship
tool
called
vexctl?
We
we
love
ctl's,
I,
think
anyway,
so
so
the
idea
here
and
I'll
demo
this,
but
the
idea
here
is
you-
can
use
vexctl
to
quickly
get
up
and
running
with
next,
with
with
openvx
in
particular,
but
also
the
intent
is.
E
You
can
also
ingest
other
existing
Vex
formats
as
well
and
operate
with
those,
so
we
have
commands
to
create
Vex
documents
to
merge
Vex
documents
and
then
to
the
big
one.
That's
that's
of
interest
is
to
filter
out
existing
scans
with
effects
documents,
so
two
short
demos
and
then
I'll
shut
up.
So
we
have
Vex
CTL.
E
Here's
an
example,
so
this
is
a
a
Vex
document
that
that
I've
created
is
actually
real.
In
a
sense,
this
is
commenting
on
real,
false
positives
that
were
produced
by,
in
this
case,
great
we're
a
container
image
and
there's
a
there's,
a
pretty
common,
false
positive
that
gets
produced
where
there's
there
are
vulnerabilities
reported
for
protobuf
the
spec,
the
specification
that
are
flagged
against
protobuf,
the
actual
like
code
implementation
and
it
that
does
not
go
together.
So
here's
what
Vex
lets
you
do.
E
We
we
get
to
say:
okay,
there's
two
vulnerabilities
in
particular
that
have
to
do
with
this
false
positive,
the
CBE
and
this
cve,
and
we're
going
to
make
two
statements
that
we
intend
to
apply
to
the
scan
results
and
I'll
show
you
that
in
a
second,
but
we're
saying
that
this
package
is
actually
not
affected,
and
so
this
seems
simple,
but
the
sense
of
being
pretty
powerful.
E
When
you
can
do
this
in
mass,
and
so
you
can
start
to
accumulate
this
of
X
information
for
artifacts
that
you're
continually
shipping
or
continually
iterating
on,
and
you
get
to
use
Vex
to
encode.
This
knowledge
that
you've
that
you
gain
from
investigation
work
from
humans
really
looking
at
that.
What
goes
and
what
doesn't
go
and
the
benefit
is
that
Downstream
consumers
can
now
if
they
choose
to
trust
this
data
and
use
it
to
get
a
leg
up
on
their
voluntary
action
process.
E
So
this
is
in
Sarah
format.
This
is
gripe
output
for
for
a
scan
of
a
Prometheus
container
image.
So
let
me
show
you
really
quick.
E
So
this
is
this:
is
the
Prometheus
Prometheus
serif
report
I'm
going
to
run
some
JQ
on
it,
just
because
serif
can
be
a
little
verbose,
but
we're
going
to
get
the
count
of
results?
Kind
of
loan
findings
that
this
report
has
I'm
happy
to
show
you
the
full
data
if
you're
interested,
but
so
basically
there
are.
There
are
four
loan
findings
and
the
reason
is:
there's
two
vulnerabilities
and
there's
two
components
that
are
reported
purported
to
have
that
vulnerability.
E
So
two
times
two
is
four
and
then
you
can
also
run
vexctl.
So
this
is
a
one
of
the
Vex
CTO
sub
commands
called
filter
where
we
can
take
a
vulnerability,
scan,
specify
a
Vex
document
to
apply
to
it.
I'm
heading
logging
just
for
fun,
and
then
we
can
look
at
the
same
JQ
query
to
see
what
it
returns
and
it
returns
zero.
So
it's
filtered
out.
E
I
know,
isn't
that
amazing,
four
minus
four
is
zero
and
and
what
is
outputting
just
to
be
clear
if
we're,
if
we
hide
that
sort
of
JQ
part
of
the
pipe,
it's
outputting
a
transformed
version
of
the
original
scan
report.
So
if
you're
using
the
idea
is
if
you're
using
serif
and
you
need
serif
Downstream
we
operate
on,
you
know
seraphin
serif
out,
it's
just.
It's
been
modified
in
consideration
of
the
Vex
data
that
you've
decided
to
trust.
E
One
of
the
things
that
we're
looking
to
do
soon
is
out
of
support
for
more
scanner
format,
so
working
on
Grape
right
now,
for
example,
gripe
has
a
native
implementation.
That's
pretty
rich
we'd
like
to
do
the
same
for
charity
Etc.
E
The
other
thing
I
wanted
to
show
is:
we
have
a
edge
anger.
We
have
a
Linux
distribution
called
Wolfie
that
we're
pretty
excited
about
and
what
we've
started
doing
to
kind
of
show
that
Vex
can
work
end
to
end
is
we
have
Vex
data
being
published
for
our
wolfy
packages
and
that
flows
Downstream
into
other
ways
that
you
put
those
packages
together
like
container
images
in
our
case?
E
So
here
is
the
repo
behind
Wolfie,
and
so
this
is
the
get
package,
the
the
actual
way
that
we
should
we
package
up.
Git,
that's
a
lot
of
artifact
and
what
we've
decided
to
do
is
inform
our
advisory
format
with
Vex.
The
idea
of
Vex
we
want
to
be
able
to
have
yeah,
we
want
to
make
sure
we
can
really
easily
produce
Vex
data,
and
we
realize
it
made
sense
if
there's
a
if
there's
a
really
great
way
to
describe
effective
statuses.
E
We
can
do
that
over
time,
which
is
one
of
the
nice
things
that
the
new
Vex
minimum
requirements
outline.
E
We
can
end
up
using
that
pretty
directly
in
our
advisory
format,
and
so
with
this
we
can
produce
advisory
data,
but
we
can
also
produce
the
Vex
data
when
we
need
to
and
we
can
layer
on
other
Downstream
information
from
artifacts,
as
we
put
them
together
in,
like
I,
said
container
images
and
whatnot,
and
we
can
end
up
with
this
kind
of
Rich
evolving
data
set
of
Vex
data,
and
so
here
we're
saying
that
we
fixed
a
thing.
E
But
we
can
also
translate
that
if,
when
we
need
to
into
excuse
me
I
have
a
a
through
issue
to
the
Apparently
you.
We
can
encode,
that
in
Vex
and
and
directly
translate
these
into
the
same
kind
of
information
that
X
encodes
so,
and
so
we
have.
This
is
just
the
the
config
format.
This
format
doesn't
matter,
but
this
is
how
we,
how
we
package
up
git,
we
have
I,
said
I,
said
we
like
ctls.
E
We
have
a
Wolfie
CTL,
we're
pretty
serious
about
our
ctOS,
and
so
we
can
use
what
VCT
to
create
Vex
documents
from
our
package
config.
So
we
can
take
this
package
I'll
pass
it.
This
format
and
here
you'll,
see
again
of
X
document.
So
we
can
see
we
can
issue
Vex
documents
and
we
can
update
Vex
documents
as
we
learn
more
about
the
vulnerability,
effective
statuses
for
this
package,
whether
it's
fixed
or
not,
affected
in
the
first
place
Etc
and
produces
of
X
data.
E
Now
let
me
stop
there.
That's
those!
Those
are
the
main
points.
I
see,
there's
stuff
in
the
chat
and
yeah.
Maybe
I
could
take
questions
now.
I
Yeah
I
have
a
question
Dan,
so
I'm
just
trying
to
I'm
reading
through
the
readme
on
the
website,
and
you
know
it
says
why
not
csaf
or
cyclone,
and
it
says
it's
because
there's
gaps,
it
doesn't
say
what
the
gaps
are
I'm
just
trying
to
figure
out.
I
I
Whatever
those
gaps
are
why
not
just
work
to
fix
them
versus
make
a
brand
new
thing?
That
looks
honestly
less
comprehensive
to
me
at
first
blush
I'm,
just
trying
to
figure
out
what
the
goal
is.
E
Yeah,
so
that's
a
great
question:
I
I
too,
have
thought
of
the
same.
Xkcd
I
think
it's
it's
it's
a
it's
a
common
problem.
E
My
answer
to
that
I
don't
want
to
the
good
work
has
been
done
in
the
backspace
and
my
attempts
not
to
to
rag
on
any
other
Vex
effects
or
anything
like
that.
But
I
think
one
of
the
things
that's
difficult
to
patch
for
after
the
fact
is
minimalism
and
to
me,
that's
actually
a
pretty
important
trait
to
what
we're
doing
here.
E
The
idea
here,
some
some
Vex
Implement
implementations,
for
example,
are
tightly
coupled
to
like
an
s-bomb
format
or
something
like
that
where,
if
you
want
to
start
speaking
the
language
about
vulnerability,
effective
statuses,
you
need
to
kind
of
play
into
an
existing
ecosystem
with
other
specs
and
one
of
the
goals
here
is
that
yes,
there's
a
lot
more
to
say
about
vulnerabilities
and
software
composition.
E
We
want
to
just
comment
on
what
we're
commenting
on
here
and
when
you,
when
you
need
more
context,
and
you
often
do
to
to
do
effective
triaging,
we
can
then
say
that's
explicitly
delineated
out
of
the
scope
of
openvx
and
into
Cyclone,
DX
or
spdx,
or
something
like
that
or
on
the
other
side,
onto
a
vulner
report
format.
E
So
I
think
the
short
answer
is
we're
looking
to
get
something.
Oh,
the
other
thing
you
asked
was:
why
do
something
new
I
think
it's
really
important
to
us
that
Vex
becomes
more
ubiquitous
than
it
is
right
now,
and
so
because
of
that
alone,
we
want
to
try
something
intentionally
different
in
an
educated
way,
but
we
want
to
try
something
new
that
we
think
has
a
decent
shot
of
taking
off.
E
So
that's
the
overall
goal,
I
think
the
other
thing
I'll
say
is
I
think
we
could
do
a
better
job
on
the
readme
explaining
some
of
the
intent
here.
I
think
we
will
be
iterating
a
lot
in
the
coming
weeks
and
even
days.
This
is
just
something
that
we
haven't
even
fully
broadcast
yet.
B
D
If
art
wants
to
speak
directly
to
the
spec
I'll,
let
him
talk
to
that.
You
first
Alan,
so
continuing
on
the
line
of
multiple
implementations.
D
I
think
one
of
the
original
reasons
why
we
were
excited
about
implementing
this
is
esap
is
because
it
fit
in
with
the
product
security
team
model
and
often
commercial,
but
not
necessarily,
but
sort
of
a
mature
piece
approach.
They're
going
to
be
doing
these
notices,
so,
let's
slot
it
in
there
Cyclone
DX
among
friends,
I
think
said:
oh,
this
is
a
thing.
That's
related
to
s-bomb,
so
we'll
implement
this
as
well.
D
Sis's
position
is
vulnerability.
Information
should
not
be
tightly
coupled
with
s-bomb
data
at
all
because
vulnerability
data
changes
s-bombs
static
software,
but
they
want
to
implement
it.
That's
fine
Dan
I'm
curious,
as
you
sort
of
think
of
the
user
base
for
this
and
obviously
I
know
chain
guard
specializes
in
Cloud
native
security.
Can
you
talk
a
little
about
how
you
imagine
people
using
vexes
in
in
sort
of
the
corner
of
the
ecosystem
that
you
guys
are
leaders
in.
E
Sure
my
goal
is
for
it
to
be
transparent
and
so
and
I
mean
that
in
two
ways,
I
think
two
senses
of
the
word.
One
example
is
that
I
showed
just
now
vexctl
as
a
command
to
do
the
filtering,
for
you
I
think
that's
a
great
way
to
show
the
concept,
but
not
a
great
user
experience.
E
To
be
honest,
I
think
what
I'd
love
to
see
eventually
is
that,
for
example,
vulnerability
scanners
themselves
are
Vex
aware,
and
so
now
that
they're
operating
on
on
both
doing
their
thing,
which
is
to
find
vulnerabilities.
You
know
taking
software
composition
and
cross-examining
that
with
vulner
data
feeds,
but
also
now
informed
by
another
another
kind
of
line
at
him
in
The
Ledger,
which
is
that
what
what
does
investigation
into
these?
E
The
specific
pairing
of
vulnerabilities
and
software
effects
led
to
in
terms
of
conclusions,
we're
already
talking
with
the
gripe
team
about
implementing
this
they're
excited
about
it
they're
on
board.
We
hope
that
that
spreads,
but
I
think
what
the
average
user
I
would
hope.
What
they're
going
to
see
over
time
is
cleaner,
more
accurate,
I
should
say
vulnerability
reports.
E
The
idea
is
that
people
can
focus
on
things
that
are
actually
exploitable
or
or
I
could
say
more
minimally
like
are
not
known
to
not
be
exploitable
by
someone
who's
looked
into
it
and
so
that
they're
able
to
pay,
see
cleaner
results
and
spend
time
on
the
more
impactful
things
sooner,
but
also
B
inspect
what
just
happened
if
they
need
to.
If
they're,
seeing
vulner
reports.
E
Or
something
like
that,
there
should
be
a
clear
trail
of
auditability
in
terms
of.
Why
was
you
know?
Why
was
the
claim
made
that
something
was
not
vulnerable?
Who
made
the
claim?
When
did
they
make
the
claim?
Is
there?
Is
there
a
history?
I
can
start
to
see
about
new
knowledge
coming
into
the
to
the
system,
so
I
think
those
are.
Those
are
the
maybe
two
points.
I
would
I
would
add.
I,
don't
know
if
that
fully
answers.
Your
question.
E
C
Thanks
probe,
first
brief
apology:
Dan
I
could
not
restrain
myself
and
was
typing
stuff
in
the
chat.
While
you
were
speaking
so
I
I
tried
really
hard
to
wait
till
you
were
done,
but
I
do
apologize,
I
didn't
see
it.
I
still
haven't
I
know,
I
know,
but
it
you
know
it
detract
it's
sorry.
It's
a
dumb
thing,
but
I
I
voice
in
my
head
said
art
weight
in
it.
I
didn't
so
anyway,
let's
see
so
yes,
the
xkcd
issue.
You
know
we're
only
at
four
or
five,
not
twenty.
C
So
that's,
maybe
a
good
thing.
So
I'll
mentioned
this
I've
been
I,
guess
I'll
say
lead
editor
of
the
CIS
of
X
minimum
elements,
minimum
requirement
stock,
which
is
array
nearly
finished.
C
One
of
the
interesting
factors
in
the
experience
has
been
that
we've
got
right.
We've
got.
We
have
a
couple
of
sort
of
active
implementations.
We
have
some
existing
documentation,
we're
writing
sort
of
an
almost
spec
based
on
that.
C
C
A
huge
piece
of
me
really
likes
the
idea
of
a
clean,
minimalist,
fresh
implementation,
focusing
on
the
bare
minimum
I'm
I'm,
not
truly
a
software
developer
really
but
I've
seen
a
lot
of
it
and
right
small,
specific
things
that
work
with
other
things,
you
know,
sort
of
unix-ish
old
school
philosophy
seems
to
be
a
reasonably
good
idea.
C
Jason
to
your
to
your
comment
in
the
chat
right
about
closing
the
gaps,
the
the
sister
Community
Vex
stock
worked
very
very
closely
with
csaf
and
CDX.
We
had
a
person
from
csaf
on
every
call
very
very
closely.
Working
I
am
95,
convinced
that
the
system
minimum
requirement
stock
does
align
with
the
current
implementations.
It's
not
a
one
for
one.
You
know
the
Json
looks
exactly
like
the
sysa
doc.
It's
not
that
close
of
a
match.
C
We
explain
that
if
you
can
derive
or
Assemble
valid
Vex
from
another
system,
that's
that
counts
as
well.
Also
about
you
know,
converging
closing
those
gaps.
C
It's
entirely
reasonable
and
possible
that
you
know
the
current
ones:
Cyclone
DX
and
csaf
May.
They
update
their
themselves
to
to
match
the
sysa
doc.
I,
don't
know
that
yet
I
don't
know
what
the
best
option
is.
C
I
think
that's
a
phase
in
the
development
that
we're
in
and
write
the
code
that
is
actually
being
used
is
what's
going
to
win
out.
So
it's
also
possible
in
theory
that
the
this
is
a
minimum
requirement
stock.
Should
somebody
want
to
would
get
revved
or
replaced
or
Rewritten?
You
know
in
a
year
or
two
when,
when
Vex
implementations
have
sorted
out
what
actually
works
and
gets
used,
so
we're
we're
in
this
development
phase.
C
E
Damn
yeah
I
think
another
thing
I
wanted
to
point
out:
I
I
really
appreciated
how
those
discussions
went
with
with
the
csaf
folks
and
Cyclone
DX,
folks
and
other
folks
on
the
call
and
one
of
the
things
that
I
think
was
clear
to
to
most
of
us
was
we
have
a
bunch
of
smart
people
in
the
room
right
now
trying
to
figure
out
what's
going
to
be
best
for
the
industry
as
a
whole,
and
you
can
do
some
of
that
through
talking
about
the
specs
and
leaning
on
existing
experience
Hands-On,
but
a
lot
of
it,
especially
when
you're
talking
about
changes
that
you
would
make
that
happen
by
definition
been
enacted.
E
Yet
it
gets
really
hard
to
conceive
of
and
I
think.
One
of
the
things
that
we're
hoping
to
do
is
is
try
things
and
iterate,
and
if
and
it
could
be,
that
openvx
doesn't
win
out
just
to
say
and
I
think
that's,
okay,
I
think
the
goal
is
for
us
to
learn
how.
How
can
we
work
to
Dr
Allen's
Point
differently
than
we
did?
E
You
know
a
decade
ago
or
two
decades
ago,
and
if
we're
able
to
learn
more
about
what
models
or
and
even
down
into
the
Weeds,
about
different
aspects
of
the
spec,
if
things
are
working
or
not
working
I
think
we're
really
excited
to
learn
those
those
learn
that
wisdom
and
then
apply
it.
B
And
I
would
present
to
the
group
in
the
theater
of
the
minds.
B
B
And
then,
potentially
eventually,
maybe
that
process
Auto
magically
integrates
with
things
like
csaf
or
s-bombs.
So
just
thinking
about
that
this
is
potentially
could
be.
Something
very
valuable
makes
it
ideally
very
frictionless
for
maintainers
and
potentially
adds
a
lot
of
value
for
Downstream
consumers
that
they
get
this
information
from
the
source
they're
able
to
make
their
own
evaluations
on
things
they're
choosing
to
incorporate
in
their
own
work.
B
B
I
B
But
yeah,
so
what
additional
comments
do
we
have
for
Dan
the
openvex
tool?
I?
Normally,
no
kids,
no
animals,
no
live
demos.
I
thought
it
worked
very
well.
E
B
Yeah,
our
mission
here
is
to
help
improve
vulnerability,
disclosure
practices
and
help
get
vulnerability,
information
into
the
hands
of
maintainers
and
consumers.
You
know:
do
we
think
this
work
kind
of
aligns
with
our
goals?
Is
it
something
we
would
like
to
potentially
contribute
to
participate
in.
H
So
I
love
the
idea
of
that,
but
in
my
position,
I
get
requests
like
this
fairly
often
to
support
every
new
vulnerability
format
that
exists.
So
from
my
perspective,
I
would
find
it
very
helpful
to
understand
more
about
how
the
different
formats
are
related
and
the
different
use
cases
for
each,
because
my
team,
at
least
I
think
sits
an
interesting
place.
So
our
use
case
also
might
not
be
the
most
normal
one.
H
But
a
lot
of
this
information
in
a
lot
of
the
vulnerability
formats
I've
seen
seem
to
be
most
useful
for
incident
response
teams
and
maintainers
that
are
responding
to
to
a
security
incident
right.
So
if
I
am
managing
a
vulnerability
database
that
can
be
used
by
any
number
of
people
in
any
number
of
Industries
if
I
was
to
support
one
or
two
formats
like
what
would
be
the
most
useful
in
that
case,
which
I
don't
expect
an
answer
to
that
question.
That's
just
something
I'm
thinking
about.
D
So
let
me
share
just
a
moment
about
why
Vex
and
then
we
can
talk
about
it
because
I
think
one
of
the
easiest
things
maybe
to
say
for
your
use
case.
You
should
just
process
vexes
and
keep
them
in
the
database
rather
than
sort
of
try
to
keep
the
live
feeds.
So
the
the
impetus
behind
this
is
not
a
new
idea,
but
the
impetus
behind
this
was
to
say,
as
s-bombers
become
more
common.
D
It's
a
real
risk,
especially
for
a
lot
of
this
frankly,
was
driven
by
commercial
pieces
and
says:
hey
we're
shipping
code
that
we
know
has
a
known
vulnerability
against
it
and
it
isn't
a
priority
for
us
to
fix
it
because
it
doesn't
affect
our
product,
and
so
we
want
we're
getting.
If
we
ship
s-bombs
we're
going
to
get
calls
from
customers
saying
it
says
that
you
have
openssl.
D
So
we
want
you
to
fix
it
because
we're
worried
about
heart
bleed
and
if
you're,
only
using
the
prng
and
your
compiler
strips
out
everything
else,
then
it's
not
a
risk,
and
so
the
the
vision
was
to
sort
of
say:
hey,
let's,
let's
automate
the
ability
to
so
s-bomb
turns
on
warning
lights.
Vex
turns
them
off.
D
If
you
trust
who
said
it
Etc,
and
so
what
we
haven't
thought
through
is
is
sort
of
the
this
is
the
gap
for
Xbox.
Is
the
plumbing
piece
right?
How
do
we
take
all
this
data?
That's
coming
in
and
align
it
and
write
again.
Imagine
a
commercial
story
for
on-prem
software.
Well,
I've
got
my
s-bomb
and
I've
got
my
bone
management
tool.
The
best
mom
should
feed
in
for
the
story.
D
Madison
that
I
heard
from
you
Vex
almost
seems
like
an
input
that
you
could
take
whatever's
coming
in
in
any
format,
because
again,
I
think
it
makes
sense
that
this
is
it's
all
pretty
parsable
and
then
update
your
database
accordingly
about
what
you
care
about.
D
H
Yeah
yeah,
no
and
I
definitely
appreciate
that
and
I'm
fully
cognizant.
That
I
probably
have
a
slightly
more
unique
use
case
with
what
my
team
is
doing,
but
we
are
especially
because
we
are
very,
very
focused
on
open
source.
What
I
have
at
least
noticed
is
that
many
of
these
specifications
are
more
focused
on
the
commercial
end
and
aren't
always
the
most
applicable
to
open
source,
not
that
this
seems
like
it
is
by
any
means,
but
that
is
that
is
something
that
I
can
I.
H
Consider
a
lot
so
for,
at
least
at
the
moment,
we're
huge
fans
of
osv
and
that's
what
we
have
been
exporting
in
I'm
I
am
personally
not
at
all
opposed
to
exporting
in
other
formats
right
if
it
were
left
up
to
me,
I'd
export
in
every
format.
So
it
was
useful
for
anybody
that
wanted
to
use
it
under
any
circumstances,
but
I
definitely
cannot
get
that
buy-in
from
my
engineering
team.
So.
B
Fun
fact
osv
is
related
to
this
working
group
and
ideally,
as
the
Apec
meetings
come
online,
we'll
be
able
to
more
directly
talk
with
you
as
we
folks
so
there's
opportunity
that
if
something
like
this
was
of
interest
to
the
group,
we
could
definitely
Supply
that
connective
tissue
between
the
different
groups
cross
collaborate
Jay.
You
have
your
hand
up.
A
Oh
there
we
go
all
right,
yeah
yeah,
so
so
I
think
this
is
a
link
to
the
tool
itself.
I
think
the
tool
can
be
like,
as
we're
doing
here,
discuss
I,
think
the
I
think
conceptually
and
I
think
building
out
that
concept
across
the
broader.
How
you
know.
How
can
we
further
build
this
to
help
the
community
to
help
organizations
at
large
I
think
that
conversation
needs
to
be
brought
into
this
working
group?
Maybe
in
the
there
I
shrug
my
shows
and
their
essay
in
the
form
of
the
sink.
A
The
further
you
know
understand
the
different
tools
that
are
out
there,
how
those
tools
can
can
work
together,
what
the
bridges
are
between
those
and
and
this
conversation
itself
can
be
expanded
across
all
of
all
of
the
different
organizations
that
are
impacted
as
a
result,
I
think
that
would
be
outstanding.
A
I,
don't
know
about
a
one,
a
one
tool
to
to
discuss
to
discuss
with
that
versus
what
are
the
tools
out
there
and
let's
decide
on
if
it
is
bring
in
like
a
couple
of
tools,
decide
on
that
and
then
how
can
we
contribute
as
a
a
Sig
or
working
group
to
build
that
out
to
like
to
something
that
can
be
used?
Universal
right
so
yeah
that
that
I'll
link
I'll
end
there
yeah.
B
As
we
near
the
top
of
the
hour
I
think
this
has
been
an
excellent
conversation.
I
really
appreciate.
Dan
coming
and
sharing.
This
I
personally
feel
very
strongly
that
Vex
could
be
very
powerful
tool
to
share
information
with
maintainers
and
consumers.
I
would
like
to.
We
have
a
couple
opens.
We
want
to
get
addressed
before
the
end
of
the
hour,
so,
let's
Dan
would
you
be
able
to
maybe
come
back
in
two
weeks
to
continue
this
conversation
with
us,
I.
B
That'd
be
great,
and
then
we
can
kind
of
pick
this
back
up
kind
of
maybe
mull
over
some
more
educated
questions
as
we
go
along
and
maybe
get
down
to
rolling
up
our
sleeves
and
collaborating
a
little
bit.
Yes,
sir,
and.
E
I
just
want
one
of
the
one
of
the
I
wanted
to
quickly
respond
to
Jay
too,
because
I
think
one
of
the
you
know
in
terms
of
how
can
this
group
help
I
think
I
just
want
to
call
out
the
critique
I
think
of
what's
going
and
what
is
likely
to
work
or
not
work.
That's
going
to
help
us,
especially
now
that
we're
so
early
in
the
spec
when
things
are
malleable
and
we
can
respond
to
feedback.
E
So
I
I
just
really
appreciate
this
group's
Keen
Eye
for
like
what
are
things
that
are
important
to
the
vulner
community,
so
that,
among
other
things,
potentially
that's
one
thing
that
I
would
really
value
from
this
group.
Awesome.
B
Excellent,
so
if
you
have
any
feedback
for
Dan,
Dan
I
would
invite
you
to
hop
on
our
slack
so
that
we
can
at
you
be
very
exciting.
We
also
have
mailing
list,
and
ideally
we
have
your
contact
information
in
the
agenda.
So
again
we
can
reach
out
there,
but
let's
keep
the
conversation
open
and
transparent
Jonathan.
You
had
a
open.
You
wanted
to
talk
to
as
we
wind
down
the
hour.
Yes,.
G
First,
open
is
I
have
discussed
with
a
couple
different
people.
I
would
like
to
potentially
create
a
sub-working
group
of
this
working
group
focused
on
the
topic
of
automated
vulnerability,
fixing
at
scale
in
particular,
there's
a
bunch
of
other
organizations
that
are
engaging
these
campaigns,
trellix
just
generated
65
000,
pull
requests
to
fix
a
tar
slip,
vulnerability
across
the
python
ecosystem.
G
You
know,
manoir
and
open
refractory
are
doing
work
in
this
area.
I'm
doing
my
own
work
in
this
area.
It
seems
like
there's
enough
people
in
this
space
discussing
this
topic
and
creating
some
best
practices
and
norms,
and
things
like
that
around
automated
vulnerability,
disclosure
automatic,
automated
vulnerability
fixing
at
scale-
probably
not
just
well,
maybe
maybe
a
little
bit
of
both
but
trying
to
come
up
with
Norms
around
that
and
so
I
think
that
this
is
a
Good
Home
But
as
a
sub-working
group,
not
necessarily
its
own.
Yet.
B
Much
like
your
other
request,
I
would
encourage
you
to
submit
an
issue
make
that
a
project
idea
and
then
we
can
kind
of
gauge
the
community's
interest.
So
if
we
can
get
that
set
up,
I'll
spam
everybody
in
the
mailing
list
and
chat
and
get
people
to
express
their
opinion
and
interests
and
see
if
we
can
get
muster
up
enough
folks
to
right
some
critical
mass
on
work
in
this
I.
G
Already
have
some
people,
people
discussing
it
at
GitHub,
so
GitHub
may
be
willing
to
dedicate
some
people
that
also
I
mentioned
it's
manoir
and
then
also
the
modern
folks
are
also
interested
in
putting
forward
a
person
to
to
be
involved
in
this
group.
So
there
is
there.
The
organizations
that
I've
reached
out
to
seem
so
far
to
be
interested
in
in
contributing
an
individuals
to
be
engaged
in
these
discussions.
I
Yeah
so
I
and
I
asked
this
is
slack
too
Jonathan,
like
so
I
I.
Think
it's
a
great
idea
to
try
to
coordinate
with
others
in
the
community
doing
the
same
thing.
I
G
G
So
Alpha
Omega
hired
me
and
I
am
already
doing
automated
vulnerability,
fixing
at
scale
that
doesn't
necessarily
put
it
under
the
purview
of
Alpha
Omega,
but
also
there
are
other
organizations
that,
like
we
are
relying
upon
or
and
or
maybe
working
together
with
for
this,
and
so
that
may
or
may
not
fall
under
Alpha
Omega
depending
upon
what
campaigns
are
being
engaged
in,
so
it
it
also
Alpha
Omega
is
not
a
working
group
too.
It's
a
it's
a
different
thing.
G
So
if
we
want
to
have
a
working
group
around
the
idea
or
topic
of
automated
vulnerability
disclosure,
even
if
it
may
not
have
a
deliverable
out
of
that
working
group-
specifically
it
may
just
be
well.
Maybe
it
could
be
just
Norms
that
we
come
up
with
across
the
industry
and
like
discussions
of
ongoing
campaigns
that
would
not
necessarily
fall
under
Alpha
Omega,
because
Alpha
Omega
is
not
a
working
group.
B
Any
additional
questions
or
feedback
for
Jonathan.
On
the
first
point,
the
automated
assembling
people
to
get
together
to
talk
about
automated
vulnerability
disclosure
at
scale.
G
I
would
like
to
create
a
slack
channel
for
this
I.
Don't
know
what
the
process
is.
Do
I
and
I,
probably
Crow
you
I,
don't
need
you
to
run
it,
but
I
might
need
some
help
from
you
to
get
this
thing
stood
up
and
then
also
maybe
David
wheeler
can
be
the
person
that
I
usurp
into
helping
out
with
this
making.
B
B
We
can
work,
we
can
collab
on
slack
on
the
the
wording,
but
we'll
need
that's
the
procedurally.
We
send
a
note
to
the
operations
team
and
they
will
make
it
but
I'd
like
you
to
make
an
issue
so
that
the
group
can
express
it
can
engage,
how
much
interest
we
have
around
the
members
here
that
we're
going
to
participate
on
this
perfect
I
can
do
that
awesome
and
then.
G
Second
Point
second
Point
Alpha
Omega
needs
a
disclosure
policy
for
outgoing
vulnerability
reports.
I
have
my
own
disclosure
policy
that
I've
been
using
I've
spoken
to
like
people
in
Alpha,
Omega
and
they're.
Just
like
you
should
just
come
up
with
a
disclosure
policy,
and
then
like
say
this
is
what
we're
going
to
use
in.
Like
you
know,
is
anybody
on
feedback
but
I
also
figured?
It
would
probably
be
healthy
to
have
some
Community
feedback
on
what
the
disclosure
policy
we
have
and
maybe
there's
a
like.
G
I
G
Group
may
have
reports,
they
have
outgoing
or
things
like
that,
but
just
in
general,
at
least
Alpha
Omega
at
least
needs
a
vulnerability
disclosure
policy
for
outgoing
reports,
and
that
includes
stuff,
like
you
know,
what's
the
Timeline
under
disclosure
policy,
you
know
what
do
we
do
if
they,
if
an
organ,
if
a
repository
or
an
organization
like
goes
beyond
those
that
timeline,
do
we
fully
disclose
the
vulnerability?
G
Do
we,
like
you,
know
all
those
all
those
policies
and
rules
that
we
have
so
that
we
are
uniformly
treating
all
organizations,
we're
reporting
vulnerabilities
to
in
a
consistent
manner
and.
B
and
my
opinion
is:
we
have
made
several
work
products.
This
could
be
a
interesting
example,
an
action
of
us
applying
those
to
provide
some
assistance
to
a
fellow
project
here
within
the
foundation.
G
B
So
I
would
Jonathan
created
issue
122
for
this
topic.
Anyone
interested
in
kind
of
participating
collaborating
on
this
just
tickle
that
with
a
comment
so
that
we
know
who
to
get
together
and
then
we'll
assemble
assemble
a
side,
Avenger
team
to
kind
of
collaborate
on
this.
If
we
can
get
enough
critical
mass
again
so
yeah
I
think
it's
a
nice
way.
We
could
potentially
prove
out
the
validness
of
our
existing
artifacts.
B
All
right
team
I
appreciate
everyone's
attention
today:
wonderful
dialogue,
Dan,
thank
you
for
the
coming
talk
to
us.
Sharing
this
information.
We
would
love
to
see
you
in
two
weeks.
We
can
continue
the
conversation
and
see
how
the
working
group
wants
to
engage
around
Vex
in
general,
but
also
specifically
the
kind
of
the
software
project
you
guys
have
put
together.
B
So
thanks,
everybody
enjoy
the
rest.
Your
day,
I'm
gonna
go
shovel
some
snow
I'm.