►
Description
Deep Dive into the OpenSSF Mobilization Plan - Brian Behlendorf, OpenSSF
---
Open source software is pervasive in data centers, consumer devices, and applications. Securing open source supply chains requires a combination of automated tooling, best practices, education, and collaboration.
Join the growing list of organizations supporting the advancement of securing open source technology and funding the development and adoption of OpenSSF initiatives. https://openssf.org/
A
A
But
this
is.
This
is
a
thing
that
came
about
in
response
to
a
crisis
earlier
this
year,
really
coming
in
at
the
end
of
December,
where,
if
those
of
you
with
long
memories,
Might
Recall
log
for
Shell
broke
the
internet,
broke
it
in
a
pretty
low
level
way
and
ruined
a
lot
of
people's
Winter
holidays
by
happening
in
a
component.
That
is
pretty
low
level
happening
in
a
way.
A
That
was
not
all
that
easy
to
upgrade
or
even
know
if
you're
affected
and
the
number
of
people
who
said
they
weren't
affected,
because
they
were
running
log
for
J
version.
1.X
was
pretty
hilarious,
but
but
I
caused
a
bunch
of
people
to
to
get
a
kind
of
to
pay
attention
to
this,
including
our
friends
at
the
white
house
who
said
this
is
this
is
a
an
issue
now
with
geopolitical
ramifications
and
it's
worth
paying
some
attention
to,
and
so
they
convened
a
discussion
in
DC
in
January.
A
It
was
originally
going
to
be
face
to
face
I
flew
out,
my
boss
flew
out,
and
then
they
went
to
Virtual.
So
we
got
to
take
it
from
our
hotel
rooms,
but
because
of
covid,
but
they
convened
a
meeting
with
us
and
with
the
Apache
software
foundation
and
with
10
other
companies
and
by
the
way,
when
the
NSC
invites
you
to
a
meeting,
it's
not
a
birthday
party.
It's
it's
a
kind
of
an
honest
conversation
about.
Is
this?
How
it's
supposed
to
work
like?
Is
this?
A
How
open
source
software
expects
the
the
people
who
have
critical
infrastructure
needs
upon
it
to
respond
to
what
seems
to
be
a
recurring
event
of
people
finding
an
interesting
low-level
hole,
whether
it's
something
like
xkcd2347?
Thank
you
now
I
can
cite
chapter
verse
or
it's
some
other
other
kind
of
vulnerability
like
like
where
we
all
kind
of
you
know,
go
into
a
to
see
to
respond
and
and
try
to
get
it
upgraded
and
fixed.
A
Or
is
this
something
that
there
actually
might
be
some
solutions
to,
and
so
we
had
a
six
hour
conversation
which
kind
of
boiled
down
to
what
would
it
take
to
actually
solve
these
issues?
And
it
was
those
of
us
in
the
room
kind
of
asking
ourselves
to
come
out
of
that
and
later
and
talk
with
our
our
own
stakeholders
and
our
communities
about
how
might
we
secure
open
source
software
production
in
the
first
place
like
as
it's
being
written?
A
How
do
we
get
people
to
patch
more
often
and
and
realize
kind
of
the
risks
of
the
cost
of
keeping
around
software?
That's
suffering
from
bit
rot
and
that
sort
of
thing,
and
so
within
within
the
community?
We
had
a
conversation
at
a
lot
of
different
levels
at
the
level
of
the
the
technical
advisory
council
at
the
level
of
the
governing
board
at
the
level
of
individual
projects,
and
some
of
that
was
very
public-facing
conversation.
Some
of
that
was
very
private,
but
we,
we
said
you
know
there
are.
A
If
we
came
up
with
a
credible
plan,
not
one
that
spent
the
money
on
things
that
we'd
hope
people
would
also
volunteer
to
to
help
us
with,
but
for
the
kinds
of
things
that
you
could
accelerate
the
kinds
of
things
that
you
might
not
be
able
to
to
depend
entirely
upon
volunteer
research
sources
for
And
So
within
those
three
categories.
What
are
the
the
major
problems
that
can
be
addressed
that
would
lead
to
better
open
source
software
supply
chain
security.
A
A
In
fact,
they
cited
us
like
29
times
in
the
report,
so
it's
cool
to
see.
So
what
are
the?
What
are
the
major
problem
areas?
What
are
some
pre-existing
efforts,
whether
inside
of
openssf
today
or
not,
that
are
already
starting
to
address
these
problems?
It's
always
better
to
not
reinvent
a
wheel,
not
assume
that
you've
got.
You
know
the
five
percent
slightly
different
Solution,
that's
going
to
make
all
the
difference,
but
instead
to
build
upon
other
people's
work
and
and
double
down
on
them.
A
You
can't
guarantee
that
there's
no
code,
I
I,
know
that
there's
formal
analysis
and
and
and
certain
languages
that
might
help
with
this,
but
take
it
as
a
given
that
any
non-trivial
piece
of
software
has
a
bug
in
it
that
just
hasn't
yet
been
discovered.
What
more
can
you
do
still
to
try
to
get
at
some
of
these
systematic
issues
and
then,
finally,
once
you've
identified
these?
What
are
some
pragmatic
but
ambitious
targets
that
you
might
set
for
for
each
of
these
problems?
A
That
result
in
things
that
you
can
measure
right
and
you
it's
really
hard
to
measure,
sometimes
the
extra
benefit
of
a
security
audit
on
its
own
right.
So,
but
how
might
you
you
ask
you
know
how
do
we?
How
do
we
really
measure
benefit
across
an
ecosystem
for
doing
enough
of
these
right
and
do
that
in
in
not
not
without
too
much
of
a
lead
time?
A
You
know,
inside
of
proving
some
benefit
within
the
first
year
or
two,
so
we
we
broke
out
into
10
different
teams,
kind
of
on
a
set
of
topics
that
we
talked
at
attack
and
at
a
governing
board
level.
It
seemed
to
make
sense
to
us.
We
asked
for
volunteers,
for
each
of
those
ten
and
to
the
varying
degrees
of
being
public
I
mean
to
some
degree
we
didn't
want
to
take
months
and
months
to
develop
this
plan.
A
We
knew
that
they
wanted
to
hear
back
from
us
in
kind
of
the
April
time
frame,
so
that
meant
kind
of
being
reasonably
expeditious
about
it,
but
those
those
10
teams
developed
three
to
five
page
proposals
and
we
put
them
together
in
something
called
the
open,
ssf
mobilization
plan
software
security,
mobilization
plan
and
we
I
put
a
label
of
version
0.9.1
just
to
make
it
clear
to
people.
This
is
not
done
yet.
A
In
fact,
it's
not
even
clear
if
it'll
ever
be
done
so
much
as
represent
a
point
in
time
of
a
set
of
Experts
of
what
could
be
done
in
this
domain.
It's
it's!
What's
the
right
word,
it's
it's
ambitious!
It's
idealistic!
It's
it's
a
little
bit
of
a
of
an
optimistic
take
in
a
world
where
we
get
so
much
bad
news
around
that
it's
hard
to
be
optimistic
about
technology.
A
It
also
assumes
that
we
can
pull
together
the
resources
to
get
started
and-
and
we
know
that
that
is
always
a
an
open
question
too-
and
you
know
when
we
had
the
conversation
with
the
NSC
and
with
others
about
what
would
it
take
to
actually
have
a
huge
impact
on
this?
We
kind
of
said
this
isn't
likely
to
be
a
small
problem.
This
isn't
likely
something
that's
going
to
be
fixed
inside
of
a
year
or
or
within
a
cost
of.
You
know
a
couple
million
dollars.
A
This
is
probably
going
to
take
a
billion
to
10
billion
kinds
of
dollars
to
to
Really
solve
some
of
these
systematic
issues
purely
as
a
hand
wave
after
this
research.
We
came
in
and
realized
that
it
was
about
150
million
dollars
to
do
what
is
again
a
set
of
modest
but
ambitious
targets,
and
so
that
number
and
I'll
get
into
a
bit
of
trying
to
figure
out
how
that
number
sits
relative
to
other
things.
I
was
actually
a
nice
reassuring
number
to
get
to.
A
So
let
me
go
a
bit
into
depth
just
so.
You
understand
kind
of
what
each
of
those
10
are,
but
also
how
we
thought
about
those
10..
So,
as
you've
heard
a
lot
of
discussion
about
one
of
the
key
drivers
for
failure
out,
there
is
a
lack
of
a
security
education,
a
lack
of
understanding,
here's
the
kind
of
common
pitfalls
that
projects
hit
the
kind
of
when
people
when
developers
don't
know
enough
to
not
only
understand
the
threat
model,
but
even
just
think,
like
a
hacker
with
their
own
own
code.
A
What
does
it
mean
to
not
only
not
trust,
use
or
contributed
input
which
I
think,
hopefully
all
developers
kind
of
know
by
now?
How
do
you
sanitize
those
inputs
that
sort
of
thing,
but,
most
importantly,
don't
parse
it
for
format,
strings
which
was
again
one
of
the
contributing
factors
in
the
in
log
for
Shell?
So
how
do
we
put
the
that
basic
container
training
together
with
all
sorts
of
other
courses
to
and
content
and
try
to
reach?
Frankly,
everybody
who's
writing
software
into
some
degree
or
another
right?
A
A
You
know,
there's
a
bit
more
detail
in
the
plan,
but
it
calls
for
millions
of
people
taking
the
the
secure
software
development
course
and
millions
of
certifications
getting
out
there
and
that's
the
degree
of
scale
that
I
think
we
want
to
hit.
So
that
was
that's
stream
number.
One
stream
number
two
talks
about
risk
assessment,
which
is
a
boring
title
for
dashboards,
which
is
also
a
boring
title
for
the
kind
kinds
of
things
that
James
was
just
talking
about.
A
How
do
we
pull
together
all
of
the
information
that
you
might
get
from
Best,
Practices,
Badges
and
scorecards,
and
scans
for
vulnerabilities
and
dependencies
and
and
other
objective
metrics
data
like
when
was
the
last
time
that
this
project
had
a
third
party
audit,
and
where
was
the
report
from
that
audit
right?
How
do
you
pull
these
streams
together
and
present
in
kind
of
a
unified
view?
A
All
of
the
the
risk
factors
that
affect
the
trustworthiness
of
Open
Source
Code,
trying
to
respond
to
the
to
the
fact
that
today,
most
developers,
when
they're
picking
components,
they're
picking
modules,
look
to
things
like
GitHub
stars
or
how
active
the
Reddit
form
might
be
around
a
given
component,
or
maybe
how
many
issues
are
open,
although
that
could
be
as
much
a
measure
of
how
widely
it
is
used
as
how
much
it's
ignored
by
its
own
maintainers.
Wow.
Look!
A
There's
lots
of
issues
in
here
that
either
means
it's
very
popular
or
it
is
very
poorly
maintained.
It
could
mean
either.
Instead,
what
we
need
are
better
tools
to
understand
the
the
trustworthiness,
the
code,
the
likelihood
that
there
are
undiscovered
vulnerabilities
or,
even
frankly,
the
diligence
with
which
they
are
responding
to
known
vulnerabilities
and
getting
those
closed.
A
Everybody
figuring
out
like
how
do
I
trust,
which
Java
logging
framework
to
use
and
then
finally,
it
guides
to
the
developers
the
maintainers
on
software
to
to
write
better
code.
So
what
does
it
take
to
provide
a
free
resource,
a
free
infrastructure
for
10
000
of
these
projects?
It's
not
a
tiny
amount
of
money,
but
it's
not
an
overwhelming
amount
either,
and
we
could
do
all
this
work
open
source
and
even
share
that
data
Lake
that
we
pulled
together
of
all
of
these
underlying
data
sources.
A
I
think
I
think
pretty
effectively,
so
that
companies
like
City,
could
ingest
this
data
inside
and
incorporate
it
into
your
tool.
The
third
one
speaks
to
digital
signatures.
Now
this
should
be
thought
of
as,
like
the
the
the
funding
component
to
Sig
store.
It
doesn't
directly
call
for
the
plan
does
speak
quite
a
bit
about
Sig
store,
but
the
organizational
frame
for
this
is:
how
do
we
simply
get
greater
cryptographic
attestation
to
the
Integrity
of
components
flowing
through
the
software
supply
chain?
And
how
do
we
get
this
to
become
a
standard?
A
The
goal
is
to
get
50
of
the
top
200
projects,
using
this
top
200
by
size
by
volume
of
releases
and
community
and
that
kind
of
thing,
and
then
a
thousand
of
the
top
10
000
projects
using
it
on
the
premise
that
that
would
be
be
critical
mass
to
getting
the
rest
of
Industry
over
time,
eventually
to
adopt
it.
Now
we
does
call
for
investment
into
Sig
store.
Sig
store
is
what's
seen
as
by
that
that
team
kind
of
the
most
likely
way
to
get
there.
A
There
are
alternate
approaches,
maybe
some
that
answer
different
parts
of
the
of
the
the
needs
out
there
and
and
so
there's
a
bit
of
a
budget
to
try
to
identify
what
those
other
needs
might
be.
What
other
tools
there
might
be.
It's
not
fair
to
say,
though
it's
tools,
agnostic,
none
of
this
stuff-
is
going
to
be
agnostic.
There's
all
going
to
be
sorts
of
opinions
formed
about
how
to
get
to
the
solution,
because
at
the
end
of
the
day,
you
have
to
pick
a
tool
at
the
end
of
the
day.
A
It
also
calls
for
work
on
the
DNS
libraries
that
are
out
there,
DNS,
obviously
core
to
how
the
internet
works
and
with
a
very
small
number
of
implementations
out
there
and
all
of
those
written
in
C
and
then
finally
ntpd,
which
is
one
of
those
forgotten
about
demons
that
it
keeps
everybody
synchronized
out.
There
keeps
is
so
critical
to
to
the
infrastructure
actually
being
able
to
work.
A
I,
I
and
all
it
does
is
Network
time,
but
still
the
the
predominant
implementations
out
there
are
in
C
I
think
there
might
be
one
in
go.
I,
don't
believe
the
one
in
Rust
has
started
yet,
but
but
definitely
needs
needs
a
bit
of
focus.
So
this
is
where
there's
already
an
existing
proposal
for
this
work.
A
Coming
from
the
same
group
of
people
who
built
let's
encrypt
and-
and
this
is
really
to
to
Resource
that
work
plus,
it's
not
just
enough
to
write
the
code,
you
have
to
build
the
ecosystem
around
that
code.
Sorry
about
the
jumping
there.
You
have
to
build
the
ecosystem
around
that
code
to
help
make
sure
that
what
gets
built
gets
carried
forward
right.
A
It
does
no
good
to
have
a
whole
bunch
of
code
land
in
the
public
and
then
the
people
around
it
just
disappear,
so
it
calls
for
resourcing
developer,
Advocates
and
Community
Development
around
each
of
the
new
work
so
that
it
becomes
the
new
default.
It
becomes
the
new
standard
or
aims
to
be
at
least
stream.
Five
is
a
cause
for
developing
an
incident.
Response
Team
specific
to
the
needs
of
the
open
source.
Community
krobe
has
actually
already
launched
this.
A
working
group
focused
on
this,
a
Sig
sorry
focused
on
this
effort.
A
The
idea
is,
you
know,
a
project
like
a
a
log
for
Jay,
even
though
it's
within
the
Apache
software
Foundation,
even
though
the
ASF
has
a
great
security
team,
there
wasn't
the
full-time,
dedicated
resources
and
expert
resources
available,
necessarily
to
help
them
do
a
managed,
coordinated
disclosure
around
that
vulnerability
to
to
figure
out
now
there
are
a
couple
of
factors
in
it
as
well.
They
there
was
an
inadvertent,
commit
to
a
public
repo
that
mentioned
a
cve
that
had
not
yet
been
published.
A
A
The
idea
here
is
to
Resource
a
volunteer
team
with
a
couple
of
forepay
program,
managers
and
facilitators
and
in
some
cases
domain
experts
to
make
sure
that
there's
coverage,
but
to
really
tap
volunteer
Security
Experts,
we
know,
can
come
from
a
lot
of
different
companies,
Bond
them
to
a
common
agreement.
That
says,
if
you
help
us
figure
out
a
zero
day,
you're
not
going
to
tell
your
employer
about
it
right,
because
this
can't
become
a
a
way
to
volunteer
to
find
about
find
out
about
zero
days
early.
A
So
that's
a
really
delicate
thing
to
get
right,
but
if
we
do
that,
I
think
we
have
a
really
powerful
tool
to
help
a
whole
bunch
of
Open
Source
communities
who
otherwise
today
don't
know
who
to
turn
to
for
help
when
they
get
a
bug.
That
looks
pretty
serious
from
a
from
a
from
a
vulnerability
management
point
of
view,
and
so
it's
to
to
Resource
the
team
to
go
and
and
build
that
the
sixth
stream
is
focused
on
the
kinds
of
things
you
heard.
A
The
two
Michaels
talk
about
with
Omega,
where
it
comes
to
scanning
more
code
to
do
that
more
at
scale.
This
would
hope
to
build
an
infrastructure
that
could
do
that
for
10
000
such
projects
to
hire
some
more
researchers.
But,
more
importantly,
you
know:
you've
got
a
resource
when
you
find
these
bugs
people
to
work
with
the
Upstream
projects
to
get
those
bugs
fixed,
because
it
does
nobody
any
good
to
say.
A
Here's
a
bunch
of
problematic
output
from
a
scan
that
looks
like
it
could
be
an
issue
I
know
and
file
it
as
an
open
defects
on
an
upstream
project.
You
really
need
to
help
them
not
only
understand
why.
What
you
think
you
found
is
a
is
a
bug,
but
also
come
to
them
with,
if
at
all
possible,
with
pull
requests
to
get
those
fixed.
A
Stream.
Seven
is
to
double
down
on
code
audits
and
Amir,
told
you
a
bunch
about
with
the
work
that
he
does
at
ostev.
We
think
that
this
is.
This
is
a
very
powerful
thing
to
have
happen
on
an
open
source
project,
especially
the
older.
They
are
the
more
mature.
They
are
the
more
that
it's
helpful.
It
is
to
have
somebody
step
in
who's.
A
You
know,
or
a
team
step
in
who
understands
open
source
well
enough,
who
understands
looking
for
not
just
kind
of
off
by
one
errors
and
memory
allocation
that
can
lead
to
you
know,
memory,
corruption,
issues
and
and
vulnerabilities
that
way,
but
can
also
ask
architectural
questions.
Did
you
really
need
to
design
this
in
such
a
way
that
all
these
edge
cases
exist
and
aren't
covered
or
caught
by
your
code
or
even
end
user
kinds
of
questions?
A
Did
you
really
mean
to
put
this
chainsaw
in
the
middle
of
this
dinner
cutlery
set,
because
when
people
reach
for
a
fork
and
they
get
a
chainsaw,
that's
gonna,
you
know
cut
some
fingers,
I
I.
You
know
those
kinds
of
questions
can
come
from
a
really
good
security
audit
and
and
having
a
vetted
pool
of
organizations
that
can
do
those
kinds
of
audits
in
a
standardized
way
to
report
against
them
and
make
them
discoverable
by
people
trying
to
understand
the
security
of
a
of
a
project.
A
All
of
that
kind
of
thing
is
stuff
that
we'd
like
to
Resource
we'd
like
to
start
by
identifying
50
such
projects
where
the
average
size
of
these
projects,
typically
with
open
source
projects
of
any
reasonable
complexity.
You're,
probably
looking
at
about
a
hundred
thousand
dollars
to
do
a
pretty
thorough
audit
and
that's
on
average.
Some
will
be
a
lot
smaller
if
it's
a
500
line,
npm
module.
Of
course,
some
will
be
a
lot
larger
if
you're,
you
know
Mozilla
or
something
like
that-
maybe
Firefox
but
it'll
be
most
of
the
ones.
A
It'll
be
kind
of
modest
sized
will
be
about
100
Grand,
and
then
you
kind
of
want
to
Resource
fixes
for
those
again
as
well.
This
again,
this
message,
I'm
getting
across
you,
have
to
help
the
maintainers.
You
can't
just
show
up
with
more
problems
or
show
up
with
more
requirements
or
show
up
with
more
issues
you
have
to.
A
In
fact,
this
grows
to
be
about
half
the
budget
in
the
second
year
as
you'll
see
in
a
bit,
but
this
still
feels
like
a
super
important
thing
to
go,
not
just
to
tackle
the
Nebraska's
kind
of
problem,
but
but
to
also
go
to
the
that
the
the
the
the
second
tier
projects
that
don't
have
the
corporate
funding
that
don't
pay
to
do
this
kind
of
stuff
themselves
that
don't
have
full-time
devs
but
yet
are
used
pretty
ubiquitously.
This
is
this
is
an
essential
component
to
everything
else.
Going
on.
A
Streamate
speaks
to
the
challenges
that
we
had
in
forming.
You
heard
about
this
really
briefly,
this
study
that
was
done
in
conjunction
with
Harvard
called
The,
Open
Source
census.
In
fact,
we
did
two
of
them
one
and
we
did
released
one
earlier
this
year
called
the
census
two
which
tried
to
understand
the
criticality
of
Open
Source
components
based
not
just
on
kind
of
the
tree
of
dependencies.
A
A
But
this
work
is
essential
to
all
those
other
places
in
the
plan
where
we
talk
about
having
an
impact
on
the
top
50
here,
the
top
200
there,
the
top
10
000
there.
What
we
need
are
better
ways
to
share
that
data
in
a
more
agile
way
in
a
way
that
still
respects
privacy
and
confidentiality,
but
gives
us
an
ability
to
publish
updates
to
things
like
that
census.
2
report,
from
Harvard
more
than
once
a
year
and
with
much
less
human
labor
required.
A
Streamline
speaks
to
doubling
down
on
software
bill
of
materials.
We
haven't
talked
much
about
that.
Yet
today
and
frankly,
s-bombs
to
date
haven't
been
a
major
part
of
openssf.
Although
you're
about
to
hear
later
this
afternoon
from
Kate
Stewart
who's
going
to
present
a
bit
more
on
the
first
bit
of
work
that
we're
funding
in
this
domain
and
and
and
I
think
she
and
and
chrome
can
help
as
well.
I'm
sorry,
Josh
brasters
was
the
one
who's
been
focusing
on
this
stream
called
s-bomb
everywhere.
A
But
the
idea
here
is
you
get
if
you
can
get
these
s-bombs
created,
not
at
the
tail
end
of
the
software
supply
chain,
not
as
a
as
a
finishing
part
in
The
Last,
Mile
distribution
to
end
users,
but
instead
generated
by
every
component
Upstream.
Then
it
becomes
much
easier
to
assemble
these
Aggregate
s-bombs
and
becomes
much
less
likely
for
s-bombs
to
become
the
new
form
of
proprietary
lock-in.
A
So
there's
a
lot
of
folks
who
are
worried
that,
as
governments
start
to
require
s-bombs
as
companies
start
to
require
them
and
that
the
companies
that
tend
to
deal
with
the
last
mile
of
the
chain
will
go
to
tremendous
effort
because
they
have
to
to
figure
out
what's
in
the
black
boxes,
that
they
ship.
What's
in
the
platforms
that
they
ship.
But
in
doing
that,
they
start
to
see
that
as
competitive
differentiation
or
they
start
to
see
that
as
well.
I
spent
a
lot
to
develop
this,
so
I
got
it.
I
got
to
protect
it.
A
What
we'd
like
are
s-bomb
generation
tools
and
consuming
tools,
as
well
since
you'll,
be
publishing
an
s-bomb
for
a
package
you'll
be
pulling
in
all
these
s-bombs
from
dependencies
to
be
built
into
the
standard,
build
and
packaging
tools
that
are
out
there,
both
the
ones
that
run
on
clients
and
the
ones
that
are
hosted,
and
you
know
we
are
here-
we're
trying
to
be
be
a
bit
more
agnostic
about
format.
There's,
certainly
some
fairly
big
differences
between
the
two
leading
candidates
out
there,
spdx
and
cyclin
DX.
Those
communities
are
talking.
A
Our
meeting
are
trying
to
figure
this
out.
Those
differences
mean
it's
more
than
just
a
beta
versus
VHS
kind
of
debate
for
anybody
who's
50
years
old.
Like
me,
I
guess
knows
what
I'm
talking
about
I'm
49.,
but
but
isn't
just
like
you
know,
one
format
or
another,
but
there's
some
real
semantic
differences
between
them.
But
what
we're
trying
to
do
is
resource
enough
to
be
able
to
advance
to
figure
out.
A
How
do
we
work
through
those
differences
and
come
up
with
tools
that
maybe
can
consume
and
produce
both
of
those
formats
and
make
something
meaningful
out
of?
What
is
today,
sometimes
a
confusing
landscape
and
make
that
built
into
tools
again,
so
developers
don't
even
really
need
to
think
about
how
to
turn
them
on
they
just
become
as
standard
as
an
install.txt
again
showing
my
age.
A
I,
don't
think
any
of
us
want
it
to
look
like
the
Apple,
App,
Store
or
or
the
Play
Store
on
Android,
where
for
somebody
to
get
their
thing
listed,
is
a
tremendous
amount
of
work.
Often
costly
pushing
updates
can
take
time
but
recognize
Apple
and
Google
put
a
tremendous
amount
of
work
into
those
final
distribution
points
to
keep
their
users
secure.
So
there
must
be
something
that
we
can
think
about
doing
at
that
point,
and
so
the
folks
who
got
together
and
drafted
that
plan
looked
at
a
number
of
different
options.
A
When
we
released
the
plan,
it
means
two
years
as
each
of
these
streams
get
started,
as
each
of
these
streams
are
able
to
start
pulling.
Some
funding
in
started
tackling
some
of
the
the
milestones
and
their
plans,
but
frankly
the
milestones
and
the
plans
will
evolve
during
those
two
years
as
well.
So
there's
a
quote
from
I
want
to
say
Eisenhower,
but
it
might
have
been
a
general
instead,
who
said,
plans
are
nothing
planning
is
everything
you
know
the
basic
premise
being
the
the
process
you
go
through
to
identify.
A
What
are
our
goals?
What
are?
What's
the
reality
on
the
ground,
what
are
the
the
things
we
can
take
advantage
of
is
an
evergreen
process.
That's
something
where
every
quarter.
You
should
expect
to
lift
your
head
up
and
go.
Where
should
we
go
next,
no
matter
what
what
the
work
is,
that
you've
performed
and
and
I
expect
that
to
be
the
case
here
so
I
I
could
tell
you
more
about
we.
A
A
And
since
this
point,
I've
had
similar
conversations
with
folks
in
Japan,
we
had
a
miniature
version
of
this.
There
also,
the
Singapore
government
has
been
pretty
interested
in
this
starting
some
conversations
here
in
Europe,
we'll
see
what
that
turns
into,
but
folks
understand
that
there
is
a
need
now
to
invest
long
term
in
the
security
of
Open
Source
Code
code,
and
my
hope
is
that
just
like,
just
like
the
goal
of
Alpha
Omega,
is
to
turn
cash
into
better
security.
I.
A
We
did
get
some
pledges
towards
this
plan
from
our
own
members,
but
these
were
pledges
contingent
on
the
plans
bearing
fruit
in
the
form
of
specific
proposals
that
will
actually
go
and
make
some
progress
against
against
these
goals.
Nothing's
guaranteed.
In
this
front.
Nobody
has
written
a
check
yet
to
go
and
and
and
blow
the
doors
off.
A
This
we're
all
very
excited,
though,
because
while
150
million
sounds
like
a
lot
of
money-
and
it
certainly
is
to
an
open
source
project
like
ours
and
kind
of
the
approach,
we're
taking,
is
a
little
bit
different,
a
little
bit
unprecedented
for
both
the
Linux
foundation
and
I'd
argue
for
open
source
in
gen
General.
These
numbers
shouldn't
scare
us,
because
this
is
frankly
a
couple
of
ounces
of
prevention.
A
If
we
could
prevent
just
one
of
those
now,
the
question
is
who
pays
right
and
that's
that's
a
different
story,
but
imagine
being
able
to
stop
waves
and
waves
of
those
kinds
of
attacks,
waves
and
waves
of
those
kinds
of
reaches
I
think
it
pays
off
very,
very
nicely.
I
know
I'm
short
on
time.
The
big
picture
here
is:
we
are
figuring
out
within
the
open,
ssf
Community
how
to
take
this
statement
of
of
of
goals
of
Ambitions
of
ideas
and
turn
them
into
action.
It
is
a
hard
thing
to
do.
A
A
But
I'd
also
cite
things
like,
let's
encrypt,
which
is
running
a
real
Service
as
a
as
an
example
of
where,
sometimes
you
need
to
pay
people
to
maintain
an
SLA
on
something
or
to
have
a
staff
that
is
going
to
always
be
there
or
be
there
on
Monday
mornings
to
to
deal
with
deal
with
certain
things,
and
so
that
was
the
framing
that
we
took
this
in.
But
this
does
require
all
of
us
to
kind
of
Step
Up
level
a
bit
and
figure
out
organizationally.
How
do
we?
How
do
we
make
sure
we
don't?
A
You
know
defeat
the
kind
of
the
volunteerism
that
is
still
at
the
heart
of
making
an
open
source
project
process
work.
Well,
how
do
we
make
sure
we
don't
inadvertently
cause
people
to
have
to
be
responsible
for
things?
They
don't
have
control
over
right
or
the
opposite,
and
just
how
do
we
set
all
those
things
up
right
and
that's
an
ongoing
process,
but
we've
already
got
teams
work
meeting
now
on
three
of
the
10
10
streams
on
education,
the
emergency
response
and
on
s-bombs
everywhere.
A
In
fact,
we
funded
somebody
on
s
bomb
everywhere
already
and
we're
eager
to
get
going.
So
if
any
of
you
want
to
try
to
help
just
find
us
obviously
on
the
website,
we
talk
a
fair
bit
about
this
as
well,
and
this
would
be.
This
is
not
going
to
define
the
open
ssf,
but
this
is
a
way
to
take
the
things
that
have
been
building
inside
the
open,
ssf
and
and
and
and
put
them
into
the
into
orbit.
A
I
mean
and
really
have
the
kind
of
impact
on
the
full
open
source
community
that
we
all
hope
to
have.
So
with
that
I
guess:
I,
don't
have
any
time
for
questions,
but
I'm
going
to
be
around
and
clearly
have
not
been.
You
know
downed
by
the
jet
lag
yet
so,
okay,
25
minutes
of
coffee
time,
conversation
great
great
well
find
me
at
the
coffee
break.