►
From YouTube: Package ThinkBIG: March 2021
Description
In this edition we discuss adding in security features and improved test coverage
A
Hello
and
welcome
to
the
monthly
think
big
for
the
package
group,
and
today
we
actually
have
two
guest
stars
appearing
to
talk
through
some
potential
integrations
with
security
features
and
we
have
a
full
agenda.
So,
let's
see
what's
the
first
item
is
yeah
so
ethan
and
dennis
you
both
mentioned
the
idea
or
you
conducted
a
pov
of
package
hunter
and
proposed
integrating
the
functionality
into
the
product,
at
least
for
npm.
B
B
So
potentially
that
would
be
nice
addition
to
our
package,
offering
where
we
could
say.
Okay
when
a
package
is
added
to
our
registry,
we
kind
of
do
a
do
a
behavioral
monitoring
of
the
package,
and
then
we
let
the
maintainer
of
the
registry
know
hey
this
package
that
you
just
added
this
an
outgoing
call.
As
soon
as
you
install
it.
Maybe
you
want
to
check
that.
That's
expected
yeah.
We
already
use
this
on
the
gitlab
rails
app.
You
can
see
the
results
in
the
security
dashboard
yeah,
so
curious.
Put
your
thoughts
on.
C
I
I
was
just
gonna,
add
a
little
bit
that,
like
this
is
different
from
like
dependency
scanning
itself,
because
it
helps
identify
unknown
malicious
packages
as
opposed
to
identify,
if
you're,
using
a
known,
malicious
package
already,
and
then
I
was
just
gonna
add
along
with
uploading
packages,
it
could
potentially
be
used
as
part
of
like
a
package
proxy
or
something
like
that.
So
as
if
someone's
using
gitlab
to
download
all
their
packages,
you
know
as
it's
pulling
from
somewhere
else.
C
C
So
I
mean
I,
I
wonder:
dennis:
can
you
speak
a
little
bit
about
how
it
works
today,
because
one
of
the
questions
that
we
have
is
you
know
like
as
a
pov?
It
isn't
necessarily
like
in
a
format.
That's
performant
or
you
know,
just
ready
to
put
in
the
product
right
away
and
so
start
part
of
the
discussion
we're.
Having
is
like
what
work
would
need
to
be
done
in
order
for
it
to
be
useful
to
you
all.
B
Sure
yeah
right
now,
it's
pretty
much
a
prototype
that
was
made
on
purpose
for
internal
usage.
If
we
actually
want
to
make
that
part
of
the
product
and
we
we
can
use
the
same
concepts
and
ideas,
but
maybe
we
need
to
re-implement
it
so
very
likely.
We
need
to
be
implemented
yeah
right
now.
How
it
works
is
it's.
B
B
D
So
looking
at
this
isn't
on
a
list
of
things,
we
know
is
bad,
but
it's
acting
in
a
way
that
we
don't
think
is
good
and
it
certainly
aligns
with
what
our
larger
customers
are
asking
for,
which
is
we
want
all
of
the
data
that
gitlab
can
give
us
about
what
how
safe
and
secure
this
package
is.
So
it
really
aligns
with
what
our
users
are
looking
for.
A
B
Right
now
it's
node
right,
but
the
monitoring
works
on
the
process
basis,
so
you
could
apply
the
same
concept
to
other
programming
languages
as
well.
The
thing
that
you
probably
have
to
to
customize
for
each
languages
are
the
rules
files
so
so
far
go
I'm
not
aware
of
your
well.
If
you're
aware
of
fico
fargo
is
also
part
of
of.
E
B
So,
for
example,
I
whitelisted
the
registry
from
which
we
now
pull
the
dependencies
in,
because
this
is
expected
right
when
you
do
an
npm
install,
it
needs
to
pull
the
dependencies
from
the
registry.
So
this
is
an
okay
network
connection,
but
if
it
does
any
other
network
connection
to
some
unknown
server
that
that
would
not
be
okay
so,
like
likewise
for
ruby,
for
example,
we
would
need
to
to
whitelist
ruby
gems.
C
E
C
A
B
A
B
A
And
I
know
I'm
asking
a
lot
of
questions.
You
mentioned
the
in
the
proof
of
concept
that
the
it
ended
up
in
the
security
dashboard,
any
known
vulnerabilities,
but
I'm
assuming
that
it
would
there's
no
concerns
about
having
that
in
the
package
registry
user
interface
as
well.
Right,
maybe
have
it
bubble
up
in
both
places.
B
B
B
Yeah,
that's
actually
it's
also
a
half
of
a
question
for
you
so
right
now.
What
I
can
say
is
that
in
the
security
dashboard,
the
the
alerts
that
are
displayed
there
are
coming
from
from
the
pipeline
from
ci
pipelines,
but
I'm
not
sure
what
the
flow
would
be
if
we,
if
we
add
packages
to
our
gitlab
based
registry-
and
we
want
to
do
this
kind
of
scanning-
which
is
also
happening
in
ci
pipelines-
or
is
this
unrelated
from
ci
pipelines.
C
A
F
I
was
gonna
say
yeah,
like
users
can
can
push
packages
manually,
but
they
can
also
build
packages
and
publish
them
through
a
ci
job,
and
so
I
think,
like
the
idea
that
I'm
thinking
of
is
that
if
a
user
builds
a
package
through
ci,
it
would
be
neat
if
they
had
like
the
optional
job.
To
kick
off
of.
You
know,
go
ahead
and
scan
all
of
the
dependencies
of
the
package
I
just
built
and
and
then
in
the
package
ui.
G
Would
it
make
sense
to
add
a
status
to
the
package
like
a
security
status
and
say
every
time
a
new
package
appears
in
the
ui?
It's
you
know
untested
and
then
periodically
go
and
check
and
move
all
the
untested
to
verified
or
even
have
like
policies
that
you
may
want
to
scan
them
once
a
week,
because
the
dependency
of
the
dependency
can
change
and
invalidate
the
status
right.
B
A
C
And
I
mean
you
could
probably
do
we
could
you
know
to
build
it
out?
You
could
probably
do
some
stuff
where
you
like,
specifically
for
a
network
connection.
We
could
build
out
some
metadata
around
it
like
look
up
some
information
about
the
ip
where
it
is
who
it's
registered
to
that
sort
of
thing
to
help
someone
make
that
decision.
But
since
you
know
we're
dealing
with
unknown
behavior,
it
would
be
difficult
to,
like
you
know,
be
a
hundred
percent.
That's
saying
this
is
definitely
malicious.
A
We
were
yeah,
we
were
like
you
mentioned
earlier
on
in
the
call
we
were
talking
about
building
this
ourselves
ourselves
as
part
of
the
dependency
firewall
and
coming
up
with
a
set
of
rules,
but
it
sounds
like
maybe
package
hunter
could
be
an
accelerator
on
that
we
don't
have
to
to
build
everything
ourselves
and
then
we
would
just
have
to
when
we
add
a
new
format
update
then
like
a
rules
file.
Basically
that's
pretty
awesome.
That
would
be.
That
would
be
a
nice
bonus
for
us
to
not
have
to
build
out.
A
C
So
would
like
a
potential
mvc
be
the
pipeline
job.
Since
we
have,
we
basically
can
do
a
pipeline
now
right
and
then
it
would
just
be.
You
know
having
a
a
pipeline
template,
or
you
know
some
way
that
it
presents
this
to
someone
and
then
ingesting
the
results
into
package
and
use.
You
know
incorporating
it
into
the
ui.
F
Yeah,
I
can
see
an
mvc
where
we
have
that
ci
set
up
and
then
we
can
incorporate
it
into
the
pipeline
and
then
within
the
ui.
If
someone
manually
pushes
a
package,
maybe
there's
a
button
to
kick
off
the
job
next
to
the
package,
so
you
know
prior
to
adding
the
background
jobs.
There's
just
a
way
for
users
to
manually
start
that
job
for
packages
that
weren't
built
with
pipelines.
F
H
C
Yeah
we
would
one
of
the
challenges
we
would
have
is
how
to
that,
because
it's
basically
a
special
runner
that
does
this.
You
know
you
have
to
have
falco
running
on
a
runner,
so
it
would
be.
How
do
we
make
that
available
as
well,
because,
right
now
we
just
it
is
for
us
just
a
system
that
you
know
a
system
that
we
lives
in
one
of
our.
You
know
one
of
our
cloud
environments
that
it
talks
to
so
we'd
have
to
explore
how
to
offer
that
and
allow
customers
to
set
it
up
and
stuff.
H
So
I
feel
like
there's
a
couple
of
there's
a
couple
of
like
first
steps
here.
One
would
be
figuring
out
to
add
hooks,
but
I
think
that's
like
one
scenario
where
someone
uploads
a
package
directly
rather
than
building
one.
So
we
could
just
go
down
the
path
initially
for
an
mvc
to
go
for
built
packages
so
that
we
have
the
trigger
point
already
built
in.
H
So
we
don't
have
to
go
and
add
that
the
other
thing
we
still
have
to
do
is
figure
out
how
we're
going
to
create
this
as
an
internal
service,
because
if,
if
we
still
have
to
do
that,
then
we
there's
a
whole
bunch
of
other
heavy
lifting.
We
need
to
do
around
infrastructure
and
whatnot
to
make
sure
that
we've
got
this
service
unless
it's
like
just
an
integrated
process
that
we've
built
into
the
rails,
app
right.
C
H
You
know
how
ops
has
been
looking
at
higher
risk
areas,
and
you
know
this
type
of
scenario
security.
You
know
problem
of.
I
can't
word
today,
sorry,
but
this
type
of
scenario
is
on
the
list
of
really
high
potential
risk
areas
for
this
stage
for
the
sub
department,
so
we
definitely
want
to
like
invest.
I
don't
need
to
sound
like
I'm
trying
to
shut
anything
down,
I'm
not
like
okay,
next
steps.
What
do
we
do
so?
H
It
feels
like
the
we
already
have
hooks
for
pre-built
for
internally
built.
If
we
do
uploads
figure
out,
if
there's
a
hook
there,
I
know
there's
a
hook
there,
because
we're
obviously
logging
things,
so
there
must
be
a
way
to
hook
into
that.
If
there's
a,
we
need
to
build
a
background
process,
and
we
already
know
how
to
do
that,
so
it
doesn't
feel
like
a
heavy
lift
either,
but
working
out
whether
we
haven't
already
implemented
version
probably
feels
like
the
next
step,
who's
who's
best.
To
do
that,
you
reckon
tim.
H
A
A
I
see
him
pasting
the
issue
there
and
that
is
a
similar
dependency
that
a
ci
job
has
to
run,
and
so
there
would
need
to
be
a
background
process.
So
I
feel
like
there's
a
couple
of
things
that
we
could
bring
together.
Working
on
this,
so
I'd
be
happy
to
help
bring
in
some
of
the
defend
folks
to
see
what
we
could
do.
H
Yeah,
I
think
if
we
can,
maybe
if
we
have
an
issue,
that
we
want
to
write
up
to
start
like
figuring
out
what
we're
doing
or
how
we
want
to
move
forward
with
this
idea,
because
I
think
this
is
an
awesome
idea.
I
don't
know
if
my
tone
reflects
that,
but
I
think
this
is
great.
Thank
you
very
much
like
and
just
figure
out
what
gaps
we
have
there
write
it
down
and
then
we
can
start.
C
A
D
I
just
want
to
call
that
from
the
ux
side
that
if
we
can
get
all
of
the
defend
and
all
the
metric,
that
kind
of
gathering
to
be
consistent,
so
that
there
is
a
button
that
triggers
the
ci
job.
If
that's
the
way,
we
do
it
that
will
help
our
users
know
that
security
is
happening
the
same
way
every
time
and
it
makes
them
more
likely
to
trust
the
data
we're
presenting,
especially
when
it
comes
to
dependencies
and
security
of
those
dependencies.
We
won't
want
to
be
crystal
clear
the
whole
time.
A
A
I
know
he
was
a
maybe,
but
we
were
talking
recently
about
as
we
consider
dog
fooding
the
package
registry
which
we
are
talking
about
for
node
and
for
ruby,
should
we
should
gitlab
still
use
public
registries,
or
should
we
move
all
of
getlab's
packages
to
be
hosted
in
gitlab
and
then
there's
a
link
to
an
issue
for
discussion
and
it's
kind
of
similar
to
what
we
were
talking
about
a
few
minutes
ago.
So
I'm
just
wondering
if
anyone
has
any
opinions
on
that.
C
C
G
So
I
wanted
to
join
the
conversation
here.
I
think,
before
we
are
able
to
move
this
stuff
internally,
we
need
to
have
a
really
clear
workflow
and
now
we
end
all
updates
and
dependency
of
dependency
update,
at
least
the
front-end.
We
are
doing
weekly
updates
of
packages
and
we
need
to
be
able
to
keep
the
written
to
you
to
address,
bug,
fix
and
new
feature,
and
this
kind
of
thing
so
I
think,
a
workflow.
H
A
H
H
Yeah,
so
I'm
we've
been
talking
for
a
while
about
the
idea
of
doing
sort
of
like
a
dependency
sort
of
cash
proxy
type
scenario.
Where
we're
you
know,
setting
up
an
order
of
operations
for
customers
to
be
able
to
say
you
know
if
it's
not
in
my
local,
then
pull
it
from
somewhere
else
and
pull
it
from
somewhere
else.
Like
is
this?
Does
this
idea
contradict
that
in
that
we're
going
to
then
say
no,
we
should
be
moving.
H
A
I
shared
in
slack
that
white
paper
from
microsoft
of
of
them
basically
saying
that
you
should
host
all
of
your
packages
locally
and
not
pull
that
or
if
you
pull
them
from
a
public
registry,
pull
them
to
a
local
place
and
then
use
them
from
there
when
you
can
check
them.
So
that's
kind
of
against
the
idea
of
creating
the
virtual
registry
or
using
the
dependency
proxy.
Like
you
said,
I
think
it's
something
that
we
should
consider
and
and
validate.
It
certainly
seems
like
customers
still
want
that
capability.
A
G
I
think
the
idea
is
still
valuable
if,
especially,
if
you
think
it
has
a
middleman
step
that
you
can
configure
so
it
it
can
also
be
used
as
a
security
layer
right.
So
everything
gets
pulled
in
the
cache
and
once
in
the
cache,
you
can
validate
it
and
move
it
to
more
permanent
registry,
and
then
you
are
able
to
turn
off
pulling
out
from
external
registry.
A
H
H
Then
we,
then
we
need
to
make
sure
that
we're
the
ones
we
have
a
record,
basically
where
the
single
source
of
truth
for
whatever
packages
are
available.
If
this
is
the
type
of
thing
we
want
to
do,
and
maybe
they're
not
maybe
they're,
not
mutually
exclusive,
so
that
you
could
have
an
option
to
turn
that
on,
but
I
think
you
know
for
customers
that
are
interested
in
saying.
Well,
if
you
can't
get
it
locally,
get
it
from
here,
get
it
from
here
get
from
here.
H
Thank
you,
tim
yeah,
so
we
had
a
recent
intro
incident
in
production.
Well
documented.
Thank
you
very
much
for
that.
Definitely
just
start
thinking
more
more
carefully
about
how
we're
focusing
on
quality
in
our
code
a
couple
of
issues
I've
shared
around
that,
but
I'm
looking
for
you
know
you
know,
thoughts,
feedback
and
and
sort
of
suggested
action
to
take
here
to
improve
our
our
quality
a
little
bit.
H
I'm
I
know
we
can't.
We
can't
avoid
being
human,
it's
one
of
those
things
that
just
happens.
So
no
one's
expected
to
be
perfect
here,
because
I'm
certainly
not,
but
let's
like
sort
of
think
about
ways
that
we
could
start
improving,
how
we
can
get
coverage
end-to-end
tests,
what
testing
important
important
and
also
risk
of
evaluating
risk,
and
I
actually
have
a
document-
I'm
gonna
share
david.
You
had
a
thought.
E
H
I
think
there's
always
going
to
be
we're
not
always,
but
particularly
with
new
functionality.
There's
always
going
to
be
that
I'm
not
sure
how
our
customers
are
going
to
go
and
use
this.
We
don't
have
all
of
the
test
cases,
but
the
other
issue
I
was
looking
for
was
the
suggestion
I
made
around
scanning
logs
and
doing
an
analysis
of
actual
request
patterns
and
sort
of
seeing
if
we
can
determine
that
we're
covering
you
know
common
case
usage
patterns
from
our
customers.
H
H
You
know
but
consider
how
you
might
evaluate
the
code.
You're,
writing,
but
also
like
how
could
we
test
this
in
a
way
that
doesn't
require
an
individual
to?
You
know
like
figure
out
how
everything's
going
to
work
and
that's
our
only
method
of
preventing
issues
because
we're
all
you
know,
as
I
said,
we're
all
human
we're
not
going
to
get
everything
right
and
that's.
Okay.
Let
me
see
if
I
can
find
that
issue.
A
Do
from
a
pl
from
a
priority
perspective,
do
people
the
to
feel
like
we
have
are
moving
forward
like
we
are
scheduling
time
to
a
lot
for
this
work,
because
I
know
it
can
be
it's.
You
know
it's
another
type
of
engineering
project
to
add
these
tests
and
to
think
about
them
and
where
they
go
and
stuff
like
that.
So
I
just
want
to
make
sure
that
you
do
feel
that
way
and
that
I'm
that
I'm
making
rooms
and
space
for
that
too,
from
a
future
planning.
A
Diabetes-
it's
a
big,
maybe
well!
I
I
do
think
that
this
would
be
something
that
we
we
could
a
lot
more
time
for
our
planning
issues,
and
I'm
I'm
definitely
happy
to
do
that,
because
the
the
incidents,
the
customer
incidents
are
a
big
drain
on
our
customers
and,
of
course,
on
us.
No
one
likes
to
have
to
deal
with
with
with
those.
F
I
Go
on
something
about
code
coverage
right
now,
at
least
for
container
registry.
It's
for
go
projects,
you'll
get
a
report.
That's
just
like
hey,
like
coverage,
went
up
this
much
or
went
down
this
much
across
all
the
pipelines,
but
one
of
the
things
you
can
do
with
go
is
you
can
say
like,
and
I'm
sure
like
other.
I
I
just
have
this
where
you
just
like
highlight
my
mail
line
like
what
lines
are
actually
covered
by
the
test,
which
ones
are
not,
and
I'm
wondering
if
highlighting
those
in
an
mr
review
would
be
worthwhile.
You
know
coverage
is
not
perfect
metric,
but
it
might
be
nice
to
to
have
a
that
in
the
reviewer's
face
like
oh,
like
this
line
isn't
covered
by
a
test
like.
Maybe
I
should
ask
why
or
spay
or
pay
a
particular
attention
to
this
case.
G
I
think
we
had
a
feature
that
has
been
turned
on
for
a
while,
on.com
and
I
think
is
now
off
that
was
showing
the
coverage
on
the
reviewer
interface.
I
definitely
saw
it
live,
maybe
we
can
see
if
we
can
enable
this
for
the
container
registry
specifically,
so
you
will
get
a
green
line,
it's
not
on
now,
but
it
was
definitely
for
a
while,
and
I
remember
it
was
demoed
on
a
front-end
call.
So
maybe
we
can
investigate
this
because
it's
something
that
we
have.
H
Already
testing
team,
I
know,
is
working
on
some
really
cool
stuff,
I'm
just
looking
for
the
direction
page
that
I'll
share
here
I
go
to
ian.
I
can
type
that
thank
you
yeah,
so
that
I
know
the
testing
team
is
working
on
some
pretty
pretty
cool
things
around
code
quality
test
coverage.
So
I
I
think
what
I'm
looking
for
is
like.
Let's
consider
things
like
automated
testing,
which
is
why
I
was
proposing
you
know.
H
H
I
mean
this
conversation
applies
equally
to
all
of
the
projects
that
we're
writing
code
in
regularly.
It's
not
just
you
know
the
rails,
app
or
container
registry
independently.
It's
it's
all
of
the
things
you
know
the
the
area,
wherein
is
a
pretty
high
sort
of
considered
tier
tier
zero-ish
tier
one
to
zero-ish
operationally
and
was
really
critical
to
the
business.
So
you
know
outages
that
we
have,
as
everyone
notices,
get
a
lot
of
attention
not
only
internally,
but
also
from
you
know,
important
customers.
H
I
don't
know
the
best
format,
probably
an
issue
somewhere,
but
I
was
really
hoping
to
start
a
conversation
at
least
get
you
all
thinking
about
how
we
could
look
at
generating
automated
testing.
It
doesn't
rely
on
us
writing.
You
know
heaps
of
lines
of
code
of
testing
and
see
if
there's
a
way
we
can
improve
in
this
area.
I'm
getting
that
everyone
may
not
have
ideas,
but
that's
kind
of
what
I'd
like
to
start
thinking
about.
G
I
have
a
question
around
this:
is
there
some
expertise
that
can
be
trained,
somebody
that
specialized
on
trying
to
identify
or
like
another
set
of
eyes
that
we
can
put
on
a
risky
situation,
a
risky
piece
of
code
so,
and
why
I'm
thinking
of
this
is
that
I
know
that
there
are
some
engineers
that,
as
soon
as
I
assign
them
on
mr
the
first
thing
that
they
look
is
the
complexity
of
my
requests.
That's
the
first
thing
that
they
say
so
somebody
with
this
focus
that
could
be.
G
H
H
F
Feel
like
that
seems
like
the
kind
of
thing
that,
like
the
domain
expert
type
reviewer,
should
be
able
to
point
out
like
if
I'm
familiar
with
package
code,
I
should
be
able
to
say
hey
this.
Mr
changes,
some
things
that
might
be
a
high
risk,
so
it
could
just
be
a
matter
of
of
training
to
to
include
that
in
in
that
aspect
of
the
review.
A
I
was
gonna
say
from
from
my
part,
you
know
I
I
could
do
some
more
like
feature
assurance
testing
like
once
it's
on
staging.
I
could
try-
and
I
try
to
do
this
now
for
like
when
there's
direction,
items
I'll,
try
and
create
like
a
little
demo
video,
but
we
could
put
a
weight
and
say:
okay
until
this
feature
is
more
risky.
Let's
make
sure
that
we
like
that
the
pm
goes
through
and
does
some
feature
testing
before
we
release
it.
A
A
H
Yeah,
I
think
I
mean
that
might
be
helpful,
but
then
everything
ends
up
going
through
you
at
that
point
tim.
So
that's
a
lot
of
load
on
you
as
well.
So
I
think
maybe
what
we
could
do
here
is
evaluate
the
the
risk
analysis
rubric
that
the
document
I
shared
above
in
the
issue
I
want
to.
Let's
have
everyone
check
in
with
with
evaluating
that
risk,
analysis
and
sort
of
see
if
it
aligns
and
then
maybe
we
should.