►
From YouTube: CDF - SIG Interoperability - 2021-04-15
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
B
A
Yeah,
this
is
the
kind
of
meeting
where
so
I'm
not
I'm
in
central
time
zone
and
most.
D
A
The
people,
a
lot
of
people
offer
on
a
lot
of
people.
We
work
with
are
on
west
coast,
so
they're
pacific,
so
it's
8
a.m
from
them.
But
for
me,
it's
10
a.m
and
I
already
did
a
little
workout.
So
I
kind
of
this
is
the
only
time
a
meeting
is
like
perfect
for
me,
because
it's
I
have
a
little
time
to
start
the
day.
C
A
A
I
think
for
anyone
who
hasn't
met
me,
I'm
your
program
manager
for
cdf.
I
work
for
linux
foundation.
I
usually
have
a
conflict
at
this
time,
so
I
don't
usually
come
to
this
call,
but
I
just
want.
I
had
a
little.
I
have
half
an
hour
free,
so
I
want
to
just
jump
on
and
say:
hi.
C
C
E
Yes,
you
don't
realize
I'm
just
hugging
here,
so
I'm
victor
martinez.
This
is
my
very
first
time
attending
your
meeting.
E
Vocabulary,
I
also
saw
the
yankees
x
already-
I
enabled
some
observability
for
the
project
itself,
which
shows
which
is
really
exciting.
E
So
we
we
have
a
plugin
for
jenkins
and
I
would
like
to
listen
or
see
if
there
is
a
specific
note
about
aligning
the
or
normalizing
the
terminology
regarding
ci
cd,
because
this
is
really
important
as
well
to
have
a
same
common
schema
for
everyone.
So
this
is
the
area
of
interest.
I
relate
to
this
a
little
bit
as
well.
C
Thanks
for
joining,
I'm
sure
you
found
the
rosetta
stone,
we
call
rosetta
stone
in
our
repository
and
just
so
you
know
we
have
best
practices
seek.
They
also
work
on
glossary
like
more
general
cic
terms
as
well,
which
you
may
want
to
look
at.
I
can
put
the
links
on
chat,
which
you
can
check
them
out.
F
I'm
I'm
gopinath
ariballa,
I'm
a
cto
of
opsimix,
so
we
are
one
of
the
core
contributors
of
spinnaker
and
we
have
a
bunch
of
customers
with
spinaker.
We
are
also
building
a
intelligence
layer
on
top.
Basically
that
requires
all
the
data,
and
I
saw
the
interoperability
is
the
right
place
where
we
are
working
on
the
same
issues,
so
I
thought
I'll
join
in
and
see
what
we
can
do
to
contribute
and
also
learn.
C
Thanks
so
let
me
share
my
screen.
I
think
I
haven't
missed.
C
Okay,
so
the
agenda
for
today
is
a
bit
light,
because
we
have
a
gate
with
us
talking
about
spdx
and
we
will
continue
an
open
discussion
on
how
we
can
elevate.
But
before
that
topic
we
have
a
few
logistic
type
of
topics
and
the
first
one
is
as
usual
action
item.
We
will
followed
up
by
a
quick
question
about
what
will
be
the
next
with
our
next
meeting
and
then
another
topic
is
about
cdcon.
C
The
schedule
was
announced
this
week,
I'm
not
mistaken,
so
we
can
talk
about
that
and
maybe
tracy
you
want
to.
You
know,
give
some
highlights
about
some
of
your
plans
and
then
we'll
have
spdx
discussion
and
if
the
time
permits
we
can
take
a
look
at
policy
driven,
cicd
stuff,
which
we
had
some
contributions
a
few
weeks
ago,
and
if
you
have
a
short
topic
you
want
to
bring
up,
we
can
take
it
before
we
start
this
pdx
as
well
the
longer
topic
time.
We
will
see
how
much
time
we
will
have
for
that.
C
C
B
So
I
did
that
already
during
the
meeting.
Yes,
the
last
last
two
weeks
two
weeks
ago,.
B
I
guess
I
added
some
more
comments
somewhere.
I
think.
C
C
Watching
but
that's
only
right
and
the
next
topic
is
the
next
seeking
probability
meeting
well,
as
you
know,
seeking
interoperability
meets
first
and
third
third
days
of
each
month,
so
our
next
meeting
will
happen
on
may
6th
and,
as
you
know,
coupon
takes
place
between
may
4th
and
7th,
and
since
it's
in
europe
it
may
not
conflict
with
our
meeting.
C
C
G
So
yeah
just
please
to
announce
that,
after
working
with
the
program
committee
and
going
through
all
the
amazing
talks
folks
submitted,
we
have
the
final
program
out
for
cdcon,
as
well
as
the
additional
events,
so
github's
summit
the
day
before
and
spinnaker
summit,
which
is
running
in
parallel
throughout
the
conference,
so
encourage
folks
to
to
go
ahead
and
register
thanks.
G
I
can
see
lots
of
folks
on
this
call
who
submitted
talks
that
were
excellent
and
were
selected,
and
I
think
we'll
be
adding
on
additional
things
to
that
program
and
very
likely
having
a
birds
of
a
feather
session
for
for
this
group
as
a
chance
to
summarize
all
activities
and
particularly
welcome
new
folks
and
get
them
involved.
So
if
you
haven't
already,
please
go
ahead
and
register
and
let
me
know
if
there
are
any
questions
but
yeah
we're
very
much
looking
forward
to
a
great
event
in
june.
C
Thanks
stacey,
when
I
was
looking
at
the
schedule
actually,
I
noticed
an
interoperability
talk
given
by
someone
I
haven't
seen
in
our
meetings
or
in
cdf
like
other
meetings,
so
it
was
interesting
to
see
an
interval
talk
coming
from.
You
know
another
person
who
is
interested
in
this
area
so
which
was
great
to
see
actually
so
that
is
all,
and
we
have
all
the
links
here.
C
Cdc
only
tops
and
spinning
summit
schedules
and
also
registration
link,
and
I
think,
when
you
register,
for
when
you
go
to
registration,
you
can
register
all
three
on
the
same
registration
flow,
so
they
are
there,
and
that
is
all
just
last
time.
Anyone
wants
to
bring
up
a
quick
topic
before
we
start
the
spd-x
and
give
the
floor
to
kate.
C
Okay,
so
kate,
welcome
again,
I
can
stop
sharing
and
if
you
want
to
share
something,
please
do
that
yep
and
I
stop
talking
as
well
thanks.
Okay,.
D
So
I've
basically
pulled
together
a
bit
of
an
overview
software
bill
of
materials
as
a
so
just
a
bit
about
my
background.
I
work
at
the
linux
foundation
and
have
been
involved
in
spvdx
since
way
before
I
even
joined
the
linux
foundation
and
have
continued
my
interest
in
it.
D
Quite
frankly,
too
back
when
I
was
doing
software
software
development
kits
when
I
was
at
freescale
and
my
colleagues
at
wind,
river
and
monte
vista
had
the
same
problems
and
then
I
talked
to
people
with
linux
foundation
and
we
found
out
that
a
bunch
of
other
people
on
the
legal
side
had
the
same
problem
too.
So
we
started
software
package
to
exchange
off
to
exchange
software
building
materials
about
the
open
source
software
we're
shipping.
D
However,
the
concept
has
sort
of
been
evolved
from
there
and
is
useful
in
other
domains
rather
than
just
licensing.
In
particular,
there
are
three
perspectives
across
the
supply
chain
and
everyone's
pretty
much
hearing
these
days
about
software
supply
chain
attacks,
but
there's
people
who
produce
software,
those
who
choose
it
and
those
who
are
operating
it
and
each
of
those
perspectives
has
different
needs
for
an
s-bomb.
D
The
ones
that's
hitting
the
news
right
now,
obviously,
is
you
know:
am
I
affected
by
a
vulnerability
having
an
accurate
software
building
materials
for?
What's
actually
on
your
system?
Lets
you
be
able
to
automatically
query
this
type
of
information
and
understand?
What's
there,
and
so
certainly
things
like
solarwinds,
that's
been
pretty
prominent
in
the
news
invisible.
D
D
D
D
However,
black
duck
just
came
out
with
their
open
source.
Synopsis
is
open
source
risk
report
this
week,
and
so
I
updated
the
slide
for
this
one.
But
at
this
point
now
it's
98
of
the
code
bases
of
open
source
and
75
of
the
of
that
code
that
they
audited
was
open
source,
and
you
see
that
they're
referencing
the
fact
that
the
risk
aspects
of
licensing
as
well
as
vulnerabilities
coming
in
so
sonotype,
is
seeing
the
same
thing
from
component
side.
D
D
Xkcd
is
a
wonderful
source
of
truth
and
this
problem
down
here
at
the
what's
hiding
underneath
there
is
what
we're
trying
to
have.
As
bombs
field
help
us
solve
so
there's
been
an
initiative
from
ntia
for
the
last
couple
years
and
they've
done
a
lot
to
raise
awareness
of
the
fact
that
we
need
to
have
this
software
bill
of
materials
in
the
supply
chain
to
help
deal
with
the
vulnerability
issue
from
their
perspective.
D
It's
you
know,
just
basically
the
relationships
between
the
components
and
with
that
information
we
can
do
a
lot
more
than
we
have
today,
so
we
obviously
want
it
automated
pretty
much,
there's
reasons
to
make
s-bombs
in
any
point
in
time
in
supply
safely
in
the
software
supply
cycle,
there
is
obviously
as
we're
doing
our
development
and
build
and
see
icd
pipelines.
This
is
an
area,
that's
obviously
rich
to
generate
as
we
go
along
and
have
a
good
source
of
truth
at
the
end
of
it
all.
D
The
fda
has
signaled.
They
are
starting
to
expect
an
sd,
an
s
bomb
for
medical
devices.
D
The
energy
sector
is
also
has
a
nercsip
13
out
there
and
in
europe
we're
having
the
anissa
cyber
security
for
cloud
services
starting
to
show
up
having
an
s
bomb,
mind
you,
they
expanded
a
software
board
of
materials
as
opposed
to
build
materials,
but
we
think
this
is
a
typo
but
you're
also
seeing
some
types
of
query
risk
chain
management.
This
is
from
the
energy
sector
and
they're
starting
to
expect
this.
D
So
it
is
useful
for
many
different
other
facets
as
well.
Some
people
may
have
heard
of
the
open
chain
project.
It's
expecting
you
to
create
a
bill
of
materials
as
part
of
what
you're,
sharing
and
there's
a
lot
of
adoption
of
open
chain
now
in
various
compartment
organizations,
so
being
able
to
automate
and
create
these
build
materials
with
some
degree
of
confidence
is
a
goal
that
we
sort
of
need
for
the
industry,
and
the
financial
sector
is
saying
this:
you
know
if
it
has.
If
they
have
it,
it
saves
some
time
for
vulnerability.
D
D
Is
you
know
I
had
my
data
in
one
form
and
went
river,
had
it
in
another
form
and
one
of
us
to
headed
in
a
third,
and
we
had
no
formal
way
of
sharing
the
information,
so
this
is
still
pretty
much
valid
and
so
at
the
heart
of
a
minimum,
viable
furnace
bomb.
It's
these
fields,
a
supplier
named
component,
unique
identifier,
version
string,
component,
hash
and
relationship
and
whoever
created
the
s
bomb.
D
There's
work
going
on
to
extend
beyond
this
just
minimum
set
right
now
in
the
nti
working
groups
that
are
focusing
on
this,
but
all
the
formats
that
they
accept
or
you
know,
approve,
etc,
can
supply
support,
at
least
this,
and
so
the
three
formats
that
are
endorsed
at
this
point
in
time,
or
at
least
you
know
reference
to
rspdx
with
cyclone
dx,
so
I'm
obviously
gonna
be
talking
to
you
about
spdx,
but
I
just
want
you
to
know
that
there's
a
landscape
here-
and
it
is
important
to
understand
that
interoperability
between
these
is
going
to
be
important
as
well
down
the
road,
because
there's
different
purposes
behind
them,
but
to
make
things
effective
in
pipelines
and
like
see,
icd
and
so
forth,
tooling
is
going
to
be
required
and
people
need
to
be
able
to
produce
them,
and
ideally
this
is
all
produced
automatically
as
part
of
a
build.
D
That
is
the
best
case,
because
then
there's
probably
the
most
truth
into
it.
Sometimes
you
may
need
to
analyze
it
after
the
fact.
Like
binary
inspections
or
tools
like
physology,
those
are
options,
and
sometimes
you
need
to
potentially
even
edit
things
in
manually.
All
these
are
areas
where
we've
got
it
and
then
you
know,
if
you
create
it,
you
need
to
be
able
to
consume
it,
and
potentially
you
need
to
be
able
to
do
some
transformations
specifically,
you
need
to
consume
it
to
do
assessments
for
policies.
D
So
if
you
wanted
to
decide
whether
or
not
you
were
going
to
deploy
an
image,
there
may
be
information
in
the
s-bomb
as
to
whether
you
know
have
the
right
versions
of
a
certain
package
been
used
or
any
of
the
packages
contained
in
there
associated
with
known
vulnerabilities
that
have
not
been
remediated.
D
So
since
I'm
coming
back
in
it
from
the
cspdx,
this
is
sort
of
how
we're
looking
at
some
things
in
the
linux
foundation
right
now
or
parts
of
linux
foundation,
that
care
about
compliances,
we're
looking
at
trying
to
get
common,
tooling
available
using
this
common
data
format
and
then
making
sure
we
have
common
processes
and
norms
working
together,
that's
kind
of
where
the
focus
is
going
and
feel
free
to
interrupt
me
anytime.
So
I
just
want
to
you
know,
touch
on
the
open
chain
spec,
if
you're
not
familiar
with
it.
It's
now
an
iso
standard.
D
It
became
one
last
december
and
so
it's
easier
for
people
to
specify
procurement.
So
I
think
this
will
help
with
adoption
software
package
data
exchange
is
spdx.
D
D
So,
just
to
give
you
a
bit
of
history
is
we
started
working
into
foss
bazaar
in
2010,
and
this
august
will
be
our
10th
anniversary
of
the
specification
being
out
there
and
bit
by
bit.
D
We've
been
adding
use
cases
so,
as
people
are
trying
to
represent
certain
pieces
of
metadata
associated
with
software,
we've
been
trying
to
make
sure
we
can
represent
the
use
cases
either
with
what
features
that
are
there
already
or
we
start
adding
in
fields
and
sections,
and
so
we
have
been
evolving
this
pretty
much
through
the
this
period
of
time,
with
a
variety
of
stakeholders
coming
in
and
out
as
they're
in
interest.
D
You
know
are
on
sport
and
talks
to
make
sure
that
they
can
use
things
it's
fairly
well
adopted
in
most
tools
and
large
companies.
We've
got
a
fair
amount
of
adoption
there
on
their
internal
system,
so
lining
lighting
around
the
fields
and
information
there.
Now.
The
other
thing
we've
been
doing
in
the
last
release,
in
particular,
is
for
a
long
time.
We
just
had
rdf,
and
you
know
these
three
formats
and
then
two
two
we've
added
json,
yaml
and
xml.
D
I
mean
this
was
possible
because
it's
all
modeled
underneath
the
covers,
and
so
there's
a
coherent.
You
know
data
model
for
the
fields,
and
so
this
lets
us
do
the
transformations
into
these
different
formats,
which
helps
with
the
adoption
and
the
act.
Projects
are
ones
that
are
all
committed
to
working
with
spdx
as
their
interchange
right
now,
and
the
spdex
project
itself
has
tools
for
reading
and
writing
various
libraries,
so
there's
tooling
in
there
that
can
be
pulled
from
and
if
you've
learned
of
a
tool.
That's
not
on
this
list,
you
can
feel
free
to.
D
You
know,
consult
it
if
you
learn
one
feel
free
to
add,
but
I
think
what
I
really
wanted
to
talk
to
you
guys
about
now
that
I've,
given
you
the
background
where
we
are,
is
what's
happening
with
spdx3
in
the
sense
that
we're
reformatted
we're
refactoring
the
specification
into
a
base
which
will
align
closer
with
the
nti.
So
you
don't
have
to
carry
fields,
you
don't
care
about,
and
then
various
profiles
for
these
domains
of
interest
and,
in
particular,
there's
a
fair
amount
of
interest
of
having
something
for
pedigree
and
provenance.
D
So
as
I
go
through
this,
if
there's
questions
please
just
interrupt
me,
I'm
just
trying
to.
I
was
told
to
keep
it
to
about
half
an
hour.
So
I'm
trying
to
do
that.
D
So
if
I've
been
going
too
fast
too
feel
free
to
tell
me
to
go
back
up
if
there's
questions
as
well,
but
this
is
kind
of
where
we're
sort
of
heading.
To
give
you
a
little
bit
more
feel
for
this.
The
bass
is
going
to
have
elements
of
artifacts
being
packages,
files
and
snippets,
which
we
have
today
already.
D
We
are
probably
extending
our
identity
ability
and
making
that
a
bit
more
richer
and
automated
and
added
some
instructions
in
to
support
that
and
we'd
had
one-to-one
relationships.
But
there
was
a
strong
desire
for
some
of
the
use
cases
to
switch
them
over
to
one-to-many,
so
we've
been
modeling
and
working
on
that
and
the
spdx
document
become
a
document
itself.
That's
one
of
the
directions
we've
been
going,
so
there
is
various
in
base
we're
looking
at
things
like
external
document
refs
and
to
refer
to
another
document,
so
you
can
link
these
documents
together.
D
You
can
also
refer
out
to
other
external
repositories,
like
you
know,
maven
npm,
the
cpes
for
the
from
the
national
national
development
database,
pearls
package,
urls
and
then
software
heritage
ids
as
well,
have
been
added
as
references,
but
if
there's
other
things
that
make
sense
to
link
out
to
for
augmenting
information,
you
know
definitely
are
interested
in
those
cases
as
well
and
then
there's
a
group
working
on
improving
the
integrity
methods
we
already
have
hashes
and
we
already
hashes
on
groupings
as
part
of
the
specification,
but
again
interested
in
use
cases
and
interesting
to
see
if
we
can
satisfy
them.
H
D
It's
in
the
scope,
like
I
say
we
want
to
be
able
to
represent
everything
that
happens
in
a
build
eventually,
and
we
need
experts
in
these
areas
to
help
us
flush
this
out
properly
kind
of
what
it's
coming
down
to.
We
have
vmware
pretty
active
with
us
on
the
container
infrastructure
and
how
we
can
represent
things
effectively,
but
we
don't
have
a.
D
We
need
more
expertise
in
the
docker
instance
that
it
ends
in
some
of
the
built
in
fragmentation,
which
is
why
I'm
here,
because
I
think
you
guys
probably
have
some
of
the
knowledge
we
need
to
pull
in.
So
this
is
you
know
this
is
an
eye
chart
at
this
point
in
time,
but
this
is
sort
of
our
model
has
sort
of
evolved
into
this
for
the
base.
At
this
point,
and
then
you
can
sort
of
see
that
research
have
a
software
profile
emerging
which
is
effectively
this.
D
These
two
plus
the
licensing,
is
what's
in
spdx22,
but
we
are
making
certain
elements
and
aspects
richer
and
evolving
them,
so
the
licensing
profile,
the
heart
of
it's
going
to
be.
You
know
this
is
sort
of
there
today
there's
a
declared
license
and
things
there's
a
concluded
license
and
then
there's
some
copyright
text
and
you
could
be.
You
could
be
wanting
this
level
of
information
at
a
package,
a
file
or
even
at
a
snippet
level.
D
So
we've
been
extending
the
model
to
make
this
possible
it's.
You
know
it's
sort
of
there
today,
but
it's
a
lot
of
fields
and
so
we're
trying
to
simplify
certain
things
and
one
of
the
things
that's
pretty
powerful
in
spdx
is
you
do
have
the
ability
to
use
an
and
or
to
actually
describe
and
figure
out,
the
relationships
between
licenses
and
software?
There's
also
the
concept
of
none
and
no
assertion
that
you
can
use
in
this
expression
syntax.
D
So
we
do
have
you
know,
because
these
are
things
that
are
interesting
from
a
risk
and
from
a
deployment
perspective.
If
you
have
not
complied
with
the
licenses,
people
do
not
want
to
deploy
the
software.
D
It
causes
a
lot
of
problems
when
you
do
otherwise,
so
making
that
automated
making
it
easier
to
do
is
obviously
something
we
still
want
to
preserve
and
potentially
even
improve,
and
the
modeling
that's
being
worked
on
from
the
licensing
side
is
roughly
looking
like
this.
At
this
point
and
from
the
licensing
there's
also
a
license
list
which
a
lot
of
people
know
from
4s
pdx
and
we're
just
actually
five
312
came
out
recently.
D
Sorry,
I
need
to
update
that
slide
too,
but
313,
it's
probably
gonna,
be
coming
out
at
the
end
of
the
month
and
so
any
license
that's
commonly
for
open
source.
We
put
in
yeah,
go
for
it.
I
Most
software
projects,
I've
been
involved
with
open
source
or
internal
doesn't
matter
usually
adhered
to
a
single
license.
In
fact,
I'm
having
a
hard
time
imagining.
How
would
I,
how
would
I
create
a
project
that
adheres
to
multiple
licenses,
but
are
you
talking
about
licenses
that
are
part
of
your
open
source
that
you're
using
and
you're
kind
of
graphing
it
out,
or
is
it
just
your
own
software.
D
I'm
talking
about
the
open
source,
that's
out
there.
We
have
that
we
have
people,
have
this
assumption,
that
a
project
isn't
just
that.
You
know
if
the
project
declares
a
license
at
one
level,
that's
what
it
stays
at
lots
of
people
bring
open
source
from
one
plate
project
to
another
and
they
carry
the
license
of
the
origination
with
them
into
these
other
projects
and
to
a
large
extent,
things
are
compatible.
I
I
You're
trying
to
graph
out
everything
that
a
particular
project
uses
and
it's
yeah,
it's
very
likely
that
you'll
run
into
incompatibilities
between
licenses
so
yeah,
okay,
thank
you.
D
You
need
to
do
it
on
security
in
some
ways,
one
of
the
there's
another
little.
You
know
thing
that
people
comfort
themselves
with
is:
oh.
If
we
just
map
out
what's
happening
at
the
package
level
and
our
relationships
between
that
we'll
be
able
to
solve
things.
D
The
challenge
is
that
when
the
images
you
build
may
or
may
not
have
depend
vulnerabilities
in
it,
depending
on
the
options
you're,
giving
the
configs
you're,
giving
it
and
being
able
to
be
able
to
be
definitive
about
things
like
that
is
costing
you
know
taking
a
lot
of
effort.
So
you
know,
I
don't
think
I
don't
see
the
ecosystem
switching
to
the
fire.
Higher
fidelity
immediately,
I'd
quite
frankly
be
happy
just
to
get
them
to
have
s
bombs
for
the
packages,
but
realistically
over
time.
D
I
do
think
we're
going
to
need
to
get
to
the
source
level,
at
least
on
some
critical
components,
for
critical
infrastructure,
because,
like
amnesia
33,
when
it
came
out
last
year,
the
zephyr
project
actually
used
fnet
in
the
lts
version
of
it,
not
in
the
current
version,
but
the
lts
version.
However,
we
could
not
assert.
We
had
to
basically
put
out
an
advisor
saying,
hey
we're
not
affected
here,
because
we
were
not
using
that
part
of
the
code
in
the
images
that
were
zephyr.
H
D
Well,
if
you
go
actually
and
look
at
the
licensing
in
linux,
you'll
see
about
30
licenses
in
there
right
now.
D
So
there's
a
lot
of
key
components
that
you
know
these
things
have
come
into
and
keeping
active
eye
on
not
letting
incompatible
licenses
in
is
something
that
you
know
projects
do
some
projects
pay
attention
to
more
than
others.
I
guess
I
could
say.
H
Well,
will
the
will
the
model
change
slightly
to
deal
with
the
scenario
that
you're
talking
about
where
you
have
individual
licenses
at
the
source
level
within
a
package,
or
is
it
already
handled.
D
Already
handled,
we
can
even
represent
individual
licenses
at
the
snippet
level
if
we
need
to
okay,
because
one
of
the
common
things
that
happens
in
composition
systems,
specifically
in
the
java
space
is,
you
know,
people
will,
you
know,
assemble
their
code
from
places
so
to
speak
and
their
composition,
they're,
taking
snippets
from
places
and
they're,
putting
it
there
and
they're,
not
paying
attention
necessarily
to
the
license
thing,
and
so
some
of
the
source
code
analysis
tools,
find
these
elements
out
and
say:
hey,
you
know
the
correct
provenance
for
this.
Is
it
came
from
this
project?
D
We
added
that
in
about
five
years
ago
for
the
use
cases,
so
licensing
is
fairly
well
handled,
one
of
the
things
that
we
are
getting
pressure
towards,
and
so
there's
a
group
in
japan.
That's
sort
of
focusing
on
this
and
taking
the
lead
here
is
usage
being
able
to
sort
of
along
with
an
image,
and
it's
metadata
say
what
you're
allowed
to
do
with
it
and
be
able
to
send
that
through
the
supply
chain.
D
So
you
know
as
you're
building
up
your
you
know:
cars
and
automotives
and
all
the
software
in
there
you
need
to
be
able
to.
You
know,
pull
all
these
pieces
together
and
if
a
component
hasn't
been
qualified
to
the
right
level,
they
may
not
want
it
going
to
production.
So
you
want
to
be
able
to
signal
that
somehow
and
some
similar
cases
end
of
life
you
know
being
able
to
convey.
D
This
is
very
common
in
the
commercial
space.
But-
and
you
know,
open
source
projects
have
end
of
lives
too,
but
people
don't
know
how
to
convey
that
information
so
being
able
to
convey
these
type
of
information
through
the
supply
chain,
with
the
software
when
you're
actually
making
it
and
when
there
are
known
end
of
lives
will
hopefully
let
us
see
when
there's
weaknesses
and
issues
showing
up
faster.
C
Because
you,
I
use
the
keyword
policy,
I
am
coming
from
telco
sector
and
in
telco
there
are
lots
of
conversations
about
policy,
governance
and
such
things
and
some
of
the
things
you
highlighted
now
and
in
previous
slides.
Like
could
this
software
be
put
on
production
because
it
has
some,
you
know,
dependency
use.
That
is
end
of
life.
C
No,
it
can't
code
production,
because
if
someone
wants
to
call
991-
and
this
may
cause
failure
for
it
because
like
no
bucks
fixed
in
that
dependency,
so
it's
like
it's
now,
because
why
I'm
talking
about
this
now
is
like
our
next
topic
is
policy
and
like
I
never
I
actually
say
I
know,
but
I
didn't
really
think
about
connection
between
between,
like
the
metadata
and
policy
at
this
level.
I
was
like
talking
about
dependencies
stuff,
but
not
on
this
level.
Choice.
Dependencies.
D
I
think
that's
where
we
need
to
get
to
for
this,
and
so
coming
up
with
these
standard
formats
and
being
able
to
share
these
things
across
the
ecosystem,
from
open
source
and
free
tools
all
the
way
through
proprietary
into
you
know,
individual
companies
organizations
is,
you
know
the
ecosystem,
we've
gotta
sort
of
shift
by
you
know
aligning
around
a
few
things.
D
Vulnerabilities
there's
a
group
that
wants
to
start
catching
some
of
the
vulnerability,
information
and
assertions
about
it
in
there
and
so
thomas
deanbergen
from
here
dot
com
and
is
basically
he's
also
one
of
the
leads
on
the
oss
review
toolkit
or
ort
and
they're
they're
actively.
You
know
having
that
tooling
available
to
be
used
with
builds
and
so
forth,
and
he
wants
to
he's,
got
the
use
cases
to
start
catching
the
vulnerabilities.
D
So
people
are
interested
in
that
and
some
of
those
discussions
that's
actively
ongoing
we're
trying
to
keep
it
interoperable
with
cyclone
dx
and
how
they
do
it
and
csaf
group
is
basically
revising
their
spec.
That's
coming
in
from
the
oasis
side
and
they've
got
some
terminology
they're
doing
so
we're
trying
to
align
in
with
what
is
emerging
as
well
or
at
least
what
people
are
trying
to
standardize
on
in
other
groups,
so
that
we
have
something
that's
going
to
be
hopefully
coherent
between
these
different
organizations
from
linkage.
D
This
is
sort
of
the
relationships
in
connect
and
we've
been.
We've
had
relationships
right
now
in
current
spec,
we're
thinking
about
looking
at
making
a
first
order
object
with
additional
properties,
and
this
is
kind
of
where
the
container
folks,
like
lasker
and
nisha
and
so
forth,
are
focusing
on
to
make
sure
that
their
use
cases
can
be
represented
effectively
and
that
we
have
the
right
level
of
hierarchy
and
naming
you
know.
How
do
you
deal
with
layers?
D
You
know:
what
are
we
going
to
capture
things
like
that,
so
there's
linkage
that's
coming
into
there
and
I'll
bring
this
back
up
right
now,
just
to
go
through
it
after
I
finish
these
slides,
but
the
whole
aspect
of
pedigree
and
providence,
we
sort
of
consider
it.
You
have
your
upstream
supplier
or
a
third
party.
D
So
if
we
take
a
look
at
that
model,
we're
pretty
much
considering
pedigree
to
be
everything,
that's
going
through
your
build
and
providence
is
who
has
had
you
know,
who's
had
their
hands
on
it
as
it's
been
going
through
the
supply
chain,
effectively
your
components,
and
so
you
know
this
is
that's
kind
of
the
definitions,
we're
working
with
right
now
and
there's
people
who
want
to
get
together
on
this.
One
for
discussing
in
this
I've
been
in
discussions
already
with
reproducible
build
folk.
D
So
I
want
to
certainly
make
sure
we
align
in
on
terminology
that's
being
used
and
ideally
help
define
it
from
some
of
the
work
you
guys
are
doing,
and
then
provenance
is
okay
as
it's
moving
between
people.
How
do
we
have
assurance
that
you
know
people
haven't
been
sabotaging
it
along
the
way?
You
know
these?
D
There
there
is
a
project
called
sparks,
or
software
parts
that
wind
river
put
into
the
hyperledger
incubator.
D
The
other
project
that's
emerging,
is
alvarium,
that's
looking
at
trust
fabrics,
and
so
what
I'm
trying
to
do
with
spdx
is
try
to
make
sure
we've
got
the
data
to
feed
all
of
these
for
d-bomb.
It's
basically
looking
encapsulation
of
the
information
and
then
attesting
to
the
identities
in
the
provenance.
D
So
I
guess
the
conclusion
I
had
is
it's
in
development
now
I
said
well
like
say:
you'll
be
hearing
noise
in
the
summer,
probably
about
spdx
coming
out
of
iso,
but
we're
working
on
the
next
generation
for
it,
and
what
I
want
to
do
is
make
sure
we
have
the
right
use
cases
so
that
when
we
come
up
with
spdx3,
you
know
towards
end
of
year
next
year,
somewhere
in
that
range,
it'll
be
useful
for
people
starting
to
work
on
policies.
K
Of
it
in
a
nutshell,
hopefully
that
was
coherent.
Okay.
This
is
tracy
from
deploy
heaven
ortilius.
I
know
that
probably
most
of
the
people
on
this
call
are
getting
excited
about
this
talk.
But
this
is
what
you
know
steve
and
I
have
you
know,
thought
about
how
to
present
this
data
for
quite
some
time.
So
thank
you
so
much
for
being
here
and
going
through
that
and
going
through
what
you're
up
to
we
are
integrating
with
spdx
and
cyclone
from
the
point.
K
So
there's
and
then
we
roll
it
up
at
the
logical
application
level.
So
all
of
this
can
be
shown
from
a
microserver's
perspective.
Everything
that
the
logical
application
is
consuming.
So
we
we
do.
The
good
news
is:
we've
already
started
from
the
cdf
side
of
the
house.
We
have
already
started
to
think
about
this
and
done
some
integration.
D
D
They
have
dependencies,
you
know
and
then
optional
test
dependency,
runtime
dependencies
examples
of
generates
generated
from
so
forth.
D
D
Spec
here
it's
all
in
markdown,
well
slow
thing,
and
you
can.
This
is
most
of
the
work
right
now
is
happening
in
the
discussions
in
the
meetings,
and
we
have
our
minutes
up
on
github.
Now
it
used
to
be
on
wiki.
We
had
10
years
of
meeting
meeting
history
on
wikis,
but
we've
got
it
up
on
github
now,
but
you
can
sort
of
go
through
and
go
into
the
chapters
and
sort
of
understand
what's
happening.
D
It
renders
nicely
in
the
other
version
you
saw,
but
if
you
sort
of
looked
at
those
relationships
here
list
just
between
spdx
elements,
you'll
see
that
it's
in
markdown,
it's
actually
just
it's
just
raw
markdown,
and
then
we
render
it
appropriately,
but
you
know
go
ahead
and
open
issues
to
what
you
need
it
to
be
like
and
the
issues.
If
there's
a
use
case,
you
can't
represent
you're,
not
trying
to
represent
just
go
in,
and
you
know
open
an
issue
here
against.
There
is
the
spec
and
we'll
be
working
on.
H
Could
you
jump
back
to
the
other
tab?
I
just
didn't
get
the
repo
yeah
that
one.
D
D
By
far,
that's
why
we
did
it,
and
you
know
the
aspects
of
the
specification
you
know,
kate.
K
D
D
Go
thank
you
I'll
put
the
spec
one
in
at
the
same
time
too.
In
case
you've
got
questions
and
issues.
The
tech
call
meets
every
week,
and
this
is
where
we're
working
on
x3.
D
So
if
you've
got
ideas
and
proposals
about
for
the
pedigree
at
some
point
in
time,
I'm
more
than
willing
to
spin
up
a
separate
meeting
ad
hoc
meetings
with
people
who
are
interested
in
it
to
start
talking
and
putting
a
proposal
together
to
present
to
the
tuesday
group
for
alignment
and
with
the
rest
of
it
for
the
pedigrees
I'd
like
to
get
a
starting
point.
So,
if
there's
someone
who
wants
to
work
with
me
on
that,
I
would
welcome
it
or
you
know.
D
K
Yeah,
let's
just
we'll
follow
up
with
you,
connect
with
me
on
linkedin
and
we'll
figure
out
a
time.
D
Okay,
great
gracie,
thank
you.
So
hopefully
that
gave
you
guys
a
bit
of
a
feel
did.
D
E
D
So
the
policies
and
the
framework
for
the
policies
there's
work
going
on
in
use,
I
think
there's
gonna
be
work
going
on
in
usage.
Basically,
we've
been
talking
to
some
of
the
security
people
and
they
have
various
risk
policies
and
risk
management
policies,
and
so
I
think
they're
sort
of
gravitating
around
usage
at
this
point
in
time.
D
But
there
was
you
know,
other
policies
that
are
out
there
are
things
like
you
know
the
graphics
and
critis
stuff
that
was,
google
was
working
on
or
is
still
working
on
in
total,
so
as
well,
so
we're
trying
to
pull
in
the
right
levels
of
metadata
so
that
policies
can
work,
but
we
do
not
have
a
policy
engine
for
evaluation
that
we've
standardized
on.
Yet,
if
that's
what
you're?
Asking?
Okay,
I'm
just
focusing
on
the
data
getting
to
getting
data
organized
and
lined.
D
F
F
D
How
does
so?
I
think
I
need
to
talk
to
you
and
I'm
trying
to
understand
anthos
versus
critics,
so
I'll
need
to
figure
that
one
out.
F
You
know
it's
only
a
relation
on
how
the
policies
are
implemented
in
life.
The
data
is
a
data
layer
right,
so
once
you
figure
out
which
process
you
will
use,
then
then,
based
on
the
data,
you
can
apply
those
kind
of
structure
to
it.
D
Okay,
cool
the
other
thing
I'd
like
to
talk
about.
You
were
talking
at
the
start
about
your
rosetta.
I
probably
should
take
and
look
sure,
look
through
this
and
also
line
up
and
see
if
to
some
extent
we
can
align
terminologies
or
at
least
pla,
and
highlight
where
there's
a
difference
of
when
people
are
using
the
same
term.
It
means
slightly
different
things.
D
I
know
I'm
sure,
but
yeah
so
because
we've
got
people
busy,
you
know
defining
what
they
want
in
the
spdx
world,
based
on
things
that
they're
coming
in
from
their
perspectives.
D
C
Yeah,
that's
the
link
I
put
vocabulary.nd,
it
kind
of
looks
at
the
terms
used
across
different
cic
technologies
and,
as
I
mentioned,
we
have
this
glossary
repo,
which
I
put
the
link
there.
I
think
it's
chrisley
wilson
started
that
reply.
D
So
we've
also
like
you
know
one
of
the
the
lead
for
the
of
the
base
profile.
Like
you
know,
the
base
part
of
the
profile
or
the
core
part
is
actually
william,
bartholomew
from
github
and
so
they're
pretty
engaged
in
this
as
well
with
us
and
yeah.
I
think
it
lab
has
got
their
stuff
too
cool.
You
know,
thank
you
for
those
links.
I
appreciate
them
happy
to
share
back
and
forth
no
problem
at
all.
Yeah.
L
C
Great,
can
you
put
the
link
to
slice?
Can
you
share
them
with
us,
so
we
can
store
them
in
our
presentation,
repo,
for,
like
the
people
who
miss
yep.
D
Yep,
I
can
share
just
a
second,
I
let
me
just
open
it
up
and
if
you
think,
if
you
think
you
actually
might
use
it,
I
will
put
comment
ability
on
it
so
that
we
can
talk
about
things
in
future.
If
you
think
that's
helpful.
C
D
C
Thank
you
pleasure,
so
I
want
to
well,
I
don't
know
if
you
have
seen
kate
the
hecame
document
we
had
for
the
standardized
metadata.
This
is
how
you
know
we
got
in
touch
with
you
as
well.
Let
me
show
that
page
because
we
are
like
again
within
our
group.
We
are
a
bit
like
beginning
of
this.
C
You
know
work,
I
must
say,
and
now
I
hope
you
can
see
this
document
now
and
we
just
start
talking
about
what
kind
of
metadata
we
produce
and
consume
within
our
cicd
flows
and,
as
you
will
see
some
brain
dumps
here
and
then
thanks
to
steve
and
others,
we
start
putting
metadata
for
commits
and
artifacts,
because
we
want
to
be
able
to
pragmatic.
You
know
install
thank
them.
D
Yeah
I'd
say:
if
that's
the
link
I'd,
certainly
I
I
certainly
am
willing
to
take
a
pass
myself
through
and
say:
hey.
This
is
what's
in
spdx
right
now
that
matches
what
I
think
you're
going
after
and
you
can
use
json
in
the
ammo.
You
don't
need
to
use
the
other
format.
So
hopefully
it's
something!
That's
potentially
you
know
easy
for
you
guys
to
work
with
in
your
flows
already,
but
it's
just,
let's
see
if
we
can
standardize
on
the
field
so
that
you
know
no
one
has
to
do
a
translation
at
the
end.
H
The
what
spdx
has
for
definitions
and
those
pieces,
we
should
look
at
those
first
and
then
see
if
we
can
bring
those
into
our
vocabulary
and
if
they
make
sense,
instead
of
going
the
other
way
where
we're
starting
from
the
ground
up
and
trying
to
then
cross-reference
back
to
the
spdx
definition.
So
that
that's
my
viewpoint
that
actually
makes
more
sense.
D
Well,
happy
to
get
like
I
say:
if
there's
a
group,
that's
served
meeting
to
work
through
this,
I'm
happy
to
serve,
attend
and
help
do
the
translation
and
have
a
sort
of
discussion
that
way.
D
C
B
Yes
sure
we
are
yes,
we
are
and
we're
taking
a
lot
of
input,
of
course,
from
the
vocabulary
document
that
you
pasted
there
before
as
well
and
from
different
solutions
that
exists
already.
We
focused
on
two
kt
on
on
event,
specific
event,
data
that
can
be
sent
from
any
cicd
pipeline
system.
B
D
D
B
C
Okay,
I
think
this
was
great,
like
we
finally
got
in
touch
with
work.
You
are
going
there
so,
while
like
the
next
topic,
is
actually
related
to
what
you
touched
during
the
you
know,
spd-x
this
profession
presented
when
I
got
not
also
mentioned
so
I
want
to
highlight
this
as
well.
This
policy
driven
cd
starts
again
a
few
like
months
ago
or
perhaps
end
of
2000.
I
don't
exactly
remember
in
this
document.
C
C
If
you
want,
please
take
a
look
at
this
one
as
well,
because,
like
we
are
trying
to
collect
how
communities
or
companies
approach
the
policy
on
this
document,
which
could
give
us
chance
with
the
trends
like
what
we
observed
now
is
like
open
policy.
Agent
seems
to
be
coming
the
things
in
police
area.
C
Okay
and
the
last
contribution
we
got
to
this
was
from
harness.
Actually
we
got
our
harness,
you
know
approaches
to
policy
and
they
leverage
opa
and
they
also
have
some
implicit,
the
offending
policies.
C
C
Okay,
thank
you,
kate.
Thanks
a
lot
for
joining
and
presenting
spdxn
for
the
discussion,
I
think
we
have
lots
of
opportunities
to.
You
know
work
on
this
metadata
data
topic
and
see
where
we
end
up
coming
months
years.
Perhaps.
D
C
D
L
C
Yeah,
thank
you.
So
our
next
meeting
will
be
on
6th
of
may.
We
will
skip
the
meeting
on
last
thursday
because
we
are
meeting
first
and
third
third
days
of
the
month
so
until
then
take
care
everyone
and
hopefully,
in
few
weeks.
Thank
you
very
much.