►
From YouTube: The Ortelius Evidence Store of SBOMs
Description
SBOMs are often generated but seldom consumed. Learn how Ortelius is tracking SBOMs with microservices and aggregating SBOM data to all 'logical' applications that consume them. Understand what an 'evidence' store is and how it works.
A
A
Okay.
First,
it's
really
important
to
understand
that
developing
software
in
a
microservice
architecture
is
complex.
It's
complex
because
of
the
amount
of
dependencies
even
monolith
have
a
lot
of
dependencies,
especially
when
we
start
thinking
about
open
source
packages
and
according
to
Tyler
Jewell.
A
He
says
that
software
systems
have
become
so
complex
that
it's
getting
too
difficult
for
humans
to
reason
about
the
systems
they
design,
which
is
the
complexity
of
microservices,
and
he
says
the
complexities
can
span
even
small
teams
who
could
have
a
broader
committer
graph
than
a
group
of
10
000
Engineers.
So
in
other
words,
it
doesn't
take
very
long
for
the
number
of
dependencies
and
open
source
packages
to
turn
into
a
massive
massive
hairball
and
securing
this
offer
supply
chain
has
leaped
to
the
top
of
CIO
and
cdo's
imperators
for
2022
and
I.
A
Now,
driving
this,
it's
not
just
cios
and
cdos.
It's
the
president
himself
in
May
of
2021
President
Biden,
pursued
a
cyber
security
executive
order
to
establish
the
use
of
s-bombs
to
show
your
software
supply
chain.
So,
in
other
words,
if
you
want
to
do
business
with
the
US
government,
you
need
to
have
an
s-bomb
and
that
s-bomb
then
can
show
all
the
dependencies
we
learned
this
because,
a
year
ago,
literally
one
year
ago,
the
December
9th
actually
is
when
this
this
broke.
Log
for
Jay
taught
us
how
important
understanding
your
dependencies
can
be.
A
Log4J
is
used
by
millions
of
developers,
it's
a
core
component
for
Java
developers
and
according
to
semantics,
they
claim
their
intrusion
detection
system
blocked.
More
than
93
million
log
for
J
related
exploited
attempts
between
the
9th
of
December
and
the
21st
of
December.
Now
what
we
learned
was
a
lot
of
organizations
couldn't
answer
the
question:
where
are
we
using
log
for
J
Who's
consuming
it
and,
most
importantly,
what
version
they
had?
No
insights
on
that.
A
So
there
is
a
demand
now
for
s-bomb
and
software
composition,
analysis,
SCA,
composition,
consumption.
We
have
s-bombs,
but
oftentimes.
If
you
generate
them
along
your
pipeline,
what
we
considered
as
a
check
box,
we
are
doing
an
s-bomb.
We
created
an
s-bomb,
so
if
it's
sitting
there
in
a
text
file
in
your
in
your
pipeline
directory,
where
you
ran
your
build,
does
it
help
us
probably
not
and
the
most
pressing
issue?
A
According
to
the
software
bill
of
materials
and
cyber
security,
Readiness
report
done
by
the
Linux
Foundation,
one
of
the
most
pressing
issues
was
62
percent
of
the
overall
sample
indicated
that
the
need
for
a
consistence
on
best
practices
to
integrate
the
production
and
consumption
of
s-bombs
into
our
software
development
practice,
and
in
my
world
that
means
the
the
devops
pipeline.
A
So
what
artelius
is
doing
in
terms
of
collecting
this
data?
It's
pulling
information
from
tools
like
Cyclone,
DX
or
osv,
or
Helm,
or
Argo,
Quay
and
GitHub,
and
it's
pulling
that
information
in
to
create
Federated
insights
and
logical
application
compositions.
So
we
have
the
high-level
microservice
composition
and
we
know
that
for
each
microservice,
but
in
a
cloud
native
microservice
architecture.
How
do
you
indicate
that
at
the
application
Level
when
the
application
Level
is
a
bit
obfuscated?
A
So
artelius
is
pulling
this
information
creating
these
Federated
insights,
including
microservice
versions,
which
then
can
provide
logical
application
versions?
If
we
know
that
the
applications
for
using
the
microservice,
we
could
obviously
create
a
blast
radius
for
a
microservice,
so
we
know
who
it
impacts.
We
can
also
show
the
difference
between
two
application
release:
candidates
based
on
a
change
at
the
microservice
level.
We
can
track
the
inventory
create
logical
application
s-bombs,
because
we
can
aggregate
that
information
up
as
well
as
a
logical
application
vulnerabilities
we
can
track
drift.
A
Show
differences
between
environments,
show
the
ownership
of
applications,
the
application
of
microservice
dependencies
and
super
important.
We
can
centralize
the
OS
search
packages,
so
we
can
do
a
centralized
search.
So
look
for
log
for
J
in
one
place,
so
how
does
it
work?
Well?
First,
a
producer
of
a
service
registers
their
service
to
the
the
ortillas
catalog.
Now
we
are
working
on
a
backstage
integration.
If
you're
a
backstage
user
user,
we
I
will
soon
be
able
to
pull
that
information
from
backstage.
A
Once
that's
done,
the
application
team
can
Define
through
the
user
interface
or
through
a
Tomo
file
what
their
application
consumes.
So
they
can
say
this.
We
want
to
create
a
baseline
version
of
our
our
application.
This
is
what
we
know
the
application
uses
now
over
time.
The
service
the
services
under
the
covers
will
change
and
that's
what
creates
new
versions
of
the
consuming
application.
A
So
if
a
microservice
changes-
and
it
has
a
new
version
as
collected
by
artillius,
then
The
Logical
applications,
not
just
one,
but
any
application
that
consumes
that
service
is
going
to
get
a
new
a
release
candidate
or
a
new
version
number.
So
now
the
application
teams
know
that
something
changed
and
they
have
a
new,
a
new
release.
Candidate
and
along
with
that
new
release.
Candidate
comes
s-bombs
and
new
vulnerabilities,
new
Swagger
information
and
a
whole
lot
of
other
things.
A
The
results,
though,
is
we
can
start
tracking
the
blast
radius
of
these
components
and
how
they're
moving
across
the
the
devops
pipeline.
We
can
generate
those
application,
Level,
s-bombs
and
understand
the
application
component
dependencies
or
the
dependency
the
microservices
dependencies
that
they
rely
on
now,
let's
just
step
through
quickly
how
it
works.
This
is
a
lightning
talk,
so
I'm
going
fairly
fast
of
all,
as
I
indicated.
If
you
are
a
API
or
microservice
developer,
you
register
your
microservice
to
artillius.
A
Now
you
can
do
that
with
a
Tama
file
or
you
can
do
it
manually
or
potentially
we'll
be
able
to
do
an
integration
with
backstage
to
get
that
done
when
you
register
at
the
initial
time
you
register
it,
we
call
it
the
base
version.
So
now
we
know
you
have
a
base
version
of
that
that
service,
but
as
that
service
changes,
we
start
tracking
versions.
So
that's
how
the
Microsoft
microservice
versioning
comes
into
play
now,
if
you're
an
application
team,
you
also
create
a
base
version
and
you
create
a
base
version
of
the
applic.
A
Now,
once
we
begin
tracking
these
changes,
then
we
have
both
microservice
versions
and
application
versions.
Each
time
a
microservice
changes,
a
component's
updated,
a
new
application
is
created.
So
now
we
begin
a
Cadence
now
there's
data
that
we
pull
when
we
do
that
when
we
have
a
new
microservice
update,
we
start
pulling
it's
at
the
its
software
composition
analysis
so
that
we
can
aggregate
that
data
up
to
The
Logical
level,
so
for
each
service,
we're
going
to
pull
in
the
readme
information,
the
cves,
the
the
license,
consumption,
the
s-bomb
data.
A
Basically-
and
even
your
Swagger
information,
if
you,
if
you
choose
to
provide
that
to
us
now,
ortelius
does
its
work.
It
says:
okay,
I
have
a
version
of
a
microservice,
that's
new!
It's
got
a
new
s-bomb.
It's
got
a
new
cve
I'm,
going
to
aggregate
that
up
to
every
logical
application.
That's
dependent
upon
that
at
that
that
microservice
and
when
I,
do
that
I'm
going
to
generate
a
consolidated
s-bomb
at
the
application,
Level
and
I'm,
going
to
show
all
of
the
vulnerabilities
now
in
a
Consolidated
way.
A
So
now
the
application
team
has
insights
on
how
their
application
is
changing.
Over
time,
even
when
they
are
not
the
ones
making
the
changes-
and
this
happens
in
a
microservice
architecture
when
microservices
are
proper,
properly
reused
across
teams
as
opposed
to
constantly
being
recreated
or
copied.
A
Thank
you.
So
much
I
hope
that
gives
you
some
insights
on
what
we're
doing
at
artillius
to
help
it
organizations
begin
consuming
and
using
s-bomb
data.
It's
critical,
it's
the
the
core
of
starting
zero
trust
policies
and
just
policies
in
general
and
how
your
your
supply
chain
is
managed
within
your
organization
at
each
application
and
microservice
level.
A
If
you're
interested
in
helping
out
we'd
love
to
have
you
visit
us
at
ortilius.io,
you
can
follow
us
on
Twitter
or
you
can
follow
me.
I
am
at
Tracy
Reagan.
You
can
find
me
on
LinkedIn
at
Tracy,
Dash,
Reagan,
Dash,
OMS,
and
if
this
is
something
you
want
to
chat
about,
I
am
always
happy
to
talk.
You
can
reach
me
at
this
at
this
calendar
link.
If
you
can
find
that
on
the
deployhub.com
website.
Thank
you.
So
much
and
I
hope
everybody
has
a
fabulous
holiday.