►
From YouTube: Package Vulnerability Management & Reporting Collaboration Space for... - Darcy Clarke & Wes Todd
Description
Package Vulnerability Management and Reporting Collaboration Space for OpenJS World - Darcy Clarke, Github & Wes Todd, Netflix
B
A
B
Yeah,
so
we
were
hoping
to
kick
out
things
off
by
talking
a
little
bit
about
the
state
of
the
ecosystem
and
why
this
all
sort
of
came
out
of
and
sort
of,
spun
out
of
the
package
maintenance
working
group.
Actually
so
there's
been
some
recent
data
come
out
about
sort
of
the
state
of
the
ecosystem
in
2020.
What
we
continue
to
see
in
the
javascript
ecosystem
is
exponential
growth.
There's
one
point
over
1.6
million
packages
on
the
mpm
public
registry,
which
is
incredible.
B
B
B
Typescript
has
recently
jumped
a
few
spots
in
terms
of
a
top
language
that
we
are
seeing
in
the
repositories
that
live
on
github,
and
this
just
tells
you
how
important
our
our
ecosystem
is,
and
these
languages
are
to
programmers
as
a
part
of
this
data
and
part
of
this
sort
of
discovery
work.
We
notice
that
there's
over
94
of
the
repositories
that
are
you
know,
utilizing
javascript.
They
rely
on
open
source
and
our
ju
as
a
very
healthy
community.
B
C
Vulnerabilities
in
software
they
occur
like
regardless
of
language
and
framework
and
ecosystem.
Getting
them
fixed
is
really
where
I
focus
on
from
like
the
security
side.
So
getting
things
fixed
kind
of
in
any
ecosystem
is
really
difficult.
I
think
they
call
it
dependency
hell
everywhere
for
a
reason.
B
B
So
we
also
wanted
to
take
some
time
to
look
at
the
state
of
the
advisories
that
get
flagged
within
our
ecosystem
as
well
and
utilize.
Some
of
that
same
data
that
we
found
within
the
octavers
report
from
2020.
first
off.
We
just
want
to
take
note
that,
since
you
know,
october
of
2015,
the
npm
advisory
db
has
filed
over
1600
avayari
advisories,
which
is
pretty
amazing.
B
In
terms
of
you
know,
the
folks
flagging
issues
that
are
coming
up
within
the
software
that
we're
consuming
and
another
really
interesting
fact,
is
that
59
or
there's
a
59
percent
chance
of
you
being
flagged
or
they're
a
cve
being
filed
against
one
of
your
dependencies
based
on
you
know
those
numbers
that
we
were
seeing
before
with
how
many
transitive
defenses
we
have
it's
pretty.
That's
a
pretty
large
number.
B
B
We've
seen
that,
at
least
from
you
know,
github
side
that
there
was
only
70
of
those
that
were
sort
of
actively
malicious
that
those
cvs
were.
You
know,
potential
worms
or
malware,
whereas
there
were
the
other
83
of
those
seem
to
be
results
of
mistakes
potential.
You
know
errors
and
vulnerabilities
within
our
code
that
were
being
caught
by
by
researchers
and
and
and
folks
that
were
flagging,
these
things
to
to
maintainers
and
to
the
ecosystem.
A
D
Great
thanks,
so
I'm
nick
o'leary,
I'm
the
project
lead
co-creator
of
node-red,
one
of
the
other
projects
of
the
opengs
foundation,
which
is
a
low-code
programming
tool
written
in
node.js,
and
I
think,
what's
a
bit
different
about
some
of
node-red's
interests.
Is
our
users
aren't
necessarily
node
developers
or
javascript
developers?
A
We
often
focus
so
much
on
the
developers
of
libraries,
the
developers
of
applications,
but
I
think
we
really
miss
out
on
the
perspective
of
the
end
users,
who
often
are
just
seeing
reports
in
their
cli,
and
they
don't
really
know
you
know
what
that
means.
Yeah
does
that.
Does
that
play
a
big
role
in
in
your
users
and
the
reports
that
you
get.
D
Absolutely
you
know
certainly
for
users
who
aren't
familiar
with
with
npm.
You
know
we
we
document
the
commands
they
should
run.
We
don't
go
overboard
on
all
the
flags.
You
can
give
npm
to
quieting
down
the
warnings,
because
you
know
you
don't
want
to
suppress
genuine
warnings
that
users
kind
of
should
know
about,
but
there's
always
going
to
be
stuff
in
there
that
we
know
doesn't
matter,
but
some
users
well
lots
of
users
ignore
it,
but
some
users
do
get
concerned
by
having.
D
Even
you
know,
moderate
severity
audit
warnings,
whatever
it
might
be
and
again
the
nature
of
node-red-
is
there's
quite
a
large
dependency
chain
of
modules,
because
it's
a
programming
platform
it
can
pull
in
all
sorts
of
different
modules,
depending
what
else
you
install
into
it
to
supplement
it.
So
you
know
the
scope
of
what
warnings
you
might
get
is
pretty
pretty
large,
depending
on
the
modules
being
being
installed.
C
How
I
would
interpret
this
right,
it's
it's
given
all
these
inputs,
given
my
background,
given
my
security
expertise,
this
is
what
I
think
is
you
know,
kind
of
the
most
correct
or
the
safest
path
forward
and,
let's
you
know,
work
together
on
ways
to
address
any
productivity
issues,
or
can
we
can
we
join
those
things
right?
Like
can
we
say
productivity
and
security
get
to
hold
hands
and
cross
the
finish
line
together
right.
A
A
E
E
Meanwhile,
I'm
also
doing
some
open
source
and
trying
to
lurk
around
the
nodejs
diagnostics
working
group
and
some
other
places
and
a
bit
of
security,
so
yeah,
so
it
all
started
when
we
had
around
20
apps-
and
you
know,
security
was
important,
but
we
discovered
that
we
can
monitor
dependencies
for
security
a
bit
late.
In
my
opinion.
Well,
npm
audit
didn't
exist
yet,
but
node
security
project
was
already
there,
so
I
installed
the
nsp
command
and
run
nsp
check
and
thought.
Well.
This
is
awesome.
E
So
one
day
like
two
or
three
weeks
after
I
put
it
in
ci
everything
literally
everything
got
red
because
there
were
like
10
or
20
different
dependencies
that
got
us
the
bad
status.
So
first
thing
we
did
was
spotting
that
most
of
those
are
death.
Dependencies
and
most
of
the
vulnerabilities
are
regular
expression,
denial
of
service,
so
yeah,
the
one
that
everyone
loves.
So
an
sp
check
at
the
time
would
only
allow
ignoring
by
the
vulnerability
advisory
number.
E
E
So
we
switched
to
npm
audit,
but
it
was
still
too
much,
and
that
was
the
decision.
So
I
have
to
choose
between
not
running
this
as
a
ai
step,
which
I
still
consider
a
good
thing
to
run
it
in
ci
to
build
the
the
culture
of
caring
for
security
on
any
team,
and
so
the
other
choice
was
to
make
it
reasonable
to
run
npm
audit
as
a
ci
step.
And
that's
where
npm
audit
resolver
came
in.
A
E
E
E
I
want
people
to
think
about
it
every
now
and
then,
and
if
you
get
a
tool
that
tells
you
now,
this
is
insecure
every
single
time
you
commit
something:
that's
not
going
to
build
this
culture,
because
people
are
going
to
treat
it
as
an
annoyance.
So
you
need
a
tool
that
lets
you
make
decisions,
hopefully
informed
decisions
on
what
to
ignore,
because
only
when
you
can
ignore
some
vulnerabilities
you're
going
to
be
able
to
really
care
about
the
ones
that
are
important.
C
Where
can
we
take
decisions,
maybe
away
or
obstruct
them
away,
but
put
in
safe
defaults
right?
I
think
I
think
safe
defaults
with
the
option
to
undo
with
the
understanding
that,
like
that's
an
action
that
a
developer
is
taking
so
that
they
have
to
you,
know
kind
of
understand
what
they're
undoing,
rather
than
going
in
with
the
expectation
that
something's
secure,
because
why
would
they
give
me
something
insecure
to
start
with,
and
I
have
to
go
like
do
all
of
the
work
to
pop
security
onto
it
yeah.
C
A
A
The
information
that
is
gathered
on
one
end
of
the
life
cycle
is
not
propagated
all
the
way
through
to
the
other
end,
I
think
in
the
case
of
cve
remediation.
This
is
especially
true
to
help
understand
this
better.
I
asked
each
of
our
interviewees
a
little
bit
about
how
they
think
we
can
improve
this
situation.
D
D
The
bit
that
I
feel
is
missing
is
a
way
for
us
to
then
say
you
know
in
a
in
some
metadata
somewhere
in
the
module
saying
you
know
this,
this
vulnerability.
We
have
evaluated-
and
please
you
know,
suppress
this
from
when
you
install
when
a
end
user
installs
us,
because
you
know
we
have
done
the
technical
work
to
validate
that.
That
vulnerability
does
not
apply
to
us
and
please
don't
bother
our
users
with
that.
Now.
D
I'm
also
well
aware,
there's
a
lot
of
good
will
in
a
mechanism
like
that,
and
it
would
be
right
for
abuse
for
people
to
not
do
the
technical
work
to
do
that
validation
and
just
do
whatever
it
takes
to
shut
the
warnings
up.
But
you
know,
I
think,
there's
going
to
be
a
trade-off
between
the
user
developer,
experience
for
end
users
of
modules
and
maintainers
of
modules,
and
I
I
do
think
there's
got
to
be
a
better
balance
to
what
we
have
today.
E
The
security
game
when
you're
not
attacking
when
you're
defending
is
about
prioritizing,
so
you
always
need
to
be
able
to
say
okay.
This
is
the
last
day
of
the
sprint
and
I
need
my
build
green,
even
if
it
means
there's
gonna
be
some
vulnerable
dependencies
that
I
didn't
have
time
to
review
what
now.
So
I
literally
built
a
feature
for
that
which
lets
you
quickly
ignore
a
failed
dependency
scan
for
24
hours.
E
This
is
enough
for
the
sprint
review
and
then
your
build
is
red
on
the
next
day,
again
you're
you're
back
to
fixing
it,
but
you
didn't
have
to
break
everything.
You
didn't
have
to
fail
a
sprint
because
there's
a
tool,
so
it's
no
longer
an
annoyance.
It's
something
that
helps
you
and
it
builds
the
culture
in
the
team
to
well
try
to
stay
on
the
ball
with
making
your
dependencies
secure
and.
C
So,
if
it's
like
tell
me,
tell
me
the
right
path
to
get
rid
of
this
thing.
To
answer
your
actual
question
that
you
asked,
I
do
see
that
there's
opportunities
to
kind
of
pass
through
that
guidance,
and
I
I
like,
I
wonder,
also
if
that's
just
a
way
of
standardizing
how
that
stuff
kind
of
comes
in
doing.
A
These
interviews
was
a
great
way
to
validate
that
there's
room
for
improvement
in
cve
reporting
and
remediation,
but
at
this
point
I'm
sure
you're
asking
yourself
well
what
is
a
collaboration
space?
Why
not
talk
about
these
things
in
some
existing
groups
like
the
package,
maintenance
working
group
or
with
folks
directly
at
npm
or
sneak
or
one
of
the
other
parties
involved?
Since
this
is
the
very
first
one
I
you
know,
we
want
to
make
sure
that
people
understand
what
what
we're
doing
here.
A
So
the
collab
space
is
a
new
program
set
up
by
the
opengs
foundation.
It
gives
us
a
neutral
ground
to
bring
together
parties
from
from
different
parts
of
this
ecosystem,
different
parts
of
the
cve
life
cycle,
and
and
gives
us
a
nice
space
with
support
from
the
foundation
to
to
discuss
these
ideas
and
come
out
of
it
with
you
know
solutions.
A
A
Something
like
improving
communication
lines
between
mainer
maintainers
of
open
source,
libraries,
end
users
and
then
also
the
other
direction,
maintainers
open
source
libraries
and
the
full
the
security
folks
who
file
and
then
there's
the
obvious
space.
Where
we
sit
in
the
middle,
which
is
tooling.
We
have
a
lot
of
tooling
in
the
ecosystem.
A
But
you
know
the
the
context
that
the
security
folks
have
it's
not
always
reaching
that
that
folks,
who
have
the
the
control?
In
the
end,
the
application
developers,
the
open
source
library,
authors.
So
you
know
finding
the
ways
that
we
can
better
tool
around
these,
so
that
the
the
people
who
are
most
impacted
by
these
security
incidents
have
the
context
they
need
to
be
able
to
remediate
or
ignore,
because
we
always
know
sometimes
ignoring
is
the
right
answer
when
that
particular
cve
doesn't
apply
to
your
project.
A
So
the
next
obvious
question
is:
how
can
you
get
involved
in
this
we're
going
to
be
starting
regular
meetings,
monthly
to
get
kicked
off,
we'll
be
scheduling
them
on
the
github
repo?
Our
hope
is
to
start
next
week,
so
hopefully,
y'all
can
can
hop
over
onto
the
github
repo
and
and
and
join
us
for
the
meeting
and
we'll
discuss.
A
B
E
So
every
time
I
get
an
audit
to
me,
it's
just
free
information.
These
are
things
that
I
could
have
spent
a
lot
of
time
figuring
out
for
myself,
but
I'm
getting
this
for
free
and
it's
literally
the
same
attitude
when
it's
code
and
when
it's
information
about
the
vulnerabilities.
So
that's
my
point
of
view.
So
this
is
free
information
and
I
decide
what
to
do
with
it.
No
the
site
is
not
the
right
word,
I'm
responsible
for
figuring
out
what
to
do
with
it.
E
A
D
D
That's
a
good
question.
I
I
don't
think
I
necessarily
get
a
a
good
sense
on
that,
certainly
when
it
is
someone
who
is
emailing
us
rather
than
asking
yeah
when
it's
someone
who's
following
our
security
policy
to
report
a
security
issue,
you
kind
of
immediately
understand
that
this
is
someone
who
is
perhaps
a
bit
more
switched
on
to
these
problems.
So
and
in
general
you
know
the
response
when
we
explain
the
situation.
D
E
D
Having
some
way
that
npm
audit
could
say,
yes,
there's
a
vulnerability,
but
here's
what
the
node-red
project
says
about
it
and
put
that
up
front
would
just
again
put
that
put
more
confidence.
It
would
remove
that
period
of
doubt
when
someone
has
felt
the
need
to
report
a
security
vulnerability
to
the
time
when
they
get
a
response
from
us.
D
You
know
if,
if
the
tooling
could
at
least
give
give
our
assessment
to
that
vulnerability
up
front,
even
if
you'd
rather
hide
it,
you
know
just
say
you
know,
and
here's
what
node
red
says
about
this,
which
could
be.
Thank
you.
We're
aware
fix
coming
in
in
a
week's
time
in
our
next
mentioned
release,
or
you
know,
judged
as
not
relevant
to
the
node-red
use
case
whatever
it
might
be.
E
Well,
I
want
to
say
yes,
because
theoretically,
there
is
a
link
to
a
write-up
with
a
poc,
often,
but
not
really
so.
I've
seen
it
way
too
many
times
that
that
conversation
on
the
team
we're
building
a
feature.
There's
a
there's,
a
merger
request
it's
getting
reviewed.
Meanwhile,
the
build
is
red
because
of
audit.
So
hey
what's
happening,
oh,
I
gotta
fix
the
audit
okay
ten
minutes
later.
What
did
you
do?
E
E
C
E
I
can
spare
some
time
to
research
it
now,
but
we
can
move
forward
with
the
feature
or
exploitability
is
very
high.
Okay,
let's
stop
the
work
and
look
into
it,
so
that
seems
to
me
like
a
very
valuable
thing,
but
this
is
just
a
number
and
I
don't
know
where
it's
coming
from
so
I
might
just
be
very
naive
about
it.
D
D
Where
a
lot
of
people
run
node-red,
they
wouldn't
necessarily
have
the
right
build
tools,
so
we
actually
have
b-crypt
as
an
optional
dependency
and
bcrypt.js
as
a
main
dependency,
so
that,
if
whatever
reason
bcrypt
fails
to
install,
we
can
fall
back
to
the
javascript
version.
That's
slightly
slower,
but
as
it's
only
when
you
log
in
we
can
afford
for
it
to
take
slightly
longer.
D
So
there
there
was
a
period
of
time
when
our
checks,
you
know,
are
there
updates
available
for
modules.
We
just
completely
overlooked
b-crypt
for
for
a
time,
because
again,
the
tooling
just
didn't
pay
attention
to
it,
because
it
was
marked
as
optional,
which
is
a
separate
issue.
But
then
along
came
a
an
issue
that
someone
pointed
out
that
the
b
crypt
we
had
installed
was
had
a
cve
that
the
the
encryption
it
did
in
certain
scenarios
was
not
strong
enough.
D
You
know
it
had
had
vulnerabilities
in
its
encryption
now,
because
bcrypt
is
by
well
as
from
my
understanding
of
it,
because
bcrypt
has
a
binary
component,
they
have
been
quite.
They
have
a
compatibility
table
of
if
you're,
using
these
versions
of
node.
This
is
the
version
of
b
crypt
and
it's
actually
quite
a
you've,
got
to
try
and
get
that
right
and
thankfully
that
it's
always
the
case.
Their
latest
version
supports
everything
and
higher,
so
it
as
long
as
long
as
you're
on
the
latest
version.
D
So
when
we
looked
at
the
actual
details
of
the
vulnerability
again,
I
I
can't
remember
the
the
specific
parts
of
the
internals
of
the
module,
but
our
analysis
of
it
showed
the
the
very
limited
way
we
used
group
bcrypt
purely
just
to
encrypt
the
password
which
is
stored
on
disk.
It's
never
transmitted
anywhere
and
then
to
do
the
comparison
of
the
password.
That's
received
that
didn't
go
near
the
the
vulnerable
code,
so
we
were.
We
were
satisfied
that
the
the
risk
was
not
present
for
for
node
red
users.
I
think.
C
Yeah
we
we
fight
this
frequently
right,
I
think
everywhere.
I've
been
just
software
supply
chain
is,
is
hard
and
so
a
lot
of
times
like
the
only
way
to
scale
it
has
been.
You
know,
let's,
let's
have
people
update
their
libraries,
even
if
it's
not
necessarily
vulnerable,
but
we,
but
it
has
a
vulnerability
right.
C
E
What
what
I
would
find
useful
is
information
in
the
audit
or
elsewhere
about
other
people's
choices.
So
there
is
thousands
of
people
like
me,
checking
the
audit
looking
at
it
deciding
like
this
regular
expression,
denial
of
service
in
a
fourth
level,
dependency
of
express
doesn't
seem
like
it's
affecting
anything.
But
what
do
I
know?
So?
The
question
is:
are
there
any
people
who
already
researched
it
and
made
a
informed
choice?
E
I
could
be
okay,
I'm
a
troll,
I'm
gonna,
say
influencer
in
this
area.
So
what
I
publish
is
gonna
be
a
an
informal
guideline
for
some
other
teams,
for
example.
If,
if
I'm
involved
in
a
certain
project,
I
can
publish
information
about
what
I
consider
safe
to
ignore
and
people
could
use
that
information
as
a
factor
not
one
by
one,
so
not
importing
my
decisions,
but
just
reading
up
on
them,
treating
them
as
a
suggestion
where,
when
making
their
own
choice,.