►
From YouTube: Supply Chain Integrity WG (July 20, 2022)
A
A
A
Reminder
that
these
meetings
are
recorded,
it
should
be
uploaded
to
youtube,
they
were
happening.
Someone
was
doing
it
for
me
and
then
I
think
that
stopped.
So
I
need
to
go
back
and
look
for
this
meeting,
which
ones
haven't
been
uploaded
to
the
youtube
channel
and
try
to
make
sure
those
get
uploaded.
I
think
there
was
a
a
comment
around
that
that
I
saw
but
feel
free
to
ping
me
in
slack
too
and
remind
me
I
could
use
a
nudge.
A
A
A
Okay
thanks
brian
yeah,
someone
was
uploading
them
and
it
had
like
a
nice
little
open,
ssf
slide
in
the
beginning
and
I'm
not
a
youtube
expert.
So
I
had
no
idea
how
to
how
to
do
that
when
I
was
uploading,
salsa
recording
so
anyway
cool
so
before
we
get
started.
Anyone
new
to
the
meeting
today,
that
wants
to
say
a
quick
hello
or
introduce
introduce
yourself.
D
G
A
C
A
Awesome
welcome
yeah
for
for
the
new
folks,
this
this
meeting's
been
great
to
get
presentations.
That's
how
we
started
the
meeting
early
on
when
we
weren't
quite
sure
what
all
the
problems
were
in
supply
chain
space.
So
if
there's
a
topic,
that's
relevant
to
open
source
software
supply
chain
stuff
feel
free
to
toss
your
name
in
the
upcoming
meeting
slot
or
we'll
get
you
scheduled.
F
F
We're
pretty
close.
We
just
need
to
wait
for
some
spiffy
spire
updates
to
tectonic
tecton
chains
to
land,
which
we
have
a
couple
of
prs
open
for
that
actually
brendan
lum
is
one
of
the
contributors
on
that
one
along
with
park
patel,
but
so
we're
doing
a
bunch
of
stuff
there
just
wanted
to
kind
of
highlight.
F
F
The
second
is
sort
of
building
sorry,
the
provisioning
of
the
actual
builds
themselves
tied
to
identity,
so
zero
trust
for
your
actual
build.
So
that's
both
of
those
are
sort
of
somewhat
accomplished
in
fresca
via
tecton
and
spire.
In
those
cases,
and
then
the
final
piece
that
we've
been
working
on
is
runtime
visibility,
which
is
just
how
you
know.
F
So
that's
one
big
thing
that
that
we've
been
looking
at
and
sort
of
looking
at
lots
of
different
tools,
whether
it's
a
lot
of
different
open
source
tools
on
that
on
that
front,
looking
at
ebpf
and
so
on,
but
we're
we're
definitely
interested
in
getting
some
more
thoughts
on
that,
and
in
addition
to
that,
we
are
also.
We
are
also
working
with
a
couple
of
different
groups
regarding
confidential
computing
and
sort
of
hardware
keys.
F
F
It's
not
really
usable
without
the
actual
hardware
that
backed
it
and
then
secondarily,
we're
also
looking
at
different
ways
to
you
know,
with
the
hardware-backed
identities
being
able
to
actually
sort
of
associate
that
with
the
build
so
that
we
can
actually
have
that
sort
of
where
we
can
sort
of
guarantee.
That
builds
were
actually
happening
on
hardware
that
was
approved
for
use,
as
opposed
to
you
know
somebody
who
had
nefariously
gotten.
You
know
hardware
attached
to
your
your
build
cluster
in
some
way.
F
F
You
know
where
you
really
want
to
make
sure
that
you
know
stuff
is
not
interfering
with
the
build,
as
well
as
in
cases
where
you
know
the
source
code
itself
is
considered
secret
or
is
considered
like
really
sensitive
and
or
some
sort
of
data
that
you're
pulling
into
the
build.
The
sensors
are
sensitive
and
you
don't
want
to
give
access
to
the
host
to
actually
be
able
to
see
what's
going
on.
F
So
those
are
the
main
updates
for
fresca
and
inside
the
the
google
doc
for
the
notes.
For
this
thing
I
have
some
additional
stuff
in
there.
If
folks
want
to
contribute
or
join,
there
is
a
open
ssf.
It's
it's
under
the
open,
ssf
calendar
is
the
the
meeting
and
it's
every
other
wednesday
at
10
a.m.
So
it
didn't
happen
this
week.
It'll
be
happening
next
week.
F
F
A
The
next
thing
we
have
on
the
agenda
is
a
presentation
from
adelpho
and
I'm
not
sure
how
long
how
how
much
time
he's
going
to
take,
but
we
might
end
up
early
if
any
or
if
anyone
has
any
other
topics
they
want
to
toss
in
the
agenda
for
discussion.
Please
speak
up
now
or
say
something
in
the
chat
and
we
can
time
box
adolfo
a
bit
if
needed.
A
A
B
Yeah,
okay,
cool
all
right,
so
yeah,
so
if
for
anybody
who's
around
the
s-bomb
and
s-phone
tooling,
as
some
specs
world,
I
probably
knows
that
during
this.
In
the
past
week,
cesa
has
been
running
this
series
of
listening
sessions,
which
have
brought
together
people
from
lots
of
industries,
government
contractors,
tool
makers
and
the
some
of
the
learnings
from
those
sessions
have
been
really
great
and,
and
one
of
the
one
of
the
recurrent
subjects
that
have
been
coming
up
is
specs.
B
B
So,
okay,
so,
let's,
let's
start
so
the
first.
The
first
thing
is
what
what
what
problem
is
vex
trying
to
solve.
So,
as
I
said,
if
you
have
a
known
vulnerable
component
inside
of
your
software,
what
does
it
mean
to
be
affected?
And
you
know
it's
in
there,
so
is
there
a
chance
that
that
idea
may
be
a
little
bit
nuanced?
So,
for
example,
if
I
give
you
the
phrase,
there
is
a
spider
in
my
house.
B
You
can
think
about
that
idea
and
it
can
have
several
possible
meanings.
So,
for
example,
maybe
puerto
has
a
pet
spider
in
his
house.
Maybe
I
just
found
a
spider
somewhere
dead
lying
around
or
maybe
there
is
an
actual
spider
in
my
house,
and
I
am
about
to
ingest
it.
While
I
sleep,
you
don't
know.
So
if
you
think
about
this
idea-
and
you
apply
it
to-
there
is
a
component
with
a
known
security-
we'll
know
it
in
my
product.
B
B
So
the
idea
of
an
s
bond,
you
have
a
product,
you
have
several
components
in
it
and
then
you
take
those
components
list
them
in
documents
and
those
documents
are
the
actual
field
of
materials
of
your
describing
your
your
project,
then
an
approach
is
you
take
those
build
of
materials,
feed
them
into
security
scanners,
and
then
they
give
you
information,
but
sometimes
that
information
can
take
this
shape.
For
example,
maybe
matching
a
list
of
vulnerabilities
with
known
versions
of
those
components.
B
So
vex
is
trying
to
solve
this,
for
your
try
to
is
trying
to
to
break
this
idea
and
give
you
more
information
about
those
components
living
inside
of
your
software
product.
So,
let's
think
about
what
it
means
to
have
that
vulnerable
component,
and
so
what
is
exactly
what
you
can
tell
users
using
vex?
B
Then
it
may
not
be
affected
and
it
gives
you
the
chance
to
express
why
it
is
not
affected,
and
it
also
gives
you
the
chance
to
tell
users
you
just
don't
know
yet
what's
going
on
and
so
then
the
another
two
key
factors
about
vex
is
one
information.
Is
time
based
and
it's
relevant
for
a
certain
period
of
time.
So
that's
the
first
one
and
the
second
is
text.
Documents
are
supposed
to
be
machine,
readable,
okay.
B
So,
going
back
to
the
idea
of
conveying
that
information
to
your
customers,
the
first
thing
that
you
would
sell
after
and
knowing
you
have
a
component
listed
as
vulnerable.
Is
you
you
need
to
give
your
customers
an
assessment
of
impact?
So,
as
we
said,
as
we
saw
before
it,
vexy
finds
your
pro.
Your
project
may
be
affected,
not
affected.
It
may
be
fixed
meaning.
It
was
affected
at
some
point,
but
you
it
affixes
already
inside
a
product
or
it's
still
on
an
investigation.
B
If
your
project
turns
out
to
be
affected
by
a
non-vulnerability,
vex
will
give
you
the
chance
to
give
if
it's
not
affected.
Bex
will
give
you
the
chance
to
express
to
your
users
how
why
it
is
not
affected,
so
it
provides
a
set
of
justifications
to
that.
You
can
express
in
the
documents,
along
with
a
human,
readable
explanation
of
why
it
is
not
affected.
B
This
include
the
component
may
not
be
present,
for
example,
if
you,
if
a
scanner
picks
up
a
vulnerable
component
in
a
container
layer,
and
you
override
that
that
later
the
squash
file
system
may
not
have
that
that
component,
then
code
may
not
be
there.
So,
for
example,
if
you
have
a
vulnerable
package
and
you
patch
it,
it
may
be
that
a
scanner
picks
up
the
version
listed
as
affected,
but
you're
already
patched.
So
the
code
is
not
there.
B
The
code
might
not
be
in
the
executable
path.
So
citing
dr
alan
friedman's
example,
I
think
there
are
two,
if
I
remember
correctly
well,
I
think
it's
two
functions
that
will
actually
trigger
the
heartbleed
bug
inside
of
open
ssl,
and
these
are
among
hundreds
of
other
functions
and
inside
of
the
library.
So
if
you
don't
trigger
those,
you
could
express
that
the
vulnerability
is
not
in
your
executable
path.
B
Then
the
code
that
is
exploitable
is
cannot
be
controlled
by
an
adversary.
So
then
the
simplest
example
of
that
one
is:
you
know
that
if
you
connect
to
a
socket
fitted,
some
garbage
you
may
be
able
to
get
an
exploit,
but
maybe
your
product
doesn't
even
expose
that
that
that
socket
and
the
same
thing
for
mitigation.
So
if
you
know
then
feeding
input
to
a
to
some
component
will
give
you
elevated
access.
B
B
So
there
are
currently
two
ways,
at
least
that
I
know
of
the
first
one
is
in
csuf
documents
and
also
inside
of
cyclone
dx.
So
let's
take
a
quick
look
at
how
this
the
the
vex
metadata
looks
inside
of
the
documents.
The
first
one
is
in
cyclone
dx.
So
while
we
go
through
these
examples,
keep
in
mind
the
formula
that
I
showed
earlier,
which
is
product
vulnerability
in
an
asset
and
a
set
of
outcomes.
B
So
in
cyclone
dx,
you
would
have
your
product
listed
as
the
application
inside
of
the
document.
Cyclone
dx
for
those
that
may
be
not
familiar
is
mostly
known
for
being
a
good
way
of
writing
software
wheel
of
materials.
It
also
has
some
some
other
tricks
of
its
sleep,
like,
for
example,
conveying
vulnerability
information
so
and
here's
the
the
application
listed
as
a
component,
then
here's
the
information
about
the
vulnerability.
B
This
is
a
made-up
data,
of
course,
and
then
here's
the
the
assessment
of
impact,
which
says
that
my
enterprise,
professional
application
version
2000,
is
not
affected
and,
finally,
the
analysis
conveying
information
of
why
it
is
not
affected.
This
is
the
machine.
Readable
label
which
is
vulnerable
code
cannot
be
controlled
by
adversary
and
then
a
human,
readable
explanation
and
the
next
one
is
in
srisa
insist
of
documents.
B
So
csf,
which
is
common
security
adversary
framework,
also
defines
a
way
of
conveying
security
information
about
products
and-
and
so
here
are
the
same
elements
inside
of
the
of
the
document.
Here's
a
the
product,
so
csaf
documents
really
allow
for
a
great
expression
in
defining
products
and
product
sets.
It
allows
you
to
define
families
groups,
some
list
them
in
all
sorts
of
creative
ways.
Then
here's
a
link
to
vulnerability,
then
the
product
status.
So
I'm
stating
here
that
version
one
is
affected,
but
version
two
is
no
longer
reflected.
B
Then
flags
inside
of
the
of
the
document
that
tell
me
why
my
product
may
not
be
able,
may
not
be
vulnerable.
So
here
I'm
saying
enterpriser,
2000
version
2
is
no
longer
vulnerable
because
the
components
are
no
longer
present
inside
of
the
of
the
product.
So
these
are
simplified
documents,
of
course,
just
to
give
you
an
idea
of
what
they
look
like.
B
Csf
has
one
feature
which
may
be
relevant
to
the
relevant
to
the
use
of
of
of
vex
and
expression
expressing
effects
information,
and
it
has
the
all
of
this
metadata
about
tracking
the
evolution
of
the
document
on
how
it
it
evolves
on
versions
and
and
maybe
cyclone
the
exerciser
too.
I
don't
remember,
but
this.
This
tracking
information
allows
you
to
know
if
you're,
looking
at
the
on
how
the
document
has
been
changing
over
time,
and
so
that's
basically
the
the
the
presentation
before
leaving.
B
So,
for
example,
things
like
how
can
we
discover
vex
metadata
and
how
do
we
store
the
documents
and
both
cyclone
dx
and
csaf
provide
guidance
on
how
to
store
and
locate
documents,
but
sometimes
these
recommendations
turn
out
to
be
not
as
useful
in
practice.
So,
for
example,
are
we
thinking
about
storing
them,
in
other
sorts
of
attestations
that
we're
already
doing
maybe
pointing
to
them
in
transparency
logs?
B
All
of
that
sort
of
questions
are
about
it
here
and,
for
example,
one
of
the
big
questions
regarding
index
and
some
of
the
uses
of
phase
bombs
is
what
about
when
we
compose
bombs
dynamically
or
we
have
a
workload
defined
with
several
less
bombs.
This
is,
I
think,
the
most
puzzling
question
for
me
right
now,
since,
if
you
think
about
a
cloud
native
environment,
you
may
have
a
several
workloads
running
which,
if
you
compose
the
s
bombs
for
them
may
all
of
them
may
be
different.
So
you
have
a
running
workload.
B
If
you
update
a
base
image
it
effectively,
it
effectively
has
a
new
s-bomb.
So
if
we
describe
exploitability
information
in
a
vex
document
which
is
paired
to
a
which
is
spread
to
a
product,
how
does
it
apply
to
changing
images,
for
example,
and
changing
workloads?
That
is
well.
I
understand
that
bex
may
be
fixed
in
time
and
maybe,
depending
on
the
information
available
at
the
time.
How
do
we
express
how
do
we
match
information
about
the
product
to
its
running
workload,
for
example,
questions
about
trust
who
can
produce
specs
documents?
B
Is
it
valid
if
a
company
doesn't
provide
tax
information,
but
I
have
an
assessment?
Can
I
produce
that
for
a
product?
Can
I
trust,
whoever
is
providing
that
information,
and
another
thing
is:
should
we
have
a
expiration
time
on
vex
documents,
for
example,
I
mean
those
get
superseded
by
new
versions,
but
do
we
need
the
freshness
of
the
data?
B
And,
finally,
what
I
would
be
most
interested
in
hearing
is
how
people
are
using
vex.
Are
you
using
it?
Yes,
how
are
you
writing
documents
consuming
them
and
if
no,
why
do
you
think
it
applies
to
your
scenario
or
not,
or
are
you
planning
to
to
do
it,
and
so
my
twitter
handle
it's
workable?
If
you
want
to
connect
and
still
discuss
a
little
bit
more
about
vex,
I'm
happy
to
hear
use
cases
and
ideas
about
people
and
and
yeah.
That's
that's!
It.
G
B
So
one
thing
is:
I'm
coming
towards
specs
as
a
mostly
as
an
end
user
and
implementer.
So
I
I
have
some
ideas
that
may
not
reflect
the
current
vex
group
thinking
and
it's
basically
well.
My
opinion
is
that
all
of
this
information
should
be
machine.
Handled
and
tooling
is
gonna,
be
the
answer
at
some
point,
but
I
would
love
to
hear
what
the
others
think.
I
think.
E
B
H
Yeah,
I
I
think
also
one
of
the
at
least
the
industrial
use.
Cases
really
is
around
kind
of
like
the
delivery
system
of
of
like
where
these
documents
come
from.
I
think
initially
it's
looking
at
it
from
a
product
standpoint
and
obviously
I
think
the
the
group
also
has
brought
up
the
back.
Smoking
group
has
brought
up
things
like.
Oh,
you
know
like
the
disclosure
policy
and
things
like
that
as
well.
So
and
these
from
the
current
point
of
view,
it
seems
like
and.
H
G
Yeah,
I
put
it
in
the
chat
that
you
know
for
for
us.
We
have
several
contracts
right
with
large
corporations
or
government
entities
that
you
are
not
allowed
to
disclose
a
vulnerability
until
you
have
a
fix
or
a
patch
right.
So
having
the
ability
for
customers
to
pull,
vex
right
or
you
know,
receive
the
vax
prematurely
is
not
we're
not
capable
of
doing
that
right.
We
might
be
able
to
expose.
G
G
No,
there
are
some
contracts
where
it
literally
says
you
are
not
allowed
to
disclose
unless
we
are
disclosed
first
right
and
there's
a
lot
of
contracts
like
that,
and
the
idea
is,
is
that
if
you
disclose
it
to
a
customer-
and
they
have
somebody
that
you
know
is
you
know,
nefarious
and
then
wants
to
do
damage
to
other
companies
that
they
know
use
that
product.
Then
they
can
go
attack
that
product,
because
they
have
premature
information
about
that
vulnerability.
G
A
G
And
so
the
customer
can't
state
certainty
or
100
certain
that
it
is
affected.
They
would,
you
know,
ask
our
pcert
team
to
validate
and
we
would
go
investigate
right,
but
that
wouldn't
be
a
true
case
right
unless
the
s-bomb
is
is
or
unless,
unless
the
vulnerability
has
been
disclosed
by
ibm
and
has
said
they
are
affected
or
not
affected
or
it's
been
fixed.
A
customer
can't
state
that
we
are
vulnerable
because
we
haven't
made
an
official
documentation
on
on
that
vulnerability.
C
G
G
C
F
F
B
Yeah,
I
think
that's
the
the
time
fashion
of
the
document,
so
they
are
bound
to
a
certain
point
in
time.
So
you
you
expect
them
to
to.
You,
expect
to
be
new
versions
of
the
document
once
the
information
about
the
vulnerable
packages,
changes
and
also
information
about
how
those
packages
affect
your
product.
B
F
It'd
be
interesting
because
I
can
imagine
some
universes,
where
you
know
there's
some
situations
where
there
could
be
contradictory
information
right.
You
know
a
a
provider
of
a
package
might
say:
hey
we're
not
vulnerable
to
this,
and
some
security
firm
says.
Actually
we
tested
your
package
and
it
is
very
much
in
fact
vulnerable
to
this,
and
what
does
that
look
like.
B
D
E
H
H
H
H
H
Done
probably
have
to
do
with
some
level
of
sensations
and
the
trust
bothers
you
around
that
michael
id
brought
up
a
earlier
point.
I
think
it's
interesting
so
facts.
You
can
also
say
that
if
you
don't
know
whether
you're
affected
by
a
certain
cpe,
I
think
the
default
is
like
there's
a
under
investigation,
so
you
can
state
that
you
know
that's
a
cv.
We
don't
know
whatever
affected.
So
we
just
like
it
is
under
investigation.
F
It
just
means
that
you
do
not
have
the
information
right,
yeah
or
or
rather
the
thing
that
I'm
actually
kind
of
curious
about
with
some
of
this
stuff
is
right.
When
I
go
and
view
like,
is
the
lack
of
effects
mean
that
it
actually
is
vulnerable
that
can
kind
of
get
complicated
right
like
at
what
point
can
a
is
there
something?
And
I
don't
know
if
this
is
included
in
any
of
the
other
stuff,
that
is
there?
F
Is
there
something
like
the
opposite
of
a
vex
of
a
package
acknowledging
that
it
is
vulnerable
to
something
and
that
currently
there
is
no
patch
for
it
or
this
particular
version
is
vulnerable.
And
yes,
you
should
be
updating
to
the
more
recent
version,
because
he
you
know
if
it's
just
something
like
if
based
on
what
we've
been
discussing
here.
F
If
certain
companies
are
reluctant
to
issue
a
vex
without
disclosing
other
things
and
whatever
else,
I
could
see
a
lot
of
situations
where
people
would
be
reluctant
to
either
acknowledge
that
there
is
a
vulnerability
or
issue
of
x.
Given
certain
situations-
and
I
think
the
thing
that
we're
trying
to
push
here
is
more
transparency,
not
not
have
folks
scared
of
giving
transparency.
F
Yeah
and-
and
I
think
like
because
when
I
think
about
purely
from
the
end
user
perspective,
an
end
user
is
going
to
go
and
download
a
package
or
download,
and
and
when
I
say
a
package,
I
don't
just
purely
mean
the
code.
It
could
be
a
combination
of
the
source
code
plus
the
configuration
plus
infrastructure
as
code
whatever
it
doesn't
necessarily
really
matter.
But
I,
when
I
think
about
that,
I
think
that,
there's
probably
you
know,
the
things
I
would
want
to
know
is
whoever
is
giving
me
this
thing
to
the
best
of
their
knowledge.
F
Are
they
exposed
to
certain
cds,
and
I
want
to
have
information
that
I
could
use
to
make
informed
decisions
so
if
they
are
vulnerable
to
a
certain
thing,
if
you
use
it
a
certain
way,
I
want
to
know
if
they're
not
vulnerable
to
a
certain
thing,
because
they
have
mitigating
whatever
you
know
something
like
vex
or
whatever,
and
they
can
say
hey.
I
still
want
to
know
and
if
they
are
not
sure
right.
I
want
to
know-
and
I
think
all
three
of
those
are-
are
super
valuable
to
sort
of
the
end
user.
B
F
Yeah,
no,
I
I
agree.
I
think
folks
are
gonna,
start
demanding
this
information
and
I
think
over
time-
and
I
know
this
is
a-
is
a
big
thing-
that's
being
discussed
at
especially
large
enterprises
that
are
more
like
consumers
of
this
sort
of
stuff,
like,
for
example,
large
banks
and
whatnot
they're.
Coming
out
there
and
saying
hey
at
a
certain
point.
You
know
we
might
be
signing
big
contracts
that
have
that
as
an
expectation
right.
You
know
that
you
are
going
to
be.
F
You
know,
giving
s-bomb
you're
gonna
be
giving
vex
information
as
part
of
the
deal
and
and
if
you
know-
and
I
think
once
again,
you
know
to
to
melbourne's
point.
I
think
we
might
start
to
see
a
bit
of
a
shift
where
customers
might
start
asking
for
some
of
this
stuff
and
there
might
be
a
little
bit
of
also
a
shift
in
in
sort
of
the
the
legal
way
of
thinking
around
some
of
it.
B
B
There
are
two
two
main
goals
that
your
product
will
need
to
have
one
if
you're
affected
get
the
fix
out
as
quick
as
possible,
which
is
should
be
fine
with
legal
and
then
on
the
other
side,
if
you're
not
affected
by
a
certain
cve
or
whatever
vex
will
give
you
the
chance
to
tell
your
users.
Okay,
my
product
is
not
affected,
which
should
be
much
easier
with
lego.
I
guess.
E
E
You
know
staging
whatever
they're,
not
they're,
not
going
up
there
and
vex
is
separable,
so
the
the
consumer
of
x
is
not
just
the
end
user.
The
s
bomb,
the
consumer
of
vex,
could
also
be
internal
sources,
internal
ci,
devsec,
ops,
people,
internal
people,
pcert
teams.
They
could
track
life
cycles
and
build
on
information.
The
purpose
of
vex
is
to
convey
the
complete
picture
of
a
vulnerability
at
all
stages
to
show
what
type
of
remediations
what
tools
were
used.
What
analysis
was
done?
E
What
the
corrective
actions
are
all
those
things
and
that
update
that
information
is
dynamic,
as
developers
and
security
people
look
at
a
vulnerability
and
fix
it
in
a
given
product
and
that
information
can
keep
conveying
backs
it's
the
choice
of
how
you
make
that
public,
either
in
the
s
bomb
directly
or
relative
to
that
I'm
referenced
by
it.
That's
your
choice.
Ideally,
though,
that's
why
I
go
to
apache
apache.
Everyone
has
a
project.
A
A
A
B
E
Yeah,
I
just
want
to
raise
awareness.
I
mean
this
speaks
to
there's
a
new
effort
started
at
owasp
os
foundation
and
actually
it's
joint
cross-spx
there's
something
called
an
s-bon
maturity
model,
they're
going
to
be
looking
at
different
industries
and
different
levels
of
information,
the
s-bomb
and
they'll.
Be
you
know.
The
maturity
model
will
reflect
the
need
for
vulnerability
expression
and
all
this
information
that
michael
was
alluding
to,
so
that
people
are
being
looking
for
more
and
more
mature
s,
bombs
more
with
better
information
over
time.