►
From YouTube: Ortelius Demo - A Supply Chain Security Dashboard
Description
Steve Taylor provides a look at the DeployHub Dashboard, powered by Ortelius. See how Ortelius tracks #SBOM data, aggregates the data to the logical application level based on consumed components, and builds a dashboard of security details.
A
A
A
And
one
of
the
things
that
we
do
is
we
look
at
the
the
world
through
basically
three
types
of
objects,
so
we
have
our
our
applications
and
applications
are
composed
of
components
and
then
components
have
packages
so
npm
packages
rust
packages,
that's
kind
of
the
the
lowest
level
that
we
dive
into
now
at
the
component
level,
you
can
have
different
types
of
components.
What
we're
going
to
be
looking
at
today
are
going
to
be
basically
Docker
images
that
have
been
built
through
from
source
code.
A
They
created
a
doc,
an
image
this
one
I,
don't
remember
when
I
dive
into
it.
We
can
tell
what
it
is,
but
at
that
point
we
don't
really
care
about
the
language,
but
the
things
that
we
do
care
about
from
our
point
of
view
is:
when
was
that
image
created
who
created
it?
How
do
we
get
to
the
the
build
logs,
since
this
is
an
image
that
we're
talking
about?
Where
was
it
eventually
pushed
through
the
digest
and
all
those
fun
things,
and
then
we
get
into
the
commit?
B
So
this
is
good,
but
why
I
like
the
commit
is
because
increasingly
there's
no
way
for
me
to
actually
mitigate
and
verify
if
someone
has
used
like
AI
generated
Snippets
we're
talking,
the
logic
is
fine,
but
maybe
there's
a
part
of
that
logic,
which
is
an
executional
vulnerability
and
now
I'm
by
a
large
organization.
I
would
have
to
be
asked
to
scan
line
by
line
of
your
source
code
just
to
make
sure
we
mitigate
potential
vulnerabilities.
B
A
A
The
next
part
is
what
we
call
the
variant,
so
you
can
think
of
as
a
feature.
This
usually
typically
is
derived
from
the
branch
that
you're
on
then
the
schematic
versioning.
Then
we
just
tack
on
the
commit
again
just
for
convenience
sake.
The
last
Parts
is
not
not
needed,
but
it
is
just
helps
pop
things
out
without
having
to
dive
too
deep
into
that
world.
A
So
every
time
you
do
a
build
you
and
you
create
a
new
component,
a
new
artifact
you're,
going
to
end
up
creating
a
new
component
version,
so
we
do
have
a
CLI
that
we
plug
into
your
pipeline
process
that
happens
after
the
artifact
is
created.
It
may
happen
before
it's
like
pushed
to
like
artifactory
or
Nexus
or
over
to
your
Docker
registry.
It
just
depends
on
the
nature
of
the
Beast
Docker
Docker
images.
A
You
can't
get
the
digest
until
it's
actually
pushed,
so
you
have
to
actually
wait
for
that
push
to
complete
before
we
can
grab
the
the
appropriate
digest
and
now
this
is
all
versioned
other
things
that
we
associate
at
that
time
are
going
to
be
like
the
service
owner.
Any
of
the
you
know
the
slack
Channel
some
of
this
detail
over
here
can't
be
derived,
so
we
have
a
basically
a
toml
file
that
the
developers
Supply
us.
That
say
this
is
the
who
the
owner
is.
A
A
The
other
things
that
we're
able
to
grab
out
of
the
the
pipeline
process
is
what's
the
readme
and
the
Swagger
if
they
exist
also
the
license
file,
which
is
down
here
a
little
bit
that
is
used
for
this
component,
any
key
value
pairs
that
come
into
play
that
we
want
to
persist
with
this
version,
because
the
reason
why
this
is
important
is
you
can
have
the
same
component
act
differently
based
on
the
key
value
pairs.
So
we
need
to
know
what
those
are
as
well.
A
Then,
of
course
the
s-bomb.
We
are
not
an
s-bomb
tool,
but
we
do
consume
them.
So
in
this
case
we
ran
sift
as
part
of
the
the
pipeline.
It
generated
the
the
Cyclone
GSN
file
and
we
consume
that,
whether
it's
Cyclone
or
spdx,
it
doesn't
matter
to
us.
We
just
are
able
to
consume
either
format,
and
that
gives
us
yeah
I.
B
A
B
B
One
of
the
things
that
I
find
useful
is
having
the
information
like
the
numerics
around
what
your
not
slas
but
like
slos,
are,
and
if
you
can
like
last
deployments,
slis
and
I
like
seeing
that
specifically
for
SRE
and
for
cyber
security,
I
would
like
to
be
able
to
see
that
I.
Don't
know
if
that's
information
that
can
be
derived
here
but,
for
example,
I'd
like
to
know
like
did
we
intake
known
vulnerabilities
in
our
last
s-bomb
and
were
there
any
any
consequences
in
that
over
the
last
one
two
three
months?
A
And
I'll,
sh
and
I'll
show
you
exactly
how
we
get
to
that.
So
this
version
of
the
the
our
component
doesn't
have
any
vulnerabilities,
so
we
actually
cross-reference
our
s-bomb
with
osv
Dev,
basically
in
real
time.
So,
if
a
new
vulnerability
is
found
in
hibernate
tomorrow,
it
would
show
up
so
the
vulnerability
list
is
more
Dynamic.
The
s-bomb
is
versioned
with
this
component
and
I'll.
Show
you
why
we
do
that
down
the
road.
Some
of
the
other
things
that
we're
able
to
gather
are
who's
consuming
us.
A
So
we
have
a
concept
like
I
said
at
the
beginning,
components
are
packaged
together
into
applications,
so
this
component
is
being
consumed
by
this
application
version.
So
not
only
do
we
do
versioning
at
the
component
level,
but
we
also
do
it
at
the
application
Level.
Other
data
that
we
are
extending
out
and
that
we're
going
to
be
Gathering
are
more
of
the
things
around
like
the
the
open,
ssf
scorecard
things
like
your
fuzzing
number.
A
You
know
your
branching
profile
for
your
your
git
repo,
those
type
of
metrics
we're
going
to
be
consuming
as
well
and
adding
them
to
this.
Our
component
version
things
like
the
git
commit
signing
signed
off
by
those
things
are
going
to
be
added
as
well
as
part
of
this,
and
it
also
depends
upon
that.
The
s-bomb,
if
there's
any
signatures
or
assetations,
that
we
need
to
consume,
we'll
be
adding
that
as
well.
A
It's
one
of
these
things,
you
know
the
the
chicken
versus
the
egg,
we're
just
setting
it
up.
So
when
that
data
starts
becoming
available
to
us,
we
can
start
capturing
it
and
displaying
it.
We
have
a
new
version
in
the
works
and
that
new
version
is
we've
extended
upon
the
data
model
drastically
together
those
type
of
that
type
of
information.
A
Now
one
of
the
things
because
we're
versioning
everything
we
can
actually
compare
and
see
what's
happening
at
that
between
two
different
versions
at
the
component
level.
So
in
this
case
the
older
version
I
picked
didn't
have
an
s-bomb
associated
with
it,
where
the
one
on
the
left
did,
and
we
can
see
the
different
where
things
came
from
and
one
was
off
a
master
versus
main
that
type
of
information
I
actually
have
another
component.
A
A
So
this
is
where
developers
clean
up
their
code,
their
package
dependencies.
This
allows
us
to
really
see
how
things
are
Drive
changing
over
time
and
as
a
result,
we
can
actually
see
that
the
old
version
had
all
these
cves
that
were
being
exposed,
and
now
the
developers
have
actually
resolved
those
with
updating
their
package
dependencies.
They
may
not
have
necessarily
changed
any
of
their
code,
but
you
know
basically
did
a
dependency
update
and
they're
able
to
bring
in
a
cleaner,
fixed
versions
of
the
packages.
B
A
A
So
one
of
the
things
that
we
need
to
know
is
what
what
does
an
application
look
like
so
in
our
world,
when
you
get
into
microservices,
you
have
many
little
things
running
all
over.
We
bring
those
together
as
a
logical
view,
so
our
dependency
list
here
is
about
a
dozen
microservices
at
the
at
this
logical
application
view
we
are
rolling
up
all
of
the
the
s-bombs
up
to
The
Logical
application.
B
B
Me
through
these
so
I
have
two
quick
questions
on
this,
so
it
looks
like
if
I'm
understanding
that
graph
at
the
bottom
there
that's
like
just
like
source
code
dependencies.
There
was
an
interesting
thing
from
sonotype.
It
was
a
like
temporary
release
thing,
but
was
public
where
they
did
a
thing
called
bomb
doctor
where
it
was
a
graphical
analysis
of
the
vulnerabilities
and
would
show
you
where
you
should
take
the
next
action
and
at
what
layer
like
would
fixing
a
Upstream
dependency
within
your
code
base,
be
the
most
efficient
use
of
time.
B
That
was
really
helpful,
because
that
list
I
mean
it.
The
problem
with
an
anti-pattering
that
I
can
get
into
with
this
kind
of
visualization
is
the
lack
of
understanding
from
the
end
developer
of
zero
day
resolution
and
preventative
resolution,
so
doing
the
highest
risk
highest
importance
activity
with
their
time
to
prevent
security
right.
A
We
are
going
to
be
extending
out
the
package
dependencies
into
this
graphical
View
and
then
also
we
had
a
meeting
earlier
this
week
with
the
Clock
Team
and
with
their
basically
their
their
package
dependency
tree.
That
would
be
able
to
that
we're
going
to
link
into
through
their
graphql
to
be
able
to
do
like
what
you're
talking
about
if
I,
if
I
have
this
vulnerability
and
I
fix
this
I
get
this
bang
I
get
this
Bigger
Bang
for
my
buck
type
of
resolution.
A
So
if
we
go
ahead
and
look
at
the
oops,
let's
look
at
the
comparison
here,
so
we're
comparing
two
different
two
different
versions
of
the
application,
and
one
of
the
things
that
we
recognize
is
not
everything
changes
all
the
time.
So
actually,
in
software,
a
lot
of
stuff
becomes
static,
but
we
do
have
new
things
that
pop
up.
So
in
this
case
the
one
on
the
left.
We
actually
added
a
node.js,
a
whole
world,
node.js
service
that
wasn't
in
the
the
other
version
and
that
a
low
World
node.js
actually
has
a
few
dependencies.
A
The
other
thing
that
changed
was
our
shipping
service.
We
basically
changed
the
the
variant
that
we're
using
on
that
one.
So
we
did
have
a
change
at
two
services
that
actually
changed
the
one
that
is
most
impactful.
It
was
the
node.js
one,
and
these
are
all
the
package
dependencies
just
to
run
hello
world.
A
Not
yet
we
have
not
taken
gotten
to
that
Point.
What,
where
we're
at
right
now
is
trying
to
gather
the
data
and
kind
of
consolidate
it
into
a
dashboard,
and
the
next
step
would
be
able
to
do
like
you
said
the
recommendations
you
know
this
is
what
you
need
to
do
for
this
is
your
next
step
for
addressing
this
vulnerability.
If
you
fix
this,
this
Upstream
package
dependency,
then
you're
going
to
fix
all
these
other
vulnerabilities
as
well.
A
The
same
thing
goes
with,
like
you
said
you
know,
being
able
to
help
developers
and
your
your
security
profile
stance
on
what
direction
you
need
to
take
yeah
and
this
a
lot
of
this
data.
Once
we
started
collecting
it
and
kind
of
making
it
available
to
folks,
then
we
can
get
into
the
mlai
world
where
those
those
types
of
Technologies
actually
have
data
to
work
against
right
now,
it's
kind
of
dispersed-
and
you
know
we're
in
the
process
of
gathering
things
together.
B
So,
like
you
can
choose
selectively
the
right
data
to
put
into
this
dashboard
that
doesn't
like
you
got
to
take
your
head
out
of
remediation
because
we
can
get
the
data.
It's
really
strong.
If
you
get
the
right
data
for
those
OS
packages
you
consume,
you
can
use
that
as
a
way
to
measure
how
much
time
you
don't
spend,
which
is
interesting
consideration
there.
A
A
And
that's
one
of
the
things
that
we're
going
to
be
looking
at
is
bringing
in
the
the
scorecard
the
ossf
scorecard
for
each.
Basically,
you
know
we
will
we'll
add
a
column
for
each
one
of
the
checks
in
the
scorecard
whether
you
have
fuzzing
turned
on
whether
you
have
your
branch
protection
turned
on.
You
know
all
those
are
going
to
be
added
this.
A
Our
current
scorecard
right
now
is
being
driven
by
one
of
our
customers,
so
they
wanted
to
know
things
about
their
tool:
integration
about
cert
sonar
and
Vera
code,
whether
they're
this
kind
of
comes
into
the
salsa
model.
Is
there
their
bills
being
triggered
automatically
or
somebody
going
out
there
running
them
manually,
but
then
another
interesting
one
that
they
wanted
us
to
add
was
because
they
are,
they
hire
Consultants
to
do
a
lot
of
their
work.
A
A
There's
there's
ways
to
get
around
it.
You
know
we
don't
go
and
say
that
this
person
did
500
lines
of
change,
change
the
lines
of
code
and
this
other
person
did.
You
know,
added
a
new
line
character.
We
can't
distinguish
at
this
point,
but
just
to
get
a
rough
estimate,
we're
able
to
look
at
the
total
number
of
committers
that
are
assigned.
A
So
what
we
do
is
we
actually
go
through
and
look
at
the
basically
do
a
git
log
and
find
all
the
committers
that
are
that
have
committed
either
during
a
date
range
or
on
a
specific
branch.
And
then
that
gives
us
gives
us
our
our
number
of
committers.
And
then
this
is
one
of
those
numbers.
The
total
committers
has
to
be
supplied
to
us
that
were
assigned
to
that
that
project
or
that
that
team
to
work
on.
A
Other
things
that
were
like
we
were
looking
at
the
Swagger
and
read
me
whether
those
are
available,
and
then
we
get
into
deployments
so
the
on
the
back
end
side
of
things.
We
want
to
know
where
things
were
deployed
to
so
we
have
another
hook
into
the
deployment
process.
That
lets
us
know
that
this
application
version
went
to
this
QA
kubernetes
cluster,
for
example.