►
Description
A software bill of materials, or SBOM, is a list of components that make up a given application. Think of it like a list of ingredients on food packaging. Understanding what the software you're running consists of is useful for lots of use cases, from license compliance to software supply chain security. Although not a new idea, we’re at the point where SBOMs are about to go mainstream.
In this talk we will:
* Quickly introduce SBOMs and the problems they solve
* Look at some of the competing standings like CycloneDX and SPDX
* Survey existing open source tools for working with SBOMs, with a focus on Kubernetes and the Cloud Native ecosystem
* Discuss what’s missing, including mature open source libraries, and what the community can do about it The audience should come away with a sense of where things might be heading and some interesting ideas and demos to experiment with.
A
B
Yeah
apologies
folks.
We
had
some
slight
technical
difficulties,
but
we
are
frantically
in
the
background
trying
to
update
the
twitter
page
and
the
kcd
uk
dot
io
website
so
that
you've
got
the
up-to-date
youtube
link.
Although
I
guess,
if
you're
hearing
me,
you
must
already
have
the
link.
So
that's
kind
of.
A
B
Not
just
whilst
we're
waiting
for
our
next
speaker,
why
don't
I
do
a
quick
readout
for
sneak
who's,
one
of
our
diamond
sponsors.
So
just
a
quick
bit
information
about
sneak.
They
are
a
cloud
native
application
security
leader.
They
enable
2.2
million
developers
to
build
securely
with
a
vision
to
empower
every
modern
developer
in
the
world
to
develop
fast
and
stay.
Secure.
B
Only
sneak
provides
a
platform
to
secure
all
of
the
critical
components
of
today's
cloud
native
application
development,
including
the
code
open
source,
libraries,
container
infrastructure
and
infrastructure
as
code
sneaks
developer.
First
approach
enables
technology
driven
companies
to
scale
security
in
today's
fast-paced,
digitally
transforming
world
sneak's
security
platform
is
powered
by
its
industry-leading
proprietary
vulnerability
database
maintained
by
the
expert
sneak
security
research
team
that
also
powers
security,
solutions
from
strategic
partners
such
as
atlassian,
datadog,
docker,
ibm
cloud,
rapid7,
red
hat
and
trend
micro.
A
Excellent,
thank
you
for
that
paula
and
sneak
also
pay
my
salary.
Yes,
so
clearly
I
am
horribly
biased,
but
and
that
that's
a
that's
a
really
good
timing
as
well,
because
our
our
next
speaker
is
is
I'm
sure,
familiar
to
to
many
of
you
in
the
in
the
community,
certainly
familiar
to
me
as
I
work
with
him
every
day,
and
so
let's
bring
gareth
rushgrove
onto
the
stage.
A
C
Yeah,
okay,
so
good
to
meet
everyone
I'll
jump
in.
I
will
jump
into
slides
shortly,
but
just
to
say
hi,
I'm
gareth
rushgov
vp
of
product
at
sneak,
also
sort
of-
I
guess
like
well,
I
say
occasional,
but
it's
far
too
much
time
spent
hacking
on
open
source
projects
for
a
good,
while
now
probably
most
recently
with
contest
and
open
policy
agent,
but
around
the
kubernetes
community
and
docker
community
and
public
community
and
a
bunch
of
others
performing.
C
So
welcome
everyone,
I'm
going
to
talk
about
software,
build
materials
for
cognitive
applications,
but
don't
worry
if
you
don't
know
what
software
builder
materials
is
I'll
do
a
bit
of
an
introduction
there.
This
isn't
a
super
deep
dive,
talk,
we're
not
going
to
see
loads
of
demos
and
examples
and
get
into
the
weeds
of
this.
I
really
want
to
just
put
this
in
people's
heads.
Get
people
started
thinking
about
this
space.
Tell
you
about
a
bunch
of
the
interesting
things
that
are
happening
and
maybe
give
you
some
homework.
C
C
Okay,
so
what
is
a
software
bill
of
materials
this?
This
might
be
something
that
you've
come
across
before
it
might
be
something
that
you
never
come
across
at
all,
but
I
don't
think
it's
something
that
will
be
fundamentally
unfamiliar
and
when
you
sort
of
work
out
what
it
is,
but
here's
a
description
that
I
think
sort
of
encap
and
it
sums
it
up
really,
it's
a
complete,
formally
structured
list
of
components,
libraries
and
modules
that
are
required
to
build
a
given
piece
of
software
and
the
supply
chain
relationships
between
them.
C
C
But
why
is
this
interesting?
Why
is
this
something
that
maybe
isn't
just
part
of
how
we
work
already,
and
why
is
it
interesting
now
in
particular-
and
there
are
a
number
of
different
use
cases
for
like
having
a
list
of
all
the
software
in
all
your
software,
and
I
think
these
three
sort
of
sum
it
up
to
a
degree
like
you've
got
sort
of
intellectual
property
management
problems
and
that
might
be
compliance,
oriented
that
might
be
export
rules
and
that
might
be
open
source
license
issues.
C
Probably
the
one.
That's
bubbling
up
more
and
more
recently
is
software
supply
chain
security
that
we're
much
more
conscious
today
than
maybe
when
a
lot
of
the
technology
we
use
was
built
and
designed
that
there
are
risks
inherent
in
how
we
build
software
and
open
source
is
undeniably
good
at
many
different
things,
but
it
absolutely
means
that
the
number
of
contributors
to
the
piece
of
software
that
you're
producing
is
a
lot
greater
than
you
can
probably
reasonably
fathom
you're
getting
software
from
lots
of
places.
C
It's
coming
through
various
different
tools,
build
systems,
source
control
systems,
a
compromise
at
any
one
of
those
points
potentially
opens
you
up
to
an
issue
yourself
and
we're
seeing
more
of
those
attacks.
We're
seeing
attacks
on
the
sort
of
like
package
management
infrastructure,
we're
seeing
attacks
on
source
code
management
systems
and
so
understanding
what
goes
into
your
software
is
the
first
step,
arguably
to
being
able
to
maybe
reduce
the
risk,
maybe
manage
some
of
those
vulnerabilities
and
understand
them.
C
End
of
life
like
when,
when
is,
is
something
in
your
chain
actually
no
longer
maintained,
and
there
are
also
just
requirements
around
high
assurance
systems,
like
not,
everyone
is
going
to
be
working
in
a
sort
of
high
security,
high
threat
environment,
but
at
some
point
those
environments
were
very
niche.
They
were
very
much
in
the
sort
of
government
military
industrial
sort
of
complex.
C
And
last
but
not
least,
I
think
there
are
a
number
of
interesting
use
cases
just
on
asset
management
and
that
title
I'm
not
sure
about,
because
it
sounds
boring,
and
I
don't
think
it
is.
I
think
there's
all
sorts
of
interesting
use
cases
that
if
we
knew
what
software
we
were
running,
we
could
actually
like
come
up
with
and
solve
just
research
around
usability
and
usage
is
interesting
process
improvements.
Why
is
this
organization
using
103
different
versions
of
open
ssl?
C
It's
probably
a
good
question,
but
not
when
we're
even
capable
of
knowing
the
answer
to
the
number
of
things
we're
using
today
in
lots
of
cases
so
search
and
visibility
built
on
top
of
good
software
build
materials.
Infrastructure,
I
think,
is
in
the
future,
but
I
think
powerful
for
a
number
of
different
problems.
C
But
why?
Now
because
this
doesn't
feel
like
a
sort
of
a
problem
that
is
brand
new
and
yes,
maybe
the
security
stuff
is
more
in
the
news
today,
it's
more
powerful
today.
There
are
more
threats
today,
but
this
doesn't
feel
like
something
that
someone
has
just
invented
and
it's
not
the
conversations
about
software
builder
materials
date
back
and
probably
from
the
start
of
really
software
being
composed
of
multiple
parts.
C
There
have
been
conversations
in
like
sort
of
strange
corners
of
fosdem
about
licensed
compliance
that
I
hang
around
with
they've
been
standards,
bodies
or
people
very
close
to
government
scale
problems.
The
good
news
is
a
lot
of
that.
Work
has
laid
the
groundwork
for
us
to
actually
be
a
lot
further
forward
now
than
we
might
otherwise
be,
and
what's
really
lighting
a
fire.
C
So
I
think
the
impact
of
this
will
take
time
but
will
be
felt
everywhere.
There's
also
the
fact
that
solving
this
requires
software
and
software
companies
are
definitely
rushing
to
solve
these
problems
and
adopt
some
of
these
standards
and
practices.
So
I
think
you
will
see
a
lot
more
noise
about
this,
both
good
and
bad.
C
Probably
not
a
government
agency
you're
super
well
familiar
with.
They
don't
have
exciting
tv
programs
following
their
agents
around.
As
far
as
I
know,
but
they've
been
doing
some
really
good
work,
which
was
very
much
focused
on
like
a
multi-stakeholder
process.
They
weren't
trying
to
make
decisions.
They
weren't
trying
to
mandate.
They
were
trying
to
bring
often
quite
opinionated
people
who
disagreed
violently
together
over
several
years,
really
to
sort
of
work
out
some
of
the
consistent
items
of
what
we,
what
everyone
cared
about,
rather
than
what
some
people
cared
about.
C
Oh,
what's
have
the
software
component
work
more
recently,
microsoft
with
skim.
The
cncf
themselves
have
published
a
really
good
document
as
part
of
the
security
work,
so
software
supply
chain
best
practices.
All
of
these
are
interesting
to
look
at
that.
They
solve
different
problems.
Different,
like
sort
of
some
of
them
are
very
recent.
Some
of
them
are
a
bit
more
mature.
C
C
I
touched
on
something
there
as
well,
which
was
a
bit
more
detailed,
a
bit
more
technical
on
the
technology
side
that
there
are
emerging
standards
here
to
help
us
reason
about
like
technically
okay.
What
is
a
software
build
material
because
it's
fine
to
say
it's
a
list
of
software,
but
you
can
go
like
okay,
here's
a
spreadsheet,
here's
another
spreadsheet!
Here's
a
word
document!
Here's
a
pdf
here
is
a
text
file.
Here's
a
csv
file
and
all
of
those
are
software
builder
materials.
C
They
are
all
lists
of
the
software,
but
not
only
are
all
of
those
in
different
file
formats,
they're,
probably
all
in
different,
like
naming
conventions
and
version
formats,
and
they
include
different
bits
of
information
and
there's
like
it's
fine,
if
you
want,
if
you
think
this
is
a
tick
box
exercise,
that's
probably
fine,
and
someone
gives
you
one.
You
take
a
box
and
say:
yes,
we've
got
software
with
all
the
materials
job
done,
move
on
you're,
never
going
to
consume
it,
no
one's
ever
going
to
use
it.
That
sounds
like
a
waste
of
time.
C
What
we
need
there
to
make
this
work
are
interoperable
standards.
We
need
ultimately
producers
and
consumers
to
agree
on
what
we
mean
technically
about
what
our
software
build.
Materials
is,
and
this
is
the
important
work
that
has
been
going
on.
I
think
for
a
while,
and
now
suddenly
is
meeting
user
demand
and
user
need.
C
There
are,
I
would
say,
really
two
clear
standards
that
are
probably
both
going
to
be
to
some
extent
widely
adopted,
at
least
to
start
with.
One
is
cyclone
dx,
which
was
actually
originally
sort
of
not
directly
spun
out,
but
as
a
result
of
work
that
went
on
the
dependency
check
project
from
oh
wasp
and
actually
now
the
cyclone
dx
project,
which
was
spun
out
separately
and
has
been
a
community
effort
very
much
open
source.
C
Turn
up
and
pull
requests
issues
very
much
just
on
an
open,
source-centric
sort
of
development
model,
svdx
that
you
might
have
come
across
for
its
list
of
economical
list
of
license
identifiers,
but
actually
the
spdx
project
is
broader
than
that.
It's
about
software
package
data
exchange,
it's
been
standardizing
in
software,
build
materials
bits
for
a
long
time.
There
is
a
stable
spec
and
that's
actually
just
been
going
through.
C
Basically
iso
certification.
So
there's
nicer
standards
around
this
now
the
new
sddx3
bit
as
well
solves
some
of
the
more.
I
think
supply
chain,
oriented
problems
and
it's
looking
quite
promising,
but
it's
still
early,
so
there's
a
bunch
of
history,
and
so
some
of
the
people
involved
might
say
these
are
not
emerging.
These
are
in
common
usage.
C
There
are
commonalities
between
these
two,
which
is
good,
and
there
are
already
tools
that
allow
some
interop
you
could
get
into
arguments
about.
Why
are
there
two,
rather
than
one
there's
an
x-killer?
You
see
a
xkcd
joke
about
that
somewhere,
but
there
are,
but
there
are
common
elements
and
other
standards
could
emerge
here
that
address
the
same
set
of
common
elements
and
again
I
think
they'll
have
an
interrupt
sort
of
conversation
already,
but
these
are
the
sorts
of
things
that
you're
talking
about.
Okay.
C
C
What
other
information
is
there
about
this
software
that
might
be
useful
to
the
consumer
and
and
again
for
both
the
cyclone
dx
and
spdx?
There
are
schemas
that
describe
this
in
jason
and
there
are
some
protoboss
schemers
around
there
are
xml
schemas
around.
This
is
actually
arguably
quite
good
for
something
like
xml,
where
there's
a
lot
more
richness
to
the
schema
declarations,
which
is
a
strange
thing
for
me
to
be
saying.
C
So
I
think
there
are
three
things
about
software
builder
materials
that
are
worth
sort
of
thinking
about
when
you
sort
of
start,
considering
like
how
they
might
play
in
a
software
stack,
the
first
one
that
everyone
goes
to,
and
I
think
too
many
people
stop
at
is.
I
need
to
generate
them
and
then
success
and
the
first
bit
is
you
probably
do
need
to
generate.
Then
the
second
one
is
not
true.
It's
not
the
end.
This
is
very
much
the
star.
There
are
tools
emerging
here,
both
from
within
the
cyclone
and
spdx
camps.
C
There's
a
good
set
of
cyclone
dx
plugins
for
different
package
managers.
The
maven
one
actually
is
particularly
particularly
rich
and
there's
a
long
tail
and
a
maturity
problem
there
which
I'll
come
back
to,
and
there
are
other
tools
as
well
that
have
been
doing
this
for
a
while
or
a
newer
that
are
also
starting
to
be
able
to
normally
as
well
as
generate
things
in
their
own
propriety
format,
also
output,
things
in
standard
formats.
That's
how
standards
become
the
de
facto.
C
So
there
is
work
going
on
here
and
I'll
come
back
to
some
of
the.
I
think
where
this
needs
to
go
from
where
it
is
today,
but
certainly
if
you
want
to
get
started
today,
there
are
probably
some
tools:
that'll
help
you
generate
response,
but
what
do
you
do
with
them?
It's
a
far
far,
I
guess
more
nascent
space.
C
How
do
you
store
them
like,
if
you
think
of
all
the
software
that
you're
producing
and
all
the
versions
of
software
you're
producing
and
all
their
dependencies,
not
just
in
terms
of
like
the
package
management
sort
of
libraries
you're
bundling
in,
but
maybe
container
dependencies,
maybe
service
dependencies
like
and
the
whole
chain
of
that
it's
huge
like?
Where
did
you
store
them
and
how
do
you
keep
them
up
to
date?
And
how
do
you
know
what
the
latest
versions
are?
All
those
problems
become
the
next
problem
to
solve.
C
This
is
much
earlier,
though
there
are
a
bunch
of
things
going
on
here
that
I
think
are
interesting,
and
this
is
actually
an
area
of
a
lot
of
innovation
happening.
I
would
say
around
the
sort
of
cloud
native
communities
and
like
the
bom
repo
server
is
a
good
example
from
the
cyclone
dx
folks.
I
don't
think
it's
specific
to
cyclone,
but
actually
it
might
be.
C
I've
played
around
with
this
a
little
bit.
It's
really
a
web
server.
That
gives
you
an
api
for
accessing
this.
That's
accidentally
s
bombs,
a
side
note
there
is,
I
think,
maybe
a
little
bit
like
the
work
that
led
like
led
from
docker
to
the
oci
specifications
as
well
as
the
s-bomb
specs.
We
probably
need
specs
that
describe
access.
C
You've
got
in
the
container
world.
You've
got
the
registry
specification
that
describes
all
of
that.
How
do
we
access
install
these
things
and
you've
got
the
image
spec
that
describes
the
actual
thing.
I've
not
seen
much
movement
there.
I
think
it
would
be
good
to
see
like
specifications
extracted
out
of
some
of
the
implementations
and
some
standard
submerged
there
as
well,
but
that's
maybe
getting
ahead
of
ourselves
because
realistically,
there's
not
a
great
solution
for
starring
today.
C
Everyone
ends
up
a
bit
hand,
rolling
something
interesting
things
here,
actually
shout
out
to
dan
lorenk
who's
working
on
the
six
star
project
he's
been
doing
some
work
around
looking
at
how
do
we
use
oci
registries
to
style
these
s
bombs,
because
why
can't
I
store
it
like?
If
I've
got
a
container
image?
Can
I
store
the
s-bomb
with
the
container
image?
C
Well
actually
with
the
artifact
spec
in
oci?
Now,
yes,
you
can,
and
you
can
even
sign
those
things
together
with
something
like
cosine,
so
there's
some
good
early
signs
of
like
the
tooling
here,
and
I
think
this
is
from
a
storage
layer
perspective.
A
really
interesting
idea
like
what,
if
we
just
said,
like
s-bombs
they're,
just
next
to
the
thing
that
they
are
representing
in
a
container
world
or
using
an
oci
registry
as
a
distribution
mechanism.
That's
a
really
powerful
idea.
I
think,
but
a
lot
of
work
to
do
here.
C
This
is
a
problem
you
run
into
and
I
think
you
should
not
focus
too
much
on
generating
there'll
be
a
lot
of
work.
There
you'll
find
something
you
get
started.
This
is
like
if
to
make
value,
I
think
this
is
part
of
it.
You
need
to
be
able
to
star
and
then
access
and
retrieve,
because
at
the
end
of
the
day,
that's
not
the
point
either.
The
point
is
to
consume
like
okay,
you've
got
all
the
vest
bombs.
What
are
you
going
to
do
with
them?
What
value
do
you
get
from
doing
so?
C
Yes,
you've
now
spun
up
some
infrastructure
now
storing
something
you've
got
new
steps
in
your
pipeline,
generating
all
this
stuff.
Do
you
just
end
up
with
bits
on
discs
that
never
get
used?
That
is
a
reasonable
fear.
That
is
something
that
some
people
in
the
broader
security
community
are
saying.
S-Bombs
are
a
bad
idea,
because
we
don't.
This
is
not
going
to
happen.
C
I'm
not
hopeful,
I'm
generally,
the
hopeful
person
like.
I
think
this
absolutely
can
happen,
but
we
need
to
have
people
thinking
about
focusing
on
it
and
building
things
and
demonstrating
examples.
There
are
really
strong
use
cases
here,
which
I
think
helps
and
checking
for
licenses
checking
for
vulnerabilities
again.
Actually
I
work
at
think.
This
is
what
we
do.
We
generate
an
s
bomb
and
we
check
for
licenses
and
vulnerability
issues,
but
that's
generally
been
coupled
it's
generally
been
an
implementation
detail.
C
Suddenly
both
are
independently
valuable
and
I
think
that's
an
interesting
like
sort
of
decomposition
that
we'll
see
more
broadly
around.
Like
some
of
these
spaces
I
mentioned,
I
created
contest,
I'm
a
contributor
to
the
open
policy
agent
project
when
I
get
time,
there's
lots
of
interesting
things
here
around
enforcing
policy,
and
you
can
think
of
an
s
bomb
as
a
really
rich
document.
C
Well,
I
can
now
write
policies
against
that
using
rego.
I
can.
What,
if
I
want
to,
I
don't
know,
prohibit
the
packages
from
github
or
I
want
to
say
no
to
specific
licensed
npm
packages.
That's
just
a
policy
decision.
I
can
encode
that,
in
regard
I
can,
I
can
put
all
of
my
s
bombs
through
it
and
I
can
surface
the
violations,
so
I
think
there's
lots
of
like
we
have
the
low
level
components
there
actually
fairly
straightforward
to
build
singular
demos.
On
top
of
that.
What
does
that
look
like
at
scale?
C
I
think,
is
interesting.
So
you
can
like
this
is
a
chicken
and
egg
problem.
No,
no
one
really
has
a
large
storage
of
s-bombs
in
a
in
a
standardized
sort
of
accessible
format
to
build
these
things
on
top
of,
but
it's
coming.
We
need
to
do
all
these
things.
I
sort
of
feel
we'll
probably
need
to
do
them
all
in
parallel
to
see
the
value
if
we
focus
just
on
generation
and
then
on
storage,
we'll
be
so
far
along
that
we
won't
have
value
and
it
collapse.
C
I
mentioned
some
other
things
I
think
search
here
is
a
really
interesting
case.
Imagine
just
the
ability
to
really
sort
of
quickly
seamlessly
ask
questions
of
your
organization's
software
supply
chain
like
like
how
many
versions
of
this
library
are.
We
using
you
sort
of
get
this
in
some
places.
Out
of
some
tools,
but
this
is
a
way
of
doing
it
in
a
decoupled
and
I
think
more
open
way.
I
think
there's
a
lot
of
interesting
potential
to
build
on
top
of
those
types
of
interfaces.
C
So
the
last
thing
is
really
okay.
If
you
think
this
is
interesting,
then
I
mentioned
the
sort
of
framework
documents
and
the
sort
of
some
of
the
introduction
documents
earlier.
They're.
Definitely
a
good
start
to
go
a
bit
deeper
if
you're,
like
already
okay,
I
buy
this,
I
want
to
get
hacking.
I
want
to
get
involved.
I
think
this
is
an
area
where
there's
a
huge
potential
to
do
so,
and
I
think
there
are
three
areas
and
that
are
interesting.
C
One
is
client
libraries
and
I
think
for
this
to
work.
We
don't
need
a
tool
over
here
that
generates
an
s-bot.
We
need
this
to
just
be
built
into
like
how
god
does
packaging,
how
cargo
works,
how
npm
works,
how
maven
works
like
we
need
first
class
I
like
plugins,
is
part
of
it
like
it
has
to
be
upstream,
in
my
view,
for
this
to
be
something
that
really
has
an
industry-wide
effect.
C
C
But
actually,
if
you
go
use
any
of
these
things,
you
need
to
be
someone
who
goes
like
great
jason
schema.
I
love
jason's
schema,
oh
fantastic
xsd.
I
know
this
backwards.
We
don't
have
good
like
higher
level
libraries
in
nearly
any
languages.
At
the
moment
we
don't
have
type
definitions,
we
don't
have
classes,
we
don't
have
things
that
really
lower
the
barrier
to
entry
to
using
these
tools.
C
It's
schemers.
I
have
a
strange
history
of
doing
weird
things
with
schemas.
Even
I
don't
really
want.
I
want
the
client,
client
libraries.
I
want
the
higher
level
tools
to
add
things.
So,
if
you're,
a
low
level,
client
library
person,
I
think
there's
a
bunch
of
things
you
can
get
involved
in
and
last
but
not
least,
I
mentioned
that
this
sort
of
we
need
tools
to
consume
s-bombs.
C
Yes,
there
aren't
many
out
there
yet
but
get
building
some
to
see
what
might
be
valuable.
What's
an
interesting
use
case,
what
do
people
hook
on
to?
I
think
these
are
great
opportunities
for
small
focus
projects
or
combining
project
x
with
s-bombs
to
see
if
something
valuable
comes
out.
The
other
side,
I
think,
actually
we'll
see
an
explosion
of
talks
and
little
projects
over
the
next
year,
or
so
that
do
just
this.
I
think
that
will
be
a
good
sign.
Not
all
of
them
will
be
right.
Not
all
of
them
will
work.
C
A
Fantastic,
thank
you
gareth.
That's
super
interesting.
I
I'm
really
interested
in
in,
in
the
whole
s
bomb
world.
You
know
I
spent
a
lot
of
time
around
the
embedded
space
and
I
I
kind
of
feel
like
some
of
those
ideas
that,
from
the
embedded
space
have
sort
of
moved
over
into
the
mainstream.
Now
you
know
it's
particularly
around
traceability.
If
we
look
at
I'm
thinking
of
things
like
base
rock
linux
and
stuff
like
that,
that
you
know
we're
all
about
which
particular
git
commit,
you
could
trace
every
single
software
back
to
yeah.
I.
C
Think
they're
like
the
embedded
space
is
like
is
often
been
it's
hardware,
people
and
hardware
people
have
to
deal
with
this
already
because
they're,
like
the
costs
and
economics
and
the
industry
as
a
whole,
is
generally
supply
chain
is
a
thing.
Software
has
not
been
the
case
and
I
think
we're
realizing
in
hindsight.
It
sort
of
has
to
be.
A
C
Good
question,
I
think
so
I
I
think,
there's
a
difference
between
configuration
and
the
sort
of
the
what
goes
into
something
I
think
like
that.
Difference
is
a
bit
subtle,
but
I
think
one
is
about
input.
One
is
that
what
went
into
the
creation
of
this
and
the
other
is
invariably
about
sort
of
much
more
focused
on?
C
What's
like
the
the
actual
thing
that's
running
so
again,
I
think
sometimes
cmdbs
have
been
stretched
or
actually
have
some
of
these
properties,
but
one
of
the
things
I
think
as
well
with
cmdb
is-
and
some
of
us
have
this
similar
problems
here.
Like
do
people
use
the
rich
data
in
a
cmdb
like
the
problem
with
cmdb.
C
That,
in
my
view,
is
never
the
theory,
and
I
built
some
similar
sorts
of
things
that
I
would
like
on
top
of
the
puppet
same
beauty,
puppetdb
back
when
I
was
a
user
and
that
puppet,
but
how
many
people
actually
have
a
really
successful
cmdb
story?
There
is
absolutely
the
same
risk
around
s-bombs.
I
think
s-bombs
need
to
be
embedded
in
software
development
and
cmdbs
never
were
yeah.
It's
a
good
rabbit
hole
to
jump
down
that
I
won't
do
do
now,
but
good
question.