►
From YouTube: Security Tooling Working Group (August 30, 2022)
A
A
A
B
C
B
C
B
B
B
D
E
D
D
We
are
not
signing
in
in
the
S
Bond
everywhere
agenda,
because
this
is
technically
a
tools
working
group
or
whatever
we'll
figure
that
out
someday
Alan
asked
if
he
could
give
a
brief
overview
of
just
I,
guess
everything
sisa,
which
I
think
would
be
lovely,
because
sis
is
doing
an
amazing
amount
of
s-bomb
work
right
now
so
Alan.
Why
don't
you
take
the
floor
for
a
few
minutes
and
then
we'll
get
the
rest
of
the
meeting
underway.
A
A
Anyone
has
questions
great
and
I'll
paste
some
email
in
the
chat,
and
we
also
have
if
you're
curious
s
bomb
at
cisco.dhs.gov
gets
you
the
s
bomb
team,
which
now
has
three
people.
Us
government
is
paying
three
people
to
think
about
s-bomb,
so
ongoing
work
streams
are
Vex
vulnerability,
exploitability
exchange.
This
is
complementary
to
s-bomb
work,
essentially
allowing
you
to
say
hey.
This
is
my
S1,
but
it's
not
affected
clearly
smoke
and
Source
ideas.
There
number
two
is
Cloud,
not
only
online
applications.
A
Most
of
the
very
public
discussions
around
s-bomb
have
focused
on
on-prem
software.
We
want
to
tell
some
use
cases
about
what
it
means
for
more
modern
software
as
well
as
think
about
what
implementation
hurdles
we
need
to
overcome.
So
what
don't?
We
know
how
to
do
in
sort
of
modern
software
for
s-bomb
number.
Two.
Sorry
number
three
is
truly
an
implementation.
I
think
there's
a
lot
of
overlap
here.
A
The
vision
here
is
government
of
interest
in
a
thriving
test
bomb,
tooling
ecosystem
and
also
making
sure
that
our
assumptions
about
s-bomb
interoperability
are
actually
true
and
and
I'm
in
my
darker
days
of
skepticism
worried
that
we're
not
nearly
as
far
along
on
interop
as
we
need
to
be,
and
so
that
group
is
going
to
be
focusing
on
both
helping
Foster,
tooling
ecosystem
and
ideally
doing
some
Hands-On
work
for
testing.
In
drop
would
love
to
have
some
help
on
that
front.
A
Last
two
one
of
them
is
sharing
and
exchanging
s-bomb
data.
This
is
very
important
for
Enterprise,
but
also
I
think
valid
for
open
source,
which
is
how
we're
going
to
move
this
data
around,
especially
at
scale
if
you've
got
organizations
that
have
hundreds
of
suppliers
and
hundreds
of
customers.
What
does
moving
this
around?
Look
like
this
isn't
unique
to
s-bomb
data
I.
Think
it's
going
to
apply
to
a
lot
of
the
other
supply
chain
data
that
we're
focused
on
in
the
open
source
World.
A
But
that's
one
of
the
things
that's
really
driving
it,
and
the
last
piece
is
sort
of
on-ramps
and
adoption
trying
to
track
all
of
the
different
moving
pieces
of
the
s-bomb
world,
and
things
like
that.
So
those
are
the
five
working
groups.
We've
got
Cloud,
tooling
on-ramps
and
adoption
sharing
and
Vex.
All
of
those
are
different
from
government
policy.
A
If
you're
interested
in
talking
about
government
policy
I'm
happy
to
have
that
conversation,
but
from
the
perspective
of
the
government
convening
folks
in
a
public
friendly
fashion,
it's
not
supposed
to
directly
feed
into
things
like
executive
order
implementation.
But
we
can
talk
about
that.
If
you
want
to,
if
you're.
A
A
The
next
step
is
how
do
what's
the
actual
leverage,
so
nist
wrote
a
framework
which
sort
of
zoomed
out
and
made
it
a
little
fluffier,
and
the
next
step
is
is
what's
the
actual
lever.
There
are
two
levers
that
are
called
for
by
the
White
House.
One
is
a
directive
from
OMB
which
is
office
management
budget.
That's
part
of
the
White
House,
which
is
going
to
direct
agencies
on
how
to
purchase
things,
and
that
is
sort
of
administration
level
that
was
supposed
to
come
out
earlier
this
year.
It's
due
out
soon.
A
C
A
F
A
Great
great
question
fatigue:
this
is
where
I
I
have
to
sort
of
emphasize
that
sisa
is
convening
these
five
work
streams
and
our
job
is
to
help
the
community
bind
constructive.
Behavior
is
similar
to
sort
of
blf
convening
model,
so
I
I
worked
very
hard
to
not
put
my
thumb
on
the
scale
of
what
the
outputs
could
be.
The
out
type
of
outputs
that
have
happened
in
the
past.
Is
we
draft
a
document
that
has
you
know
an
FAQ
or
some
guidance
or
some
best
practices
or
some
definitions?
A
So
I'll
give
you
a
quick
example
of
something
that
has
been
proposed
in
the
tooling
Group,
which
is
to
say,
hey,
there's,
differences
between
different
parts
different
than
between
s-bombs
and
the
different
life
cycles.
So
an
s-bomb
of
a
Repose
different
from
an
s-bomb
builds
is
different
from
s-bombers
deployed
is
different
from
an
s-bomb
from
binary
analysis
tool,
and
so
wouldn't
it
be
helpful
if
we
had
a
new
data
field
and
some
definitions,
so
that
could
be
something
that
that
is
something
that
people
have
said
hey.
This
would
be
useful.
A
Some
of
you,
I
I,
I'm
locked
into
the
analogy
of
simulated
and
kneeling
from
you
know,
early
AI,
where
essentially
we're
in
a
high
energy
State
and
we're
going
to
brainstorming
and
then
slowly
we'll
crystallize
around.
What's
what
we
can
make
progress
on,
what's
tangible,
what's
valuable,
what's
feasible!
Is
that
helpful
critique,
yep.
A
I'll
put
a
link
to
the
list
which
is
on
the
assistant
website
and
if
anyone
is
not
signed
up
on
any
of
those
work,
streams,
send
us
a
note
and
we'll
get
you
signed
up
to
mailing
list
so
that
you
can
get
information
about
the
and
we'll
send
the
calendar
invites
and
we'll
we'll
give
you
updates.
We
try
to
send
notes
things
like
that.
B
Thanks
Josh,
thanks
for
the
the
overview
Alan
and
I,
will
I
will
plead
overbooked,
calendar
and
a
little
bit
of
ignorance
and
ask
are
any
of
the
work
streams,
in
particular,
focusing
on
the
consumption
of
signal,
right
signal,
being
s-bombs
or
attestations
or
other
other
sort
of
artifacts
of
a
build
process?
Are
any
of
the
work
streams
focused
on
the
consumption
of
those
artifacts.
A
A
There's
a
necessarily
lag
here
right
until
very
recently,
no
one
had
Pyle's
best
mom
sitting
around
so
I'm
completely
comfortable,
saying
yeah,
we're
that's
not
nearly
as
mature.
The
other
piece
on
consumption
is
telling
use
cases
for
cloud
and
online
applications,
which
is
to
say,
if
you
had
salesforces
s-bombed.
D
Awesome
all
right,
so
thank
you,
Alan
that
was
lovely
as
always,
and
I'd
encourage
anyone
interested
to
get
involved.
This
is
doing
some
amazing
work
and
it's
some
great
folks.
It's
definitely
a
different
cross-section
of
the
people
we
see
in
the
open
ssf,
which
I
think
it's
very
valuable,
good.
All
right.
Let's
move
right
along
I'm
gonna
share.
My
screen.
D
D
G
D
G
We've
got
a
rough
road
map
here,
including
when
we
start
the
community
when
they're
ready
and
aiming
to
start
Community
meetings
on
our
bi-weekly
Cadence
and
see
who's
interested
and
things
like
that
and
to
build
up.
The
community,
which
is
one
of
the
things
that
we
wanted
to
make
sure,
was
ready
for
trio.
G
G
They're
all
used
in
different
types
of
the
life
cycle,
and
we
have
some
gaps
in
some
of
them.
But
I'd,
like
you,
know,
I'd
like
to
make
sure
that
we
are
all
roughly
when
we're
talking
about
a
build
desk
bomb.
We're
all
thinking
the
same
thing.
We
know
that
that
is
different
than
a
source:
s
bomber
analysis
based
desk
bomb.
C
G
So
this
is
my
one
pager,
that's
what
I'm
gonna
say,
but
I
think
what
we
need
to
do
is
start
to
get
a
document
and
possibly
share
it
with
the
work.
That's
coming
out
of
the
tooling
group
that
Ellen
was
referring
to
and
make
sure
that
between
both
groups
we
have
General
alignment
about
the
names
and
then
examples
under
each
of
what
is
a
source,
but
s
bomb,
a
pointer,
either
pointers,
or
at
least
you
know.
G
Examples
of
this
is
the
type
of
thing
that
you
would
see
as
used
as
a
source
as
well.
Like
not
you
know
things
like
the
deployed
s
bomb,
though
I
think
we
may
want
to
change
the
terminology
a
bit
on
that
or
we
may
want
to
stick
with
that.
But
the
concept
is,
is,
and
the
install
configure
and
maintain
you
know
part
of
a
software
life
cycle
and
then
quite
frankly,
retiring.
H
So,
okay
I
I
love
the
idea
of
trying
to
split
up
these
different
kinds
of
s-bombs
because
your
rights,
it
can
be
confusing
if
there's
no
terminology
for
it.
I
have
to
admit,
though
my
head
is
going
tilt
on
these
definitions.
I
I
understand
each
word,
I,
don't
understand
the
secrets
of
words
are.
Are
we
open
to
trying
to
how
do
we
do
what's.
H
G
Comments
on
this
and
I'll,
probably,
and
then
once
this
has
been
there-
and
you
know
if
we've
got
some
aspects
from
the
season
side,
we'll
turn
it
into
a
Google
doc,
and
then
people
can
continue
to
refine
it.
I
can
see
I
think
it's
going
to
become
more
real
to
people
when
they
can
see.
Oh,
you
know
here's
an
example
of
why
I
want
to
use
a
sources
bomb
type
of
deal,
but
at
least
this
is
a
starting.
G
The
definitions,
I
thought.
The
diagram
that
came
out
of
the
ntia
effort
was
been
very
valuable.
In
fact,
I've
got
a
refined
version
of
that
diagram.
It
also
has
end
of
life
cycle
that
Bob
Martin
did
so.
He
took
this
diagram
and
added
a
another.
Little
actually
put
it
another
part
in
that
wheel
and
which
is,
you
know,
end
of
life
before
plan.
So
between
maintain
and
plan,
there's
sort
of
an
end
of
lifeing.
You
know
retiring
something.
D
B
I
I
Two
things
one
is
I've
seen
some
early
work
from
Cyclone
DX
in
terms
of
they
plan
to
add
formulation,
and
they
also
I've
all
seen
an
event
model,
so
they're
planning
to
basically
be
able
to
tag
data
in
the
s-bomb
relative
to
where
it
was
produced
in
the
complete
software
development
life
cycle
and
actually
and
and
bringing
what
tools
are
involved
to
produce
different
parts
of
the
data
potentially
so
is.
Is
that
can
be?
Can
that
be
considered
as
well?
C
G
I
You
and
and
lastly,
the
hardest
thing
for
me
is
not
not
not
getting
the
data
by
telling
people
how
to
put
the
data
into
the
s-bomb
relative
to
the
type
of
artifacts,
that's
being
produced,
whether
it
be
a
a
VM,
a
container
Hardware.
What
what
are
the
you
know,
basically,
I
think
what
are
the
guides
and
I
think
there's
a
concept
of
SAS
bombs
and
service
bombs,
and
how
do
they
look
differently?
Is
there
guidance
on
how
to
fill
those
different
types
of
artifacts
in.
G
G
I
I
I,
I,
guess
looking
to
to
create
a
graphic
that
represents
that
I
think
that,
like
I
said
something
that
represents
that
life
cycle
aspect
and
how
these
things
could
emerge
together
goes
about
the
graying
of
the
lines.
I
think
our
cameras
mentioned
that
these
things
will
you
know,
as
moms
will
have
a
a
combination
of
this,
of
these
data
sets
not
just
be
separated
out
or
in
these
different
categories.
Well,.
G
B
I
think
David's
comment
that
just
popped
up
a
visible
for
everyone
to
see
is
pretty
aligned
to
what
I
was
going
to
say.
These
four
terms
and
the
the
short
definitions
here,
I
think
I'm
missing
a
lot
of
context
to
map
these
definitions,
to
my
understanding
of
the
software
development
life
cycle,
whether
in
open
source
or
in
closed
Source
or
really
across
both
so
I'm
a
bit
lost
and
I
just
wanted
to
add
that
color
that
I'm
not
sure
how
a
source
s-bomb.
B
G
It's
it's
actually
talking
about
the
source
files
that
could
be
used
to
create
a
build,
so
I
think
the
key
phrase.
The
key
words
in
that
first
one
are
imported
because
what
companies
are
doing
today
is
you
know
if
they're
pulling
an
open
source
they
are
bringing
in
the
entire
package
and
doing
the
analysis
on
a
source
package
and
there's
an
S1
to
that
the
sources,
the
straight
source
files
you're
not
building
an
image,
yet
it's
just
the
source
file.
G
B
G
B
H
Yeah
and
let
me
put
my
cards
in
the
table
strategically
I
think
that
build
and
from
in
general,
we
want
Bill
dust
bombs,
because,
if
you're
only
analyzing
source
code,
there
is
always
the
risk
that
the
build
that's
performed
is
doing
something
that
you
can't
get
from
just
analyzing
the
source
and
trying
to
analyze
after
the
fact
after
a
bill
to
figure
out.
What's
in,
there
is
notoriously
difficult.
Dan
Lawrence
has
an
awesome
paper,
awesome
blog
post
about
the
drama
of
doing.
G
I
G
Definitely
your
build!
That's
like
that's
the
sort!
So
if
we
said
what
the
highest
source
of
Truth
is
I'd
actually
say,
you're
deployed
s-bomb,
linking
back
to
your
build
linking
back
to
your
sources
is
going
to
be
your
path
with
the
most
credibility
associated
with
it,
but
I
think
time
you
integrate
third-party
heuristics,
like
you
would
do
with
an
analysis
one
before
you
did
your
build
you're
going
to
or
quite
frankly,
you've
just
been
given
something
by
someone
and
you're
trying
to
figure
out
what
it
might
have
been
as
a
build
s
bomb.
G
There's
some
variability,
but
I
think
over
time.
If
you
don't
config
like
say
the
config
options
that
you
deploy,
something
some
that
vulnerability
may
or
may
not
be
triggered
and
I,
don't
think
we're
I
think
this
is
the
area
we
need
to
expand
into
as
a
group,
because
I
think
this
is
missing.
I
think
we're
getting
I
think
it's
a
community
we're
fairly
getting
a
good
idea
of
what
we
want
to
see
in
a
build
s-bomb.
Now
there's
a
lot
of
places.
G
We
can
continue
to
add
information
Etc,
but
the
deployed
s-bomb
is
where
I
see
people
doing,
runtime,
s-bombs
and
things
like
that
and
I
think
they've
got
so
the
idea,
because
if
something
is
built
in
you
may
or
may
not,
it
may
not
be
reachable
depending
on
how
you've
deployed
it
other
configs
and
deploy
works
too.
All.
D
Have
the
discussion
on
in
the
issue,
as
well
as
the
mailing
list
for
a
wider
audience,
because
we
don't
have
enough
people
here
so
I
mean
thank
you
Kate
for
putting
this
together,
because
it's
clear
that
we
don't
know
as
much
about
any
of
this
as
we
thought
we
did,
which
is
always
humorous
to
me
when,
when
we
bring
something
like
this
to
a
group,
but
all
right
I
want
to
keep
moving
us
along.
So
we
got
the
the
next
issue
was
s-bomb
use
cases.
Kathy.
Are
you
here,
Kathy
I
am
oh
fantastic!
E
G
E
E
-O-E,
okay,
I'll
I'll,
put
it
in
chat
here
before
you,
but
anyways
yeah
so
and
apologies
I,
was
on
PTO,
so
I
had
limited.
I
was
not
working
at
all,
so
so
I'll
get
started
on.
These
I
saw
some
comments
about
you
know
the
ntia
s-bomb
use
cases
and
stuff
like
that.
So
I'll
go
through
those
and
and
see
where
we
have
gaps
in
here.
I'm
sure
there's
a
lot
that
they
have,
that
we
don't.
E
H
D
D
G
This
is
like
this
is
something
that
that
clarification
on
what
I
was
planning
on
doing
the
the
NTI
docs
to
something
more
friendly
I,
don't
want
to
quite
frankly,
convert
the
ntia
documents
to
markdown
I,
think
that's
a
waste
of
time
and
an
error
prone.
So
if
someone's
meaning
that
I
disagree,
they're
up
on
ncia
just
go
there,
but
what
I
was
planning
on
doing
was
just
basically
sit.
What
I
had
sort
of
talked
about
was
looking
at.
G
The
here
are
the
key
fields
that
you
have
to
do
and
I
was
going
to
put
it
together
for
spdx
and
say
these
are
the
minimum
Fields
here's
the
spdx
stuff.
If
someone
else
wants
to
do
it
for
another
format,
they're
willing
to
stay
they're,
welcome
to
step
up,
and
if
we're
talking
about
these
documents
here,
which
are
the
tooling
ecosystem
that
was
part
of
the
taxonomy
that
seemed
to
cause
some
rat
holding
in
the
last
meeting.
I've
understood
things
properly.
The
taxonomy
is
the
moving.
G
H
G
Well,
we
want
to
get
this
up
on
GitHub
so
that
we
can
then
turn
it
into
something
that
is
either
a
dashboard
or
someone
can
basically
create
this.
The
to
do
right
turn
these
into
machine,
readable
format.
That
was
the
goal
that
we
were
aiming
towards.
The
first
thing
was
to
come
up
with
well,
okay,
how
do
we
classify
things
and
so
I
figured
use
the
starting
point
of
the
NTA
documents
and
the
taxonomy
there,
and
then
that
seemed
to
provoke
some
discussion
while
I
was
on
vacation.
G
H
I
I:
okay,
that's
the
real
question.
What's
the
goal
here,
everything
else
will
get
derived
from
that,
because
if
it's
a
list,
I
mean
there's
many
ways
to
do
it.
If
it's
a
landscape
form
like
the
cncf
and
I'd,
be
happy
to
post
a
link
to
it.
For
those
who
haven't
seen
those
this
is,
it
was
all
created
by
the
late
Dan
con.
So
right.
G
G
So
getting
it
to
us
to
the
stage
that
we
are
agreeing
on
the
basic
starting
point.
At
least
it's
nothing.
It
can't
change
it's
just
that.
You
know.
If
people
are
volunteering
time
to
do
work,
you
want
to
make
sure
that
they're
not
having
to
do
it
five
times
before.
We
can
start
to
see
something
visible.
D
I
Ice
was
odd
enough
to
the
issue,
but
basically
I
think
in
terms
of
tooling
one
of
the
things
I've
discovered
looking
at
all
the
tooling
is
every
tool
creates
their
own
graph,
I
think
and
a
lot
of
desk
mom
tools
are
specific
to
a
language.
A
lot
of
a
lot
of
tools,
try
to
bring
them
together,
run
them
independently,
but
each
runs
against
a
different
graph
or
partial
graph.
I
I'm
I
was
hoping
that
we
would
look
at
creating
a
tool
that
creates
a
what
we
believe
is
a
canonical
graph,
that
people
can
add
their
graphing
or
their
Technologies
to
where
they
their
intelligence.
In
terms
of
package
managers
list
file
system,
interrogation,
Etc,
that's
something
I'd
like
to
see
us
pursue
all.
D
B
Yeah
holidays
for
for
losing
the
connectivity
for
a
second
I
might
have
misheard,
but
it
sounds
like
folks
are
asking
for
a
or
they're
already
working
on
a
landscaper
overview
of
work
in
the
space
and
a
sort
of
shared
taxonomy
for
different
types
of
tools.
I
think
about
a
month
ago,
we
touched
on
that
and
I'd
offered
up
one
that
I
started
last
year
as
a
starting
point.
G
Right
and
we
would
we'd
sort
of
talk
through
that
and
I
took
some
of
that
feedback
and
but
I
took
the
ntia
starting
point
to
figure
that
we
could
go
from
that.
The
idea
is
the
taxonomy
and
so
forth.
We
want
to
have
it
in
a
way:
that's
machine,
readable
and
so
that's
part
of
why
we
want
to
try
to
standardize
some
of
this
stuff
and
that's
why
the
discussion
started
in
this
area.
B
G
B
F
D
I
Yeah,
it
basically
I
type.
My
comment
into
boxing,
so
basically,
every
tool
I've
encountered
creates,
has
its
own
graphing
tool,
so
it'd
be
nice
to
come
up
with
a
graphic
standard
and
and
a
tool
that
basically
can
be
added
onto
in
some
way
to
understand
more
and
more
the
dependencies
that
you'll
encounter
at
different
points
in
time,
even
going
back
to
Source
dependencies
build
dependencies.
I
G
I
Yeah
I
understand
I,
understand
that
that's
fine
I
just
put
it
here,
since
it
seemed
logical
I'm,
just
saying
every
tool
chain
I
create
that
creates
an
s-bomb
runs
a
bunch
of
scanners
and
they
all
contribute
to
data
in
the
s-bomb
and
they
all
create
their
own
graph.
And
that
seems
like
a
big
problem.
I
D
I
Work
if
you
go
to
every
tool
that
we're
going
to
be
evaluating,
go
in
the
code,
we'll
have
some
graphic
graphing
portion
and
even
tools
that
I
have
I'm.
You
know
I'm
trying
to
see
what
graphs
we
have
an
IBM
and
some
of
our
tooling
that
we
can
open
source.
My
goal
is
to
open
source
everything
I'm,
just
saying.
Let's
look
at
let's
look
at
the
tooling
as
we're
evaluating
it
for
its
graphing
capabilities,
sure
and
figure
out,
which
ones
are
best
to
breed
and
see.
I
B
Gonna
jump
in
we're
talking
about
two
different
things
here:
Kate
was
talking
about
having
a
taxonomy
or
a
machine,
readable
classification
system
for
tools
and
Matt
I.
Think
what
you're
asking
for
what
your
comment
is
asking
for
is
a
way
to
graph
dependency
chains
and
a
very
compact
machine,
readable
format
for
representing
and
thereby
graphing
dependency
chains
across
languages.
Artifact
types
Etc
has
already
been
proposed.
It's
gitbomb
we've
been
building
it
we'd,
love
folks
to
jump
in
and
use
that
and
adopt
that
as
a
standard
across
other
tools
and.
D
All
right
folks,
I
I
apologize
I
need
to
jump
actually
David.
Would
you
mind
kind
of
running
through
whatever
we
can
in
this
list
here?
I
have
a
family
thing:
I've
got
to
go
run
to
real,
quick
I
apologize,
but
I
think
the
takeaway
I
have
from
this
is
like
we
need
to
do
a
better
job
of
documenting
what's
going
on
and
what
we
want
to
do,
because
I
think
there's
still
a
lot
of
confusion
over
what
we're
even
trying
to
do
in
some
of
these
instances,
but.
D
H
B
B
Let's
create
a
common
taxonomy,
maybe
a
self-service
navigation
landscape
View
to
help
people
find
tools
that
meet
the
needs
that
they
have
that's
a
fantastic
goal
at
a
high
level
of
community
enablement
and
Tool
consumption.
Enablement
graphing
dependencies
is
one
type
of
tool
that
would
be
in
the
landscape
graph
right.
G
So,
like
you
know,
I
think
that
there's
there's
dependency
track.
There's
depths.dev
from
Google
we've
got
tools
out
there,
they're
all
doing
things
slightly
differently
and
I.
Think
Matt's
point
is:
how
do
we
make
sure
that
this
level
of
linkage
is
visualized
in
a
way
that's
coherent
and
consistent
so
that
when
different
formats
are
coming
in,
we
can
get
coherent
under
knowledge
out
of
the
graph.
Is
that
correct,
Matt
you've
got
your
hand
up
yeah.
I
I
So
anyways
in
terms
of
s-bombs
that
bring
in
tooling
and
other
parts
of
the
graph
and
and
part
of
formulation
and
then
also
I,
mentioned
the
runtime
graphs.
Some
I've
been
in
conversation
where
people
have
I
want
to
do
call
stack
graphs.
Actually
code
is
actually
executed
right
because,
like,
for
example,
we
have
containers
and
that
package
lots
of
they
aggregate
lots
of
things,
but
in
a
given
use
a
given
instance,
runtime
they're
they're,
not
all
on
all
the
tools
in
the
in
the
container
being
executed
right.
G
J
B
J
So
Eva
is
there
a
chance
that
you
might
be
able
to
create
a
shared
Google
doc
that
the
community,
this
community,
can
begin
making
comments
to
and
create
a
collaborative
document
to
get
this
conversation
moving
forward.
If
we
don't
do
something
like
that,
we're
just
going
to
stay
in
the
doldrums
and
it's
always
going
to
be
in
our
way.
B
I
I
actually
migrated
my
work
from
a
Google
doc
into
a
GitHub
project
so
that
folks
could
open,
PRS
and
discuss
it.
That
way,
based
on
a
community
request
last
year
to
stop
using
Google
Docs,
it
is
currently
in
GitHub
as
I
as
I
mentioned.
The
last
time
I
joined
this
working
groups
call
I'm
happy
to
move
that
project
into
an
openssf
hosted
repo.
So
it's
not
just
on
my
GitHub
I'm
happy
to
have
other
people.
B
J
Well,
it'll
be
really
cool.
If
it
was
on,
we
had
a
Hugo
server.
We
could
do
it
in
the
markdown
that
way.
We
have
a
finished
product,
it's
kind
of
getting
finished
as
we're
writing.
That's
how
I
would
really
love
to
see
it,
but,
however,
we
can
do
it.
I
think
we
need
to
get.
We
need
to
focus
our
attention
on
getting
that
done.
First,.
B
B
H
B
Think
I
introduced
A
New
Concept,
at
least
to
the
series
of
calls
that
I've
been
on
in
his
written
Group,
which
is
that
our
Focus
shouldn't
be
on
tooling
insofar
as
a
common
taxonomy,
our
Focus
shouldn't
be
on
tooling,
but
on
community
outreach
and
Community
cross-pollination
to
build
a
consensus
on
on
terminology.
How
do
others
feel
about
that
proposal?.
C
H
D
C
H
Both
are
important
you're.
Absolutely
right.
Community
is
vital
for
a
typical
developer,
though
they're
not
going
to
join
8
000
communities.
Tell
me
the
tool
to
install
I
install
it
now.
I,
don't
think
those
two
are
actually
really
separate
because
tools.
Typically
many
tools,
are
developed
by
communities.
So
they're
not.
B
How
would
we
address
that?
We
have
to
do
Outreach,
build
Bridges
talk
to
both
communities
to
reach
a
point
where
one
Community
is
willing
to
change
their
documentation,
words
in
their
in
their
docs,
like
open
PRS,
to
bring
them
together.
That's
the
challenge,
I
think
we're
facing
when
I
did
the
survey
last
year.
B
There
are
many
communities
and
the
projects
they've
produced
that
have
subtle
differences,
particularly
around
words
like
evidence
attestation.
Yes,
things
like
that,
and
that's
what's
continuing
to
roadblock
all
of
us
here
folks
will
join
the
openssf.
This
working
group
in
a
month
coming
from
some
other
community
with
a
different
expectation
for
those
sort
of
words.
H
H
H
H
G
Above
can
how
does
what
we
were
looking
at
right
now,
map
in
with
your
doctorate
at
this
point
too,
because
it's
a
fair
amount
talked
about
in
terms
of
some
of
these
definitions?
Are
there
things
that
are
close
enough
from
the
stuff
that
we're
talking
about
from
the
NTA
in
this
perspective?
Or
are
we
revisiting
this
from
a
completely
different
angle
and
that's
what
I'm
just
trying
to
understand.
B
B
Your
bill,
it's
the
Google
Doc,
is
an
annotation
or,
if
you
will
a
database
in
document
format
or
you've
defined
one
two,
three,
four,
five,
six,
seven
seven
fields
or
one
of
them,
is
the
primary
key.
That
is
the
project.
Name,
support
functionality,
location,
instructions,
how
to
use
version
supported,
are
the
six
data
fields
on
it
and
that's
the
the
structure
proposed.
Is
that
an
accurate
summary
and.
G
B
What
I'm
struggling-
and
it
may
just
be
the
the
format
of
this
I?
Okay,
there's
the
taxonomy
category-
produce
consume,
transform
yeah.
This
is
a
very
different
view
than
how
I
was
looking
at
it,
which
is
what
but
portion
of
a
supply
chain.
Does
it
fill
in,
and
that
is.
Is
this
a
specification?
Is
this
a
object
or
artifact
creation
tool
or
process
a
storage
system,
an
identity
system?
All
of
these
are
components
of
a
supply
chain.
G
G
H
Got
it,
unfortunately,
at
least
officially
our
we're
supposed
to
have
ended
at
55
after
so
technically
we're
almost
over.
So
thank
you,
everybody.
We
didn't
get
to
some
things.
I
guess
that's
good!
That
means
that
we
know
that
there's
more
that
needs
doing
I
think
we
knew
that
to
start
with,
but
you
know.
Thank
you.
Everybody
thank
you
for,
for
everybody
very
much
we're
willing
to
give
their
time
Matt.
If
you
haven't
created
that
new
issue,
please
do
because
I
actually
agree.
I
viewed
the
graph
I.