►
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Microservice Supply Chain and the Ortelius Application SBOMs - Tracy Ragan, DeployHub
One of the new requirements under the Biden Administrations’ executive order on improving Cybersecurity is the requirement to provide purchasers a software bill of material (SBOM) for each software solution. But what is a software solution? Is it just a single microservice or is it a collection of microservices? In this presentation, you will learn how Ortelius aggregates an application-level SBOM by tracking the microservices, with versions, that it uses. This level of reporting is important to show what the ‘logical’ application is consuming, its vulnerabilities, and all transitive libraries and services it consumes. While this may be easy to create in a monolithic architecture, creating these higher-order SBOMs at the application level is difficult. The Ortelius catalog simplifies the process for every ‘logical’ application version released.
A
A
All
right,
so
I
assume
maybe
people
will
be
like
oh
okay,
but
we're
going
to
start
anyways.
So,
yes,
s-bombs
are
something
that
we
have
had
recent
discussions
on.
I
think
that
it's
important
to
start
this
session
by
saying
we've
always
had
we've
had
s-bombs.
For
a
long
time
now,
we've
been
able
to
generate
s-bombs.
A
Since
I've
been
doing
this,
we
used
to
call
them
build
audit
reports
for
at
least
20
years,
so
s-bombs
are
not
new
they're,
just
finally
being
recognized
for
what
they
do
and
the
insights
that
they
provide,
but
we'll
walk
through
and
we'll
just
talk
about
some
of
the
challenges.
You
know
why
work,
what
artillios
is
about
and
how
we've
created
do
we
have
a
a
clicker
that
I
can
use,
so
I
don't
have
to
come
back
up
here
in
my
little
corner.
B
A
B
C
A
Do
that,
oh
this
one,
okay,
great,
all,
right,
okay!
So
recently,
I
think
the
reason
why
s
s-bombs
have
gotten
some
more
visibility
is
because
we
have
had
some
big
vulnerabilities
like
log
for
jay
woke
everybody
up.
Many
of
us
who
have
in
the
industry
said:
oh,
you
know
what
that
was
going
to
happen.
It
just
finally
did
and
the
linux
foundation
started.
A
Taking
note
and
the
us
government
started
taking
note
as
well,
if
you
need
to,
if
you
want
to
learn
more
about
s-bombs
and
what
the
linux
foundation
is
doing,
I
probably
should
have
not
just
put
that
I
should
probably
put
the
full
link,
but
this
is
this:
you
can
download
this
session
and
you
can
get
the
link,
but
they
create
they
did
a
document
called
s
moms
and
cyber
security
readiness
highly
recommend.
You
read
it.
It's
a
really
good
read
and,
as
jim
zemlin
points
out
is
that
you
know
s.
A
A
A
A
I
also
am
the
ceo
and
co-founder
of
a
little
company
called
deploy
hub.
I
call
this.
The
little
company
that
could
I
have
been
have
been
recognized
as
a
tech
beacon,
which
is
kind
of
cool,
it's
kind
of
fun
to
have
that
happen,
and
I'm
also
on
the
board
of
the
open
ssf,
I'm
involved
in
what
they
call
stream
nine
of
the
government
s-bomb
evaluation.
I
would
call
it
that
the
linux
foundation
is
working
with.
A
A
So,
let's
just
talk
about
when
I,
when
I
this
session,
is
specific
around
microservices
and
the
challenges
and
with
s-bombs
with
microservices.
There
are
plenty
of
challenges
with
s-bombs
in
the
monolithic
world.
I'll
give
you
one
big
one,
there's
a
massive
gap
in
s-bombs
from
the
time
that
you
generate
it
and
it's
sitting
underneath
your
cd,
your
ci
cd
pipeline
in
the
format
of
a
file.
Somebody
could
take
that
and
delete
the
packages.
A
They
don't
want
anybody
to
see
and
move
forward
and
nobody
would
know
the
difference
so
they're
not
immutable,
which
is
a
problem,
but
that's
a
problem
for
all
s:
bombs,
not
just
microservices
or
monolith.
That's
just
a
problem,
and
I
can
talk
to
you
about
what
we're
thinking
about
doing
to
solve
that.
A
But
in
a
monolith
world,
when
we
create
the
s1,
we
do
it
at
the
time.
We
do
this
software
compile
and
link
step.
So
we
take
all
of
that
information
and
that's
where
the
s
bomb
gets
generated.
So
you
have
an
s
bond
for
each
application
version
and
that's
what.
For
example,
the
us
government
wants
to
see
they
don't
care
about,
seeing
an
s-bomb
for
every
single
microservice
that
your
company
produces.
They
want
to
know
what
an
application
version
s-bomb
looks
like
now.
A
Why
that's
important
is
because
actually,
if
you
take
two
s-bombs
from
an
application
version-
and
you
compare
them,
you
can
see
the
difference.
What
was
different
different
between
the
two
releases
and
you
can
drive
down
and
see
all
your
your
vulnerabilities,
so
application
level
s
bombs
will
continually
be
what
are
used
to
determine
if
an
application,
the
higher
level
software
solution
is
secure.
A
But
in
microservices
we
decompose
all
that,
so
we
have
hundreds
of
potential
of
s-bombs
and
how
do
you
collect
that
all
together
and
produce
that
as
a
single
report
at
an
application
version
when
we're
not
even
thinking
about
application
versions
anymore,
and
I
feel
like
that's
one
of
the
reasons
why
microservices
are
often
seen
as
being
super
complex.
They
are
because
the
north
star
that
we
always
had
is
now
gone.
It's
like
we're
trying
to
calculate
our
longitude
and
we
have
no
north
star
to
follow.
A
A
You
can't
easily
find
the
providence
if
you
don't
have
an
s
bomb,
so
that
becomes
another
issue
for
application
teams
and
at
the
bottom,
at
the
end
of
the
day,
we're
really
trying
to
find
vulnerabilities
and
the
way
you
find
a
vulnerability
is
to
know.
What's
in
your
in
your
package
and
the
way
you
find
your
packages
through
an
s
bomb,
so
it
all
kinds
of
trickles
up
or
trickles
down
from
the
s-bomb,
and
that's
what
oftentimes
causes
this
this
this
problem
and
where
the
problem
really
resides
is
around
transit
of
artifacts.
A
How
do
you
know
what
those
are
and
we
can
get
this
information?
We
have
fabulous
tools
like
you
know.
The
jfrog
folks
who
are
here
go
talk
to
them
about
the
tools
that
they
use.
We
love
jfrog
and
they
have
that
that
information.
But
how
do
you
calculate
that
and
bring
it
up
to
the
application
level?
A
It
is
a
job
that
should
have
been
tossed
out
the
window
a
long
time
ago.
We
still
have
build
meisters,
who
are
really
struggling
to
pull
stuff
together,
but
in
a
micro
services
world
that
does
change.
So
we're
going
to
talk
about
ortillius.
It
is
one
of
the
first
incubating
projects
at
this
at
the
cd
foundation.
I'm
very
proud
of
that
fact.
A
We
started
in
20,
you
know
covet
has
lost.
I
would
have
no
reference
of
time.
It's
only
pre-covered
and
post-covet.
It
was
sometime
during
that
time.
I
think
it
was.
This
is
2022,
so
it
would
have
been
2021
or
20
december
of
2020
is
when
we
got
accepted
into
the
cd
foundation,
and
we
began
this
journey
of
building.
A
Details
like
a
component
microservice
is
a
component
we
track
of
the
version,
so
we
actually
do
the
versioning
on
the
back
end.
We
do
the
application
to
component
relationships.
We
track
the
component
blast
radius
over
here.
On
the
right
hand,
side
we
have,
we
see
our
cart
service
and
that's
the
component
and
it's
impacting
multiple
versions
of
this
particular
product.
We
call
the
hipster
store,
probably
because
in
this
image
it
was
running
in
multiple
clusters.
A
We
track
the
service
and
application
s-bomb.
So
every
every
service
has
an
s-bomb.
It
gets
aggregated
up
at
the
application
level,
as
well
as
the
cves
the
ownership
and
where
it's
deployed
across
the
inventory.
So
when
you,
the
company
that
I
run,
is
called
deploy
hub,
what
what
we're
gathering
is?
A
hub
of
deployment
information
that
includes
things
like
the
cves,
the
inventory,
the
versioning
all
of
the
things
all
of
the
pieces
of
this
giant
lego
system,
we're
building.
A
A
So
I
said
we
have
a
fabulous
group
of
open
source
contributors,
one
of
the
things
we
did
before
the
beginning
of
this
year.
We
had
our
first
election
of
a
governing
board.
These
are
all
requirements
to
eventually
become
a
graduated
project.
We
have
a
long
way
to
go
at
the
adoption
level,
but
we're
putting
together
the
infrastructure
in
in
terms
of
the
project
itself.
A
A
A
We
really
pushed
to
bring
in
women
to
this
board
and
aisha
she's
out
of
pakistan,
which
is
really
fun
to
have
this
kind
of
global
community
and
she
started
as
a
project
manager
and
what
she
wanted
to
do
with
her
career
is
to
become
more
technical.
So
we
threw
her
all
the
hardest
things,
so
she
worked
with
steve
and
they
built
out
quite
a
bit
of
the
architecture.
A
Sasha
is
out
of
south
africa.
He
is
one
of
the
funniest
people
I
ever
have
met
in
the
technology
area,
but
then,
when
he
goes
to
do
a
presentation
he's
all
very
professional
we're
all
like
come
on
sasha.
We
want
to
see
the
real
you
and
then
anne-marie
fred
and
sergio
canelos
they're,
both
from
red
hat
and
red
hat's,
been
watching
pretty
closely
what
we're
doing
and
our
our
adopters
siddharth
parikh
he's
from
nat
west
group.
A
It's
one
of
the
largest
banks
in
in
europe
and
they've
been
adopting
and
sort
of
learning
from
the
community
as
we've
grown,
and
we
have
an
amazing
group
of
of
contributors,
brad
mccoy
karam
singh
utkar,
sharma,
phil,
gibbs
bin
po,
sam
safdor,
arvind
and
adam
gardner.
This
kid
here
I
have
to
brag
because
I'm
so
he
is
only
a
junior
in
college
and
he
has
17
000
followers.
A
A
So
what
are
we
up
to?
What
is
this
group
of
fabulous
people
up
to?
We
really
are
up
to
what
I
like
to
call
taming
microservices
and
we
have
to
tame
microservices
by
collecting
the
data
about
them,
so
devops
teams
use
ortelius
to
track
the
service
inventory.
So
knowing
things
like,
what's
what
the
drift
might
look
like,
so
how
many
of
you
out
there
have
started
doing
cloud
native
and
you
only
have
one
cluster,
none
of
you.
Of
course,
there's
there's
hundreds
of
clusters
clusters
have
turned
into
I
you
know.
As
a
developer.
A
I
used
to
ask
for
having
my
own
server
under
my
desk,
because
I
wanted
a
nice
protected
environment,
so
we
could.
Our
team
could
put
things
on
and
test
it
before
we
push
it
out,
which
was
a
really
bad
idea
to
be
quite
honest,
but
that's
how
what
clusters
are
doing
now?
We
have
you
know
infrastructure
as
code.
Anybody
can
spin
up
a
cluster,
so
you
have
hundreds
of
clusters.
Well,
if
you're
using
services
in
a
way
that
is
shared,
you
could
have
services
that
are
running
on
clusters
that
are
different
versions.
A
That's
the
reason
why
we
have
to
understand
all
in
one
place
where
what
versions
of
the
of
the
services
are
being
used
and
what
and
where
they're
being
used.
You
know
microservice
developers,
I
always
companies
that
are
doing
microservices.
I
tell
them
that
sometimes
I
feel
like
they
have
one
big
junk
drawer.
A
Every
microservice
has
a
particular
focus
area.
It
solves
a
certain
problem
and
being
able
to
communicate
that
so
that
we
can
find
and
share
them
is
important
because
you
can't
just
throw
them
all
in
the
junk
door.
So
has
a
domain
structure
that
allows
you
to
tag
things.
Basically,
it's
really
more
than
tagging.
It
is
really
a
domain
structure
that
says
these.
These
microservices
belong
to
a
certain
domain
and
they
could
have
sub
domains,
and
then
application
teams
have
a
way
to
package.
A
So
now,
let's
talk
about
we're
starting
to
get
what's
below
the
surface.
Once
we
have
that
information,
we
can
start
tracking
what's
below
the
surface.
So
in
that,
in
that
method,
security
teams
now
have
a
way
to
see
s-bombs
from
a
central
place
and
they
begin
seeing
s-bombs
aggregated
up
to
the
application
package.
A
A
My
applications
use
many
microservices
microservices
are
consumed
by
many
applications.
We
track
that
many-to-many
relationship
and
then,
of
course,
support
teams.
Can
you
imagine
being
a
support
person
and
getting
a
phone
call
from
you
know
we
use
the
hipster
store
as
our
example,
so
our
hipster
store.
I
can't
I
can't
finalize
my
transaction.
My
credit
card
isn't:
go,
isn't
working?
A
Okay,
you
think
that
that
customer
would
have
said.
You
know
your
microservice.
That's
handling
those
credit
card
transactions
are
a
problem.
So
what
is
the
support
team
to
do?
They
want
to
call
the
application
team
to
say
your
hipster
store
is
not
working
and
the
hipster
store
team
is
going
to
say
we
didn't
change
anything.
A
I
don't
know
we
didn't
change
anything.
I
have
no
idea
what
could
be
wrong
and
then,
if
you
do
find
it
out,
because
you're
looking
some
you're
using
an
observability
tool
and
you're
like
well
look
at
that
particular
transaction
is
having
it
just
having
some
latency.
Now
we
know
it's
this
particular
microservice,
but
who
do
we
call?
Who
do
we
know?
How
do
we
know
who's
who's
using
it
something's
as
simple
as
that
is
a
challenge
with
microservices?
A
The
next
thing
that
happens
is
the
service
changes.
It
gets
registered,
let's
say
the
query
or
docker
hub
or
where
whatever
repository
you're
using
ortilius
gets
woke
up,
and
we
say
oh
we're,
triggered
at
the
point
in
time.
A
new,
a
new
container
has
just
been
registered.
We're
going
to
go
grab
the
shaw,
we're
going
to
go.
Look
at
the
cd
pipeline,
we're
going
to
pull
in
the
swagger
information,
we're
going
to
pull
in
the
cves
we're
going
to
pull
in
the
s-bombs.
A
We're
going
to
pull
in
anything
that
we
need
and
what
we
can
get
from
that
cd
pipeline
at
that
point
in
time,
ortilius
is
going
to
say.
Okay
now
I
have
a
new
version
of
this
particular
component.
I
know
I
have
10
applications
that
use
it.
I'm
going
to
go,
create
10
new
versions
of
those
applications,
each
one's
going
to
have
a
new
application
version.
A
A
The
build
the
very
first
thing
we
do
is
create
a
build.
We
take
all
the
libraries
all
the
code,
we
link
it
in
and
we
create
a
new
release
candidate.
So,
in
essence,
what
we're
doing
is
we're
create
we're
replacing
this
the
the
old
build
with
a
new
build,
but
the
new
build
is
logical
and
we're
and
we're
managing
that
so
that
we
have
this
information
now
it
doesn't
mean
that
that
got
released.
A
It
just
means
that
there's
a
release
candidate
out
there
and
the
application
team
can
make
the
decision
if
they
want
to
push
it
out.
With
that
data,
we
can
start
grabbing
some
information.
We
can
show
the
blast
radius,
which
we
talked
about.
We
can
start
generating
these
application
level
s
bombs
and
we
can
track
the
application
component
dependencies
at
the
high
level
that
we
know
about
and
that
application
component
dependency
is
what
creates
the
new
version
of
the
release
candidate.
A
A
When
they
register
their
component
they're
going
to
create
a
base
version
up
here
in
the
the
red
circle
that
shows
you
says
component
based
version
and
we're
going
to
grab
some
information.
So
I
created
this
demo,
I
put
my
my
name-
got
pulled
out
my
email,
my
phone
number,
all
this
is
actually
very
accurate,
so
you
can
call
me
if
you
wanted
my
pager
duty.
A
The
we
also
can
see
from
here
that
it's
a
the
component
type
is
a
container,
and
we
all
also
can
see
that
I
used
helm
to
do
the
deployment
now
included
in
this.
If
we
were
had,
if
we
were
doing
a
live
demo,
we
could
scroll
down,
and
I
could
show
you
that
we
are
also
tracking,
like
things
like
key
value
pairs
for
each
environment.
Those
key
value
pairs
might
change.
This
is
the
information
me
as
a
developer
is
telling
everybody
else
when
you
go
to
use
my
microservices.
A
This
is
this
is
what
you
this
is
how
you
should
treat
it.
This
is
how
it's
being
deployed-
and
this
is
what
you
want
to
use
now.
You
can
have
different
kinds
of
components,
not
just
microservices.
You
can
have
a
file
to
think
about
lambda,
think
about
salesforce,
or
you
could
have
a
database
and
each
one
of
these
between
these
three
types.
Believe
it
or
not.
We
can
cover
every
kind
of
component,
a
file
system
component,
a
container
or
a
database
component.
A
A
Now,
when
you
do
register
your
component,
we
are
going
to
start
pulling
in
from
the
ci
cd
pipeline
information,
like
your
swagger
details,
the
readme
file
and
your
cv
issues
and
your
license:
consumption
from
the
license,
consumption
and
the
cve
issues.
These
are
just
based
on
the
actual
component.
We
are
not
generating
that.
I
want
to
make
it
clear.
We
are
a
consumer
of
the
information
we
consume
s-bombs.
A
A
I
am
going
to
create
a
package
in
the
same
way
I
have
for
a
long
time.
If
I'm,
you
know,
if
I'm
familiar
with
products
like
hey
david
hello,
if
we,
if
we've
if
we've
consumed,
if
we've
done
things
like
harness,
you
know
what
a
package
is.
We've
done
this
before
application
teams
understand
this
and
we
even
built
it.
A
Now
what's
going
to
happen,
is
a
micro
service?
Developer
is
going
to
create
a
new
version
of
our
cart
service,
they're,
going
to
create
a
new
build
image
of
it,
they're
going
to
store
it
somewhere
in
version
control
or
their
artifact
repos
they're
going
to
generate
s-bombs
and
cves,
and
then
we're
going
to
bring
it
up
we're
going
to
suck
all
that
information
up
into
the
ortelius
catalog
and
we're
going
to
start
tracking
it
and
we're
going
to
create
that
logical
application.
A
A
So
now
we're
starting
to
just
track
this
information
over
time.
If
it
didn't
get,
if
it
didn't
get
deployed,
you
would
have,
it
would
say
over
here,
never
deployed,
so
you
can
have
an
application
release
that
was
never
deployed
because
that
application
team
didn't
say:
okay,
I'm
going
to
use
that
new
service
and
I'm
going
to
pull
it
into
my
cluster.
A
Now
we
have
all
that
information.
Now
it's
really
easy.
We
just
go
out
and
we
grab
the
s-bom
information
from
all
of
this,
the
consuming
microservices
and
we
create
an
application
level
s
bomb.
So
in
this
case
we
have
the
the
this
is
a
fully
aggregated
s-bomb.
So
it
shows
every
single
component
s-bomb
brought
up
it
at
the
at
the
application
level,
and
then
we
also
pull
it
into
the
vulnerabilities
so
now
we're
showing
for
the
application
we're
showing
the
s
bomb
and
the
vulnerabilities.
A
A
And,
as
a
result,
we
get
these
kinds
of
reports,
so
we
have
the
application
version
to
component
mapping.
This
is
sort
of
how
we
started
this
business.
Somebody
asked
us
if
we
could
track
what
components
an
application
was
was
using
and
what
their
versions
were.
We
can
generate
this
difference
report
so
at
the
application
level,
if
you
get
a
phone
call
that
says
hey,
I
can't
somebody's
having
problems
with
your
credit
card.
You
can
now
go
look
at
your
application.
What's
running
in
that
particular
cluster.
A
Look
at
the
version
and
see
what
was
may
have
been
the
problem
so
right
here,
the
card
service
was
the
the
usual
suspect
I'll
call
it
now
from
early
adopters.
We're
being
told
that
the
reducing
the
sprawl
and
the
drift
of
microservices
is
saving
about
50
percent
of
time
tracking
the
supply
chain
automatically
saves
one
to
two
hours
per
release.
That
doesn't
seem
like
a
lot,
but
when
you're
doing
microservices
and
you're
trying
to
release
all
the
time,
it
actually
saves
a
quite
a
bit
of
time.
A
Sres
are
really
starting
to
understand
the
need
for
visibility,
not
just
observability,
but
visibility
before
you
do
a
release.
What's
going
to
happen
before
I
do
a
release,
and
then
we
really
want
to
evolve
the
ci
cd
pipeline.
So
this
information
is
being
tracked
with
it
for
more
information.
Please
come
and
visit
the
ortillius
team.
If
you've
never
contributed
to
an
open
source
project
and
you're
a
female
in
the
audience,
we
would
love
to
have
you
I'm
really
really
pushing
for
more
women
to
get
involved
in
open
source.
A
A
The
closest
we
had
would
be
the
swagger
information
that
shows
that
we
do.
We
have
had
people
now
ask
us
about
how
to
manage
microservices
that
have
close
dependencies
and
if
one
gets
updated,
the
other
one
should
one
way
to
do
that
is
through
an
application,
so
you
create
an
application
of
those
microservices
that
have
to
get
always
released
as
a
unit
and
that's
another
way
to
do
it.
But
we
don't
have
a
good
way
to
warn
you
that
this
at
this,
this
microservice
has
a
dependency
on
another
microservice.
A
I
know
we're
not
supposed
to
do
that,
but
it
will
happen
netflix.
They
call
it
a
application
with
a
little
a
and
what
they
do
for
that
is
they.
They
always
release
all
of
those
microservices
together
as
an
application
with
a
little
a
because
it
doesn't
actually
provide
a
customer
facing
solution.
It's
just
a
collection
of
services
and
that's
how
what
we're
seeing
is
how
this
is
being
adopted.
A
That
is
is
immutable.
So
we
really
want
to
solve
the
gap
that
I
talked
about
earlier.
The
only
way
to
really
do
that
is
to
use
something
like
a
blockchain
to
really
solidify
and
make
those
s-bombs
immutable
and
available
to
everybody,
because
one
of
the
complaints
that
we're
hearing
is
s-bombs
are
not
everywhere.
A
Even
though
we
know
that
there's
a
requirement
to
generate
them,
they're,
sitting
somewhere,
underneath
a
in
a
file
system,
nobody's
actually
consuming
them
or
doing
anything
with
them,
the
more
we
make
them
accessible
the
easier
it
will
be
for
people
to
make
the
next
step
to
start
consuming
them
any
other
questions
before
they
chase
us
out
of
here
all
right.
Thank
you
everybody.
I
appreciate
your
time.