►
From YouTube: Distributing Supply Chain Artifacts with OCI & ORAS Artifacts - Steve Lasker, Microsoft
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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.
Distributing Supply Chain Artifacts with OCI & ORAS Artifacts - Steve Lasker, Microsoft
In a world of continuous supply chain attacks, secure distribution matters more than ever. Your images are now signed, with systems bill of materials (SBOM) and frequent scan results. How will you consume them from public endpoints, promoting them across environments into private network environments where there's no external access? ORAS Artifacts lifts OCI Artifacts to the next level by enabling graphs of artifact relationships to be established. When you archive or delete any given container image, the related artifacts are archived or deleted as well, providing predictable lifecycle management. ORAS Artifacts enable you to build upon the hardened, performant, securely distributed registries you're already using. Come see how registries are evolving, enabling all your cloud-native artifacts to be distributed from the public registries to your private environments, wherever they may be.
A
A
A
Where
are
you
going
to
store
them?
How
are
you
going
to
distribute
them?
It
turns
out
the
what
matters,
because
of
some
of
the
best
practices
for
how
we
think
about
just
to
distribute
and
deploy
these
and
we'll
talk
a
little
bit
about.
Should
we
be
building
new
services,
or
should
we
invest
and
extend
some
of
the
existing
services
that
you're
all
using
already
so
I'll,
spend
a
little
time
talking
about
this
elegance
and
evolution
of
registries,
which
will
put
context
to
the
whole
whole
thing
of
oci
and
aura's
artifacts.
A
So
there's
lots
of
them.
Oh
my
it's
just
every
day,
there's
a
new
artifact
type,
that's
coming
out
whether
it's
a
new
s-bomb
format
or
claims
or
attestations,
there's
just
lots
of
different
types
that
are
applying
to
the
software
already
thinking
about.
So
we
think
about
containers,
but
there's
packages,
there's
loose
binaries
turns
out.
There's
iot
deployments
that
we
should
be
thinking
about
from
the
killer
cars
that
can
be
taken
over
to
the
medical
devices
that
are
in
the
people
that
got
hit
by
the
killer
cars
right.
A
These
are
all
components
that
we
should
be
thinking
about
of.
How
do
we
have
supply
chain
artifacts
around
these
new
types
or
new
types
around
the
existing
things
we're
already
deploying,
but
it
also
applies
to
our
vms
that
are
under
the
covers
for
all
of
our
containers
that
we're
running
right.
This
is
not
a
new
problem,
it's
just
a
matter
of
how
do
we
think
about
it
across
the
spectrum
of
software
and
hardware.
Quite
frankly,
so,
as
we
started
this
effort
several
years
ago,
a
lot
of
these
formats
didn't
exist.
They
continue
to
pop
up.
A
A
On
your
way
here,
you've
made
some
software
available.
You
might
have
you
know,
built
a
new
image
or
whatever
you
were
working
on
as
you're
leaving.
The
cluster
needs
to
scale
should
that
cluster
be
pulling
across
the
internet
and
a
thousand
different
types
of
connections
from
docker
hub
or
some
other
public
registries
like
elastic.
A
How
many
of
you
have
a
refrigerator
in
your
house,
why
you
can
go
to
the
store
and
get
fresher
milk
every
day
right?
What
is
it
going
to
be
in
stock
right?
We
go
to
the
refrigerator
in
our
house
in
our
hotel
room,
because
it's
right
there,
it's
faster,
it's
reliable,
because
it's
there
right
right
there.
Now
I
keep
on
updating
it.
I
keep
on
replenishing
it.
It's
the
same
model
with
our
production
notes.
A
A
Lots
of
updates
are
well
intended
and
break
us
because
everything
that
changes
is
a
change
of
some
sort.
So
we
want
to
make
sure
that
we've
got
a
tested
copy
of
the
software.
We
depend
on
in
a
location
we
can
depend
upon
and
then
have
a
constant
stream
of
updates
that
could
come
in
after
we've
tested
them
to
apply
so
the
content.
The
concept
here
is
basically
we
want
to
keep
a
copy
of
the
stuff.
A
A
So
we
want
to
ship
all
of
that
software
together,
so
it
as
I'm
trying
to
do
verification,
whether
I
should
be
deploying
this
thing,
because
I'm
making
a
decision
based
on
the
s-bomb
or
the
git
bomb
or
any
of
the
other
claims
of
details.
We
want
to
make
sure
that,
with
the
software
itself
now
we
have
automated
builds
right.
We
probably
build
more
than
once
a
week
these
days
or
once
a
month,
it's
probably
multiple
times
a
day,
maybe
even
every
get
commit
for
every
one
of
those
builds.
How
many
do
you
test?
A
A
A
How
many
of
you
have
compliance
requirements
that
for
any
software
you
deployed
you
need
to
keep
for
some
amount
of
time.
18
months
tends
to
be
the
magic
number
for
all
of
that
software
you've
deployed,
but
it's
not
deployed
now.
Are
you
scanning
it?
Well,
you
probably
should,
because
you
want
to
know
if
there
was
any
exploits,
do
you
patch
the
archive
software,
because
you've
got
an
alert
you're
supposed
to
go
patch
it.
A
If
I'm
patching
the
archive
software,
which
I'm
keeping
for
compliance,
then
it's
not
the
software
I
deployed
so
there's
just
lots
of
complexity.
Here,
as
you
want
to
move
your
deployed
software,
that's
that
was
now
archived.
You
want
to
keep
that
in
a
separate
place,
you're
going
to
need
all
of
those
supply
chain,
artifacts
to
travel
with
it
as
well.
What
was
the
s-bomb
at
the
time?
Hey,
I've
got
a
vulnerability
now.
Why
did
you
deploy
that
thing?
A
A
A
Now
is
everything
publicly
accessible
by
everybody
right?
It's
one
thing
to
have
oss
software
that's
available,
but
we
consume
oss
in
software
that
we
either
ship
with
intellectual
property
that
we
don't
make
publicly
available
to
the
ingredients
or
it's
internal
within
our
firewalls
within
our
companies
that
we
need
to
keep.
A
What's
the
scoping
of
access
to
all
of
that,
does
everybody
have
equal
access
to
all
things?
Does
everybody
get
create,
update
and
delete
rights,
or
we
should
we
just
trust
everybody
kind
of
defeats?
The
purpose
of
you
know
well,
actually,
if
we
trusted
everybody
that
we
wouldn't
have
to
worry
about
security,
but
of
course
that's
not
the
case
and
then
what
about
just
listing
the
information
out?
What
about
the
metadata
on
it
right
all?
A
These
are
the
things
that
we
think
about
the
more
the
days
day
next
around
what
these
storage
services
have
to
provide,
and
what
about
all
the
idi's
for
production
capabilities
right
these
there
needs
to
be
geo-replicated
into
multiple
regions
within
a
region.
There
are
available
multiple
availability
zones.
This
is
the
expectations
that
are
put
on
a
cloud
providers
for
these
services.
A
How
do
you
promote
that
content?
How
many
of
your
customers
are
multi-cloud
or
you
are
multi-cloud?
Will
this
work
across
multiple
clouds
or
on-prem
and
when
stuff
goes
wrong?
How
do
I
think
about
the
diagnostics
and
all
the
troubleshooting,
so
you
kind
of
get
the
pattern
here
is
in
in
firewalls
right.
We
talked
about
how
this
software
needs
to
be
able
to
be
available
within
a
v-net,
because
all
of
our
customers
want
their
security
that
they
had
on-prem
in
the
cloud.
A
No
public
access
lock
it
down.
So
these
are
all
the
requirements
that
keep
on
coming
up
on
these
various
storage
services.
Oh
and
then,
by
the
way,
who's
going
to
support
these
things
so
running,
a
storage
service
is
complex
right.
We
start
with
some
blob
storage.
We
add
some
rest
apis
for
discoverability.
A
We
put
authentication
on
it.
There's
some
caching
for
the
multiple
requests
for
the
same
thing,
there's
some
kind
of
support,
there's
integrity
and
signing
that's
available
on
all
of
these
things,
and
all
these
other
capabilities
keep
on
coming
up.
So
it
turns
out
like
we
should.
You
know
it
is
complex
for
all
of
these
and
all
of
the
supply
chain.
Artifacts
are
going
to
have
the
same
checkboxes
for
requirements.
A
A
So
that's
kind
of
the
setup
here
is
which
one
should
we
invest
in
so
git
turns
out
pretty
popular,
very
tailored
towards
your
build
environments,
right,
it's
optimized
for
developers,
making
changes
and
tracking
those
changes.
It
is
not
optimized
for
production
deployments.
We
have
lots
of
things
trying
to
pull
from
at
the
same
time,
and
we've
seen
that
with
some
of
the
various
technologies
that
are
trying
to
do
more
git-based
deployments.
A
There's
lots
of
existing
package
managers
and
most
of
them
are
underfunded.
They
just
don't
have
the
capabilities,
we're
always
trying
to
get
them.
You
know
to
improve,
but
just
it's
not
the
critical
business
sure
we
could
use
raw
storage
accounts,
which
is
underneath
all
that,
but
it's
not
robust
enough,
and
then
we
can
get
to
various
isv
products,
but
then
we're
starting
to
compete
for
things,
and
this
is
not
the
place
that
we're
trying
to
compete.
A
The
package
managers
and
the
storage
services
and
registries
they're
lost
leaders
they're
there
to
enable
the
rest
of
the
workloads
which
brings
us
to
what
we've
been
doing
under
the
oci
distribution.
Spec
is
leveraging
that
capabilities
to
which
every
one
of
your
cloud
providers
have
it.
You
have
them
on
friend,
if
you're
kubecon,
I'm
sure
you
have
a
registry
somewhere
at
least
one,
how
about
we
extend
into
that
infrastructure.
A
A
The
idea
is,
there
is
some
address
for
where
you
find
this
thing.
It's
kind
of
a
little
weird
that
registries
are
the
only
package
managers
that
you
have
the
addressability
in
it
right,
like
every
other
package
manager,
it's
a
config
option.
So
that's
a
different
effort.
We're
trying
to
make
that
a
little
easier,
so
you
can
promote
these
things
and
it's
a
configuration
for
the
registry.
There's
some
name
space
where
your
stuff
is
stuffed
into
and
depending
on
the
particular
registry,
it
could
be
one
two
or
n
levels.
A
A
So,
what's
under
the
covers
for
all
of
this,
that
net
monitor
v1
image
is
backed
by
a
manifest.
A
manifest
is
just
a
json
document
that
has
some
descriptive
information
about
it.
It's
intentionally
lightweight
and
we'll
talk
about
that
a
little
bit
more
then
there's
one
or
more
collections
of
content,
the
actual
content
that
makes
it
up.
Those
are
blobs.
A
It's
all
stored
in
some
kind
of
blob
storage,
usually
some
of
the
lightweight
registries
that
are
on-prem
or
you
know
on
you
know,
iot
snares
they
might
be
using
regular
files
for
storage,
but
typically
there's
some
kind
of
blob
storage
and
there's
this
rest
api.
We
talked
about
if
we
map
that
into
a
registry
the
manifests
there's
a
lot
of
them.
They're
stored
and
the
blobs
are
in
blob
storage
and
now
we're
starting
to
see
how
this
is
framed
together.
A
A
A
I
might
even
have
one
of
those
blobs
on
disk
already,
because
I
already
pulled
the
base
layer
for
some
other
image
all
right,
so
I've
already
got
some
of
that
information.
I
really
don't
want
more
information
to
come
to
the
manifest
than
possible.
It
now
says:
hey
from
that
list
of
layers
or
blobs.
That's
in
that
manifest.
I
already
have
this
one,
but
I
don't
have
the
other
one:
hey
registry.
Can
you
give
me
a
url
for
this
blob,
and
this
is
another
interesting
part
about
the
way?
A
The
response
to
the
request
for
the
id
for
layer
2
can
be
a
completely
different
url.
That's
a
protocol.
That's
set
up,
that's
how
we're
able
to
enable
that's
how
we
enable
cdns
that
can
be
serving
the
blob
content
from
different
endpoints.
It's
how
we
do
regional
endpoints
right.
It
allows
us
to
kind
of
there's
a
negotiation
there.
It
says
I
know
you
asked
for
rabbit
networks,
registry,
rabbit
networks,
io.
When
I'm
going
to
give
you
the
content,
it
actually
can
be
a
different
endpoint.
A
So
those
are
things
just
to
be
aware
of
when
you're
configuring
firewall
rules
too,
as
to
look
what
your
cloud
provider
is
doing
or
your
registry
is
doing
so,
then
it
finally
says:
hey
here's,
the
url
and
the
client
goes
okay,
great!
Let
me
go
pull
them
and
I
might
pull
them
concurrently
and
of
course
this
is
the
model
we
see.
We
see
that
in
the
docker
model
we
see
the
layers
being
expanded
and
once
all
those
layers
are
there,
it
goes
hey.
I'm
done.
Here's
the
container
register
the
container
image
and
off
it
goes.
A
And
then
there's
some
additional
metadata,
which
we'd
love
to
do
more
with.
This
is
like
we
think
what
people
are
using
labels
for
this
is
what
annotations
were
intended
for.
We're
hopeful
that,
as
we
can
start
indexing
these
more
that
they'll
actually
be
a
nice
circle.
That'll
come
around
and
go
like
well.
I
can
actually
do
something
with
them,
so
maybe
I'll
produce
more
annotations.
A
Now
the
files,
the
blobs,
are
really
just
a
pre-structured
way
to
kind
of
segment
stuff.
It's
really
optimized
around
that
shared
content,
but
it's
really
no
different
than
what
your
disk
subsystems
do
when
they
were
slower
and
we
had
these
defragmenter
things
and
they
were
fun
to
watch
the
little
bits
going
around.
A
A
There's
the
one
that's
probably
the
most
popular,
because
if
you've
done,
if
you're
doing
docker
build
that's
what
the
docker
manifest
is
it's
the
original
one
when
it
was
submitted
to
oci,
there
was
a
little
bit
of
reformatting
of
it
to
make
it
a
little
more
vendor-neutral
and
standard.
So
that's
the
oci
manifest
same
functionality.
A
If
you
have
multi-arc
images,
whether
it
be
windows
and
linux
or
arm
or
whatever,
there's
a
another
manifest
list,
that's
basically
says
here's
the
separate
individual,
manifest
for
arm
linux,
windows
and
so
forth,
but
you
can
associate
it
with
a
single
tag.
It's
a
nice
little
way
to
kind
of
get
an
abstraction
there
and
then
the
oci
index
is
the
multi-arc
version
of
that.
A
A
If
I
want
to
reuse
that
tag,
there's
another
manifest
and
potentially
more
blobs
that
get
uploaded,
and
this
synthetic
thing
over
here
that
you've
called
the
tag
is
pointed
at
the
new
manifest
that
old,
manifest
is
still
there.
It's
just
called
an
untagged.
Manifest
is
usually
the
terminology
and
you
might
even
set
up
that
automatically
delete
untag
manifest
as
a
thing,
but
there's
a
virtual
concept
of
a
tag,
and
it
has
a
pointer
that
can
float.
A
A
We
talk
about
the
tags
or
pointers,
and
the
artifacts
in
a
registry
can
be
from
a
k
to
multiple
gigabyte
machine
learning.
Folks,
man,
you
guys
got
some
really
big
images.
It
is
pretty
amazing
how
you
stretch
the
extent
of
what
a
registry
is
capable
of
so
as
I've
gone
through
this
is
there
anything
really
unique
around
a
container
image
in
this
in
this
flow
that
we
just
walked
through
it's
pretty
generically
useful,
so
I'll,
take
you
through
a
little
journey
on
how
we
wound
up
doing
this
generic
model.
A
A
So
we
started
going
down
this
azacr
helm
repo
ad
and
before
we
could
even
and
it
worked
and
mapped
out
pretty
well,
but
it
was
unique
to
azure
like
yeah.
Okay,
but
as
we
started,
we
didn't
even
get
finished
and
cnab
was
becoming
a
thing
and
singularity
was
saying
like
we
really
don't
want
to
host
our
own
registry.
Can
we
just
get
this
working
in
the
existing
registries?
We
don't
want
to
run
yet
another
storage
service,
so
we
just
kept
on
going
down
this
list
and
we're
like
az
acr
as
the
ac.
A
A
So
what
we
did
is
we
went
back
and
said
what,
if
we
leveraged
that
same
infrastructure
and
generalized
it,
so
you
can
store
helm,
charts
in
oci
registries
work
in
azure,
aws,
google
on-prem
wherever
any
place
has
a
registry.
It
should
just
work
now,
all
of
a
sudden.
It
makes
sense
for
the
helm
team
and
the
terraform
team
and
all
these
other
teams
to
say
well.
Why
should
I
create
my
own
registry?
A
A
A
A
A
So
how
can
we
generalize
from
individuals
to
enabling?
How
do
I
find
other
things
based
on
that
same
name?
I
don't
want
to
change
the
tag
or
digest
because
that's
what's
locked
in
my
deployment
file.
Don't
mess
with
that.
Like
that's
what
I
know,
but
I
want
to
discover
related
things.
I
want
to
filter
on
those
related
things.
I
might
want
to
sort
them,
because
my
scan
results.
I
do
a
lot
of
so
I
can't
I
don't
have
just
one.
A
A
A
A
A
Usually
I
start
with
a
container
image,
but
what
I
want
to
show
is
it
doesn't
have
to
be
a
container
image.
So,
at
microsoft
we
have
to
abide
by
the
us
executive
order
for
providing
s-bombs
and
claims
and
details
not
just
on
the
software
we
ship
like
office
and
other
things,
but
on
the
services
that
we
run.
A
So
here
I'm
using
the
webbit
networks
company
and
they
have
this
network-
monitor
service
that
they
run
and
they're
going
to
have.
Let's
just
call
it.
The
2022,
q1
m1
version
that
we're
just
going
to
create
an
arbitrarily
named
thing
in
the
registry
to
make
a
reference
to
so
I
just
created
some
json
document,
no
big
deal.
A
I'm
going
to
push
this
to
the
registry
using
auras.
Now
this
is
the
original
oci
artifact
stuff
we
did
a
couple
years
ago.
All
I'm
doing
is
saying
push
localhost
5000,
that's
the
registry,
and
then
the
namespace
is
services,
and
then
the
artifact
is
net
monitor
and
I've
got
a
version
associated
with
it.
A
The
manifest
config
thing,
that's
again,
that's
how
we
did
ocr
artifacts
the
first
version
just
there's
a
way
to
have
a
type
in
there.
So
I
said
it's
an
application.
Json
just
made
up
a
type,
and
then
the
service.json
is
the
stub.
It's
just
that
little
file
that
just
represents
something.
So
there
is
if
I
want
to
find
some
information
about
the
service,
whatever
you
want
to
make.
Really.
The
main
thing
that
I'm
trying
to
do
is
just
create
a
reference
that
tag.
A
Now
let's
say
I
have
an
s-bomb:
I've
got
a
very
fancy
s-bomb
here.
It
says
I
think
it
says
it's
good,
so
it's
just
version
whatever
it
might
be.
200
megabytes
long,
some
of
our
s
bombs
for
some
of
our
services
are
huge
right.
So
we
need
something
that
can
scale
from
very
small
to
very
large.
So
I
have
an
s
bomb.
A
A
And
now
what's
interesting
is
now.
I
can
start
saying,
show
me
what's
related
to
that
service,
so
I
now
have
an
s-bomb
I've
called
it.
The
s-bomb
example
right,
I
know
of
the
net
monitor
service.
I
don't
know
what
the
identifier
is
for
the
s-bomb,
but
I
know
my
service
name.
I
know
the
software
I'm
looking
for.
A
Let's
say
I
want
to
add
some
claims
we'll
make
this
a
little
fancy
here.
Wait
is
that
the
one
I
did
yeah
so
I've
got
some
claims,
stop
with
the
paste
all
right
we'll
do
it
there.
Let's
say
that
it
conforms
to
some
sdf
compliance
again.
I've
got
some
document.
I
want
to
make
it
available
for
people
that
are
looking
for
the
information
on
the
service.
A
I'm
going
to
push
this
one
also
as
a
reference
so
push
to
the
repo.
Basically,
it's
push
the
claims.
Example,
that's
the
type
think
of
it
as
like
the
file
extension,
the
dot.
You
know
the
dot
json
file,
the
dot
steve
file,
whatever
there's
a
type,
I'm
taking
the
claims.json
file
and
I'm
just
pushing
it
up
and
the
subject.
A
Do
you
know
the
end
of
life
for
software?
When
you
build
it,
you
think
you
do
usually
don't
it
changes.
It
turns
out.
It
might
be
more
useful.
You
might
have
to
extend
it.
You
don't
know
what
the
next
version
I
originally
had.
M1,
I
think,
was
the
version
I
had
up.
There
turns
out
the
replacement
m2
turned
out
not
to
be
so
good,
so
we're
going
to
say
the
new
version
of
this
software.
If
somebody's
looking
for
an
update
is
actually
m
3.1.
A
A
A
I
just
created
it
and
I've,
given
it
the
reference
right,
because
everything
in
the
registry
has
a
unique
reference,
and
if
I
were
to
now
take
a
look
at
the
output
surprise,
surprise
I
was
able
to
round
trip
that
information
back
out
of
the
registry.
I
was
able
to
pull
just
the
claims
file.
I
didn't
have
to
pull
all
the
other
stuff.
A
I've
used
several
different
tools.
I
had
an
sp,
I
had
an
s-bom
tool,
maybe
it's
spd-x,
maybe
it's
cyclone
dx.
I
had
a
claims
tool.
I
had
some
annotations
that
I
added
to
it
if
you're
trying
to
copy
the
files
from
one
folder
to
another
on
your
computer,
do
you
open
up
powerpoint
and
visual
studio
code
or
some
other
tool
like
adobe
illustrator
or
whatever
you
use
the
file
system
api
you
say
copy
from
here
to
here
it
doesn't
care
what
the
type
is,
because
we've
set
up
this
relationship
with
the
objects
in
the
registry.
A
I
can
literally
go
hey
copy,
this
from
point
a
to
point
b
and
take
the
entire
graph
copy
from
services
net
monitor
to
web
networks.
Net
monitor
could
be
a
completely
different
registry,
and
now,
if
I
look
at
the
destination,
I
got
the
same
graph,
but
it's
at
the
other
end,
that's
kind
of
what's
powerful
by
saying
hey.
The
registries
now
know
about
references.
A
A
A
The
new
manifest
just
says:
look
it's
a
new
type.
That's
the
the
media
type
says
this
is
the
new
schema,
the
we've
taken,
the
hack
we
did
in
oci
artifacts
v.
You
know
the
original
one,
because
that's
the
way
we
just
took
the
config
media
type
and
we
surfaced
it
as
a
first
class
object,
a
property.
So
we
can
do
the
filtering
by
we've
taken
the
layers
and
we've
named
it.
The
blobs,
because
layers
are
unique
to
containers,
turns
out.
Blobs
are
pretty
generic.
A
If
you
really
really
really
really
need
a
config
object,
there's
a
media
type,
just
stuff
it
in
the
blobs
collection
and
call
it
the
same.
Config
object,
so
you
can
still
get
it
out.
It
turns
out.
Most
of
them
don't
need
configs.
The
subject
is
the
really
the
magic
piece.
The
subject
is
the
thing
that
says:
hey.
This
s-bomb
is
related
to
the
net,
monitor
image
or
the
the
service,
the
goofy
service
reference
that
I
created.
A
A
A
Now,
to
get
things
back
out,
there's
the
gazentas
and
the
gazelletas.
If
I'm
putting
new
manifests
in
with
the
subject
property
we
index
that
information.
So
when
I
call
this
new
referrers
api,
it's
it's
the
opposite.
I
call
an
api
to
get
the
content
and
I
have
another
api
that
says
I
want
the
related
objects
to
that
net,
monitor
image,
so
it
just
returns
a
list
of
descriptors
with
the
artifact
type.
So
I
can
decide
whether
I
actually
want
the
signature
or
the
s-bomb.
That's
how
the
filtering
works.
A
A
We
want
to
keep
them
alongside,
so
we
can
copy
them
and
we
can
pull
them
independently.
Just
like
when
you
go
to
the
airport,
you
don't
walk
through
with
your
your
passport.
You
give
your
passport
through
the
hole
and
if
they
like
you-
and
they
approve
you,
because
they
you
weren't
revoked,
then
they
download
the
rest
to
you
through
the
security
checkpoint
or
onto
the
node.
A
Let's
see
what
else?
That's
basically
it
so
there's
a
couple
of
links
here
for
how
we've
been
doing
the
work
we
originally
had
oci
artifacts,
that's
there,
that's
the
single
individual
objects,
the
auras
artifacts.
We
think
reference
types.
We've
done.
The
incubation
under
auras
we're
working
with
oci
to
get
that
submitted
as
a
standard,
auras
and
oci.
Obviously,
both
linux
foundation
projects
so
we're
you
know
they're
available
for
everybody
to
use.
Then
the
aura
cli
is
how
I
was
using
it
there
think
of
it
as
the
file
system
api.
A
But
if
I'm
in
an
application,
I
can
do
file
save
and
file
open
within
an
application
right.
Those
are
libraries
for
how
to
interact
with
the
file
system.
We
have
rs
go,
which
is
how
you
can
build
your
s-bom
tool
to
interact
with
the
registry
right.
So
that's.
We
really
want
to
make
sure
that
these
things
are
available
for
other
people
to
use
in
their
tools.
A
Your
users
shouldn't
have
to
think
about
auras.
They
want
to
think
about
your
thing,
your
sbom
tool,
your
scan
results,
your
whatever
it
is,
you
guys
are
going
to
creatively
come
up
with.
Is
you
can
use
the
rs
go
libraries
to
say?
Look
I
just.
I
don't
want
to
be
dealing
with
storage
things.
I
want
to
leverage
what's
already
there.
A
So
let
me
just
use
this
library
and
I'll
do
the
push
discover,
pull
and
then
we've
got
a
fork
of
distribution
that
supports
all
of
this.
So
that's
it
for
the
talk
we
have
this
running
in
azure
aws
is
coming
soon
docker's
working
on
their
version
of
it.
We're
we're
looking
for
anybody
else.
That's
looking
for
support
and
new
innovations,
new
ideas.
Our
goal
here
was
to
not
worry
about
a
specific
type.
It
was
to
enable
the
ecosystem
to
store
all
these
things
and
not
have
to
create
yet
another
storage
solution.