►
Description
Ortelius connects to your CI/CD Pipeline to automatically gather supply chain and DevOps Intelligence into a central 'Evidence Store' for the data to be consumed and acted upon. Steve Taylor shows us how to implement the Ortelius CLI to connect to your pipeline including the generation of SBOM data.
A
A
So
one
of
the
first
things
we
need
to
do
is
to
have
a
version
of,
or
until
you
see,
they're
running
locally
or
we're
going
to
go
ahead
and
use
the
PlayHub
team
version.
So
if
we're
going
to
run
things
locally,
we
can
go
over
to
artifact
Cobb,
just
type
in
artillius,
in
the
search
bar
and
we'll
be
able
to
get
the
Helm
charts
to
install
locally
in
the
instructions
I'm
actually
going
to
go
ahead
and
run
everything
I'm
going
to
set
up
an
account
with
the
deploy,
Hub
team
and
I'm
going
to
do
that.
A
A
A
And
I'll
use
my
very
secure
password
that
you'll
see
later
and
I'm
going
to
go
ahead
and
hit
sign
up,
get
rid
of
all
those
screens
and
that's
going
to
go
ahead
and
get
us
over
to
an
account
over
on
the
deploy.
Hub
team
SAS
version.
That's
going
to
take
a
few
minutes
to
get
created.
So
in
the
meantime,
we're
going
to
go
back
to
our
documentation
and
one
of
the
things
that
we're
going
to
need
to
do
is
install
the
CLI
locally.
A
So
I'm
going
to
install
the
CLI
actually
uses
Python
and
it's
actually.
The
package
is
hosted
on
Pi
Pi.
So
if
we
go
and
do
a
search
for
artillos
here,
we'll
see
that
we
have
the
artillery
CLI
and
the
details
about
all
the
flags
and
stuff
like
that
and
all
the
it's
basically,
the
readme
for
the
CLI
that
we
use
and
here's
going
to
be.
The
install
and
I
actually
happen
to
be
using
both
versions
of
python.
A
A
So
that
went
out
to
out
to
Pi
Pi
and
brought
down
our
latest
version
here
of
our
package,
so
the
93222
should
be
the
version
that
we
just
downloaded
from
over
here
so
now,
I
have
my
local
environment.
All
set
we're
going
to
need
some
code
to
work
with
so
I'm,
going
to
take
a
spring
boot
demo
and
I'm
actually
going
to
Fork
it
and
I'm
going
to
use
that
as
our
repo
that
we're
going
to
pull
information
from
now.
This
can
be
any
repository.
A
A
All
right
so,
like
I
said
this
is
a
spring
boot
that
has
been
wrappered
up
into
a
Docker
file.
So
if
we
actually
look
at
the
docker
file,
we'll
see
where
they
actually
do,
the
maven
build
create
the
jar
file,
and
then
we
go
ahead
and
run
with
that
from
that
level.
You'll
see
here
that
we
just
have
the
source
code
down
in
our
lower
levels.
Some
test
cases
there's
nothing
to
do
with
our
like
a
get
action,
a
GitHub
action
or
anything
to
do
with
artillius.
A
A
So
some
of
the
information
that
we
needed
to
kind
of
expose
from
the
pipeline
side
is
going
to
be
the
the
deploy
the
URL,
the
user
ID
password
the
name
of
the
repository
the
image
tag,
those
type
of
things
we
need
to
go
ahead
and
push
over
and
make
available
so
I'm
going
to
create
a
little
shell
script
here,
grabbing
this
information.
So
if
I
go
back
to
my
Visual
Studio
I'll
do
a
new
file
dhenv.sh.
A
A
One
of
the
things
that
we
need
to
do
is
provide
two
ortillas,
the
information
that
we
can't
derive
from
the
pipeline,
and
that
includes
from
the
git
repo
from
the
pipeline
process
itself
from
other
tools
that
maybe,
as
part
of
the
pipeline,
let's
see
if
you're
running
like
varicode
or
something
like
that,
and
we
want
to
pass
across
Vero
code
results
over
into
ortilius.
We
need
to
do
that.
A
It's
using
a
toml
file,
so
this
time
will
file
basically
is
going
to
allow
us
to
Define
that
non-derived
data
and
some
of
that's
going
to
be
like.
What's
the
name
of
the
application,
the
version
of
the
application?
What
do
we
name
our
component,
because
when
we
get
into
microservices
World
we're
going
to
have
many
microservices
that
make
up
a
single
application,
so
we're
going
to
have
multiple,
a
component
toml
file
for
every
single
microservice?
Basically
so
I'm
actually
going
to
go
here.
Grab
the.
A
I'm
going
to
put
that
in
now,
when
we
signed
up,
we
were
we
did
the
our
company
name,
our
project
name
and
then
from
there.
We
need
to
build
that
out
as
part
of
the
domain
structure,
so
I'm
gonna
go
ahead
and
log
back
in
over
on
the
deploy
Hub
side
into
that
account
that
we
created
and
grabbed
that
information.
So
when
we
created
our
our
highest
level,
we
have
a
global
and
then
our
spring
demo
and
then
our
hello
world
at
that
level.
A
So
that's
going
to
be
kind
of
our
our
domain
structure
is
going
to
be
that
lowest
level.
So
that's
what
I'm
going
to
copy
that
domain
I
can
grab
it.
Now,
that's
going
to
be
part
of
where
we're
going
to
put
our
application,
and
so
that
beginning
part,
is
like
the
folder
structure
and
now
we'll
go
ahead
and
call
it
our
Hello
World
app
and
we're
going
to
use
version.
A
A
As
the
feature
Branch
next
I'm
going
to
go
ahead
and
give
it
a
the
component,
the
microservice
itself,
a
version
as
well
so
I'm
going
to
go
ahead
and
kind
of
tie
it
to
the
application
version,
so
we're
going
to
do
V100
and
then
we're
going
to
take
the
build
number,
and
this
would
be
the
build
number
coming
from
the
pipeline
tool.
So
we're
actually
going
to
because
we're
going
to
run
this
locally.
A
So
the
dash
G
is
just
a
placeholder
and
then
we're
going
to
take
the
shorts
off
from
the
git
repo
other
things
that
we're
going
to
add
to
this
we're
going
to
go
ahead
and
grab
the
set
the
docker
build
date.
The
docker
repo
determine
the
digest
image
tag
if
we
have
like
a
any
service.
Catalog
data,
like
in
case
in
this
case
we're
going
to
use
a
Discord
channel
the
service
owner,
the
service
email.
A
If
we
had
like
I,
said,
like
Vera
code
information
other
metrics,
that
we
want
to
gather
and
attach
to
this
version
of
the
component,
we
would
go
ahead
and
add
on
to
that
attribute
list.
The
attributes
can
be
anything
there
are
certain
ones
that
we
do
look
for.
So
if
we
actually
go
back
over
to
Pi
Pi
here,
we'll
see
that
there's
a
set
of
attributes
that
we
are
actually
go
ahead
and
and
gather
and
grab
automatically
so
in
the
in
the
toml
file
I'm
not
going
through
and
defining
every
single
variable.
A
If
we
had
a
chart
to
deploy
this,
we
would
want
to
put
the
chart
name
in
there.
Some
of
that
information.
We
would
want
to
go
ahead
and
give
to
ortilius
that
we
can't
drive.
You
can't
really
derive
the
chart
very
easily.
So
that's
one
of
those
supplied
values,
things
certainly
like
the
docker
and
the
git.
Most
of
those
we
can
drive
by
running
commands
against
the
git,
repo
and
Docker
commands
to
find
out
what's
happening
on
that.
A
Also,
if
we
have
a
license
in
that
repository,
we
would
go
ahead
and
pull
in
that
license.
To
read
me
if
there's
an
open,
API
or
Swagger
file
we'd
want
to
give
that
information
as
well
again.
This
is
just
some
of
the
the
default
information
that
we
gather.
You
can
add
anything
you
want
to
that
key
value
pair
attributes,
so
let's
go
ahead
and
save
that
and
we'll
go
ahead
and
build
that
should
go
pretty
quick.
So
this
is
your
Docker.
A
Build
normally
would
be
done
in
your
pipeline
process
here
we're
just
doing
manually
to
get
a
Docker
image
that
we
can
then
scan
at
that
level.
We
can
see
that
we
have
our
image
here
that
we
just
created
30
seconds
ago,
so
we're
actually
going
to
go
ahead
and
scan
that
image
for
the
s-bomb
data
in
order
to
do
that,
we're
actually
going
to
use
another
third-party
tool
called
sift
sift
is
from
Encore.
They
do
a
pretty
good
job
of
scanning
images
and
search
code
directories,
and
things
like
that.
A
So
I'm
going
to
just
go
ahead
and
run
the
install
here
to
generate
the
s-bomb,
we're
going
to
take
the
the
docker
repo
and
tag
we're
going
to
look
at
all
the
layers,
and
you
can
scope
this
just
to
like
the
latest
layer
or
the
top
layers
for
getting
dropping
off
the
the
ones
that
you're
built
from.
But
we
need
some
data
so
we're
going
to
scan
all
theirs
and
we're
going
to
Output
to
the
Cyclone
DX
format.
A
We
can
use
Cyclone
DX
or
the
spdx
format.
The
Cyclone
DX
is
I
like
it,
because
it's
a
little
bit
easier
to
understand
the
Json,
it's
not
as
confusing
as
the
spdx
Json
layout.
If
we
go
back
to
visual
studio,
we
have
our
cycle
and
DX,
so
we're
actually
going
to
go
ahead
and
pass
all
this
information
over
to
our
to
this.
Now
it's
a
simple
command.
A
So
that's
going
to
be
the
one
that
we're
going
to
run
if
you
generated
it
with
spdx,
then
you'd
use
the
spdx
prefix
or,
if
you
didn't,
if
you
skip
that
step
around
the
s-bomb,
then
you're
just
going
to
go
ahead
and
run
this
example
here.
So
let's
go
ahead
and
run
our
Command
up.
First,
we
need
a
build
number.
So
if
you
remember
back
in
our
toml
file,
we
created
a
build
number
or
we're
going
to
use
a
build
number,
because
we
don't
have
we're
not
running
in
the
context
of
a
pipeline.
A
At
this
point,
we
need
to
make
up
a
build
number.
So
we're
just
going
to
say
it's
going
to
be
build
number
one.
One
of
the
next
steps
we're
going
to
do
is
we're
going
to
take
and
resolve
all
the
variables.
So
anything
in
the
curly
brackets
is
a
variable
like
the
Sha,
the
branch,
all
this
information
and
we're
going
to
go
ahead
and
and
resolve
all
that
that
those
details-
and
this
is
mainly
because
we're
running
locally,
but
it
doesn't
hurt
to
have
an
the
extra
step
of
the
environment
variable
resolution.
A
Okay,
so
one
of
the
things
we're
going
to
do
is
we're
going
to
generate
another
shell
script
that
is
going
to
resolve
a
lot
of
the
environment
variables.
So
anything
in
the
curly
brackets
is
an
environment
variable
that
the
sh
I
mean
the
the
short
shot,
the
get
Branch
the
digest
image
tag
we're
going
to
go
through
and
resolve
all
those
variables
and
make
them
grab
the
values
from
like
the
git
repo,
those
type
and
Docker
to
get
those
variables
resolved.
A
A
So
we
found
at
this
level
we
have
our
sh
file.
So
if
we
go
back
over
to
visual
studio-
and
we
can
see
all
those
information
like
the
git
Branch,
the
docker
repo,
the
license
file,
all
those
have
been
resolved
and
what
I'm
going
to
do
is
I'm
just
going
to
source
that
in
before
I
run
our
final
step
of
sending
all
the
information
up
to
artillius.
So
I'm
going
to
source
resolved.
A
A
A
One
of
the
things
that
didn't
did
not
get
resolved
was
the
digest
and
the
reason
for
that
being
unresolved
is
we
did
not
push
the
docker
image
up
to
Docker
Hub.
The
only
way
you
get
a
digest
in
in
the
docker
world
is
to
actually
put
push
it
up
to
a
registry
and
then
query
the
registry
about
what
the
digest
is
not
going
to
worry
about
that
now,
because
when
we
move
over
to
doing
all
this
in
a
pipeline
process,
that
variable
actually
be
resolved
because
we
actually
push
our
image
somewhere.
A
Next,
we
created
our
parent
component
and
then
we
created
our
our
individual
version
of
our
microservice.
So
this
is
where
we
remember,
we
had
our
version:
zero,
zero,
zero
one
is
one
zero
zero,
our
build
number
followed
by
the
getcha,
so
that
was
created
and
then
all
the
other
attributes
that
we
were
able
to
derive.
A
So
some
of
the
things
that
we're
able
to
figure
out
was
like
the
git,
commit
authors
number
committers
on
the
repo
the
lines
deleted,
those
type
of
things
we're
able
to
gather
and
Associate
to
our
microservice
version
and
finally,
we
go,
went
and
added
our
component
version
to
our
new
application
version.
So
if
we
go
back
over
to
our
team
version
here,
we
can
see
I
got
our
Hello
World
app
and
our
version
zero.
A
And
we
have
our
microservice
as
one
of
our
dependencies
and
then
the
s-bomb
that's
being
aggregated
up
from
all
of
the
individual
components.
So
in
this
case
we
only
have
the
one
component
so
that
one
component
ended
up
having
a
lot
of
dependencies
and
we
can
actually
see
that
one
of
the
dependencies
that
yaml
the
libmeaml
actually
has
a
cve
that
we
need
to
address
at
that
level.
A
So,
if
I
actually
go
into
the
component
level,
we
can
see
we
have
our
base
component,
followed
by
our
microservice
component
and
again
we're
going
to
have
that
same
level
of
detail
around
the
information
that
we
gathered
like
I
said.
This
is
where
that
digest
was
unresolved.
That
will
get
fixed
when
we
go
actually
go
ahead
and
do
our
plug
into
a
GitHub
action.
A
Other
things
that
we're
able
to
drive
the
git
commit
the
repo
the
tag
the
get
URL.
We
were
able
to
pull
in
the
readme
file,
this
serviced
in
Hemi
Swagger
information.
So
we
didn't
upload
any
Swagger.
Here's
our
s-bomb
data
again
with
our
individual
vulnerability,
the
license
file
that
was
grabbed
and
then
additional
attributes
that
we're
able
to
grab
so,
like
I,
said
the
the
lines
added
deleted.
Total
the
repos
details
about
that
information
as
well.
A
We
can
see
the
consuming
application,
is
the
Hello
World
app
and
we
should
be
able
to
see
our
map
our
association
here
at
that
level.
So
at
this
point,
we've
actually
gone
through
and
created
a
component
in
an
application
version
in
a
few
short
steps
within
our
local
environment.
Now
our
next
step
is
we're
going
to
actually
go
ahead
and
do
this
through
a
pipeline
okay.
A
So
our
next
step
is
going
to
be
creating
a
GitHub
action
that
will
do
everything
that
we
did
at
the
command
line,
so
we'll
set
the
environment
variables
in
the
action
and
then
we'll
go
ahead
and
run
the
sift
along
with
the
ortilia
CLI
commands
to
upload
the
information
over
to
artillius,
so
I'm
going
to
go
ahead
and
just
copy
a
file
that
I've
done
earlier,
just
to
save
some
typing
and
we'll
walk
through
it.
So
let
me
go
ahead
and
copy
this
over.
A
A
One
of
the
first
things
we're
going
to
do
is
we're
going
to
check
out
the
basically
clone
the
repo
and,
after
we
clone
the
repo
we're
going
to
do
a
couple
kind
of
like
housekeeping
things
in
the
GitHub
world.
The
way
you
pass
things
around
is
through
this
get
GitHub
EnV
file.
So
what
we're
going
to
do
here
is
we're
going
to
derive
the
image
version
from
GitHub
itself,
so
the
image
version
will
be
one
of
the
info,
one
of
the
information
that
will
drive
and
pass
along
in
the
component
Tamil.
A
This
is
one
of
those
default
variables
that
we're
going
to
go
ahead
and
grab
and
we're
also
going
to
use
the
image
version
environment
variable
later
in
this
workflow.
So
this
is
looking
at
the
GitHub
Road
number,
getting
the
shot,
cutting
it
down,
so
it's
a
short
shot
instead
of
the
long
one,
and
then
we're
going
to
drive
the
image
tag.
A
Next,
we're
going
to
actually
just
going
to
set
up
some
git
stuff,
so
it
doesn't
complain
about
us
doing
anything
without
a
user,
ID
or
email.
So
that's
just
some
housekeeping
there.
Next
we're
actually
going
to
log
into
Quay,
so
we
can
push
our
image
over
to
our
Quay
Repository
again.
The
the
user
ID
password
normally
would
be
set
like
we
do
here
in
a
secret
instead
of
having
exposed
in
the
workflow
itself,
so
we'll
actually
get
flagged
about
a
user
ID
password
from
a
security
scan.
A
A
A
So
out
of
all
this,
all
we're
really
adding
on
to
it
is
just
a
another
step
into
our
pipeline
process.
Instead
of
doing
really
it's.
If
we
want
to
s-bomb
in
the
artillius
CLI,
it's
two
little
steps
that
we
had
in
this
case
we're
going
to
go
ahead
and
install
our
CLI
pip
3
is
the
default
on
GitHub
actions
that
sock
and
we're
using
pip
versus
pip3.
We're
going
to
run
and
resolve
our
all
of
our
environment.
Variables,
expose
them
up
and
then
do
our
upload
over
to
ortilia.
A
So
we're
going
to
take
that
same
component
hommel
that
we
did
before
and
we're
going
to
reuse
it
in
our
action.
One
of
the
things
we
need
to
do
is
set
up
our
secrets
over
on
the
GitHub
side,
so
we
can
go
ahead
and
log
in
over
and
make
sure
that
we
can
upload
to
Quay.
So
in
order
to
do
that,
I
have
to
do
one
step
on
the
GitHub
side,
which
is
assign
the
secrets
to
my
new
repository
that
I
forked.
A
A
And
if
you
click
on
the
details,
we'll
see
where
we're
at
okay
looks
like
our
s-bomb
has
been
finished,
yep
and
now
we'll
go
ahead
and
update
the
component
again
you're,
going
to
see
a
similar
thing
that
we
did
from
the
command
line
ourselves
outside
of
the
GitHub
action.
We're
going
to
have
our
information
about
our
component
and
we're
going
to
resolve
a
bunch
of
that
information
and
upload
the
details.
A
So
now
with
our
GitHub
action
finished.
If
we
actually
go
back
over
to
artillius,
we'll
see
that
we
still
have
that
same
application
version,
because
we
did
not
increment
the
application
version
as
part
of
our
process.
We
could
do
that
automatically
and
we
have
our
new
component
dependency
right
here.
So
let's
look
at
look
at
our
components
and
we
have
our
new
component
here.
A
And
we
can
see
more
details,
we
have
our
our
build
number
build
ID,
some
of
our
tags,
our
commits
again
we're
pulling
in
the
readme.
Everything
that
we
saw
from
the
command
line
is
again
being
pulled
in
automatically
as
part
of
that
process.
So
with
that,
we're
able
to
add
into
our
pipeline
process,
which
is
two
simple
steps,
we'll
step
here,
can
be
added
to
pretty
much
any
pipeline
tool
so
whether
you're
on
Jenkins
Google
Cloud
build
again
GitHub
actions.
A
If
you
have
Azure
pipelines,
we're
just
gonna,
be
adding
in
a
few
simple
commands
to
make
all
this
happen.
So
that's
how
we
get
the
information
from
your
pipeline
tool
through
the
or
to
the
CLI
and
grab
all
those
goodies
and
push
them
into
the
artillius
UI.
So
we
can
view
them
easily.
We
can
see
the
s-bomb,
the
vulnerabilities,
the
readme,
the
Swagger,
all
that
good
information
is
available
all
in
one
place
and
again,
that's
all
going
to
aggregate
up
to
the
application
Level
through
all
the
microservices.