►
From YouTube: Operation SLSA: Episode 2
Description
Episode 2 - The SLSA team discusses software supply chain security and the various attacks that can be unleashed and what open source tools you can use to mitigate them.
These supply chains aren't going to secure themselves.
To find out more about the OpenSSF - https://openssf.org
Music License MB01SKRLANUVOEN
A
A
Okay,
everyone,
here's
what
I
found
so
one
of
the
easiest
ways
to
insert
malware
into
your
code
is
to
submit
bad
code
to
your
repository.
You
can
think
of
this
like
trying
to
submit
a
forged
piece
of
art
into
an
auction.
So
obviously
the
forger
wants
to
pass
off
their
art
as
the
real
thing,
so
in
the
real
world.
How
would
we
prevent
this
from
happening?
A
We
might
get
an
expert
to
come
and
check
the
piece
of
art
to
make
sure
it's
authentic
before
we
allow
it
into
the
auction
even
better
than
having
one
expert
check
it
out
would
be
to
have
two
experts
check
it
out.
We
might
also
ask
for
Providence
for
the
piece
of
artwork
itself
make
sure
that
the
owner
who
owns
the
artwork
is
legit
and
that
we
can
trace
it
back
all
the
way
to
the
painter
themselves.
A
We
can
apply
the
same
concept
to
our
code.
If
we
want
to
stop
bad
code
from
entering
our
repository,
we
can
similarly
request
one
or
two
experts
to
look
at
the
code
itself
before
it
is
allowed
into
the
repository.
If
we
already
have
bad
code
in
our
repository,
we
need
some
way
of
auditing
it
to
find
it
in
the
future.
If
something
bad
happens,
this
is
where
higher
salsa
levels
come
into
play.
A
Higher
salsa
levels
recommend
storing
all
of
your
code
in
a
version
control
system
like
git
or
Mercurial,
so
you
can
keep
track
of
every
change
that
is
made
in
your
code
base.
Each
change
should
be
verifiable
so
that
you
can
see
who
made
the
change
who
approved
it
and
how
it
was
merged
into
the
code
base.
A
B
I,
don't
care
how
many
experts
you
have
verifying
your
art.
If
you
leave
your
Warehouse
unlocked,
anyone
can
go
in
and
change
whatever
they
want.
This
is
true
for
software
supply
chain.
You
have
to
lock
down
your
Source
control
repositories,
so
no
one
can
get
in
and
mess
around
with
it.
You
can't
have
your
source
code
repository
running
on
someone's
computer
sitting
under
their
desk.
Once
your
source
code
repository
is
compromised,
it
doesn't
matter
how
many
checks
you
have
in
place.
C
We
need
to
talk
about
dependencies.
These
are
added
all
throughout
the
software
supply
chain.
They
can
be
added
and
removed
without
any
sort
of
notice
whatsoever.
It's
like
when
I
was
at
lunch.
The
other
day
it
was
a
dead
flower
on
the
table.
Presumably
nothing
changed
to
the
restaurant,
but
something
changed.
Their
wholesaler
changed
their
suppliers
down
the
line
changed
they
didn't
catch
it.
C
At
the
end
of
the
day
they
had
a
dead
flower,
but
we
have
is
an
opportunity
for
any
sort
of
attack
to
occur
by
a
malicious
package
getting
substituted
throughout
the
supply
chain.
Someone
could
come
in
take
over
an
open
source
project.
They
could
go
ahead
and
compromise
the
package.
Someone
could
make
an
obscure
code
change
to
a
package
that
depends
on
another
package
that
depends
on
another
package
and
it
won't
get
detected.
C
The
only
real
mitigation
we
have
is
to
be
very
diligent
in
logging,
every
one
of
those
packages
and
what
we're
using
by
us
recording
exactly
what's
used
and
where
it's
used.
We
can
start
to
look
for
changes.
We
can
look
for
anomalies
as
they
occur.
If
something
is
known
to
be
a
bad
package,
we
can
do
an
audit
to
determine
what
is
actually
compromised
in
our
software
supply
chain.
C
So
it's
not
surprising
that
as
we
keep
depending
on
more
and
more
and
more
packages,
this
becomes
more
and
more
important
in
the
salsa
framework
is
a
complicated
problem
and
it's
a
higher
level
that
we
need
to
achieve.
But
it's
something
that
we
should
always
strive
to
be
doing
so
that
we
mitigate
any
potential
attack.
D
So,
building
on
what
agent
Verde
was
telling
us
malicious
dependencies
are
what
keep
Security
Experts
up
at
night.
So
when
I
was
in
the
restaurant,
I
ordered
a
salad
and
my
salad
came
out
and
I
was
going
to
eat
it.
I
looked
away
for
one
second
and
another
dish
appeared,
it
looked
delicious.
It
was
a
hamburger
and
cake.
D
So
this
is
similar
to
a
software
supply
chain
attack
that
actually
can
happen
after
the
build
system
builds
a
package,
so
an
artifact
can
be
ingested,
bypassing
a
CI
CD
system
and
slipped
into
the
supply
chain,
resulting
in
an
unwanted
piece
of
code
that
people
are
using
and
can
lead
to
a
breach.
So
one
way
that
we
can
defend
against
an
attack
like
this
is
using
a
framework
like
salsa,
which
has
a
strong
tie
into
the
Providence
or
the
metadata
that's
created
when
you
build
an
artifact.
D
So
when
we
look
at
this
provenance
data,
we
can
verify
it.
We
can.
We
can
set
policies
around
the
build
system.
We
can
ensure
that
we
are
only
accepting
artifacts
and
software
packages
that
are
built
by
particular
build
systems.
And
if
we
see,
if
there's
an
unwanted
package
in
there,
we'll
be
able
to
verify
that
this
package
shouldn't
be
in
our
supply
chain
and
we
will
know
not
to
put
it
in
our
production
systems.
E
Look
agent
Pico,
that's
all
fine,
but
people
are
putting
blind
trust
in
their
package
managers.
What
we
need
is
to
have
transparent
audit
Trails
of
where
those
artifacts
are
being
built
so
that
people
are
delivered
what
they
intend.
When
I
got
to
the
art
gallery,
I
saw
fake
art
pieces
held
up
with
real
labels
that
just
didn't
line
up
with
what
people
were
seeing
and
what
we
need
is
to
apply
this
to
software
salsa
can
help
us
get
there.