►
From YouTube: Keynote: Bringing Greater Trust and Security by Design to the Open Source Ecosys... Brian Behlendorf
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Keynote: Bringing Greater Trust and Security by Design to the Open Source Ecosystem - Brian Behlendorf, General Manager, Open Source Security Foundation
A
Everyone
good
morning
welcome.
I
I'm
really
glad
to
be
here
to
talk
with
all
of
you
about
the
things
that
we're
doing
at
the
open
source
security
foundation
to
help
really
just
elevate.
The
state
of
security
across
the
open
source,
ecosystem
and
you've
heard
a
lot
about
software
supply
chain
yesterday
and
you'll
hear
even
more
about
it
today
and
and
the
need
to
secure
it
and
the
ways
that
are
vulnerable.
A
What
I
wanted
to
talk
a
bit
about
are
some
of
the
operational
things
we're
doing,
but
first
just
to
set
the
stage.
This
is
something
all
of
you
know:
open
source
software
is
90
of
the
software
world.
I
don't
care
if
you're
talking
about
a
car
or
a
phone
or
or
any
of
the
different
websites
out
there.
All
of
you
are
here
because
you
work
together
on
that
90
and
that
10,
maybe
it's
what
pays
your
salary?
Maybe
it's?
A
What
pays
the
bills
so
there's
always
going
to
be
that
10,
but
90
of
the
software
world
is
open
source,
and
this
is
studies
and
and
data.
They
get
cited
a
bunch
of
different
ways,
there's
something
actually
called
the
sauna
type
state
of
the
software
supply
chain
deck
that
they've
been
doing
for
a
couple
years.
That's
always
worth
referencing.
A
What
might
not
be
as
obvious
is
that
vulnerabilities
known
vulnerabilities
are
still
pervasive
through
the
software
that
we're
shipping
today,
29
of
popular
projects
contain
cves
in
their
dependencies,
sometimes
even
in
the
code
that
they
ship
out
and
even
the
non-popular
projects.
The
long
tail
have
lots
and
lots
of
known
cves
that
they
have
yet
to
address
in
their
dependencies
or
in
their
core
and
and
the
problem
isn't
just
obviously
known
cves.
A
It's
the
ways
in
which
the
software
that
we
build
and
the
way
we
choose
our
dependencies,
though,
and
pull
them
in
to
the
to
common
packages
and
distribute
them
and
get
them
to
the
end
users.
Those
are
under
all
sorts
of
new
kinds
of
attacks,
attacks
that
have
led
to
some
of
the
more
prominent
breaches
that
we've
all
heard
about.
A
I
don't
know
how
many
of
you
were
kind
of
online
at
this
time,
but
I
used
to
remember
getting
email
from
people
I
didn't
know
and
being
excited
about
that.
Like,
oh,
you,
hadn't
know
about
email
too.
You
must
be
cool
right
these
days.
You
get
spam
and
it's
like,
oh
I'm,
drowning
in
it.
But
back
then,
there
was
a
bit
of
a
presumption
that
if
you
could
stand
up
a
dot,
org
website,
yeah
and
and
distribute
software
from
it,
you
probably
knew
what
you
were
doing.
A
You
probably
took
a
lot
of
pride
in
your
work.
You
probably
were
doing
that
out
of
just
enough
insecurity
that
you
wanted.
Other
people
to
you
know
check
your
code
for
bugs,
and
that
kind
of
thing
that
was
my
trick.
I
had
zero
confidence
in
my
ability
to
code
and
the
world
is
much
better
off
without
my
code.
A
So
now
everything
from
compromised
access,
control
to
the
code
that
gets
out
there
without
any
other,
without
even
a
second
set
of
eyeballs.
Looking
at
it,
let
alone
a
group
of
people
taking
responsibility
for
it
to
compromise
source
code
systems,
which,
which
still
happen
all
the
time
to
to
all
sorts
of
ways
which
really
try
to
take
advantage
of
that.
In
fact,
some
of
you
perhaps
remember.
A
Well,
they
got
caught,
but
not
before,
burning
a
whole
lot
of
core
maintainer
time
so
much
so
that
the
university
of
minnesota
was
now
banned,
is
now
banned
from
contributing
to
the
linux
kernel
and
for
anybody
who's
worried
about
hackers
from
one
country
or
another
like
looking
at
this
as
a
way
to
compromise.
That's
that's
like
a
thing
to
remind
people
of
is
you
know,
hackers
know
how
to
use
vpns,
so
it
doesn't
matter
where
they're
coming
from
in
terms
of
whether
you
can
trust
them
or
not.
A
So
at
the
open,
ssf
and
we're
a
project.
That's
been
going
for
about
two
years
now
we
have
participants
in
our
community.
I'm
sure
many
of
you
work
for
organizations
that
are
part
of
what
we
do
I'll
show
the
nascar
logo
slide
in
just
a
bit.
But
there's
there's
not
just
one
solution
to
this
problem.
Obviously
right
there
we've
got
working
groups
in
a
bunch
of
different
domains
from
focusing
on
best
practices
where
it's
everything
from
the
best
practices
badge
that
some
of
you
might
be
familiar
with.
A
It's
been
around
for
for
quite
a
few
years
to
the
development
of
educational
materials.
For
teaching
secure
software
fundamentals
to
a
working
group
focused
on
vulnerabilities
and
and
how
those
get
disclosed
that
has
developed
a
guide
for
coordinated
vulnerability
disclosure
to
help
open
source
projects
that
perhaps
have
not
gone
through
a
cve
process
before
not
gone
through
coordinating
with
their
end
user
community
to
make
sure
people
are
exposed
for
as
little
time
as
possible.
A
A
We've
got
another
working
group
focusing
on
security,
tooling.
That
is
trying
to
come
up
with
all
sorts
of
automated
ways
to
analyze.
A
repository,
a
body
of
code
and
figure
out
what
are
some
worrisome
parts
about
what
you're
doing
here
right
as
well
as
to
to
to
use
some
more
computational
tools
around
the
cvs
and
and
and
disclosures
process
to
try
to
get
a
better
picture
of
risk
in
in
an
open
source.
Community
we've
got
another
one
focused
on
this:
the
supply
chain
integrity.
A
Initially,
it
was
kind
of
focused
on
identity,
and
then
we
realized.
Obviously
it's
a
hard
problem.
There's
lots
of
people
working
on
identity,
let's
instead
think
about
levels
of
attestation
of
process
through
the
software
supply
chain,
and
so
that's
the
working
group
that
oversees
salsa,
which
some
of
you
might
be
familiar
with
and
which
now
has
been
adopted
by
the
cloud
native
community,
and
I
think
we
just
saw
the
first
release
of
kubernetes
using
salsa
level.
Four.
A
If
I'm,
if
I'm
not
mistaken,
we
also
have
a
securing
critical
projects
working
group
focusing
on
things
like
trying
to
understand
what
are
the
critical
projects
that
are
forgotten
about
out
there.
What
is
the
next
openssl
or
or
log4j
that
everyone
uses
that
has
professionals
working
on
it,
but
simply
not
enough
right?
That
is
simply
forgotten
about
and
in
fact,
one
of
the
biggest
things
that
we've
done.
There
is
fund
a
project
with
harvard
to
develop
something
called
the
harvard
census.
A
A
To
talk
about
common
systems,
common
protocols,
how
do
we,
you
know,
do
things
consistently
across
those
when
it
comes
to
things
like
requiring
multi-factor
auth
for
developers
and
and
publishers
of,
say,
the
top
and
100
most
important
components
right
or
start
to
adopt
things
like
sig
store,
which
is
a
a
a
digital
signatures
platform
for
signing
of
software,
artifacts
or
even
salsa,
or
other
things?
So
and
then?
A
Finally,
we've
got
a
couple
of
key
projects
that
are
kind
of
hang
off
to
the
side
that
actually
have
their
own
funding,
that
we
have
some
oversight
over,
but
we
really
try
to
stay
close
to
I'll
go
from
the
bottom
up.
One
of
those
is
called
the
gnu
tool
chain
infrastructure.
It
turns
out
the
the
build
servers
and
the
the
the
really
critical
pieces
that
are
involved
in
the
development
of
gcc
glibc.
A
On
top
of
a
surprisingly
few
number
of
people
who
were
building
that
on
personal
boxes
and
off
to
the
side
of
corporate
resources
that
needed
a
bit
more
rigor,
it
needed
a
bit
more
kind
of
like
what
we
have
for
the
linux
kernel
in
terms
of
build
systems,
and
so
we've
been
working
with
that
community
to
better
support
the
build
systems
that
that
everybody
depends
upon
to
be
to
be
to
be
locked
down
and
hardened.
And
then
two
more
I
mentioned
sig
store.
A
Six
store
is
basically
kind
of
like,
let's
encrypt
in
terms
of
very
low
levels
of
proofing,
required
to
get
a
key
pair
to
be
able
to
sign
artifacts
in
the
software
development
process,
partly
focused
on
how
to
make
it
really
really
easy.
Not
automated.
This
is
important.
You
still
want
a
human
in
the
loop
but
easy
enough
to
go.
A
How
do
you
systematically
go
and
scan
as
many
different
repositories
out
there?
For
you
know,
let's
say
with
log4j:
we
discover
hey
parsing
of
untrusted
input
for
format.
Strings
is
an
anti-pattern.
Who
else
is
doing
that
out
there
and
can
we
write
codeql
queries
to
do
that?
Can
we
write
other
kinds
of
scripts
to
go
and
look
for
that
and
then
a
second
part
of
alpha
omega
is
going
in
providing
funding
for
key
open
source
projects.
A
The
alpha
projects
out
there,
who
don't
yet
have
some
of
the
resources
or
community
support
for
for
core
security
practices
that
we're
hoping
to
see
eventually
becomes
a
key
part
of
every
major
open
source
project.
Things
like
a
funded
security
team
and
in
fact,
one
of
the
first
places
we
put
some
funding.
A
But
it's
also
to
try
to
develop
a
a
capacity
in
that
community
for
more
than
just
the
one
person
we're
able
to
fund
to
go
and
build
a
culture
of
of
more
secure
development.
Perhaps
it's
adopting
other
other
tools
and
other
standards
that,
like
zig,
store
or
salsa.
Maybe
it's
simply
about
trying
to
get
better
metrics
into
to
where
what
are
what
are
perhaps
the
more
worrisome
kinds
of
projects
that
are
heavily
dependent
upon?
A
How
do
we
help
instill
a
culture
of
security
releases
and
and
coordinated
disclosure?
All
those
kinds
of
things
are
part
of
that
process,
and
what
we're
hoping
to
do
is
find
a
repeatability
to
this.
That
then,
could
be
applied
to
other
critical,
open
source
projects
that
also
are
understaffed
on
their
security
teams
and
provide
some
funding
to
those
projects
as
well
to
help
them.
In
fact,
we'll
have
two
more
that
we'll
launch
soon
on
that
front,
but
to
also
help
inspire
the
communities
we
work
with
and
the
key
stakeholders
in
that
community
to
go.
A
You
know
what,
if
we
have
a
pool
of
money
that
we
fund
the
kind
of
core
operations
of
this
project
with.
Maybe
we
should
include
some
more
funding
for
kind
of
this
security
proactivity.
So
that's
really
the
big
idea
behind
alpha
and
kind
of
what
we're
doing
with
the
the
npm
community.
This
is
the
nascar
slide
I
mentioned
just
to
try
to
make
it
across.
A
In
our
perspective,
most
of
our
members
are
in
the
u.s
and
a
few
in
europe
and
a
few
in
the
asia
pacific
region,
but
everybody
has
common
cause
here
to
to
to
think
about
how
do
we
improve
the
state
of
security?
In
fact,
into
the
six
minutes,
I've
left
I'm
gonna
breeze
through
something
really
quickly
that
we
we've
recently
accomplished
or
worked
on
with
the
us
government,
although
what
we're
doing
here
will
be
applicable
to
any
government.
A
So
we've
put
together
something
called
the
mobilization
plan,
and
let
me
just
give
you
a
bit
of
a
background
to
this
in
december.
All
of
you
perhaps
saw
and
heard
about
log
for
shell,
and
it's
it
really
sucks
when
you
become
a
poster
child
for
something
that
you
don't
really
deserve.
The
log
for
j
developers
are
all
pros.
Apache
has
a
great
process
behind
what
they
do,
but
they
missed
a
few
things.
A
Are
you
all
okay
like
if
you
guys
are
the
bridges
and
highways
of
the
internet
and
of
this
digital
cultural
building,
and
something
like
this
can
pop
up
like
an
earthquake
like
a
really
massive
like
worldwide
earthquake
and
cause
us
to
have
to
scramble
like
this?
Where
are
there
other
problems
like
this?
We
should
be
knowing
about,
and
how
do
we
reduce
the
chances
of
it
happening?
How
do
we
make
it
easier
to
deal
with
it
when
it
does
happen,
and
is
there
something
fundamentally
wrong
here
with
how
open
source
is
built?
A
You
know
in
in
the
executive
branch
about
10
different
companies,
us
and
the
apache
software
foundation,
to
talk
about
the
problem
and
after
six
hours
we
kind
of
boiled
it
down
to
three
kind
of
big
overarching
goals:
securing
the
production
of
open
source
code,
improving
vulnerability,
discovery
and
remediation
and
shortening
the
time
it
takes
to
fix
patches
and
so
in
re.
As
an
outcome
of
that
meeting,
we
at
the
open,
ssf
started
to
think
hey.
A
A
Let's,
let's,
let's
really
invest
in
getting
this
stuff
out
there
and
driving
adoption,
because
you
all
know,
there's
things
you
can
invest
in
from
a
devrel
point
of
view,
from
a
building
of
core
code
that
doesn't
just
show
up
on
its
own
kind
of
point
of
view
with
those
three
goals.
What
are
the
major
problems
that
we
might
be
able
to
address
when
it
leads
to
building
better
open
source
software
and
and
addressing
those
issues
in
the
software
supply
chain?
A
Where
are
there
pre-existing
efforts,
whether
inside
the
open,
ssf
or
not,
that
are
already
starting
to
address
those
problems,
things
that
are
like
experiments
that
are
proven
or
or
things
that
are
demonstrable,
that
we
can
just
double
down
on
or
put
10x
the
effort
into
repeating
building
on
those
efforts?
What
are
are
the
resources
we'd
need
if
money
were
no
object,
but
not
it's
always
an
object.
A
But
if
you
had
enough
money
to
go
and
solve
these
problems,
what
would
it
take
and
what
would
be
a
reasonable
strategy
to
have
impact
a
demonstrable
impact
on
this
within
the
first
two
years?
So
we
developed
this
mobilization
plan,
which
is
really
the
first
time
I
know
of
and
at
least
the
linux
foundation,
that
a
community
has
tried
to
systematically
ask
these
big
questions
and
and
be
ambitious,
be
be
usually
with
the
linux
foundation.
A
A
We
were
about
facilitating
all
of
you,
but
if
we
were
to
be
a
bit
more
top
down
and
and
try
to
to
really
drive
an
impact
with
our
community,
what
would
that
look
like,
and
so
we
developed,
along
with
our
governing
board
and
all
the
experts
in
our
community,
a
plan
that
kind
of
our
surprise
called
for
150
million
dollars
in
funding
over
two
years
on
ten
different
themes
and
I've
got
2
minutes
and
48
seconds
left
to
walk
through
each
of
those
10.
So
I
won't
do
them
justice
at
all.
A
It's
not
done
it's
things
that
you
know,
plans
that
will
continue
to
evolve,
but
we
rolled
it
out
in
may
in
a
room
with
again
all
the
same
people
that
we
had
at
the
first
meeting
from
from
government,
along
with
our
own
members
and
a
bunch
of
other
open
source
projects
and
the
like
reviewed
it
together
and
and
actually
in
that
conversation
both
with
the
government.
It
was
like
how
do
we
align
this
with
what
the
government's
already
doing?
A
We
weren't
there
to
like
put
a
handout
to
the
government
to
pay
to
put
money
into
this
plan
just
yet
we'll
see
what
happens
over
the
course
of
time
we're
having
some
other
conversations
with
other
governments
too,
but
from
our
own
community.
We
raised
30
million
in
pledges
against
that
plan.
Now
we're
still
having
to
figure
out
where
that
goes,
and
what
that,
how
that
gets
applied
as
a
as
a
really
quick
scan
of
those
10,
the
first
one
is
focused
on
secure
education
on
teaching
software
fundamentals.
A
We've
got
courses
up
on
both
edx
and
the
lf
training
portal
that
take
about
20
hours
to
go
through.
It's
not
a
huge
thing,
it's
half
of
a
work
week
that
goes
through
all
the
major
kinds
of
how
do
you?
How
do
you
program
defensively?
How
do
you
keep?
How
do
you
think,
like
a
like
somebody,
who's
going
to
red
team,
your
code
right?
How
do
you
not
assume
that
security
by
obscurity
is
enough
right?
How
do
you
work
with
these
things?
A
We
want
to
take
that
courseware
and
then
blanket
the
world
with
it
right
and
get
companies
to
adopt
it
as
a
standard
for
when
their
developers
engage
in
open
source
offer
even
write
code
for
them
right
all
these
other
things.
The
first
first
is:
how
do
we
get
that
everywhere?
The
second
is:
how
do
we
develop
kind
of
a
risk
assessment,
dashboard
kind
of
like
some
of
the
stuff
for
us
showed
you
yesterday,
which
is
on
a
project
by
project
basis?
A
How
do
I
understand
how
risky
this
code
is,
or
if
I'm
looking
for
a
new
module
that
does
x
here
are
the
three
different
ones
that
do
it
and
assembling
as
much
objective
data
as
we
can
about
the
things
that
we
know
make
for
more
secure
software?
How
do
we
help
people
choose
the
more
secure
alternatives
or
help
developers
understand
what
they
can
do
to
change
that?
How
do
we
drive
more
adoption
of
digital
signatures
throughout
the
software
supply
chain,
based
on
sig
store
but
interfacing
with
other
digital
systems?
A
How
do
we
develop
an
incident
response
team
that
can
work
with
open
source
projects
when
they
first
get
when
they
get
their
first?
You
know
security
notice.
That
looks
like
a
really
big
deal.
Who
will
they
call?
Who
could
they
call
to
help
them
manage
a
response
to
this
make
sure
their
patch
is
the
right
one?
We
know
you
can't
just
go
and
put
new
mandates
on
open
source
developers.
You
have
to
show
up
with
help,
so
an
incident
response
team
for
that.
A
A
And
then,
finally,
where
are
there
other
places
in
the
infrastructure
to
invest
in
improving
the
software
supply
chains,
both
those
major
distribution
hubs
and
the
gatekeepers
there
or
other
places
upstream,
where
better
practices
and
better
default
tooling,
so
that
it's
built
in
so
you
don't
have
to
lift
a
finger
to
be
more
secure
about
what
you
do
all
together.
This
called
for
70
million
dollars
the
first
year,
80
million
dollars
the
second
year.
This
is
ambitious.
A
A
Here
I
and-
and
just
as
the
last
thing,
I
know
140
million
dollars,
150
million
dollars
might
sound
like
a
lot,
but
a
bigger
number
than
this
700
million
dollars
was
the
fine
that
the
ftc
levied
on
equifax
in
2017
after
the
2017
data,
breach
that
they
had
because
they
failed
to
update
apache
struts
quickly
enough
and
so
as
a
leveraged
piece
investment.
This
is
going
to
really
pay
off
and
the
ftc
has
already
said:
they're
going
to
go
after
organizations
that
suffer
data
breaches
if
they
haven't
updated
their
instances
of
log4j.
A
With
that
get
the
plan
join
us
in
the
open
ssf
on
the
projects
we're
working
on
we're
really
eager
to
help
uplift
everybody
in
the
community.
We
know
all
the
communities
are
different
in
how
they
build
code
and
so
really
eager
to
go
and
meet
you
where
you
are
and
provide
tooling,
to
make
everything
that
we
build
more
secure
by
default.
Thank
you.
So
much.