►
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.
How’s Your Supply Chain with Your Insecure OSS Ingestion? - James Holland, Citi
OSS libraries can be used by anyone, but how does an enterprise secure what should, or more importantly, should not be used? The package/artifact managers are at best simple proxies, so security checking is mostly beyond them. Moreover, within enterprises, these tasks end up being manual. This talk will outline the additional checks that should/could be performed at ingestion and subsequently; continuous automated grooming of OSS artifacts. James will demonstrate the Continuous Secure Software Ingestion (CSSI) application, a policy driven system built on Tekton & Open Policy Agent (OPA), to perform continuous secure ingestion from any source, including Google AOS. He will also show the additional constraints that are placed on the downstream enterprise Software Composition Analysis (SCA) tooling to handle the data graph that this generates.
A
A
How
is
your
supply
chain
with
your
insecure,
your
OSS
ingestion,
so
try
and
take
you
through
what
we're
going
to
go
on
that
so
try
and
give
you
a
bit
of
a
overview
of
the
landscape
I'm
not
going
to
go
into
supply
chain
details.
There's
a
lot
more
bright
people
in
the
room
than
me
who
know
a
lot
more
about
this
than
I
do
so
I'm
going
to
leave
that
to
them,
but
I'll,
try
and
say
where
we
think
the
landscape
is
going.
Okay,
I'll,
give
you
a
background
of
the?
A
Why
a
bit
of
a
history
of
what
I've
been
doing
over
the
20
years
in
supply
chain
with
people
like
Department
of
Defense,
which
is
super
interesting,
some
of
the
tourings
we've
seen
in
the
past
and
what
we're
hoping
to
open
source
to
the
community
with
with
controlling
and
City
okay
and
then
wrap
up.
So
this
is
how
we
are
looking
at
the
landscape
from
the
work
we're
doing
in
the
marketplace.
A
A
A
Some
nervous
looking
people
yeah
hands
up
anybody
else,
doing
some
straight
into
your
pipelines
without
checking
where
it's
coming
from
or
whether
you
should
use
it
or
not.
Any
and
another
show
hands
how
many
people
are
actually
doing.
An
assessment
of
whether
you
should
be
using
that
library
or
not
one
excellent,
come
speak
to
you
later
Okay,
so
I
think
that's
what
I'm
trying
to
emphasize
is
that
the
point
is
that
you
can
use
this
library,
but
should
you
is
it
fit
for
purpose?
Is
it?
What
it's
saying
is
doing
is
the
right
thing?
A
Okay,
now,
as
you
can
see
in
this
landscape
here,
you
can't
have
a
supply
chain,
secure
bills.
If
you
have
no
idea
where
you're
getting
your
libraries
from
and
you
don't
know
the
maturity
levels
and
all
the
other
signals
that
might
go
around
that.
Okay,
if
we
look
at
this
tweet
I
think
this
sums
up
the
problem
pretty
well,
actually
look
at
all
these
package
managers.
You
know
very
flexible
super
helpful,
but
a
lot
of
them
allow
do
you
run
pre
and
post
install
Scripts
as
soon
as
you
installed
it.
A
The
piece
of
software
into
your
development
environment.
Now
we
know
from
previous
experience,
npm
has
got
2.2
percent
of
all
the
libraries
have
scripts
that
run
and
then,
if
we
look
in
further
we've
done
some
analysts
and
analyze.
Some
of
these
94
of
them,
you
say,
are
pretty
insecure
or
malicious.
It's
quite
a
huge
amount.
So
if
you're
looking
at
npm
alone,
two
percent
of
the
library
is
there
are
doing
malicious
activities.
A
Now,
that's
not
great,
especially
as
you've
got
no
way
of
checking
that
at
installation
time
at
the
present
moment
in
time.
Okay,
so
you
might
have
software
that
does
things.
There
is
some
commercial
software
that
does
this
okay,
but
there's
nothing
really
out
there
for
anybody
else.
Okay
and
thanks
to
Abby.
He
gave
me
permission
to
show
this.
A
So
if
we
start
looking
at
what
signals
we
want
to
look
at
is
never
green.
Yet
yes
or
no
there's
always
a
gray
area
in
between.
So
we're
always
going
to
take
libraries
from
Google
shut
up
and
Source
or
Alpha
Omega
project
from
openssf,
because
they've
gone
through
a
whole
series
of
checks
and
we
can
rely
on
them
and
you
know
that's
the
level
of
trust
we
have
with
those
organizations,
but
you
still
have
to
ingest
them
and
you
still
have
to
then
check
the
signatures.
A
They
came
in
from
there
that
Source,
okay
and
then
there's
the
ones
you
can
deny.
You
know
we're
having
a
signal
that
we
know
this
library
has
been
worked
on
by
somebody.
Who's
has
a
sort
of
dodgy
background,
or
you
know
it's
coming
from
a
sanctioned
country.
We've
seen
this
in
the
bank.
Okay,
the
fact
the
package
doesn't
have
a
signature
is
not
necessarily
a
bad
sign,
but
if
a
signature
is
failing,
it
would
suggest
it
is
I'm
not
going
to
go
into
Mrs
code.
I.
A
Think
that's
where
the
install
Scripts
I
was
saying.
The
p
and
post
in
Source
grips
on
the
package
manager
comes
into
this
red
area
and
as
a
bank,
you've
got
to
try
and
make
a
decision
or
organization.
Enterprise
you've
got
to
try
to
make
a
decision,
but
then
you
get
all
the
gray
area
should
any
one
of
those
fail.
Should
you
block
the
usage
of
that
Library?
No,
except
each
individual
individual
Enterprise,
to
make
a
risk
decision
based
off
this
information
and
have
their
own
policies
around
this?
A
Okay
and
there's
a
lot
of
information
in
there.
A
lot
of
signals
coming
in
that
we
see
and
a
lot
of
different
feeds
coming
in
okay.
So
we
need
a
way
of
having
a
right
in
a
very
simple
policy
for
Enterprises
to
check
these
signals
and
make
a
decision
whether
they
should
ingest
this
library
or
not.
Okay,.
A
A
So
just
looking,
this
is
a
spreadsheet
that
my
colleague
Francois
Marsh
used
to
come
up
with
and
we
used
to
use
this
every
time.
So
any
developer
used
to
come
in
and
ask
for
a
library
they
had
to
go
through
this
checklist
and
then
we
go
like
an
Empire
Emperor
thumbs
up
or
a
thumbs
down,
and
that's
including
that
was
including
Oracle
database.
So
we
had
to
build
Oracle
database
from
source
for
DOD
and
put
it
into
escrow,
which
was
quite
interesting.
A
So
what
I
would
like
to
say
about
this
is
that
the
process
of
building
everything
resource
is
not
possible
for
most
people.
Okay,
there's
only
certain
organizations
of
a
certain
scale
can
do
that
Google.
Do
it
for
their
Borg
DOD
demand
it
of
a
lot
of
organizations,
but
trying
to
do
a
reproducible,
build
or
build
your
source
code
is
impossible
because
all
of
the
environments
are
so
different
on
all
the
install
Scripts.
A
A
What
else
so
I
think
we
mentioned
this
before
I
think
the
previous
speaker
mentioned
this.
So
there's
a
load
of
new
tooling
coming
in
this
is
allowing
us
to
automate
a
lot
of
this
so
s-bomb
salsa
attestations.
That
would
be
great
if
we
could
get
that
every
time
vex,
as
mentioned,
there's
also
Kev
another
one
which
is
known
exploitable
of
vulnerabilities.
That's
an
interesting
one
to
look
at
so
you
can
say.
A
Actually,
there
is
a
proper
exploit
here,
but
these
are
never
know
and
allowing
us
to
automate
and
scale
this
automatically
and
that's
what
we're
hopefully
trying
to
do,
but
the
tools
do
exist
that
have
evolved
a
little
bit.
We
have
scorecards
and
stuff
like
that,
but
they're
limited
normally
proprietary
systems.
So
you
have
a
lot
of
the
vendors,
do
have
the
intelligence,
but
they
don't
actually
allow
you
to
make
a
decision
on
the
gray
area.
They'll
just
say:
yes,
no
and
that's
it.
A
Some
of
the
use
cases
around
this
are
getting
a
bit
more
complicated.
So
at
the
moment,
we're
focusing
on
the
blue
areas
the
top
right
about
how
we're
ingesting
the
libraries
in,
but
we're
doing
a
bit
of
a
separation
of
the
policy
of
what
you
ingest
in
and
actually
what
the
scanning
policy
might
be
or
the
test
policy
you
do.
A
So
when
we
collect
the
evidence,
we
don't
make
a
decision
within
the
container.
At
that
time
we
collect
the
evidence
and
story
for
later.
We
sign
it
and
store
it
for
later
and
then
make
a
policy
decision
at
the
end,
because
the
allow
us
then
to
rerun
that
in
the
future,
the
next
day
or
the
day
after
the
day
after
so
if
we
collected
the
evidence,
we
can
then
the
policy
changes.
We
can
then
see
it
re-evaluate
it,
and
this
allows
us
to
groom
the
libraries
daily.
A
What
do
I
also
want
to
say
about
this
I
think
it's
very
interesting
to
separate
what
the
initial
lookup
is
from
the
scan
policy,
because
an
initial
lookup
policy
of
the
PRL
can
do
this
particular
scan
or
not,
or
it
can
be
coming
in
a
particular
way
is
okay,
but
the
scam
policy
can
have
a
massive
effect
across
all
the
scans
and
all
the
all
the
lowers
you're
using.
So
if
I
change
the
policy
on
whether
a
signature
is
allowed
or
not,
I
want
to
see
what
that
effect
is.
A
A
And
also
we
want
to
be
able
to
subscribe
to
feeds,
so
we
can
bring
these
in
earlier
and
I.
Think
that's
the
red
section
top
left,
but
individual
libraries
you've
got
to
be
able
to
give
an
override
as
well.
We
see
this
a
lot
that
this
stuff
is
brought
in.
That
fails,
the
policy
very
specific
policy
which
Thomas
will
demonstrate
later
that
you
actually
say
for
this
Library.
A
We
make
a
policy
decision
there,
we
can
get
feeds
to
make
a
instant
decision
or
yes
or
no,
but
then
we
can
go
into
different
flows.
The
first
is
the
Intel
flow.
You
know
going
to
a
scorecard
or
a
chain
guard
skirt
or
other
fees
from
other
vendors
within
the
city.
We've
got
about
four
or
five
different
feeds
that
we
use
giving
us
various
information
about
even
individual
Developers.
A
So
then
most
things
will
go
through
the
standard
flow,
but
you
also
think
they
might
go
on
to
things
like
okay.
This
is
a
package
npm.
Do
we
want
to
actually
run
this
in
a
sandbox,
see
what
it
does
on
the
install
scripts
run
it
in
over
a
period
of
time
with
Linux
timestamp.
So
we
can
see
what
is
going
to
happen
over
a
two
or
three
week
period
and
accelerate
that
to
see
what
it
does,
because
it
might
actually
have.
A
You
have
some
sleeper
code
in
it
that
gets
triggered
in
two
weeks
time.
So
that's
the
sort
of
extensions
we're
looking
to
put
into
this
okay
and
also
getting
from
alternative
sources.
I
think
I've
mentioned
that
here.
I
think
that's
Google
I've
mentioned
that
in
the
first
slide,
so
without
further
Ado
I'm
gonna
a
lot
of
talking,
it's
a
very
similar
talk
that
we
gave
in
Dublin,
but
this
time
we
want
to
give
a
demo
of
what
we're
doing
we're
in
early
Alpha,
but
we'd
like
a
bit
of
feedback
off
that.
B
C
C
Actually,
it's
better
all
right.
Let
me
kick
off
with
an
example,
so
we
are
going
to
demo
the
npm
ecosystem
today
and
react.
Everyone
knows
it
I,
guess
and
yeah.
So
if
someone
requests
react,
we
always
care
also
about
the
dependencies
and
in
this
one
the
direct
one.
We
have
loose
energy
file
and
a
transitive
one
with
Chase
tokens
that
we
also
need
to
ingest
that
we
also
need
to
check
so
we've
built
open
source
ingestion
based
on
AWS,
eks
and
attacked
on,
and
so
we
have
techno
pipelines
in
place
and
yeah.
C
Let's
just
kick
it
off,
those
are
the
two
PLS
I'm
going
to
send
off.
So
one
is
the
mentioned.
React
example
and
the
other
one
is
the
shadow
quote
package
I'll
moderate
that
later.
Why-
and
this
is
just
a
test
script
to
send
it
to
our
API
and
I,
send
it
off
and
right
now
the
Techno
dashboard
is
a
good
way
to
Showcase.
What's
going
on
and
I
and
we
can
see,
we
have
four
pipeline
runs
running.
The
reason
of
that
is
the
first
one
is
react.
C
We
can
we're
gonna,
have
the
pre
and
post
install
script
checks
in
a
different
task
and
sales
checks
Etc
all
of
all
kinds
of
things
we
can
run
here
so
right
now
we
have
in
the
first
stage
the
Intel
scorecard
check
the
scorecard
check
itself.
So
we're
going
to
look
at
the
GitHub
repository
of
that
dependency.
C
C
Most
package
managers
or
registries
publish
or
Supply
the
signatures,
and
we
are
checking
the
signature
here
against
the
public
key
that
is
publicly
available
and
at
the
first
stage,
you're
running
our
vulnerability
stage.
So
we're
doing
running
calling
out
to
sneak
here
and
checking
if
there
are
any
vulnerabilities.
Any
CBE
stuff
like
that
in
here
and
James
mentioned
before
the
policy.
C
And
let's
go
inside
the
task,
one
itself
to
see
so
in
the
policy
decision
stage
we
are
fetching
all
the
check
results
of
the
previous
stages,
we're
getting
them
back
and
we
run
a
policy
check
against
Opa
with
a
bit
of
policy
we've
written
and
in
this
case
a
bit
of
a
spoiler.
Here,
it's
a
pass,
so
police
policy
passed-
and
that
means
we
can
continue
with
ingestion
and
can
put
in
our
internal
libraries.
C
Now
the
last
one
Shell
Code
one
second
here
I
got
a
kind
of
a
bit
of
different
message
here.
First
I
got
a
message
from
scorecard:
Appliance
protection
is
not
so
great.
Many
GitHub
repositories
I
have
that,
so
it
could
be
a
warning.
It
could
be
failure
depending
on
your
policy.
So
that's
that's
quite
flexible,
but
here
in
here
we
also
have
a
high
cve
coming
back
from
Snook
and
there's
a
remote
code,
execution
CV,
and
we
probably
don't
want
that
and
to
be
ingested.
C
So
in
terms
of
ingestion.
What
does
that
mean?
So
we
have
let's
go
in
here.
We
have
a
e-chased
stage.
We
do
a
couple
of
things
here
so,
depending
on
the
previous
policy
decision,
we
go
different
paths,
so
we
can
go
to
the
internal
registry
and
if
everything
passed-
and
we
are
golden,
we
can
throw
it
to
quarantine
or
we
can
straight
up,
deny
things
or
emit
warnings
at
the
same
time,
not
only
putting
a
lot
of
Registries
but
also
making
sure
that
everyone
knows
about
it.
C
That's
that's
another
important
thing
to
notify
people
so
right
now,
simple
emails
we
are
sending
out
to
SMS,
and
here
I
can
see
what
happened
inside
our
tecton.
In
summary,
so
cord,
we
already
know
why
it
failed.
Let's
look
into
Chase
tokens
and
here
here's,
the
signature,
Jack
reason
being
of
that
signature
check
is
because
npm
does
not
enforce
you
to
put
signatures
on
your
packages
in
Maven.
C
That
is
mandatory,
for
example,
and
so,
if
a
signature
check
fails
in
the
maven
system,
it
gets
much
more
interesting
because
then
something
is
really
going
wrong,
but
in
npm
it's
not
mandatory,
and
if
it's
not
there,
we
can't
run
a
signature
check
and
therefore
it
shows
for
us
in
terms
of
e-jest
right
now.
We
are
putting
it
into
an
S3
bucket
that
is
kind
of
like
our
output
store,
and
you
can
see
here.
We
have
the
two
packages
that
both
got
accepted
along
with
their
signature
for
further
consumption.
C
If
someone
else
wants
to
run
signature
checks
again,
they
can
use
that,
but
I
want
to
failed
packages,
of
course,
are
not
are
not
part
of
that
going
in
here,
because
we
didn't
allow
them
there's
a
bit
more
going
on.
So
in
terms
of
check
results
and
provenance,
we
we
are
using
tactone
chains
to
create
provenance
for
us,
so
we
are
signing
that
before
kmski
and
I'm,
putting
in
a
Dyno
DB
for
all
of
our
provenance,
but
the
provenance
doesn't
capture
the
actual
result
of
the
checks
for
us.
C
C
So
we
have
a
bunch
of
information
in
here
and
there's
going
to
be
more
in
the
future,
but
all
of
that
is
metadata
that
we
can
use
to
reference
data
with
each
other
to
reference.
What
other
checks
have
been
running
and
time
of
ingestion
stuff
like
that
to
also
trigger
re-inchests
things
like
that,
but
we
also
have
a
payload
and
signature
check
is
kind
of
easy
right.
Now
we
have
either
it
passed
or
it
failed.
So
here
we
have.
C
C
C
C
Yes,
kind
of
because
the
check
itself
is
versioned
because
it's
Unique
in
in
the
context
of
tecton
chains
as
well.
We
have
the
taskran
ID
in
our
context,
with
the
database
to
make
it
unique
and
in
terms
of
the
versioning
of
the
database.
We
also
have
with
that
context,
with
our
versioning
of
the
actual
code.
We
are
running
inside
those
checks.
Those
are
at
the
end
of
the
day,
Docker
images
that
we
can
version
accordingly
and
and
that
information
is
also
part
of
tactone
chain.
B
C
B
Mean
you're
you're
the
example
you
had
was
you,
someone
went
in
and
edited
it
it
made
it
super
good,
but
the
the
check
itself
it
didn't.
Look
like
you
had
enough
information
on
the
check.
You
had
a
time
stamp
and
you
had
the
name
of
the
track,
but
you
didn't
have
the
version
of
it
so
that
could
itself.