►
From YouTube: OpenSSF Town Hall Quarterly Meeting (February 23, 2022)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right,
let's
get
started
good
morning
and
welcome
everyone
to
the
first
quarter,
edition
of
the
quarterly
open,
ssf
town
hall.
This
is
a
tradition
that
the
openssf
has
hosted
for
for
quite
a
while
as
a
way
for
the
community
as
a
whole
to
come
together
to
talk
about.
A
What's
going
on,
some
recent
updates
fun
news
things
to
share
between
the
different
projects,
but
also
be
a
nice
way
introduction
for
anyone
new
to
the
project,
still
learning
about
what's
going
on
in
the
different
projects
and
where
they
might
get
involved
or
things
that
they
might
find
useful
in
in
the
rest
of
their
work.
A
I'm
brian
belindaur
executive
director
of
I'm
sorry,
the
general
manager
for
the
open
source
security
foundation
working
for
the
linux
foundation,
and
I
just
wanted
to
remind
everyone
that
the
meeting
is
being
recorded
and
we'll
be
posting
up
on
youtube.
As
we
start,
every
formal
meeting
at
every
linux
foundation
hosted
event,
there's
an
anti-trust
policy
that
applies
to
this
meeting.
I'm
sure
many
of
you
have
read
this
committed
it
to
memory
stenciled
it
on
the
back
of
your
eyelids.
A
I
do
encourage
you
to
check
it
out
if
you
haven't
before
it's
a
it's,
a
way
that
we
all
stay
clean
and
legal.
I
also,
I
am
happy
to
to
remind
you
all
of
the
code
of
conduct
at
the
open
source
security
foundation
and
the
linux
foundation
as
a
whole.
We
are
committed
to
providing
a
harassment,
free
experience
for
participants
at
all
of
our
events,
whether
they
are
held
in
person
or
virtually
seriously.
A
So
thank
you
for
your
attention
to
that
just
a
little
bit
of
housekeeping,
please
if
we're
using
the
webinar
format
and
the
moderated
q
a
function
on
that
just
to
try
to
make
the
q
a
part
of
this
really
efficient.
So
please
try
to
use
that
feature
on
zoom
to
ask
questions
and
I'll
play
the
role
of
kind
of
guiding
those
answers
to
the
right,
panelists
and
getting
those
questions
answered
and
anything
we
don't
get
around
answering
on.
A
This
call
we'll
try
to
answer
in
follow-up,
so
I
will
give
a
brief
organizational
update,
just
some
small
bits
of
news
and
then
really
dive
in
with
our
panelists,
into
updates
on
six
store
on
the
developer.
Best
practices,
working
group,
vulnerability,
disclosure,
securing
critical
projects
and
the
alpha
mega
project
and
my
hope,
my
goal
is:
we
leave
at
least
20
minutes
towards
of
the
of
the
hour
for
q,
a
and
open
discussion.
A
Let
me
give
that
quick
update.
You
know
it's.
It's
sometimes
hard
to
get
good
metrics
on
how
we're
doing
as
a
community,
but
you
know
some
of
you've
assembled
some
of
these
here
that
we
track
on
a
monthly
basis,
and
we
think
you
might
find
useful
we're
currently
up
to
60
sponsoring
organizations,
these
organizations
that
provide
the
funds
to
do
everything
we
need
to
do
here
and
and
reflect
some
of
that
back
out
to
to
all
of
you.
Their
current
active
members
are
60..
A
These
include
23,
premier
and
and
30
general
I'll
show
you
the
the
logos
and
seven
associate
as
they
come
up
very
happy
to
add.
Coinbase
alibaba
cloud
chain
guard
cloudsmith,
spotify,
open,
uk
and
mitre
as
new
members
just
recently,
and
I
should
also
mention
wipro,
I
forgot
to
add
them
here
as
well.
A
We
also
have
been
tracking
the
fundamentals
of
developing
secure
software
courses
at
edx
there
we
have
had
6
700
people
register,
for
that
course
those
three
courses-
sorry
60,
sorry
6,
700
registrations
for
those
courses.
We
are
really
some
big
ambitions
to
grow
that
substantially
this
year
and
we
think
that
we
just
continue
to
get
really
positive
feedback
from
folks
who
go
through
that.
As
you
know,
this
is
something
every
open
source
developer
should
know.
Frankly,
every
software
developer
should
know
our
engagement
through
the
community
has
climbed.
A
You
know
pretty
gradually
up
about
10
percent
over
the
last
month
in
in
the
mailing
list,
membership
and
visits
to
the
websites
and
those
sorts
of
things.
So
so
pretty
nice
and
active
continuing
to
build
some
steady
progress
on
our
engagement
with
the
world.
Here's
the
list
of
current
supporters
at
the
premier
level,
their
their
resources,
give
us
their
financial
support
as
well
as
their
guidance
gives
us
the
ability
to
go
out
and
have
the
kind
of
impact
we
want
to
have
in
the
world.
A
So
thank
you
to
all
of
these,
including
those
who
have
recently
joined
and
thank
you
as
well
to
to
those
organizations
that
have
been
providing
even
brought
more
broad-based
support,
really
happy
to
see
the
breadth
of
different
kinds
of
organizations
represented
here,
different
geographies,
different
industries
and
also
really
happy
to
have
now.
A
You
know,
reasserted
our
partnership
with
open,
uk
and
added
mitre
to
the
list
of
our
associate
members.
So
thank
you
all
for
that
really
quickly
as
well.
We
recently
had
a
tech
election
and
have
seeded
the
new
attack.
This
is
the
technical
advisory
council.
A
This
is
really
you
know
the
the
group
who
are
chartered
with
overseeing
broadly
the
technical
initiatives
at
the
open,
ssf
and
making
sure
that
they
hold
up
to
a
high
standard
and
are
working
together
across
the
different
working
groups
and
projects
at
the
open,
ssf
wherever
possible,
so
congrats
to
avi
shakarya,
eva
black
bob
callaway,
krobe,
robinson
dan
lawrence
josh,
brushers
and
luke
hines,
many
of
whom
you
will
hear
from
in
just
a
few
minutes,
also
welcome
back
to
in
coldwater
as
the
security
community
individual
representative
to
the
governing
board.
A
Both
of
these
are
both
attack
and
the
scir
are
elected
positions.
So
thank
you
as
well
to
everybody
who
ran
in
those
two
elections
and
to
everyone
who
voted
and
participated.
A
It
was
the
technical
community
who
participated
based
on
those
who
had
contributed
in
some
way
in
any
way,
actually
to
the
open
ssf
over
the
last
year
also
wanted
to
highlight
that
supply
chain
security
con,
which
is
started,
started
life
as
a
one
day
event
at
the
cloud
native
summits,
as
now
graduated
to
become
a
parallel
event
to
the
linux
foundation's
open
source
summit,
our
main
kind
of
industry
or
open
source
industry-wide
event
that
is
back
to
taking
place
face-to-face
in
austin
june
21st
to
24th
so
supply
chain.
A
Security.Com
will
be
there.
I
think,
have
two
days
of
content.
The
call
for
the
cfp
is
open
now
and
closes
pretty
soon.
I
think
so.
So
please,
please
check
that
out
and
participate
if
you
can
and
with
that
I'd
like
to
pass
the
microphone
to
priya,
who
can
lead
us
through
an
update
on
project,
sig,
store
and
priya
I'll
advance.
The
slides,
just
kind
of
you
know,
send
me
a
buzzer
or
mention
when
you
want
me
to
advance
okay.
B
Cool,
thank
you
so
much
yeah,
so
I'll
give
a
quick
update
on
project
six
store,
so
we're
working
on
general
availability
for
six
store
right
now,
which
I
will
talk
about
more
in
the
upcoming
slides.
So
I'm
gonna
move
on
right
now.
We
recently
hit
1.5
million
log
entries
in
record,
which
is
exciting.
I
think
almost
half
a
million
of
those
just
happened
in
the
past
couple
months,
so
I
think
usage
is
definitely
growing.
B
B
We
also
have
a
kubernetes
cap
cap,
three
zero,
three
one
almost
finished,
and
with
that
we
should
have
kubernetes
one
point:
two
four
signed
with
six
store
and
cosign
so
and
users
of
kubernetes
can
start
verifying
the
images
produced
by
kubernetes
yeah
thanks
so
to
get
more
into
six
store,
ga
a
little
bit
the
goals
of
cigar
ga
are
to
get
all
of
the
majors
extraordinary
projects,
cosine
record
and
folsio
to
1.0
status.
B
So
this
one
is
pretty
easy
for
cosine
because
we
already
achieved
1.0
a
few
months
ago,
but
we
still
need
to
get
there
for
recoil
and
full
co.
So
a
lot
of
this
work
is
going
to
be
around
getting
recoil
and
full
co
production
ready
and
stable
we're
hoping
to
be
able
to
tell
users
that
they
can
expect
99.9
uptime,
and
once
that's
done,
we
can
remove
all
the
scary
experimental
warnings
that
we
have
in
cosign
and
other
tools
around
using
full
cio
and
recore
right
now.
B
So
focus
areas
for
our
ga
work.
The
big
ones
are
infrastructure
and
testing,
and
once
those
are
done,
we're
going
to
look
into
the
documentation
and
also
individually
at
the
projects,
adding
any
features
or
fixing
any
bugs
that
might
need
to
be
fixed.
So
that's
going
to
be
full
zero,
recording,
cosine.
B
So
to
talk
about
the
like
infrastructure
and
testing
work
that
we're
doing
at
the
moment,
the
big
one
is
automation
in
the
past
year.
I
think
we
haven't
really
focused
too
much
on
automating
a
lot
of
a
lot
of
the
infrastructure
behind
six
stores,
so
that's
kind
of
the
main
focus
right
now.
This
includes
stuff
like
cutting
and
deploying
releases
setting
up
a
staging
environment
and
automating
impermissions
for
the
gcp
project
that
production
runs
in
so
that
we
can
kind
of
have
like
a.
B
We
can
see
the
history
behind
who
has
access
to
the
project
in
version
control,
we're
also
planning
on
setting
up
monitoring
for
the
different
background
services
that
we
rely
on
and
alerting
on
those
services
with
alerts
slack
so
that
the
community
can
see
if
anything
is
wrong
and
we're
also
planning
on
setting
up
progress
on
github
actions
so
that,
if
anything
goes
wrong
with
tcp,
we
should.
B
We
should
be
informed
of
it
pretty
quickly
in
terms
of
testing
we're
looking
at
load
testing,
possibly
in
record
before
we
announce
their
1.0
and
in
more
generally,
a
comprehensive
review
of
unit
and
integration
tests
for
all
three
projects.
B
In
terms
of
the
specific
projects
themselves,
there's
not
too
much
work
that
needs
to
happen
here
for
cosign
is
pretty
easy.
We
just
have
to
eventually
remove
experimental
warnings
once
everything
is
stable,
we're
planning
on
looking
at
rate,
limiting
for
both
the
record
and
full
cio
services
and
adding
log
charting
to
recore,
and
once
these
features
are
kind
of
done,
we
should
be
able
to
announce
report,
1.0
and
full
co
1.0,
which
will
come,
which
will
come
with
some
api
stability
guarantees
and
will
help
us
prepare
for
ga.
B
Also
in
progress
alongside
all
of
this
work,
we're
getting
a
third-party
security
audit
done
from
a
third-party
company
and
planning
some
sort
of
on-call
system,
so
that,
once
we've
announced
ga
people
who
are
relying
on
the
public
instances
of
these
services
can
kind
of
be
sure
that
if
something
does
go
wrong,
there
will
be
some
system
available
to
get
things
fixed
as
soon
as
possible.
B
So
how
long
is
this
all
going
to
take?
I
love
this
in
my
blank
because
we're
not
totally
sure
just
yet
right
now,
the
the
goal
is
around
two
months,
but
because
you
also
are
doing
the
security
audit,
it's
kind
of
I'm
kind
of
anticipating
that
they
will
hopefully
not
find
too
many
things
that
we
need
to
fix,
but
there's
always
a
chance,
we'll
find
a
lot
of
things
that
we
need
to
fix.
B
B
I
just
want
to
say
a
quick
thank
you
to
all
the
ga
contributors
who
have
who've
been
helping
with
this
effort.
I'm
sure
this
list
is
gonna,
get
bigger
in
the
coming
two
months,
if
anybody's
interested
in
working
on
ga
or
has
questions
I'd
liked,
the
project
planner
or
the
design
doc
on
this
slide,
yeah
feel
free
to
ping
me
on
slack.
If
you're
interested.
A
Thank
you,
priya,
and
I
know
since
there's
some
names,
I
don't
recognize
on
the
attendee
list.
Some
folks
might
not
be
even
familiar
with
six
story.
What's
like
the
one
sentence,
pull
full
description
of
sig
story
just
for
those
who
might
be
curious
and
then
secondly,
I
know
there's
been
some
signs
of
interesting
adoption
out
there,
particularly
the
cloud
native
community.
Is
there
any
anything
you
can
give
as
like
a
stat
or
a
number
of
signatures
made
in
the
during
the
pilot
or
anything
like
that.
B
Yeah,
so
to
one
sentence,
description
of
six
store,
I
would
say
that
c
store
may
exciting.
Verifying
software
opens
our
software
easy
and
simple,
so
it's
kind
of
making
things
secure
by
default
and
making
that,
like
the
easiest
way
easiest
way.
So
I
would
say:
that's
like
the
one
sentence
description
in
terms
of
a
stat.
I
don't
have
one
off
the
top
of
my
head.
I'm
really
sorry.
A
No
okay,
I'm
sorry
it's
hard
to
spend
that
on
you,
but
but
I've
just
I've
been
following.
Obviously
the
twitter
feed
and
the
project
from
the
outside,
and
it's
really
exciting,
to
see
a
number
of
projects
that
that
even
even
in
its
pre-1.0
state,
have
picked
it
up
and
started
to
go
with
it.
So
that's
that's
really
cool
to
see.
I'm
really
glad
that
we're
finding
that
the
security
audit
work
through
austif
and
looking
forward
to
what
that
returns
and
don't
worry.
A
If
somebody
will
find
a
bug
in
the
1.0
release,
you'll
have
to
do
one
one:
zero
one,
one
zero,
two
one
dot
one
even
like
they
say.
If,
if
you
didn't
find
a
bug,
you
know
if
you,
if
you,
if
you
wait
till
it's
perfect,
you
wait.
You've
waited
too
long
to
if
you're,
not
embarrassed
by
your
1.0.
You've
waited
too
long.
C
A
Release
it,
that
was
the
quote-
I
remember
so
so
congrats
to
everybody,
who's
been
working
towards
that
that
goal
and
and
really
happy
to
see
thanks
and
we're
going
to
save
questions
to
the
end.
So
if
you've
got
some
questions
about
this,
certainly
cue
them
up
in
the
q,
a
so
priya.
Thank
you
and
we'll
come
back
to
you
soon.
Now,
let's
move
on
to
the
developer
best
practices,
the
the
working
group
focused
on
that
and
krobe.
Can
you
lead
us
through
these
this
status.
D
I
would
love
to
hey
everybody.
I'm
krobe.
I
have
the
amazing
honor
to
represent
the
folks
that
work
on
developer
best
practices.
If
you
haven't
guessed,
our
working
group
is
focused
on
helping
open
source
developers,
learn
some
good
security
practices
and
improve
the
overall
quality
of
their
code
and
projects.
D
We
have
six
core
projects
within
the
working
group
and
there's
a
little
reference
architecture,
kind
of
showing
how
we
all
relate.
We
divide
our
work
up
into
things
that
help
people
learn
things
that
help
developers
identify
good
practices
and
then,
finally,
a
quadrant
where
we
help
the
developers
adopt
these
kind
of
new
good
practices.
D
Our
six
core
projects
are
the
common
requirements,
enumeration
project
which
is
designed
to
help
identify
requirements
like
853,
for
example,
it's
a
list
of
requirements
that
developers
might
want
to
consider
as
they
are
building
their
projects.
We
have
the
existing
guidelines
for
developing
and
distributing
secure
software.
This
is
a
kind
of
a
rosetta
stone
of
where
all
the
really
great
knowledge
is
across
the
internet
of
how
to
write
code
securely
and
tools
that
can
help
you
do
that
and
broken
down
by
language.
D
Badge
formally
was
the
cii
best
practices
badge,
but
david
got
smart
and
we're
part
of
the
open,
ssf
now
yay
us-
and
this
is
a
badge
that
helps
identify
good
practices.
We
work
with
projects
to
help
them
implement
this
and
we
give
them
a
fancy
little
badge
depending
on
you
know
how
well
they
are
able
to
adhere
to
these
great
coding
practices.
D
We
have
a
scorecards
project,
which
is
an
automated
way
to
help
collect
a
bunch
of
statistics
around
open
source
projects.
We
have
the
edx
course
that
brian
mentioned,
which
is
around
secure
software
development
fundamentals,
amazing
work.
I
encourage
everyone
developers
or
not
to
take
a
look
at
it.
You'll
learn
a
lot
and
then
finally,
we
have
the
skf
the
security
knowledge
framework.
This
is
a
lab
environment
that
helps
developers
practice,
and
you
know
what
they've
learned
throughout
all
these
different
elements:
how
to
do
secure
coding
in
real
life
next
slide.
Please.
D
D
Another
note
our
skf
project
just
recently
had
we
went
over
70
different
developer
labs
for
node.js
python
and
java
that
developers
can
kind
of
go
through
and
learn
these
skills
very
exciting.
We
just
recently
took
on
some
work
where
we're
working
with
the
npm
security
team
to
help
develop
an
npm
security
best
practice
guide.
D
We're
really
excited
about
that
collaboration
and
then,
finally,
our
scorecards
project
launched
version
four
in
february,
so
you
know
cosign
you'll
get
there
someday,
but
scorecards
is
doing
a
great
job
tracking,
a
lot
of
different
metrics
and
automated
fashion,
helping
consumers
kind
of
understand
what
some
of
the
security
qualities
are
of
these
different
projects,
and
my
final
slide
for
this
group,
which
is
probably
my
favorite
working
group
of
all
just
so
you
know
our
upcoming
projects
is.
D
We
have
we're
working
on
also
some
recommended
compiler
option
flags
for
c
and
c
plus
programs
pretty
exciting.
We
think
this
will
be
very
useful
since
a
lot
of
code
in
the
open
source
ecosystem
is
done
in
c
we're
working
on
a
newbies
view.
We're
gonna
have
some
interactive
artwork
that
kind
of
walks
the
developer
journey
through
code
from
kind
of
imagination
out
through
deployment
and
at
each
stage
we're
to
have
links
to
different
tools
and
practices.
D
You
know
understand
I'm
in
this
particular
stage
of
developing
and
I'd
like
to
know
kind
of
what
resources
and
tools
are
available
for
me:
we're
working
on
package
manager,
best
practices,
document
kind
of
overall,
looking
at
the
different
ecosystem
package
managers
and
trying
to
find
good
guidance
to
help
people
you
know,
do
things
in
secure
ways
and
then
finally
we're
working
on
a
the
second
convention.
This
is
a
way
to
help
identify
when
a
commit
message
in
a
repository
has
a
security
property.
D
So
it's
a
standard
we're
trying
to
help
encourage
people
to
use
that
way.
Automation
can
more
easily
identify
this
code.
Change
was
security
related
and
there's,
potentially
additional
actions
that
need
taken.
So
I
encourage
you
to
check
out
all
of
our
projects
and,
if
anyone's
interested
you
know
come
help
us
out
with
this
upcoming
work,
got
an
exciting
docket
for
the
year
and
always
looking
for
help.
D
Oh
next
up
is
my
favorite
working
group,
the
vulnerability
disclosures
working
group.
This
is
a
amazing
group
of
folks
that
I
get
to
work
with
where
we're
focused
on
improving
coordinated
vulnerability,
disclosure
practices
within
open
source.
We
have
a
couple
projects.
First
off,
we
recently
published
a
guide
to
cvd
for
oss
projects,
which
we'll
talk
about
just
in
a
moment.
D
We
are
working
on
a
white
paper
kind
of
just
talking
about
recommendations
overall
for
how
cvd
coordinated
vulnerability
disclosure
can
be
done
within
the
open
source
community,
and
then
we
also
curate
a
set
of
personas
and
we're
working
on
kind
of
exploring
the
pain
points
between
these
different
personas
within
open
source.
So
we
have
maintainers.
D
We
have
security
researchers
which
are
called
finders.
We
have
suppliers,
consumers
and
coordinators.
So
all
these
different
personas
within
the
open
source
ecosystem
have
a
particular
perspective.
They
have
needs
and
wants,
and
there's
also
potentially,
some
friction.
You
might
think
about
some
friction
between
maintainers
and
security
researchers,
so
we're
trying
to
identify
those
problems
and
find
unique
ways
to
help
solve
some
of
those
next
slide.
Please.
D
So
recent
achievements
we've
been
working
quite
a
lot
last
year
with
the
cve
board.
These
are
the
folks
that
help
kind
of
manage
the
cve
process
for
the
industry
and
we've
been
working
with
them
and
we
kind
of
expressed
some
up.
Typo
cbd.
We've
discussed
kind
of
open
source
perspectives
around
cvd
and
some
pain
points
we
had
and
some
requirements.
We
learned
a
lot
about
the
improvements
that
that
program
has
made
over
the
year
and
what
they're
planning
on
doing
in
2023.
D
So
we're
very
excited
so
hopefully
we'll
see
a
much
better
vulnerability
identifier
low
in
the
next
coming
year,
and
then,
as
I
mentioned,
we
published
a
1.0
draft
of
our
guide
to
coordinated
vulnerability
disclosure
for
open
source
projects.
So
this
is
a
template
and
a
set
of
resources
that
any
project
you
know
one
person
project
all
the
way
up
to
you
know
huge
ecosystems,
like
you,
know,
kubernetes
style
project
where
folks
can
take
this
look
at
the
guide
and
potentially
adopt
some
of
its
practices,
so
that
really
helps
ease.
D
D
Finally,
this
year,
lots
and
lots
of
activity
we'll
be
changing
our
attention
from
maintainers,
which
we
love
maintainers,
to
that
other
persona
group
that
those
finders
or
security
researchers,
so
we're
going
to
be
figuring
out
a
way
to
figure,
create
a
guide
for
cvd
to
help
security.
Researchers
better,
engage
with
open
source
projects,
there's
a
lot
of
misconceptions,
and
we
think
we
can
spell
this
out
and
help
again
ease
that
process
so
that
all
users
of
open
source
are
best
served
when
a
finder
finds
something
we'll
be
continuing
to
meet
with
cert
cc.
D
Hopefully
in
talking
about
their
vince,
coordinated
vulnerabilities
disclosure
program
and
their
plans
on
open
sourcing
that
a
bunch
of
us
are
presenting
at
the
foss
backstage
conference
talking
about
zero
days
within
open
source
and
open
source
cbd.
Very
excited
so
check
that
out
in
march,
if
you're
interested
we're
gonna
be
working
on
a
survey
to
help
learn
how
the
working
group
can
assist
open
source
projects.
So
we're
going
to
be
reaching
out
to
a
bunch
of
maintainers
predominantly
through
the
securing
critical
projects
working
group
list,
but
we'll
be
open.
D
We
will
be
collaborating
with
the
omega
project
on
kind
of
helping
codify
cbd,
good
practices,
and
how
folks
can
you
know
best,
react
and
vulnerabilities
are
found
and
then
we'll
also
be
working
on
vulnerability
report
formats
this
year,
and
with
that
you
know.
Thank
you
from
the
developer
best
practices
group
and
the
vulnerability
group
robot.
A
E
Yes,
hello
good
morning,
everybody
just
a
couple
updates
on
the
securing
critical
projects.
Work
group
that
myself
and
jeff
mendoza
from
google
co-chair
a
couple
updates
since
november.
E
The
first
main
one
is:
we
created
an
initial
short
list
of
the
most
critical
projects,
with
the
objective
of
that
to
be
to
help
inform
other
other
work
groups
and
projects
in
open
ssf,
namely
project
alpha
omega
and
the
great
mfa
project.
So,
with
the
great
mfa
project,
you
just
heard
yes
from
krobe.
Thankfully
we
were
able
to
help
with
that.
E
We
set
a
goal
as
a
work
group
to
complete
that
kind
of
to
complete
that
list
in
about
two
weeks,
so
it
was
about
two
working
sessions
with
the
work
group
and
a
little
bit
of
work
offline.
Some
caveats:
it
was
not
meant
to
be
comprehensive
due
to
time
constraints.
We
didn't
want
to,
let
perfect
be
the
enemy
of
good
and
we
wanted
to
get
something
out
to
help
to
help
these
projects
and
the
initial
output
did
help
the
great
mfa
project
reps
to
to
identify
some
of
those
projects.
E
So
I
think
that
was
a
great
thing
that
we
were
able
to
kind
of
collaborate
within
openssf
and
help
and
support
other
working
groups
and,
in
the
meantime,
do
something
you
know
very,
very
important
to
to
our
working
group
as
well,
and
that
and
as
well
so
the
that
list
of
projects
to
help
project
alpha
to
help
inform
decision
making
and
just
to
provide
a
little
bit
of
insight
onto
where
resources
could
or
should
be
allocated
to.
E
And
we
did
complete
a
rough
initial
short
list
of
100
critical
projects
that
can
be
accessed
by
anybody.
The
intention
was
for
it
to
be
iterative,
the
list
to
be
iterative,
both
qualitative
and
quantitative.
We
used
tools
such
as
the
security
score
cards
project,
as
well
as
criticality
score
and
for
the
qualitative
piece
we
tried
to
really
discuss
as
a
work
group
the
the
the
projects
that
were
that
were
being
recommended
for
this
list,
as
well
as
community
driven.
E
We
wanted
it
to
be
a
process
where
anybody
in
the
work
group,
in
openssf
or
in
the
open
source
community
at
large,
could
essentially
nominate
or
suggest
something
for
consideration
and-
and
as
mentioned
earlier,
we
did
complete
the
first
draft
in
time.
E
So
I
want
to
give
a
big
thank
you
to
the
work
group
to
the
working
group
for
coming
together
and
really
all
hands
on
deck
and
focusing
on
getting
this
out
in
time,
and
so
since
january,
we've
been
refining
that
process
for
a
more
comprehensive
and
representative
list
of
the
most
critical
projects,
so
that
will
include
developing
further
to
prioritize
and
rank
projects.
E
We
would
love
to
to
have
a
way
to
find
those
projects
from
the
famous
graphic
of
you
know
all
of
modern
infrastructure.
You
have
that
one
project
so
hopefully
we'll
be
able
to
prove
to
shed
some
light
onto
those
projects
and,
as
mentioned
earlier,
it's
meant
to
be
iterative,
so
we
want
to
iterate
and
improve
on
this
process
and
also
awaiting
the
release
of
the
full
census,
2
project
results,
which
I
believe
are
coming
out
in
under
a
month.
E
Other
updates,
as
well
through
this
through
this
carrying
critical
projects,
work
group,
open
source
technology
improvement
fund.
Ostiff
was
briefly
mentioned
in
the
last
town
hall,
but
oh
stiff
did
facilitate
a
security
review
of
the
flux
project
that
one
was
funded
by
cncf,
which
resulted
in
22
security
improvements,
including
the
reporting
and
patching
of
the
project's
first
cve,
and
that
all
of
that
can
be
found
both
on
austin's
website,
as
well
as
the
security
reviews.
E
Repo
that,
I
believe,
michael,
is
going
to
discuss
shortly,
as
well
as
actively
facilitating
about
15
security
engagements
right
now
for
critical,
open
source
projects.
We
also
have
the
all-star
security
policy
bot.
That
is
the
project
that
my
co-chair
jeff
runs
some
announcements
on
that
it.
It
has
now
been
installed
on
over
20,
000
repos
and
scanned
over
20
000
repos
and
over
400
organizations,
and
has
been
enabled
on
2
000,
unique
repos
in
over
100
organizations.
E
So
again,
I
want
to
really
thank
everybody
in
the
work
group
for
coming
together.
We
typically
get
very
good
lively
discussions
and
a
good
good
turn.
A
good
show.
Every
a
lot
of
people
show
up
and
we
get
good
discussions
from
that.
So
big,
thank
you
to
everyone
from
the
work
group
and
thank
you
to
all
of
you.
E
If
you
have
any
questions
at
the
end
or
would
like
to
get
involved
in
anything
that
I
have
mentioned,
feel
free
to
join
a
working
group
meeting,
we
love
seeing
new
faces
and
getting
new
perspectives
so
yeah.
We
look
forward
to
seeing
from
you
and
hearing
from
you
and
with
that
I'm
done.
Thank
you
so
much
brian
and
everybody.
F
Awesome
hi
everybody
good
morning.
My
name
is
mike
scaveta.
I
lead
the
identifying
security
threats
working
group,
I'm
here
to
talk
to
you
about
about
that.
So
we've
been
kind
of
top-level
working
group
since,
since
the
beginning
we
have
probably,
I
would
say
four
four
main
projects.
We
have
a
couple
other
things
kind
of
in
incubation
that
are
just
kind
of
percolating
at
this
point,
but
the
main
ones
are
are
in
no
particular
order
security
insights.
F
This
is
work
led
by
luigi,
and
the
purpose
here
is
to
you
know,
make
a
machine,
readable
security
information
that
for
things
that
are
hard
to
detect.
So
as
an
example,
you
know,
if
you
have
a
github
repository
and
you
distribute
on
npm,
there's,
usually
a
pointer
from
npm
back
to
github,
but
there
often
isn't
a
pointer
from
github
to
npm
understanding
that
and
being
able
to
express
that
in.
F
We
think
provides
some
value,
so
this
is
still
in
the
in
the
kind
of
design
and
kind
of
early
incubation
phase,
but
we
think
it
has
it
meets
and
meets
a
need
where
automation
is
just
either
not
there
or
not
possible
next
project
is
security
reviews.
This
is
a
collection
of
public
security
reviews
against
open
source
projects.
F
I
think
amir,
I
think
we
have
about
35
or
so
on
the
site
right
now,
there's
a
dashboard
and
we
we're
looking
to
collect
more
and
and
amir
is
leading
this
leaving
this
project
there's
been
some
automation
to
create
a
fancier
view
of
it.
So
you
don't
have
to
actually
look
through
the
repository
itself
and
we're
looking
to
continue
having
this
integrated
into,
for
example,
the
the
next
one,
the
security
metrics,
the
security
reviews
are
displayed
within
the
security
metrics
dashboard.
F
We
want
to
continue
that
process
where
this
information
is
available
to
to
dashboards
and
projects
that
that
display
things
like
this
security
metrics.
This
is
metrics.openssf.org.
F
This
was
an
aggregation
layer
for
different
sources,
so
it
pulls
together,
scorecard
criticality,
best
practice,
security
reviews
and
and
assembles
that
as
one
kind
of
view
of
a
project.
This
was
done
as
a
kind
of
a
proof
of
concept.
We
made
it
kind
of
mvp-ish
it.
It's
pretty
clear
at
this
point
that
the
right
thing
to
do
is
probably
to
replace
it
with
either
lfx
security
in
the
kind
of
medium
term
or
another
kind
of
aggregation
layer.
That's
like
fully
supported
and
not
kind
of
a
side
thing.
F
We
also
don't
need
multiple
aggregation
layers
doing
exactly
the
same
work.
So
I'm
happy
to
you
know
eventually
deprecate
this
in
in
favor
of
a
better
solution
and
then
finally
alpha
omega,
which,
if
you
skip
to
the
next
slide,
we're
we'll
likely
right
now.
Alpha
omega
is
you
know,
kind
of
de
facto
under
the
identifying
security
threats
working
group
it?
I
think
it
makes
sense
for
it
to
be
a
top
level.
F
You
know
project,
but
the
purpose
of
alpha
omega
is
to
protect
society
by
improving
the
security
of
the
open
source
software
that
everybody
uses,
but
we-
and
we
do
this
through
direct
maintainer
engagement
and
expert
analysis.
So
this
is
different
fundamentally
than
a
lot
of
the
other
work,
and
I
think
it's
complementary
to
to
to
the
others
where
it's
it's,
it's
not
about
producing
better
education,
that
re
that
results
in
better
software
or
measuring
things
that
entice
and
and-
and
you
know,
pressure
maintainers
to
to
configure
something
some
way.
F
But
it's
actually
going
after
the
source
code
and
saying:
is
this
thing
secure
or
not?
And
if
not
helping
helping
it
be
secure
next
slide,
so
we
officially
launched
at
the
beginning
of
the
month.
I
leave
this
with
michael
windsor,
from
google
and
and
brian
right
now
we're
hiring
full-time
roles.
So
we
have,
I
think,
brian.
I
think
we
have
five
on
the
list,
so
I
think
it's
a
product
manager,
a
project
manager,
security,
engineer
and
two
analysts.
F
It's
something
like
that:
we're
working
through
the
job
descriptions
and
we're
I'm
hoping
to
get
the
job
descriptions
public
in
the
next
couple
weeks,
we're
also
working
on
governance,
because
we
realize
that
you
know,
because
this
is
a
fully
funded
project.
It
needs
to
have
some
structure
around
how
we
make
decisions,
so
I'm
super
thankful
to
ann
bertucci
and
and
ava
black
on
helping
us
produce
a
a
governance
model
that
works
and
is
also
flexible,
but
kind
of
achieves
the
transparency
that
we
need
we're.
F
Looking
at
initial
alpha
engagements
on
at
least
one
probably
two
major
projects
that
we
can
engage
deeply
on
over
the
next
year,
starting
soon
you
know
so
as
soon
as
we
can
and
we
are
refining
the
initial
omega
tool
chain,
analysis
workflow.
All
of
that
a
lot
of
this
work
is
dependent
on
getting
these
full-time
roles
hired.
F
This
is
this
is
very
much
a
nine-to-five
level
job
that
is
kind
of
very
difficult
to
do.
With
this
kind
of
thing,
it
needs
fewer
people
with
more
time
and
not
more
people
with
less
time.
So
if
you're
interested
in
learning
more
about
this,
we
I
mean
obviously
there's
the
press
release.
We
did
a
webinar
a
webinar
last
week.
Welcome
to
do
that.
Join
us
on
slack,
join
the
announcements
panel
list,
as
we
have
things
to
announce,
we'll
announce
them
there
for
out
for
the
slack
channel
come
ask
questions.
F
I
think.
That's
it
next
slide.
F
F
A
Yeah,
so
thank
you
to
all
the
presenters
for
going
through
quickly
through
their
sessions.
I'm
gonna
leave
this
slide
up
just
in
the
background,
so
folks
can
see
that
if
they
need
the
links,
obviously
these
slides
will
put
up
on
the
same
on
the
town
hall
page,
along
with
the
recording
of
this
session,
when
we're
done
still
definitely
interested
in
more
questions.
A
So,
as
things
come
to
you,
based
on
any
of
the
content
that
we
talked
about
or
even
other
topics
related
to
openssf,
please
feel
free
to
submit
them
into
the
q
a
box.
But
I'd
like
to
take
on
the
the
the
one
question
we've
got
in
that
q
a
box.
Now
we
can
also
get
to
mootoo's
question.
He
asked
him
chat
back
and
forth,
but
to
start
with
luke's
question
luke:
do
you
want
to
unmute?
C
C
A
key
aspect
to
their
security
is
their
build
system
security,
how
they're
generating
releases?
Okay,
how
they're
getting
those
releases
to
the
end
users
we've
got
project
six
store
in
the
open
ssf.
Now
so
has
it
ever
been
considered,
or
would
it
be
considered
that
those
projects
could
be
supported
in
being
onboarded
to
use
in
six
store.
E
I
could
I
could
take
a
first
stab
at
an
answer.
Thank
you
for
the
question
luke.
I
would
say
so.
Yes,
as
as
more,
I
would
say,
formal
kind
of
documentation
and
and
excuse
me
as
more
formal
documentation
and
recommendations
are
being
developed,
as
you
know,
actual
resources
and
materials
that
we
could
hand
projects
similar
to
the
like
the
vulnerability
disclosure
guide
that
krobe
was
talking
about.
E
E
I
think
it
makes
sense
to
as
part
of
the
stage
that
involves
reviewing
the
release
and
build
system,
and
things
like
that
to
you
know
if,
if
they're
not
using
anything,
for
example,
to
recommend
a
tool
like
six
store,
so
I
would
say
so:
yes,
it
would
definitely
make
sense
to
incorporate
these
tools
and
these
these
tools
and
these
guides
into
the
actual
projects
so
that
they
can
adopt
these
tools
and
use
them
and
and
become
more
secure
as
a
process,
I
would
say
anyone
else.
You
have
anything.
F
So
so
just
add
to
that
I
think
for
alpha
omega,
yes
as
well,
I
don't
want
to
preclude
that.
Sig
store
is
a
requirement,
but
as
for
for
alpha
as
we're
as
we're
talking
about
things,
naturally
the
security,
the
build
system
and-
and
you
know,
integrity
and
things
like
that-
would
come
up
and
sig
store
being
a
good
option
for
most
projects
to
you
know
improve
that.
I
think
that
that
would
just
naturally
come
out
of
there
omega.
F
Similarly,
as
we
leave
projects,
we
will
we
have
a
leave
behind
packet
or
work
on
a
leave
behind
packet,
which
would
include
things
like
hey
click
here
and
do
this
thing
to
set
up
sig
store.
So
that
said,
I
think
another
approach
might
be
to
go
after
kind
of
instead
of
doing
deep,
dives
on
on
a
single.
You
know,
project
number
one
you
go
after
all,
100
and
more
of
a
horizontal
slice
and
say:
can
we
get
all
hundred
just
on
board
to
sig
store
through
some
sort
of
a
campaign?
F
A
Taken
that
one
one
thing
from
the
from
from
our
perspective,
we
have
resources
to
be
able
to
help
with
a
number
of
things
that
that
help
high
quality
software
high
quality
services,
the
kind
of
stuff
we're
building
at
openness
is
that
reach
a
broader
audience
that
we're
really
eager
to
look
for
how
to
use
whether
it's
helping
with
documentation
and
by
helping
I
mean,
potentially
paying
people
to
do
this
stuff.
A
Because
I
know
that's,
like
you
know,
I
normally
you
want
folks
to
volunteer,
and
we
certainly
love
volunteers
to
help
us
with
this
too,
but
I'm.
I
would
really
look
forward
to
finding
ways
that
we
could
work
with
the
different
working
groups
and
their
subprojects
on
what
what
are
ways
that
we
could
help
expand
the
number
of
people
who
might
pick
this
up
by
marketing
and
promotion
and
funding
the
development
of
tutorials
and
better
docs
getting
stuff
placed
in
blogs.
Getting
people
to
speak
at
conferences.
I
mean
all
the
kind
of
outreach.
A
That's
that's
really
necessary
specific
to
this
kind
of
stuff
to
sig
store.
I
think
it's
also
lines
up
with
this,
too,
is
how
do
we
get
the
stuff
baked
into
the
the
the
tooling
into
the
build
tooling
and
and
working
with
the
package
managers
to
get
them
to
look
for
this
stuff,
and
even
you
know
to
consume
it,
to
publish
it
and
then
maybe
there's
like
a
last
mile,
which
is
actually
showing
up
to
major
projects.
A
You
know
identified
by
the
critical
projects
list
and
even
beyond
and
saying
here's
a
pull
request
that
adds
support
for
this
to
to
your
systems
and
we'll
stick
around
to
make
sure
it
works,
and-
and
you
know
it's
not
just
like
a
drive-by
but
but
you
know,
I
I
think
there.
All
of
these
things
are
important.
High-Quality
software
doesn't
sell
itself,
you
know.
Sometimes
it
does.
A
Sometimes
we
look
out,
but
I,
generally
speaking
especially
these
days,
you
have
to
kind
of
rise
above
the
noise
floor
with
a
lot
of
this
stuff,
and
so
I'm
very
eager
to
find
ways
for
us
to
be
helpful
in
across
the
different
open
south
projects
to
go
and
tackle
that.
A
So
all
right,
I
would
mutu
and
I'd
like
to
unmute
and
ask
his
question
verbally
and
then
and
then
I
know,
there's
been
some
answering
on
the
already
over
chat,
but
but
just
so,
we
captured
for
the
recording
and
like
way
too.
G
All
right,
thanks
brian,
this
is
mutter
from
dtcc
yeah.
I
like
to
understand
a
little
more
about
the
os
vulnerability
disclosure,
how
it
works
and
does
it
even
get
reported
to
right
because
for
us,
for
instance,
right
from
our
ecosystem,
we
use
a
product
from
stone
type
nexus,
that's
fully
integrated
into
our
devsecops
and
that's
how
our
developers
consume
the
open
source
that
they
need.
D
So,
as
I
jokingly
said,
how
much
time
do
you
have
I've
been
involved
in
the
open
source,
vulnerability
space
for
seven
eight
years
now,
and
I
still
learn
something
new
every
day
at
its
most
basic
level,
somebody
finds
a
problem
and
tr
attempts
to
report
it
to
the
responsible
party,
the
maintainer,
the
project,
and
that
that
maintainer
reviews
that
defect
report
and
either
agrees
with
it.
Yes,
this
is
a
bug.
D
It's
a
security
bug,
I'm
going
to
fix
it
or
not
and
closes
it,
and
then
they
will
produce
a
patch
and
work
within
their
community
to
make
sure
everyone
has
access
to
the
patch,
and
then
they
will
go
public
and,
as
I
mentioned
also
in
my
typing,
there
are
as
many
ways
that
story
happens
as
there
are
as
many
different,
beautiful
and
diverse
people
here
on
this
call,
every
project
every
community
does
things
slightly
differently:
how
in
nvd
the
national
vulnerability
database
is
a
entity
run
by
mitre
in
the
united
states.
D
There
are
several
other
of
these
vulnerability,
aggregation
databases,
but
nvd
is
the
most
famous
and
nvd
gets
their
information
from
the
mitre
cve
database.
So
when
a
cve
is
recorded,
so
when
that
maintainer
agrees
yes,
this
is
an
issue.
This
is
a
problem
I'm
going
to
physically
I'm
going
to
fix
it.
D
They
get
a
cve
and
that's
when
that
gets
recorded
by
miter
and
gets
pushed
over
to
things
like
the
nvd,
the
open,
the
maintainer
itself,
rarely
directly
communicates
with
these
aggregators,
and
then
you
have
third
parties
like
a
black
duck
or
a
sonotype
that
are
scraping.
Not
only
databases
like
the
nvd
europe
has
one.
China
has
one
there's
many
of
them.
D
Some
of
these
companies
maintain
their
own
data
where
they
will
follow
projects
and
scrape
you
know
their
github
for
commits,
for
example,
there's
a
lot
of
different
ways.
This
happens,
but
typically
when
an
open
source
community
has
a
vulnerability,
they
make
sure
that
everyone
that
is
participating
in
that
community,
that
has
a
need
to
know
is
informed
so
that
they
can
take
action
and
that
gets
pushed
out
publicly
and
then
downstream
needs
to
take
that
patch
and
react
to
it
and
patch
their
own
products.
D
So,
like
log
4j
that
upstream
community
fixed
that
published
the
the
the
source
and
then
downstream
vendors
suse,
red
hat,
you
know
aws
azure.
All
these
different
consumers
took
that
developed
their
own
patches
and
pushed
that
out
to
their
customers.
So
it's
kind
of
like
a
big
inter
interconnected
web.
I
have
a
diagram.
I
was
looking
for
it
as
part
of
a
working
group.
That
kind
of
explains
the
happy
path
for
cbd,
but
there's
a
lot
of
ways,
a
lot
of
different
variations
and
a
lot
of
different
ways.
G
Yeah
it
does
you
know,
but
even
in
that
log
for
james
case
right,
that
vulnerability
actually
exists.
You
know
for
several
years,
but
no
one
really,
you
know
gone
behind
it
and
you
know
exploited
it
right
that
vulnerable
function
was
there,
but
it
was
created
for
a
good
reason,
but
but
it
created
another
hole
in
it,
but
which
was
eventually
took
several
years
to
expose
it
right.
D
Source
is,
as
defects
are
reported.
We
have
the
ability
to
be
very
agile
and
re
pivot
very
quickly,
so
that
report
came
into
the
log
4g
team.
They
were
able
to
evaluate
that
work
out
a
solution,
and
then
you
know
the
log4j
team
is
responsible
for
the
log
4j
source.
They
aren't
responsible
for
the
whole
downstream
ecosystem
that
are
consumers.
D
A
What
how
do
we
help
people
find
vulnerable
packages
and
update
more
quickly?
I,
and
I
I
just
have
better
situational
awareness
around
where
there
might
be
latent
risk,
such
as
the
the
the
undiscovered
you
know,
log
for
j
issue
right,
but
also
you
know,
to
kind
of
elevate.
A
The
importance
of
you
know
it
amazed
me
how
many
people
said
well,
we're
not
vulnerable
to
the
problem,
because
we're
still
on
log
for
j1.x,
so
no
worries,
even
though
that
one.x
hadn't
been
under
support
for
five
years
with
other
several
known
vulnerabilities
out
there.
I
think
dan
lawrence
even
suggested
that
projects
that
are
officially
you
know
kind
of
end
of
life
should
have
a
cve
automatically
issued
for
them
so
that
pops
up
on
people's
radar.
A
A
The
stuff
to
try
to
figure
out
if
it
applied
to
you
or
not,
and
then
we
had
cves
and
we
had
now
the
nvd
and
other
things,
but
I
think
there's
still
some
work
to
do
to
go
and
make
it
easier,
semantically,
more
programmatic,
to
be
able
to
say
I'm
building
this
code,
I'm
running
this
code,
where
are
there
known
cdes,
just
in
in
everything
I'm
depending
upon?
A
But
now
I
quickly
update
it.
So
if
there's
additional
standards,
additional
services,
additional
kind
of
databases,
we
should
run
as
a
public
resource.
Let's
talk
about
it
and
I
think
I
think
the
the
that
working
group
is
key
to
figuring
that
out,
but
I
think
there
might
be
other
places
in
open
ssf
that
we
could
be
helpful
to
that.
D
Right
and
things
like
the
cvd
guide
for
oss
is
helpful
for
projects
to
learn
from
reflect.
Do
we
want
to
change
and
it
provides
kind
of
a
a
measuring?
Stick
like
this
is
kind
of
the
bare
minimum
stuff
we
need
to
do
as
you
have
a
bigger,
more
capable,
more
mature
project.
They
might
have
a
dedicated
security
team.
They
might
have
dedicated
security
researchers
on
their
own
payroll,
so
to
speak.
That
can
do
some
of
this
work,
but
you
know
open
source.
D
You
have
projects
that
are
maintained
and
created
by
one
or
two
people,
and
then
you
have
things
that
are
maintained
by
thousands
of
people
and
those
the
experience
of
those
packages.
Those
pro
and
products
can
be
very
different,
and
hopefully
you
know
that
our
guide
kind
of
speaks
to
everyone
and
anyone
from
any
size
can
learn
from
it
and
improve
how
they
do
stuff.
A
Thank
you
pro.
I
want
to
move
on
to
a
question
that
vladimir
shingarev
asked
in
chat
vlad.
Can
you
unmute
and
ask
that,
on
the
call.
A
Sorry,
if
I'm
surprising
I
can,
I
can
also
read
it
out
loud,
which
is
basically
the
question
is
sigstor
is
great,
but
there
seem
to
be
other
either
parallel
or
complementary
efforts
out
there.
I
think,
perhaps
more
complementary
than
anything
else
in
toto
cyclone,
dx
and
spdx
as
s-bomb
standards.
Salsa.
Are
you
moving
in
the
same
direction?
Collectively?
Was
this
question
and
as
their
coordination
between
the
projects
is
it
enough?
A
You
know
he's
just
trying
to
figure
out
how
all
these
pieces
fit
together
and
so
priya
not
to
put
you
on
the
spot.
But
could
you
talk
about
a
little
bit?
How
you
think
about
working
with
these
other
other
efforts
or
how
the
six
store
team
thinks
about
working
with
the
other
effort.
B
Definitely
I
would
definitely
say
that
there
is
good
collaboration
with
all
these
different
projects.
I
think
a
lot
of
the
like
folks
here,
who
are
also
in
the
sixther
call
attend
a
lot
of
the
like
salsa
meetings,
the
in
total,
like
open
source
meetings
and
I'd
say
the
community
is
like
pretty
strong
and
and
there's
there's
definitely
been
a
good
amount
of
collaboration.
B
I
would
also
say
that
there
are
a
lot
of
pieces,
so
I
can
definitely
understand
like
why
it
would
be
like
difficult
to
see
how
they
all
work
together
or
kind
of
how
they
all
fit,
and
in
that
sense
I
would
recommend,
probably
like
reaching
out
in
like
a
more
either
and
like
in
a
six
star
slack
or
reaching
out
like
in
the
six
store
community
meeting
when
it
happens
every
week,
because
I'm
sure
that
there
are
resources
out
there,
which
kind
of
explain
how
to
fit
all
these
pieces
together
and
I
think
in
those
like
forums.
A
I
do
also
want
to
highlight
that
the
security
I'm
sorry
the
supply
chain
working
group
recently
approved
a
a
contribution
from
city
called
the
the
the
secure
software
factory,
which
puts
a
lot
of
these
pieces
together
into
kind
of
a
template
into
a
playbook,
so
to
speak
worth
taking
a
look
at,
and
maybe
we
can
provide
an
update
on
that
in
a
future
call.
I
want
to
get
to
one
last
question
just
I
I
see
andrew
eight
kind
of
asked
he
kind
of
clarified,
mootoo's
question.
A
D
Andrew
clarified-
and
he
thinks
luther's
question-
was
more
oriented
towards
how
end
users
consume
that
fix
more
effectively
and
efficiently,
and
that
really
depends
on
who
your
supplier
of
that
software
is.
If
you
are
directly
consuming
from
some
upstream
source,
you
should
probably
monitor
their
change
log,
their
advisories,
if
you
get
it
from
a
commercial
supplier,
you
it's
incumbent
upon
that
vendor
or
supplier
to
notify
their
end
users.
So
it's
you
really
open
source
is
an
amazing
ecosystem,
but
you
really,
it
does
require
some
work.
D
You
need
to
invest
some
time
in
understanding
how
these
communities
work,
how
they
communicate
and
where
best
you
can
learn.
If
you're
waiting
on
the
nvd,
there's
gonna
there's
lag
time.
If
that's
your
kind
of
your
canary
in
the
coal
mine
that
there's
a
vulnerability,
there
will
be
potentially
days
worth
of
lag
time
from
the
time
it
gets
reported
up
in
mitre
until
it
flows
down
to
something
like
the
nvd
and
then
down
to
something
like
a
black
duck
or
a
sonotype.
D
H
Can
you
hear
me
brian
okay
thanks,
so
I
I
think
it's
important
to
understand
the
scale
of
the
challenge,
for
let's
say
an
average
global
enterprise
right
they're,
using
anywhere
between
10
to
30,
000,
different,
open
source
components
so
expecting
them
to,
and
they
have
they
consume
through
a
whole
bunch
of
different
channels
right
right.
They
consume
directly.
They
consume
through
third
parties.
They
manage
this
through
multiple
different
tool,
chains
and
and
and
multiple
different
products.
H
And
so
having
that,
having
that
expectation
that
they
are
one
that
they
understand
how
and
where
they're
consuming
open
source
two
having
them
understand
that
there
are
that
they
need
to
be
managing
this
through
multiple
different
practices
and
processes
is
far
more
is
a
higher
degree
of
expectation
than
than
we
can
have
with
them.
Today
right,
we
still
have
a
couple
of
of
clients
who
have
an
opt-in
policy
across
their
developer
ecosystem
once
a
year.
They
survey
the
developers
and
say:
would
you
please
mention
which
open
source
components
you're
using?
H
But
if
you
don't
feel
like
it,
you
don't
have
to,
and
these
are
large
global
enterprises
right
so
mike.
My
question,
I
think,
maybe
to
mutu's,
is,
does
open,
ssf,
anticipate,
also
helping
provide
through
some
of
these
working
groups,
not
just
ways
that
communities
can
manage
this
process
better,
but
that
end
user
consumers
can
manage
it
better.
Also,.
A
I'll
actually
jump
in
and
answer
really
shortly
quickly,
which
is
because
I've
heard
from
both
you
andrew
and
a
few
other
people
that
the
interests
of
end
users
are
kind
of
unique,
are
worth
considering
as
kind
of
a
first-class
actor
in
this
ecosystem.
I
I
I'm
really
interesting.
How
do
we
convene
those
conversations
and
figure
out?
Is
there?
Is
there
a
need
for
a
new
working
group?
Is
there
a
need
for
like
even
like
a
sig
or
something
like
that
to
support
that?
A
So,
just
to
start
out,
I've
created
a
slack
channel
on
the
openness
of
slack
called
pound,
sign,
end
users,
and
if
anyone
has
a
better
term
for
what
they
think
you
know
this
might
be
to
distinguish
them.
I
guess
from
vendors
in
the
space
that'd
be
that'd
be
great,
but
let's
start,
let's
continue
the
conversation
there,
because
I
think
understanding
that
perspective.
Those
perspectives
is
really
super
important,
and
I
I
I
saw
michael
skivet
had
his
hand
up
to
help
answer
this.
A
So
did
you
want
to
jump
in
on
this
thread,
or
is
it.
F
Yeah,
I'm
just
going
to
riff
on
this
and
say
you
know
like
this
is
a
really
hard
problem.
I
this
is
one
of
the
things
that
makes
this
interesting
and
why
I'm
here
is
to
solve
these
problems
that,
like
it's
not
just
as
simple
as
well
just
have
everybody
do
x,
and
you
know
you
know,
even
even
to
the
point
of
a
trade-off
between,
like
we'll
just
tell
everybody,
to
keep
their
open
source
up
to
date
and
have
it
every
week
it's
just
auto
magic.
F
You
know
you
delete
your
lock
file
and
you
re,
you
know
you
reinstall,
that
works
great
in
theory
in
practice
a
whole
bunch
of
challenges
and
and
will
eventually
get
there
as
an
industry,
but
we're
still
at
the
point
where,
like
we
all
know
that
we
have
a
problem,
and
we
have
lots
of
different
ideas
on
how
to
tackle
this,
but
we
don't
know
what
the
best
ideas
are.
We
don't
like
that.
There's
no
there's
no
standard
for
this
we're
making
up
the
standard
as
we
go
so.
A
A
To
david
wheeler,
just
because
I
saw
you
guys
his
hand
up
and
where,
at
the
last
minute
so
david
go
for
it.
I
Yeah,
so
I
just
wanted
to
add
that
there
are
tools
and
services
that
can
least
help
with
the
you
know,
with
the
notifications
and
and
such
I
think,
in
the
longer
term,
you
know
I
agree
with
mike
scaveta
that
you
know
with
things
are
still
being
developed,
but
I
think
in
the
end,
automation's
key
if
we're
waiting
for
developers
to
figure
it
out
by
hand
you
already
lost,
but
there
are
some
tools
and
services
that
can
help.
A
Okay,
thank
you
david.
Thank
you
to
everyone
who
asked
questions
and
participate
in
the
conversation.
Thank
you
to
our
panelists
and
thank
you
to
all
of
you
and
see
you
through
all
of
our
different
communities,
and
perhaps
next
quarter
at
the
next
town
hall.
Take
care
thanks.
Everyone.