►
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Bringing Continuous Delivery to Open Source - Sudhindra Rao, JFrog
Open-source software plays an essential role in the supply chain of modern software development. Proprietary software is typically composed of 75% or more open-source dependencies. In open source software we rely on ad-hoc methods of software process and quality control.
A few of those ad-hoc methods have received much attention in the last few years - need of MFA on source repositories, need of signing every binary, need for verifying such signatures and building trust in open source packages.
In this talk we want to cover different tools that help in making these methods easy to implement and help you decide which ones fit your way of working. We will talk about the recent attacks on the open source software, SLSA framework, Sigstore, Notary, Pyrsia. We will also highlight how the Continuous Delivery of open source often does not receive the same attention and rigor as compared to proprietary software. We discuss how to apply this rigor and enjoy the same benefits with open source.
A
While
you
read
this
quick
trivia
question,
how
many
of
us
have
played
badminton
quick,
raise
of
hands?
Does
anyone
know
the
original
name
of
badminton
and
this
is
going
somewhere?
But
no
so
I
come
from
the
town
that
invented
badminton
where
it
started.
The
original
name
of
Abandonment
badminton
is
Puna
and
that's
the
place.
I
come
from
the
reason
I
mentioned.
That
is
you
in
during
this
talk.
A
You
will
also
see
me
sharing
some
of
the
pictures
and
imagery
of
that
City
that
I
love
and
that
will
hopefully
add
to
the
context
that
I'm
going
to
talk
about
so
I'm
sudindra
I
work
at
jfrog.
Currently,
I
am
the
development
manager
for
Persia
the
project
that
that
we
just
announced
as
part
of
CDF
and
I
wrote.
A
A
Hopefully,
this
will
give
you
an
Insight
on
what
you
know,
or
this
may
be
similar
to
what
you
are
using
in
building
your
proprietary
software.
So
we
had
some
source
code.
There
are
some
components
that
came
together
there
are.
There
were
Integrations
on
that
kubernetes
platform
like
networking
and
observability,
that
that
are
not
part
of
the
communities
platform.
So
all
of
these
are
built
and
they
take.
A
You
know
X
number
of
minutes
to
build
individually
and
the
the
really
heavy
task
comes
when
we
start
building
these
on
variety
of
configurations
that
that
these
need
to
be
deployed,
and
the
reason
I
stopped
at
49
is
that
those
were
the
number
of
configurations
we
were.
We
were
building
on
this
platform.
A
Each
of
them
then
went
through
some
acceptance,
testing,
some
of
which
was
manual,
and
then
we
used
to
publish
a
downloadable,
binary
or
downloadable
software
that
people
can
install
on
on
cloud
of
their
choice
now,
just
to
put
some
stuff
into
context.
Each
of
these
pipelines
took
eight
hours
right
and
that
added
up,
so
it
used
to
be
a
whole
three-day
effort
to
bring
bring
up
a
new
version
and
then
figure
out
if
things
things
broke
and
so
on.
A
Right-
and
this
is
the
kind
of
rigor
we
put
in
in
developing
a
proprietary
software
right
this.
This
is
a
dedicated
team
trying
to
trying
to
build
things.
Everyone
knows
everyone,
or
at
least
they
can
be
traced
back
to
what
they
are
doing.
Every
commit
can
be
traced
back
to
a
system
that
it
came
from
and
and
if
a
component
builds
failed
in
the
integration,
we
could
go
back
to
the
component
team
and
say
hey.
A
A
There
is
no
infrastructure
that
will
give
you
all
of
this
information
and
no
trustworthy
information,
and
some
of
this
was
required
for
security
like
identifying
CVS
and
all
of
that.
Some
of
this
was
required
for
legal
purposes
to
ensure
that
we
know
we
didn't
violate
copyright
and
all
of
that
and
are
we
done
we're
still
not
done,
because
there
is
some
process
that
that
happens
like
there's
some
marketing
that
needs
to
happen.
Some
legal
documents
needs
to
be
signed.
A
A
The
reason
that
these
are
good
practices
is
that
you
know
you
have
a
dedicated
Team.
All
of
them
know
each
other
there's
an
inbuilt
trust,
and
how
do
we
do
that
today
in
open
source?
We
know
these
are.
These
are
some
some
of
some
of
the
research
data
I
found
from
my
references,
70
78
of
the
code
that
is
currently
shaped
is
is
open
source,
meaning
out
of
all
the
code
bases
that
that
are
shipped
78
of
a
code
in
those
code
basis
is
open,
is
open
source.
A
Almost
all
projects
are
dependent
on
some
open
source
somewhere
right
and
we
we
have.
We
have
come
a
long
way
in
adding
automation
at
various
levels
to
help
with
releasing
them
and
Linux
project
itself
is
a
very
good
example,
but
how
does
it?
How
does
it
scale
we
when
we
decide
to
use
open
source?
We
we
just
think.
A
We
find
badges
like
that
saying
that
if
it
is
green
or
if
it's
some
salsa
level
or
something
that
is
flashy,
we
go
go
after
it
and
and
pick
that
one
or
we
look
at
the
GitHub
stars
like
I
was
saying
or
if
there
are
more
Forks.
That
means
you
know,
there's
more
Community
around
it,
but
is
that
enough.
A
And
this
is
what
I
think
when
I
think
about
open
source
right,
open
source
is
infrastructure,
and
this
is
this
is
a
picture
of
you
know
a
Mumbai
Pune
Expressway
that
I
love
to
ride,
and
it
is.
It
is
really
beautiful
during
the
rainy
season,
because
there
is
rain
coming
down
and
there
are
clouds-
and
it's
amazing
and
it's
it
works
really
well,
when
infrastructure
is
in
good
shape
like
this
right
and
what
happens
when
when
that
is
not
the
case
when
that
is
not
the
case.
A
The
thing
that
worked
for
us
for
years
and
years
is
now
in
trouble
and
we
don't
have
a
way
to
protect
it
right
to
improve
the
infrastructure
system.
I
mean
some.
Some
solutions
are
obvious
that
you
need
to
put
the
right
right,
drainage
system,
so
that
so
that
this
doesn't
happen
in
the
future.
We
need
we
need
similar
things
in
open
source
and
if
we
look
in
a
similar
way,
if
we
look
deeper
onto
this
project,
this
is
what
I
see
in
log4j
and
I
know
that
people
are
working
on
this.
A
So
it's
the
build.
The
workflow
is
kind
of
disabled
right
now,
maybe
they
are
working
through
some
things
and
last
few
builds
are
read.
So
this
is
not
really.
You
know.
This
is.
This
is
what
my
software
depends
on,
but
this
is
the.
This
is
the
trust
level.
I
have
Rascal
arrest,
client,
the
one
I
showed
has
had
a
name
spotting
last
week
right
so
again,
and
the
third
thing
that
I
showed
you,
which
was
Salsa
level
3
project
that
actually
is
not
a
project.
That's
a
Ping
Server
that
is
no
code.
A
Ping
Server
that
was
demonstrated
by
Kelsey
Hightower
in
in
a
in
a
recent
talk,
so
I
just
picked
that
and
that
doesn't
exist.
Even
it's,
because
it's
somebody
he
just
he
was.
He
was
demonstrating
how
you
can
fake
salsa
levels
just
by
putting
Badges
and
that's
what
it
is.
So
we
we
rely
on
those
kinds
of
trust
mechanisms
and
that
is
very
weak
and
some
some
more
like
emphasis
on
how
open
source
is
sort
of
ingrained
right.
A
If
you,
if
you
build
a
web
app,
that's
how
much
open
source
software
is
as
part
of
the
web
app.
If
you
look
at
very
famous
libraries
that
everyone
here
knows
right,
pandas
people
probably
know
or
have
used
it.
It
shows
that
it
has
1400
commenters,
but
the
actual
work
is
being
done
by
four
people.
How
can
you
expect
the
four
people
to
have
a
complex,
a
mature
CD
system?
You
can't
they
need
support,
and
there
is
this
trust
or
inbuilt
trust
that
oh,
what?
What
is?
A
What
is
this
person
going
to
do
wrong
just
be
if,
if
I
give
them
access
well,
this
person
can
write
a
script
that
can
steal
Bitcoin.
That's
what
happened
on
a
recent
project
that
is
a
event
stream
library
that
was
very
popular
and
the
original
maintenance
said:
hey
I
I'm
getting
help.
Maybe
I
should
just
trust
them
and
what
could
they?
What
could
they
do
wrong
right,
and
this
is
what
happens
if
you
put
put
a
trust
in
in
in
the
in
the
people
that
that
really
don't
deserve
this?
A
A
These
small
dependencies
that
that
we
blindly
use,
if
you,
if
you
actually
run
a
hello
world
application
in
npm,
it
seems
there
are
about
more
than
thousand
dependencies
that
come
come
with
it
and
we
don't
pay
attention
to
those,
and
this
is
just
the
first
level
dependencies
and
there
are
transitive
dependencies
the
other
days,
the
other
day
I
was
assessing.
You
know.
A
Why
is
my
application
using
openssl
I
found
out
that
openssl
is
being
required
by
native
TLS
and
that
is
required
by
Tokyo,
which
is
a
async
library
for
rust
and
I
I
only
picked
Tokyo
and
I
never
paid
attention
to
that?
Oh
now,
openssl
is
required,
and
it's
important
in
this
context,
because
openssl
also
has
difficulty
in
being
compiled
for
different
operating
systems,
which
was
what
we
were
trying
to
do
right.
A
Dependencies
are
so
hidden
that
we
really
really
don't
know
where
they
came
from
and
we
don't
really
pay
attention
to
how
they're
being
used
right
and-
and
this
is
I-
think
this
is
a
well-known
story
where
a
bridge
in
Pennsylvania
was
on
its
knees
already
and
and
the
infrastructure
build
bill
was
the
impetus
to
fix
these
kinds
of
problems.
So
we
need.
A
We
need
that
kind
of
emphasis
to
improve
the
CD
etiquette
for
open
source
and
generally
people
talk
about
GitHub
when
we
talk
about
open
source,
but
here
is
a
research
that
actually
compared
GitHub
and
other
places
where,
where
open
source
software
is-
and
it
found
that
more
or
less
the
number
of
committers
for
every
project
stays
the
same
between
two
and
ten,
it's
not
a
big
big
team.
They
are
doing
it
more
more
on
a
philanthropic
basis,
they're
doing
it
on
the
side.
A
It's
not
their
full-time
job,
but
they're
still
trying
to
support
it.
So
so
there
is,
we
need
to
put
more
people
more
more
energies
there.
So
talking
about
Doom
and
Gloom.
What
can
we
do
about
fixing
the
the
CD
etiquette
for
our
open
source
right?
There
must
be
some
things
we
can
do
and
I
want
to
share
some
of
the
some
of
the
work
that
has
been
happening
before
the
pandemic
and
even
through
the
pandemic.
A
100
automated,
if,
if
possible,
remove
the
human
parts
of
the
often
my
build
pipeline
that
I
showed
it
needs
to
be
trustworthy,
it
can't
depend
on
the
badges
and
the
stars,
and
all
of
that-
and
it
needs
to
be
Dependable
I-
need
to
know
every
single
detail
about
every
single
dependency
that
I'm
using.
Also
this
system
cannot
go
down.
You
cannot
have
the
situation
where
npm
or
Us
East
one
was
down
and
it
stops
going
to
production.
A
It's
not
so
much
just
going
to
a
continuing
development
with
development,
But
continuing
to
release
the
production.
So
in
in
the
last
few
years
there
has
been
more
emphasis
on
protecting
the
supply
chain.
There
have
been
tools
that
allow
you
to
write
software
bill
of
materials.
There
is
also
government
emphasis
regulation
on
how
to
improve
the
cyber
security
etiquette,
and
some
of
this
is
required-
the
regulation
literature
so
that
the
practices
start
start
flowing,
but
this
is
not
going
to
be.
A
A
Some
of
the-
and
this
is
the
most
talked
about
research
around
software
supply
chain
and-
and
the
first
thing
this
does
is
this-
lays
lays
out
the
land
for
to
Showcase
what
are
the
places
where
software
Israel
is
vulnerable
right,
and
this
gives
us
something
to
play
with
and
figure
out.
You
know
if
our
tools
are
capable
of
handling
all
this,
and
if
you
compare
this
with
my
my
original
CD
flow,
this
is
much
less
complicated
and
in
a
real
life
situation
there
might
be
more
attack
vectors
that
you
will
need
to
handle.
A
A
A
Basically,
the
point:
the
idea
is
to
make
sure
that
when
you
put
any
image
into
production
that
is
already
signed
and
it
can
cannot
be
tampered
with
and
so
on,
so
it
it
allows
you
to
do
continuous
delivery
on
that,
because
a
lot
of
those
signing
verification
processes
are
now
automatable
right
and
that's
all
try
to
tries
to
solve
the
very
end
of
of
the
supply
chain
where,
where
the
packages
are
sorry,
the
images
are
being
shipped
to
your
kubernetes
clusters
right.
So
that's
good,
that's
a
good
start!
A
There's
another
project
called
six
store
and
it
tries
to
do
the
same
thing
signing,
but
with
a
lot
more
variety
of
ecosystems.
Now
you
can
sign
your
Pi
Pi
packages.
Now
you
can
sign
your
ruby
gem,
so
you
can
sign
your
Java
packages
and
so
on
right
and
you
can,
you
can
take
it
all
the
way
to
your
through
your
supply
chain
into
kubernetes.
A
So
if
you
haven't
looked
at
these
projects,
go
look
at
them
and
and
at
least
find
out
how
you
can
use
them,
and
this
six
store
and
the
projects
are
underneath,
do
a
little
more
like
I
said
they
they
sign,
and
you
can
verify
all
of
those
at
the
end
of
the
supply
chain
and
at
the
beginning.
Also,
when
you
start
consuming
them,
you
can
verify
that
hey
this
thing
that
I'm
trying
to
download
is
now
signed
and
and
and
I
know
that
it
came
from
a
certain
developer.
Is
that
enough?
A
There
are
all
these
things
in
between
that
that
need
to
be
addressed,
though
tekton
chains
is
another
project
which
allows
you
to
take.
Take
it
for
kubernetes
deployments
that
aren't
tecton
all
the
way
through
through
the
chain.
Right
same
thing
tries
to
address
the
the
one
end
of
the
supply
chain,
and
we
need
that
we
need.
We
need
to
know
what
goes
into
our
production
yeah
right
and
with
with
when
we
looked
at
the
landscape.
That
is
what
we
found
that
we
need.
A
We
need
something
that
allows
you
to
build
those
dependencies
better
and
that's
when
we
what
we
started
investing
time
in
building
this
and
we
called
it
Persia.
So
what
Persia
does
is
actually
allows
you
to
build
from
Source.
You
can
take
any
open
source
project
and
build
it
from
Source.
You
can
figure
out
how
it
was
built.
You
can
verify
that
it
was
built
built
in
the
way
that
you
wanted
it.
A
A
So
so
this
is
something
similar
that
that
people
are
doing
to
to
ensure
that
there
are
no
single
points
of
attack
like
the
ones
that
happened
in
solarwinds
case.
So
this
is.
This
is
something
that
they
are
investing
in
in
it,
and
Persia
also
has
a
prominence
log,
so
you
can
actually
write
automation
to
figure
out
where
certain
thing
came
from
and
it's
not
just
the
Stars.
It
tells
you
that
this
binary
was
built
from
this
gitsha,
and
these
were
the
steps
that
were
run
in
building
it
here.
A
Here
was
the
end
result,
and
then
it's
then
it
is
stamped
with
with
vulnerabilities,
even
the
known
vulnerabilities
at
that
time,
and
you
can
ask
these
kinds
of
questions
what
this
allows.
You
is
to
write
automation
on
top
to
us
to
actually
make
release
decisions.
So
you
don't
have
to
wait
and
figure
out.
You
know
somebody
has
to
go
and
do
a
due
diligence
on
whether
you
know
this.
A
This
binary
is
something
that
I
can
use
and
there's
there
are
a
few
few
more
projects
that
I
wanted
to
talk
about,
because,
as
I
showed,
it's
not
enough
that
we
have
this.
This
the
simplistic
supply
chain
covered
Persia
to
work
well
needs
needs
to
build,
needs
to
have
reproducible
bills,
because
only
reproducible
bills
can
be
verified
against
each
other
right.
A
So
there
is
a
project
which
Google,
open
source
team
is
I,
think
doing
around
reproducible
builds
and
it's
it's
a
heavy
lift,
because
people
have
a
lot
of
variety
of
ways
in
which
they
can
get
to
the
same
result
sometimes
or
they
have
a
very
complex
ways
in
which
they
get
to
the
build
and
in
between
do
do
many
other
things
and
and
what
the
Google
team
is
trying
to
figure
out
is.
What
is
that?
One
script
that
you
can
derive
and
make
that
build?
Reproducible.
A
Another
thing
that
we
Overlook
is
GitHub
stars
and
salsa
badges.
They
don't
tell
you
what
is
happening
real
time
with
with
the
libraries
that
you're
using
what
is
let's
say
you
download
an
Alpine
image
351.
What
are
the
vulnerabilities
that
you're
facing
yeah?
Is
that
vulnerability,
vulnerability
in
your
development,
staging
or
production?
And
how
are
you
going
to
handle
that
so
there's
more?
There
is
more
stuff
happening
around
integrating
vulnerabilities
into
the
into
the
CD
pipeline
itself,
and
and
Percy
is
going
to
do
that.
A
A
There
is
automation
that
needs
to
be
built
on
top
of
this,
so
that
you
can
actually
have
a
continuous
delivery
pipeline
that
looks
more
continuous
and
not
not
as
broken
as
it
is
today
and,
as
you
see,
there
are
still
some
gaps.
How
do
we?
How
do
we
make
sure
that
the
source
that
is
coming
from
out
from
a
source
control
system
is
secure?
How
do
we?
How
do
we
make
sure
that
Source
control
system
is
not
compromised
right?
There
are
some
unsolved
problems
that
that
other
teams
are
working
on
and
we
need.
A
So
here
I
want
to
sort
of
summarize
with
a
call
to
action.
You
should
go
back
and
find
out
if
you
do
have
a
good,
continuous
delivery
plan
for
your
open
source.
Have
you
used
any
of
the
tools
that
I
mentioned?
If
you're
not
are
you
do
you
find
any
opportunity
to
do
to
do
that?
Let's,
let's
do
this
as
a
community
from
from
the
get-go,
we
found
found
that
people
are
doing
these
one-off
Solutions
and
some
of
them
work
for
them
and
some
of
them
not,
but
this
is
open
source.
A
We
need
to
invest,
invest
in
this
together
and
make
sure
that
we
are
trying
the
same
things
and
we
have
we
built
the
same
trust
mechanism
instead
of
instead
of
instead
of
Bank
a
trying
to
invent
their
own
and
and
the
company
B,
trying
to
invent
their
own
right
and
time
to
act
is
now
the
supply
chain
is
the
supply
chain.
Software
for
software
is
under
attack.
We
need
to
do
it
now,
and
this
is
also
an
opportunity
to
sort
of
wish
Happy
Diwali
to
all
of
you.
A
We
are
celebrating
Diwali
this
week
and
today
happens
to
be
the
day
when
actually
businessmen
in
India.
They
they
open
new
books.
They
start
new
projects.
So
if
you're
waiting
for
the
right
timing
today
is
the
is
a
very
good
day
very
auspicious
day
to
start
contributing
to
any
of
these
projects.
Thank
you
good
question.
Actually,
yes,
x-ray
is
very
good
at
going
through
your
registry
or
repositories
and
identifying
what
vulnerability
vulnerabilities
exist.
A
A
We
can't
just
have
companies
who
have
purchased
x-ray
doing
that
for
their
open
source
and
doing
that
you
know
individually
and
trying
one-off
Solutions.
What
we
are
saying
is
we
need
something
that
we
all
can
trust
and
we
can
all
can
trust
in
the
same
way
right
so
Percy
app
provides
that
because
then
you,
you
are
looking
at
the
same
Province
log
that
I
am
looking
at
and
we
are
making
the
same
decisions
if,
because
the
provenance
log
is
also
telling
me
that
my
log
4J
has
availability
and
the
new
version
doesn't
have
that
vulnerability.
A
A
Correct
yeah,
so
it
we
will
be
able
to
like
what,
if
effective
palm
and
what
what
we
are.
What
we
just
released
is
the
first
level
and
then
we
are,
you
will
see
the
nested
structures
come
come
out
of
that
as
well.
So
you
can
ask
the
questions
about
of
that.
Nested
structure
am
I
using
openssl.
We
can't
answer.
Ask
that
question
today,
but
you
could
you
could
ask
that
question
to
Persia
and
you
will
know
any
other
questions.
Hi.
A
Yeah-
and
so
the
question
is,
are
we
thinking
about
you
know,
configurations
and
and
artifacts
that
are
not
traditional
binaries
right,
so
at
jfrog
we
use
the
term
binaries
to
to
to
cover
all
all
any
any
type
of
software
that
goes
into
production.
So
we
consider
the
configuration
file
as
as
an
equivalent
of
binary
that
needs
to
be
stamped
that
needs
to
be
verified.
There
needs
to
be
run
on
multiple
machines
to
make
sure
that
it
produces
the
same
result
as
well.
A
A
Rather
than
waiting
until
it's
already
been
published,
I
think
I
think
the
question
is
most
of
this
should
be
caught
when
when
we
are
trying
to
build
instead
of
trying
to
publish
and
I
agree
completely
agree
with
with
you.
Most
of
this
should
be
caught
when
we
start
start
to
ingest
it,
but
we
don't
have
tools
that
allow
it
allow
that
deep
and
Analysis
and
what
we
are
saying
here
right,
right,
yeah
and
there
are
cannot
exactly
and
that's
that's
the
problem.