►
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).
A
Cool
so
yeah,
first
of
all
welcome
amir
and
I
s
z-
I
I
don't
know,
but
if
you
wouldn't
mind
giving
a
quick
intro
to
everybody,
whoever
would
like
to
start
yeah.
B
Yeah,
I'd
love
to
start
good
morning,
everybody
I'm
amir
montezeri.
I
represent
ostif.org
the
open
source
technology
improvement
fund,
we've
been
participating
in
the
securing
critical
projects.
Work
group
and
I
saw
your
presentation
on
at
the
town
hall
meeting
on
monday,
and
I
thought
you
brought
up
some
really
good
points
and
I
actually
referenced
your
white
paper
when
I
was
talking
about
ostif
and
our
security
audits
and
doing
security
review
of
open
source
projects
so
yeah.
B
I
just
thought
I
would
get
involved
with
this
with
this
work
group
as
well,
and
looks
like
you're
working
on
some
really
cool
stuff
too,
with
the
security
metrics
that
I
find
interesting.
So
I
thought
I'd
get
involved
here
as
well.
A
Oh
and
sz
or
lind,
I'm
sorry,
yeah.
C
Hello,
everyone
good
morning
and
a
good,
let's
say
good
night,
because
he's.
C
C
This
project
aims
to
establish
an
open
source
based
layer
of
industrial
grade
software
to
enable
the
use
and
implementation
of
software
building
blocks
for
c4
infrastructure,
and
I'm
the
steering
committee
member
former
newest
kernel,
work
group,
chair
and
active
in
the
security
work
group
and
the
last
month.
I
have
the
session
in
embedding
in
this
conference,
europe
with
the
topic
of
the
thread:
modeling
key
methodology
and
applications
from
open
source
software
c4
infrastructure
platform
perspective.
C
Another
nearest
from
our
project
is
open.
Champ,
I'm
the
governing
board
member
in
open
chen,
the
invention
project
defines
effective,
open
source
components
and
the
open
chance
standard
became
the
iso
standard
last
month,
yeah.
So
in
my
space
yeah.
Finally,
in
my
spare
time
I
contribute
various
open
source
projects
such
as
linus
kernel
and
debian.
C
The
goal
of
the
team
is
to
maintain
the
security
relative
to
us
correctly
and
we
merge
back
to
us
from
the
directives,
so
I
have
been
checking
this
workgroup
status
for
months
to
seek
some
possible
collaboration
either
in
jbn
or
cip
project.
So
that
is
my
brief
introduction.
Thank
you.
C
I
will
pass
some
project
or
teams
link
to
the
chat
box.
A
Okay,
awesome
so
there
I,
I
posted
the
meeting
notes
if,
if
anybody
needs
the
midi
notes
or
somehow
missed
it
in
the
chat,
I
think
it
kind
of
goes
away.
If
you
join,
if
I
post
it
and
then
you
and
then
you
join
it's
in
the
meeting,
invite
as
well.
Please
add
your
name
to
the
top.
A
If
you
have
anything
for
the
agenda
that
you'd
like
to
talk
about
today,
just
add
it
to
the
to
the
to
the
bullet
points,
but
I
think
we've
got
a
discussion
on
kind
of
the
north
store
north
star
I'd
also
just
like
to
maybe
just
start
with
kind
of
the
super
high
level
let's
be
well.
A
In
my
opinion,
at
least,
there
are
multiple
work
streams,
doing
work
that
could
at
least
be
perceived
as
overlapping
with
one
another
and
that's
not
necessarily
a
problem,
and
that's
not
a
certainly,
not
a
problem
that
we
must
fix
like
immediately,
but
we
should
at
least
rationalize
where
the
interfaces
between
those
those
things
are
so
that
we're
not
unnecessarily
or
accidentally
duplicating
work.
So
the
the
thing
that
I
have
in
my
head-
I'm
going
to
be
super
super
transparent
here
is
the
scorecard
project
is
collecting
metrics.
A
The
metric
project
had
started
collecting
metrics
a
lot
of
those
metrics
are
exactly
the
same
metrics,
so
I
don't
like,
I
don't
think,
there's
any
reason
to
have
like
both
of
them
doing
the
same
things,
and
I
also
have
like
no
ego
in
this
at
all.
So
I
have
don't
care
that
the
slightest
bit
if
the
metrics
project
uses
the
scorecard
project
to
do
the
the
calculations
or
any
other
combination
of
anything.
A
But
I
don't
want
to
go
down
a
path
and
just
kind
of
ignore
the
problem
until
it's
so
obvious
that
we
have
two
exactly
the
same
projects,
full
stack,
you
know
top
to
bottom,
so
what
I
would
propose
is
as
we're
as
we're
having
this
discussion
today
I
would.
I
would
submit
that
we
should
all
kind
of
just
keep
an
open
mind
on
the
the
kind
of
focus
on
the
requirements
and
not
so
much
the
implementation
or
who
does
it
or
which
work
group
it's
under
or
anything
like
that.
A
I
think
we
can
all
work
to
make
sure
that
the
right
thing
happens.
We
need
to
know
what
the
right
thing
is.
First,
though,
I
think
that's
the
purpose
of
the
the
requirement
doc
I'll
open
it
there.
If
any,
does
anybody
want
to
kind
of
comment,
or
am
I
totally
off
base?
Am
I
making
something
out
of
something
that
isn't
there.
E
Yeah
so
I'll
jump
in
I
I
agree
with
that.
I
think
you
know
from
from
my
perspective,
you
know
that
is
kind
of
the
purpose
of
the
requirements
document.
So
we
have
these
three
projects
that
are
all
doing
similar
things
and
that
they're,
you
know
gathering
security
data
and
then
trying
to
make
that
available,
for
you
know,
developers
to
see
how
they're
doing
and
also
for
consumers
of
software
to
make
choices
about
what
software
they
use.
E
I
I
would
you
know
my
sort
of
putting
it
out
there
is
that
I'd
love
to
see
all
those
things
kind
of
converge
in
the
long
run,
which
is
why
I,
you
know,
started
a
section
called
north
star.
I
think
it
might
take
some
time
and
we
kind
of
need
to
think
about
what
the
roadmap
is
and
how
the
pieces
fit
together.
E
But
so
I
don't
think
there's
anything
we
need
to
change
immediately
for
anything,
but
just
you
know
be
conscious
about
what
what
we're
building
and
how
we're
building
it
and
what
customer
problems
we're
solving
together
going
forward.
Those
are
my
putts.
C
F
Yeah,
I
would
echo
similar
sentiments
to
both
michael
and
kay.
I
think
it
makes
a
lot
of
sense
to
make
sure
we're
not
duplicating
effort.
I
may
have
missed
a
meeting
or
there
may
be
some
reason,
but
I
was
actually
a
bit
surprised
about
the
scorecard
project
launch
because
it
was
so
similar
in
flavor
to
a
lot
of
the
things
we've
been
doing
here,
and
I
know
we
were
talking
about
kind
of
what
project
goes
where
and
how
they
relate
to
each
other
with
kay's
documents.
F
G
Hey
so
this
is
kim
I
work
on
the
scorecards
project
when
we
set
out
to
start
working
on
this.
You
know
our
requirements
were
different,
it's
not
actually
even
metrics,
they
are
boolean
results
coming
from
different
projects
and
in
there's
you
know
everything
has
to
be
objective,
so
there's
no
sort
of
subjective
data
that
we're
gathering
the
word
less
interested
in
the
display.
G
We
would
like
this
data
to
be
consumed
in
different
places,
but
that
is
not
something
we're
actively
working
on
we're,
hoping
that
other
places
you
know,
can
ingest
or
call
the
cli
and
display
the
results
somewhere,
and
so
I
think
I
think
those
are
some
of
the
differences
that
were
coming
out
so
that
you
know
there's
not
our
scope,
isn't
to
expand
it
into
covering
things
like
insights
and
subjective
data.
G
One
of
the
core
goals
was
to
make
this
automatable,
so
you
know
for
consumers
or
for
people
just
trying
to
call
the
api
or
the
cli.
Sorry
yeah,
we,
you
know
we
looked
at
at
all
of
the
spreadsheet,
the
the
insight
spreadsheet
data
and
went
through
and
tried
to
see.
If
we
could,
you
know
if
there
was
a
lot
of
overlap
and
there's
just
wasn't
a
lot
of
what
we're
trying
to
cover.
In
there
we
shared
our
docs
early
on
and
yeah.
G
A
Okay,
so
so
I
I
mean,
I
guess
my
again
super
transparent.
My,
like
quote
fear,
it's
not
really
a
fear,
but
like
is
that
the
scorecard
project
as
a
in
the
scorecard
project
roadmap,
is
building
the
ui
front
end
similar
to
what
the
metrics.
A
So
so,
if
you
say
that
you
know
and
obviously
like
the
future,
can
change
sure
you
know,
but
if
right
now,
you're
not
envisioning
a
ui
on
top
of
the
scorecard
and
you're
limiting
scorecard
to
the
mechanics
of
the
collection
of
objective
data,
then
that's
great,
because
that
that
should
just
plug
into
our
or
any
other
system
and
all
is
happy
and
that
and
that
that
also
helps
us,
because
that
means
that
we
don't
need
to
worry
so
much
about
how
to
collect
those
same
things.
We
can
just
call
the
scorecard.
G
Yeah,
there's,
you
know,
there's
no
storage
right
now,
like
it's
not
you
know
it's
just
a
cli.
It's
not
running,
there's
no
api,
but
we
have
no
plans
to
build
a
ui.
Okay.
A
Okay,
any
other
comments
on
on
this
topic.
Before
we
jump
into
the
the
cave's
requirement,
talk.
A
H
So
hearing
all
that,
like
you
know,
sounds
great.
You
know
I'm
all
in
favor
of
having
this
uber
goal
that
we're
all
going
towards
and,
however
we
slice
it
as
far
as
implementation,
I
really
don't
care.
The
main
thing
is
that
it's
accruing
towards
a
common
thing,
so
mike
my
concern
with
scorecards
versus
metrics
dashboard
is
that
on
the
surface
to
the
outside
community,
they
look
very
very
similar
and
it
could
be
very
confusing
to
developers
maintainers
trying
to
figure
out,
which
one
am
I
supposed
to
use.
H
Why
would
I
use
this
versus
that,
like
we
might
want
to
just
make
it
clear
that
hey
the
scorecard
thing
is
meant
for
this
very
specific
scenario
and
we're
gonna
be
a
part
of
this
other
dashboard
in
the
future
or
how
whatever
it
ends
up
being.
I
just
think
we
should
be
crisp
about
what
that
overall
vision
is
because
I
did
see
some
comments
on
the
hacker
news
link
that
was
posted
about
future
things
that
they
want
to
do,
and
it
is
verbatim
what
the
metrics
dashboard
is.
H
So
I
can
see
some
confusion
there,
so
I
just
think
we
should
get
very
crisp
about
that.
But
as
far
as
who
does
the
work
and
how
we
slice
it
right,
I
mean
that's
just
that's
implementation
and
that's
great,
but
just
as
long
as
we're
working
towards
the
same
goal.
That's
the
important
part.
A
Okay,
if
there's
nothing
else,
okay,
I
believe
the
floor
is
yours.
E
Okay,
I
saw
a
note
in
the
chat
someone
was
looking
for
a
link
to
the
scorecard
project.
Can
someone
drop
a
link
there
and
then
I
can
go
on
and
share
my
screen
and
we
can
talk
about
requirements.
G
Sorry
I
was
trying
to
go
refresh
my
my
memory
of
the
hacker
news
post,
I'm
not
sure
which
pieces
you're
we're
specifically
specifically
talking
about
ryan.
One
thing
that
we've
called
out
in
here
is
is
being
able
to
surface
this
info
on
somewhere
like
github,
so
I'm
not
sure
what
the
relationship
is
with
the
dashboard
and
the
security
security
overview
page
that's
displayed
on
github,
so
I
I
would
be
curious
to
hear
more
sort
of
about
that
and
how
these
things
can
all
work
together
in
that
capacity
too,.
H
Yeah
I'll
just
give
a
really
quick
overview.
I
don't
want
to
take
too
much
time
from
kay,
but
a
lot
of
things
that
we
talked
about
in
the
past
was
there
sort
of
there's
two
pieces
actually
to
the
identifying
security
threats,
metrics
dashboard
project
god
we
need
a
better
name
and
it
there's
the
ux,
the
actual
dashboard
part,
but
there
was
also
a
second
equal
piece,
which
is
the
api
for
everything.
So
all
the
metrics
that
were
gathered-
and
we
have
yes,
some
intangible
things,
but
also
some
very
automatable.
H
Things
was
the
goal
as
well
so
like
when
you
listed
your
requirements
like
yeah.
Those
are
things
we've
been
talking
about
for
months
as
well,
so
the
idea
was
that
yeah
there'd
be
the
centralized
dashboard,
but
other
projects
could
pull
it
in
as
well
using
the
api,
including
github,
and
we
had
that
conversation
with
maya
and
jamie
as
well
a
few
months
ago
and
something
that
they
were
interested
in.
So
in
that
aspect
it
seems
like
those
goals
are
very
similar,
which
is
not
a
bad
thing.
E
E
Okay,
so
just
a
you
know,
quick
recap:
what
we've
done
previously
is
we.
You
know
we
took
each
of
the
the
three
kind
of
related
projects,
best
practices,
badge
security,
metrics
and
scorecard,
and
we
identified
goals,
scenarios
and
use
cases
and
requirements,
and
then
we
made
a
pass
at
creating
common
goal
scenarios
and
requirements
across
all
three
and
there's
more
work
that
we
could
do
on
this.
We
just
spent
one
meeting
on
it.
I
didn't
want
to
get
too
down
in
the
details
of
it.
E
E
So
then,
for
our
next
discussion,
what
I
thought
we
could
do
is
talk
through
what
our
north
star
is
and
then
once
we
have
a
rough
idea
about
a
north
star,
come
back
and
create
a
road
map,
so
how
we
get
from
where
we
are,
you
know,
working
toward
this
north
star
and
how
all
the
different
pieces
fit
in
so
so
that
was
our
my
plan
for
today
was
to
talk
about
the
north
star.
So
what
what
I
call
the
north
star
was
a
security
metadata
store.
E
You
know,
maybe
we
can
discuss
more
about
what
the
name
of
it
is
right.
Now
it's
like
metrics
dashboard.
E
I
started
to
pick
something
that
didn't
that
was
slightly
different
from
any
one
of
the
existing
three
but
kind
of
rolled
off
free
up
anyway.
So-
and
I
thought
of
this-
you
know
what
I'm
describing
as
a
north
star
is
one
option
for
a
north
star.
Maybe
we
have
different
ones,
but
let's
walk
through
this
one,
and
then
you
know
we
can
see.
Certainly
I'm
not
tied
to
anything
that
was
here.
It
was
just
you
know
my
first
pass
at
trying
to
coalesce
things.
E
So
I
said
in
this
option
we
described
what's
needed
at
an
abstract
level
for
security,
metadata
store
that
meets
the
common
requirements
that
we
defined
earlier
in
the
document,
and
then
what
I
thought
we
could
do
is
identify
both
the
requirements
for
the
overall
system,
the
metadata
store
system
and
then
existing
technologies
that
could
fill
the
requirements.
E
And
so
the
way
I
started
to
break
it
out
is
to
you
know,
into
components
of
an
abstract
model
and
again
we
can
add
or
tweak
these
as
as
people
think.
So
I
think
we
want
a
data
store
and
we'll
talk
about
requirements
for
that
later
and
then
a
data
model
and
exchange
formats
and
an
api
for
putting
data
into
the
store
and
retrieving
data
from
the
store.
E
E
D
Okay,
what
pr
what's
pushing
you
towards
having
to
storing
the
data?
I
mean
if
your
inputs
are
things
like
the
best
practices
badge
and
the
scorecard.
You
can
just
request
that
interactively
I
mean
I.
I
can
believe
that
you
need
a
store,
but
I
just
what's
the
what's
the
data
set,
that's
pushing
you
towards
needing
to
store
it.
E
Good
good
question,
so
so
my
the
scenario
that
I'm
thinking
of-
and
you
know
this
is
me-
sort
of
very
close
to
what
we're
hoping
for
what
we
microsoft
are
hoping
for
from
openssf.
E
So
we
are
looking
for
there
to
be
one
sort
of
one
source
of
data,
one
api
that
we
can
use
to
gather
information
and
make
decisions
about
our
consumption
of
open
source.
E
And
so
you
know
my
my
thought.
Processes
is.
If
there's
one
store
one
api
everybody
feeds
into
that,
then
it's
very
easy
for
us
as
we're
consuming.
H
So
we're
taking
a
pretty
big
step
back
here.
I
think,
compared
to
what
this
working
group
originally
had.
You
know
some
months
ago
and
it's
fine.
I
think
it's
okay,
to
get
some
clarity
here,
given
the
confusion,
but
we
had
in
the
past
there's
a
a
gigantic
spreadsheet
of
a
ton
of
different
metrics
that
this
group
identified
that
we
would
want
to
collect,
and
so
it
was
everything
from
you
know.
Has
a
security
review
been
run
on
this
project?
What
analysis
tools
are
running
regularly?
H
Does
it
have
a
reproducible
build
like
there's
just
a
ton
of
different
things,
so
all
of
those
metrics
would
be
stored
per
project,
so
we
need
some
sort
of
data
store
backend
to
maintain
that.
F
D
Yeah,
if
somebody's
done
a
security
review,
I
can
believe
that
that
you
know
well
that
needs
to
be
stored
somewhere.
Obviously,
it
can't
get
rid
of.
A
Right,
sorry,
I
I
think
I
think
the
other,
like
a
really
super
clear
reason
why
the
physical
data
store
is
so
that
you
can
run
things
across
and
you
can
say
what
are
the
top
10
healthiest
projects
or
top
10
least
healthy
projects
that
have
had
a
vulnerability
in
the
past
year
or
you
know
anything
else
where
you
can't
enumerate
the
universe.
In
order
to
answer
that
query.
D
C
C
E
Okay,
no,
I
I
appreciate
you're
asking
that
question
and
the
same
for
anyone
else.
You
know
please
check
any
assumptions
all
right,
so
I'll
I'll,
stop
there
and
and
see
you
know
just
check
where
people
are
feeling
about.
You
know
one.
The
approach
start
with
north
star
then
look
at
road
map
and
then
also
are
there.
E
You
know,
is
this
idea
of
you
know
a
store
that
has
an
api
that
has
a
presentation
layer
you
know
is
that
what
what
people
are
thinking
are.
We
are
we
on
on
the
same
page
there
and
then
also
are
there
other
components
that
I'm
missing
that
should
be
listed
there.
H
I'd
be
so
hopeless
to
say,
given
the
history
of
this
group,
I
think
we're
all
in
agreement
that
that
is
the
plan.
I
like
that,
we're
writing
it
all
down,
but
I
don't
think
we
should
go
through
an
exercise
of
necessarily
rehashing
it,
but
maybe
make
the
assumption
and
then
and
then
move
from
there,
and
if
people
have
concerns
we
can
revisit
I'd
rather
clarify
maybe
for
the
new
people
rather
than
redecide.
H
D
Certainly
not
with
the
having
a
single
api
to
yank
in
data
from
many
other
places
and
then
be
able
to
present
it
yeah.
I
think
it
might
be
useful
to
at
least
briefly
chat
with
the
chaos
folks,
who
are
also
interested
in
gathering
data
about
open
source.
I
don't
think
that
they've
I
I
my
understanding,
though,
is
that
you
want
to
be
able
to
type
in
like
a
name
of
a
repo
or
a
url
of
a
repo
and
learn
all
about
it.
D
Right
is
that
at
least
one
of
the
use
cases
below
right
so
who
banks
data
into
you
know
how
you
exchange.
Data
between
various
other
systems
may
have
to
be
worked
out
case
by
case,
but
I
mean
certainly
the
desire
to
be
able
to
do.
That
seems
very,
very
small.
E
Sure,
I'm
I'm
just
wondering
if
you,
if
this
you
know
way
of
thinking
about
you,
know
kind
of
what
our
north
star
is,
which
is
that
we're
trying
to
get
to
a
central
store
that
has
data
about
software
projects,
that
people
can
view
and
query
and
external
sources
can
provide
data
into
it.
Is
that
is
that
a
picture
of
a
north
star
make
sense
to
you.
G
D
I
Sorry
so
I
remember
we
discussed
about
adding
adapters
which
will
collect
data
from
different
sources
and
dumping
in
a
single
data
store.
This
was
our
initial
design
during
our
initial
meetings.
If
I
remember
right
so
I
remember
checking
the
scorecard
tool
as
well.
This
the
scorecard
tool
could
be
just
one
of
the
adapters
for
the
matrix
project
right.
Yes,
yes,
right,
okay
and
a
data
store,
I'm
not
that's.
One
part
where
I
got
confused
because
we
are
discussing
should
we
need
a
central
data
store
or
not.
E
No,
I
don't
think
we're
well,
I'm
just
you
know.
I
just
wrote
down
that
we
do
need
a
data
store
so
and
it
sounds
like
we're.
It
sounds
like
now
we're
all
in
agreement
that
we
that
a
data
store
is.
It
is
something
that
we
need.
I
All
right,
because
I
was
wondering
how
else
can
we
do
it
without
a
data
store,
because,
especially
since
we
are
considering
getting
or
gathering
data
from
multiple
sources,
if
we
plan
on
doing
it
on
the
fly,
it
will
just
be
too
slow.
D
Yeah,
well,
I
I
think
that
decision
has
already
been
made,
but
there
are
alternative
designs.
One
is
I'm
going
to
gather
data
from
12
sources.
I
send
out
the
request
to
all
12
sources
simultaneously,
if,
if
it
takes
five
seconds
for
each
one
to
apply,
you
know
the
one
that
the
takes
the
longest.
Maybe
one
of
them
takes
all
five
seconds.
Then
it'll
take
five
seconds
to
get
the
data,
you,
don't
you
don't
request
sequentially,
just
do
it
all
in
parallel
yeah,
but
but
that
doesn't
work.
D
If
there's,
if
there's
a
data
that
you
can't
request
the
data
from
easily
or
if
you
want
to
do
very,
very
large
data
sets.
I
mean
this
is
what
kay
just
wrote
in
the
data
store
allows
researchers
and
consumers
to
run
queries
across
multiple
software
projects.
The
highlight
right
there,
you
know,
if
you
have
to
analyze,
say
I
want
to
analyze
all
open
source
software.
I
Also,
I
think
if
we
start
relying
on
real
time,
I
mean
making
api
calls
in
real
time.
I
think
even
the
resource
consumption
would
become
huge.
Let's
say,
like
you
mentioned,
if
it
takes
five
seconds
for
one
project's
data
and
let's
say
there
are
thousand
users
just
looking
at
the
dashboard
that
will
bog
down
the
system.
D
E
All
right,
so
I
think
then,
let's,
let's
move
on
you
know
at
some
point.
I
think
we
might
want
to
create
a
nice
little
diagram,
but
I
didn't
I
don't
have
that
for
now,
so
so
for
dave
the
store,
I
started
to
write
down
some
requirements,
so
I
think
we
have
some
performance
metrics,
I'm
not
sure
what
those
are,
but
maybe
the
characteristics
we
want
are
that.
A
I
I
A
I
A
Although
I
think
conceptually
we'll,
you
know,
keep
it
as
a
container
and
you
know
run
it
in
a
container,
in
which
case
we
can
deploy
it
anywhere.
Have
it
be
kind
of
well
designed,
so
we
can
put
different
pieces
in
different
places,
but
we
shouldn't
rely
on
any
particular
like
especially
cloud
vendors
sas
level.
A
I
J
E
I
I
so
I
would
like
to
defer
that
until
later,
so
just
for
this
discussion,
let's,
let's
try
to
stay
a
little
higher
level
and
then
we'll
get
to
that.
If
that's,
okay,
okay,
okay,
so
other
requirements,
I
think
we
want
public
read
access
and
we
want
private
right
access,
meaning
echoled
right
access
and
not
not
everyone
can
write
to
it.
E
H
A
Why
why
why
is
immutability?
Is
it
for
auditability
or.
E
Yeah,
so
this
is
coming
to
me
and
we
don't
you
know
we
might
not
need
to
get
stuck
into
this.
We
can
discuss
it
later,
but
this
is
coming
to
me
because
the
work
I've
been
doing
with
software
bill
of
materials
and
for
software
bill
of
materials
we
think
of
a
bill
of
materials
as
something
that
is
it's
created
and
then
it's
immutable.
E
And
if
someone
wants
to
make
changes,
then
they
then
they
create
a
new
record
that
points
to
the
previous
record,
and
so
you
can
still
chain
these
things
together
to
see
versions,
but
you
know,
but
each
change
remains
separate
so
that
you
can
have
that
audibility
and
the
traceability
over
time.
A
So,
since
part
of
this
yeah
we
can,
we
can
have
it
if
you
just
put
a
question
mark
or
like
a
needs,
more
discussion
next
set.
A
Just
we
don't
forget
and
the
reason
for
that
is,
you
know
we
can
collect
a
pretty
large
amount
of
data
about
each
one
and
if
we're
doing
this
on
a
kind
of
continuous
basis,
so
I
won't
see
how
the
project
health
changes
over
time
or
the
contributor
list
changes
over
time,
like
I'm
kind
of
maybe
it's
like
functionally
immutable,
but
like
not
actually
immutable
because
yeah,
it
doesn't
matter,
but
I
I
think
we
we
yeah,
we
can
talk
more
about
it.
Yeah.
D
Yeah
yeah
and
just
to
give
an
example,
maybe
the
stuff
and
the
software
build
materials.
One
of
the
challenges
has
been
the
list
of
the
software
technically
is
fixed,
except
when
you
find
out
that,
in
fact,
this
components
contain
something
else
that
they
didn't
mention
before,
or
it
has
a
publicly
known
vulnerability
now
that
we
didn't
know
about
before,
and
so
things
are
fixed
until
they
aren't,
and
so
it's
hard.
E
Right
yeah,
it's
just
a
different.
I
mean
we
need
the
ability
to
make
changes
over
time.
Just
it's
just
that
in
our
in
our
s
bomb
world.
There's
we've
been
thinking
that
the
way
you
fix
it
is
you
create
a
new
build,
a
new
record
in
your
bill
of
materials
that
has
the
changes
that
links
back
to
the
previous.
So
anyway,
we'll
we'll
discuss
more
later
and
then
I
just
added.
A
E
A
Sorry
for
public
read
access:
do
we
want
to
consider
a
as
a
embargoed
for
for
lack
of
a
better
word,
read
access
to
certain
things,
so,
for
example,
if
we
find
a
a
non-public
vulnerability
in
something
we
being
like,
I
I
now
I'm
talking
me
as
as
microsoft,
not
as
open
ssf.
A
A
E
B
D
E
Cool,
perfect,
okay,
so
let's
so,
let's
put
it
on.
As
with
a
question
mark
thanks
david
for
adding
the
question
okay
and
because
I
would
like
to
try
to
get
through
all
of
these
today
and
we've
got
20
minutes
left
I'll
I'll,
try
to
move
us
a
little
a
little
faster.
So
so
I
identified
a
couple
of
possible
stores
that
we
could
use.
So
I
know
the
best
practices
badge
has
a
store
currently
david's.
Just
writing.
Rdbms.
E
Rdbms
there's
another
project
called
recore,
and
this
is
something
that
luke
heinz
from
red
hat
and
lucas
on.
Our
tac
has
been
working
on,
and
this
is
a
a
store
for
supply
chain
metadata
that
is
uses
the
trillium
trillium
as
the
back
end,
and
it
it
is
julium
is
an
immutable
store.
That's
used
with
an
immutable
data
store,
that's
used
with
currently
the
dns
records,
it
tracks,
changes
to
dns
records
or
that's
how
what
it
was
originally
created
for,
but
it
can
be,
you
know
used
for
other
things.
E
So
that's
one
idea,
there's
a
another
project.
That's
called
the
d-bomb
project
that
is
just
coming
out
of
the
linux
foundation
and
that's
a
store
that
it's
it.
Actually,
it's
an
overall
storage
system
that
allows
storing
things
like
software-built
materials,
hardware,
bills
of
materials,
other
types
of
supply
chain
metadata,
and
it
has
already
an
access
control
model.
E
E
A
In
my
opinion,
the
other
ones
are
interesting
record
and
d-bomb,
but
because
we're
storing
arbitrary
data,
like
I
don't
know
if
we'd
be
fighting
with
them,
to
store
like
arbitrary
things
in
there
and
and
again,
like
postgres,
has
been
around
you
know
since
the
beginning
of
time.
It
works
great.
If,
if
we
need
something
that
it
can't
do,
then
we
should
consider
others,
but
I
feel
like
that
should
be
the
default.
D
I
would
agree,
the
postgres
is
simple:
it
works
for
lots
of
things,
start
there,
but
really
the
correct
way.
Whoops.
The
correct
thing
is:
what
date
are
you
storing?
How
are
you
going
to
access?
It
then
figure
out
the
store,
but
in
my
experience
simply
I'm
a
big
believer
in
simplicity
and
postgres
is
super.
Easy
to
deploy
and
scale
is
great.
D
D
Well,
let's
see
the
last,
we
actually
did
a
count
at
my
previous
organization.
The
number
of
live
active,
open
source
projects.
It
was
in
the
millions
and
I'm
imagining
that
you're
probably
gonna
store.
Maybe
you
know
a
thousand,
you
know
well,
probably
nothing
probably
a
hundred
metric
values,
maybe
or
so
for
each
one.
A
A
Because
it's
because
what
we're
going
to
do
is
we're
going
to
store
like
the
list
of
contributors
and
like
it's
so
expensi.
It
expects
us
to
store
more
more
data
than
you
expect
than
you
can
think
of,
but
not
hundreds
of
megabytes,
so
a
meg,
a
megabyte
per
project.
So
that's
about
a
terabyte
two
terabytes.
D
Big
yawn,
that's
not
going
to
stretch
postgres
at
all.
I
can
run
that
on
my
on
my
laptop.
C
D
The
the
issue
also,
is:
how
structured
do
you
need?
I
mean
a
list
of
contributors,
for
each
project
is
not
a
complex,
it's
not
a
complex
graph.
If
you
actually
needed
to
store,
say
a
an
entire
get
repo
and
but
yet
represented
as
a
graph.
Maybe
a
graph.
D
E
Okay,
let's,
let's,
let's
move
on
because
those
are
you
know,
kind
of
getting
us
to
some
more
implement
implementation
details.
So
so
I
think
we
need
a
data
model,
an
exchange
format
and
an
api,
and
you
know
these
are
how
external
tools
interact
with
the
the
data,
that's
in
the
store.
E
E
Oh
so
elements
that
are
defined
in
the
existing
best
practices,
badge
security,
metrics
and
scorecard
projects,
and
possibly
others.
Let
me
kind
of
jump
through
the
rest
of
this
and
then
we
can
come
back.
So
I
identified
possible
data
models,
so
you
know
we're
working
on
something
in
the
in
the
s-bom.
The
number
of
groups
that
are
working
on
defining
a
standard,
x-bomb
format,
there's
also
an
api
for
the
best
practices
badge,
there's
a
tool
for
storing
or
an
api
for,
storing
supply
chain,
metadata,
graphics.
E
I'm
not
sure
what
recore
has
currently
and-
and
I
I
know
that
the
d-bond
project
has
something
that
I
don't
know
the
details
of
that
right
off.
So
those
are
a
few
items
to
consider
when
somebody
put
apis
in
here.
So
rest
is
an
api
and.
E
All
right
so
thoughts
on
this.
I
don't
know
I'm
interested
again
and
what
was
thought
of
before
for
security
metrics.
Were
we
planning
to
try
to
use
an
existing
api
or
come
up
with
something
separate?
D
D
Yeah
particularly
identify
just
here's
a
few
data
sources
to
start
with.
You
know,
I've
already
talked
with
some
of
you
folks.
We
actually
modified
the
ci
best
practices
badge
to
make
it
easier
to
yank
data
into
this.
So
in
the
case
of
that
of
the
best
practices
happy
to
make
changes
to
make
you
know
extraction
of
whatever
you
need
super
easy
and
just
you
know
the
scorecard
best
practices,
maybe
there's
a
couple.
Other
sources
identify
those
and
make
that
the
starting
point
is
that
kind
of
what
you're
thinking.
H
Yeah
exactly,
I
think,
if
we
start
with
that,
that
that'll
get
us
going
and
then
we
can
easily
show
progress
and
we
can
expand
from
there
right
I
mean
once
we've
got
some
infrastructure
for
a
rest
api
and
we're
working
with
json.
We
can
even
store
that
you
know
on
a
some
sort
of
data
store
very
very
easily.
E
Okay,
let
me
just
check
with
dan
lawrence
or
kim,
if
you
guys
have
any
input
on
this.
A
Yeah,
what
I've
seen
from
chaos
is
that
they
have
the
tools
I
couldn't
find,
and
maybe
I
didn't
look
hard
enough.
The
place
where
I
can
just
go
like
they've
already
collected
it.
For
me,
that
would
be
super
useful.
Having
the
tool
is
now
set
up
infrastructure
to
run
a
private
chaos
instance,
which
we
could
do
we
we
should.
Actually
I
I
will
invite
some
folks
from
chaos
to
the
next
meeting.
Yeah.
D
I
think
they
had.
They
had
talked
about
setting
up
something
a
year
ago
and
I
was
very
excited
and
then
I
hadn't
heard
anything
from
them
since
so
so
maybe
they've
set
one
up,
but
I
fear
they
haven't,
but
I
think
that's
what
people
are
looking
for
and
you
know
what
if
they
haven't
well,
maybe
yeah.
This
will
prod
them
into
something
or
work
together
with
them.
That'd
be
better.
E
You
know.
So
when
we
talk
to
developers
and
to
researchers
and
to
you
know,
corporations
their
github,
our
long-term
story
is
we
we,
you
know,
the
the
metrics
dashboard
is
a
place
that
they
can
come
to
for
a
summary
of
information
across
multiple
data
sources,
and
then
I
think
that
best
practices-
you
know,
let's
see
if
people
are
on
the
same
line
and
then
do
the
roadmap.
D
D
E
H
H
To
make
that
just
a
quick
note
of
that
for
the
the
scorecards
thing,
given
that
it's
like
a
locally
run
thing
currently
just
make
a
note
for
future
like
how
do
we
integrate
those
metrics
per
se?
Will
they
push
to
us?
Will
we
run
a
local
copy
in
our
service
or
something
you
know
how?
How
exactly
will
we
do
that.
D
C
D
I
have
an
idea
on
that
and
I
would
propose
this
as
the
starting
point.
If
somebody
requests
a
project
and
it's
never
been
run
before
locally,
you
know
the
the
site
would
run
a
cop
would
run
the
scorecard
and
cast
the
results,
and
maybe
you
know
after
if
that
last
cash
result
is
has
aged
out,
run
it
again
same
for
the
best
practices
badge
well
best
practice.
Imagine
just
query
online.
It's
I
mean
the
data
is
what
it
is,
but
I
would.
I
would
expect
that
for
some
of
this
you
would
re-run.
D
Occasionally
you
would
you
run
if
you've
not
seen
before
and
rerun
if
it's
too
old.
I
All
these
details
in
this
page,
it's
done
again-
are
we
making
all
these
notes
on
this
particular
page,
which
I
just
sent.
Is
that
a
link?
No
so.
A
There's
a
link
in
the
the
the
meeting
for
today
there's
a
link
to
the
north
star
security
metadata
store.
That
link
is
the.
What
k
is
editing
right
now,
all
right.
I
No,
I
just
asked
for
the
link
where
we
are
making
all
these
notes,
but
in
the
meantime
we
we
just
discussed
how
should
we
run
scorecard
or
similar
tools,
so
I
already
posted
in
our
chat.
I
was
thinking
if
we
decentralized
all
these
data
collectors,
it
might
even
become
easier
or
convenient
for
contributors.
For
example,
let's
say
we
register
an
application,
so
a
user
or
a
developer
can
register
on
our
system.
They
get
an
access
token
and
they
can
run
their
own
data
collectors
and
keep
pushing
to
our
system.
I
So
if
we
have
a
queue
and
handle
I
mean
once
you
push
it
to
the
queue
we
can
sanitize
do
whatever
we
want
in
a
in
synchronous
manner,
so
that
you
won't
be
bogged
down.
I
believe
that
kind
of
decentralized
approach
might
help
us
more
even
for
better
adaptability.
E
Okay,
so
we
have
just
a
couple
minutes
left.
I
I
feel
pretty
good
about
thinking
about
how
these
things
kind
of
map
together
again,
a
diagram
you
know-
might
help
us
in
the
future.
But
how
do
other
folks.
D
E
D
D
E
H
E
We
we
have
just
one
minute
left
thoughts
on
what
our
next
step
should
be.
So
what
should
we
do
in
our
next
meeting?
B
H
Going
to
work
a
little
bit
more
asynchronously
on
this
document,
so
rather
than
going
through
the
dock
like
every
meeting,
which
I
think
is
good
to
review,
but
not
necessarily
filling
it
out
per
se.
If
we
could
encourage
everybody
to
go
in
here
and
maybe
add,
some
notes
add
what
they
think
the
requirements
are
and
then
we
can
have
that
discussion
and
then
we
can
start
iterating
just
a
little
bit
faster.
E
Okay,
so
it
would
be
so
we'll
continue.
You
know,
working
on
requirements
and
and
we'll
ask
people
to
provide
data
ahead
of
time
that
we
can
review.
C
E
A
One
last
quick
thing
in
the
remaining
30
seconds:
we
are
so
as
part
of
oss
gadget,
which
is
the
the
open
source
like
swiss
army
knife
that
we
that
we
have
on
github
and
there's
a
link
to
this
in
the
in
the
meeting
notes
where
we
we
just
started
doing
a
metadata
normalization
tool,
meaning
so
what
this
means
is,
if
you
go
out
and
you
query
nuget
or
npm
or
rubygems,
the
metadata
that
you
get
back
is
is
like
structurally
different
and
sometimes
it
means
different
things.
A
We
are
normal,
we're
going
to
normalize
that
into
one
common
format.
So,
regardless
of
what
ecosystem
you
query,
you
get
back
a
you
know
it's
organized
by
whatever
it
is
like
releases
and
the
releases
have
authors
and
the
authors
are
a
name
and
email
address
things
like
that.
So
we're
going
to
use
that
as
or
I
would
think
we
should
use
that
as
part
of
the
metadata
collector
and
keep
as
much
of
that
kind
of
hard,
like
just
squirrely
logic.
A
Out
of
the
you
know
the
the
dashboard
itself
and
just
delegate
that
off
to
another
tool,
so
we're
that
that's
we're
doing
so.
If
somebody
would
like
to
contribute
to
that
right
now,
we
have
like
a
proof
of
concept
done
for
npm.