►
From YouTube: Leveraging SBOMS to Automate Packaging, Transfer, and Reporting of D... Ian Dunbar-Hall & Jerod Heck
Description
Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Leveraging SBOMS to Automate Packaging, Transfer, and Reporting of Dependencies Between Secure Environments - Ian Dunbar-Hall & Jerod Heck, Lockheed Martin
Software Bill of Materials are being touted for tracking software build dependencies and security of a built application. Often delivered with built applications for transparency. In this talk we’ll explore a different use for Software Bill of Materials, where it is used as a packaging standard to validate and transfer assets across network boundaries. At Lockheed Martin, we’re using CycloneDX Specification to automate transfers into secure environments with strict controls to allow development teams to update build dependencies without network connectivity. We also use the CycloneDX Specification to create “seeding” deployments for Cloud Native infrastructure deployments. We’ll be demoing Hoppr, an open source tool with an extendable plugin architecture to do security validation and multi team transfers. It used CycloneDX SBOMs to collect items based on purls, run validation, and create transfers to be brought into these environments.
A
A
A
So
keep
an
open
mind.
I
think
the
premise
of
this
talk
really
revolves
around
one
concept.
You
know
we
hear
a
lot
about
s-bombs
over
the
over
the
week
and
we're
often
talking
about
it
as
a
build
artifact.
That's
something
that
you
made
through
through
analysis
with
trivia
or
sift
or
something
else,
and
it's
used
for
compliance
or
tracking
I'm
gonna.
Ask
you
to
just
think
about
it
slightly
differently,
think
of
it
as
a
packaging
definition.
A
So
we
have
this
kind
of
agnostic,
packaging
format
that
allows
you
to
specify
your
Pearl
and
that
Pearl
could
be
of
many
different
types.
So
when
we
talk
about
how
to
package
something
and
move
it
between
different
environments,
it's
really
nice
because
it
doesn't
necessarily
tie
you
to
one
specific
package
format,
not
necessarily
you
know,
say
the
requirements.txt
file
with
python
or
maybe
even
Gradle
file
for
something
in
the
Java
Realm.
A
So
what
is
our
problem?
Well,
it's
a
show
of
hands
here
who
here
has
worked
on
a
classified
or
other
secure,
environment,
yeah,
okay!
This
is
why
you
got
this
talk
so
number
one.
It
sucks
being
a
developer
in
a
disconnected
strict
environment
right
when
I
say
a
strict
environment,
I'm
talking
specifically
classified
or
some
sort
of
air
gaps
environment
where
you
don't
have
access
to
the
general
internet.
How
do
you
pull
in
your
package
dependencies?
How
do
you
get
them
updated?
Well,
what
do
you
do?
You
do
something?
That's
incredibly
slow
right!
A
A
A
Is
there
a
way
to
do
this,
where
you
have
a
common
workflow
for
multiple
teams
through
a
single
data
flow
right?
If
you
have
15
teams
working
in
a
strict
environment,
you
don't
want
them
all
doing
their
own
data
flow.
Synchronite,
neuron
disks
into
that
environment
and
often
you're
not
just
going
to
pull
things
out
from
the
general
internet.
You'll
want
to
collect
things
from
trusted
sources
within
an
intranet
or
something
like
iron
bank
or
some
other
trusted
Repository.
A
Well,
that's
where
Hopper
comes
in,
so
we're
gonna
be
talking
a
lot
about
Hopper,
it's
an
open
source
project
that
we've
been
working
on
and
it's
a
framework
for
defining
validating
and
transferring
build
dependencies
between
environments
using
software
build
materials
right.
So
for
us
we
are
heavy
users
of
cyclone
DX.
You've
heard
a
lot
this
week,
probably
about
the
executive
order.
A
Well,
if
we're
already
going
to
produce
them,
we're
already
going
to
make
them,
can
they
be
the
thing
that
we
use
to
to
move
stuff
between
environments
and
maybe
package
it
up
to
get
to
a
customer?
Hopper
provides
this
well-defined
solution
and
it's
repeatable
right.
We
have
s-bombs,
ideally
they're,
going
to
be
semantically
released,
and
then
you
can
reprocess
things
over
and
over
again
to
pull
stuff
in
so
I'm
going
to
talk
a
lot
about
Hopper,
but
there's
two
other
projects
that
are
pretty
key
to
this.
All
working
one
of
them
is
a
renovate.
A
So
if
you're
not
using
renovate
or
depend
about
highly
recommended
right,
you
get
a
tooling
out
there.
That
will
look
at
your
upstream
dependencies
and
tell
you
when
something's
changed
and
there's
a
patch
or
a
minor
or
a
major
update.
We
in-house
use
renovate
pretty
extensively
renovate
is
excellent
for
us,
because
it
does
that
it
goes
out
and
looks
at
python.
Packages
may
go,
look
at
them.
Even
Gradle
go,
doesn't
really
matter
and
it's
easily
configurable
for
internal
sources
too.
So
you
can
use
renovate
to
look
at
other
projects
and
say
GitHub
instance.
A
They
have
that's
private.
We
also
use
semantically
release
for
pretty
much
everything.
So
how
are
you
versioning
all
your
stuff?
Well,
semantic
version
is
probably
the
best
way
to
do
it
and
semantic
release
is
really
nice
for
us.
It
ties
in
really
well
to
our
pipelines.
So
at
the
very
beginning,
it
will
kind
of
parse
through
all
your
commit
messages
and
look
for
conventional
commits.
So
you
say,
like
fix
colon,
whatever
feature
colon
whatever
for
for
patches
and
for
minor
updates,
and
then
those
are
used
as
part
of
the
semantic
versioning
all
right.
A
Well,
let's
take
that
and
pair
those
two
together
right,
you're,
probably
not
handwriting
s-bombs,
you're,
probably
taking
again
I'm
going
to
use
Python,
but
like
a
requirements
that
text
file
and
using
maybe
the
Cyclone
DX,
tooling
and
generating
and
a
spawn
around
it.
Well,
let's
semantically
release
that
and
that
can
be
consumed
as
your
packaging
format,
to
bring
your
build
dependencies
across
that
environment.
A
A
A
The
big
thing
here
right
is:
if
you
have
these
s-bombs,
that
different
teams
are
producing,
they're,
all
being
updated
with
renovate
and
then
they're
semantically
released.
You
can
build
on
that
and
create
a
tree
inclusion
process
where
you
have
like
a
master
project
that
then
references
the
inputs
from
these
other
teams
that
could
reference
other
teams.
Maybe
you
can
have
a
generic
process
for
bundling
things
together
and
be
included
in
bigger
deliverables.
A
Well,
I'm
going
to
jump
over
this
diagram.
So
I
have
three
diagrams
here.
This
first
one
just
kind
of
talking
data
flow
I.
Don't
think
this
is
going
to
be
shocking
to
anyone.
If
you've
worked
in
this
realm,
we
typically
break
things
into
kind
of
three
three
areas.
You
have
general
internet
where
you
might
have
Docker
Hub
iron
bank
Quay,
other
sources
of
container
images,
and
then
you
have
multiple
package
repositories.
A
You
might
also
have
stuff
from
GitHub,
especially
if
you're
working
a
lot
with
go
more
Helm
charts
that
are
coming
from
from
collaborator
or
GitHub.
We
pull
things
into
internet
instances
for
proxy
caching
and
that's
where
we
do
a
lot
of
our
scanning.
We
look
for
security
and
other
types
of
vulnerability,
information
there,
and
then
we
probably
are
going
to
change
things
transfer
things
across
a
diode
using
a
gitlab
pipeline.
A
B
A
And
merge
any
any
git
repo
changes
Hopper.
As
that
thing
that
runs
in
a
pipeline
kind
of
has
a
couple
inputs
and
a
couple
outputs,
so
I
talked
a
lot
about
Cyclone
DXs
bombs
as
the
thing
that
defines
the
what
to
transfer,
but
that
doesn't
really
help
us
in
our
situation.
Right
if
I
just
give
you
an
s-bomb,
it
has
a
whole
bunch
of
pearls.
Well,
you
need
to
know
where
to
pull
things
from.
A
You
may
not
want
to
pull
things
up
from
the
general
Internet.
You
may
want
those
internal
raw
repositories
or
container
registries.
That's
where
manifest
comes
in
and
that's
our
definition
of
the
where
to
pull
froms.
So
we
say
for
a
specific
package:
URL
type
like
I
say
you
know,
Pi
Pi,
again
pull
from
this
internal
Nexus
instance.
If
you
are
using
a
Docker,
Pearl
type,
pull
from
this
ordered
list
of
container
Registries.
A
A
There
is
go
out
and
find
all
this
stuff
right
and
we've
written
a
plug-in
architecture
here,
where
you
can
have
our
base
core
plugins
that
are
about
eight
I,
think
Pearl
types
and
you
can
add
other
ones
for
anything
custom
that
you
want
once
you
bring
it
in.
You
can
augment
and
filter
that
s-bomb
all
right.
So
one
of
the
big
problems
we
have
often
seen
here
is
you
have
an
s-bomb
and
it's
lacking
additional
metadata
that
you
may
need
for
security
approval.
A
A
All
things
you
may
want
to
give
off
to
an
authorizing
official
at
the
other
end
is
a
series
of
plugins.
We
have
two
out
of
the
gate,
there's
others
that
could
be
easily
added,
and
one
of
them
produces
the
giant
tarfile
of
what
those
things
are
they
need
to
be
transferred.
The
other
one
would
be
a
Nexus
instance,
so
you
can
have
Nexus
instance
that
spun
up
and
then
you
can
transfer
all
the
stuff
that
you
define
in
s-bombs
into
that
Nexus
instance
snapshot
it
as
a
container
image.
A
You
move
that
to
the
high
side,
we
have
a
feature
flagged,
but
as
part
of
this,
you
can
generate
in
total
attestations
for
each
stage
and
all
the
files
that
have
been
collected
and
processed
as
part
of
it.
We
also
snapshot
the
s-bomb
as
it
changes
over
this
period
of
time,
so
you
can
see
exactly
what
stage
and
where
it
was
modified
and
again
just
to
kind
of
you
know,
I
guess
bring
it
home
again.
A
Our
primary
goal
here
is
one
data
flow,
One,
Security
team
right
and
multiple
teams
have
their
own
ability
to
specify
what
they
want
right.
You
have
the
control
as
a
team
member
to
say,
hey
I
need
to
update
these
four
packages.
I!
Don't
need
to
go
talk
to
someone
to
get
permission
to
do
that
right.
You
just
add
to
your
s-bomb.
You
say
where
to
find
it,
the
security
team
then
has
dependencies
on
those
and
Jared
will
show
you
how
that
works.
A
They
could
then
bring
that
stuff
in
do
additional
testing
if
need
be
and
then
bring
it
over
to
the
high
side.
Also
because
we
allow
you
to
specify
a
set
of
places
that
go
find
things
in
a
manifest.
You
can
easily
override
it
as
a
security
team
and
say
well,
I'm,
actually
going
to
only
allow
you
to
pull
things
from
these
four
types
of
package
repositories
and
these
container
registries.
A
So
the
hurdles
here
right
and
what
are
we
solving?
Well
often,
you
see
incomplete
s-bombs.
They
don't
have
all
the
information
you
need
for
security
approval
and
we're
looking
at
how
we
use
augmenters
and
filters.
The
I
guess
add
additional
metadata
there
that
someone
would
want
to
see
for
that
security
approval,
because
it
is
a
plug-in
architecture.
If
you
wanted
to
generate
a
digital
documentation
and
say
I,
don't
know
Excel,
because
no
one's
here
ever
done
that
you
possibly
could
do
that
right.
It's
a
plug-in
architecture.
You
have
an
s-bomb.
A
A
So
as
things
change
Downstream
in
s-bombs,
they
all
percolate
up
to
the
security
team.
That
can
then
do
that
transfer
automatically
and
then.
Lastly,
this
allows
us
to
have
a
one-way
delivery
into
an
environment,
but
a
clear
understanding
of.
What's
in
that
environment
From
anesman
perspective,
so
you
can
do
it
all
on
the
low
side.
A
So
we
talked
a
lot
about
these
advantages,
but
I'm
just
going
to
point
out
a
couple
of
them.
The
biggest
one
being
is
hey.
We
have
Cyclone
DXs
bumps
for
everything,
that's
in
that
in
that
environment.
Well,
that
allows
us
to
work
with
a
lot
of
existing
tooling
out
there,
I'm
going
to
say
one
of
my
favorite
dependency
track
right.
A
A
We'll
probably
briefly,
show
an
out
of
stated
sorry,
an
out
of
state,
a
cve
report
with
hopper
cup
and
then
we'll
share
a
little
bit
about
out
of
station
creation
and
specifically
a
layout
file
for
that.
So
you
have
a
way
of
verifying
all
the
the
title
links
and,
lastly,
we'll
just
show
the
bundle
this
demo
does
work
in
gitpod.
So
if
you
scan
the
QR
code,
you
can
actually
pull
it
up
yourself
and
play
with
it
and
that's
how
we're
going
to
download
this
and
get
pod.
D
D
D
So
you
can
see
it
kicking
off
right
down
there
and
talks
a
lot
about
the
multi-team
concept
and
really
that
is
defined
in
our
let's
grab
this
and
expand
this
out
a
little
bit,
it's
defined
in
our
manifest,
so
our
manifest
we've
got
some
metadata
up
there,
but
really
what
we're
looking
here
is
we're
saying:
grab
a
local
s-bomb,
that's
other
stuff.
We
want
to
augment
here
and
then
you
can
see
in
here.
D
Our
includes
are
referencing
two
different
external,
these
guys
here,
two
different
external
teams
that
have
manifests
that
also
Define,
that
team,
or
that
projects
dependencies
and
lists
and
whatever
they
want
to
bundle
up
there
and
what
we're
able
to
do
there,
then,
is
say:
go
grab
from
this
team.
We
expect
it
in
this
format.
We
expect
an
s-bomb
with
it
give
us
our
references,
pull
that
all
together
and
then
let
us
basically
zip
it
up
and
package
it
up
so
that
we
have
an
artifact
to
deliver
down
here
with
the
repositories
that
you
see.
D
Let's
bring
that
back
up
we'll
go
here,
real,
quick,
we're
going
to
look
at
the
transfer.
The
transfer.yaml
is
really
what
what
in
total
used
earlier
to
kind
of
understand
what
was
going
to
happen
in
here.
We
have
stages.
For
example,
we
have
a
collect,
a
report
and
a
bundle,
but
those
names
can
they're
free
form
as
long
as
the
structure
maintains
the
same,
but
inside
we
Define
in
the
collect.
D
We
want
to
run
our
git
plugin,
our
raw
plug-in,
our
Docker
plugin,
we're
going
to
go
and
generate
our
report
with
hopper
cop,
and
these
are
the
different
scanners
that
we
want
to
enable
and
then
down
here
at
the
bottom.
Pretty
simple.
You
know
where's
my
tar
file
going,
what
what
should
it
be
named
and
so
forth.
D
D
C
D
See
we
got
our
s-bombs
in
there.
We've
got
our
Consolidated
and
delivered
so
there's
two
different
s-bombs
that
get
put
into
the
tar
file
right
now,
they're
going
to
be
identical,
but
on
day
two
operations
where
we
want
to
go
and
send
a
Delta.
That
is
where
the
Consolidated
looks
at
what
the
original
was
and
then
the
delivered
is
the
pieces
that
we,
the
Deltas
right.
We
only
want
to
bring
over
that
smaller
subset
instead
of
the
entire
package,
especially
when
the
deliverables
can
be
pretty
big.
D
D
On
the
other
side,
we're
currently
in
progress,
we're
looking
at
unbundling
and
installation
of
disconnected
networks,
those
can
be
a
little
bit
challenging
because
those
networks
kind
of
also
Define,
where
pieces
go.
They
don't
always
go
to
the
more
traditional
locations
and
they're,
often
Diversified
across
those
systems,
and
then
looking
at
doing
addition
and
implementation
with,
as
we
go
forward
with
some
of
the
work
with
it's
the
s-bomb,
with
the
verified,
verifiable
s,
bonds
with
them.
You
got
to
say.
D
A
So
we're
not
checking
if
s-bombs
are
stale
in
any
way,
but
what
we
we
kind
of
encourage
and
what
we're
doing
in-house
is
using
renovate
quite
heavily
right.
So
if,
if
there
are
dependency
updates
that
should
happen,
we
would
assume
that
a
new
respawn
gets
generated
and
then
that's
what
would
be
used
to
generate
a
new
Pipeline
and
push
a
new
bundle
across
into
our
environment.
We.
B
A
A
B
B
A
Yeah
we
haven't,
we
haven't
experienced
that
problem
yet,
but
somebody's
gonna
keep
in
mind,
I.
Think
the
bigger
problem
that
we
have
right
now
is
discoverability,
with
the
open,
ssf
scorecard
being
path
based
and
assuming
that
you're
on
GitHub.
How
do
you
for
us
since
Pearl,
is
our
biggest
identifier?
How
do
you
transition
from
Pearl
to
the
scorecard
URLs?
It's
been.
A
So
that's
yeah,
that's
that's
a
tough
one!
I
think
we
are
right
now,
assuming
that
you
are
defining
your
transitive
dependencies
and
we're
not
going
to
discover
them
for
you
granted
again.
Hopper
could
facilitate
the
addition
of
your
transitive
dependencies,
I'm,
not
sure
if
it's
in
this
example,
but
we
typically
like
if
you're
using
python
or
something
else
we
force
those
Transit
dependencies
into
that
spawn,
so
that
they're
tracked
as
part
of
the
the
buttons
yeah.