hello my name is david a wheeler
and i'm here to talk about securing open
source
i hope to convince you about four key
points
attacks weakness hope change
attacks hope weakness hope
change what do i mean by that well the
first part
part i hope you already are convinced of
attackers
are attacking systems they're attacking
those systems via the vulnerabilities
that they have
when they are deployed and also through
their supply chains
weakness sadly those attackers are often
succeeding
um and this is primarily because current
development
and supply chain processes really often
don't adequately counter attacks
and even when they're fixed they often
don't get deployed in a timely way
but i don't want you to leave without
hope there is hope
there are counter measures to attacks
and there's ongoing work to ease their
deployment
for change we need to change how we
develop software how we select it how we
deploy it
uh things like making sure that things
are secure by default
and we're going to need to continuously
learn from adversaries
and anticipate adversaries
i think that first point about
software's under attack is pretty
obvious
um i mean these are just some logos and
and some
indications of examples of software
under attack
uh the top left symbol there is heart
bleed um
but in fact there's a whole bunch of
different attacks and vulnerabilities
um but of course repositories have been
under attack
um the more recent solarwinds orion
subversion
was caused through a subverted build
environment it didn't matter what the
software developers wrote because the
code they wrote wasn't what was going to
be used for shipping
um there's a an interesting paper called
the backstabbers knife collection that
reviewed over 174 supply chain attacks
found a dominance of type of squatting
attacks for example
a good part of this problem is that most
projects and organizations
simply cannot accurately summarize
what software is within their system
and some of you may say oh hey we use
cloud therefore
somehow we're immune to all this so of
course that's ridiculous
um dan lawrence has this interesting um
article where uh he notes that today's
cloud
infrastructure is still being built out
of duct tape and kite strings
um so he played around with um uh helm3
he looked at a particular helm
chart and tried to answer what you would
think would be simple questions
you know exactly what software was
installed where did it come from
how was it built and he could not answer
those questions
and as a result you know he he made some
interesting observations one of course
is if you think your container scanning
setup is catching everything
think again he found 25 vulnerabilities
in just that one
package um and he noted that hey package
managers add convenience but
every layer adds trust and i would also
add adds time
it can take a long time for a
vulnerability that's been fixed to get
through all those layers
so it's i think it's helpful to think
about how is software developed
um you know and so this is a simple
model of the software supply chain
called a supply chain integrity map as
you can see you know it's a simple map
what's what goes on developers work
within their local environments
then send their changes and so on off to
source and data repositories
then they that software gets built and
verified
eventually it's approved for release to
be sent out to various package
repositories and distribution platforms
uh hopefully they're that's assessed in
various ways
both the builds and the eventual
packages
finally people select and acquire them
and then bring them into their
environments to be
uh to go through the cycle all again and
eventually
things get deployed out to operations
and of course there are cycles here
because smaller components get
brought into larger components which get
into larger components
but of course if you look at this from
the point of view
of an attacker that's a system and
systems can be attacked
and a great way to learn how to attack
them is to look at those parts
and see how those various parts of the
system can be attacked
and those these red squares are just
sample kinds of attacks and there's a
lot of them
uh typo squatting which is basically
confusing
uh acquirers and developers uh
into thinking they're installing one
package when they're installing another
dependency confusion where they think
it's the software's coming from one
repository
but it's actually coming from another
there's malicious software
um there's all sorts of
vulnerabilities that go in as part of
developments
and just there's a whole host of
problems
but i don't want you to leave with oh my
gosh there are so many problems
because in fact there are counter
measures
and these are again just a sample of
counter measures
various approaches where you can do
various things
to counter some of those attacks i
certainly can't talk about all of them
but a trivial one i'll note for example
is you know
one of the big problems right now is
developers often don't understand a lot
of things nobody teaches them in classes
and so a little education and training
can go a long way
and of course that's not enough there's
various tools you can add to say the
build verification processes and so on
to really help
there's no silver bullet there is no one
thing if you do
the one thing congratulations you have
solved all problems
that's not how it works instead you need
to bring
a variety of approaches to bear to
counter the different kinds of attacks
that attackers can do
so what can open source software
developers and users do
well if you're not already doing these
already here's some first starting steps
you'll learn how to develop and acquire
secure software
uh if you don't have if you if nothing
else
take a look at the secure software
development fundamentals course it's
free
it's on edx go take it there's others
take those
but learn how to do this stuff make the
software secure by default
make it easy to use securely harden it
up
against attacks if you're doing open
source software development
work to earn an open source i'm sorry
cii best practices badge there's the url
use many tools to find vulnerabilities
in your build and verification
environment
no tools will not find everything but
they're helpful as
part of a solution of course monitor for
known vulnerabilities
in the in whatever you depend on so that
you can immediately respond and
immediately update
of course in order to do that rapid
update you need to use package managers
and automated tools so you can rapidly
respond
when a vulnerability is found and i
mentioned these tests those need to
include negative tests
in other words there are some things
that should not be allowed
test for that make sure they stay not
allowed
this is something that people often
forget particularly if they're using tdd
finally evaluate software before you
select it you know look for typo
squatting is that really the right name
is that software malicious do you have
reason to believe it secure
and when you're evaluating here's some
sample things to consider
is it easy to use securely is there
evidence that developers work to make it
secure
is it maintained has significant use
what's the license
um if it has a not an open source
license
shockingly it's not going to be
collaboratively developed like an open
source project
if it's important what is your own
evaluation of it
the good news is lots of folks are
working to make
things better the open ssf for example
open source security foundation
uh is working on this there's a number
of other projects here in fact this is a
short list there's many more uh uh
projects and foundations and
organizations working to make things
better
so if you are an open source software
developer user
you need to do all those things i
mentioned earlier but you also need to
prep for the future
here's some things that i see coming
down the pike
um you need to start being prepared to
generate and request software build
materials uh there's a lot of pressure
in even high levels of government and so
on to start saying we need to know
what's in our software
and we need to be prepared to answer
that question it's a reasonable question
look for more information about the
software before you select it there's
organizations like those within the open
ssf
that are working to improve information
about the software
uh that you're to improve information
about the software so you can have
better information when you select it
i think verified reproducible builds are
important that's particularly useful for
countering
uh subverted builds um improved
cryptographic signature verification
um you know we've had this for a long
time but it's challenging to do
verification
i think sigstor has a lot of promise um
but you know we'll see but no matter
what i think this is something we need
to see more of
more generally integrity attestation
approaches like in toto
and increasing use of memory safe and
more generally safe languages
and more broadly working with others to
help things
to help make things better there's a lot
of opportunity
and frankly there are folks who could
really use your help to
speed these up so let me do a quick
recap
i came and said there are four key
points i wanted to talk about
attacks weakness hope change
and i hope that you'll see that it's yes
they're attacks and yes there's weakness
but there is hope and but will need to
change to take advantage of that hope
a quick parting thought developing and
deploying secure software is a journey
of learning
and improving it's not a single event
but that's okay we just need to get
started
thank you very much for your time