►
From YouTube: Adding Open-Source Security Tooling to your DevOps Pipeline - a CDFOnline Meetup, April 2023
Description
With the recent 'security awakening' new supply chain tooling is available to harden the DevOps Pipeline. Learn from Steve Taylor, CTO of DeployHub and CDF TOC Board Member, what tools go where. He will explore 5 phases of the pipeline where scanning, signing, SBOMs, and cataloging can be added to evolve your DevOps Pipeline into a DevSecOps Pipeline.
A
B
Thank
you
all
for
joining
the
either
you
joined
us
through
the
ortelius
Meetup
group
or
the
CDF
online
Meetup
Group.
Thank
you
for
coming
on
board
and
your
interest
in
continuous
delivery
and
how
to
secure
your
your
software
supply
chain.
This
is
becoming
more
and
more
of
a
topic,
so
it
seemed
like
a
a
a
good
and
relevant
topic
for
an
online
Meetup
to
start
really
having
a
discussion
about
what
kind
of
tools
we
should
be
adding
into
the
CD
pipeline.
B
I
am
Tracy.
Reagan
I
have
been
hosting
these
meetups
now
for
a
few
years.
Thank
you
to
the
CD
foundation
for
trusting
me
to
pull
these
things
off.
This
is
being
recorded
and
will
be
pushed
out
to
the
city,
CDF
Community,
as
well
as
anybody
who
has
joined
these
meetups
today.
I
am
happy
to
introduce
Steve
Taylor.
He
is
the
full
disclosure
he
is
our
our
deploy.
B
Hub
CTO
he's
also
on
the
board
of
the
technology
oversight
committee
for
the
CD
foundation
and
has
done
some
work
around
some
open
source
projects,
including
ortilius.
He
is
pretty
much
the
senior
contributor
to
that
and
a
project
pushed
by
jfrog
called
Persia
he's
also
done
some
work
around
stream,
nine
for
the
open
ssf,
which
has
to
do
with
consuming
s-bomb
data.
B
So
he
has
some
experience
and
background
in
software
security
on
that
Steve
I
am
going
to
take
myself
off
of
the
the
video
and
mute
myself
and
I'm
going
to
hand
it
over
to
you.
A
A
The
amount
of
attacks
that
we've
been
getting
through
the
supply
chain
have
been
growing
tremendously.
The
hackers
have
figured
out
the
supply
chain
is
the
easy
way
to
get
their
their
malicious
code
into
the
process
and
distributed
for
them
out
to
the
all
the
end
users.
A
So
we've
had
this
huge
increase
of
seven
times
higher
than
we've
seen
in
the
past
and
as
a
result,
the
boards
of
the
companies
are
and
like
the
CEOs,
the
c-level
execs
are
considering
cyber
security,
a
larger
business
risk,
so
they're
putting
more
focus
on
security.
A
Just
because
you
know
it
can
make
such
a
a
huge
impact
when
your
company
is
taken
out
of
you
know,
blown
out
of
the
water
for
a
week
or
so
when
you're
trying
to
recover,
even
though
Disaster
Recovery
plans
are
in
place
still
a
huge
loss
of
Revenue
on
that
front,
so
they're
really
focusing
on
that
level
to
make
sure
that
cyber
security
is
addressed
and
then,
lastly,
application
teams
and
companies
are
really
wanting
to
see
more
visibility
into
the
application.
Level
security.
A
There
are
things
where
you
know
we
have
the
at
the
edge.
You
know
our
incoming
routers
and
stuff
like
that
are
able
to
able
to
handle
some
like
denial
of
service
attacks
and
things
like
that.
But
that's
just
part
of
it.
A
A
So
when
we
think
talk
about
application
security,
we
need
to
look
at
our
devops
pipeline
and
our
devops
pipeline
has
basically
four
to
five
different
areas
that
you
can
start
addressing.
Your
security
changes
to
one
is
actually
at
the
the
code
and
we'll
go
into
each
one
of
these
in
detail.
I'll
just
give
a
highlight
here,
so
the
first
stage
is
like
the
coding
and
the
pre-build
side.
A
So
that's
where
the
developers
are
actually
doing
their
work,
then
you
have
the
build,
which
is
creating
your
artifacts
and
making
sure
that
you
are
doing
that
level
of
automation
at
the
build
level
and
then
there's
a
post
build
piece
depending
on
upon
your
build
tool
and
your
development
language
that
you're
using
you
may
need
a
post
build
step
for
application
security,
and
then
you
have
your
publish,
which
is
where
you
actually
are.
A
You
know
pushing
out
your
artifacts
to
be
consumed,
some
sort
of
registry
or
release
process
at
that
level,
and
then
finally,
we
have
our
audit.
You
know
when
we
go
through
an
audit
everything
how
that
takes,
what
we're
going
to
do
with
the
data
that
we
We
Gather
at
that
level.
So
we'll
look
at
all
these
different
stages
here
and
we'll
dive
into
our
phase,
one
coding
in
pre-build.
A
So
when
we
think
about
adding
security
steps
to
our
coding
and
our
and
our
pre-build
when
I
talk
about
pre-build,
this
is
like.
When
you
do
your
git
commit.
You
want
to
make
sure
that
you
have
a
code
signing
enabled
so
get.
You
can
enable
two
things,
there's
a
signing
piece
and
then
there's
a
signature
piece.
A
So
the
signing
piece
is
where
you
actually
use
a
key
to
sign
your
commit,
and
then
you
can
associate
your
key
to
your
like
your
GitHub
repo
or
your
you
get
lab
repo
and
then
it'll
give
you
like
this
verified
tag
for
your
commit.
So
that's
one
of
the
first
things
that
you
want
to
be
able
to
do
is
generate
your
basically
your
signing
key
and
then
make
sure
that
git
is
configured
to
go
ahead
and
do
all
of
the
signing
for
every
every
change
that
you
make.
A
The
next
part
is
signatures,
signatures,
saying
signed
off
by
Steve
Taylor,
for
example,
and
that's
just
another
level
to
say
that
I've
I've
actually
done
this
is
this
is
what
I
really
wanted
to
do
and
I
signed
off
on
it?
A
The
next
part
we
have
is
code
scanning
tools
that
happen
at
the
the
the
code
and
pre-build
level.
The
the
co-skating
tools
are
going
to
be.
You
have
your
SCA
code
scanning
tools,
so
software
composition,
analysis,
Vera
code,
sonar
Cube
there.
Those
are
type
of
of
tools,
that'll,
look
at
the
how
your
source
code
is
put
together
and
determine,
if
there's
any
vulnerabilities
at
that
level.
Next,
we
have
a
repository
scanning
tools,
code,
ql,
trivia,
dependabot
frogbot.
A
Those
are
actually
looking
at
your
repository
looking
for
Secrets.
Looking
for
how
your
workflows
are
structured,
those
basic
type
of
dependency
analysis
if
you're
looking
at
like.
If
you
have
a
node.js
program,
it's
going
to
look
at
your
package.json
to
see
if
you're
on
the
the
latest
version
of
a
package
same
thing
with
like
Ross
Ross.
A
Has
this
cargo
toml
file
that
you
need
to
look
at
dependencies
for
so
all
the
different
languages
are
going
to
have
some
sort
of
files
that
are
at
the
repository
level
that
are
going
to
be
viewed
and
reviewed
by
these
repository
scanner
scanning
tools.
A
You
know
if
you
want
a
full
list,
go
out
to
oasp
and
check
out
what
they
have
for
those
tools,
also,
if
you're
a
GitHub
user.
If
you
go
to
the
security
tab
for
a
repository,
you
can
turn
on
and
off
things
like
trivia
code.
Ql
depend
about
those
are
all
configurable
right
from
your
repository
there.
So
it's
pretty
easy
to
get
up
and
going
so.
The
next
phase
we're
going
to
go
into
is
our
build
phase.
So
this
is
where
we're
actually
going
to
gen
create
our
our
our
artifact.
A
So
we're
actually
going
to
start.
You
know
doing
compiles
packaging
things
at
that
level.
So
one
of
the
things
that
happened
at
the
build
phase
that
we
need
to
address
from
a
security
standpoint
is,
we
want
to
make
sure
we're
we're
generating
s-bomb.
A
A
Basically,
appco
is
focused
around
building
from
source
and
getting
you
a
clean
artifact
that
at
that
level,
appco
can
also
produce
a
an
s-bomb.
So
your
software
build
material
is
generated
actually
at
build
Time
same
thing.
With
the
build
X
you
when
you
run
build
X,
you
can
tell
it
to
generate
and
ask
Mom
at
the
the
creation
time.
Other
things
we
want
to
do
at
the
build
phase
is
we
want
to
make
sure
we're
signing.
We
want
to
assign
our
artifacts,
so
Sig
store
has
a
tool
called
code.
A
Cosine,
notary
2
has
a
tool
so
those
things
we
want
to
make
sure
that
are
being
done.
So
we
want
to
build
as
in
build
our
code,
generate
the
s-bomb
at
build
time
and
then
make
sure
that
it's
signed
now
things
like
build
ax
and
Sig
store.
These
tools
will
work
hand
in
hand.
So
the
when
you
do
the
build
X
it'll
actually
generate
the
s-bomb
and
the
signature.
At
the
same
time,
other
things
we
want
to
make
sure
that
we're
doing
is
at
the
build
phase.
A
Is
we're
not
doing
this
on
our
own
computer
by
just
say
like
doing
a
npm
package?
For
example,
we
want
to
make
sure
that
it's
being
done
on
a
hosted,
build
system,
so
you
have
Google
cloud
build.
You
have
the
GitHub.
You
have
git
lab
tecton
Jenkins.
You
want
to
make
sure
that
it's
being
done
on
a
a
build
system
and
that
build
system
is
actually
locked
down.
A
So
there's
another
phase
that
you
can
get
into
where
you
can
make
sure
like
with
tecton
titanium,
has
something
called
chains,
tecton
chains
that
will
report
everything.
That's
happened
during
the
workflow
or
the
build
process
and
give
you
like
a
log
of
exactly
where
things
came
from.
So
you
know
they
have
a
secure
build
system.
A
Now.
What
will
happen
is
if
we
do
not,
if
we're
not
able
to
do
a
an
s-bomb
at
the
build
phase,
we
need
to
add
in
a
secondary
step
into
our
pipeline,
and
this
is
where
the
artifacts
are
are
actually
produced
at
the
build
build
phase,
but
the
build
tool
wasn't
able
to
produce
the
the
s-bomb
natively
so
because
of
that,
we
have
to
go
ahead
and
do
a
second
step
where
we
actually
generate
the
s-bomb
based
on
the
artifact
from
the
previous
one.
A
A
Those
are
two
different
I
want
to
say
they
kind
of
are
competing
formats
of
your
s-bomb,
but
basically
in
the
software
build
material.
It's
going
to
list
all
of
your
dependencies
that
your
artifact
is
dependent
upon.
Now,
one
of
the
things
I
haven't
seen
yet
in
these
s-bomb
tools
is
actually
reporting
the
source
code
that
was
used
at
build
time.
A
What
ends
up
happening
is
it'll
report
upon
package
dependencies
so
dependencies
that
you
have
from
a
package
to
package
level,
but
right
now
they
haven't
been
generating
at
the
very
first
level
saying
you
know,
I
just
built
this
artifact,
here's
a
list
of
all
the
source
code,
all
the
hashes
for
every
single
piece
of
source
code
that
went
in
to
create
this
artifact.
So
it's
one
of
those
they
haven't
quite
got
there.
Yet
the
s-bomb
formats
supported,
but
the
tools
just
haven't
been
rolled
out.
A
Yet
to
do
that
and
the
reason
why
that's
important
is
when
you
look
at
your
vulnerabilities,
you
want
to
make
sure
that
you
may
have
a
vulnerability
in
in
this
one
file
in
your
code
base
and
that's
where
the
vulnerability
exists
and
we
want
to
be
able
to
track
back
to
the
actual
commit
that
could
have
introduced.
That
vulnerability.
A
For
example,
like
maybe
there's
a
regular
expression
that
is,
enables
a
denial
service
attack
type
of
thing,
and
you
want
to
be
able
to
get
back
to
that
exact
source
code
and
that
commit
where
that
was
introduced.
So
the
s-bombs
are
evolving
at
this
level.
We
are
when
we're
talking
post,
build
we're
mainly
going
to
get
a
package.
The
package
type
of
s-bomb
created.
A
On
our
next
phase,
we're
actually
going
to
do
our
publishing,
so
we've
created
our
artifact,
whether
it's
a
Docker
image,
a
jar
file,
War
file-
you
know,
we've
done
our
we're
going
to
do
our
our
release
now,
so
we're
going
to
release
our
artifact
out
to
a
location
that
it
can
be
consumed.
A
So
the
when
we
do
a
publish,
if
we're
talking
Docker
images,
we're
going
to
push
those
out
to
oci
Registries,
so
like
artifact,
hob,
Docker,
Hub
Quay
are
just
a
few
of
the
oci
Registries
that
are
out
there.
You
may
also
have
internal
oci
registries.
You
know
all
the
cloud
vendors
have
them
so
Google
as
there's
the
GCR
Azure
has
one
you
know.
Basically,
AWS
has
their
their
registry,
so
it
doesn't
really
matter
where
it's
going
to
end
up.
A
But
what
we
want
to
make
sure
of
is
that
when
it
gets
there,
we
want
to
go
ahead
and
scan
again,
anything
that
was
published
out
to
the
the
Registries
and
the
reason
why
we
do
this.
This
secondary
scan
is
in
case.
The
build
pipeline
is
not
doing
the
vulnerability
rescan
at
the
build
or
at
the
post,
build
step.
So
we
want
to
make
sure
that
we
we
do
that
scan
at
that
level,
and
also
one
of
the
things
I've
seen
is
different
tools
will
find
different
vulnerabilities
at
different
times.
A
So
some
of
the
scanning
tools
will
work
really
well
and
we'll
find
a
vulnerability
like
at
build
time
like
the
code.
Ql
and
trivia
will
find
things
at
build
time
or
post
build
time,
but
after
it
gets
out
to
Docker
Hub.
The
vulnerability
may
show
up
two
days
later,
that
we
have
no
new
vulnerability
that
we're
not
catching
at
the
build
time.
So
it's
these
things
that
we
have
to
constantly
keep
running
and
keeping
track
of
and
keeping
an
eye
on
throughout
the
process.
A
Because
one
of
the
things
with
securing
your
your
pipeline
and
your
your
supply
chain
is,
you
have
to
constantly
do
it.
You
just
can't.
Do
it
once
and
say:
okay
I've
done
it
I've
done
my
security
scan
at
the
the
code
level
we're
all
good,
but
because
these
things,
because
we
have
vulnerabilities
popping
up
every
day,
we
need
to
be
constantly
looking
over
our
code
base
and
our
artifacts
that
we've
created
now.
One
of
the
things
that
will
will
happen
is
the
cve
side,
the
vulnerability
side.
A
They
will
get
published
to
different
repositories
at
different
times
depending
upon
the
language.
So
we
have
things
like
nist,
miter
openssf
has
the
osv
dev,
which
is
kind
of
like
a
aggregation,
cve
details,
GitHub
advisories,
so
all
these
different
locations
we
have
to
go
and
check
to
see
if
a
new
vulnerability
has
been
found,
and
that's
one
of
the
things
that
we
want
to
keep
an
eye
on
is
is
making
sure
that
our
our
that
we're
checking
or
cross-referencing
those
databases
on
a
daily
basis.
A
So,
finally,
we
get
to
our
our
pipeline
audit,
and
one
of
the
things
that
we
want
to
do
at
this
level
is
to
actually
audit
what
we
did
from
our
developer
check-in
all
the
way
out
through
all
the
different
stages.
So
when
we
did
our
our
code
check-in,
then
we
did
our
build.
Then
we
did
our
post
build.
Then
we
did
our
publish
and
we
did
our
release.
We
want
to
make
sure
we're
auditing.
All
of
that,
and
one
of
the
things
in
the
supply
chain
process
is
we
want
to.
A
We
want
to
audit
the
supply
chain
itself
to
see
if
there's
anywhere
that
things
could
have
been
introduced
when
we
went
from
our
build
phase
to
our
publish,
were
there
any
new
dependencies
that
were
introduced,
that
we
weren't
expecting
so
did
somebody
hack
the
the
supply
chain
itself?
This
is
where
the
audit
process
comes
into
play
and
there's
the
Jenkins
Auto
Trail
techton
chains
are
just
a
couple
examples
of
auditing
the
pipeline
itself.
A
So
some
of
the
things
that
we
want
to
try
to
pull
out
of
each
step
in
our
pipeline
is
the
the
s-bomb,
and
then
we
want
to
take
the
s-bomb
in
cross
reference
that
with
the
cve
and
then
we
want
to
make
sure
that
when
we
do
a
release,
we
have
that
release
being
audited
and
any
cves
attached
to
that
addressed,
and
then
we
want
to
keep
track
of
what's
happening
at
the
the
changes.
You
know
what
changes
were
actually
done
for
from
the
developer,
all
the
way
out
now.
A
A
Is
these
days
is
around
200
microservices,
so
we
have
basically
200
workflows
or
Supply
chains
that
we
need
to
Monitor
and
then
aggregate
that
information
up
into
our
logical
application.
View
and
then
we
want
to
be
able
to
look
at
it
from
the
The
Logical
application
and
see
where
things
are
are
falling
over.
Where
which
parts
of
our
code
base
are
are
could
have
vulnerabilities
that
could
be
attacked.
A
And
then
we
need
to
make
sure
we
address
those
if
we
focus
things
on
just
at
the
low
level
we'll
be
able
to
track
it,
but
it's
much
harder
to
figure
out
what's
running
where
what's
running
and
which
microservice
version
is
running
in
development
versus
one
which
version
of
the
same
services
in
QA
and
production.
So
we
have
to
look
at
this
from
the
high
level
perspective
of
pulling
together
and
aggregating
all
the
data
up
to
a
logical
application
viewpoint.
A
So
that's
where
the
open
source
project
that
I
work
with
ortilius
it'll
hook
in
and
grab
for
each
one
of
those
microservices
the
data
that
we
want
and
do
that
aggregation
up
to
the
app
logical
application
view.
Now
that
gives
us
information
that
we
can
really
utilize.
A
We
can,
you
know,
be
able
to
say
for
this
application
that's
running
in
production.
This
is
all
the
actual
data
that
we
need
to
look
at.
So
these
are
the
new
cves
that
popped
up,
that
we
have
to
address
within
the
last
couple
hours
and
then
we
can
then
go
through
and
say:
oh
microservers,
a
is
the
one
that's
giving
us
problem.
Let's
go
focus
on
that
all
the
the
other
199
are
good
for
today.
A
So
what
this
allows
us
to
do
is
really
give
us
that
Federated
Insight
across
all
of
our
applications
and
all
the
Clusters.
A
As
part
of
that
you
can,
you
know,
answer
questions
like
where's
log4j
running
you
know:
do
we
have
which
services
are
are
using
these
vulnerabilities
and
being
able
to
really
pinpoint-
and
you
know
in
a
few
keystrokes
what
is
going
on
where
and
what
needs
to
be
addressed
at
that
level.
This
this
really
helps
developers
manage
drift,
see
what's
happening
between
the
different
environments,
and
you
know
address
things
quicker.
A
It's
a
it's
amazing
on
how
much
time
you
can
spend
just
chasing
cves
and
fixes,
even
though
the
fix
may
be
just
as
simple
as
bumping
to
the
you
know,
this
version
to
the
latest,
one
knowing
which
ones
have
to
be
you
know
addressed
and
when
really
cuts
down
the
amount
of
time
on
the
development
side,
and
then
also
it
gives
you
the
the
point
of
view
of
you
know:
microservice
a
was
the
one
that
had
the
vulnerability.
A
We
just
fixed
that
now
we
should
just
be
able
to
test
the
the
test
microservice
a
instead
of
having
to
retest
all
200
services
so
drastically
cutting
down
on
our
our
time
to
production
at
that
level,
foreign.
A
We
want
to
be
able
to
look
at
the
whole
supply
chain,
aggregate
that
together.
A
A
So
all
of
this
will
happen
on
an
automated
level.
So
the
way
we
introduce
artillius
into
the
pipeline
is
at
the
build
stage
and
then
at
the
published
stage
or
the
release
stage,
it
could
go
either
place.
But
basically,
when
you,
when
you
generate
your
ass
bomb,
we
have
a
process,
basically
ortalia
CLI,
that
allow
us
to
capture
that
that
s-bomb
Associated
to
the
git
commit
of
the
source
code
and
then
be
able
to
track
that
as
it
moves
through
that
version
of
the
of
your
microservice
or
your
artifact
moves
through
the
pipeline.
A
So
when
it
gets
deployed
and
released
out
to
production,
that's
where
we
make
a
second
call
out
to
artillius
to
say:
I
just
deployed
this
service.
This
version
out
to
this
this
cluster,
for
example,
and
now
I,
know
what's
running
where
the
S
associated
s-bomb
with
it
all
the
supply
chain.
Information
is
aggregated
to
that
version
of
that
service
and
then
aggregate
it
up
to
the
logical
application
view.
A
So
now
that
we
have
our
data,
let's
do
something
with
it.
So
one
of
the
things
that
we're
going
to
be
able
to
do
is
with
artillius
is
centralize
all
of
your
devops
and
all
your
security
and
and
software
composition
into
one
place.
Give
you
that
view
of
what
your
open
source
footprint
looks
like
across
the
organization.
A
If
we,
if
we
have
microservices
involved,
how
is
each
microservice
put
together
and
how
is
that
microservers
relating
to
other
microservices
and
to
the
application
View,
and
then
we
can
look
at
the
impact
you
know.
Like
I
said
we
have
a
package
vulnerability,
we
can
look
at
it
from
the
microserver
side
or
the
you
know,
going
from
I
know
that
this
service
has
a
vulnerability.
What
are
all
the
lot,
what
are
all
the
application
teams
using
it?
A
So,
if
I
fix
this
vulnerability,
who
do
I
have
to
tell
to
go
fix
and
retest
their
their
logical
application
or
from
the
other
side?
How
does
the
the
security
footprint
look
like
from
this
application?
Are
we
are?
Do
we
get
the
greens,
you
know
the
thumbs
up.
A
Everything
is
coming
up
green
or
do
we
have
vulnerabilities
that
we
need
to
address
and
what
is
the
the
level
of
risk
that
we
that
we're
exposed
to
then
also
we
can,
you
know,
track
at
the
The
Logical
application
view
what's
happening
in
development
versus
production
and
all
those
stages
in
between
is
Qi
does
QA
have
house
QA,
looking
or
uat,
because
of
that
we
can
version
that
logical
application
view
across
the
different
stages
of
the
pipeline
and
give
you
that
that
print
that
look
in
between
what's
running
in
production,
what's
in
QA
and
see
if
things
are
getting
fixed
and
how
things
are
moving
across
the
pipeline.
A
And
finally,
when
we
talk
about
microservices,
you
know,
like
I,
said
typical
microservice
applications
getting
around
200
100
to
200
microservices.
How
does
that
affect
all
the
Clusters
that
we
have
running?
What
we're
seeing
is
you
know
production.
A
Is
that
one
single
big
cluster
these
days,
but
it's
many
clusters
spread
out
across
different
regions
of
the
world
that
we
need
to
keep
track
of
what's
running
in
each
cluster
compared
to
you
know
like
a
a
blue
green
deployment,
or
you
know
a
a
tiered
deployment
where
we're
going
to
go
hit.
Maybe
the
states
at
three
o'clock
in
the
morning
I
see
how
things
happen
and
then
we're
gonna
run
out
roll
it
out
to
the
UK
the
next
day.
A
Type
of
thing
so
we'll
be
able
to
track
what's
happening
in
each
level
across
that
and
give
you
that
that
view
of
how
your
securities
and
supply
chain
looks
at
that
point,.
A
So
here's
just
an
example
of
one
of
the
and
a
microservice
environment
and
looking
at
a
version
of
a
component
is
what
we
call
them
so
basically
an
artifact
that
we've
created
all
of
the
dependencies
that
are
in
it
from
the
s-bomb
level
and
then
the
corresponding
vulnerabilities.
So
it
makes
it
an
easy
dashboard
to
take
a
look
at
where
you
stand.
Vulnerability,
wise.
A
And
then
again
you
know
who's
using
log4j.
Basically,
it's
a
search
box.
You
say
I
want
to
find
out
who's
using
this
package
and
we're
able
to
give
you
the
component,
that's
consuming
it
and
then
the
application
that's
being
affected
by
it.
So
that
gives
you
that
that
quick,
Deep
dive
to
answer
that
question
who's
using
what.
A
So
we
have
some
exciting
new
architectural
changes
coming
through
for
artillius.
One
of
the
things
that
we're
actually
going
to
be
doing
is
utilizing
a
blockchain,
so
The
xrpl
Ledger
to
track
historically
the
immutable
data
that
we're
Gathering.
A
So
all
the
package
dependencies
the
application
dependencies,
the
cves,
the
s-bombs,
all
that
information
is
going
to
be
pushed
through
on
a
Rango
database
that
we're
going
to
use
for
caching
we're
going
to
persist
that
information
in
the
blockchain,
the
basically
The
blockchain
Ledger,
and
then
also
we're
going
to
persist
the
data
over
in
nft
storage.
The
reason
why
we're
doing
this
is
the
amount
of
data
that
gets
generated
from
your
your
supply
chain
process
is
huge.
We
were
talking
to
one
of
the
the
lead
project
managers
over
at
Encore.
A
They
were
just
keeping
track
of
the
the
verified,
Docker
images
on
Docker
Hub
and
they
ran
their
s-bomb
tool
against
those
images
for
two
weeks
and
they
ended
up
getting
three
gig
worth
of
of
s-bomb
data.
So
we're
going
to
be
using
this
process
to
normalize
data
and
do
some
efficient
storage
and
be
able
to
make
it
easy
for
folks
to
be
able
to
find
things
and
keep
track
of
what's
Happening,
where
in
an
immutable
fashion,.
A
So
if
we
look
at
the
the
open
source
side
of
the
security
landscape
again,
this
is
just
the
open
source
side.
There's
many
other.
You
know
regular
vendors
out
there,
but
if
we're
looking
at
the
the
code
and
pre-build,
there
are
open
source
tools
from
verico.
It's
on
our
Cube,
the
repository
scanning,
the
code
ql
truvy
depend
about
those
are
already
part
of
just
need
to
turn
them
on
in
GitHub
the
build
side.
A
When
you
go
ahead
and
do
the
artifact
generation
APCO
in
build
X
now
both
of
these,
especially
in
the
APCO
side,
you
need
to
do
a
little
work
because
it
actually
changes
up
how
you
do
your
packaging,
so
that
is
going
to
be
actually
a
a
change
in
your
package
manager
to
utilize
that
build
X
will
work
with
a
a
basic
Docker
file,
but
there
are
some
extra
bells
and
whistle.
If
you
go
ahead
and
change
up
the
the
way
you
do,
your
Docker
images,
you
do
build
them.
A
A
Github
actions
I,
haven't
seen
anything
yet
on
that
front
and
I
believe
Google
Cloud
build
is
starting
to
introduce
some
more
and
more
like
supply
chain,
immutable
supply
chain
auditing
around
that
the
signing
side
and
attribution
Providence
the
signing
side
of
six
store,
which
is
cosine
notary,
twos
coming
out.
There's
other
tools
out
there
like
I
to
do
I
to
dodos
is
another
part
of
attribution
and
Providence.
A
So
there's
those
are
some
of
the
tools
you
want
to
look
at
from
the
signing
and
attribution
Side,
Package
verification,
the
Persia
project,
which
is
a
build
consensus
process.
So
you
actually
build
the
open
source
projects
on
four
different
five
different
nodes
and
compare
that
they
all
came
up
with
the
the
same
result.
A
Making
sure
that
you
didn't
have
a
supply
chain
hack,
then
post
build
we're
going
to
have
the
s-bomb
generation
tools
that
are
going
to
look
at
the
artifacts,
so
sift
spdx,
Microsoft's
s-bomb,
there's
a
couple
other
tools
out
there,
depending
upon
your
language,
that
your
your
coding
in
we'll
have
the
different
posts,
build
s-bomb
tools,
and
then
we,
when
we
publish,
we
want
to
make
sure
that
we're
publishing
over
to
a
registry
that's
being
scanned
as
well.
A
So
like
Docker
Hub
has
their
scanning
artifact
hob
for
your
home
charts
Quaid
does
scanning
Maven
Central
the
mpm
world,
Pi
Pi.
All
those
Registries
have
some
sort
of
scanning
happening
at
the
publish
level
to
see
where
you
stand
for
the
CVS
and
finally,
the
evidence
catalog
that
pulls
all
of
this
information
together
is
where
artillius
lies.
A
So
if
you're
interested
in
artillius,
please
join
us
we're
part
of
the
the
CD
Foundation,
you
can
go
to
artillius.io
or
you
can
go
to
thecd.foundation
and
you
can
find
us
there.
Like
I
said
we
have
some
exciting
work
going
on.
A
We
have
a
new
project
that
we're
just
starting
up
around
The
blockchain
Ledger,
the
ipfs
and
the
nft
storage,
and
we're
also
pulling
in
additional
oci
Registries
as
part
of
the
data
storage
that
we're
going
to
be
utilizing
as
as
a
side,
project
or
side
option
to
the
nft
storage.
A
So
we
are
looking
for
more
contributors
to
dive
in
we.
If
you
go
out
to
the
CD
Foundation,
they
have
a
calendar
and
you'll
be
able
to
find
the
artillius
meetings
out
there.
There's
the
general
meeting
we
just
had
one
this
morning,
and
then
we
have
an
architecture
and
Outreach
meeting
that
will
be
happening
next
week.
A
So,
like
I
said,
come
out
and
join
us.
If
you
have
any
questions,
let's
go
ahead
and
open
it
up.
I
believe
there's
the
Q
a
that
we
have
enabled
for
this
webinar.
A
B
And
yeah
everybody
is
unmuted,
so
you
can
just
ask
a
question
or
put
it
in
the
Q.
A
I
do
have
one
question
when,
when
the
open
ssf
is
also
or
the
Google
salsa
project
in
the
phases,
does
it
just
primarily
deal
with
the
build
phase.
A
A
That
I
think
has
like
eight
different
areas
that
you
can
attack
or
or
are
part
of
the
attack,
plane
and
I,
believe
they
simplified
it
down
the
four
or
five
in
the
new
version
of
salsa
and
what
that
is
highlighting
is
places
that
you
can
introduce
malicious
code
into
as
part
of
the
build
process
so
like,
for
example,
if
I
do
a
git,
if
I
do
a
get
clone
and
I
check
out
the
code
and
then
I
do
my
build
in
between
that
those
two
steps,
if
my
supply
chain
is,
if,
if
my
workflow
is
not
secure,
I
can
introduce
a
vulnerability
in
there.
A
So
I
could
actually
do
a
like
a
curl
command
and
go
fetch
some
malicious
code
and
put
it
into
the
build
directory.
So
there's
processes
and
things
that
they
do
at
that
level
to
ensure
that
there's
nothing
being
introduced
into
the
salsa
framework
there.
But.
B
B
So
the
projects
like
Persia
doing
the
package
verification
helps
get
you
to
those
salsa
levels,
because
you
are
addressing
those
gaps.
Correct.
A
Okay,
so
like
one
of
the
things
so
in
the
Persia
project,
where
it's
a
build
consensus,
Network,
if
you
have
five
five
build
nodes,
they
all
check
out
the
same
code
and
then
one
of
the
nodes
is
compromise.
Where
you
go
ahead
and
introduce
some
malicious
code,
what
will
end
up
happening
is
that
one
node
out
of
the
five
will
come
up
with
a
different
result
and
because
it
it
comes
up
with
a
different
result
than
the
other
four
that
result
from
that
build
node
is
basically
thrown
away.
A
And
the
same
thing
happens
like
with
the
the
the
signing,
those
those
aspects
of
it.
So
when
you
build
your
code
and
you
you
sign
it
and
then
you
do
your
release,
you
know
somebody
downloads
that
release
and
they
go
to
verify
the
signature
in
the
signatures,
not
matching
up.
That's
where
you
know
that
that
release
has
been
compromised.
A
B
See
well,
thank
you.
So
much
Steve.
You
gave
us
a
huge
amount
of
information.
There
there's
a
lot
to
do
in
terms
of
building
up
that
that
devops
process
to
add
security,
but
it's
well
worth
it
and
with
the
tools
I
think
you've
given
us,
all
of
which
are
open
source.
You
can
do
it
at
kind
of
a
low
cost,
but
there
is
a
lot
of
human.
The
cost
of
the
humans,
to
put
it
together,
can
be
challenging.
B
A
Yeah,
it's
it's
amazing.
When
you
look
at
the
amount
of
work
like
I
said,
if
you
have
a
microservices
project
that
has
200
repositories
and
you
want
to
go
turn
on
dependabot
for
200
repositories,
it's
more
than
a
five
minute
effort.
A
Know
and
and
turning
on
just
the
pen
about
to
make
sure
you're
on
the
latest
release
of
everything
is,
you
know
really
basic
I
mean
it's
it's
a
simple:
it's
a
big
win
for
a
simple
amount
of
effort,
but
when
you
look
at
200
repositories,
it
grows
your
your
amount
of
work
grows
exponentially
and
then
then
the
next
part
is
when
you
actually
go
find
that
you
have
a
dependency
that
needs
to
be
updated.
Now
you
have
200
pull
requests,
you
have
to
go
approve,
you
know.
B
A
Yeah,
when
I,
when
we've
been
working
with
artillius
and
implementing,
you
know,
supply
chain
security,
and
we
only
have
a
about
a
dozen
microservices.
That.
A
That
process
is,
is
easy
to
to
implement
and
we're
able
to
keep
track
of
it,
and
we
put
some
automation
around
it,
but
you
know
the
the
complexity.
A
Our
new
version
of
artillius
is
going
to
have
about
30
different
microservices,
so
it's
growing
quickly
and
keeping
track
of
all
those
different
areas
you
have
to
invest
in
is
quite
complicated,
because
what
I'm
seeing
is
in
order
to
secure
your
supply
chain.
It's
there's
about
15
to
20
different
I,
won't
say
necessary
tools,
but
checks
you
have
to
do.
You
have
to
make
sure
you
have
GitHub
git
commit
signing,
and
then
you
have
to
have
your
signature
and
then
you
have
to
have
your
you
you're,
dependent
by
trivia.
A
You
know,
so
the
list
is
about
15
different
things.
You
have
to
do
for
every
single
repo
to
make
sure
you're
you're
getting
a
secure
supply
chain.
So
it's
it's
one
of
those.
Take
a
little
bit
at
a
time
is
what
we
found
just
do
one
one
thing
at
a
time
and
and
figure
out
that
process
and
then
keep
adding
to
it,
and
that's
where,
like
CD
events
will
come
into
play,
which
will
be
nice
is
I
need
to
add
in
another
scanning
tool.
A
B
Okay,
so
next
next
month
we
do
have
cdcon.
Cdcon
is
in
Vancouver
May,
8th
and
9th,
followed
by
open
ssf
days,
which
is
on
the
10th,
and
it
was
all
happening
at
the
same
time
as
open
source
Summit,
which
I
believe
is
the
8th
through
the
11th.
So
if
you're
there
come
find
us
we'll
be
hanging
out
at
the
CDF
Booth
ortillas
will
have
a
room,
I,
don't
remember
the
time
and
date,
but
artillius
will
have
a
room
for
a
summit.
I
believe
it's
on
the
8th
at
noon.
B
So
look
for
that
in
the
schedule
and
in
announcements
coming
from
us
see,
the
events
will
also
have
a
summit
and
that
will
be
on
the
schedule.
So
if
that's
something
of
interest
to
you,
I
would
highly
recommend
if
you're
there
go
to
the
CD
events,
project
Summit
I
said
like
an
hour
and
a
half
where
you
can
talk
about
what
events
will
do
and
how
how
far
along
the
events
framework
is
to
getting
a
version
one
getting
it
implemented.
So
we
hope
to
see
you
all
next
month.