►
From YouTube: Office Hours: 2021-06-17
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
A
B
Certainly,
I
don't
have
a
presentation,
but
I
I
can
talk
a
little
bit
of
a
bit
about
the
background
why
it
exists,
what
problems
it
solves
and
really
I'm
here
for
all
of
you
and
to
answer
any
questions
that
you
have
regarding
the
specification
regarding
s-bombs
in
general.
B
B
Certainly
so
the
project
that
I
was
working
on
was
os
dependency
track.
It's
a
currently
it's
a
flagship
project.
It
was
started
in
2013
around
this
notion
of
component
inventory.
B
B
A
combination
of
hardware
and
in
in
the
entire
software
stack
everything
from
the
firmware
to
the
drivers
to
the
operating
system,
to
the
application
to
the
libraries
we
needed
to
track
the
entire
thing,
and
there
wasn't
the
solution
that
that
really
did
that
at
that
time
and
dependency
track.
I
started
that
project
as
as
kind
of
a
way
to
do
that,
and
it
worked
for.
B
You
know
for
the
use
cases
that
it
was
intended
for
at
the
time,
but
you
know
that
concept
started
gaining
a
little
bit
of
momentum
in
the
security
space
right
having
that
that
portable
inventory
of
stuff-
and
it
wasn't
until
2017,
where
the
dependency
track
project
really
started
to
look
heavily
into,
we
just
call
them
bombs
or
bill
of
materials.
B
B
It
was
very
flexible
in
how
it
could
actually
do
things
which
actually
led
to
huge
amounts
of
problems
when
it
came
to
automation,
so
the
security
space
we're
all
about
automation,
just
because
we
we
have
a
lack
of
resources
for,
for
the
most
part,
everybody
in
this
space
is
already
employed
so
having
having
something
that
was
highly
automatable
and
was
simple,
was
was
kind
of
a
requirement,
as
well
as
having
the
available
tooling
and
ecosystem
support
to
be
able
to
have.
You
know,
widespread
adoption
and
in
2017
I
looked
at
spdx
and
I'm
like.
B
Oh,
this
is
not
it
so
I
looked
around
for
some
other
things
and
I
just
didn't
find
anything
so
not
that
I
went
out
in
in
this
was
my
desire
to
create
a
new
specification,
but
unfortunately
that's
that's
the
way
the
world
was
in
2017.
B
B
One
is
that
if
you
have
a
very
simple
model,
you
can
very
easily
get
high
degrees
of
automation
without
much
effort
and
number
two.
If
you
have
a
simple
model,
you
get
mass
adoption
relatively
easily,
so
I
learned
a
lot
of
things
with
regard
to
that
spec
and
I
kind
of
apply
them
to
to
cyclone
dx
in
its
initial
version.
B
So
cyclone
dx
is,
if
you
look
at
it
and
you
compare
it
to
spdx,
they
are
night
and
day
right.
These
standards
look
entirely
different
and
that
is
by
design
one
we
needed
in
the
security
community.
We
need
we
needed
people
to
adopt
this
right.
We
needed
the
ability
for
any
individual
contributor
or
any
security
organization
to
be
able
to
spend
as
little
resources
as
possible
and
create
a
fully
100
compliant
version
of
the
spec
with
minimal
amount
of
effort.
B
So
that
goes
back
to
the
very
simple
model:
two
we're
in
the
security
community
and
we're
dealing
with
continuous
integration
and
delivery
pipelines
all
day
long
and
one
of
the
things
that
we
wanted
to
be
able
to
achieve
with
a
software
bill
of
material
is
not
just
the
creation
of
it.
That's
easy
anybody
can
do
that,
it's
the
once!
You
actually
have
it
and
it's
being
passed
on
throughout
your
build
pipeline.
B
How
do
you
automate
the
augmentation
and
correction
and
modification
of
that
s-bond
throughout
your
build
pipeline,
using
a
bunch
of
different
tools
to
do
that
so
that
your
end
result?
Is
this
uber
enhanced
thing
that
yeah
it
has
what
you
started
out
with,
but
now
it's
got
all
this
enriched
data
in
it.
So
having
a
really
simple
model
is
actually
key
to
being
able
to
do
that,
and
what
we
found
is
that
we
we
had
a
lot
of
adoption
pretty
much
right
away,
so
the
spec
was
essentially
created
in
2017.
B
The
first
version
is
in,
I
think,
like
march
2018,
and
I
don't
know
how
many
tools
we
support
right
now,
but
it's
upwards
of
60
tool
tools
that
actually
support
the
standard
that
we
know
of.
I
I
know
there's
more
than
that,
because
I
know
there's
other
organizations
that
that
have
built
their
own
tools
and
haven't
necessarily
created
a
commercial
product
around
them
or
have
open
sourced
them
yet,
but
it
currently
has
the
largest
tooling
ecosystem
of
all
the
formats.
B
We
support
pretty
much
every
build
environment.
You
can
imagine
everything
from
cocoapods
to
you
know,
java,
to
npm,
to
golang
and
for
some
of
these
ecosystems
like
golang,
there's,
multiple
options
right,
there's
not
just
one
there's
like
three
or
four
that
you
can
actually
choose
from
so
there's
there's
a
lot
of
choice
in
the
ecosystem.
B
In
cycle
and
dx,
the
model
is
fairly
simple.
Everything
is
a
component
right.
You
can
have
file
components,
you
can
have
library
or
framework
components,
you
can
have
container
components,
operating
system
components.
Basically,
everything
is
a
component
and
cocoapods
right
on,
and
so
with
that
regard,
it's
really
simple
to
do.
B
B
It's
really
it's
going
to
be
very
difficult
to
find
any
kind
of
software
that
is
specific
to
a
local
machine
and
doesn't
make
remote
calls
somewhere
so
cyclone
dx
a
couple
years
ago,
we
we
created
the
concept
of
a
service
as
well
again
we're
in
the
security
space
and
so
now
services
are
are
now
part
of
the
are
part
of
the
the
model,
and
what
this
allows
us
to
do
is
capture
dependency
graphs,
for
example.
B
If,
if
I
have
an
application-
and
I
have
a
you-
know
list
of
my
dependencies
and
whatnot-
and
maybe
I
have
a
dependency-
maybe
it
was
auto-generated
code
from
a
swagger
dock
right,
but
that
that
library
that
I
have
it
doesn't
actually
do
anything.
It
just
makes
these
remote
function
calls
somewhere.
B
One
thing
that
I
learned
early
on
is
that
when
you
communicate
the
inventory
of
your
components,
you're
not
providing
all
the
context,
so
cyclone
dx
and
this
kind
of
goes
into
the
whole
open
source
thing
right.
Open
source
is
the
ultimate
supply
chain.
Right
components
are
modified
and
forked
and
renamed
and
rebranded
and
redistributed
all
the
time
and
cyclone
dx
actually
has
adopted
that
kind
of
model.
B
So
you
can
actually
describe
a
component's
pedigree
where
its
derivatives
were
from
what
the
specific
modifications
that
you
have
made
to
a
component
to
make
something
unique,
and
this
is
really
important
because
most
sca
tools
today
software
composition,
analysis
tools.
They
have
no
idea
about
any
of
that
information,
really
it
just
they
basically
just
try
to
fuzzy
match
on
hey.
I
think
this
is
component
x
because
it
has
this
kind
of
evidence
and
that's
really
as
far
as
they
go.
B
But
if
you
are
truly
embracing
s-bombs
as
part
of
the
way
you
build
software,
you
can
actually
describe
what
those
changes
and
modifications
were.
My
employer
we
own
about
300,
open
source
projects
today,
not
that
we
want
to,
but
these
are
things
that
we've
forked
and
we've
modified,
and
we
need
a
way
to
communicate
what
those
things
were
and
in
many
cases
in
many
cases.
This
goes
back
to
context.
B
In
many
cases
we
need
to
communicate
what
we
fixed,
because
when
you
communicate
inventory,
you
are
inevitably
going
to
get
a
lot
of
questions
on
hey
you're,
using
this
vulnerable
version
of
jquery
right.
Actually,
no
I'm
not
I'm
using
this
older
version,
because
I
can't
upgrade
because
of
api
changes,
but
I've
actually
back
ported.
These
fixes.
So
there's
your
additional
context
and
you
can
actually
describe
a
lot
of
different
security
use
cases
with
cyclone
dx
today.
I
think
there's
about
a
dozen
or
so
security
use
cases
that
we
that
the
spec
fully
supports.
B
C
I
have
a
really
basic
question
to
start,
so
you
know
the
use
case.
We're
looking
at
for
cyclone
dx
is
to
describe
the
contents
of
the
container
image.
I
think
we
also
maybe
have
a
an
idea
that
we
need
to
describe
the
tools
that
were
used
to
build
the
container
image
kind
of
separately
from.
What's
actually
you
know,
what's
the
software
that
is
included
in
this
artifact
right,
what
you
know
have
you
seen
other
use
uses
of
cyclone
dx
to
describe
container
images?
Can
you
talk
about
pitfalls
of
doing
that?
C
A
C
B
Sure
sure
yeah,
I
don't
think,
there's
in
terms
of
containers
containers,
are
interesting,
obviously
fully
supported
in
cyclone.
I've
seen
a
number
of
different
ways
that
various
companies
have
created
their
s-bombs
for
container
images.
B
Cyclone
dx
is
pretty
prescriptive
in
how
you
do
things,
so
it's
it's,
it's
much
less
flexible
than
something
like
spdx,
but
that's
by
design
right.
So
there's
just
a
lot
less
possibility
to
shoot
yourself
in
the
foot,
but
I
think
there's
a
number
of
different
ways
that
you
can
approach
container
images.
B
There
is
a
component
type
called
container
right,
so
within
that
container,
then
you
can
then
have
a
nested
set
of
other
components.
For
example,
if
you
wanted
to
have
nest
branches,
basically
for
each
of
your
layers,
for
example,
that's
entirely
possible
or
if
you
don't
want
to
represent
layers,
that's
possible
too.
C
I
think
that's
really
helpful
for
that
that
first
software
build
materials.
It's
like
this
is
this
is
the
contents
of
the
container.
In
the
end,
the
layering
is
especially
useful
for
us
because
our
unlike
a
dockerfile,
our
layers
are
very
contractual.
They
each
have
a
set.
You
know
grouping
of
software,
but
the
you
know.
I
think
we
we
also
want
to
capture
the
tools
that
are
used
to
build
the
image
that
may
not
end
up
in
it
right,
and
you
know.
C
Is
blurry
like
oh,
a
compiler,
actually
puts
a
runtime
in
your
binary
right,
sometimes,
but
sometimes
it's
very
clear,
like
you
used
curl,
and
it
was
this
version
of
curl
to
download
something,
and
it's
definitely
not
related
to
the
image
you
generate.
Does
cycling
dx,
you
know
have
ways
of
representing
that
type
of
data.
Do
people
usually
combine
that
data
together
or
do
they
keep
it?
You
know
with
with
the
description
of
what's
in
the
artifact,
do
they
keep
it
separate.
B
There's
a
couple
of
different
ways
that
you
can
do
that
cyclone
dx
was
created
to
be
extensible
from
day
one.
So
basically
the
validation
of
cyclone
involves
xsds
or
json
schema
right,
that's
it.
Of
course.
We
have
tools
to
help
you
validate
that,
but
it's
fairly
simple
to
validate,
but
for
xml
json
json's
a
special
case,
because
it's
not
extensible
in
the
same
way
that
xml
is
but
for
xml
it's
it's.
It's
actually
quite
easy
right.
B
B
But
it
can
be
done
so
most
of
the
organizations
that
have
extended
it
use
xml,
just
because
it's
easier,
however,
there's
a
couple
of
different
ways
that
I've
seen
other
organizations
use
that
kind
of
data
lockheed
martin,
for
example,
adopted
it.
I
don't
know
a
couple
of
years
ago
and
they
were
actually
using
a
custom
version
of
of
cyclone
that
they
were
using
and
their
modifications
essentially
have
been
integrated
into
the
core
spec
as
a
as
a
version
1.3.
B
B
The
other
option
is,
you
know,
like
I
said,
cyclone
dx
is
is
meant
to
be
extensible
and
one
of
the
things
that
we
are
experimenting
with
is
the
concept
of
I'm
at
a
loss
for
words.
Now
it
is
oh,
a
formulation,
extension
and
formulation
is
really
the
concept
of
what
were
the
parallel
and
sequential
build
steps
that
were
undertaken
to
create
the
artifact
that
I'm
representing
in
the
s-bomb.
B
A
So
I
think
the
the
main
reason
why,
like
this
whole
conversation
started,
is
buildbacks
currently
do
have
like
some
support
for
bill
of
materials
in
the
sense
that
we
allow
authors
to
generate
one
during
the
during
container
building
itself,
which
is
sort
of
uniquely
different
from
docker.
But
it's
not
structured.
So
we
were
looking
at
different
formats
to
sort
of
structure
the
data
we're
putting
in
there
so
that
it's
easy
to
use
for
like
scanning
tools.
A
Further
on
in
the
pipeline,
I
think,
like
one
of
the
questions
that
I'm
interested
in
is
like.
There
seems
to
be
like
this
ntia
working
group,
comparing
different
formats
and
like
trying
to
figure
out
which
one
like
what
kind
of
gaps
and
holes
each
one
has.
So
can
you-
and
I
also
saw
you-
were
involved
in
discussions
there
representing
the
cyclone
dxi?
A
I
don't
know
if
you
have
any
yeah
yeah
thoughts
on
like
what
cyclone
dx
shines
at
and
what
spdx
does
better.
Apart
from
what
you
already
mentioned
around
flexibility,
is
there
anything
else
that.
B
Certainly,
yeah
and-
and
there
are
some
cases
where
spdx
truly
shines-
it's
had
a
lot
of
history
in
the
license
and
intellectual
property
space,
because
that's
where
it
started
from
so
things
like
snippets,
for
example,
only
only
available
in
in
spdx.
Now
we
can
debate
whether
or
not
snippets
actually
belong
in
an
s
bomb.
They
may
not,
but
that's
something
that
that
s
pdx
supports,
there's
a
lot
of
other
smaller
license
and
intellectual
property
attributes
that
that
spdx
supports
as
well.
That
is
not
present
in
cyclone.
B
What
you
will
find
is
that
there's
a
lot
of
again.
This
goes
back
to
the
flexibility,
there's
a
lot
of
of
of
things
that
different
ways
to
represent
things
in
spdx
and
what
you'll
find
is
that
cyclone
is
just
the
opposite.
It's
very
prescriptive
in
how
you
do
things
and
that's
by
design
again
going
toward
the
automation
being
easily
adoptable,
etc.
B
B
You
will
find
that
cyclone
dx
has
more
capabilities
than
spdx
does
today,
especially
with
software
security.
Use
cases
the
easy
case
is
hey.
I've
got
this
component,
it
has
known
vulnerabilities
right.
Anything
can
do
that.
A
spreadsheet
can
do
that,
but
there's
a
dozen
other
software
security
use
cases
that
that
cyclone
dx
supports
today,
in
which
there's
some
really
interesting
commercial
investments
that
are
happening
in
this
area.
I
mentioned
services
before
this
is
some
really
interesting
stuff.
B
There's
there's
actually
organizations
using
s-bombs
today
as
a
baseline
and
they're
actually
measuring
the
telemetry
information
from
from
applications
at
runtime
to
see,
if
there's
any
variance
in
what
the
s
palm
actually
describes,
which
which
is
versus
what
the
application
actually
does
and
looking
for
anomalies.
B
So,
when
you're
looking
at
supply
chain
as
a
as
a
you
know
as
a
concern,
cyclone
dx,
it
doesn't
handle
everything,
but
it
handles
a
large
number
of
software
security
use
cases
today.
So,
if
you
look
at
the
capabilities,
it's
it
will
become
apparent,
which
one
is
is,
is
better
at
security
use
cases.
B
A
B
Right,
okay
and
and
cyclone
dx-
actually
just
the
last
point
here
it,
the
dx
after
cyclone,
is
actually
in
homage
to
spdx.
When
we
set
out
to
create
a
spec,
we
did
not
want
to
reinvent
the
wheel.
B
Spdx
license
ids
and
expressions
they're
everywhere.
We're
not
going
to
reinvent
that,
so
we
reuse
them.
So
cyclone
supports
spdx
license
ids,
it
supports
license
expressions
and
copyrights
and
a
lot
of
other
licensed
use
cases,
but
that's
definitely
an
area
where,
if
that's
your
focus,
that's
where
spdx
shines.
A
I
think
the
other
question
we
had
was
around
like
the
different
package
locators
or
coordinates
that
both
of
these
ecosystems
use.
So
the
there's
swift
tags,
there's
the
url
of
pearl
and
there's
cpe
like
a
lot
of
us
here.
I
don't
know
about
others,
but
I
I
personally
am
not
very
much
familiar
with
what
what's
best
among
all
three
of
these
or
things
or
which
tools
use
which
format.
A
Can
you
talk
us
through
a
bit
about
like
what
these
different
formats
do
and
how
they're
actually
used
like
downstream
for
scanning.
B
Certainly
so
there's
three
different
common
ways:
I
guess
to
identify
software.
One
is
package
url.
This
is
anything
that
is
going
to
be
either
using
a
package
manager
or
is
stored
in
a
repo
somewhere
rpms,
for
example,
could
be
represented
using
package
url
and
then
there's
cpes,
which
is
primarily
used
by
the
nvd,
but
it's
also
used
elsewhere
and
then
there's
suite
tag
ids.
B
All
three
of
these
things
are
used
to
identify
software,
perl
or
package
url,
also
being
able
to
not
only
identify
the
software
but
actually
being
part
of
the
providence
as
well.
Where
did
you
actually
get
this
piece
of
software
from
so
pearl
actually
handles
both
of
those
use
cases?
The
other
two
just
are
merely
identity.
B
All
three
of
those
can
be
used
in
software
security
use
cases
today,
perl
package
url
being
the
most
widely
used,
so
most
sca
vendors.
They
they
have
their
own
internal
databases
of
this
book.
This
component
is
vulnerable
to
this
thing.
Most
sca
vendors,
don't
actually
use
cpes
natively.
B
What
they
actually
do
is
they
actually
have
a
mapping
between
the
the
open
source
components
and
the
vulnerabilities,
and
if
it,
if
the
vulnerability
is
in
the
national
vulnerability
database,
that
how
that's
how
cpes
are
derived,
but
they
don't
typically
use
cpes
natively,
because
cpe
is
not
capable
of
representing
modular
components,
so
it's
only
capable
of
representing
vendor
name
and
version.
B
That's
it
so
things
like
spring
framework,
where
there's
30
different
sub
modules.
You
can't
represent
that
in
cpes.
Today,
you
can
represent
that
in
package.
Url,
so
you'll
find
that
most
of
the
vulnerability
databases
out
there
outside
of
the
nbd
don't
actually
use
cpes
natively.
Just
it
doesn't
give
them
the
the
the
detail
that
that's
necessary,
but
the
nvd
is
adopting
swid.
B
Everybody
is
kind
of
waiting
for
the
transition
plan.
Cpe
is
deprecated
according
to.
According
to
the
nvd
folks,
I
haven't
seen
any
public
documentation
on
the
fact
that
cpe
is
deprecated.
However,
from
the
from
the
mouths
of
the
nvd
folks,
it's
been
communicated
multiple
times.
Swit
is
their
replacement.
B
They
have
rest
endpoints
on
the
nvd
today
that
actually
supports
swift
and
I've
been
talking.
The
the
cyclone
dx
core
working
group
has
been
talking
with
the
folks
over
at
nist
for
a
while
now
and
there's
some
shared
efforts
that
we're
going
forth
with,
with
with
regard
to
cyclone,
dx
and
suid,
because
swit
is
actually
natively
supported
in
cyclone
dx.
Today,.
C
One
thing
I've
noticed
about
pearl
like
compared
to
cpe
with
cp.
I
can
you
know,
query
for
all
open,
jdk,
cds
or
you
know,
open
jdk
cves
that
match
some
portion
of
a
cpe,
but
not
others
with
wild
cards.
I
haven't
found
a
way
people
are
using
pearl.
That
way,
you
know,
do
you
have
if
we
kind
of
lean
towards
pearl
for
identifying
software
packages,
but
you
needed
to
refer
to
this
ubuntu
package,
but
not
the
specific
version
of
it.
B
Yeah
so
pearl,
you
know
it's
going
to
represent.
You
can't
really
do
wild
cards
today
in
pearl.
There
is
a
proposal
to
support
version
ranges,
so
that
might
actually
come,
and
that
would
actually
solve
a
lot
of
the
verbosity
that
that
might
exist.
So
you
won't
have
to
describe
a
thousand
different
cpes.
B
You
could
have
a
much
shorter
list
to
describe
the
all
the
various
ranges
of
of
things
that
are
potentially
affected,
so
if
version
ranges
actually
come
to
see
pearl,
then
that
would
probably
be
the
the
best
way
forward.
Most
of
the
use
of
pearl
that
I've
seen
is
is
with
regard
to
oss
index
from
sona
type.
B
Now
it's
called
sonotype
lift,
I
think,
but
they
basically
have
mappings
between
all
the
various
package,
urls
and
vulnerabilities,
whether
it's
you
know
something
in
the
nvd
versus
something
that
sonotype
themselves
know
about,
etc,
so
that
that's
yeah
until
version
ranges
are
supported.
I
think
it's
your.
A
How
how
does
sweden
come
into
play
with
this,
like
you
said
that
cp
is
being
deprecated
in
favor
of
squid
so
like
how
does
swing
handle
these
kind
of
things.
B
B
B
A
I
had
a
follow-up
question
on
that,
so
currently,
cyclone
dx
only
allows
a
single
diago
component,
I'm
not
sure
what
it's
called,
whereas
like
some
of
the
tools
like
sift
output
like
a
list
of
them-
and
I
think
spdax
also
supports
like
the
list
of
external
references.
C
A
B
B
For
external
references,
one
of
the
things
that
you
can
do
with
cyclone,
for
example,
and
you've
been
able
to
do
this.
For
I
don't
know
the
last
couple
of
years
or
so,
but
every
component
can
have
external
references,
and
our
external
references
are
a
lot
different
than
than
spdx's.
B
Identity
is
not
an
external
reference
in
cyclone
dx.
It's
it's
part
of
a
component's
identity.
So
it's
it's!
It's
not
something
external
to
the
component,
but
with
cyclone
you
can
actually
link
out
to
security
advisories.
So
if
you
have
a
csrf
or
csaf
or
some
other
kind
of
security
advisory
feed,
you
can
actually
say
hey.
I've
got
this
component,
and
this
is
where
you
can
find
the
advisories
for
that
component.
B
C
I
have
a
question
kind
of
going
back
to
the
you
know,
different
available
formats
for
describing
you
know,
software
build
materials
or
build
materials.
Cloud-Native
build
packs
has
adopted
on
most
major
cloud
platforms
at
this
point.
If
we
commit
to
choosing
a
particular
format-
and
you
know
make
it
create
a
dependency
both
on
the
provider
side,
people
writing
the
build
tools
and
on
the
consumer
side,
people
looking
at
images
and
getting
software
build
materials
off
of
them.
C
C
More
functionality,
you
know
the
cyclone
dx
definitely
isn't,
isn't
the
only
tool
that
tries
to
capture
some
information.
We
like
that
it's
very
security
focused
right
and
there's
lots
of
real
tools
to
work
with
it
right
now.
You
know,
would
you
recommend
kind
of
betting
on
cyclone,
as
you
know
the
thing
that
I
think
that
we
could
stick
with
for
a
long
time
that
would
provide
that
kind
of
you
know
functionality
for
security
scanners
to
understand.
B
Yeah
so
yeah
cyclone
I
mean
I
I
would
we're
going
to
live
in
a
just
like
we
live
in
a
polyglot
language,
environment,
we're
going
to
live
in
a
polyglot
bomb
environment.
That's
just
the
reality
right
having
having
imagine
a
world
where
we
only
had
one
programming
language
to
choose
from
that
would
really
suck.
B
And
you
know
you,
you
pick
a
language
and
you
you
find
things
that
you
like
about
it,
whether
you,
maybe
you
like
static
typing
over
dynamic
typing
right
or
maybe
you,
like
you,
know,
dynamic
languages
or
you
know
whatever
so
there's
use
cases
for
all
of
these
things
and
they're
all
going
to
be
viable.
B
The
one
thing
that
cyclone
dx
has
is
the
design
right.
It's
prescriptive
and
it's
highly
automatable
spdx
with
version
three
anyway.
Obviously
they're
introducing
some
breaking
changes
and
those
breaking
changes
are
very,
very
necessary
because
version
two
dot
x
is
kind
of
broke
in
my
opinion,
so
I'm
glad
they're
actually
breaking
spdx
because
they
need
to.
I
don't
necessarily
I'm
not
convinced
that
they've
actually
figured
out
security
profiles
and
vulnerability
profiles
and
all
this
stuff
yet
they're
still
trying
to
well.
B
I
won't
speak
for
spdx,
but
I
think
what
you'll
find
is
that
there's
already
a
lot
of
adoption
in
the
security
community
for
cyclone
dx,
the
momentum
is
already
there
trying
to
come
into
the
security
space
with
a
lot
of
folks
doing
license
and
intellectual
property
kind
of
leading
that
effort
might
have
mixed
results.
B
We
o
wasp
actually
had
to
create
a
new
category
of
of
projects
specifically
for
cyclone
dx.
Previously
they
only
supported
documentation,
tools
and
code
projects.
B
So
now
there's
standards
projects
within
oasp
so
because
of
the
owass
connection
and
all
the
security
vendors
supporting
owasp,
I
think
you're
gonna
see
the
adoption
escalate
even
more
than
it
has
already.
I
know
of
a
handful
of
sca
vendors
that
are
like
almost
complete
with
their
implementation
of
cyclone
already
so
you're,
going
to
see
many
more
announcements
in
the
coming
months
for
various
commercial
providers
that
that
support
it
you're
also
going
to
see,
I
think,
some
innovation
in
the
space
as
well.
B
You
know
the
more.
The
more
one
of
the
formats
stretch
stretches
the
boundaries
of
what's
possible.
That's
those
are
the
things
that
kind
of
lead
toward
innovation
and
keep
in
mind
this
space,
this
space
that
we
we
now
refer
to
as
software
bill
of
materials.
This
is
actually
over
the
last
decade.
This
was
this
was
a
market
that
essentially
failed
right
and
it
if
it
wasn't
for
the
the
efforts
of
ntia,
would.
C
B
Still
be
failing,
although
you'd
still
have
a
lot
of
folks
adopting
this
in
the
security
community,
but
it
would,
for
the
most
part,
still
be
a
failed
market,
but
I
think
the
s-bomb
formats,
especially
the
ones
that
that
push
the
bounds,
are
really
going
to
be
sparking
some
innovation.
B
I
mentioned
some
of
the
work,
that's
being
done
by
a
few
different
commercial
vendors
to
you
know
for
for
doing
the
services
support
in
cyclone
right,
where
you're
actually
monitoring
an
active
application
and
using
the
s-bom
as
baseline,
etc,
incorporating
the
data
classifications,
the
directional
flow
of
data,
trust,
boundary,
traversals,
etc.
I
think
you're
going
to
see
a
lot
more
of
that
kind
of
innovation
in
the
future.
For
example,
how
do
we
automatically
identify
services
in
rs
in
our
components
today?
There's
no
way
to
do
this
right.
B
Sca
vendors
have
had
the
last
decade
to
figure
it
out.
They
have
it
because
nobody
was
asking
for
it.
So
it's
specs
like
cyclone
that
are
pushing
the
bounds
and
and
trying
to
make
things
happen
that
I
think
hopefully
will
kind
of
spark
some
of
this
innovation
in
the
in
the
security
space,
because
it's
truly,
we
desperately
need
it.
A
Thanks
for
that,
I
had
a
couple
of
questions
on
like
conversion
between
different
small
formats.
As
you
said
like
this
is
going
to
be
a
poly
market,
so
there
might
be
tools
that
that
they
only
support
or
right
or
something
else.
Can
you
speak
a
bit
more
about
like
conversion
between
the
two
formats,
because
there
are
obviously
fields
that
exist
only
in
cyclone
dx
and
cannot
be
mapped
to
spdx
and
vice
versa.
A
So
how
does
like
what
kind
of
information
is
typically
preserved?
Is
there
some
sort
of
convention
between
the
field
mappings
across
the
different
formats,
and
I
see.
C
A
Cyclone
dx
already
sort
of
supports
some
conversion,
but
I'm
just
curious
to
know
some
thoughts
on
that.
B
Certainly
so
we
talked
about
capabilities
earlier
right
and
you
know
spdx
being
more
flexible
and
has
more
options
to
to
represent
data
in
different
ways:
cyclone
being
more
prescriptive,
less
of
flexibility.
B
So
we
recognize
the
the
security
industry
recognizes
that
security
is
only
one
of
the
seats
at
the
table.
It
just
happens
to
be
the
one
that
gets.
You
know
board
room
discussions
most
of
the
time
licensed
not
so
much,
but
we
recognize
that
lawyers
also
have
to
to
use
this
stuff
and
so
with
cyclone,
because
we
have
more
capabilities
than
spdx
does
today
we're
actually
very
easily
able
to
actually
generate
spdx,
2.1
and
2.2
documents.
B
Today
from
existing
cycle
and
dx
documents,
it's
fairly
elementary,
the
only
thing
that
we
can't
really
do
because
it
the
spec,
doesn't
support.
It
is
snippets
right-
and
I
don't
know
if
I
don't
even
know
if
we
ever
will
support
snippets.
I
talked
about
that,
but
all
your
component
information,
your
license,
information,
copyright
information,
external
references,
all
that
kind
of
information
can
be.
You
can
start
off
with
cyclone.
If
you
have
lawyers
legacy
systems
whatever
that
need
spdx,
we
can
generate
that
no
problem
going
back
the
other
way.
B
However,
going
from
spdx
to
cyclone
dx,
you
can
also
do
it
again,
you're
going
to
lose
the
snippets.
So
if
you
start
out
with
with
spdx,
you
could
lose
snippets
when
you
go
to
to
cyclone,
unless
you
actually
have
a
a
schema
extension
for
cyclone
that
actually
supports
it,
so
you
will
lose
snippets,
but
everything
else
will
pretty
much
be
field
to
field
mapped.
B
Once
you
get
outside
of
the
the
package
or
the
component
in
cyclone,
you
start
to
get
into
just
great
differences
and
concepts
right
and
that's
when
the
field
to
field
mapping
approach
breaks
down,
because
how
can
I
map
a
commit
for
a
pedigree?
You
know
a
modified
component.
How
can
I
map
that
piece
of
code
over
to
spdx?
B
B
But
yeah
with
cyclone
dx
cli,
which
is
our
command
line
interface,
you
can
you,
can
output,
spdx21
and
two
two
from
any
cyclone
dx1.2
or
1.3.
A
Document,
I
think
one
other
question
I
had
was
around
merging
different
cyclone
dx
documents.
So,
as
we
said
currently,
buildbacks
are
these
individual
units
that
come
together
to
build
a
final
container
image,
and
these
individual
units
currently
will
are
in
charge
of
providing
their
own
s1
representation,
and
we,
as
a
project,
are
responsible
for
merging
them.
Together
is
so
what
kind
of
merge
strategies
does
cyclone
dx
support
and
like?
Is
there
a
predefined
one
for
containers
when
it
comes
to
layers,
or
do
you
have
any
thoughts
on
that.
B
Yeah
right
now
the
tools
support
merging
of
s-bombs.
This
is
a
fairly
common
use
case.
Actually,
most
applications
are
polyglot,
you've
got
maybe
java,
or
you
know,
ruby
or
python,
or
something
on
the
back
end,
and
you
might
have
a
javascript
front
end.
You
want
to
create
a
single
less
bomb
to
represent.
You
know
your
application
as
a
whole,
so
you
take
the
s-bom
from
the
python.
You
take
the
s-bom
from
the
javascript
and
you
merge
them
together
into
one
bomb
that
actually
represents
reality.
B
That's
that's
a
very
common
use
case.
The
cyclone
dx
cli
does
that
today,
where
there
is
some
room
for
improvement,
is
to
be
able
to
define
where
at
in
the
s-bomb,
you
actually
want
to
merge
right.
So
right
now
we
just
merge
at
that
top
level
right,
but
in
reality
what
we
would
want
to
do
and
what
the
spec
is
capable
of
doing
is.
Maybe
you
have
a
component
which
includes
other
components:
that's
that's
kind
of
a
nested
assembly
in
cyclone
dx.
B
So
what
we
would
like
to
do
is
be
able
to
take
a
supplier's
s-bom,
for
example.
Maybe
maybe
I'm
creating
a
piece
of
software,
but
I
have
another
supplier.
I
want
to
be
able
to
take
their
s-bomb
and
put
that
into
a
single
component
in
my
s-bomb
have
their
have
their
nested
assembly
actually
signed
by
them,
and
then
I
will
sign
the
s-bomb
in
its
entirety.
B
So
you
can
have
a
lot
of
flexibility
with
regard
to
what
parts
of
the
s-bomb
you
actually
want
to
sign
and
what
parts
you
don't,
but
I
think
there's
some
ways.
The
I
think
there's
some
ways
that
we
can
improve
where
in
the
s-bomb
you
want.
Actually
your
component
inventory
to
go
and
that's
just
that's
just
a
tool
tweak.
That's
that's
nothing
with
the
spec.
B
B
B
Obviously,
if
you're
a
security
person,
you
frown
upon
that.
You
don't
want
that
behavior,
but
it's
the
only
way
to
make
json
extensible
really
versus
xml,
which
obviously
has
namespaces
and
all
that
so
unless
you're
using
something
that
is
not
part
of
the
core
spec
you're
not
going
to
lose
any
information.
In
fact,
the
cyclone
dx
cli
can
convert
between
json
and
xml
all
day
long.
It's
no
problem.
We
also
support
protobuf
because
we
realize
that.
A
B
Everything
has
to
be
a
file,
in
fact,
if
you,
if
you
want
to
do
true
automation,
you
should
never
have
a
file,
so
we
we
support
protobuf
as
well
as
a
as
an
official
format,
so
you
can
actually
store
it
in
that
way
too.
B
One
thing
that
you
might
want
to
consider,
however,
is
signing,
so
if
an
s-bomb
was
actually
signed,
can
you
actually
store
that
in
your
repository
today,
in
whatever
native
format,
you
have
and
be
able
to
return
that
same
thing
signed
or
not?
If,
if
that's
a
requirement
or
not
but
I'll,
just
I'll,
just
throw
it
out
there.
A
B
Most
of
them.
Well,
let's
see
dependency
track.
My
project
sona
types
tools
I
think
sonotype
is
mostly
xml
dependency
track
is
both
right.
We
can
ingest
json
all
day
long.
Then
you
have
other
vendors,
like
encore,
for
example,
which
you
know
they've
got
a
bunch
of
container
stuff,
some
commercial,
some
free
they're,
mostly
json
right.
I
don't
think
they
do
any
x
about
today.
B
You
know
we
don't
necessarily
want
to
prescribe
what
format
people
should
use.
We
want
to
make
it
as
easy
as
possible
to
use
whatever
format
is,
is
good
for
you
right.
It
becomes
problematic,
however,
with
extensibility.
That's
that's
where
json
just
kind
of
falls
apart.
A
And
is
that
going
to
be
like
even
supported
in
the
future
like
if
there
are
some
shortcomings
of
json
in
the
future?
There
are
no
like
concerns
about
that.
Being
deprecated
and
xml.
B
No,
no,
no
we're
actually
we're
actually
experimenting.
We've
had
a
call.
We've
had
a
couple
conversations
with
some
pms
over
at
snick
and
because
they
want
to
support
only
json
right
and
how
do
we?
How
do
we
support
these
schemas
extensions
in
x
in
json?
It
is
kind
of
an
open
question,
there's
a
number
of
different
avenues
that
we
can
take
if
we
want
to
actually
validate
something
and
as
well
as
you
know,
not
just
a
core
spec,
but
that
extensible
stuff
as
well.
B
If
you
want
to
validate
the
entire
thing,
one
of
the
approaches
we
could
do
is
we
could
have
the
the
cli,
the
cyclone
dx
cli,
actually
dynamically
create
json
schemas.
Based
on
what
capabilities
you
actually
want
to
validate
against
right
that
that's
one
option.
B
Another
option
is
to
have
a
extensions
array
in
the
json
and
just
don't
validate
anything
in
there
right.
It's
you
can
just
put
whatever
you
want
in
there.
The
third
option
is
to
mimic
the
namespace
support
that
exists
in
xml.
Try
to
mimic
that
in
in
json.
So
there's
a
there's,
a
few
different
ways
that
we're
kind
of
experimenting
with
it.
All
of
these
ways
are
not
are
less
than
ideal
right.
B
Ideally,
we
would
have
something
better
than
json
schema
to
deal
with,
but
we
don't
and
because
of
that
json
with
with
extensions
in
json
format,
it's
always
going
to
be
a
less
than
ideal
option,
we're
just
trying
to
figure
out
what
the
best
approach
is
going
to
be
for
the
greatest
number
of
people.
A
I
know
we're
running
short
on
time.
I
just
had
one
last
question
like
in
in
terms
of
merging
things,
so
since
buildbacks
are
provided
by
different
authors
and
we
only
provide
the
platform,
what
happens
when
the
authors
provide
different
versions
of
the
cyclone
dx
pack
and
we
want
to
merge
them.
B
Nothing
really
I
mean
you,
can
you
can
merge
them
as
much
as
you
want.
The
only
requirement
when
you
merge
is
that
every
component
can
have
an
identifier.
We
we
call
it
a
bomb
ref
and
the
bomb
rough
needs
to
be
unique.
That's
really
it
so
just
you
need
to
make
sure
that
bomb
ref
is
unique.
Otherwise
the
document
will
fail
to
validate
validation
in
cyclone
is
fairly
simple.
B
Again,
we
rely
on
xml,
schema
and
json
schema.
We
do
not,
unlike
unlike
spdx,
where
you
have
structural
validation
and
business
level
validation,
both
of
which
are
required
to
do
document
level
validation
with
with
cyclone.
It's
it's
much
simpler.
B
So
we
don't
have
that
additional
complexity,
so
you
can
use
the
cli
to
validate
or
you
can
just
use
xml
scheme
and
json
schema.
It's
up
to
you.
A
A
Yeah
and
I
think
we're
running
out
of
time,
but
thank
you
so
much
for
joining
us
today
and
if
you
have
any
questions
I
think
we
can
is.
Is
the
slack
channel
the
best
place
to
ask
any
further
questions.
B
Yeah
absolutely
feel
free
to
reach
out.
You
know
if
you
have
questions
on
cyclone,
where
it's
good,
where
it's
not
so
good.
Let
me
know
be
glad
to
answer
any
questions
you
have
and
I
also
encourage
anyone
to
join
the
cyclone
dx
slack
channel
that
sam
mentioned,
we
have
a
fairly
good
community
of
people
there
that
are
adopting
and
supporting
the
spec
so
check
it
out.