►
From YouTube: Package Vulnerability Management & Reporting Collaboration Space Collab Space - 2021-07-16
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
Awesome
well,
everybody.
Thank
you.
So
much
for
coming.
Welcome
to
the
kickoff
meeting
for
the
first
openjs
collab
space
for
package.
I
got
to
get
the
name
correct
because
it's
a
long
one.
We
we
chose
verbosity
over
over
easy
to
say,
package,
vulnerability,
management
and
reporting
collaboration
space.
I
think.
A
Have
an
agenda
yeah:
do
we
have
an
abbreviation
p
v
m
r
c?
S
is
also
probably
a
pretty
tough
abbreviation,
we'll
see
how
it
goes
so.
Well,
since
we're
the
only
collab
space
we
can,
we
can
maybe
just
say
the
the
collab
space
for
now
and
then
once
once
new
ones
get
spun
up,
we'll
we'll
have
to
be
a
bit
more
creative,
excellent.
There
is
a
meeting
agenda
posted
in
the
chat.
It's
pretty
light,
basically
we'll
we'll
just
do
introductions.
A
I
wanted
to
give
us
a
little
bit
of
time
to
make
sure
this
meeting
time
was
going
to
work
for
folks
and
then
we'll
jump
into
the
actual
topic
so
scope.
Some,
I
figure.
A
lot
of
this
time
will
be
brainstorming.
So
you
know,
we've
talked
a
lot
about
what
the
collab
space
means,
but
I
think
we
have
been
trying
to
purposely
leave
the
solutioning
and
the
sort
of
like
actual
initiatives
we're
going
to
take
undertake
until
we
we
got
everybody
together.
A
So
I
wanted
to
give
a
little
bit
of
time
for
that
and
then
lastly,
just
takeaways
next
steps,
because
I
imagine
we'll
have
a
bunch
of
those
from
this:
does
anybody
have
anything
else
they
think
we
should
have
on
the
agenda.
A
Nope,
okay,
excellent!
Well,
then
I'll
start,
so
I'm
wes.
I
work
at
netflix
on
the
node.js
platform
team.
Previously
I
was
on
our
build
team,
which
was
responsible
for
all
of
the
package
open
source
and
internal
library.
Publishing
infrastructure,
which
is
really
when
we
started
talking
about
this
stuff,
was
while
I
was
on
that
team,
and
so
we
had
a
lot
of
the
supply
chain.
Security
domain
for
javascript
fell
under
my
role.
A
A
You
know
michael
approached
darcy
and
I
to
start
this
and
kick
it
off,
and
so
I'm
really
excited.
It's
been
a
bit
of
a
long
road
to
get
to
this
first
meeting,
but
we
had
a
lot
of
details
to
work
out
about
what
it
means
to
be
a
collab
space
and
what
things
need
to
be
done.
But
here
we
are
so
excellent.
I
will
hand
it
off
to
darcy
as
the
the
co-champion,
if
you're,
if
you're
all
right,
dude
you
wanna,
you
said
you
were
in
transit.
C
Take
that
as
a
yes
yeah,
so
my
name
is
chris
clark,
I'm
the
engineering
manager
on
the
cli
working
at
github,
very
interested
in
this
space,
we're
doing
quite
a
bit
of
work
right
now
at
github
and
obviously
within
the
npm
ecosystem,
to
deal
with
mpm
audits
and
basically
cbe
management
in
general
and
kind
of
excited
to
hopefully
have
this
conversation
a
few
levels
up
of
the
tooling
stack
and,
and
ideally
collaborate
with
folks
from
our
security
organizations
across
across
organizations
and
not
just
within
the
two
silos
that
I'm
a
part
of
so
yeah.
C
I'm
super
excited
about
what
we're
gonna
do
here.
I
have
some
updates
from
things
that
we've
been
working
on
internally.
Obviously
recent
news
that
has
come
out
or
recent
news
that
has
put
a
spotlight
back
on
this
topic
as
it
seems
to
happen,
sort
of
yearly
and
yeah
in
terms
of
my
involvement
for
the
last
few
years.
This
has
been
something
that's
being
top
of
mind
for
me.
C
We
haven't
shipped
any
new
tooling
within
the
npm
cli
around
this
for
a
number
of
years,
although
we've
had,
as
west
noted
rfcs
and
proposals
pitch
to
us
at
the
mpm
level
and
we're
definitely
looking
at
you
know
how
we
can
improve
that
in
the
near
term.
So
yeah,
that's
a
good
synopsis.
I
guess
of
what
I'm
involved
in
is
all
involved
with,
and
what
I'm
looking
forward
to
working
with
all
y'all
on
so
yeah.
I
can't
see
who
I
can
pitch
it
to
next,
but
feel
free
to
rest.
B
Sure
robin
ginn
exec,
director
at
openjs,
I
think
I
know
most
of
you
just
want
to
tell
you
all
that
we,
you
know,
think
about
a
collab
space
just
like
we
would
an
open
source
project
like
node
or
node-red
or
anything
else.
So
our
team
is
here
to
support
you.
We
also
have
the
resources
of
the
linux
foundation
behind
us.
So
if
there's
other
security
initiatives,
industry,
people,
corporate
people-
I
can
be
that
bridge
so
can
jory
and
the
rest
of
our.
B
A
Maybe
we'll
let
the
people
who
finish
pick
them
the
next
person
if
they
can
it'll
be
easier
than.
E
Thanks
hi
everyone,
I'm
I'm
also
in
transit.
Can
you
can
you
hear
me?
Okay,
yes,
awesome
all
right
yeah,
so
my
name
is
jamie
sloam,
I'm
the
cto
of
a
company
called
huns.dev.
E
E
I've
come
across
a
few
of
you
in
the
chat
already,
but
really
we
and
myself
specifically,
would
love
to
get
involved
in
sort
of
an
open
source
way
as
well
just
see
how
we
can
help
maintain
and
sort
out.
You
know
this
this
kind
of
big
problem,
that
is,
you,
know,
sort
of
working
through
triaging
vulnerabilities,
giving
maintainers
more
control
over
vulnerabilities
in
their
packages,
not
freaking
everyone
out
when
there
is
a
vulnerability,
and
so
you
know
that's
something.
E
F
Jordan,
everybody
I'm
jordan.
I
work
at
coinbase
where
my
team
I'm
on,
is
called
client
foundations
and
we're
responsible
for
almost
all
things
javascript
in
inside
the
company.
So
I
have.
I
share
a
lot
of
the
challenges
that
west
describes.
I
also
maintain
a
few
hundred
npm
packages,
so
I
get
sort
of
personally
disrupted
every
time.
F
So
I'm
very
excited
to
come
up
with
ways
that
will
avoid
undermining
the
entire
security
ecosystem
while
and
making
things
while
making
things
more
secure
for
everyone.
D
Hey
everyone,
I'm
don.
I
build
things
for
clients
at
uniform,
as
the
case
may
be.
I
end
up
doing
a
lot
of
internal
tooling
stuff
and
dealing
with
ci
stuffs
and
also
because
of
my
time
zone
and
the
team.
I'm
in
I
end
up
being
the
first
in
the
morning,
so
I'm
the
first
responder
to
all
the
red
builds.
D
So
I
get
to
see
some
of
these
vulnerabilities
bubbling
up
and
I
have
a
personal
interest
in
that
as
well,
so
that
it's
actually
useful
and
not
just
a
box
sticking
exercise.
D
That's
me
who's.
Sending
joe.
H
Hey
friends
joseph
here,
I'm
an
open
source
engineer
and
advocate
at
ibm,
and
you
know
I'm
active
in
the
node
space
and
I
am
the
chairperson
of
the
cross
project
council
at
the
openjs
foundation
and
I'm
generally
just
kind
of
interested
in
this
space
and
want
to
be
helpful,
I'll
pass
it
along.
I
guess,
since
I
see
michael
up
there
and
he's
my
buddy
I'll
pass
it
to
michael.
G
I
Yeah
I
just
recently
joined
so
your
next
set.
Thank
you,
okay.
So
I'm
doctor
at
least
that's
my
handle
for
the
open
source
and
internet
stuff
and
at
work.
Everyone
calls
me
pb
because
they
can't
get
further
than
that
in
my
name
just
to
push
the
letters
are
pronounceable
in
english.
I
So
I'm
going
to
react
to
both
anyway,
I'm
here,
because
I
built
npm
audit
resolver
a
while
back
kind
of
like
four
years
ago
and
opened
a
an
rfc
to
npm
to
maybe
pull
some
of
the
functionality
in
and
that
started
some
conversation
that
ended
up
causing
this
group
to
be
set
up.
So
I'm
the
person
who
brings
prior
art
to
the
table
and
hopefully
something
more
than
that
yeah,
let's,
let's
not
get
into
further
details.
So
that'd
be
it.
J
I
didn't,
I
think
I
am
last
to
go.
Thank
you
nodder,
it's
nice
to
meet
you,
hello,
I'm
jory
burson!
I
am
the
community
director
for
the
openjs
foundation
and
my
role
is
to
help
support
all
of
our
37
plus
projects,
and
there
are
many
maintainers
and
tscs,
and
that
sort
of
thing
to
be
able
to
take
advantage
of
all
of
the
resources
that
the
foundation
has.
J
I'm
really
excited
about
this
first
collab
space
because
first
off
it
is
it's
it's
a
like
critical,
I
think
need,
and
second
it's
our
it's
our
first
collab
space,
which
is,
I
think,
going
to
be
a
really
great
opportunity
for
us
to
bring
more
value
to
our
maintainers
and
our
communities.
So
I'm
happy
to
be
here
and
also
don't
forget
to
give
me
your
github
handle.
If
you
want
me
to
add
you
to
our
repo-
and
I
think
that's
it.
Wes
back
to
you.
A
Yeah
awesome,
sorry,
I
turned
off
my
video,
so
you'll
see
the
nice
open,
js
logo
there
a
little
internet
stability,
okay,
so
quick
check
in
on
the
meeting
time,
we
mentioned
a
little
bit
that
it's
late
for
some
of
our
friends
in
europe.
I
was
wondering:
do
we?
I
think
we
have
really
two
options,
so
one
is
do
the
alternating
thing
where
we
do
one
like
around
this
time
and
one
a
bit
earlier.
A
I
know
we
also
questioned
whether
friday
was
going
to
be
good
for
long-term
meeting
scheduling
at
one
point-
and
I
don't
know
if
that
still
holds.
I
think
almost
everybody
who
was
on
the
original
list
was
has
been
able
to
make
it.
A
I
guess
we
have
lauren
who
wasn't
but
he's
even
further
right
he's
in
israel,
so
that
time
zone
here
is
is
pretty
bad,
but
I
think
it
would
be
great
to
get
him
because
the
representation
of
snick,
which
would
be
really
great
so
I
I
my
proposal
would
be
that
we
do
an
alternating
time
and
and
try
to
get
one.
That's
pretty
I'll,
say
early
in
the
morning
for
the
folks
in,
like
the
us
west
coast.
A
Time
like
something
you
know
like
around,
like
8
a.m,
would
probably
be
best
to
be
able
to
to
make
that
happen.
And
again
maybe
we
just
alternate
every
other.
I
think
the
decision
we
had
was
to
to
meet
every
month
again.
We
can
also
that's
up
for
discussion,
but
but
then
so
it
would
be
every
other
month.
We'd
have
a
like
an
8
a.m,
pst
and
and
then
maybe
alternate
to
a
noon.
F
G
I
Well,
I'm
gonna
cross
myself
off
the
list
because
I'm
not
a
good
representation
of
europe,
because
this
time
is
my
favorite
time
for
meetings
across
time
zones.
So
after
my
kid
goes
to
sleep,
I'm
the
most
available
but
yeah,
don't
count
me
in
everyone
else
is
doing
this
as
less
of
a
hobby.
So
you
probably
need
to
check
with
them.
C
So
this
time
for
me
works
right
now
as
long
as
it's
not
happening
like
weekly,
since
the
no
tooling
working
group
actually
has
the
same
time
supply
as
this
bi-weekly,
and
if
you
want
to
do
something
earlier,
I
can
make
myself
available
anytime
earlier
than
this.
Time's
live
pretty
much.
D
I
would
prefer
an
hour,
or
at
least
an
hour
earlier,
because
this
is
roughly
the
time
when
my
kids
do
go
to
sleep
so
happy
to
be
there,
but
other
than
that.
If
it's
not
a
friday,
it's
probably
easier.
A
Okay,
so
it
sounds
like
what
we
should
do
is
a
new
doodle,
but
with
this
in
mind-
and
I
would
like
to
get
lauren
because
he
he
said
he
would
like
to
come,
it's
you
know
again.
I
think
it's
just
a
time
problem
like
every
every
meeting
we
scheduled
to
get
this
set
up
and
planned
has
been
midnight
for
him.
B
G
B
F
F
So
it's
not
really
my
choice
as
long
as
it's
a
morning
that
I
don't
have
child
like
that,
I'm
not
the
child
care
and
I
also
don't
have
a
meeting
conflict.
Then
that
should
be
fine.
A
Yeah,
I
think,
we're
all
on
the
same
boat
on
that.
Okay,
so
we'll
we'll
take
it
back
to
the
drawing
board,
probably
open
up
an
issue
in
the
repo
with
a
doodle,
preferably
non-friday,
preferably
a
little
bit
earlier,
but
we'll
open
up.
A
You
know
a
bunch
of
time
slots
trying
to
find
non-competing
meeting
slots
so
excellent,
okay
moving
on
so
this,
I
think,
is
the
probably
the
most
important
thing
for
us
to
do
today
and
that
is
really
nail
down
what
we
think
the
scope
of
the
group
is
so
we've
had
some
discussions
and
went
back
and
forth.
A
So
I
I
know
at
one
point
when
we
were
first
discussing
this,
we
were
thinking
that
we'd
focus
really
tightly
on
the
javascript
ecosystem
and
there's
a
lot
of
benefits
to
that,
the
main
one
being
that
it
gives
us
a
clear
problem
space
and
we
have
just
known
players
and
known
tooling
when
we
shopped
that
idea
around
a
little
bit.
I
do
remember
getting
some
feedback
specifically.
I
remember
miles
boring's
giving
this
feedback.
I
think
we
got
it
from
a
few.
A
People,
though,
is
that
this
is
not
a
problem
unique
to
the
javascript
ecosystem,
some
of
the
key
players
in
this
you
know,
and
he
was
representing
github's
view
at
the
time
handle
you
know
it's
polyglot,
like
they're,
not
just
focused
on
the
javascript
ecosystem,
so
finding
solutions
that
might
work
beyond
just
our
scope
would
have
some
value.
A
You
know
the
trade-off.
There
is.
If
we
try
to
bite
off
too
much.
You
know
we'll
we'll
drown,
trying
to
make
something
that
works
for
everybody
so
anyway.
A
So
I
wanted
to
open
up
the
floor
and
and
sort
of
feel
out
people's
opinions
on
whether
you
know
we
think
really
tightly
scoping
to
javascript
is
the
best
approach
or
if
there's
you
know
some
level
of
abstraction
or
maybe
it's,
maybe
it's
really
inclusion
that
we
would
want
to
get
from
people
outside
of
the
javascript
ecosystem,
like
obviously,
security
companies
are
really
important
here
but,
like
maybe
there's
some
other
groups
that
we
should
be
reaching
out
to
to
bring
in.
F
I
mean,
while
I
think
I
think
whatever
we
do,
will
be
much
much
more
quickly
adopted
if
it
is
beyond
just
javascript
right
like
if
we
come
and
say
the
whole
javascript
ecosystem
would,
like
all
the
big
players
really
want
this
change,
then
people
will
do
that
for
the
javascript
ecosystem
but
like,
if
maybe
but
if
we
come
and
say
like
across
languages
and
across
ecosystems
like
with
it.
You
know
all
the
major
players
are
saying.
F
This
is
a
good
thing,
then,
like
it's
kind
of
table
stakes
for
everyone
else,
but
I
think
it's
useful
to
acknowledge
that
the
javascript
ecosystem
has
both
a
philosophy
of
lots
of
dependencies
and
also
the
largest
dependency
pool
to
pull
from
like
period.
So
we
are
likely
to
both
see
these
problems
more
often
and
also
have
the
most
context
for
how
to
fix
them.
G
You
know,
then
it's
worth
testing
it
against
some
other
some
other
ecosystems
to
see
like
would
this
apply,
but
I
think
if
we
try
and
think
of
everything
to
start
we're
going
to
have
we're
going
to
spend
too
much
time
like
researching
and
learning
and
understanding
versus
saying,
okay,
we
understand
the
people
here
understand
the
javascript
ecosystem.
G
Let's
come
up
with
something
we
think
is
a
way
for
a
potential
way
forward
and
then,
based
on
that,
you
know
consider
whether
it
applies
to
others
versus
the
other
way,
or
you
know
trying
to
understand
something
and
pitch
something
from
the
very
beginning.
So
I
guess
I'm
advocating
for
like.
Let's
keep
the
scope
a
little
bit
smaller
to
start
with
the
we
know,
we
should
revisit
that
at
some
point.
Once
we
make.
I
Guess
I
can,
if
we
make
it
work
for
if
we
make
it
work
for
the
javascript
ecosystem
because
of
like
okay,
I'm
gonna
repeat
this,
but
because
javascript
ecosystem
has
this
the
biggest
scope
of
the
problem
and
there's
so
many
dependencies
and
the
dependency
tree
is
so
long.
This
is
specifically
why,
if
it
works
for
javascript,
it's
likely
to
work
for
everyone
else,
but
not
every
other
ecosystem
is
going
to
feel
the
need
to
take
part
in
figuring
it
out
yet
because
they're
not
hit
as
hard.
I
So
I
think
we're
in
a
position
to
figure
it
out
for
javascript
and
keep
it
in
the
back
of
our
heads
that
we
don't
want
to
build
something.
That's
too
specific,
so
it
eliminates
some
languages
out
of
the
box,
but
we,
I
don't
think
it's
realistic
to
assume
we're
going
to
be
able
to
bring
in
people
from
other
languages
to
the
table
with
figuring
it
out,
because
it's
it's
difficult
to
organize
already.
C
So
I
guess
I
can
speak
to
as
being
somebody
that
I
feel
like
is
in
the
camp
working
at
github
managing,
obviously
the
npm
apply
and
then
also
being
a
part
of
this
cloud
space
we're
having
internally.
I
can.
I
can
speak
to
this
a
little
bit,
but
we're
talking
with
the
defendable
team.
We've
been
talking
with
our
security
team
and
obviously
you
know
within
the
mpm
camp
itself,
within
github,
we've
been
having
conversations
about
how
we
improve
this.
C
C
The
information
that
we
would
want
to
see
for
potentially
some
sort
of
meta
information
or
meta
data
around
cvs,
and
we
can
do
that
in
tandem
with
any
other
work.
That
would
be
done.
That
would
be
more
broad
to
all
ecosystems
at
large,
especially
when
you
consider
like
the
the
tooling
that
dependable
has
implemented,
at
least
at
github.
C
C
This
is
still
sort
of
javascript
and
node
focused
for
us,
but
we
would
probably
transform
like
some
sort
of
stream
of
information
and
whatever
that,
like
service
looks
like
in
the
future
like
we,
we
don't
quite
know
yet,
but
we're
the
ideas
that
we
sort
of
propose
right
now.
What
information
we
would
like
to
see.
That
would
be
helpful.
That
would
help
produce
noise
that
could
help
make
better
tools
to
again
to
make
this
situation
better
for
everybody.
C
So
I
guess
that's
a
little
bit
of
insight
a
little
bit
of
an
update
on
how
we're
thinking
about
this
and
sort
of
the
next
steps
that
my
team's
going
to
be
taking
is
at
least
trying
to
you
know,
take
some
of
the
work.
You
know
that,
obviously
tp's
done
and
other
folks
have
done
and
propose
some
sort
of
schema,
at
least
for
let's
say
like
some
sort
of
like
meta
information
that
maintainers
could
potentially
be
providing,
whether
that's
considered
to
be
like
a
counter
claim
or
whatever.
C
That
is
that
we
could
then
have
served
to
us
similar
to
the
advisory
dv
service
that
we
have
today
have
some
sort
of,
alongside
that.
Some
sort
of
information
that
you
know
gives
us
more
more
understanding
about
the
cv
itself
and
the
package
and
packages
that
potentially
are
or
aren't
vulnerable
to
it,
based
on
maintainers,
providing
sort
of
feedback.
So
yeah.
C
Yeah,
I
was
just
gonna
say:
that's,
that's
some
really
tangible
actionable
and
I
feel
like
I
apologize
if
it's
jumping
to
solutioning,
but
we've
been
like
ideating
around
this
area
for
a
while
and
and
we're
sort
of
getting
to
a
place
where
we
really
want
to
do
something
quickly,
and
so
just
say
that
we're
this
is
expediated
in
internally,
at
least
in
terms
of
prioritization
of
work.
We
want
to
focus
on.
I
mean
it.
A
Can
I
just
I'm
just
going
to
redirect
this
just
for
saying
let's
I
want
to
have
that
conversation,
but
I
I
it's
technically
in
the
agenda
a
little
bit
later
and
I
want
to
make
sure
we
nail
down
before
we
we
go
too
far.
So
so
what
I
was
gonna
say
is,
I
think,
what
you
said:
darcy,
which
is
really
important,
is
you
all,
are
ready
to
start
working
on
some
stuff,
and
I
think
we
as
a
group
need
to.
A
A
A
I
say
that
there's
the
tooling
side,
which
is
you
know
what
darcy
you
are
talking
about,
but
then
there's
the
where
some
of
this
information
is
being
discovered,
registered
the
advisory
db,
those
things
and
I
think,
making
sure
that
we
collaborate
there
is
is
really
like
what
the
heart
of
what
I
think
this
group
can
help
achieve.
A
So
I'm
wondering
if
maybe
a
way
we
could
set
the
scope
properly
and
then
bring
in
the
people
who
who
are
going
to
work
on
the
more
concrete
parts
like
what
you
mentioned
would
be.
Maybe
if
we
had
like
set
up
non-recurring
meetings,
but
a
meeting
where,
like
your
team,
could
come
and
present
the
work
that
you're
doing
and
the
direction
you'd
like
to
go,
and
we
could
do
the
same
thing
with
some
of
these
other
teams
that
are
that
are
really
important
in
the
ecosystem.
A
Again,
like
some
of
the
security,
you
know,
companies,
I'm
sure
you
know
we
would
probably
want.
A
Maybe
some
maintainers
of
things
that
have
been
particularly
hard
hit
by
you
know:
maintenance
involving
you
know,
cve
updates
like
something
like
some
structure
like
that,
where
we
can
get
those
teams
and
be
aware
of
the
work
they're
doing
collaborate
on
it,
give
feedback,
but
not
necessarily
have
it
be
like
it
doesn't,
need
to
be
owned
by
this
group
or
the
foundation
right,
because
the
goal
here
is
just
to
foster
the
collaboration,
not
necessarily
for
us
to
you
know
not
definitely
not
for
us
to
be
the
only
place.
These
innovations
are
happening.
A
What
do
you
all
think
about
something
like
that,
so
that
so
that
when
we
come
with
those
solutions
like
darcy
and
jordan,
we're
hoping
to
jump
into?
We
know
what
different
teams
are
working
on
and
what
different
directions
they're
going.
Do
people.
G
A
Well,
yeah,
that's
kind
of
what
I
was
thinking
is
if
we
focus
really
on
certain
aspects
of
it,
but
we,
but
those
aspects,
have
important
parallels
or
maybe
like
touch
points
with
some
of
the
work
that
like
github,
is
going
to
be
doing
having
it
would
be
very
tough
for
so
I
think
it
will
be
unsuccessful.
Actually,
let
me
say
this
flat
out.
A
I
think
it
will
be
very
unsuccessful
if
we
push
forward
for
say
a
spec
on
a
schema
and
then
the
people
who
are
probably
the
the
closest
to
that
today
at
github
right
who
have
that
on
their
probably
quarterly
plans
or
something
to
work
on,
go
in
a
different
direction.
Like
I'm
thinking
sort
of
like
how
we,
with
the
support
spec,
we
did
a
lot
of
work
in
the
package,
maintenance
working
group
to
try
to
get
a
robust
specification
and
I
think
it
it
unfortunately
did
not.
A
We
took
it
to
npm
too
late
right
and
like
the
goal,
is
to
get
npm
on
board
and
then
like
it
was.
We
already
had
this
big
fleshed
out.
You
know
spec,
and
I
see
the
same
risk
in
this
group.
Is
if
we
don't
go
and
understand
the
work
that
darcy
wants
to
do
on
that,
or
maybe
you
know,
maybe
sneak
already-
has
something
implemented
and
rolled
out
to
their
customers.
That
does
something
similar
to
this
like
we
need
to.
A
We
need
to
know,
because
if
we
can't
get
those
people
to
adopt
the
output
of
our
work,
it's
not
going
to
go
anywhere
right.
So
that's
I'm
trying
to
think
of
a
way
that
we
can
better
collaborate
with
those
key
stakeholders
to
make
sure
that
the
scope
that
we're
doing
is
not
like
overlapping
and
divergent
from.
You
know
the
work
that
there
were.
G
I
guess
I
was
just
thinking
if
we
just
if
we
just
said
our
you
know
our
scope
is
going
to
be.
You
know
our
we're
going
to
come
up
with
something
we
think
works
in
the
javascript
ecosystem
and
then
tests
as
others
and
that's
kind
of
the
scope,
then
moving
on
to
brainstorming
with,
like
you
know,
I
fully
agree
with
what
you're
saying
like
we
need
npm
and
we
need
stick
and
that's
why
we've
you
know
darcy
is
one
of
the
co-chairs
here
and
we've
got
lorann.
G
So
I
I
guess
I
don't
want
to
I'm
just
thinking.
Do
we
really
need
to
spend
a
ton
of
time
on
scope
versus
getting
into
the
brainstorming
the
ideas,
with
the
caveat
that,
of
course
it
needs
to
include
you
know
the
what's
already
on
the
table
for
npm
and
snick
and
the
other
people
in
the
ecosystem
who
will
actually
have
to
implement
it.
I
Yeah,
I
definitely
agree.
I
wanted
to
add
one
more
thing
to
this.
I
I'm
not
sure
if
this
is,
if
it's
just
me,
but
I
think
the
conversation
is
kind
of
going
towards
us
having
to
decide
if
we
want
to
host
the
spec
for
whatever
we're
gonna
come
up
with,
and
if
so,
I
strongly
believe
we
need
to
start
as
soon
as
possible,
so
I
can
donate
the
json
schema
that
I
have
in
npm
mode.
I
It
reads
over
as
a
starting
point
and
I'm
not
going
to
be
upset
if
it
ends
up
being
completely
different
and
I'm
the
only
owner
of
this,
so
it
kind
of
makes
it
easy
in
terms
of
copyright.
I
G
That
sounds
like
a
good
idea
to
me
to
get
like
something
concrete,
that
people
can
poke
holes
at
and,
like
you
said
like
it
may
end
up
being
totally
different,
but
having
something
to
talk
about
is
a
good
and
I
don't
know
you
know.
Darcy
mentioned
that.
There's
been
some
thoughts.
If
there
was
something
that
darcy
could
you
know
pr
in?
We
could
even
have
a
few
which
we
would
iterate
on
and
hopefully
get
to
something
in
the
end
right,
yeah.
C
C
Is
there
existing
tooling
so
like
like
my
head,
and
I
feel
like
a
lot
of
us,
are
our
heads
point
to
the
existing
mdm
audit
or
our
the
npm
advisory
duty
is
sort
of
the
source
of
the
pain
points
for
most
of
node
and
javascript
developers
right
now,
like
that's
what
we're
trying
to
solve
for
so
that's
kind
of
I'd,
rather
just
make
sure
that
we
get
that
written
out
explicitly
that
you
know
it's
at
the
mpm
cli
or
crn,
or
it's
what
like,
what
tools
need
to
be
involved
in
adopting
something
as
well
once
we
figure
out
what
that
is
like
what,
where,
where
are
cvs
being
made
visible
and
what
tools
are
making
them
visible
today
in
javascript
developers
workflows,
I
feel
like
that
would
be
a
more
inclusive
approach
versus
working
backwards
from
like
solution
and
who's
actually
going
to
implement
something
right
like
maybe
we
take
a
step
back
tried
to
essentially
scan
like
and
get
a
whole
bunch
of
different
use
cases
of
how
people
are
experiencing,
let's
say,
cvs
and
where
they
are
visible
to
them,
outline
what
those
are
and
where
those
touch
points
are.
C
I
Yeah
we
can
assume
npm
registry
is
the
building
block
of
the
ecosystem.
I
I'm
not
sure
if
we
can
assume
npm,
tooling
and
the
database
of
vulnerabilities
is,
is
the
only
platform,
so
snake
has
their
own
repository
of
cves
and
advisories
and
everything.
I
So
what
we're
gonna
create
here
probably
needs
to
be
independent
of
anything
other
than
the
registry
itself,
the
the
package
ecosystem,
so
it
it
should
not
be
built
as
something
that
goes
into
the
the
vulnerability
database,
any
specific
one,
but
something
that
could
be
a
thing
facilitating
adoption
anywhere.
I
So
in
this
case,
trying
to
solutionize
here
to
to
give
a
better
example.
If
we
want
people
to
be
able
to
declare
what
vulnerabilities
can
be
ignored,
we
get
a
format
in
place
and
we
let
package
maintainers
and
package
users
use
that
format
to
declare
and
then
let
them
share
it
and
sharing
could
be
done
anywhere.
But
one
of
the
ways
you
could
share
is
publish
yours
as
a
package
maintainer
alongside
your
package.
I
So
that's
that's
possible,
but
then
snake
could
have
their
own
method
of
sharing
that
to
be
used
internally
by
their
customers
might
as
well.
So
I
think
we
need
to
be
careful,
sorry,
drc
not
to
make
it
to
npm
cli,
specific
and
npm
audit
specific.
C
Totally
that's
kind
of
what
I
was
getting
at
and
I
think
that's
actually
one
of
the
mandates
in
the
original
proposal
we
had
the
outcome
of
this
work
should
be
delineating.
Let's
say
the
existing
sources
of
truth.
C
The
existing
actors
within
the
pipeline
and
like
what
we
could
potentially
propose
is
new
models
that
abstract
models
of
how
you
know
these
things
are
communicating
together
and
how
to
like,
make
that
more
efficient
and
potentially
schemas
of
information,
and
that
can,
you
know,
be
implemented
by
who
whomever
is
at
whatever
part
in
that
whole
process
and
flow.
C
But
I
feel
like
we're
not
if
we
don't
document
that
first
and
we
don't
take
a
step
back
and
actually
like,
say:
okay,
we're
who
is
providing,
let's
say,
cve
information
and
then
what's
their
existing
sort
of
like
format
to
having
consumers
discover
that
information.
How
do
audits
happen
right
now?
Then?
If
we
don't
do
that
kind
of
like
documentation
process,
then
I
feel
like
we're.
You
know
yeah
we're
just
going
to
optimize
for
only
one
workflow
and
not
you
know,
really
cover
a
large
enough
swath
of
the
ecosystem
and
yeah.
G
Yeah,
I
I
like
certainly
I
know
we,
you
know,
there's
the
the
mpm
snick
are
two
tools:
there's
also
like
container
standards
scanners
out
there
that
often
use
like
the
os
np.
You
know
in
the
case
of
red
hat
rpm
information
and
like
an
index
that
says
this,
rpm
has
this
version
and
therefore
it
has
you
know.
So
those
are
the
three
that
I'm
most
aware
of.
I'm
not
sure
if
there's
others.
C
Yeah
so
just
like,
if
we
can
get
a
document
going
like
and
and
categorizing
those
players
and
then
even
like
creating
wireframes
or
whatever
it
is
architectural
diagrams
and
how
they
communicate
with
their
like
the
people
that
consume
that
information.
Through
what
tools
then
we're
going
to
get
a
better.
I
think
visual
on
on
where
it
is
that
we
can
improve
the
process
or
where
we
can
maybe
even
kind
of
standardize
across
the
ecosystem,
so
that
we
can
have
the
biggest
impact
with
the
work
that
we're
doing
here.
So.
F
I
think
this
challenge
is
that
the
top
of
the
pyramid
or
the
source
of
truth
or
the
you
know,
whatever
the
source
of
the
river-
I
don't
know
what
metaphor
works
here,
is
like
the
cve
database,
and
unless
we
have
them
willing
to
make
changes,
then
we
are
going
to
have
to
see
what
the
where
the
closest
layer
is
that
we
can
make
changes
in,
because
if
we
focus
only
on
making
npm
audit
and
github
depend
about
and
sneaks
like
tools
better,
then
any
additional
tools
or
other
ecosystems
aren't
going
to
benefit
from
those
improvements
and
like
the
a
solution
we
come
up
with
here.
F
A
What
it's
worth,
though,
I
think
we
need
to
go.
We
need
to
go
even
a
step
further.
You
talk
about
the
database,
but
this
this
doesn't
that's
not
the
source.
The
database
is
the
security
researchers,
finding
the
vulnerabilities
and
reporting
them.
So
I
think
really
what
we
want
to
do,
and
I
think
I
love
the
idea
of
trying
to
come
up
with
some
sort
of
reference
material
that
we
can
show
people
when
we're
talking
about
these
changes.
That
goes
from
start
to
finish.
A
Maybe,
like
you
said
wireframes,
you
know,
whatever
structure
makes
the
most
sense
there
and
and
really
point
out
where
we
see
the
the
areas
of
improvement
are
and-
and
I
think
it
should
start
all
the
way
from
how
our
security
researchers
finding
vulnerabilities
in
packages
you
know
are
there
things
that
you
know
steps
that
they
should
be
taking
that
they're.
A
You
know
beyond
just
the
ones
that
generally
are
considered
best
practice
for
security,
vulnerability
reporting,
but
are
there
things
that
would
help
maintainers
would
help
end
consumers
be
more
security
minded
and
conscientious
about
that,
and
in
order
to
have
that
discussion,
I
think
we
need
to
also
be
making
sure
we
bring
those
people
in,
even
if
even
if
we
can't
quote
unquote
make
changes
there
like
in
the
end.
Of
course,
we
want
to
find
the
areas
of
leverage
where
we
make
the
changes,
but
we
need
to.
A
We
need
to
understand
what
is
happening
in
the
process
for
those
people
who
are
reporting
those
things
and
is
there
extra,
maybe
there's
extra
metadata
that
they
would
love
to
provide,
but,
like
the
database
doesn't
accept
it
or
maybe
they
wouldn't
mind
going
in
after
the
cve
gets
added
to
the
database
and
coming
to
github,
you
know
and
adding
some
extra
metadata
in
some
github
ui
or
npm
ui
like
there's
a
bunch
of
solutions
we
could
take
where
bringing
those
folks
to
the
table,
I
think,
could
really
be
a
game
changer
and
it's
not
just
you
know
these
organizations
that
run
the
the
databases
involved
here.
F
F
I
think
what
they
will
do,
though,
is
validate
our
many
of
our
existing
intuitions,
because
I
think
I
I
suspect
I
have
no
evidence
to
back
it
up,
but
I
suspect
that
I
can
already
answer
those
questions
like
I
that
I
already
roughly
know
what
they're
going
to
say
those
security,
researchers
and
so
on,
and
I
think
that
that
my
that
we
absolutely
still
need
to
validate
all
that
right,
like
even
if
all
of
us
were
just
as
confident
as
I
am
about
that
stuff
like
we
should
still
validate
it.
F
But
the
my
suspicion
is
that
if
I'm
correct
that
the
issue
is
that
researchers
are
incentivized
to
have
the
most
impact,
the
most
the
broadest
reach
possible
with
their
reports,
they
want
to
find
the
the
biggest
security
problems
that
hit
the
most
people
you
know
and
whether
their
motivation
is
altruistic
to
make
things
more
secure
or
financial
to
get
the
biggest
bounty
or
a
combination
of
those
or
others
like.
That's
still
the
incentive,
and
so
the
the
way
I
s.
F
G
It's
not
that
the
cve
itself
needs
more
information,
because
it's
not
the
cv,
that's
causing
the
problem.
The
problem
is:
is
that
we're
transitive
like
we're
basically
pushing
that
cve
information
from
a
a
dependency
up
through
the
chain
and
as
we
push
it
up
through
the
chain,
that's
where
it
becomes
less
and
less
relevant,
so
the
original
cv
being
reported
may
be
perfectly
valid,
but
because
of
that
chain,
we're
we're
creating
all
sorts
of
false
positives
and
and
that's
where
it
does
get
a
little
bit
more
specific
to
like
our
ecosystem.
G
A
On
we
only
have
five
minutes
left,
so
I'm
just
gonna,
I'm
gonna,
let's,
let's
wrap
this
up,
but
I
wanted
to
add
one
quick
caveat
to
to
that
is
the
cbe
could
have
things
there
are
special
domain
specific
languages
for
describing
how
you
can
test
if
something
is
vulnerable,
there's
specific
things
that
we
could
start
promoting
to
help
flush
out
those
cves
with
more
metadata.
That
would
make
it
easier
for
us
to
validate
against
the
deep
dependency
tree,
whether
it
actually
got
bubbled
up
so
like
these
are
the
kind
of
things
where
yes,
I
agree.
A
We
need
to
focus,
and
this
is
why
I
wanted
scope
and
it
took
our
whole
meeting
to
be
the
number
one
thing
but
like
just
just
to
be
aware,
we
we
need
to
think
that,
broadly
and-
and
I
didn't
even
know
about
some
of
these
things
until
I
started
talking
to
the
security
partners
at
netflix
like
we
are-
we,
this
group
is
90
as
well.
A
There's
nine
of
us
and
jamie,
I
think,
is
the
only
one
who
really
sits
outside
of
the
tooling
and
javascript
ecosystem,
and
maybe
you
consider
yourself
tooling
too,
and
we
haven't
really
even
heard
from
jamie
today.
So
I
just
want
to
make
sure
we're
really
good
about
including
the
right
voices
in
this,
because
we
can
come
and
solutionize
all
we
want,
but
without
having
somebody
like.
A
So
I
interviewed
julia
to
do
the
presentation
she's
a
security
partner
on
netflix,
and
I
a
lot
of
this
got
cut
because
we
didn't
want
to
include
a
lot
of
things
about
solutions
in
the
talk.
But
she
brought
up
like
five
or
six
different
great
ideas
for
how
she's
worked
with
security
researchers
to
help
get
more
metadata
into
netflix
when
they
report
something
to
a
bug,
bounty
and
like
we
don't
have
those
voices
in
these
conversations.
A
Typically,
because
we've
been
so
narrowly
focused
in
the
javascript
tooling
space
that
I
think
we
need
to
make
sure
we.
We
are
regularly
battling
against
our
our
urge
to
think
we
have
the
right
answer
and
and
going
out
to
to
those
people.
So
zb
I'll
call
on
you.
But
then
we
need
to
move
on
right
after
you,
two
takeaways
and
next
steps.
I
So,
just
a
quick
observation:
we're
still
focusing
on
trying
to
find
one
solution.
Meanwhile,
I
think
it's
going
to
be
perfectly
okay
to
start
somewhere
downstream,
with
the
solutions
that
we
have
ideas
how
to
build,
and
we
understand
well
and
then
start
pushing
upstream.
I
So
we
want
to
break
the
chain
of
the
cve
coming
down
and
disturbing
people,
even
though
it's
not
relevant
anymore,
I
think
so
so
my
tool
does
it
at
the
consumer
level,
we
can
bring
it
up
to
the
package
maintainer
level
and
we
can
start
going
up
the
stream
until
we
find
a
way
to
reach
the
security
researchers
themselves,
adding
layers
and
layers
of
new
ideas
to
how
to
you
know,
move
this.
I
This
whole
thing
upstream
and
create
less
noise,
so
I
think
it's
perfectly
fine
to
start
with
what
we
find
familiar
and
figure
out
the
way
to
push
it
up.
That's
what
I
wanted
to
add
here.
A
Excellent,
I
I
agree,
so
I
think
we've
had
a
lot
of
great
discussion.
This
sets,
I
think,
a
good
foundation
for
us
all
to
sort
of
better
understand
what
we're
trying
to
do
here.
I
think
we
really,
though,
do
need
to
get
to
what
are
our
next
steps,
so
it
sounds
like
we
should
probably
start
opening
issues
in
the
repo
with
specific
ideas
that
we
talked
about
today.
So
we
have
documenting
the
process.
A
We
have
a
schema
for
sharing
metadata
about
vulnerability
applicability.
That
could
be
like
the
maintainers
counter
claim
stuff
like
that.
G
A
Right,
maybe
even
pr
in
the
json
schema
would
be
a
good.
A
To
start
with,
or.
G
I
Yeah,
so
I'm
gonna,
I'm
gonna
ask
some
questions
asynchronously,
because
I
have
some
minor
tooling
around
the
schema,
because
it's
the
second
version
and
I
have
a
migration
tool-
that's
kind
of
embedded
around
it
and
validation,
but
yeah.
Let's,
let's
do
that
offline.
A
Okay
and
then
did
we,
I
don't
think
we
had
any
other
clear
to
do
items
from
this.
G
Discussion,
I'd
ask
darcy.
He
mentioned
that
you
know
they've
been
they've
been
thinking.
Is
there
something
that
you
can
share
on
that
front?
Darcy
either,
like
you
know,
share
it
through
text
issues,
or
you
know
present
as
like.
You
know,
set
up
a
time
for
you
to
do
that.
Does
that
make
any
sense.
C
Yeah
there's
some
stuff
I
can
and
can't
share.
So
that's
so
I'll
have
to
figure
out
what
that
is,
but,
like
I
said
before,
we
are
probably
gonna
have
some
asynchronous
work
done
in
terms
of
rc
created,
at
least
within
the
next
week
or
two
around
this
kind
of
same
kind
of
stuff.
C
So
I
think,
there's
going
to
be
I'll
have
to
figure
out
how
we
can
best
make
sure
that
we're
not
duplicating
efforts
and
so
that
it
feels
like
a
whole
like
holistic
sort
of
approach
to
solving
this
problem,
and
everybody
here
is
involved
in
whatever
we
start
proposing
within
the
mpm
cli.
G
A
And
then
one
other
thing
that
I'm
I'll
open
an
issue
for
is
outreach,
so
I
think
one
again
again
going
in
the
topic
of
what
I
was
saying.
I
think
we're
missing
some
voices.
We
need
to
bring
those
voices
in.
We
need
to
hear
from
them.
I
think
we
need
some
security
researchers
who
have
been,
preferably
if
we
can
find
some
that
have
been
prolific
in
the
node.js
ecosystem
to
discuss
their
process.
A
I
think
we
need
maybe
some
folks
from
that.
This
focus
on
the
security
side
from
some
companies
like,
I
might
be
able
to
tap
some
of
the
folks
at
netflix.
If
we
could
maybe
get
some
of
the
security
team
members
from
github,
that
would
be
great
anybody
else
who
who
we
think
would
have
a
good.
You
know
viewpoint
to
share
on
how
this
process
is
working
for
them
and
what
areas
of
improvement
they
you
know
concede.
I
think
that
would
be
like
another
really
good
initial
step.
A
A
Okay,
well
thanks
everybody.
I
think
this
was
really
productive
and
we
had
a
great
conversation
and
to
be
honest,
our
month,
cadence
after
seeing
how
this
conversation
went,
might
be
too
sparse,
because
we
had
a
lot
to
talk
about,
and
I
think
I
think.
A
Yeah,
I
think
that
makes
sense.
Okay,
so
as
part
of
the
scheduling
for
the
next
meeting,
we'll
we'll
consider
trying
to
get
a
bi-weekly,
maybe
for
the
for
the
first
little
bit,
and
then
we
can
slow
it
down
as
necessary.
So
excellent.
Well,
thanks
everybody
for
coming
and
we'll
see
you
in
github.
Thank.