►
From YouTube: SLSA Specifications Meeting (March 6, 2023)
Description
Meeting notes: https://docs.google.com/document/d/1kMP62o3KI0IqjPRSNtUqADodBqpEL_wlL1PEOsl6u20/edit#heading=h.yfiy9b23vayj
A
A
E
C
C
C
A
H
A
A
B
F
It's
fine,
don't
worry
so
I
think
yes,
I'm
working
for
a
decor
and
I've
been
working
on
bit
system
for
last
20
years
and
I
did
the
call.
We
are
building
many
compilers
either
compilers
based
on
GCC
and
today's
another
vm2,
and
so
we
have
a
huge
supply
chain
and
big
system
that
is
homemade
and
will
be
interesting
to
take
the
next
step,
which
is
to
integrate
stuff
like
salsa,
especially
because
we're
also
working
with
U.S
government
so
for
the
executive
order,
14
or
28.
If
I
remember
correctly,
remember.
B
C
Okay,
so
if
anyone
has
agenda
items,
please
add
it
to
the
to
the
list
one.
So
we
had
published
the
draft
on
late
Friday
night,
which
was
when
do
we
pull
the
head?
Drive.
I,
guess
this
is
now
what
the
24th,
and
so
it's
now
been
a
week.
We
have
a
couple
feedback
items
so
far.
We
we
asked
for
feedback
by
I
believe
the
24th
or
something
like
that.
So
it's
a
four
week
comment
period.
C
C
C
Size
so
the
there's
something
around
the
verification
piece:
I
think
that
still
needs
more
iteration,
Chris
and
Cara
on
who
who
work
with
me
at
Google
I
think
are
working
on
iterating
on
there.
So
I
think
that
we
have
that
covered
the
what's
new
I
think
Cara
has
signed
up
for
for
writing
that
we
could
still
use
something
around
like
versioning
explaining
like
what
is
the
strategy
for
versioning
how
you
refer
to
Etc,
like
I,
said
S2
c2f,.
C
Is
probably
worthwhile
too,
there
was
a
thing
about
probably
provenance
publication
and
Discovery
I.
Don't
know
if
we've
decided
like
should
that
be
part
of
the
spec
or
not,
but
it's
listed
here
and
there's
several
comments
on
there:
oh
okay,
that's
all
Justin
Dustin,
just
and
then
there's
like
consistency
thing,
because
we
have
like
there's
a
lot
of
consistency
thing
across
the
site
and
I
could
I
could
tackle
that
on
the
Providence
side.
C
C
Some
of
these
probably
aren't
P
Zeros
like
this
one,
for
example,
some
P0
more
of
the
clarity
thing
this
one
list
I
haven't
gone
through
yet
but
I
think
in
several
of
these
we
have
addressed
them
to
some
degree
in
the
current
draft
and
I
suspect.
What
it
is
is
like
how
much
effort
are
we
going
to
put
in
like?
Is
it
when
is
good?
When
is
it
good
enough?
C
So
there's
kind
of
some
clarity
thing
there
and
I
think
a
lot
of
the
feedback
we
got
so
far
wasn't
kind
of
in
the
vein
of
like
clarity,
and
then
these
I
think
are
kind
of
a
best
effort
thing
more
if
you're
reading
the
spec
and
think
like.
Oh,
this
is
a
problem
like
we
don't
Define
what
source
means
or
the
term
Builder
is
confusing,
and
when
I
talk
to
people
on
my
team
they're
confused
by
it,
then
then
we
should
like
it's
helpful
to
say
so.
C
We
could
bump
up
the
priority
of
those
and
the
things
that
we
read
and
we
think
are
like
it's
fine
I
say
we
just
we
just
call
it
like
well,
not
fix
like,
for
example,
that
move
the
use
cases
to
the
spec,
I
suspect,
I,
suspect,
we'll
just
say
it's
good
enough.
It's
not
hampering
our
ability
to
you
know,
have
people
understand
the
specs
so
we'll
just
at
least
move
it
off
this
1.0
project
board
and
some
of
these
I
think
have
already
been
addressed
too.
C
E
D
D
C
A
I
mean
it
sounds
to
me
like
another
kind
of
clarification,
and
you
know
I
I'm,
a
big
believer
in
you
know,
make
your
specs
as
clear
as
possible.
So
if
there's
some
confusion
and
we
can
fix
it
without
great
trauma,
awesome,
do
you
think
a
lot
of
these
clarifications
are
just
we
need
to
Define
some
more
terms.
I
haven't
done
the
the
broader
look
at
which
you
know
for
all
the
clarification
buttons
which
ones
are
just.
We
need
to
define
a
term
versus
something
else.
C
C
D
A
Yeah-
and
you
know
there
are
many
specs
you
that
use
you
know,
for
example,
blah
blah
blah.
Obviously
those
aren't
Norm
in
the
standards
of
terminology
they're
not
normative,
because
if
it's
an
example
that
implies
there's
another
ways
to
do
it,
but
you
know
making
it
so
that
people
can
clearly
understand
it
is,
is
a
necessary
step
to
applying
it.
H
D
C
E
C
G
Also
in
the
tooling
side
is
we
started
creating
a
bunch
of
tracking
issues
across
a
bunch
of
the
different
tools
that
are
like
already
implementing
software
planning
to
implement
salsa
to
kind
of
at
least
a
lot
of
the
primary
open
source
ones
to
sort
of
get
them
ready
for
implementing
1.0,
and
so
does
it
make
sense
to
create
like
a
a
separate
tracking
issue
inside
of
our
inside
of
salsa,
just
to
kind
of
then
refer
to
those
other
issues
in
these
other
projects.
Just
to
kind
of
do
that.
C
G
G
G
C
C
I
think
it
depends
on
the
person
like
I
think
like
if
you're
it's,
it
could
be
annoying
like
the
reason
why
we
did.
The
snapshot
is
because,
like
it
could
be
annoying
like
I
read
it
and
then
you
go
back
the
next
day
and
it's
different
like
what
the
I
could
have
sworn
I
read
something
we
could
probably
better
documentation.
That
would
be
good,
but.
A
A
A
D
E
C
C
Okay,
I
I
quickly
wanted
to
talk
about
the
something
that
came
up
that
Arno
and
I
have
been
discussing,
which
is
this
issue
662
in
the
spec
we
in
the
provenance
spec
we
require
there's
kind
of
like
another
layer
down
below,
which
is
the
build
type,
and
each
build
system
could
have
a
different
build
type,
for
example.
So
far
we
have
two
examples
where
we
Define
one
one
for
GitHub
actions,
one
for
Google
Cloud
build,
but
those
are
both
proprietary
commercial
systems.
C
C
Having
an
index
is
fine,
but
there's
a
question
of
like
hosting
and
who's.
You
know
who's
responsible
for
it.
I
I
feel
I
think
this
is
a
part
where
Arnold
and
I
had
discussed
a
little
bit,
but
I
think
it's
maybe
worth
opening
to.
The
group
I
think
it's
valuable
to
have
a
Central
repository
for
Community
owned
definitions
for
one
it's
not
like.
C
If
there
is
no
central
place
to
actually
store
them,
then
you
have
to
come
up
with
a
good
URL
for
it.
You
have
to
come
up
with
a
hosting
provider
and
that's
kind
of
annoying,
and
so
I
was
thinking.
If
we
don't
want
to
have
it
under
the
salsa.dev
domain,
maybe
we
could
just
like
make
a
separate
git
repo
and
with
like
a
sub
domain,
or
something
like
that.
G
Yeah,
so
just
a
a
little
comment
that
this
is
also
another
problem.
That's
also
happening
within
the
entire
org,
with
some
of
the
stuff
that
they're
trying
to
do
with
their
own
attestations.
Where
they're
trying
to
say
hey,
does
it
make
sense
to
have
Community
stuff
under
like
Community
attestation
types
underneath
in
Toto,
so
I
think
they're
also
doing
something
similar
where
they're
looking
to
create
like
a
dictionary
or
a
library
of
stuff,
while
still
allowing
folks
to
sort
of
create
their
their
own
there
as
well.
E
We
get
to
a
certain
amount
listing
them
all
on.
The
website
might
get
a
bit
unwieldy
or
not
just
listening,
but
including
them
all
in
the
website
might
get
a
bit
unwieldy,
like
keeping
them
up
to
date
with
the
systems
that
we
do
not
maintain
that
they
are
kind
of
reportedly
documenting,
but
certainly
at
this
stage
of
the
project.
Having
like
ready
access
to
these
examples
is
super
useful
for
helping
people
understand
the
project,
so
I'm
kind
of
torn
on
those
lines
like.
C
B
I
Yep,
yep,
okay,
Josh
and
I
have
also
been
wondering
where
exactly
we
can
put
the
repository
of
build
conformance
proof,
and
it
would
make
sense
to
me
that
they're
in
the
same
spot,
but
I
I,
believe
someone
told
me
recently
that
spdx
has
a
similar
need
for
a
repository
of
either
Builders
or
tools
or
something,
and
if
in
Toto
also
has
this
need.
Would
it
make
sense
for
such
a
repository
to
be
its
own
project
rather
than
owned
by
salsa.
A
A
J
Terms
so
I'll
just
say:
I'll,
say
I'll,
just
say
that
I'll
say
the
most
everything
that
does
not
fit
into
the
you
know
comment
externally.
Only
aware
of
the
Cyclone
DX
spdx
map
things
I
know:
assistations
are
the
general
mechanism
for
any
type
of
external
link
to
something
else,
so
that
would
qualify
what
you've
described,
but
I
can
talk
specifically
about
Cyclone.
That's
why
I
have
my
hand,
rights.
J
Yeah
so
I
did
put
on
the
agenda,
so
maybe
it's
a
good
segue
or
a
delayed
segue
I've
been
I'm.
The
author
of
the
formulation
portion
of
the
cycle
index
version,
1.5
spec,
which
is
includes
workflows
or
CI,
CD,
workflows
and
I,
can
tell
you
how
we're
doing
these
things,
but
in
terms
of
the
design
we
it's
our
hope
that
any
service
or
any
component
that
runs
a
a
workflow
for
CI
CD
purposes,
will
have
their
own
s-bomb.
J
That's
what
we're
encouraging,
and
you
can
describe
this-
that
s-bomb
to
any
level
of
detail.
You
want
there's
this
concept
of
public
facing
versus
private,
so
there
might
be
a
private
public
facing
s-bomb
that
describes
the
component
service
and
that
should
provide.
There
should
be
linkage
in
the
actual
workflow,
the
actual
run
that
you
did
Brian
protect
on
the
task
run
or
the
workflow
run.
J
J
So
external
references
is
the
way
to
go
explicit.
You
can
have
explicit
inputs
and
outputs
from
a
system
logs
evidence
whatsoever.
You
can
make
them
explicit
if
they're
part
of
the
workflow
themselves
or
outputs
from
the
workflow,
but
you
can
also
include
them
as
external
references
as
well.
If
they're
located
in
a
remote
repository
like
a
recore.
J
J
B
C
One
is
the
build
definition,
which
kind
of
says
what
was
done,
and
then
the
Run
details
is
like
who
was
done
at
this
specific
instance
of
doing
it,
and
so
in
this
case
this
would
be
like,
for
example,
if
like
when
you
run
on
GitHub
actions.
Let's
say
this
would
describe
just
like
the
the
interface
to
GitHub
actions,
which,
theoretically,
you
could
have
a
different
system.
C
J
Well,
it
means
you
know
to
tell
me
that
it
was
run
on
this
Builder
that
Builder
can
be
described
as
an
s-bomb,
either
as
a
component
and
or
service,
and
in
terms
of
like,
like
IBM,
has
they
call
it
continuous
delivery
service,
which
is
basically
tucked
on
with
a
lot
of
extra
stuff.
Much
like
Fresca
is
to
to
open
up
and
sound.
So
you
want
to
describe
perhaps
the
entire
topology
of
where
that
ex
that
job
was
run
where
that
build
was
run.
G
So
I
believe
that's
kind
of
more
of
the.
The
intent
of
the
Builder
ID
piece
was
to
sort
of
say,
yeah
that
is
sort
of
the
run
time
itself
and
then
the
build
definition
is
kind
of
like
the
type
of
build
and
and
I
think
it
is
sort
of
like
an
intersection
of
the
two
right,
because
you
could
have
multiple
different
ways
to
run
tecton,
let's
say,
but
then
the
Builder
itself
might
be.
This
is
the
running
instance
of
tecton
with
these
parameters,
and
you
know
with
stuff
like
yeah
like
this.
J
I
think
that
that
that's
great,
maybe
for
some
Downstream
consumers,
but
in
but
going
forward
for
any
you
know,
contracts
that
require
you
to
list
all
your
Hardware
bills
and
materials.
What
harder
you
ran
on
and
a
whole
bunch
of
other
things.
That
would
be
good
to
consider
how
you
would
link
a
bomb
to
this.
So
a
bomb.
J
Can
you
have
a
service
descriptor
here
is
my
workflow
service
and
where,
where
it's
at
and
and
that
it
coincides
with
the
instance
document
that
you
for
that
run
of
that
of
your
build,
but
what
service
where's
the
bomb
for
the
actual
service?
No
matter
what?
Where
is
the
code?
I
ran
this
on
techton
version?
You
know
1.0
beta
spec,
API,
kubernetes
or
whatever
release
of
of
techcon
1.18
or
whatever
it
might
be.
So
where
is
that
information.
C
C
J
I
think
that's
great,
that's
great
for
for
first
pass
but
realize
that
public
Builders,
and
only
you
know,
there's
we
could
say
we
can
try
to
enumerate
all
the
public
builders
that
are
known
out
there.
They're
typically
used,
but
the
reality
is
is
that
people
who
are
asking
for
bombs
and
asking
for
this
level
of
security
in
detail
most
these
are
running
running
on
private
builds
in
different
companies,
whether
it
be
Google
even
or
IBM
or
Microsoft,
or
using
s2ctf
or
whatever.
C
Yeah,
yeah
and
I
think
that's,
that's.
That's
fine,
I
think
it's
like
I
have
no
objection
to
like
adding
a
link
here,
but
what
we're
describing
is
this,
which
is
a
conceptually
different
thing,
which
is
NOT
saying:
where
did
it
run,
but
this
is
like
the
input
to
the
build
this
is.
This
is
basically
the
external
interface
to
the
build
of
like
what
you
know
like
how
do
you
interpret
the
build?
You
know,
theoretically,
that
how
could
you
reproduce
the
build.
J
C
G
Yeah
and
I
think
one
of
the
things
that
that
we've
been
mucking
about
with
with
Fresca
was
to
say
that
the
Builder
itself
is
a
URI.
The
Builder
ID,
rather
I
should
say,
is
a
URI
and
that
Builder
ID
would
include
them
the
details
that
would
require
both
for
the
actual
runtime
piece
of
it,
as
well
as
sort
of
the
the
Upstream
sort
of
we
weren't
using
bomb
right
now,
but
we're
using
some
other
stuff,
but
it
could
be
easily
just
like
a
bomb
link
of
like
yeah.
G
C
So
so
I
guess
what
I'm
asking
is
like
in
the
Cyclone
DX
formulation?
How
would
you
describe
so,
for
example,
you
know
actions
like
we
have
documentation
for
like
this
is
what
it
means
to
to
run
GitHub
actions.
There
is
a
deployment
object,
there's
an
inputs,
object
and
there's
a
workflow
file
and
a
ref
and
a
repository
and
these
what
these
means-
and
you
like.
C
J
E
J
J
J
Cyclone
DX
hasn't,
isn't,
has
been
intending
to
you
and
has
had
a
work
group
ongoing
to
work
on
formulation
which
basically
is
any
type
of
workflow,
primarily
against
cicd,
with
the
intent
to
map
it
to
salsa,
but
primarily
I
wanted
to
map
it
to
Tech
time.
First,
before
I,
even
salsa
even
existed,
so
here's
the
here's,
the
concept
I-
can
go
to
the
concepts,
the
goals
and
things
like
that.
I
can
actually
show
you.
J
The
schema
and
I
submitted
the
the
draft
that
will
be
used
for
the
RFC
that
will
go
out,
hopefully
this
week,
so
be
so.
This
will
be
included
in
the
1.5
version
of
cyclone
DX
targeted
end
of
April,
so
a
lot
of
goals
is
to
represent
modern
cicd
pipelines,
actually
listed
Fresca
as
a
Target
representation
sauce
level
three.
So
these
are
my
slides
and
things
include
things
like
hoopla,
because
there's
other
work
groups
that
I
that
are
at
Cyclone
for
machine
learning,
cryptographic
builds
and
materials,
and
things
like
that.
J
That
need
to
be
factoring
these
things
as
well.
These
account
for
those
type
of
things
in
the
build
how
data
models
are
built.
Etc
concept
executor.
This
is
the
runtime.
This
is
kind
of
Runner.
If
you
will,
depending
on
terminology
executor,
was
the
initial
term
I
call
it
the
runtime
in
general,
and
then
it
basically
has
an
event
trigger
model
so
tasks.
We
can
actually
tap
track
tasks
or
events
that
trigger
pipelines
or
trigger
original
tasks,
including
manual
tasks.
So
again,
tactan
was
the
basis,
so
people
at
the
at
the.
J
So
to
me
it's
the
Grail
Fresca
is
the
Grail
and
you'll
see
my
representation
of
it
shortly,
but
I'd
probably
point
out
that
it
has
the
typical
workflows
have
these
Concepts
in
place
and
that
they're
directed
graphs
and
things
like
that,
each
with
conditional
conditions
between
them
to
determine
if
they
get
triggered
or
not
and
their
resources
and
things
that
feed
into
pipelines
and
whatnot
jumping
ahead.
Even
simple
basic
workflows,
you
need
to
cut
so
this
goes
back
to
capturing
inputs
and
outputs
to
every
single
task.
J
That
participates
an
ability,
even
a
a
three
t
or
two-tier
application-
can
have
many
tasks
because
it
has
many
different
languages
and
builds
and
get
dependencies
and
stuff
like
that.
So
all
those
need
to
be
recorded
in
a
bill
of
materials.
So
here's
what
I
here
I
spent
some
time
on
this
diagram
and
it
doesn't
capture
like
identities,
Access
Control
groups
or
things
like
that.
Kubernetes
by
the
goal
would
be-
and
this
is
an
I-beam
as
a
requirement
for
this
or
anybody
else
runs
techton.
J
We
have
to
record
down
to
Hardware
bare
metal
what
we
rounded
on
what
what
images
we,
what
we
installed
into
bare
metal,
whether
in
kubernetes
installations-
and
we
have
to
record
things
like
excuse
me,
sorry
and
I
included
spire
and
all
the
configuration
files.
So
every
time
there's
a
link.
There
is
some
type
of
unique
configuration
file
that
configures
the
resource
that's
allocated
by
the
kubernetes
control
plane.
J
That
is
everything
we're
seeking
to
capture
in
a
bill
of
materials.
Everything
down
to
bare
metal
that
in
in
each
age,
task
can
have
a
different
runtime,
so
workflow
can
comprise
a
Midas,
actually
run
a
different
systems,
so
the
the
degree
we're
trying
to
capture
here
is
like
complete.
Reproducible
builds
down
to
down
to
hardware.
J
These
are
internal
goals
before
we
reuse
and
schema
and
stuff
like
that,
so
walking
it
down
from
a
high
level.
Basically,
is
the
build
materials
root?
You
have
these
things
called
formula
that
you
can
add
for
different
use
cases,
but
we'll
they'll
be
comprised
of
one
or
more
workflows.
Again.
These
are
definitions,
workflow
definitions,
their
workflows
themselves
are
tasks.
J
If
you
will
that
are
comprised
or
have
tasks
within
them
and
there's
a
dependency
graph
that
dictates
the
orders
in
each
of
these
tasks
are
triggered
by
again
have
triggers
that
have
conditions
that
must
be
triggered
by
the
previous
task
or
brain
external
force
or
an
event
to
cause
them
to
be
triggered
in
terms
of
the
formula
there's
some
new
types.
This
is
what's
currently
under
debate.
Why
I
broke
this
on
a
different
slide,
so
the
con?
J
The
concept
is
that
we
have
task-based
workflows
that
have
events,
raw
events
like
Cloud
events
and
and,
like
perhaps,
a
kubernetes
ecosystem
that
map
to
triggers
so
events,
don't
necessarily
events
can
have
different
forms
or
functions,
and
we
have.
We
have
task
types
like
lent
scan,
merch,
build
and
things
like
that.
Some
of
these
terms
are
recognized
by
cncf
work
groups
because
they
have
a
common
CI
CD
build
a
work
group,
that's
working
on
stages,
if
you
will
they're
called
stages,
so
we
have
tasks
themselves
can
have
a
resource
instance.
J
So
you
can
actually
point
to
the
instance
that
this
task
was
so.
This
could
be
a
task
run
in
in
tecton
or
our
workflow
and
again
the
task,
a
workflow
is
a
task,
so
it
can
be
a
workflow
run.
If
you
will,
you
can
link
to
those
things,
you
can
give
it
a
name
description,
and
you
have
start
time
and
end
time
recorded
So.
These
can
also
in
terms
of
mapping
to
things
that
can
you
can
actually
record
your
steps.
If
you
want
you
describe
your
workspaces,
your
inputs
and
outputs
and
inputs.
J
Outputs
are
what
I
think
is
interesting
to
the
current
conversation
as
well
as
runtime.
Topology
sorry
got
a
meeting
coming
up
so
trying
to
quickly
move
ahead.
Just
to
give
you
a
ten
thousand
or
five
thousand
foot
view
of
scope
so
event
trigger
tasks
we'll
skip
over
that
input
schema.
So
this
goes
back
to
every
task
has
inputs
and
outputs
that
again,
the
runtime
provides
these
things.
J
Actually,
where
you
put
these
things
in
terms,
you
can
capture
resources,
so
resources
can
be
configuration
files,
so
things
like
Q
files
like
frisca
talks
about,
as
well
as
the
the
actual
the
yaml
file
you
send
into
Cube
cuddle
to
actually
instance,
you
to
rest
all
those
things
can
be
captured
as
inputs
if
parameters
and
environment
variables.
So
this
goes
back
to
you
could
use
this
for
make
files
or
other
systems
as
well,
so
I
also
validated
this
against
Jenkins
and
you
know
basic
make
files
as
well
as
data.
J
So
if
you
have
raw
data,
perhaps
your
building
environment
brings
in
raw
data.
So
again,
these
are
things
that
the
runtime
permits
or
introduces
into
the
task.
So
you
have
a
clear
or
you
actually
can
explicitly
say
what
what
you,
what
you
brought
in,
so
resources
can
be
brought
in
as
well.
So
we
any
attached
resources
like
a
git
resource
and
a
tech
time
thing
which
I
know
our
deprecated
are
going
away,
but
people
still
use
them,
but
if
new
model
you'll
bring
in
services.
J
So
if
you
have
an
attached
service
that
is
brought
into
a
task,
you'll
represent
a
service
as
an
input
as
well,
and
you
can
actually
describe
your
topology
that
the
task
is
run
on
as
well,
which
I'll
show
in
a
second
but
I'll
show
output
first,
so
output
has
the
same
thing.
It
has
where
the
source,
so
the
source
could
be
this.
We
copied
this
from
this
location,
or
this
workspace
into
a
Target
repository
you
can
describe
the
resource
and
resources
can
be
described
as
described
through
two
mechanisms.
J
An
actual
explicit
definition
here
is
a
file
and
I
can
describe
it
as
a
component
of
the
bill
of
materials
or
I
can
describe
as
a
you
know,
external
reference
and
qualify
it
with
a
schema.
It
can
be
qualified
with
a
schema
to
your
to
Mark
said
earlier,
so
you
know
how
to
parse
it
or
use
it.
You
can
sit
in
the
target's,
the
repository,
here's,
the
resource
identifier,
where
do
I
get
it
from?
What's
it
schema
and
here's
its
URL,
so
you
can
declare
all
those
things
and
external
resources
as
well.
J
It
can
have
a
plurality
again
of
your
inputs
and
outputs,
and
you
have
properties
for
extension.
So
if
you
want
to
add
tag
in
your
or
your
own
typing
system,
you
can
actually
add
those
properties
and
tag
these
inputs
and
outputs
as
well
in
terms
of
conception
concept.
Is
that
basically,
you
describe
in
your
formula
concrete
resources,
so
this
is
where
I
would
describe
my
all
my
images
in
the
ingredients.
J
It's
like
a
recipe
here
are
all
the
ingredients
and
the
formula
on
the
right
is
all
the
tasks
mix,
all
the
ingredients
together
and
what
were
the
outputs
and
how
do
we
mix
them?
And
when
do
we
mix
them?
What's
the
instance
and
things
like
that,
so
on
the
left,
you
would
describe
things
like
configuration,
yaml
files,
Q
files
tools,
you
bring
into
the
system
repositories
that
are
associated
with
your
system
as
outputs
or
inputs,
and
actually
things
like
Hardware
built.
So
anything
you
run
your
topology
on
as
well.
J
So
if
you
have
container
images
you're
running
so
I
know
that
we
have
a
specific
Canon
camera
image.
It
has
a
bomb.
We
can
reference
that
that
runs
on
a
tacton
delivery
service.
We
still
have
a
bomb
for
the
IBM,
continuous
delivery
service
that
runs
on
and
we
have
another
another
bomb,
the
hardware
bomb
for
the
for
the
tool
chain,
team
that
been
described
with
Hardware
it
ran
on.
So
all
these
are
capturable
and
a
in
a
in
the
runtime
topology,
which
is
shown
shown
here
so
resource
references.
J
So
resources
can
be
either
in
this.
In
the
current
Cyclone,
GX,
specs
or
either
components
and
components
are
anything
that
you
would
think
of
the
resource
in
spdx.
It
can
be
a
actual
package,
a
library
it
can
go
down
to
a
file.
It'll
include
data,
machine
learning,
data
models,
and
things
like
that.
Eventually,
when
that
part
of
the
spec
comes
out,
any
inputs
can
be,
you
know,
concrete
inputs
can
represent
as
a
component
necessarily
and
then
in
terms
of
external
references.
J
So
in
the
some
people
are
not
aware
so
run
type
topology
with
the
rely
on
Headline
is
called
a
bomb
link.
So
if
you
describe
a
resource
that
was
run
on
a
work,
a
GitHub
action,
it
was
a
get
action
run
on
a
GitHub
workflow.
You
can
actually
describe
your
your
your
file,
you
can
say,
and
here's
my
repository
if
you
want
to
describe
your
repository-
and
these
are
ingredients
in
your
inner
component,
but
in
a
runtime
context
in
a
formulation
context
you
can
actually
describe
for
a
set
of
context
as
well.
J
You
can
actually
reference
here's
the
here's,
the
resource,
here's,
the
descriptor
and
the
hardware
and
software
that
this
thing
ran
on
someplace
else,
and
you
can
link
it
to
your
current
formulation.
Basically
you
can
say:
here's
the
you
know:
here's
ibane's,
continuous
delivery
service
or
here's
Red
Hats.
You
know
open
shift
pipeline
service
and
you
can
actually
have
a
bomb
for
that.
You
can
link
it.
You
link
it
to
that
and
then
you
can
go
even
further
for
your
run.
J
You
would
have
instance,
and
if
you're,
that
customer
you
should
have
access
to
your
contractual
access
to
say
well,
tell
me
you
know
externally:
I
can't
see
it,
but
internally
here's
my
instance
Give
me
the
give
me
the
the
bombs
that
represented
my
run
internally
as
well,
so
as
a
concept
of
internal
bombs
and
external
bombs
based
upon
contractual
agreements
and
and
things
like
that,
but
there
should
be
a
public
descriptor
of
every
build
service.
Clearly
that
can
be
LinkedIn,
that's
kind
of
where
it's
getting
at
so
I
mean
I'll.
J
C
But
we
want
to
draw
like
a
box
around
it
of
the
build
and
just
say
like
at
the
very
top
level
you
built
from
you
know
this
get
repo
like,
let's
say,
Let's
Pretend
getting
up
actions.
This
could
have
GitHub
actions
from
this
get
repo
in
this
workflow,
like
that's
it
and
by
drawing
the
Box
around
that
it
makes
it
practical
in
order
to
like
form
expectations
of
like
what
should
be
done.
C
So
when
you
like,
if
you
know
oh,
this
is
normally
built
by.
You
know
this
particular
git
repo
from
this
workflow,
but
now
I
see
a
build,
that's
built
from
something
else
like
you
could
detect
that,
and
so
like
recording
all
the
details,
while
valuable
for
other
use
cases
is
not
really
very
valuable.
For
that
use
case
because,
like
you
don't
kind
of
know,
the
details
like
like
there's
kind
of
it's
too
much
detail
to
know
like
what's
expected
and
what's
not
so
in
Cyclone,
DX
formulation.
C
J
Again,
welcome
on
off
a
dedicated
session
to
go
against
it.
So
I
understand
what
you're
saying
I
just
I
just
I
again
in
terms
of
in
you
know,
I,
don't
know
the
spec
inside
out
I
relied
upon
other
people
who,
from
my
company
and
red
hat,
who
attend
this
call
to
represent
those
things.
I
just
know
that
we
both
have
a
goal
of
capturing
sauce
level,
three
plus
and
information,
including
provenance
pedigree,
and
these
things
and
all
I
know
is
I
can
I?
J
Can
we
can
try
to
do
a
mapping
of
what
you're
doing
to
what
I'm
trying
to
do
in
in
the
recycling
DX
specification?
But
again
it
comes
down
to
I,
believe
it
you
have
to
have.
You
know
to
be
able
to
reproduce
liable
reliably.
You
need
to
have
that
a
type
of
chronological
order
of
what
tasks
did.
What,
with
what
inputs
done
to
that
level?
And
that's
you
know
that
came
across
so
again,
I
have
to
revisit
the
goals
that
you
stated
and
and
see.
H
F
C
The
idea
is
that,
like,
when
you
say,
like
I
built
this
thing
with
GitHub
actions,
and
here
was
the
source
repo-
and
this
was
the
workflow
here-
here's
here's
an
example
of
of
one
I'll
put
it
in
the
chat
room,
not
that
that
I'm
saying
this
is
necessarily
perfect
and
there's
an
example
down
at
the
bottom,
I
think
from
a
salsa
build
perspective
or
most
interested
in
here.
Let
me
actually
it's
probably
useful
for
me
to
present.
C
It's
just
listed
as
an
example,
but
do
they
just
make
sure
the
builds
to
know
like
the
hello
world
program
is
supposed
to
be
built
from
the
octocat
repo,
and
every
version
is
always
built
from
that
repo,
and
if
you
suddenly
see
one
from
a
different
repo,
you
know
that's
an
indication
that
something
is
you
know
not
as
expected
and
so
that's
kind
of
what
we're
trying
to
represent.
But
this
schema
is
different
for
different
build
systems.
C
Originally,
we
kind
of
tried
having
like
one
but
like
it
was
hard
like
you
know,
to
find
like
what
is
the
common
things
that
all
things
have.
But
then
it
was
hard
for
different
systems
to
map
because,
like
tecton,
has
different
cons,
slightly
different
concepts
than
GitHub
actions,
which
has
different
ones
than
like
Circle,
CI
Etc.
C
And
so,
instead
of
trying
to
do
that
with
1.0,
we
said
we'll
just
say:
the
build
system
can
describe
it
in
whatever
schema
make
sense
to
them,
and-
and
so
people
can
actually
understand
like
when
you
know
what
a
workflow
is
and
then
like
how
you
interpret
that
is
like.
What's
in
the
rest
of
the
talk.
G
Yeah
and
just
as
FYI
I
know
that
I
don't
know
if
folks
have
seen
it
yet,
it's
been
posted
a
couple
times
in
the
slack
macaron,
which
is
made
by
Oracle,
is
actually
going
out
and
verifying
some
of
this
sort
of
stuff.
So
it
actually
goes
out
and
looks
at
like
it
tries
to
First
understand,
obviously
the
intent
and
then
based
on
the
schemas
that
are
coming
out
of
these
things.
G
C
C
J
Just
I'll
just
say:
Obviously
in
general,
we've
gotten
to
problems
in
in
Cyclone,
Jackson
and
I
have
spdx
as
well
and
trying
to
create
typing
systems,
because
it
implies
that
especially
down
to
discrete
types
of
components
owned
by
companies,
because
you
get
the
problem
of
swedes
and
cpes.
You
have
to
credit
registry,
and
things
like
that
so
in
in
my
mind,
types,
if
you
use
a
typing
sub,
it
should
provide
a
journal
type
and
plot
a
pointer
to
the
actual
service.
If
you,
if
you
will
and.
J
D
So
the
build
type
is
actually
meant
to
be
a
URI
as
a
question
in
the
example
of
Oxford.
But
indeed
the
question
is,
you
know:
do
we
need
the
registry,
and
what
does
that
look
like?
Does
that
include?
You
know
all
the
definitions,
or
is
it
just
a
pointer
to
a
definition,
that's
held
somewhere
else?
That's
the
kind
of
food
issue
we're
talking
about
that
Mark
and
I
have
been
discussing.