►
From YouTube: SBOMs for All Using Ortelius
Description
Presented by Steve Taylor at the May 20, 2022 Ortelius Visionaries Summit
Hardening cybersecurity in cloud-native environments means we need to track not just service SBOMs, but more importantly application SBOMs. In a decoupled architecture, it can be almost impossible to create an application SBOM - Steve Taylor will show us how Ortelius gets this job done so everyone has an SBOM.
A
So
arturus
is
a
microservice
catalog
that
governs
your
microservice
supply
chain
by
tracking
your
microservice
versions,
the
blast
rate
of
this
blast,
radius
of
a
service,
the
inventory,
the
s-bom,
cves
and
vulnerabilities
the
service
catalog
information
such
as
the
owner
of
a
service,
and
we
do
this
to
give
you
a
proactive
view
of
your
microservice
application
as
it's
changing
over
time.
Arterius
is
an
incubating
project
under
the
cd
foundation,
and
our
mission
is
to
simplify
the
adoption
of
microservices
through
a
world-class
microservices
management
platform,
driven
by
a
supportive
and
diverse
global
open
source
community.
A
So
our
topic
today
is
we're
going
to
talk
about
hardening
cyber
security
in
a
cloud
native
environment,
meaning
that
we
need
to
track
not
just
a
microservice
s-bomb
but,
more
importantly,
the
applications
s-bomb
in
a
decoupled
architecture.
It's
almost
impossible
to
create
an
application
s-bomb
without
using
something
like
ortelius
a
little
bit
information
about
me.
I,
like
I
said,
I'm
the
deploy
hub
cto.
A
I
am
the
one
of
the
architects
on
the
ortiz
open
source
project.
I
am
on
the
technical
oversight
committee
for
the
cd
foundation
and
I'm
a
persia
open
source
contributor
and
been
doing
this
for
over
20
years.
Please
reach
out
to
me
on
my
linkedin.
Send
me
a
message
and
we'll
get
a
conversation
going.
A
A
A
So
what
we
need
to
do
is
take
another
look
at
what
a
microservice
application
really
looks
like
it
actually
is
a
a
collection
of
microservices,
all
all
the
micro
services
that
are
needed
to
make
the
application
run.
So
if
we
have
100
microservices
that
are
used
to
make
our
application
run,
we're
going
to
have
to
pull
all
those
together
and
represent
our
application.
Logically.
A
So
because
of
this,
we
have
a
lot
of
change
happening
that
we
need
to
keep
track
of
and
because
of
that,
the
s-bombs
get
even
more
complicated
because
remember
when
we're
talking
about
these
microservices
being
having
their
own
build,
we
have
to
look
at
those
builds
happening
all
day
long
and
those
builds
are
going
to
create
their
own
individual
s-bomb
and,
in
truth,
s-bombs
are
not
only
are
there's
many
levels
to
them.
So
we'll
have
a
hardware
s-bomb
we're
using
arm
versus
amd
what
was
os
being
used
when
we
created
this?
A
What
was
the
compiler?
What
were
all
the
dependencies,
including
the
transitive
dependencies
that
were
consumed?
What
was
the
package
manager
doing
and
finally,
what
was
the
when
we
pulled
it
all
together?
How
does
this
new
s-bomb
relate
up
to
our
applications,
and
now
this
is
happening
for
every
single
microservice
that
we're
creating,
and
you
know
if
we
have
a
hunt
like
I
said
if
we
have
100
microservices
in
our
logical
application,
we're
going
to
have
a
lot
a
hundred
s
bombs
that
we
need
to
start
tracking
and
managing.
A
So
how
do
we
fix
the
problem?
Well,
we're
going
to
aggregate
up
all
those
micro
service
s-bombs,
including
their
vulnerabilities
up
to
the
application
level,
and
we're
going
to
pull
that
together
at
the
logical
viewpoint,
so
this
aggregation
has
to
occur
to
give
us
that
view
from
the
application
point
of
view.
A
So
how
do
we
make
all
this
work?
First,
like
a
a
producer
of
the
microservice
and
one
of
those
developers
is
going
to
give
us
and
create
us
the
base
version
of
the
microservice
in
the
in
ortelius.
This
base
version
is
going
to
give
us
the
starting
point
to
start
tracking
the
s-bombs
and
the
relationships.
A
One
of
our
future
enhancements
is
when
the
developer
registers
their
new
service
that
will
integrate
with
backstage
or
cookie
cutter,
to
go
ahead
and
generate
the
back
end
pipeline
plumbing.
To
have
everything
all
ready
to
go
on
on
the
pipeline
side.
Also
we'll
be
adding
tags
to
domains
to
help
searching
for
microservices
a
bit
easier
and
then
the
consumer
who's
gonna
be
con.
You
know
the
like.
A
The
front-end
developer
is
going
to
need
to
save,
which
versions
of
the
microservices
that
they
want
to
start
consuming,
and
this
is
where
we
build
the
relationships
between
the
producer
and
the
consumer
and,
in
this
case,
we're
pulling
in
about
a
dozen
microservices
into
our
logical
view
of
our
application.
Now
we
do
this
once
again.
This
is
at
the
the
base
version,
and
this
gives
us
the
starting
point
and
from
there
on
it's
going
to
be
self,
maintaining
as
the
ci
process
comes
along,
we
update
a
service.
A
We
know
where
the
previous
one
was
used
and
therefore
we
can
generate
new
application,
logical
application
versions
going
forward.
So
it's
it's
really
nice
because
it's
you
know,
you
define
it
once
and
forget
about
it,
and
it
just
keeps
going
collecting
the
data
that
you
know
we
need
to
aggregate
forward.
A
So
even
though
some
of
them
most
of
them
will
probably
only
make
it
to
a
certain
point
in
your
pipeline
process,
it
gives
you
the
choice
of
which
ones
to
want
to
be
a
release
candidate
and
therefore,
which
ones
are
going
to
make
it
out
to
production.
We
need
to
keep
track
of
all
that
information,
so
we
have
a
history
in
a
timeline
of
what's
happening
with
your
application,
as
changes
are
being
made
to
it.
A
A
The
git
commit
server's
catalog
information,
all
that
is
gathered
by
the
artillious
step
in
the
pipeline
and
then
from
there
we're
going
to
go
ahead
and
update
artilleries
and
tele
artilleries
about
all
that
information,
and
it
will
go
ahead
and
give
us
a
new
logical
view
of
our
application
at
that
point.
So
we'll
create
a
new
version
of
the
component
and
subsequently
create
a
new
logical
version
of
the
application,
and
this
gives
us
the
ability
to
aggregate
again
the
s-bom
up.
A
Look
at
the
versioning
of
your
application,
as
is
happening
over
time.
Do
difference
reports
do
trend
analysis,
those
type
of
things
at
the
application
level
and
that's
the
important
thing
we're
doing
this
for
every
single
service
and
therefore
we
get
this.
This
nice
complete
picture
at
the
application
level.
A
So
what
what
does
it
look
like
when
we
start
looking
at
the
data?
From
the
application
point
of
view
you
can
see
here
on
the
left
table
panel?
We
got
our
vulnerability
list
and
in
that
vulnerability
list
you
can
see
which
component
the
vulnerability
is
showing
up.
So
if
they,
the
same
vulnerabilities
and
multiple,
we'll
report
that
or
if
it's
only
in
one
we'll
be
able
to
show
that
as
well,
but
here
you're
able
to
see
from
the
application
point
of
view.
Where
do
you
all?
A
Your
vulnerabilities
exist
across
all
your
services
that
are
that
your
application
is
using
and
then
on
the
right.
We
have
our
sbom
and
here
we're
listing
all
the
packages
that
are
being
consumed
across
all
the
the
services
and
what
licenses
those
packages
are
using.
You
know
that
the
licensing
is
concerned.
Maybe
you
have
a
like
a
new
license
in
there
and
the
lawyers
say
you
can't
use
anything
from
gnu.
This
will
allow
you
to
find
that
information
at
the
application
point
of
view.