►
From YouTube: The thing about the software supply chain
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
So
what
are
we
going
to
talk
about
today?
So
an
intro
of
me
and
algon
is
done
and
just
a
few
words
about
the
software
supply
chain,
what
it
is
and
how
it
comes
into
play.
We're
going
to
speak
about
a
few
of
the
recent
attacks
and
we'll
dive
into
two
of
them,
specifically
after
that
we're
going
to
have
a
live
demo
of
an
attack
and
how
it
looks
like
in
the
wild
and
we'll
see
how
album
comes
into
play
and
all
of
that
and
that's
it
for
today.
A
The
software
supply
chain
is
actually
a
term
that
is
borrowed
from
the
physical
world
where
it
is
used
to
describe
the
path
or
the
route
physical
products
or
services
take
from
the
moment
they
are
composed
in
the
factory
from
all
those
different
ingredients
throughout
the
entire
chain
of
supply.
Up
until
the
time
they
are
delivered
to
my
doorstep.
A
So
the
software
world
concept,
the
concepts-
are
pretty
similar,
as
we
can
see
here,
the
five
different
phases
of
the
software
supply
chain,
so
starting
from
the
code
itself
and
the
source
code
management
platforms
that
manage
it
throughout
the
materials
which
is
another
way
of
saying
dependencies,
so
open
source
dependencies
and
ci
pipeline
dependencies.
We'll
see
how
those
look
like
later
on,
then
we
have
the
build
phase.
A
Ci
pipelines,
taking
raw
lines
of
source
code
are
compiling
them
and,
finally
achieving
a
final
form
of
artifact.
Those
need
to
be
managed
as
well.
So
we
have
all
those
different
package
registries
for
artifact
management
and
the
final
phase
is
the
deployment
phase
where
you
take
the
final
docker
image
or
npm
package
and
deploy
it
to
the
relevant
environment.
A
Let's
say
your
kubernetes
cluster
in
the
production
here
we
have
a
relatively
simple
example,
I
guess
of
this
type
of
chain.
We
can
see
that
the
technological
change
that
was
introduced
here
in
the
just
recent
years
is
very
dramatic,
so
we
didn't
used
to
look
anything
like
that.
Just
a
couple
of
years
ago,
companies
would
release
software
completely
different.
You
would
have
this
quarterly
release
night.
Everything
would
go
according
to
some
project
plan,
a
lot
of
human
intervention
in
the
process.
A
Today
this
is
not
the
case,
so
software
companies
have
released
software
tens
of
times
a
day
with
full
automation
without
any
human
intervention,
and
the
technological
chain
was
very
quick
to
to
come
into
play
here.
We
can
see
some
of
the
major
recent
events
just
in
the
last
few
years
to
understand
how
quickly
this
has
come.
So
we
can
see
that
in
2015
lab
was
just
a
10
employees.
A
Companies,
after
that,
in
2016
google
cloud
build
was
only
released
in
beta
today
is
one
of
the
more
popular
build
platform
outdoors
bitbucket
pipeline
replaces
bamboo
just
in
late
2017
and
azure
devops
cloud.
What
was
introduced
in
2018
granted
microsoft
did
have
tfs
platforms,
but
some
would
argue
that
is.
It
is
different,
github
action,
I
guess
it.
This
is
the
more
interesting
part.
So
gita
veteran
is
the
third
most
ci
use.
A
Today
it
was
only
released
in
general
availability
in
2019,
so
just
child
two
years
ago
and
github
container
registry
is
production
and
production
ready
just
last
year.
So
we
can
see
how
a
lot
of
the
services
a
lot
of
the
products
of
a
lot
of
the
companies
that
we
use
today
and
we
almost
take
for
granted,
was
just
were
just
introduced
in
the
last
couple
of
years.
A
So
argon
conducted
the
survey
to
ask
companies
to
ask
security
leaders
how
this
change
has
affected
them.
We
can
see
the
results
here,
but
we
don't
have
to
look
at
all
the
numbers
now.
This
is
just
for
show
I'll.
Tell
you
about
three
main
data
points
that
I
find
to
be
interesting,
so
the
first
one
which
is
kind
of
obvious,
I
guess
over
90
of
companies
today
use
full
cicd
automation
to
deploy
software
to
production.
A
I
guess
today.
This
is
not
a
big
surprise.
However.
Only
23
percent
of
those
same
companies
feel
that
they
have
confidence
in
those
processes,
meaning
the
rest
feel
they
don't
really
know
what
goes
on
there.
They
don't
have
the
proper
control
over
it
and
when
we
asked
those
security
leaders,
those
csos
and
application
security
team,
we
asked
them.
A
What
was
the
number
one
challenge
in
securing
the
software
supply
chain
today
and
the
number
one
result
that
we
got
was
collaboration
between
devops
and
security
teams,
which
I
find
to
be
extremely
interesting,
because
it
has
nothing
to
do
with
technology
and
automation
and
everything
to
do
with
people
and
processes.
A
So,
let's
see
some
of
the
recent
events
that
took
place
involving
that
software
supply
chain,
so
these
are
just
some
of
the
high
profile
attacks.
I
won't
go
into
each
and
every
one
of
them
we'll
just
do
a
quick
overview,
so
mercedes
had
a
major
source
called
leakage
through
through
their
gitlab
on-prem
server.
Roughly
600
code
repositories
were
leaked
online,
including
very
sensitive
code
projects.
A
Later
on,
codecov
an
automation
company
was
breached
and
attacker
was
able
to
modify
the
software
basically
affecting
all
of
codecov's
customers
running
that
same
software.
In
the
ci
environment
and
cause
the
leakage
of
sensitive
data
directly
from
those
environments,
the
third
one
here
that
we
see
is
the
one
known
as
dependency
confusion.
A
So
a
white
hat
hacker
demonstrated
how
easy
it
is
to
trick
those
package
registries,
those
artifact
manager
into
pulling
their
own
packages
from
the
outside
world
instead
of
private
one
developed
in-house
and
the
final
and
fourth
one
probably
doesn't
need
a
lot
of
explanation.
A
Solo
wind
was
a
major
build
time
code,
manipulation
attack,
basically
unticker
gained
access
to
the
building
environment
of
the
orion
app
and
was
able
to
modify
its
source
code
affecting
thousands
of
users
of
it,
and
just
last
week
we
had
another
major
incident
involving
this
action:
the
check
spelling
action.
Basically,
we
can
see
here
a
screenshot
of
the
security
advisory
explaining
that
workflows
using
it
were
vulnerable
to
leakage
of
the
github
token
and
we'll
see
a
live
demo
of
how
this
looks
like
in
the
real
world.
A
Just
yesterday,
less
than
24
hours
ago
travis,
I
published
this
notice,
noting
that
all
public
repositories
using
travis
as
their
ci,
were
in
danger
of
leaking
secrets
directly
from
those
repositories.
A
We
can
see
that
the
issue
is
valid
only
for
pub
public
repositories,
which
which
I
guess
should
be
kind
of
reassuring
in
a
way,
and
this
happened
less
than
24
hours
ago.
A
So,
let's
see
how
one
of
those
attacks
looks
like
when
we
dive
a
little
deeper
so
taking
the
check
spelling
incident,
for
example,
we
can
see
here
the
lines
of
installation,
it's
pretty
amazing,
to
consider
the
level
of
trust
that
we
put
in
them.
We
can
see
here
how
a
workflow
could
add
the
check,
spelling
action
directly
onto
the
gita
repository
using
it,
and
we
can
see
how
the
app
store
4
action
looks
like
it's
no
longer
just
your
application
today
that
contains
dependencies,
but
rather
your
workflows,
your
ci
pipelines.
A
So
this
means,
when
you
release
software,
someone
else's
code
running
as
part
of
this
same
process
is
taking
place,
has
access
to
your
repository
to
its
secrets
and
to
the
code
itself.
Now.
This
is
not
a
dependency
of
your
application.
This
is
not
listed
in
your
manifest
file
in
your
package.json
file.
This
is
other
people
code
running
as
part
of
your
ci
process.
So
what
happened
with
check?
A
Spamming,
so
we
can
see
here
that
it's
a
github
action
used
by
a
lot
of
repositories
to
well
check
the
spelling
of
each
pull
request
submitted
against
them.
Now
its
workflow
was
say
very
improperly
configured.
We
can
see
a
switch
from
the
official
page
about
the
recommendation
of
how
to
set
it
up
and
essentially
each
repository
using
it
allowed
an
attacker
to
gain
write
access
to
them.
Just
by
submitting
a
carefully
crafted
pull
request.
A
So
this
is
a
schedule
from
the
advisory
from
the
security
advisory
that
was
published.
We
can
see
four
repositories
using
the
check,
spelling
action,
which
enabled
the
trigger
on
police
target
and
attacker
was
able
to
send
the
pull
request
and
cause
the
github
access
token
to
be
leaked.
A
With
that
token,
you
can
do
a
bunch
of
stuff,
including
read,
including
write
to
the
target
repository,
so
this
is
kind
of
what
the
workflow
using
spell
checking
action
would
look
like
you
can
see
here
that
the
event
is
on
police
target
and
when
you
put
that
together,
we
check
out
all
the
specific
pull
request.
A
This
is
when
things
become
a
little
messy
and
for
those
of
you
who
haven't
used
github
action
before
don't
worry,
we're
going
to
show
live
how
this
workflow
can
allow
an
attacker
to
gain
access
to
your
repository.
A
So
a
couple
of
workarounds
that
were
suggested
suggested
well,
the
first
one
would
be
to
simply
disable
the
workflow,
which
I
guess
is
not
that
much
of
a
fix,
but
rather
kind
of
a
first
aid
kit.
The
other
would
be
to
kind
of
change
the
way
that
you
allow
specific
actions
to
run.
A
You
can
allow
only
actions
created
by
github
or
only
actions
verified
by
github,
for
example,
and
I'll
show
you
how
this
looks
like
in
just
a
few
slides
plus,
you
can
change
the
github
token
level
of
access
its
scope
by
default.
It
is
granted
something
else
rather
than
simply
read,
so
these
are
kind
of
just
the
quick
fixes.
So
I
created
a
completely
new
github
repository
and
added
just
an
example
workflow
to
see
how
those
configuration
are
configured
by
default.
A
So
we
can
see
here
that
the
workflow
permission
is
granted
read
and
write
access
to
my
repository.
These
permissions
are
reflected
in
the
github
token
itself,
so
an
attacker
gaining
access
to
this
github
token
actually
has
read
and
write
permissions
by
default
to
my
depository
containing
this
workflow.
A
Another
security
configuration
here
that
I've
also
checked
is
the
default
action
permission.
So
basically,
if
you're
managing
a
github
organization,
you
can
control
the
different
level
of
which
actions
you're
allowed
to
run
the
default,
as
we
can
see
here,
is
allow
all
this
means.
I
can
run
anybody
else's
code,
which
is
wrapped
in
a
github
action
and
granted
access
to
my
repository
to
my
source
code
as
part
of
my
workflow.
A
Now,
the
solution
itself
is
a
little
trickier
because
you
would
have
to
not
only
fix
the
main
branch
of
your
repository
and
update
it
to
the
latest
version
of
check
spelling,
but
rather
you
would
have
to
fix
each
and
every
branch
containing
a
copy
of
this
workflow,
because
the
way
this
works
is
each
branch
has
its
own
workflow
file
and
if
it
is
still
using
the
affected
version,
then
any
pull
request
submitted
against
this
branch
could
also
trigger
this
check,
spelling
action
with
the
vulnerable
version
allowing
the
leakage
of
the
github
token.
A
A
This
is
the
okato
app
readme
file,
plus
I've
added
a
very
standard,
node
starter
workflow,
which
I've
copied
directly
from
the
example
at
so
we
can
see
that
it
really
doesn't
do
much
just
a
standard
workflow
for
ci,
plus
I've
altered
the
event,
we're
listening
to
to
be
the
purpose
target
event
together
with
checking
out
of
the
pull
request
itself.
A
A
So
another
github
profile,
which
I
have
my
alter
ego-
we
can
see
it
here
which
doesn't
have
any
access
to
the
locator
organization
or
the
okto
app
it
can
find
it,
but
just
because
this
is
a
publicly
double
positor
and
in
order
to
make
changes,
the
other
user
would
have
to
fork
this
repository
and
suggest
modification
using
a
blueprint.
So
this
is
what
we're
going
to
do
now,
I'm
going
to
focus
ok
to
upload
pository
I'll,
give
it
a
few
seconds
here.
We
can
see
that
now,
I'm
working
on
this
four
chord.
A
So
while
I'm
doing
that,
I
can
suggest
modification
to
the
source
code.
Specifically
I'm
going
to
suggest
modification
to
the
packet
json
file.
Now
I'm
going
to
use
this
script
stack
in
order
to
run
my
arbitrary
code.
Now
there
are
all
these
different
sorts
of
ways
to
run.
Orbital
record
specifically
running
npm
test
would
be
something
a
lot
of
ci
platforms
would
do
so
I'm
going
to
use
this
one.
We
can
see
here
the
file
with
the
instructions
of
my
alberta
record
and
what
it
is
going
to
do.
A
It's
divided
into
three
phases,
so
the
first
one
would
be
to
obtain
the
github
token.
Now
this
is
accessible
because
my
code
would
run
in
the
context
of
the
gitlab
github
runner
and
it
does
have
right
access
which
is
enabled
by
default.
So
I'm
going
to
extract
this
github
token
using
git
config
just
to
see
where
it
is
stored.
A
Once
I
have
this
token,
I
can
make
a
request
to
github
to
modify
the
source
code
of
the
vocato
app.
I
would
obviously
have
to
use
this
token,
and
I
will
also
send
this
token
back,
so
we
can
see
it
together,
so
I'm
taking
all
those
lines
and
I've
compiled
them
into
one
long
line
just
to
be
placed
in
the
skip
tab.
So
we
can
copy
paste
this
one
here
and
we'll
suggest
modification.
A
A
However,
now
that
I
have
some
modification,
I
can
offer
them
in
the
form
of
a
pull
request,
so
I'll
open
up
a
pull
request,
targeting
the
okato
app
great
once
I'll.
Do
that.
A
And
the
redmi
file
will
give
it
a
few
seconds
for
the
workflow
to
be
done.
Maybe
we'll
see
what
it
does
in
the
meantime.
So
it's
running
npm
test
as
part
of
my
workflow.
Now
this
would
run
my
arbitrary
code
we'll
see
in
a
second
the
results
of
it.
So
if
I
go
here,
this
is
the
okay
to
app.
I
guess,
if
I
refresh
the
page,
this
no
longer
would
be
the
case.
So
you
can
see.
I
am
in
now
this
modification
to
one
of
the
file
the
redmi
file.
A
So
we
can
see
the
workflow
itself
has
run
this
cleverly
put
arbitrary
code
with
the
changes
and
also
sent
back
the
access
token.
For
me
to
see
so
we
can
see
here,
the
access
token
was
sent.
I
have
this
security
listening
for
any
secrets
being
sent
from
the
github
flow.
We
can
see
this
github
token
here.
A
Okay,
now,
what
are
we
going
to
do
about
this
workflow?
So
the
obvious
thing
would
be
to
change
the
event
right
so
that
now
we
will
no
longer
listen
to
the
request
target
event,
so
we
can
do
that
and
just
listen
to
pulus
different
plus
we'll
remove
this
line
because
it
doesn't
really.
A
Great
so
now
this
workflow
would
only
be
triggered
by
polarquest
event,
so
we
can
go
back
here
to
the
action
tab
and
we'll
try
the
same
thing
again.
So
I'll
go
to
my
folk
that
is
located
here.
A
And
we
should
see
the
workflow
running
here,
so
you
can
see
that
it
was
triggered
and
we
immediately
see
different
dessert,
so
the
buffalo
was
triggered,
but
it
didn't
run.
It
is
waiting
for
over.
So
firstly,
this
is
obviously
much
better
results
than
the
previous
coding
injection.
A
Great
and
let's
see
how
this
looks
like
we'll,
give
it
a
few
seconds
to
set
up,
so
it's
still
processing
my
pull
request.
However,
it
is
doing
it
in
a
different
context
on
the
event
of
the
pull
request
instead
of
the
police
target,
so
we
can
see
that
the
npm
test
has
run
successfully,
so
my
injected
code
is
still
running
as
part
of
this
workflow.
However,
now
I'm
getting
this
error
message
saying
resource
not
accessible
by
integration.
A
Now
this
is
github
letting
me
know
that
the
access
token
I've
used
here
to
try
and
alter
the
readme
file
of
the
okato
app
again
doesn't
really
allow
me
to
do
that
now.
This
access
token
only
have
read
access
it.
Does
it
isn't
able
to
change
the
file
in
the
target
repository
and
what
about
the
other
code,
the
one
where
I
send
the
token
back
home?
A
So
we
can
see
that
the
third
one
another
one
was
added
here,
so
my
secret
either
did
get
to
eat
another
secret,
and
this
is
the
github
token
generated
by
this
workflow
runner.
A
A
And
this
is
this
step,
so
the
checkout
step
now
the
checkout
step
has
another
kind
of
property
by
default.
That
is
enabled
which
we
need
to
pay
attention
to.
It
is
called
persist,
credentials
so
with
suggest
modification
here,
using
the
width
command
and
persist,
and
then
it
shows
set
to
false,
which
is
not
the
default.
A
Great
and
keep
in
mind
here,
we
are
waiting
for
the
secret
to
be
populated,
so
we
can
see
the
warfare
started
to
run.
It
will
run
my
arbitrary
code
and
it
would
fail
now
just
a
second,
so
we'll
take
a
look
at
this
failure.
So
the
reason
for
the
error
message
here
is
because
the
github
access
token
was
not
available
to
it,
and
we
can
see
that
here
we
didn't
get
any
new
lines,
so
the
secret
detail
that
is
listening
for
github
tokens
did
not
manage
to
get
it.
A
So
I
hope
this
clarifies
the
change
of
the
different
events
of
the
workflow
and
the
nuance
of
using
persist
credential
false
together
with
the
checkout
action,
because
otherwise
the
default
would
be
true,
meaning
that
the
rest
of
the
workflow
would
have
full
access
to
the
git
token
and
is
able
to
send
it
out
to
whichever
location
that
it
wants.
A
Great
so
going
back
to
the
listen,
the
text.
A
Another
thing
that
is
also
around
the
issue
of
workflows
is
code
code.
We
touched
on
that
in
the
overview
and
we
can
see
the
lines
that
are
required
to
be
targeted
by
this
attack
here.
So,
if
you're
using
the
codecov
action,
if
you
were
using
it,
you
were
potentially
leaked.
You
have
potentially
leaked
sensitive
information
directly
from
your
ci
environment.
A
We
can
see
that
kodkov
is
an
extremely
popular
test
coverage
tool.
You
use
it
as
part
of
lci,
either
with
a
dedicated
gita
version
or
simply
by
placing
the
curl
command
to
download
it,
and
it
was
hacked
pretty
bad.
So
when
attacker
was
able
to
modify
one
of
the
automation
skip
basically
affecting
all
of
quadcop's
customers
using
it
at
the
time.
A
Okay,
so
to
be
a
little
more
specific,
we
don't
really
know
how
code
cover
was
hacked.
However,
it
was
noted
noted
that
its
google
cloud
access
key
was
linked
to
one
of
the
docker
images
which
it
turns
out
is
an
extremely
easy
thing
to
do
when
constructing
a
docker
image
engineers
can
leave
sensitive
data
behind.
We
can
see
here
an
example
of
a
docker
history
command,
which
can
also
be
very
conveiling
by
itself.
A
Now
the
bash
uploader,
the
util
that
was
hacked
is
a
small
util,
looks
kind
of
like
this,
and
it
is
responsible
for
uploading.
The
test
coverage
results
back
to
the
codecov
platform
and
then
all
the
attacker
did
once
he
was
able
to
modify
the
file
was
at
this
one
new
line,
it's
a
pretty
simple
line.
Most
of
you
probably
understand
what
it
does
just
by
looking
at
it.
It
prints
out
the
environment
variables
that
are
accessible.
A
So
in
this
sense,
this
is
something
running
in
my
ci
environment
and
sends
them
out
to
a
remote
server.
So
we
can
expect
to
find
data
like
access,
token
user
connections
and
api
keys.
Now
the
results
of
this
hack
were
pretty
massive.
So
a
lot
of
high
high
name
profile
companies
did
publicly
notify
they
were
affected,
but
not
only
private
companies
for
a
lot
of
open
source
projects
using
it
as
part
of
the
ci.
A
A
So,
let's
see
how
this
looks
like
so
we'll
jump
back
to
this
workflow
this
time.
We
can
look
at
this
one
here,
so
this
is
another
workflow,
just
a
pretty
standard
one
again
with
the
produce
target
line.
However,
I've
added
this
extra
step
that
I
actually
copied
from
the
official
website
of
the
official
instructions
of
how
to
upload
my
test
coverage
result.
So
you
can
see
that
I'm
running
the
curl
command
to
download
this
automation
skip
as
part
of
my
release
process.
A
Now.
This
is
something
a
lot
of
companies
today
have
lurking
as
part
of
the
ci
pipeline,
we're
talking
about
tens
of
pipelines,
hundreds
of
pipelines
and
it's
extremely
hard
to
keep
track
of
anything.
That
runs
as
part
of
that.
So
one
of
the
tools
that
argon
has
built
to
help
mitigate
these
types
of
risks
is
this
argon
cli
and
it
accepts
ci
workflows.
A
It
goes
over
them
deconstructs
the
instruction
it
doesn't
matter
if
they
are
written
as
a
gita,
workflow
azure
pipeline
a
bit
bucket
pipeline
or
even
gitlab
ci
anything
you
use,
you
can
deconstruct
and
apply
custom
logic
on
it.
So
it
helps
you
avoid
these
security
issues,
those
misconfigurations,
those
untrusted
user
inputs.
A
We
can
run
it
here,
okay,
so
we
can
see
here.
This
is
how
it
looks
like
this
is
util.
You
can
see
that
it's
scanned
one
workflow
file.
This
is
the
one
to
the
left
and
it
has
all
those
insights
on
it,
so
starting
from
unpinned
actions
which
allows
kind
of
flexibility
into
which
code
you're
running
how
to
suspicious
use
of
environment
variables
and
even
the
poluques
target
event
which
we
referenced
earlier.
So
we
can
see
here
that
it
lets
me
know
that
the
pull
request,
elevated
access
could
be
granted.
A
We
need
to
take
a
look
at
this
specific
line
here
in
my
workflow
when
combined
with
the
checkout
action.
This
is
definitely
something
that
we
saw
could
put
me
in
risks.
Another
thing
we
can
see
here
is
that
finishes
stored
in
disks.
So
this
means
I'm
not
setting
the
persist.
Connections
flag
to
false,
so
github
token
is
kept
on
the
disk
and
is
available
for
any
secret
data
out
there
to
consume
them
now.
A
The
relevant
line
here
is
codecov,
so
you
can
see
here
that
the
argon
pipeline
scanner
has
actually
very
noticed
that
there
is
an
unverified
external
dependency.
So
someone
else's
code
running
in
my
ci,
actively
running
on
every
release,
and
it
lets
me
know
which
line
it
has
been
detected.
So
we
can
see
one
file
scan
with
seven
finding
one
is
critical,
the
other
on
medium,
and
it
also
allows
me
to
take
action
on
it.
So
not
only
find
the
relevant
security
issues,
but
also
kind
of
to
take
action.
A
We
can
see
here
sorry
a
pull
request
so
when,
when
the
workflow
contains
an
unverified
step,
avon
helps
you
kind
of
add
verification
layer
on
that,
so
it
is
added
as
a
pinned
kit
of
action
which
helps
you
kind
of
use
check
some
level.
Verification
that
anything
that
is
running
as
part
of
uci
is
in
fact
should
in
fact
run
them.
The
same
goes
for
any
of
those
gotchas.
A
Those
small
kind
of
very
dangerous
misconfigurations
that
could
be
easily
avoided,
so
we
can
do
it
kind
of
in
an
automatic
flow,
and
let's
go
back
here.
A
Great,
so
now
that
we
saw
some
of
how
of
those
scenarios
looks
like
in
the
wild,
so
an
important
thing
to
realize
about
the
software
supply
chain
is
that
we
often
think
of
it
as
just
one
long
unified
process.
However,
it
is
composed
of
five
different
layer
of
phases,
so
the
first
one
would
be
to
secure
the
source
code
throughout
the
dependencies,
the
pipelines
themselves,
building
it
the
artifacts
that
are
being
managed
and
up
until
time
of
deployment
and
in
order
to
fully
protect
this
chain.
A
We
need
to
secure
each
and
every
link
in
it,
and
if
we
fail
to
do
so,
then
we
get
incidents
like
kodkov,
which
was
a
fairly
insecure
in
one
of
the
dependencies
or
solarwind,
which
we
already
talked
about
earlier:
a
failure
to
secure
the
building
environment
or
the
dependency
confusion
which
could
have
been
avoided
with
portal
control
over
the
package
registries,
the
artifact
servers
themselves
and
the
list
goes
on
so
cncf
on
github
can
easily
show
you
a
list
of
the
software
supply
chain
incidents
that
took
place
recently.
A
So
a
little
bit
about
the
solution:
what
to
do
about
security
of
the
software
supply
chain,
so
I'm
gonna
created
this
framework.
It
is
it
correlates
very
well
to
the
five
different
phases
and
it
offers
128
the
set
of
controls
that
are
required
to
be
put
in
place
in
order
to
fully
secure
the
software
supply
chain.
So
we
can
see
some
of
them
here
and
if,
and
only
if
those
controls
are
in
place,
then
we
can
hope
to
avoid
incidents
like
the
one
that
we
mentioned.
A
We
can
see
how
each
one
of
them
targeted
a
different
phase
of
the
supply
chain
and
how
the
solution,
how
those
control
gates
could
help
medicate
them
now.
Obviously,
what
we
just
saw
with
the
algorithm
and
the
pipeline
scanner
is
only
a
small
portion
of
the
solution
in
order
to
fully
protect
the
supply
chain.
We
need
a
unified
security
solution,
so
protecting
each
phase
of
the
process
kind
of
helps.
A
You
create
a
governance
layer
on
top
of
it
and
obviously
prevent
any
in
any
affected
versions
of
your
opponent
from
being
released
to
production.
A
So
I'm
going
to
end
with
one
of
the
more
interesting
quotes
that
I
just
recently
saw
from
github
security
lab
any
modern,
build
orchestration
is
complex
enough
to
have
multiple
code
injection
points,
so
I
think
this
kind
of
reflects
well.
The
fact
that
the
technology
has
changed
build
occasion
is
now
so
complex
that
even
github
themselves.
Let
you
know
that
multiple
code
injection
points
can
definitely
be
found
there,
so
that's
it
for
today.