►
A
A
A
A
A
A
A
C
C
You
know
what
what
are
the
best
practices
for
s-bombs
and
so
we've
we've
written
something
up
initially,
obviously
a
very
happy
job
about
him,
for
instance,
yeah
talking
about
like
Maven
Central
and
things
like
that
as
an
example,
but
try
our
best
to
incorporate.
You
know
the
the
other
aspects
of
other
package
ecosystems.
C
So
we
think
that
it's,
it
would
make
sense
to
bring
this
to
this.
This
openssf
community
to
and
the
hope
is
open.
The
ideas
by
doing
our
hope,
is
to
be
able
to
say,
as
a
community
as
a
working
group
that
we've
gotten
together
and
said,
like
these
are
best
practices
for
s-bombs
and
that
we
should
kind
of
either.
You
know,
maybe
publish
a
white
paper
or
provide
some
open,
SSI
recommendations.
C
Let
me
try
and
figure
out
one
second,
too
many
windows,
open,
I.
Think
it's
this
one
all
right.
Do
you
see
a
document
awesome?
Let
me
hide
this
cool
yeah,
so
really
really
short
document.
You
know
maybe
a
page
or
two,
but
really
it's
just
introducing
s-bombs
I
think
we
we
want
to
focus
on
very
specifically,
I
know
like
as
bumps
as
multiple
users
and
it's
very
overloaded,
depending
on
the
use
case
you're
talking
about
so
for
this
particular
document.
C
C
Whenever
you
can
within
your
language
ecosystem,
you
have
10
dependencies
and
use
the
information
to
generate
s,
forms
and
for
times
where
you're,
utilizing
code
or
artifacts
from
other
ecosystems
and
you're
not
sure
what
they
are.
You
should
also
include
them
as
known
unknowns,
but
then
within
your
s-bomb
and
yeah,
so
so
the
the
and
kind
of
just
to
wrap
up
you
know
just
like
responsibility
or
as
bomb
s.
Bombs
should
really
be
the
responsibility
of
whoever
is
uploading,
the
package
or
uploading
the
binary
or
the
library.
A
C
I
think
it's
both
I
think
it
ends
up
being
a
responsibility
of
the
owner
of
the
the
application
of
the
package
because
they
know
it
best
and
therefore
they
can
speak
to
the
accuracy
and
completeness
of
it
of
the
last
one,
but
I
I
think
we've
we've
talked
about
somewhere
in
this
document.
I
can
remember
exactly
where,
but
we
say
that
you
know
in
the
meantime,
package
managers
can
help
and
that
will
provide
value
and
basically
that's
it
could
be.
C
C
D
So
are
we
talking
we're
talking
about
build
dependency
as
we're
talking
about
runtime
dependencies?
What
are
we
so?
The
reason
I'm
uncertain
about
runtime
dependency
resolution
being
critical
to
like
s-bomb
generation?
Is
that
you
know,
even
if
you
do
a
very
thorough
analysis
of
all
the
versions
that
are
currently
available,
your
s-bomb
is
going
to
be
used
by
people
who
are
then
going
to
like
pull
newer
versions
of
some
of
the
Departments,
essentially
yeah.
So
so
what
are?
What
are
we
expecting
to
get
there?
Like
am
I
having
misunderstanding?
It.
C
So
in
this,
for
for
this
part
that
we
wrote
about
for
the
results
dependency
graph,
we
were
thinking
more
of
it
from
the
build
type
dependencies
and,
more
specifically,
when
you're
thinking
about
it
like
Java,
you
can
specify.
Oh,
you
know:
I
I
I'm
using
this
Library
I
can
specify
range.
But
you
know
it's
not
really
resolved
so
in
that
sense
like
rmpm.
C
B
Yeah
I
mean
I
I,
absolutely
you
know
people
who
who
push
packages
any
open
source
need
to
be
responsible
and
should
be
given
the
tools
and
and
follow.
You
know
some
guidance,
but
much
like
Jacques
was
saying
it's
kind
of
like
people
who
actually
use
the
libraries
and
packages
they
assume
trust
in
the
the
package
managers
that
basically
put
them
on
the
shelves.
Like
a
retail
store,
you
go,
buy
a
packaged
product
off
the
shelf.
C
B
B
Don't
inherently
trust
the
package
developer,
who
might
actually
have
bad
code,
so
why
should
we
trust
them
to
produce
a
good
s-bomb
and
tell
them
to
be
honest
and
truthful?
And
also
you
know,
wouldn't,
wouldn't
you
know
in
terms
of
standardized
tooling,
people
can
choose
any
tooling
they
want,
they
can
even
be
manually
producing
that's
bomb.
So
it
seems
to
me
having
some
something.
That's
automated
and
something
with
a
consistent
set
of
tools
like
we
like
we
set
up
for
Alpha
or
Omega
or
whatever
it
might
be.
B
C
C
A
I
guess
I
would
ask
a
sort
of
a
follow-up
question
to
Matt.
From
from
what
I
hear
it
sounds
a
bit
like
you're
proposing
one
of
two
things.
One
would
be:
there's
sort
of
an
agreed
tool
set
that
folks
use
at
the
package.
I
beggar,
pardon
the
repository,
maintain
its
use
to
publish
s
bombs
versus
there
is
a
central
service
that
repository
maintainers
can
use
well.
B
E
Yeah
I
want
to
Echo
a
lot
of
a
lot
of
Matt's
points
and
just
say:
maybe
maybe
this
document
should
end
with
with
more
concrete
recommendations
and
even
phased
recommendations.
You
know
where
we're
sort
of,
in
my
opinion
at
least
something
like
what
npm's
proposing
where
you
know,
build
artifacts,
including
corresponding
s-bombs,
are
created
in
a
in
a
sort
of
verifiable
way,
and-
and
you
know,
if
you
can't
do
that-
then
at
least
build
it
into.
E
You
know
your
build
tool
and
by
default,
and
if
you
can't
do
that,
you
know
maybe
here's
some
guidance
for
your
ecosystem
on
how
to
do
it
manually,
but
yeah
I.
Think
I.
Think
this
the
stock
looks
great
and
and
I
think
you
know
it's.
It's
tough
to
strike
the
right
balance
of
how
concrete
to
be,
but
slightly
more
concrete,
I
think
would
make
it
a
lot
more
actionable
at
the
sort
of
consumer
and.
C
I
was
just
gonna,
say:
yeah,
I,
I
think
that
that
there
are
definitely
things
that
we
can
add
on
add-on
here
and
obviously
this.
This
is
what
we're
coming
to
community
for
so
anyway,
that
we
can
collaborate,
I'll,
try
and
figure
out,
at
least
like
from
the
working
group
perspective
like
what
we're
calling
this.
Are
we
targeting
this
to
be
like
a
white
paper
recommendation
just
to
kind
of
figure
out
what
the
the
angle,
the
angle
is.
C
E
C
B
A
One
question:
I
had
I
hadn't
thought
about
the
question
of
where
or
who
should
run
the
tool
before,
but
I
guess
the
question
would
be
coming
down
to
do.
We
expect
the
repository
systems
or
the
package
Management
Systems
themselves
to
get
into
the
business
of
publishing.
S-Bombs
and
I
bring
this
up,
because
this
was
a
question
that
was
raised
in
the
context
of
bundler.
A
B
Say
100,
100,
I
think
that's
backed
up
by
the
work
in
the
oci
registry
spec
that
just
got
finalized
the
version
2
spec,
if
you're
producing
container
you're
supposed
to
produce
metadata
with
a
signed
s-bomb,
that's
you
know
graphically
tied
to
the
artifacts
produce
and
it's
an
artifactory.
It's
not
just
containers,
so
it
could
be
jar
files
could
be
a
library.
It
could
be
anything
any
granularity
of
anything.
You
produced
narrative
asset.
B
A
C
So
I
I
think
it
would
be
great
if,
like
folks,
that
want
to
to
kind
of
add
on
to
this
document
and
I'm,
hoping
and
I'll
keep
on
next
week,
but
I'm
hoping
like
within
the
next
the
next
couple
weeks
or
so
we
get
together
flash
out,
like
any
other
changes
that
we're
gonna
make
the
document-
and
you
know
we
understand
that
like
this
is
one
of
many
recommendations
that
we
can
put
up
so
I
think
completeness
is
not
not
really.
The
focus
here
is
more
like.
C
So,
if
folks,
that
want
to
contribute
to
this
can
can
ping
me
or
just
comment
on
comment
and
talk,
they'll
be
helpful
and
then
I
can
search
something
up,
and
then
we
can
dive
deep
back
to
this
I
think
the
the
thought
that
is
probably
around
mid
to
end
November.
The
question
will
be:
how
do
we
as
a
working
group,
kind
of
publish
this
I?
Guess
that's
a
common
question
from
my
side:
it's
like
what's
the
medium
that
we
see
this
being
published
in.
A
A
A
Okay,
so
there
no
objections,
that's
good!
So
I
will
begin
the
process
of
moving
that
forward
to
Tech.
The
next
question.
I
have
is
who's
going
to
help
move
the
ball
forward,
because
I'm
going
to
be
away
for
a
month,
I'm
after
Australia
to
get
petrified
so
I
won't
be
able
to
go
to
tech
and
and
Pitch
with
myself
and
I
was
wondering
if
anyone
feels
like
volunteering
would
like
to
do.
That.
A
A
C
E
Forgotten
and
actually
have
an
exciting
super
quick
update
there,
which
is
just
that,
so
this
was
for
the
open,
ssf
being
a
repository
for
data
about
repositories
which
would
be
of
use
to
security.
Researchers
I
have
actually
found
someone
who
has
expressed
interest
in
taking
this
on
as
a
contract.
Obviously
it
wouldn't
necessarily
write
the
contract
with
this
person
in
mind,
but
we
were
worried
about
finding
someone
who
was.
E
You
know
a
sufficient
like
polyglot
to
feel
comfortable
trying
to
implement
with
a
bunch
of
different
repository
ecosystems,
and-
and
so
that's-
that's-
the
exciting
news
there.
So
hopefully
a
lot
more
details
on
that
proposal.
This
would
be.
We
talked
about
all
sorts
of
things,
details
about
takedowns
and
the
reasons
for
those
takedowns
details
about
package
uploads
and
the
rates
and
how
frequent
the
versions
are
package
downloads
pipei
is
actually
doing
a
great
job
here.
E
They
make
a
lot
of
interesting
data
available
via
bigquery,
so
there's
infinite
data
about
package
managers
that
could
be
useful
in
package
repositories
that
could
be
useful,
choose
security,
researchers,
and
so
our
goal
is
to
kind
of
identify
a
subset.
That's
that's
pretty
feasible
to
do
near
term
and
hopefully
expand
that
out
in
the
in
the
sort
of
medium
and
long
term.
A
I
am
definitely
really
excited
about
this
project.
I
think
it's
important,
especially
since
I
as
I
keep
raising
when
when
the
research
comes
in
and
it's
comparing
multiple
ecosystems
there
are,
there
are
differences
and
it's
difficult
to
generalize
between
them.
So
it's
useful
to
have
multiple
different
data
sets
in
play.
B
No
just
super
excited
as
well
on
somebody
clapping
and
stuff,
but
something
that's
become
on
my
radar.
The
last
couple
months
is
is
not
just
package
managers
code,
but
data
is
equal
or
more
important
case
of
ML
and
model
creation,
and
I
think
that
a
lot
of
the
new
version
of
s-bombs
will
include.
Formulation
include
ml,
specifically
called
you
know,
processes
and
things
like
that.
B
So
I
think
we
probably
should
put
on
our
radar
too
evaluating
people
who
disperse
or
claim
to
disperse
data
models.
I
think
that
there
are
some
groups
trying
to
shape
up
those
spaces
and
be
able
to
rate
those
Services
as
they
come
online
to
rate
the
quality
of
data
models,
the
provenance,
so
the
data
coming
in
ETC.
E
Yeah
I
think
that's
a
great
Point
Matt
I've
I've
had
some
discussions.
I
know
hugging
face
is
one
of
these.
There
are
a
bunch,
but
that
are
that
are
attempting
to
be
like
you
know,
GitHub
for
ML
and
apparently
state
of
the
art
there
is
you
just
use
git
lfs,
to
put
huge
Blobs
of
data.
Pickle
is
super
common
as
a
format.
So
when
you,
when
you
load
things
into
memory,
it'll
exact
arbitrary
code.
E
So
all
of
these
supply
chain
considerations
that
apply
to
software
repos
certainly
apply
to
machine
learning
model
repos
as
well.
I
can
take
an
AI
to
try
to
reach
out
to
that
Community,
specifically
a
hugging
face
and
and
see
if
anyone
from
there
would
be
interested
in
joining
these
calls
thanks
Jack
for
for
doing
that.
A
E
Okay
and
then
I
guess
I
would
I
would
ask
if
we
have
one
meeting,
that's
about
four
hours
from
now
in
one
meeting,
that's
a
little
bit
earlier
than
that
I
think
that
leaves
basically
U.S
Eastern
as
one
of
the
only
time
zones
and
that
is
gonna
be
able
to
make
both
of
them
comfortably,
which
is
you
know
it
is
what
it
is
with
time
zones.
It's
not
great.
A
A
A
E
No
and
I
think,
given
the
number
of
folks
involved
I
would
be
hesitant
to
try
to
just
pick
a
time
out
of
a
hat.
I
feel
like
that's
a
good
way
to
you
know
completely
prevent
the
whole
company.
So
maybe
the
time
range
would
look
something
like
8
A.M
Eastern
up
until
like
noon
Eastern,
so
that,
like
four
hour
window,
feels
like
pretty
comfortable
time
range.
A
I
suppose
you
take
an
action
item
to
the
sort
of
two
house.
I
think
one
is
to
check
the
existing
calendar
too,
avoid
collisions
if
possible,
yeah
as
a
nice
to
have
because
there's
a
lot
of
stuff
on
the
calendar
these
days,
but
the
other
one
also
can
I
suggest
that
you
send
an
email
to
mail.
The
list
to
let
folks
know
that
we're
doing
this
because
that'll
that'll
help
catch
folks
who
are
out
of
sync
with
the
times
we
have
now.
A
A
Okay,
I,
don't
see
anybody
jumping
on
the
thing,
although
I
saw
an
interesting
note
from
Matt,
which
I'll
call
out,
which
was
that
the
Cyclone
DX
machine
learning
working
group
is
using
hiking
faces
our
hello
world
for
CDX
1.5.
That's
quite
interesting,
I
really
I,
really
like
seeing
the
advancement
in
the
state
of
the
art
with
this
stuff.
It's
it's
cool!