►
Description
What is OpenSSF? - Brian Behlendorf, General Manager, 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
That's
what
I
wanted!
Okay,
so
with
that
one
I
just
dig
in
so
the
open
ssf
is
a
global
initiative,
securing
investment
resources
and
expertise
to
improve
the
security
of
Open
Source
software
in
the
software
supply
chain.
It's
kind
of
recognizing
the
role.
The
unique
role
that
open
source
software
plays
today
across
the
entirety
of
the
software
landscape,
it's
kind
of
impossible
to
escape
open
source
code
at
this
point,
not
that
anyone
would
want
to
which
means
that
bugs
that
are
inside
of
Open
Source
Code
exhibit
themselves
in
lots
of
very
pernicious
ways.
A
For,
for
you
know,
when
you're
badging,
with
an
L
with
an
RFID
to
get
in
to
to
Apple's
iTunes
website
right,
small
little
small
bug
can
have
these
pernicious
effects,
and
so
it's
and
and
secondly,
how
we
write
open
source
code,
the
the
mechanisms,
the
social
interactions,
the
the
tools
often
came
about
at
times
of
very
high
trust
when
the
internet
was
a
lot
smaller.
When
the
software
world
was
a
lot
smaller
frankly,
and
we
built
lots
of
social
structures
for
understanding.
A
How
do
we
trust
the
software
that
we
consume
and
and
build
a
relationship
with
the
people
who
software
reuse
that
today
simply
doesn't
scale?
So
we
need
to
be
thinking
about
tools
and
and
and
updated
processes
that
handle
the
volume
of
code
that
we're
dealing
with
today
and
that's
what
the
open
source
security
Foundation
is
all
about,
and
that
means
in
some
cases,
writing
code.
So
that's
definitely
in
the
Wheelhouse
of
the
Linux
Foundation
we're
home
for
lots
and
lots
of
software
projects
that
ride
an
awful
lot
of
code.
A
Take
a
risk-weighted
view
of
you
know
the
software
they
consume
and
the
ways
that
they
produce
software
is
the
kind
of
impact
that
we'd
like
to
have.
It's
perhaps
kind
of
try
to
mention
this
at
this
point,
but
the
the
data
is
pretty
overwhelming
that
than
average
software
stack
inside
of
a
car,
a
phone,
a
web
service
that
90
of
the
code
behind
that
is
pre-existing
open
source
code.
A
And,
of
course,
it's
the
10
that
everyone
is
paid
to
build
and
and
gets
compensated
for
and
like
builds
your
tremendous
value
out
there
and
is
cool,
but
we're
standing
on
the
shoulders
of
giants
in
so
many
ways,
each
other's
shoulders
really
as
we
build
and
deploy
code,
and
yet
so
much
of
that
code.
Ships
with
known
vulnerabilities
is
ships
with
stuff
that
perhaps
many
layers
down
is
vulnerable
and
and
end
users.
Don't
really
recognize
this
or
realize
this,
and
and
we
ourselves
in
the
open
source
space.
A
You
know
I
kind
of
ignore
that
fact
at
our
own
risk,
so
so
in
in
trying
to
address
these
kinds
of
issues,
there's
there's
six
different
kind
of
ways
of
of
slicing
this.
We
think
it's
important
to
prioritize
open
source
projects
out
there.
All
of
you
are
familiar
with
that:
XKCD
comic,
nine,
not
927,
which
is
a
10
30,
something
somebody
will
quote
the
verse
from
it,
which
shows
here's
the
small
little
component,
that,
if
that
fails,
the
whole
rest
of
the
internet
comes
tumbling
down.
Well,
how?
A
How
do
we
find
that?
How
do
we
understand
criticality?
Not
just
in
terms
of
painting
a
graph
of
which
projects
depend
upon
which,
but
also
weighting
that
by
usage
out
there,
how
do
we
think
about
criticality
based
on
the
kinds
of
industries
that
software
is
being
deployed
in
so
finding
that
and
trying
to
figure
out
if
we're
going
to
go
and
try
to
upgrade
security
of
specific
projects?
What
are
the
most
important,
50
or
100
or
10
000?
To
start
with,
is
one
one
big
component
of
what
we
do.
A
Automation
through
better
tooling,
is
critical
as
well
software
developers.
If
you
tell
them,
you
know,
we
need
you
to
be
more
secure
in
how
you
write
code
here
as
a
checklist,
they'll
kind
of
yawn
or
push
back.
If
you
say
here
are
tools
that
you
have
to
use,
you
know
that
add
a
lot
of
extra
burden,
or
you
must
use
these
scanning
tools
and
get
a
clean
report
out
of
it.
A
As
mentioned,
we
believe
educating
developers
on
best
practices,
educating
them
on
how
to
build
better,
more
secure
code
is
critical.
You'll
hear
a
lot
more
about
that
today,
including
from
Probe
and
and
from
Marta
and
and
others
will
speak
this
afternoon
on
this.
But
but
it's
it's
amazing
how
little
formal
training
there
is
in
avoiding
the
kinds
of
common
mistakes
that
lead
to
so
many
of
the
cves
out
there
and-
and
we
think,
there's
actually
some
really
really
easy
wins
in
in
that
space.
A
We
think
it's
important
as
well
to
Resource
the
fixes
for
vulnerabilities
in
open
source.
It's
not
enough
to
scream
at
the
cloud
and
say
you
know
all
your
stuff
is
broken.
It's
you,
it's
not
even
enough
to
go
and
find
these
vulnerabilities
or
to
to
you
know,
tell
people
that
looks
like
a
risky
thing.
You
have
to
step
in
with
resources
to
provide
fixes
for
that,
and,
and
ideally,
you
create
an
ecosystem
where
the
downstream
users
of
code
have
some
sort
of
connection
to
the
Upstream.
A
That
either
is
by
direct
contribution
of
fixes
or
providing
resources
to
fix
things
Upstream.
You
know
they're
able
to
to
get
that
work
done
and
be
additive
to
the
development
efforts,
because
it's
so
important
to
recognize
maintainers
on
open
source
projects
developers
are
tend
to
be
overworked.
They
tend
to
be
burdened.
There
tends
to
be
a
lot
of
free
ridership
in
open
source,
which
we've
kind
of
accepted
as
the
way
things
are
today.
A
The
answer
to
that
isn't
by
hectoring
them
and
telling
them
write
more
secure
code,
it's
by
showing
up
with
help,
and
so
that's
that's
a
critical
part
of
what
we
do.
We
think
it's
important
to
identify
new
kinds
of
security
threats
as
well.
Certainly,
the
rise
of
attacks
on
the
software
supply
chain.
I
I
didn't
cause
us
to
have
to
care
about
things
like
signing
artifacts
throughout
the
software
to
supply
chain,
not
just
at
the
very
end
where,
where
we
tend
to
it's
a
very
good,
be
pretty
pretty
good
at
that.
A
But
but
let's
identify
new
kinds
of
threats
that
affect
things
further
upstream
and
think
about
it.
Are
there
systematic
ways
to
mitigate
those
or
to
eliminate
security,
vulnerability,
classes
of
security
vulnerabilities
at
once,
and
then,
finally,
again,
standardized
look
for
ways
to
to
standardize
the
way
that
these
Supply
chains
form
when
they're
forming
across
ecosystems
when
they're
forming
across
language
ecosystems
right
forming
across
industries?
Of
course,
how
do
we?
A
How
do
we
look
for
and
build
tools
to
to
help
standardize
a
lot
of
these
practices
so
that
again
it
becomes
a
default
part
of
writing
open
source
code
is,
is
it's
written
more
securely,
so
we
have
quite
a
few
working
groups
across
the
open
ssf
that
map
to
these
different
modes
of
Engagement.
These
different
slices
of
what
we
do-
and
this
is
a
a
hierarchy
that
predominant
kind
of
part
of
that
hierarchy,
is
something
called
a
working
group
within
that
working
group.
A
There
can
be
a
long
list
of
projects
and
other
kinds
of
technical
initiatives
that
go
and
Tackle
different
things.
Some
of
those
are
still
works
in
progress.
Others
have
been
creating
output
for
even
longer
than
I've
been
involved
in
the
project
for
for
more
than
the
last
year,
and
they
run
the
gamut
from
Best
Practices
to
vulnerability
disclosures
to
understanding
how
folks
build.
How
do
we
discover
new
vulnerabilities
and
how
do
we
coordinate
the
release
of
those?
A
Many
of
the
people
behind
I,
I
and
npm
and
Pi
Pi
rust
crates
and
some
of
these
other,
essentially
the
app
stores
of
the
open
source
landscape
and
asks.
Are
there
some
common?
You
know
techniques
such
as
mandating
to
a
second
Factor
auth.
You
know
to
other
ways
of
highlighting
more
secure
options
in
the
collections
of
tools
that
are
collections
of
packages,
you
distribute
other
other
ways
that
those
repositories
could
work
together
to
to
uplift
open
source
as
a
whole
to
looking
at
software
supply
chain,
Integrity.
A
There's
a
working
group
focused
on
that
which
actually
started
life
looking
at
identity
and
then
kind
of
pivoted
to
saying.
Well,
maybe
the
focus
should
be
on
things
like
salsa
for
describing
supply
chain
levels
for
software
artifacts,
which
salsa
stands
for
again
again,
levels
of
confidence
and
attestations
in
the
way
that
software
is
built
as
it
flows
through
the
chain
to
to
two
final
working
groups,
one
on
securing
critical
projects.
A
Try
to
say
is
this
package
the
the
way
that
they
built
it
was
that
done
securely
and
then
finally,
a
working
group
that
has
just
launched
in
fact
we'll
talk
more
about
it
today
called
the
end
users
working
group
focusing
on
you
know
on
the
security
needs
and
perspectives
of
the
organizations
that
are
major
consumers
of
Open
Source
Code
and
have
started
to
feedback
Upstream,
but
aren't
themselves
Cloud
providers
or
platform
providers
and
or
tools
providers
right.
They
have
a
unique
set
of
needs
and
organizing
to
figure
out
how
to
meet.
A
A
It's
an
advisory
Council
because
they
try
to
have
have
a
light
touch
on
the
the
projects,
but
at
the
end
of
the
day,
it's
really
what
make
sure
that
there's
Harmony
between
the
efforts,
the
different
working
groups
and
and
one
thing
I-
should
throw
out
I,
unlike
certain
other
communities
that
have
a
let
a
thousand
flowers
bloom
point
of
view
in
terms
of
let's
be
the
home
for
all
things
cloud
or
all
things.
Enterprise
blockchain.
A
Not
that
you
can't
experiment
not
that
we
can't
look
at
disruptive
Innovations
in
some
ways,
but
but
let's,
let's
really
try
to
hone
what
we're
doing
out
there
into
the
best
possible
set
for
end
users,
and
that's
that's
where
the
attack
plays
an
essential
role
in
kind
of
overseeing
this.
But
there
are
some
other
parts
of
this
chart
as
well.
A
So
a
couple
of
things
that
you'll
be
hearing
more
about
today
and
in
some
cases
I
won't
Spill
the
Beans.
You
know
let
Michael
scavetta
tell
you
more
about
what's
going
on
in
Alpha
Omega,
but
we've
we'll
be
talk,
you'll
be
hearing
today
more
about
the
new
end
users
working
group,
as
I
mentioned,
you'll,
hear
about
these
new
two
new
concise
guides
for
developing
more
secure
software
and
for
evaluating
open
source
software
from
a
security
point
of
view.
A
This
is
really
just
meant
to
give
a
sense
of
breadth
right.
How
many
different
software
ecosystems
we're
touching?
How
many
different
communities?
How
many
different
folks
are
involved
in
the
open,
ssf?
It's
kind
of
a
circus
and
I
say
that
lovingly
it's.
You
know,
because
there's
so
much
going
on
in
these
different
rings
of
of
orbit,
but
that
also
means
there's
plenty.
You
know
there's
a
whole
lot
of
Need
for
other
folks
to
help
us
build
this
and
other
other
organizations
to
get
involved
in
a
lot
of
opportunities.
A
To
do
that
and
really
have
an
impact
here
is
the
technical
Advisory
board
for
sorry
technical
advisory.
Council
I
should
have
sorry
Mis
mistitled,
this
Dan
Loring
Josh
pressures,
Luke
Heinz
krobe,
who
a
very
familiar
face:
Bob
Callaway
who's
here
in
the
audience,
Ava
I
think
might
be
here
and
Abhishek
Arya.
A
These
are
Partners
who
we
work
with
to
just
get
the
word
out
more
widely
and
look
to
other
other
communities
to
to
be
partnered
with,
and
that
is
the
big
picture
for
the
open
ssf
and
throughout
the
day
again,
you'll
hear
more
about
deep
dives
into
into
many
of
the
different
working
groups,
and
projects
and
I
also
hope
that
you'll
have
a
really
take
advantage
today
of
a
chance
to
ask
questions,
engage
with
people
here.
In
fact,
should
we
talk
about
the
the
unconference
part
coming
up
too?
A
A
We
really
welcome
folks
to
to
add
a
mention
of
the
kinds
of
topics
you'd
like
to
talk
about,
perhaps
even
things
you
want
to
hear
more
about
and
then
towards
the
end
of
that
break,
you'll
be
able
to
vote
on
the
ones
you
like
and
then
the
top
four
or
five
of
those
will
break
out
into
subgroups
around
this
room
and
maybe
in
the
lobby
to
talk
about
right
before
lunch
and
it'll
be
really
great
to
hear
from
all
of
you.
What
do
you
more?