►
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
Hello,
everyone
and
welcome
to
today's
webinar
enterprise.
Javascript
done
right,
the
tools
you
love,
the
security
you
need.
My
name
is
danielle
wambolt
and
I'll,
be
your
moderator.
I
work
on
the
marketing
team
here
at
npm
and
I'm
excited
to
be
hosting
today's
session.
I'm
pleased
to
introduce
today's
mpm
speaker,
ahmad
nasri
cto,
before
I
hand
it
over
to
ahmad.
I
have
a
few
housekeeping
cover
about
the
presentation
in
the
brighttalk
webinar
platform.
A
First,
today's
webinar
will
be
available
on
demand
after
the
live
session
and
is
accessible
through
the
same
link
you're
using
now,
we've
also
added
some
attachments
which
are
available
through
the
attachment
tab
at
the
bottom
of
your
screen.
This
is
where
you
can
find
today's
slides
and
other
related
content,
as
well
as
a
link
to
all
of
our
past
webinars
next
we'd
love
to
hear
from
you
during
today's
presentation.
A
If
you
have
a
question
for
ahmad,
please
feel
free
to
send
it
through
the
ask
a
question
tab
at
the
bottom
of
your
player,
we'll
be
answering
all
questions
at
the
end,
but
please
feel
free
to
submit
your
questions
at
any
time.
If
we
don't
get
to
your
question
during
today's
webinar,
we
will
be
sure
to
follow
up
with
you
afterwards
now
over
to
ahmad.
A
B
Recently
joined
the
team
at
npm
here
and
I'm
leading
our
product
and
technology
teams
as
a
contributor
to
the
open
source
community
myself.
I've
led
and
contributed
to
many
open
source
projects
over
the
years
and
just
recently,
before
joining
npm.
Another
large
team
of
over
500
technologists
in
the
telecom
space
very
exciting,
where
we
build
all
sorts
of
technologies
and
solutions
using
javascript
and
node.js
from
web
to
e-commerce
applications
to
data
processing
and
middleware
apis.
B
A
big
focus
for
me
has
always
been
on
security
and
data
privacy,
especially
in
a
telecom
context.
I
can
tell
you
a
lot
of
interesting
stories
there,
a
lot
of
the
challenges
and
lessons
that
I've
experienced
in
both
the
open
source,
open
source
system
development,
as
well
as
building
enterprise
level
technology
using
javascript,
so
hopefully
we'll
shed
some
light
on
some
of
the
best
practices
and
the
improvements
you
can
adopt
your
own
team's
workflow,
first
and
foremost,
just
some
level
setting
here
what
is
npm
for
those
who
are
not
familiar.
B
You
know,
mpm,
is
the
keyword
that
represents
a
few
things.
So,
let's
start
with
the
cli,
which
is
where
a
lot
of
our
developer
community
is
most
familiar
with.
The
npm
cli
is
the
command
line
tool
that
developers
use
every
day
in
their
workflows
for
installing
discovering
and
running
their
javascript
applications.
It's
also
part
of
your
ci
and
cd
environments
that
are
used
for
deployment
and
installation
of
open
source
and
private
packages.
B
Npm
also
represents
the
public
registry,
which
is
the
centralized
service
that
we
operate,
that
serves
both
the
open
source
and
free
software
development
code
sharing,
as
well
as
your
private
packages
and
private
organizations,
are
hosted
on
there
all
centralized
in
the
public
registry.
It
also
represents
the
website
when
we
talk
about
npm
the
website.
B
That's
where
a
lot
of
the
community
features
the
discovery,
features
for
our
open
source
and
private
package
users
for
discovery
and
for
collaboration
on
open
source
projects,
as
well
as
private
projects
and,
of
course
least,
and
not
last
but
not
least,
is
the
mtm
company,
which
is
npm
inc
that
employs
us
all
that
helps
operate
all
these
systems
and
all
the
open
source
solutions
that
we've
created.
So
you
know
the
joke
here
is
that
naming
things
is
hard,
so
we
just
went
with
the
easiest
option,
which
is
naming
everything.
B
So
again,
let's
just
talk
a
little
bit
more
about
where
npm
fits
in
the
developer
workflow.
So
npm
really
is
the
backbone
of
javascript
development,
whether
it's
in
publishing
or
discovering
of
packages
or
the
workflows
that
developers
go
through
every
day.
We
know
we
have.
You
know
around
11
million
developers
from
all
around
the
world
downloading
about
50
billion
downloads,
monthly
and
all
all
accessing
public
packages
of
around
a
million
public
packages,
not
including
all
the
private
packages
that
are
published
and
maintained.
B
We
don't
obviously
talk
about
the
private
package
numbers,
but
the
public
ones
are
just
indicative
of
the
growth
of
javascript
in
general
and
speaking
of
javascript
javascript
is
where
modern
software
development
stacks
happen.
You
know
third
93
of
javascript
developers
all
use
npm,
whether
directly
or
indirectly,
as
part
of
your
ci
environments
or
your
local
development
practices.
We
know
that
from
surveys
that
we've
run
into
our
community
and
other
servers
in
the
javascript
community,
people
use
javascript
primarily
for
work.
B
B
So
when
we
talk
about
open
source
and
when
we
talk
about
security,
when
we
talk
about
these
million
packages
and
the
billions
of
downloads
we're
seeing
every
day,
we
know
from
asking
developers
that
there's
a
lot
of
concern
around
security
and
around
the
the
pipelines
and
around
the
workflows,
the
developers
adopt
and
use
in
their
businesses
whether
this
is
a
small
team
of
developers
or
a
large
enterprise
business
of
hundreds
of
developers.
B
So
we
know
that
83
of
javascript
developers
are
concerned
today
about
the
security
of
open
source
code
in
general,
and
only
14
of
them
are
satisfied
with
the
tools
that
they
have
in
the
industry
to
help
them
address
those
concerns.
B
We
know
the
concerns
and
the
tools
that
are
available
in
the
industry
are
not
necessarily
you
know,
have
kept
up
to
the
pace
of
growth.
The
javascript
communities
and
the
javascript
ecosystem
has
surfaced
so
we're
here
to
talk
a
little
bit
to
you
about
the
kind
of
enterprise
level,
solutions
that
we're
introducing
that
help
you
and
help
your
development
teams
adopt
a
more
enterprise,
focused
development
workflows
using
npm.
B
So
this
is
probably
a
visualization
that
you're
familiar
with
the
javascript
modularity
is
extremely
interesting
in
the
sense
that
you
know
you
might
be
using
one
or
two
or
ten
different
packages,
but
you
know
those
packages
are
going
to
pull
in
another
10x
and
another
100x,
another
1000x
packages
and
dependencies
on
average.
We
know
that
the
javascript
application
developers
are
using
around
2000
distinct
modules
and
packages
within
their
individual
application.
B
Of
course,
each
one
of
those
has
different
versions
and
different
dependencies
and
the
complexity
there
is
quite
high,
so
whether
you're
set
to
or
not
the
open
source
expenses
you
rely
on
have
a
cascading
effect
in
pulling
in
from
any
many
other
sources
behind
the
scenes.
B
So
modularity
actually
is
a
good
thing
as
far
as
development
and
software
architecture
is
concerned,
but
it
does
introduce
risk
and
it
doesn't
reduce
complexities.
So,
let's
talk
about
the
risks
aspects
for
a
bit
from
a
compliance
point
of
view.
Obviously
we
know
the
the
processes
like
I
said,
and
the
tooling
that
exists
in
the
industry
today
have
not
kept
up
with
the
growth
of
javascript
and
have
not
kept
up
with
the
frequency
in
which
these
packages
are
updated.
B
We
know
like
we
have
42
billion
unique
packages
downloaded
monthly
just
from
our
public
registry.
We
know
about
four
percent
of
them
contain
known
vulnerabilities
and
about
1.6
of
them
are
high
or
critical.
We
do
have
a
scale
of
our
vulnerability,
11
levels
so
like
higher
critical
things,
you
really
need
to
pay
attention
to.
We
know
like
things
like
artifact
storage
tools,
limit
collaboration,
you
know
they
don't
support
modularity
in
terms
of
building
and
maintaining
and
sharing
code,
and
that's
kind
of
where
the
enterprise
level
solutions.
B
Today
in
the
marketplace
look
like
and
the
story
I
like
to
share
here
in
terms
of
some
some
of
the
past
experiences
I've
had,
especially
in
the
context
of
a
telecom
business,
as
you
can
imagine,
the
data
privacy
and
the
security
concern
they're,
quite
high.
B
We've
done
all
sort
of
security
safeguards
for
our
employees
and
our
developers,
whether
it's
things
like
firewalls
vpns,
keyed
access
to
buildings,
but
the
one
thing
that's
always
a
moving
for
businesses
of
that
side
is
the
safety
and
security
of
the
developer
machine
itself,
and
this
is
where
you
know,
there's
a
lot
of
talk
in
the
industry.
Around
vulnerabilities
and
security
for
open
source
solutions
and
open
source.
Libraries
and
people
tend
to
look
at
that
only
in
the
production
context.
B
So
let's
talk
about
npm
enterprise
and
how
does
npm
enterprise
help
you
address
some
of
those
concerns.
So,
first
of
all,
what
it
is
mp.
Enterprise
is
single
tenant,
private
registry
for
your
business,
all
the
functionality
and
features
that
you
know
and
love
and
your
developers
are
familiar
with
from
the
the
open
source
public
registry
is
used
and
shared
for
your
private
purchase
for
your
private
business
and
your
private
registry.
So
same
behavior
same
workflows.
B
It
gives
you
the
ability
to
control
access
control
and
for
your
for
your
team
and
inviting
your
teams
through
functionality
like
single
sign-on,
so
administration
tasks
become
a
little
bit
easier
and
then
the
security
features
that
we're
baking
into
it.
Allow
you
to
control
and
manage
risks
of
against
and
for
open
source
development.
B
B
Then
you
already
know
what
npm
enterprise
looks
like
npm
enterprise
sits
between
your
developer,
workflows
and
the
npm
public
registry
and
allows
you
to
do
things
like
host
your
own
private
instances
of
packages
for
your
own
team
and
your
internal
collaboration,
as
well
as
introduce
functionality
and
features
that
proxy
into
the
public
registry,
for
better
performance
and
for
better
security.
So
it
gives
you,
for
example,
the
opportunity
to
have
unlimited
private
package
publishing
to
your
own
enterprise
instance.
B
It
proxies
to
the
enterprise
to
the
public,
to
the
public
registry
for
any
sort
of
security
concerns
and
and
package
filtering,
and
we're
going
to
go
into
a
demo
about
that
in
a
second
and
gives
you
the
same
ability
to
search
and
discover
between
both
public
and
private
packages.
The
same
user
experience
that
your
developers
and
your
teams
are
used
to
without
changing
any
of
the
developer
journeys
or
the
workflows
so
from
an
earth
perspective.
B
Account
authentication
and
access
control
is
a
key
factor
in
terms
of
providing
access
to
your
code
bases
and
your
your
shared
libraries
package
filtering
and
security
policies.
We're
going
to
show
you
that
in
a
second
it
is
a
single
tenant
registry.
So
you
have
a
little
bit
of
compliance
checkpoints
in
terms
of
where
your
actual
code
is
hosted.
B
So
you
have
ability
to
even
control
that
even
further
and
then
give
you
even
earlier
access
to
vulnerability
information
before
they
become
publicly
disclosed.
B
So
we've
done
a
lot
of
talking.
Let's
show
you
some
of
this
stuff,
so
hopefully
my
screen
is
being
shared
very
clearly,
first
and
foremost
I'll
just
start
by
again
showing
you.
This
is
a
demo
instance
of
what
you
will
get
as
an
npm
enterprise
user.
As
you
can
tell,
the
interface
is
very
familiar
to
you.
This
is
almost
exactly
the
same
as
what
you
get
with
npm
js.com.
B
So
this
is
important
for
us,
because
the
developer
experience
is
paramount
for
us
to
make
sure
that
your
developers
are
actually
wanting
to
use
these
tools
and
adopting
them
as
part
of
something
they're
already
familiar
with,
as
opposed
to
trying
to
train
them
all
over
again
or
give
them
something
new.
So
I'm
going
to
go
through
the
developer
workflow
in
a
second,
but
I
want
to
show
you
a
little
bit
of
the
administrative
workflow.
B
So
as
an
administrator
of
course,
you
have
all
sort
of
controls
for
yourself
for
adding
and
removing
users
and
administrating
who
gets
access.
You
can
invite
as
many
users
as
you
want,
or
if
you're
using
single
sign-on,
you
can
provision
them
more
more
seamlessly
using
that
I'm
not
going
to
go
through
a
single
sound
on
workflow
right
now,
but
we
do
support
oauth.
We
do
support
oidc
and
we
do
support
channel
pretty
sure
you've
seen
enough
of
those.
B
So
we
don't
have
to
show
you
how
those
things
work,
but
just
know
that
it's
available
for
you,
if
you
wish
to
use
it
and
then
we're
going
to
show
you
a
little
bit
about
the
security
policy
workflows
in
a
second.
So
let's
talk
from
a
user
perspective.
How
does
this
look
as
a
user
and
as
a
developer
in
javascript,
I'm
already
familiar
with
npmjs.com?
B
B
So
as
a
developer,
my
experience
is
the
same
when
it
comes
to
discovery
and
adoption
of
packages,
I
can
do
the
same
search
I
can
show
I
can
do
in
the
public,
as
I
can
do
in
the
private
npm
instance.
For
my
business,
the
same
level
of
information
is
available,
and
then
the
interesting
part
is
when
I
want
to
start
publishing
packages
for
my
team
say
I'm
part
of
a
web
development
team,
and
I
want
to
start
publishing
packages,
or
maybe
I'm
part
of
the
save,
make
it
even
more
specific,
a
marketing
team.
B
Maybe
the
marketing
team
wants
to
start
publishing
some
widgets,
some
information
that
is
used
for
their
development
workflows
or
for
another
team
in
another
department.
This
is
where
the
again
the
same
exact
workflow
that
people
are
familiar
with
from
an
open
source.
Npmjs.Com
perspective
is
brought
in
here.
So
I
might
be
part
of
the
marketing
organization.
As
part
of
this
company,
I
have
ability
to
publish
certain
packages
publicly
and
what
publicly
means
in
this
context
is
other
people
in
the
company
can
see
it
versus.
B
I
can
publish
some
packages
private
privately,
and
what
privately
means
in
this
context
is
only
people
who
are
members
of
this
organization
get
to
see
it
again.
This
is
the
same
paradigm
that
you
get
from
the
npmjs.com
public
registry
views
in
the
context
of
your
business
starts,
giving
you
even
more
detailed
workflows
and
more
control
over
who
gets
to
access.
What
so
you
can
imagine
where
you
have
a
vendor
coming
in
that
might
need
access
to
certain
things.
B
You
can
create
a
different
group
for
that
vendor
and
start
inviting
them
selectively
to
get
access
to
certain
packages.
So
let
me
show
you
how
this
works
from
a
developer's
perspective,
there's
only
a
couple
of
steps.
The
developer
has
to
do
to
update
their
already
existent
cli,
tooling
and
already
existing
any
tooling.
That
has
to
do
with
npm,
like
ci
or
cd
environments,.
B
So
here
I
have
an
npm
cli,
nothing
out
of
the
ordinary
here,
I'm
actually
a
couple
of
versions
behind
the
instructions
are
available
for
me
on
the
home
page.
So
I'm
just
gonna
do
a
bit
of
a
split
screen
here.
So
as
a
developer,
when
I'm
invited
to
this
instance
for
my
company's
npm
registry,
I'm
going
to
come
in
I'm
going
to
be
immediately
presented
with
the
information.
How
do
I
configure
my
default
registry?
Well,
first
thing:
I
need
to
install
node
and
npm.
I
have
that
check.
B
I
need
to
run
the
following
command
to
tell
my
npm
clients
to
point
at
this
registry
as
the
default,
and
that's
it
it's
done.
What
this
actually
creates
is
an
entry
in
in
the
users
and
tmcr
and
pmrc
file,
and
now
you're
going
to
see
my
private
token
for
a
second
there
you
go.
I
have
to
reset
that
later.
B
Where
that
register
url
is
set
up
the
for
publishing
workflows,
it's
a
little
bit
more
advanced.
You
have
to
actually
go
and
declare
which
scope
you
want
to
publish
into
so
I've
already
been
invited
to
a
couple
of
organizations
here.
So
this
could
be
your
marketing
team,
your
backend
team,
your
front,
end
team,
you
know
whatever
team,
you
want
to
name
it
or
whatever
scope
you
want
to
organize
it
under.
Let's
say
I
want
to
publish
as
a
marketing
team.
B
All
I'm
doing
is
I'm
telling
the
npmcli
to
publish
to
this
url
now
what
this
is
going
to
do
when
I
hit
enter
it's
going
to
actually
go
and
create
a
token
on
the
actual
registered
website
and
you're
going
to
see
it
here
in
a
second
there
you
go,
it
automatically
opened
up
the
browser
page.
It's
prompting
me
to
enter
my
password,
which
is
I'm
not
going
to
tell
you,
but
you
do
have
my
token
now.
B
I
do
have
to
reset
that
the
interesting
thing
about
tokens
in
the
npm
cli
contacts
as
well
for
user
context.
You
can
set
the
access
level
right
here
and
there.
So
if
this
is
something
you
want
to
set
up
for
your
ci
environment,
you
can
make
sure
that
this
token
is
read
only
you
may
not
want
it
to
publish
in
this
instance.
I
want
to
do
both.
B
Great,
so
this
is
again
very
simple,
very
basic,
very
close
to
the
developer
workflow
that
you're
all
familiar
with.
Let's
talk
about
the
interesting
feature
that
we
just
introduced
recently,
which
is
the
under
administration,
your
admins
are
now
able
to
create
a
security
policy
for
how
packages
are
used
now,
you're
familiar
with
public
vulnerabilities,
you're,
familiar
with
challenges
around
disclosures
of
information
and
data
leakage.
A
B
Vulnerabilities
for
your
servers,
but
how
do
you
protect
against
that?
So?
We've
introduced
this
feature
called
security
policy.
So,
as
an
administrator
for
this
company,
you
can
go
in
and
decide
to
have
a
block
level
of
anything
that
is
critical
or
anything
that's
vulnerable
to
block
everything.
So
in
a
critical
level
vulnerability,
it
means
that
your
developer
is
gonna,
go
through
a
workflow
like
this,
where
they're
gonna
run
npm
install
it's
gonna
download
all
the
package.
This
is
all
going
through
the
same
registry
that
I
just
set
up
for
you.
B
The
developers
will
see
things
like
this
or
it
says.
Well,
there
are
some
vulnerabilities
here.
You
need
to
use
them
and
again
they
can
use
the
power
of
audit
fix,
which
automatically
goes
in
and
takes
care
of
a
lot
of
that
effectively.
What
happened
here
is
the
vulnerability
was
under
package.json.
I
had
a
version
of
lowdash
that
wasn't
desirable
and
an
npm
audit
fix
just
updated
it
to
a
fixed
version.
B
B
So,
as
you
see,
you
can
run
npm
audit
and
it
will
tell
you
that
there
are
vulnerabilities
or,
as
part
of
your
install
step,
you
get
the
same
interval
information.
So
in
this
case
a
bit
zoomed
in
the
vulnerability
was
in
low
dash
and
something
that
is
probably
need
to
be
addressed,
but
this
developer
shows
up
to
address
it
and
continue
on
with
their
life.
B
Now
you
as
an
administrator,
you
can
come
in
and
say
block
all
these
vulnerabilities
and
then
introduce
a
very
friendly
message,
hopefully
or
something
along
the
lines
of
talk
to
john
and
security,
to
actually
help
educate
your
developers
about
the
challenges
that
they
might
be
facing
when
they're
selling
unsecured
packages.
So
let's
see
how
this
actually
works.
B
So
you
get
the
message:
tell
them
check
in
with
their
enterprise
admin
or
their
their
security
team
or
whatever
information
you
provided
in
that
message,
so
we'll
force
them
to
make
sure
that
they
actually
go
in
and
and
be
more
diligent
about
their
security
and
their
and
their
dependencies
that
they're
installing
for
the
public
registry.
Again,
the
message
they
will
get
is
just
talk
to
john
security
or
whatever
you
present
to
them
here
in
a
meaningful
way.
Probably
you
want
to
give
them
something
more
meaningful
like
this
is
violating
our
security
policy.
B
Please
review
our
internal
docs
and
then
perhaps
you
can
provide
a
link
to
your
internal
docs
for
security
kind
of
compliance.
So
this
is
where
we
can
start
introducing
more
features
in
the
in
the
future
around
allow
lists
and
block
lists
they're
going
to
start
having
the
ability
to
actually
selectively
pick
which
packages
and
which
versions
of
which
packages
you
might
want
to
allow
this
allows
in
your
organization.
You
can
imagine
where
you
can
have
this
goes.
B
B
So
that
concludes
our
quick
kind
of
demo
of
the
story
today,
but
just
to
recap:
real,
quick,
the
functionality
that
we're
talking
about
here
in
terms
of
helping
you
reduce
the
risk
of
your
organization
being
able
to
filter
which
packages
you
want
to
allow
for
your
developers
to
use
what
level
of
vulnerabilities
you
want
to
block
and
allow
being
able
to
control
the
tokens
and
the
the
access
control
for
each
user
within
your
organization.
You
can
do
that
through
organizations
and
teams
within
npm.
B
This
is
again
the
same
functionality
you
get
from
the
public
registry,
but
you
can
now
apply
it
to
your
team
structures,
your
organization
structure,
control,
which
vendor
gets
access
to
what
code
and
what
applications
you
can
use.
The
fact
that
this
is
a
single
sentence,
hosted
registry,
which
means
from
a
compliance
point
of
view
and
then
other
building,
point
of
view.
Your
code
is
not
being
shared
in
the
public
cloud
anywhere
and
then
obviously
getting
the
power
of
single
financial
authentication
with
office
or
saml
for
your
organization
for
provisioning.
B
Hundreds
of
developers,
if
you
so
choose
we're,
also
doing
something
interesting
around
your
organization's
usage
of
public
and
open
source
packages.
We're
calling
this
the
enterprise
vulnerability
report.
It
is
currently
in
beta
what
this
gives.
You
is
a
little
bit
more
visibility
into
what's
happening
across
your
entire
company
again,
whether
or
not
you're
using
the
enterprise
or
using
public
registry
or
have
accounts
on
it.
B
We
can
give
you
a
little
bit
more
insight
to
what
your
teams
are
doing
and
what
your
company
is
building
in
terms
of
workflows
and
what
packages
from
the
public
registry
are
coming
into
behind
your
firewall
and
into
your
developer
laptops
and
into
your
production
servers.
So,
if
you're
interested
with
that,
please
check
npmjs.com
and
get
a
little
bit
more
insight
into
that.
B
And
what
I'm
going
to
do,
I'm
going
to
go
through
a
bunch
of
the
questions
that
were
asked
and
first
question:
is
there
a
way
to
see
what
vulnerable
packages
I'm
using
and
my
team?
So
that's
what
I
was
alluding
to
in
the
enterprise
vulnerability
report
currently
is
in
beta,
but
that
will
be
a
feature
that
we're
going
to
be
introducing
into
the
npm
enterprise
products.
So
it
becomes
as
part
of
that
workflow
that
you're
designing
what
you
want
to
block
what
you
want
to
enable.
B
Then
you
get
reports
on
what
has
been
blocked
and
or,
if
you're,
not
blocking
everything
what
people
are
adopting
and
using
in
their
day-to-day
there's
a
question
about
how
do
packages
in
the
public
registry
get
classified
as
vulnerable?
I
believe
there's
a
there's,
a
there's,
a
link
that
I
don't
have
it
handy
on
me
right
now.
B
But
if
you
go
and
look
at
our
documentation
around
the
security
and
vulnerabilities,
there's
a
whole
workflow
and
process
around
that
there's
a
number
of
areas
that
we
do,
our
own
research
and
there's
a
number
of
places
where
developers
in
the
open
source
community
contribute
their
own
findings
and
report
vulnerabilities
to
us.
We
maintain
a
central
list
of
what's
what's
been
disclosed
and
what's
about
to
be
disclosed
and.
A
B
Another
question
is:
how
do
no?
I
already
read
that
question
what,
if
we're
already
using
a
different
product
for
artifact
storage
and
data
publishing.
So
again,
you
can
all
the
products
that
you
probably
rely
on
or
use
today
in
terms
of
storing
your
artifacts
and
or
publishing
artifacts
for
centralized
location,
no
matter
what
the
product
is
at
some
point
or
some
shape
or
form
your
developers
are
either
using
npm
public
registry
and
or
those
products
themselves
are
still
proxying
back
to
the
public
registry.
B
So
the
workflow
that
we're
exposing
for
you
here
and
the
work,
the
the
value
that
you're
getting
from
controlling
those
workflows,
doesn't
take
away
from
your
ability
to
store
things
in
a
different
place
or
have
a
different
kind
of
workflow
somewhere
else.
So
I
wouldn't
say
that
it's
one
or
the
other.
You
definitely
get
more
of
the
package
when
you
get
going
through
the
npm
enterprise
product,
you
get
everything
from
artifact
storage,
all
the
way
to
workflow
design
and
some
of
the
features
that
we're
going
to
start
implementing
around
reporting
and
all
that.
B
A
Packages
great,
thank
you
ahmad,
as
mentioned
earlier,
today's
webinar
will
be
available
on
demand
after
the
live
session
and
is
successful
through
the
same
link
you're
using
now,
we've
also
added
some
related
materials
which
are
available
through
the
attach
attachment
tab
at
the
bottom
of
your
player.
This
is
where
you
can
find
today's
slides,
add
your
name
to
the
waitlist
for
enterprise,
vulnerable
reporting
and
other
related
material.