►
From YouTube: Know Your Dependencies: A Guide to Automating Dependency Assurance - Steve Judd, Jetstack
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Know Your Dependencies: A Guide to Automating Dependency Assurance - Steve Judd, Jetstack
It is a truth universally acknowledged that almost every modern software component contains a selection of external dependencies whose provenance is unknown. Another truth is that no dependency should be trusted until proven trustworthy. This second truth, though, is often ignored by organisations and their engineering teams, who argue that assuring the trustworthiness of dependencies is too complex, too time-consuming and has a detrimental impact on development velocity. This talk will describe how Jetstack has worked with several clients in the financial services and defence sectors to help them develop dependency assurance mechanisms and processes that allow greater visibility and insight into the dependencies used and their impact on the clients’ risk and security postures. The audience will learn how modern tooling and practices can be used to create efficient, automated pipelines that audit dependencies for vulnerabilities and licence obligations, assess them against the organisation’s security policies and ultimately provide the ability to control which dependencies can be used and deployed within the organisation.
A
Hi
everyone,
my
name,
is
Steve
Judd
working
for
jet
stack.
Hopefully
some
of
you
are
familiar
with
jet
stack
because
of
the
product
that
we
created
cert
manager,
but
jetstack
also
has
a
kubernetes
and
Cloud
native
consultancy
Division,
and
that's
where
I
work
and
over
the
last
couple
of
years,
I've
basically
been
helping
a
bunch
of
clients
in
the
financial
services
and
the
fence
sectors
improve
the
security
of
their
software
Supply
chains.
A
A
So,
first
of
all,
I
thought:
I'd
excite
everyone
with
a
few
cherry-picked
statistics
from
a
couple
of
vendor
reports,
so
one
of
them
is
from
a
report
from
synopsis
from
this
year.
Some
of
the
other
stats
are
from
a
report
from
sonotype
in
2020.,
so
I
think
you'll
all
agree.
Basically,
modern
applications
fundamentally
consist
of
a
lot
of
Open
Source
libraries,
whether
or
not
you
think
it's
as
much
as
90
percent
bit
moot.
A
Really
it's
just
a
great
deal,
and,
interestingly
and
perhaps
alarmingly,
a
large
majority
of
these
software
applications
are
using
out
of
date
versions
of
these
open
source,
libraries
that
they
are
dependent
on
and
therefore
perhaps,
unsurprisingly,
maybe
a
half
or
so
of
code
based
is
surveyed
have
at
least
one
high
risk.
Vulnerability
in
them,
and
also
interestingly,
I
think,
is
that
about
half
of
the
code
bases
that
were
surveyed
have
some
kind
of
Open
Source
license.
A
Conflict
and
I
think
this
is
a
particular
area
that
that
doesn't
get
a
huge
amount
of
attention.
But
I'll
talk
a
little
bit
more
about
that
later
on
so
now,
I've
kind
of
shown
you
how
I
can
expertly
cherry
pick
a
few
statistics
from
some
useful
reports.
Here's
a
couple
of
kind
of
personal
anecdotal
observations
made
because
I've
spent
the
last
10
years
or
so
not
just
as
a
consultant,
but
also
as
a
tech
team,
lead,
developer
team,
lead
head
of
platform
and
so
on
and
I.
A
Think
it's
fair
to
say
and
not
in
not
at
all.
Disrespectful
is
that
software
Engineers
really
don't
know
a
great
deal
about
the
dependencies
that
they're
using
within
their
software
applications
and
the
reason
I
say
that
is
there
are
a
lot
of
dependencies,
not
just
the
direct
dependencies,
but
also
the
indirect
transient
dependencies.
So
I
looked
at
jet
stack
cert
manager
products
a
few
weeks
ago,
and
it's
probably
got
in
the
region
of
1500
dependencies
of
which
only
about
30
those
are
direct
I.E.
The
developer
deliberately
chose
to
import
them
into
their
software.
A
It's
just
not
practical
to
be
able
to
understand
and
have
much
knowledge
about
such
a
vast
array
of
dependencies
in
in
your
typical
applications.
So
if
you
don't
know
very
much
about
your
dependencies,
how
are
you
able
to
trust
them
and
if
you
can't
trust
them-
and
you
don't
know
much
about
them,
how
can
you
gauge
the
level
of
risk
that
these
dependencies
are
going
to
apply
to
your
to
your
environments
and
your
companies?
A
Okay,
so
hopefully,
I've
persuaded
you
of
the
need
to
understand
the
dependencies.
The
docker
images
that
you
use
within
your
organizations
significantly
better
than
I,
think
most
organizations
do
currently,
but
the
next
part
of
this
talk
I'm
going
to
go
through,
perhaps
what
the
outcomes
and
the
benefits
that
you
should
be
looking
to
achieve
by
getting
to
know
your
dependencies
better.
A
Think
if
you
were
in
one
of
the
sessions
this
morning,
someone
was
speaking
about
the
open,
ssf
scorecard
product.
If
you
haven't
seen
this
I
would
encourage
you
to
have
a
look.
It's
a
it's
a
great
tool
that
will
give
you
a
series
of
scores
and
based
on
the
set
of
metrics
around
the
way
that
the
source,
the
GitHub
source
code,
the
hygiene
rules
and
so
on.
A
I
will
talk
a
little
bit
more
about
this
later
on
in
my
talk,
but
as
a
good
first
step,
looking
at
creating
a
trusted
registry
from
which
it
is
mandatory
to
pull
your
images
in
your
code
rather
than
going
direct
to
the
the
public,
internet.key.io
and
so
on,
as
I've
already
said,
I
think
open
source
license.
Compliance
is
kind
of
a
thing
as
in
there
are
a
lot
of
code
bases
that
don't
fulfill
all
of
their
obligations.
A
Now
this
fourth
one,
what
we've
kind
of
noticed
over
the
last
12
months,
especially,
is
that
companies
that
consume
software
from
external
software
suppliers
are
starting
to
get
quite
keen
on
understanding
the
list
of
dependencies
in
that
software.
That
they're
taking
and
a
good
way
of
providing
this
inventory
is
to
use
some
kind
of
s-bomb
in
jetstack.
We've
had
a
lot
of
success
using
the
Cyclone
DX
s-bomb
format.
Another
popular
choice
is
spdx.
A
It
would
be
really
useful
to
be
able
to
make
that
metadata
very
visible
via
dashboards,
to
make
it
easy
to
consume
for
interested
stakeholders
such
as
security
teams
and
Dev
teams,
and
later
on
in
this
talk,
I'll
offer
up
some
suggestions
about
how
that
can
be
achieved,
and
then,
finally,
this
isn't
particularly
a
benefit,
but
I
think
it's
kind
of
important
to
emphasize.
Is
that
all
of
this
kind
of
extra
due
diligence
activity
and
the
workflows
to
make
it
happen?
Really
you
want
to
avoid
having
much
impact
on
developer
velocity.
A
Okay,
so
I've
gone
through.
Why
I
think
it's
important
that
organizations
and
teams
get
to
sort
of
better
understand
and
know
their
dependencies,
and
also
what
kind
of
benefits
and
outcomes
you
can
expect
to
achieve
now,
I'm
going
to
go
through
ways
in
which
we've
helped
some
of
our
clients
actually
achieve
the
outcomes
that
I've
been
talking
about.
A
So,
first
of
all
and
I
think
this
is
kind
of
a
fundamental
Cornerstone
is
to
have
this
trusted
registry,
so
rather
than
allowing
developers
or
the
CI
pipelines
or
even
the
runtime
environments,
rather
than
allowing
them
to
pull
images
directly
off
of
the
internet
from
docker.hub
or
key.io.
You
only
allow
them
to
pull
from
your
trusted
registry.
We've
had
a
lot
of
success
with
artifactory
and
harbor,
but
obviously
there
are
other
Alternatives
out
there.
A
A
Once
you've
now
got
this
situation,
where
the
images
are
being
pushed
into
your
trusted
registry
before
being
pulled
by
the
various
components
like
developers,
CI
pipelines
and
so
on.
What
you
now
do
is
you
can
start
to
kick
off
Security
based
workflow
pipelines
that
can
start
to
evaluate
those
new
images.
As
they're
appear
in
this
trusted
registry,
this
particular
workflow
pipeline.
We
used
Argo
workflows
to
execute
it
for
a
particular
client
and
I'll
go
through
the
the
kind
of
steps
that
this
workflow
does.
A
A
Ci
pipelines
we've
injected
an
additional
step
that
generates
an
s-bomb
from
the
particular
software
applications
source
code
from
its
go
dot,
mod
file
or
its
requirements.txt
file,
and
when
we've
got
that
s-bomb,
we
then
include
that
within
the
image
that
gets
built
that
contains
the
compiled
binary
or
whatever,
and
the
reason
that
we
create
this
separate
s-bomb
is
because
you
can
get
far
greater
level
of
detail
about
the
dependencies
that
have
been
used
in
that
software
application.
Then,
if
you
just
using
just
use
an
s-bomb
based
on
the
docker
image.
A
We
then
use
a
tool
from
Sig
store,
called
cosine,
and
we
use
that
tool
to
sign
the
s-bomb
and
then
push
both
the
signature
and
the
s-bomb
as
oci
images
back
into
that
trusted
registry,
and
thanks
to
the
way
that
the
tagging
works,
these
new
oci
images
can
be
Associated
back
to
the
image
of
the
original
Docker
image.
That
was
that
was
triggered
this
workflow
in
the
first
place,
and
the
reason
that
this
is
incredibly
useful
is
that
then
makes
that
s-bomb
available
to
Consumers
of
that
Docker
image.
A
A
So
the
reason
that
we
use
dependency
track
is
that
it's
got
some
nice
features
allowing
us
to
get
it
to
automatically
run
a
vulnerability
analysis
against
the
inventory.
That's
just
come
from
the
s-bomb
and
also
a
license
evaluation
and
once
dependency
tracks
done
that,
then
it's
got
a
nice
web
UI
that
allows
you
to
view
all
the
vulnerabilities
in
this
image
that
you've
just
processed
and
what
kind
of
Licensing
is
there.
A
A
One
of
our
clients
is
also
using
another
feature
of
dependency
track,
which
is
it's
got
this
policy
engine,
so
you
can
Define
security
policies.
Things
like
these
are
the
permitted
or
forbidden
types
of
Open
Source
license
that
are
acceptable
in
our
organization,
or
we
have
a
policy
that
any
vulnerability
with
a
score
higher
than
seven.
That's
not
allowed
to
be
used
in
our
organization.
So
what
you
can
do
with
dependency
track
is
Define
these
policies.
A
This
particular
client
is
also
trialling.
Another
o
wasp
tool
called
defect
dojo,
and
this
helps
the
the
intention
is
that
this
will
help
them
manage
the
vulnerabilities
that
have
been
discovered
and
mitigate
those
vulnerabilities
in
in
that
have
been
discovered
in
the
images
that
have
been
processed.
A
A
So
the
first
one
and
I
don't
really
expect
you
to
sort
of
be
able
to
read
everything
on
that
screen.
What
I
did
here
was
create
a
grafana
dashboard.
The
idea
of
this
is
to
kind
of
create
a
single
pane
of
glass
dashboard
that
gives
you
some
insights
and
useful,
useful
information
about
the
software
applications
in
your
organization
that
have
been
you
know,
processed
using
the
workflows
that
I've
been
talking
about.
A
If
any
of
you
are
familiar
with
a
website
called
depths.dev,
then
this
this
dashboard
is
heavily
inspired
by
that
website
and
I
would
recommend
you
go
and
have
a
look
at
it
in
any
case.
So,
on
the
left
hand,
side,
that's
really
showing
a
list
of
all
the
dependencies
in
this
particular
software
application
in
the
top
right.
A
That's
the
scorecard
score,
so
each
of
the
bars
represents
a
different
metric
and
that
scorecard
uses
beneath
that
is
a
table
showing
a
list
of
the
vulnerabilities
in
this
software
application
and
beneath
that
is
account
and
a
list
of
all
of
the
open
source
licenses
that
were
discovered
in
this
offer
application
in
the
bottom
half
of
the
screen.
This
is,
if
you
like,
a
kind
of
dynamic
and
interactive
dependency
graph.
A
So
this
this,
what
I
did
was
import
all
of
the
the
dependency
graph
into
neo4j
and
then
use
the
tool
called
Neo
neoviz
to
be
able
to
allow
developers
or
whoever's
viewing
this
dashboard
to
be
able
to
explore
the
relationships
between
the
different
dependencies,
the
direct
ones
and
the
transient
ones.
In
this
software
application.
A
And
then
the
other
thing
that
we're
going
to
look
at
and
there's
been
quite
a
lot
of
demos,
and
so
on
about
admission
controllers
like
kyverno
and
gatekeeper.
So
really,
what
we're
doing
here
is
using
one
of
those
types
of
admission
controller
to
basically
you
can
write
policies
that
say
if
this
image
hasn't
been
signed
or
if
this
image
doesn't
contain
a
particular
or
doesn't
possess
a
particular
attestation,
then
don't
let
it
be
deployed
into
this
particular
runtime
environment.
A
Okay,
so
inevitably,
during
this
little
journey
of
creating
these
pipelines
and
the
improved
sort
of
security
workflows,
we
learn
a
few
lessons
on
the
way,
the
first
of
which
is.
There
are
a
number
of
s-bomb
generating
tools
out
there.
They're
not
all
created
equal
and
by
that
I
mean
that
some
are
better
than
others
at
providing
an
an
accurate
reflection
of
the
components
in
the
docker
images
and
so
on.
A
The
second,
the
second
one
is
something
that
Adrian
brought
up
in
his
talk
this
morning
around
the
fact
that
scanners
of
Docker
images
are
not
magic.
If
you
don't
use
a
standard
package
tool
for
installing
software
into
a
Docker
image,
there
is
a
reasonably
good
chance
that
it
won't
be
picked
up
by
one
of
the
scanning
tools
and
therefore,
if
it's
not
picked
up,
it
won't
appear
in
the
s-bomb.
The
vulnerabilities
that
might
be
associated
with
that
particular
binary
won't
be
picked
up
either.
A
The
third
one
again
topical,
I.
Think
yesterday,
I
sat
through
an
interesting
talk
about
Conan,
C,
C
plus
plus
package
manager.
Sadly,
our
client
that
uses
that
develops
C
and
C
plus
plus
don't
use
Conan.
So
it
was
kind
of
tricky
to
figure
out
exactly
what
the
dependencies
and
their
versions
were
for
the
the
C
and
C
plus
plus
applications
and
then
finally
scale
and
volume
as
we
discovered
processing.
These
s-bombs
takes
up
a
lot
of
CPU
and
resource.
A
To
kind
of
do
that
whole
scanning
of
more
and
more
images,
so
just
before
we
wrap
up
here
are
the
kind
of
key
takeaways
that
I
hope.
You'll
get
from
my
talk,
open
source,
as
you
perfectly
well
know,
is-
is
fundamental
to
the
large
majority
of
modern
software
applications
and
therefore
performing
this
kind
of
additional
and
in-depth
due
diligence
is
absolutely
crucial
in
order
to
you
know,
understand
and
mitigate
the
security
risks.
A
Clearly,
automation
is
absolutely
essential.
It
is
just
not
practical
to
do
this
stuff
with
a
spreadsheet
and
manual
sort
of
manual
investigation,
I've
put
up
there
a
few
tools
that
we've
had
success
with
with
with
our
implementations
and
then
the
final
Point
as
I
keep
mentioning
is
make
sure
the
developers,
the
CI
pipelines
and
the
runtime
environments
pull
from
this
trusted
registry.
That's
in
your
control,
okay!
Well,
thank
you
for
listening
hope.
A
A
By
doing
that,
there's
there's
very
little
chance
that
you're,
like
a
scanning
tool,
is
going
to
notice
that
node.js
runtime
and
if
it
doesn't
notice
it,
it's
not
going
to
be
able
to
report
it
in
the
s-bomb
and
it's
not
going
to
be
able
to
identify
any
vulnerabilities.
We
won't
even
it.
You
know
it
won't
know
the
version
First
do
that
then
I
always
put
in
there
too
to
feed
the
scanner
to
it.
So
you
what
your?
A
A
A
No,
no,
if
you're,
that's
exactly
it.
If
you're
that,
that's
where
you
know
this,
isn't
this
isn't
a
Silver
Bullet
by
the
way
and
and
I
completely
agree
with
you.
If,
if
you
take
random
images
and
and
you
depend
on
those
random
images,
then
you're
still
leaving
yourself
open
for
abuse
as
it
were,
and
the
and
and
I
think
that's
exactly
the
point.
That's
exactly
the
point
I'm
trying
to
make
is
that
scanners
are
not
silver
bullets
either
they
will
not
protect
you
from
that
kind
of
activity.