►
From YouTube: Vulnerability Disclosures WG (September 14, 2020)
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
Yes,
it's
being
recorded
and
and
we're
live
so
just
to
set
the
stage
a
little
bit.
This
is
the
open
security,
open
source
security
foundation,
vulnerability
disclosures
meeting
today
is
september,
14th,
2020
and,
and
I
think
we
can
get
started.
So
let
me
pull
up
the
agenda
really
quickly
and
share
my
screen.
A
So
we
have
a
pretty
busy
agenda
today,
which,
which
is
actually
quite
awesome.
I,
and
there
were
a
number
of
people
reaching
out
to
me
to
either
be
included
in
the
calendar,
invite
or
join
the
the
working
group.
I
think
those
two
things
are
not
necessarily
the
same,
so
the
the
working
group
meetings
are
opened
to
everybody.
A
The
link
to
this
meeting
is
in
the
openness
of
community
calendar,
so
actually
anyone
who
wants
can
join
that
and
people
who
can
join
can
can
follow
us
on
on
youtube
later
on,
but
there
are
actually
quite
a
few
people
who
expressed
interest
in
becoming
active
members
of
this
working
group.
So
folks,
if
you
could,
maybe
tell
us
a
little
bit
about
yourselves
and
what's
what's
your
interest
in
the
working
group
marcus,
maybe
we
can
start
with
you
welcome
to
the
working
group
by
the
way.
C
Thank
you,
so
I'm
working
for
zusa
as
a
project
manager
for
the
reactive
security
or
what
that's,
what
we
call
security
incident
response
and,
of
course,
that
also
entails
that
we
are
very
much
interested
in
automation
of
sharing
of
vulnerabilities
and
how
to
process
this
on
a
more
automated
level
than
it
is
currently
done.
So
that's
the
main
reason
that
that
I'm
participating
here
to
look
at
how
to
better
interact
with
the
rest
of
the
community.
A
Yeah,
that's
definitely
one
of
the
originally
used
cases
that
we've
identified
how
to
make
this
vulnerability
information
flow
between
the
parties
in
some
interoperable
way.
Okay,
thank
you.
Welcome
eduardo.
D
Hi,
can
you
hear
me
yes
loud
and
clear
cool,
so
I'm
eduardo.
I
work
for
canonico,
mainly
working
on
ubuntu
with
community
I've
been
working
with
security
for
the
past
five
years,
probably
and
yeah.
We
just
want
to
be
part
of
it
see
if
we
can
find
any
standards
that
the
whole
industry
can
use
and
try
to
make
things
better.
A
Okay,
welcome
and
thanks
for,
and
thanks
for
the
introduction
remus
I
have,
I
don't
think
I've
seen
him
on
the
list
of
attendees.
A
Okay-
so
I
don't
think
he's
here
so
we
can
postpone
the
warm
welcome
to
the
next
meeting
and
paulo.
E
Hello,
I'm
also
from
canonical
same
as
eduardo
I'm
the
security
team
inside
canonical,
so
we
try
to
make
ubuntu
and
linux
overall
more
safe.
So
that's
the
reason
I'm
here.
A
Okay
welcome
so
we
have
a
very
strong
canonical
representation,
which
is,
which
is
great,
and
maybe
let's
is
there,
anyone
else,
who's
new
to
this
meeting
and
working
group
and
would
like
to
introduce
themselves
david.
I
don't
think
you've
we
had
the
pleasure
of
hosting
you
before.
B
Oh,
thank
you.
Well
I
I
think
I
know
some
of
you
anyway,
but
I
I
am
new
to
this
group,
so
david
a
wheeler,
I
work
for
the
linux
foundation.
That's
actually
new.
As
of
april.
My
official
title
here
is
open
source
supply
chain
security.
So
basically,
I'm
around
to
try
to
help
open
source
software
be
more
secure.
B
Obviously,
vulnerability.
Disclosure
is
part
of
that.
Our
goal
is
to
reduce
the
need
for
it,
but
since
that's
never
going
to
go
away,
let's
try
to
make
it
better
when
we
need
to
do
it.
A
F
A
Okay,
I
hope
it's
gonna
be
an
interesting,
an
interesting
session.
So
thanks
for
joining
the
last
time
around
one
of
the
things
we
we
chatted
about
was
were
a
few
topics
around
governance.
A
I
have
not
made
as
much
progress
on
those
things
as
I
would
have
liked,
but
we
might
progress
on
one
thing
and-
and
I
was
looking
for
some
brave
souls
to
help
out
to
to
run
this
group-
and
I
was
like
secretly
hoping
that
at
least
one
person
would
would
actually
respond,
and
I
was
lucky
enough
to
have
more
than
one
people
I
actually
reach
out
and
express
interest
in
helping
out
running
those
meetings
and
moving
moving
our
agenda
forward.
A
So
starting,
I
think
today,
chris
and
matthew
are
going
to
be
helping
me
run
those
meetings
and
we'll
help
out
in
you
know,
making
sure
we're.
We
have
a
proper
charter
and
we
have
well-defined
goals
and
we
can
actually
move
forward
on
those.
So
thank
you
guys
for
stepping
up.
That's.
I
really
really
appreciate
this.
A
I
and
one
other
thing
that
I
wanted
to
bring
to
your
attention
here,
is
that
at
the
very
beginning,
the
openssf
after
it
formed
like
it,
wasn't
quite
clear,
like
what's
our
stance
towards
slack.
I
know
a
lot
of
online
communities
can
use
slack
to
collaborate
in
more
real
time
than
what
github
allows
for,
and
we
now
do
have
an
open
security,
open
source
security
foundation.
Slack
workspace.
A
There
is
a
it's,
not
a
very
lively
place
yet,
but
I
think
if
more
people
joined
then
it
could
be,
and
it
definitely
will
allow
us
to
like
a
more
real
time,
communication
medium.
So
what
I'm
gonna
do
is
I'm
gonna
post
this
invite
link
in
the
meeting
notes,
but
if
you
would
like
to
get
it
any
other
way,
feel
free
to.
Thank
me
over
email
or
ask
a
question
in
the
github
issues
or
github
discussions.
B
Chance,
yeah
yeah,
I
just
wrote
a
real
quick
note
on
the
slack
for
open
ssf.
This
is
the
version.
The
version
we
have
messages
disappear
after
ten
thousand
messages.
So
don't
put
anything
here
that
you
need
to
have
a
historical
record
of
this
is
more
for
immediate,
quick
discussion,
informal
discussions.
A
Right
right
like
I
would
assume
that
everything
that
can
we
need
to
keep
track
of
is
best
track
on
github.
I
think
that's
a
better
medium,
but
I
know
a
lot
of
people.
You
know
want
to
shoot
an
occasional
message
here
and
there,
and
I
think
it's
just
getting
more
popular
than
email
these
days
and
if
it
turns
out
to
be,
you
know,
a
lively
community,
that's
fine!
A
So
whoever
wants
to
get
in
just
give
me
a
shout
and
I'll
advertise
that
anyways
already
in
our
last
two,
our
last
two
meetings,
we
were
looking
at
disclosure
practices
in
two
different
communities.
A
One
of
them
was
the
node.js
ecosystem
in
the
related
bugbounty
program
on
hackerone
and
in
the
last
being,
reid
was
telling
us
more
about
disclosure
in
the
ruby
community,
with
ruby
jams
from
the
ruby
rubyset
project,
and
today
we
actually
will
venture
into
a
little
bit
of
a
different
territory
and
and
that
territory
is
linux,
distribution.
A
So
morton
and
chris
have
actually
agreed
to
tell
us
a
little
bit
more
about
our
our
clinics
and
red
hat.
Handle
handle
vulnerability,
disclosures
so
martin
feel
free
to.
I
don't
know
if
you
wanna
just
talk,
or
do
you
want
to
present
something?
G
I'll
subscribe,
yes,
you
can
hear
me.
Yes,
can
you
hear
me?
Oh
awesome.
This
is
a
little
bit
exciting.
I
tried
to
share
screen
feature
through
the
web
browser
today
because
I'm
using
linux
and
assume
and
I'm
not
sure
exactly
how
well
it
works
so
we'll
just
try.
Can
you
see
a
screen.
G
G
What
we
sort
of
opted
in
arch
linux
was
to
write
our
own
sort
of
web
dashboard,
which
is
tightly
integrated
into
the
ecosystem.
So
here
we
can
essentially
record
vulnerability
groups
which
are
essentially
a
listing
of
the
package
in
arch,
the
cv
number,
the
affected
version
and
some
references,
and
this
allows
us
to
easily
sort
of
track.
G
We
also
tried
to
keep
the
references
handy
and
from
here
we
can
sort
of
easily
to
the
generation
of
the
email
which
is
sends
to
the
advisory
listing
of
arch.
So
sort
of
what
this
allows
us
to
do
is
to
keep
track
of
the
bumped
packages,
which
is
our
to-do
lists.
If
there's
any
issues
that
needs
to
be
sorted
and
everything,
this
doesn't
track.
Embargoed
private
cv
issues,
everything
is
public.
G
G
So
this
sort
of
works
well
for
us
compared
to
other
sort
of
we.
I
assume
cyrob,
is
going
to
talk
more
about
red
hat,
but
we
are
all
volunteers,
so
just
sort
of
loosely
based
organization
around
how
we
work
on
this
tracker,
but
it
sort
of
works.
Well.
The
thing
that
we
certified
interested
in
is
more
easier
machine,
digestible
data
from
mitra
or
other
providers
that
allows
us
to
easily
not
have
to
like.
G
Discover
security
issues
on
the
oss
security
email
list
or
how
to
watch
libyan
to
advisory
listings
for
new
issues,
because
we
simply
don't
have
the
capacity
to
stay
on
top
of
the
published
data
formats
that
micro
does
so
yeah.
That's
a
quick
rundown!
G
G
So
there's
not
a
huge
there's,
not
often
that
we
sort
of
have
to
write
our
own
cv
descriptions
or
have
to
figure
it
a
lot
of
on
our
own.
We
just
sort
of
struggle
to
find
upstream
patches
and
what's
sort
of
tie
the
patches
together
with
the
cv
numbers.
B
G
So
I
think
it's
a
combination
of
both
I'm
not
sure
what
nvd
does
to
publish,
but
mitra
publishes
like
an
xml
dump
of
the
of
the
newly
entered
ideas,
and
you
have
to
manually
go
through
them
to
figure
out
which
one
is
the
reserved
cvs,
which
has
now
been
updated.
You
have
to
like
manually
process
them.
You
could
probably
do
the
git
repo
with
json
data,
but
then
you
have
to
sort
of
parse
git
commit
logs
to
sort
of
figure
out
which
what
was
recently
added
there's.
G
Also
this
problem
of
like
debian
likes
to
split
up
packages.
You
have
the
library
headers
the
documentation,
everything
is
separate
packages
and
you
don't
really
know
which
packages
is
which
packages
are
cross
distributions,
which
is
another
problem
when
you're
sort
of
looking
at
the
sort
of
lack
of
metadata,
which
is
present
in
the
upstream
cv,
databases.
B
G
I
think
more
metadata
upstream
easier
eastern
parts,
maybe,
but
I
I
the
more
better
better
apis,
I
think,
is
the
main
main
issue.
Mitra
only
publishes
the
xml
dumps,
but
they're
hard
parts,
there's
not
one
sort
of
one
one
source
with
all
the
metadata.
It's
all
sort
of
spread
across
different
repositories,
and
sometimes
the
metadata
which
are
published
from
red
hat
or
canonical,
is
not
entered
into
the
mitra,
so
you're
sort
of
like
how
to
scavenge
a
little
bit
across
the
different
advisory
systems
to
find
everything
you're.
Looking.
A
For
so
so,
do
you
know
how
this
information
is
consumed
by
other
parties,
we're
that
that's.
A
G
G
So
I
think
the
most
usage
from
this
is
because
arch
isn't
an
enterprise
distribution,
so
it's
usually
hobbyist
people
that
that
use
it.
So
I
think
most
of
the
information
people
get
is
from
the
secured
advisory
mailing
list
and
secondary
it's
the
there's.
Some
someone
wrote
a
package
tooling,
which
basically
lists
your
packages,
which
ones
are
outdated
and
which
one
has
registered
security
vulnerabilities.
I
think
that's
the
two
ways:
people
consume
these
logs.
G
I
know
that
the
the
lvn
newspaper
scrapes
our
mailing
lists
and
probably
republishes
our
secure
advisories.
We
should
do
with
several
security
distributions,
but
I'm
not
sort
of
very
familiar
with
how,
if
there's
any
enterprise
people
that
sort
of
uses
arch
in
production
and
viruses
are
data,
I'm
not
familiar
with
them,
because
we
haven't
heard
from
them.
A
Cool,
thank
you
so,
just
to
so,
I
have
like
a
clear
picture
so
yeah
the
this
information
only
goes
one
way,
so
you
grab
it
upstream
to
make
it
available
to
whoever
is
using
arch
linux
you're
not
doing
like
disclosure
for
things
that
either
arch
linux
developers,
kind
of
discover
and
maybe
patch
themselves
and
pour
the
patches
upstream
and
make
sure
that
those
are
properly
disclosed
to
you
know
or
other
vulnerability.
Databases
upstream.
G
So
yes,
so
we
have
done
that,
but
that's
usually
from
the
metro
web
forum.
We
have
considered
been
contemplating
applying
to
via
cna,
but
we
we
don't
write.
We
don't
compare
to
other
distributions
that
does
backporting
of
patches
and
stuff.
We
stay
pretty
close
to
upstream.
So
there
isn't
like
a
usual
huge
amount
of
issues
we
need
to
handle
as
security
issues.
It's
usually
like
the
occasional
pac-man
bug
and
recently
the
file
system
package
had
the
cve.
G
I
think,
but
that's
one
or
two
a
year,
usually
so
you
can
easily
handle
them
with
mr
cve
form.
A
Okay,
cool
you,
anticipating
that
my
question
about
the
cna.
So
thanks
for
asking
yes
without
me,.
G
A
So
yes
cool,
so
all
the
people
on
the
call
feel
free
to
ask
martin
questions.
I
think.
D
Yeah,
I
have
one
question
that
you're
using
is
just
cvs.
Yes,
do
you
have
your
own
for
that
issue.
G
We
never
added
the
cbs
s
score
because
it's
easier
just
to
have
enum,
but
currently
we
look
at
nvd,
we
sort
of
always
like
to
defer
to
red
hat,
because
we
have
a
better
experience
with
what
they're
reporting
than
whatever
nbd
is
reporting.
So
we
usually
look
at
the
cvs
score
from
nbd,
slash,
mitra
and
then
also
red
hat
and
just
like
what?
What
do
we?
What
do
we
think
here?
Is
it
a
remote?
G
Is
it
a
local
dos
problem,
not
critical
severity
and
just
do
a
little
bit
of
eyeballing,
based
on
the
css
from
red
hat
and
nvd,
so
they're
not
based
on
cvss,
currently.
H
G
G
H
G
So
we
use
if,
if
we
had
already
published
the
package,
we
usually
just
go
with
the
one
that's
published
and
to
that
one
that's
fixed
if
it's
originally
discovered
one
version
ago
it's
already
published,
so
we
don't
necessarily
care
that
much
about
it,
because
we
work
on
the
basis
that
one's
security
issue
has
been
patched
for
or
been
out
for
two
weeks
we
don't
usually
publish
an
advisory
on
it,
also
to
try
to
keep
our.
A
Going
once
going
twice:
okay,
I
think
that
means.
That
means
no
more
questions.
I
I
think,
if
you
want
to
ask
questions
later
on,
if
something
you
know
pops
into
your
head,
that
that
you
didn't
think
about
during
the
meeting
during
the
meeting,
which
it
often
does
for
me,
just
feel
free
to
open
up
an
issue
on
github
and
I
think
that's
a
good
way
to
continue
the
discussion.
A
Yes,
it,
it
definitely
was
for
me.
Thank
you.
Thank
you
for
sharing,
okay
yeah.
Chris,
do
you
want
to.
I
Take
this
over,
I
would
love
to
thank
you
very
much
for
sharing
that
was
very
interesting,
we'll
see
if
I
can
meet
that
awesome
quality
content.
If
I
can
share
my
amazing
screen
here,.
I
Everybody
see
my
pleasingly
black
and
white
screen,
yep,
yes
great,
so
I'm
krobe.
I
am
the
program
architect
for
red
hat
product
security.
We've
been
a
product
security
and
incident
response
team
for
nearly
25
years,
starting
off
with
linux
and
then
migrating
to
a
portfolio
that
encompasses
over
50
different,
open
source
based
solutions,
first
and
foremost
throughout
our
history,
and
especially
more
so
today
we
follow
a
principle
called
cvd,
which
is
coordinated,
vulnerability,
disclosure.
I
So
what
that
means
for
us
is
if
we
are
brought
in
and
given
information
about
a
security
issue,
we
always
respect
what
the
finders
wishes
are
and
how
they
want
that
shared
or
kind
of
where
or
how
that
can
be
talked
about.
If
we're
aware
of
implications
within
other.
I
So,
for
example,
we
work
a
lot
with
our
partners
over
at
suse
and
canonical.
So
if
we're
aware,
if
somebody
reports
an
issue
to
us
that
we
are
aware,
we
know
it
potentially
affects
the
other
distributions,
we
will
reach
out
and
ask
the
reporter.
Can
we
we
are
aware
that
x,
y
and
z
could
affect
my?
My
friends.
Can
we
please
get
those
folks
looped
in?
But
it's
always
ultimately
up
to
the
finder
what
they
decide
and
how
they
want
to
share
this
information.
I
My
team
monitors
over
400
000
packages
and
versions
of
packages
and
projects
around
the
internet.
It's
quite
a
lot
of
work.
We
keep
that
in
a
database
a
manifest
database,
so
we
were
able
to
say,
as
we
get
information
about
a
particular
problem
we
can
tell
precisely
which
version
of
a
product
or
which
component
within
a
product
potentially
ship
that
information
and
then
we're
able
to
do
further
analysis.
I
Every
issue
that
we
have
that's
reported
to
us
is
reviewed
by
a
red
hat
engineer
on
our
security
team.
We
have
close
to
100
individuals
around
the
globe,
we're
in
17
countries,
and
they
are
experts
in
our
different
products
within
the
portfolio
and
open
source
and
linux
in
general,
and
they
go
through
and
they
verify
does
this
issue
work
within
the
context
of
red
hat
engineering.
I
One
of
the
benefits
a
commercial
distribution
has
over
community
is
that
we
have
a
large
investment
in
testing
suite
and
a
whole
battery
of
things
like
source
code
scanning.
These
other
tools
that
community
projects
might
not
have
so
we'll
go
through.
We
also
as
we
build
our
offering.
We
have
certain
compiler
options,
certain
settings.
We
know
that
on
on
or
off
as
that
offering
is
released.
So
we
understand
the
problem
within
the
context
of
red
hat,
and
then
we
will
work
with
our
internal
engineering
teams
to
get
that
patch
worked
out.
I
We
have
a
couple
different
models
on
how
we
find
out
information.
Predominantly
our
modus
operandi
is
if
we
have
packages
or
projects
that
are
important
to
our
customers.
We
try
to
ensure
we
have
engineers
that
are
contributors
to
those
projects
or
potentially
earn
their
way
up
to
like
a
level
of
maintainer,
and
we
also
work
to
potentially
work
as
either
a
participant
in
an
upstream
security
team
or
in
a
lot
of
cases.
I
We
actually
act
as
the
upstream
security
team,
because
those
smaller
projects
might
not
have
the
expertise
or
ability
to
do
this
stuff,
but
basically
we
are
either
directly
told
by
a
finder
hey.
I
found
this
problem
with
x
or
y
we'd
like
you
to
fix
it
or
through
our
engagements
with
the
upstream
community,
whether
we
are
the
security
team
or
participants.
I
We
get
this
information,
we're
also
members
of
a
lot
of
different
mailing
lists,
where
we
get
information
intelligence
about
things
that
are
going
on,
and
then
we've
developed
pardon
my
children
it's
school
from
home
today,
so
I
guess
they
decided
they
wanted
to
print
out
something
I'll,
only
mute
just
for
one
second.
Here,
if
I
can
find
the
mute
button,
I
bet
I
can't
oh
well
I'll
instruct
them
to
stop
when
they
walk
in.
I
We
have
we
have
developed
a
series
of
tools
to
monitor
those
400
000
packages
and
versions,
and
we
call
it
assembler
internally,
where
it's
basically
scraping
the
internet,
where
we're
monitoring
things
that
are
important
to
our
products
as
an
organization.
We
are
a
cna
and
we
offer
cve
services
to
smaller
projects.
If
they
don't
have
that
ability
or
mechanism
we
assist
with
upstream
groups,
writing
security
advisories.
We
help
them
analyze.
Issues
if
need
be.
I
We
also
are
very
heavily
involved
in
the
industry,
communities,
whether
that
is
first
or
in
the
other
large
mysakka,
these
these
large
industry
groups.
So
we
are
constantly
talking
with
our
security
peers
around
the
globe.
I
That's
another
source
of
intelligence
for
us,
and
then
we
will
have
people
either
randomly
report,
something
or
they
will
potentially
submit
a
paper
to
a
important
conference
like
black
hat
or
devcon,
where
we're
monitoring
those
conference
sites
to
see
what
types
of
things
are
being
submitted
and
if
they
hit
certain
characteristics
like
they,
they
say
it's
an
exploit
of
the
linux
kernel,
they're,
going
to
zero
kubernetes,
we'll
take
additional
information
to
kind
of
research.
I
I
We
feel
that,
as
an
issue
is
discovered,
it
should
be
shared
with
those
people
that
have
a
responsibility
or
ability
to
fix
it
and
users
that
potentially
could
be
impacted
by
that
issue
should
be
informed
whether
or
not
there's
a
fix,
but
they
should
be
told
you
are
potentially
at
risk
because
of
this
vulnerability
or
exploit,
but
we
as
a
corporate
entity,
will
not
knowingly
push
silent
fixes
and
that's
a
conversation
piece.
We
have
with
several
larger
upstreams
about
some
of
their
newer
practices.
I
J
K
B
Yeah,
I
actually
agree
with
you,
but,
as
as
scrub
has
already
noted,
there
are
several
projects,
I
suspect,
although
if
I
think
they
might
not
agree
with
the
characterization,
the
linux
kernel
might
be
characterized
that
way.
So
there's
one
that
apparently
some
people
hear
of
yeah.
I
B
I
It's
important
for
us
for
customers
to
understand
what
their
risks
are
and
understand
where
there
are
vulnerabilities
and
ideally
for
things
that
are
under
our
stewardship
or
care.
We
try
to
provide
as
much
information,
so
the
customer
can
have
a
mitigation
or
how
to
turn
the
thing
off
or
avoid
using
this
or
ideally
provide
a
patch.
But
yeah.
There's
some
debate
upstream
about
what
is
or
is
not
a
security
issue
and
what
needs
documentation.
B
Yeah,
let
me
attempt
to
channel
greg
kh,
although
really
you
ought
to
hear
from
his
mouth
instead
of
me,
but
I
think
from
the
linux
colonel's
point
of
view.
They
they
believe
the
correct
way
is
upgrade
to
the
latest
kernel
and
anything
that
any
you
know
back
parting,
patches
and
so
on.
Well
I
mean
we
did
we
released
the
thing
as
a
whole.
We
didn't
test
all
the
these
specific
things
back
patch,
so
they
would
much
rather
distros
quickly
package
up
the
latest.
B
I
Counter
greg's
position:
I
will
provide
as
evidence
millions
of
end
consumers
that
that's
not
how
they
use
linux.
B
I
Well,
when
you're
a
great
organization
like
us
that
has
a
10
to
15
year
tail
on
support
on
some
of
our
offerings,
that
is
not
necessarily
an
option.
That's
part
of
the
value
that
commercial
linux
offers,
as
opposed
to
going
upstream,
helps
you
buffer
from
some
of
the
changes
or
regressions
that
might
happen
up
there,
but
that's
a
future
conversation.
I
But
again
we
don't
knowingly
push
silent
fixes
how
we
do
all
this
is
once
we
discover
an
issue
that
affects
our
products
or
even,
if
there's
a
report,
we
have
internal
tooling
that
we've
developed
that
grabs
this
information,
and
then
we
start
to
create
defect.
Trackers.
Historically,
our
system
had
been
bugzilla,
so
about
half
of
our
portfolio
uses
auxiliary
as
a
public
bugzilla.
I
You
can
go
open
up
a
bug
and
if
it,
if
you
mark
that
it
has
security
implications,
it'll
mark
that
bug
temporarily
private,
as
you
interact
with
us
in
engineering
to
determine
what
is
or
is
not
the
problem
and
then,
if
you're,
the
finder,
you
can
opt
to
go
public.
If
you
desire-
or
you
can
work
till,
we
have
a
work
with
upstream
to
get
a
fix,
but
we
have
defect
tracking
systems,
primarily
bugzilla.
I
We
also
use
public
jira
and
we
use
github
and
get
lab
issues
depending
on
which
of
the
awesome
products
you're
working
with
I'll
again
post
some
links
there,
but
bugzzill.redhat.com
is
one
of
the
public
places
where
you
can
go,
look
and
see.
Look
at
what
types
of
things,
whether
it's
not
all
security
issues,
a
lot
of
times,
it's
rfes
or
they'll.
You
know,
customers
will
find
normal
bugs
they
don't
have
security
applications,
but
it's
all
in
there
all
of
the
data
that
we
collect
or
all
the
issues
we
work
with.
I
We
publish
publicly.
We
have
a
metrics
page.
That
is
a
way
to
get
it,
but
we
also
publish
all
of
our
data
as
oval
cvrf
csaf.
We
have
a
vulnerability
data
api
that
this
stuff
is
available
in
machine,
readable
formats
and
so
every
because
our
software
is
sourced.
It
opens
up
stream
open
source.
I
can't
hide
anything
so
again:
everything
in
my
world
once
it's
public.
It
is
completely
viewable
to
the
world.
I
We
have
an
internal
tool
that
watches
upstream
and
then
we
developed
an
internal
workflow
tool
that
helps
stitch
those
different
backend
systems.
So
again
we
have
about
four
different
defect:
trackers.
We
also
have
several.
We
have
several
different
internal,
build
pipelines
or
marata
systems
that
we
need
to
issue
trackers
to
we
kind
of
manage
all
that
through
a
central
pane
of
glass.
We
call
sfm2
a
security
flaw
manager
too
we're
very
original
in
our
names.
I
We
publish
all
of
our
updates
publicly
I'll
show
you
kind
of
an
example
we
have
on
our
customer
portal.
We
have
our
cve
page
where
we
provide
every
cve
that
affects
a
red
hat
component.
We
will
issue
a
cvss
score,
ideally
latest
and
greatest
right
now
we're
on
three
one:
we're
helping
develop
cvss
v4
with
the
working
group.
We
also
provide
a
cwe
analysis.
I
What
was
the
coding
flaw
that
from
which
this
vulnerability
originated,
and
then
we
will
provide
a
red
hat
severity
score,
and
this
is
our
method
to
help
teach
people
when
there
is
something
that
needs
to
have
quicker
action.
So
we
all
know
cvss
is
a
system
to
describe
how
a
vulnerability
works.
It
is
not
a
measurement
of
risk,
but
unfortunately
most
people
have
adopted
it
as
a
risk
management
tool
which
it
is
not.
So
we
provide
the
red
hat
severity
score
to
help
coach
customers.
This
is
something
if
like.
I
We
have
that
all
documented
publicly
on
our
page
and
if
something
is
critical,
that's
something
that
we
actually
take
extra
steps
to
go
out
and
tell
people,
even
though
this
might
have
a
cvss
score
of
like
a
five
six.
It
might
not
appear
to
be
interesting.
Red
hat
feels
based
off
of
how
it's
deployed
and
used.
This
is
something
that
needs
faster
action
or
something
that
potentially
needs
can
be
waited
for
a
standard
patch
cycle,
for
example,
but
that's
something
that
we
provide
with
everybody
we
brought.
I
heard
someone
mention
mitre.
I
As
we
all
know,
the
nvd
is
the
best
thing
ever
and
they
are
always
up
to
date
and
accurate.
Well,
for
this
particular
is
this
particular
cve
15802.
We
have
issued
our
cvss
score.
I
I
This
particular
kernel
issue
was
not
infected,
probably
because
it
was
a
newer
feature
than
that
older
kernel
was
you'll,
see
here
with
enterprise,
mr
g2,
that
is
that
is
affected,
but
it
is
out
of
support
scope.
So
that
is
no
longer
a
supportive
product
for
customers.
They'll
need
to
take
some
additional
actions
around
that
there's
our
security
data
I'll
get
links
to
all
this.
When
I'm
done,
let
me
see
all
of
our
advisories
have
a
cve
identifier.
We
use
cvss
to
describe
how
the
vulnerability
works.
I
We
do
cwe
to
describe
how
that
technically
that
issue.
The
coding
flaw
behind
that
issue
and
we're
evaluating
in
the
future
using
ssvc,
which
is
a
new
technique
promoted
by
cert,
cc,
art
mania
and
company,
where
it
hopefully,
if
a
customer
does
their
due
diligence,
will
provide
a
more
accurate
risk
assessment
for
them
and,
as
a
supplier
of
fixes,
we
would
state,
you
know,
are
we
affected?
I
Are
we
aware
of
active
exploit
and
what
does
engineering
what's
their
position?
Are
they
going
to
decide
to
fix
this
issue
or
not
and
end?
Consumers
would
take
that
ss
vc
information
and
plug
that
into
their
own
system
and
decide
how
critical
their
system
is,
what
kind
of
data
and
stuff
live
there?
So
that
is
the
long
and
the
short
of
it.
I
What
questions
did
that
generate
for
everybody.
A
I
I
actually
have
a
question,
so
it
seems,
as
you
said,
it's
been
going
on
for
years
and
and
very
mature
like
what
are
your
pain
points
without
maybe
pointing
fingers
at
specific.
You
know
in
industry
groups
like
for
you
as
an
organization
working
with,
as
you
said,
like
a
number
of
you,
know,
industry,
peers
and
like
tons
of
upstream
software.
I
imagine
also
with
some
security
researchers,
background
programs
things
things
of
that
nature
like
what's
what's
the
biggest
problem
for
you
today,.
I
Like
I
mentioned,
we
have
generally
a
10
to
15
year
tail
on
support,
so
we
have
a.
We
carry
a
lot
of
technical
debt,
so,
as
we
get
into
you
mentioned
now,
agile
upstream
could
be
where
you
just
install
the
brand
new
kernel.
I
have
customers
that
run
the
world.
I
Every
trading
house,
every
bank,
every
government,
every
military
organization
on
the
planet
does
not
run
on
the
brand
new
version
of
kernel,
fun
fact,
so
they
cannot
deploy
a
brand
new
thing
that
potentially
is
going
to
introduce
break
avi
or
api
compatibility.
You
know
they
have
developed
their
critical
business
system
around
this
specific
set
of
functionality.
So
it's
up
to
our
engineers
to
kind
of
figure
out
how
to
make
the
fix
relevant
on
these
older
things.
That's
really
kind
of
our
biggest
problem,
interacting
with
upstream,
is
generally
not
too
bad.
I
We
have
some
up
streams
that
are
a
little
more
aggressive
than
others
that
they're
gonna
they're
gonna
save
the
world
with
their
new
and
amazing
idea,
which
they
do
have
a
lot
of
great
ideas.
But
after
a
few
years
all
the
stuff
tends
to
kind
of
operate
pretty.
Similarly,
because
they
start
to
accept,
there's
some
good,
really
good,
good
practice
out
there
in
open
source
and
they
start
to
adopt
how
other
team
other
projects
might
be
tracking
things
or
doing
things.
I
But
yes,
so,
upstream
and
like
researchers
really
don't
bug
us,
we
love
working
with
researchers,
printer.
We
occasionally
get
to
the
great
opportunity
to
work
with.
You
know,
issues
that
affect
every
computer
on
the
globe
and
those
are
pretty
awesome.
I
You
know
marcus
is
well
aware
of
some
of
these
things
and
when
you
get
to
that
point,
where
you
have
an
external
party
controlling
the
embargo
and
when
it's
the
scope
of
things
is
very
so
large,
unfortunately,
the
embargo
time
and
the
amount
of
people
you
have
to
include
in
embargo
a
great
time
grows.
They
have
people,
you
have
to
get
included
in
it
grows.
I
But
you
know
our
typical
embargo
time,
things
that
we
see
that
are
private
for
a
period
of
time
is
about
10
to
13
days
and
that's
really
less
than
15
percent
of
all
the
vulnerabilities
we
fix
every
year
and
every
year
we
fix
about
1400
cves,
so
about
15
of
those
are
embargoed
for
some
period
of
time
and
it's
just
the
really
stupid
huge
ones
that
are
very
cumberplex
to
deal
with.
A
The
the
the
reason
I
asked
this
question
is
that,
like
previously,
we
have
identified
as
one
of
the
pain
points
would
potentially
like
to
address
in
this
work
that
there's
it's
it's
quite
hard
to
make
public
vulnerability
information
that
they're
easily
consumable
by
both
both
other
organizations,
but
also
tools,
such
as
vulnerability
scanners
and
also
like
one
of
the
use
cases
we
kind
of
ran
into
a
little
bit
later,
is
that
right
now,
as
you've
showed
us
like
you're,
showing
us
vulnerabilities
that
were
analyzed
by
humans.
A
You
know
cbs,
says
cwe.
All
of
those
things
were
deeply
analyzed
in
and
that's
kind
of
new
to
me,
but
it's
awesome
like
even
in
the
context
of
a
particular
customer.
However,
on
the
other
side
of
the
spectrum,
we've
been
also
thinking
about
use
cases
where,
for
example,
you
have
like
an
open
source,
fuzzing
engine,
that
kind
of
spits
out
like
hundreds
of
vulnerabilities
yeah.
A
So
so
that
was
going
to
be
my
question,
if,
like
you
have
any
infrastructure
where
this
information
would
be
published
automatically
for
others
to
consume,
or
does
it
also
funnel
to
like
this
human-powered
analysis
engine
for
like
every
little
vulnerability.
I
The
boggle
with
the
fuzz
like
we,
there
was
a
string
about
four
years
ago,
where
we
had
a
bunch
of
academic
researchers
that
were
fuzzing,
saying
that
they
found
the
biggest
problems
ever
and
they
were
just
kind
of
denial
of
service
stuff.
The
fuzzers
we
have
to
take
with
a
grain
of
salt.
There
is
value
and
that's
a
technique.
You
can
take
as
part
of
your
supply
chain
to
test
things,
doing
that
input,
kind
of
validation
and
boundary
testing.
I
But
from
our
standpoint
the
we
don't
get
handed
a
lot
of
fuzzing
reports
and
when
we
do,
we
try
to
encourage
the
researcher
to
go
back
and
review
their
own
data.
I'm
not
going
to
digest
a
3
000
page
report
for
them
and
if
they
feel
that
there
are
some
issues
that
are
relevant
and
actually
do
bubble
up
to
the
level
of
a
vulnerability,
not
just
an
annoyance,
then
we
will
work
with
them
to
help
coach
them.
Through
that.
I
I
get
more
on
the
flip
side,
where
I
get
a
lot
of
commercial
scanners
where
a
customer
will
use
a
qualis
or
some
other
tool,
and
they
will
pan
me
a
500
page
report,
saying
I
found
all
these
cds
and
because
we
use
back
porting
as
a
technique
to
pull
the
fixes
into
our
code
base
and
scanners
typically
just
work
off
of
a
a
version
string.
I
This
is
the
version
of
the
package,
there's
always
mismatches,
so
I
spent
a
lot
of
time
talking
about
false
positives
in
the
code
base,
because
either
we
did
not
back
port
that
piece
of
vulnerable
code
yet
or
it
was
already
fixed
in
a
different
release
and
we
added
a
zero
one
toward
the
end
of
our
kernel
package
to
show
we're
a
slightly
different
version.
But
it's
that
same
base
of
code.
I
I
K
Yeah,
sorry,
I
was
going
to
say
and
then
we
have
companies
like
sun
microsystems
used
to
do
which
doesn't
change.
The
version
number
just
patches
the
binary
and
tells
you
it's
fixed
and
then,
when
you
do
a
version
scan
or
version
shrink
scan.
You
think
there's
all
kinds
of
errors,
but
it's
been
fixed.
I
don't
know
if
people
still
do
that,
but
at
the
time
it
was
really
a
pain
in
the
butt.
So
I
agree
at
least
you
change
a
tiny
version
number
at
the
end
at
least
there's
somebody
can
think
or
some.
E
G
I
guess
yes,
yes,
so
one
of
the
problems
we
have
in
australia
is
that
sometimes
we
get
a
cv
either
on
oss
security,
or
we
found
a
cv
summer
on
twitter
example
and
usually
there's
sometimes
hard
to
find
which
patch
upstream,
which
corresponds
to
the
fixed
cv.
G
I
That
is
something
I
would
need
to
get
somebody
from
our.
We
have
an
internal
devops
team
just
for
product
security.
I'd
have
to
get
those
gentlemen
on
the
call
sometime,
and
maybe
we
can
do
that
for
a
future
call
and
they
can
explain
how
their
assembler
tool
works
and
kind
of
what
criteria
it's
looking
at,
but
yeah.
It
takes
a
lot
of
time.
I
G
Because
one
of
that's
probably
one
of
the
things,
I
think
a
lot
of
the
at
least
the
distributions
do
again
again
is
find
the
patch
for
the
cv
find
a
patch
and
often
that's
not
committed
to
either
meter
or
nvd.
G
I
J
Go
see
so
I
mean
I
troll
your
bugzilla
a
lot
still
chris
and
and
obviously
yeah
shocked
right
in
every
other
company
yeah
right
right.
The
bugs
often
contain
the
link,
but
none
of
the
metadata
red
hat
publishes
has
it.
So
when
I
need
it,
I
just
go
to
the
bug
and
it's
I'd
say
90
of
the
time.
It's
there
cool.
Thank
you.
Josh.
C
Yeah,
so
I
think
that
mitre
or
usually
includes
links
to
patches
commits
and
so,
and
I
think,
if
it's
missing
there,
that
something
that
on
one
hand,
we
couldn't
push
the
research
or
the
requester
to
do
better
like
and
actually
everyone
can
adjust
cbs
to
add
more
references.
It's
just
the
pain
and
yes
to
do
so,
but
it's
possible.
But
that
would
be
one
topic
to
this
discuss
if
we
can
enhance
this
in
a
more
easier
form
like
without
doing
pull,
requests
or
web
forms
or.
L
I
You
might
not
have
noticed
that,
but
yes,
we
with
recent
versions
of
our
portfolio.
We
have
some
tooling
that
we
are
now
able
to
get
some
of
that
insight.
If
the
customer
agrees
to
let
us
watch
and
that's
something,
I
could
take
a
look
and
see
kind
of
what
the
standard
uptake
on
some
of
this
stuff
is.
I
But
my
customer
base
is
large,
commercial
or
government
or
retail
finance,
so
they
tend
to
be
heavily
regulated,
so
they
will
both
patch
probably
more
frequently
than
some
other
customers,
but
they
also
will
probably
do
it
kind
of
bursty
where
they
will
have
a
monthly
or
quarterly
patch
cadence.
Unless
there's
a
rough
critical
thing
to
do
yeah,
I
can
do
some
research
and
see
what
I
have
and
if
we
can
make
some
kind
of
extrapolations
of
that
data.
I
And
I
again
have
a
whole
spectrum
of
people.
I
have
the
second
in
advisory
comes
out
or
just
a
note
of
public
notice.
I
have
customers
asking
when's
the
patch
coming
and
they
will
apply
immediately
because
they
have
certain
harsh
government
or
regulatory
requirements,
but
then
I
will
have
people
at
the
other
end
that
you're
still
you
know
four
or
five
years
later
they
may
or
may
not
patch.
It
just
really
kind
of
depends
on
what
vertical
the
the
group
is.
I
G
So
in
the
arch
linux
of
things,
we're
sort
of
in
the
other
end
of
everything,
so
we're
not
enterprise,
we
don't
have
enterprise
customers,
we're
usually
like
most
targeted
users.
When
there's
been
a
fixed
version,
we
usually
regard
it
as
solved
if
it's
been
longer
than
two
weeks,
because
it's
just
easier
but
the
second
either
released
version
is
published
or
there's
a
patch
published
which
can
apply.
We
can
usually
publish
within
the
day
and
have
it
available
for
users
how
long
it
takes
people
to
update.
A
Yeah,
that's
that's
a
cool
data
point
thanks,
so
much
we're
getting
very
quickly
until
the
top
of
the
hour,
so
martin
and
chris
thank
you.
That
was
those
are
very
good,
very
good
conversations.
Thank
you.
So
much
is
there.
Is
there
anything
that
you,
as
a
group
would
like
to
talk
about
in
our
next
meeting?
I
I
know
I
still
owe
everyone
a
discussion
about
like
the
cadence
and
times
of
of
those
meetings.
A
I
will
kick
that
discussion
off
next
week,
but
whenever,
whenever
we
decide
to
meet
like,
is
there
a
particular
topic
that
kind
of
maybe
is
with
flags
somewhere
over
here,
that's
relevant
to
you
and
you
would
want
to
discuss
it
or
you
know
it's
coming
from
something
else,
like
the
interest
of
open
source
disclosures.
A
Because,
if
not,
we
can
just
continue
with
maybe
bringing
and
inviting
other
people
from
other
communities
to
share
how
they
deal
with
disclosures.
I
think
that
so
far
has
been
super
educational
and
one
other
thing
that
I
would
like
to
bring
to
the
agenda
is
getting
getting
back
to
the
topic
of.
Why
are
we
here
and
was
it?
What
is
it
that
we
that
we
want
to
achieve?
So
maybe
we
would
make
a
short
discussion
about
that.
I'd
put
it
in
the
agenda
for
for
the
next
meeting.
B
Please
do
because,
I
think
that's
that's
very
important
yeah
and
I
I
I
I
know
that
the
open
ssf
wants
to
do
some
releases
at
the
end
of
october.
I
doubt
very
much
this
group
will
be
able
to
do
release
of
any
results
at
that
point,
but
I
think
they
very
much
would
like
to
see
some
things
at
some
point.
A
Yeah
and
to
to
get
anywhere,
I
think,
like
redoing,
the
exercise
of
what's
our
focus,
what
is
it
that
we
want
to
solve
and
like
putting
some
sort
of
roadmap
together
would
be,
would
be
the
good
next
step.
A
All
righty
so
once
again,
thank
you
so
much
for
coming
once
again
welcome
to
our
new
working
group
team
members
and
and
I'm
gonna
stop
the
recording
in
just
a
second
and
I'm
gonna,
upload
it
to
youtube
as
soon
as
it's
available,
and
I
will
post
the
meeting
notes
on
on
github
yeah.
Thank
you
so
much
great.
Thank
you.
Everybody.