►
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
to
everyone
watching
this
video,
my
name
is
Adam
and
I'm.
A
back-end
engineer
on
the
secure
team
in
this
video
I'm
gonna
give
a
brief
demonstration
of
using
dependency
scanning
to
analyze
a
JavaScript
project
in
an
air-gapped
environment,
which
is
a
feature
added
and
released
12.9
before
starting
I'm
going
to
assume
that
we
have
a
working
internet
connection
so
that
we
can
download
all
the
required
files
to
our
local
environment.
A
working
internet
connection
is
only
required
for
the
initial
setup
once
all
the
necessary
files
have
been
downloaded
and
we've
configured
our
CI
environment.
A
We
can
disable
our
internet
connection
and
run
a
dependency
scan
in
an
offline
environment.
I'll
also
assume
that
the
internal
gate,
lab
instance,
has
been
configured
with
an
internally
accessible,
donker
container
registry.
So
we'll
start
off
by
creating
a
new
project
on
our
internal
gate,
lab
instance.
A
A
Now
that
the
project
has
been
imported
successfully,
you'll
notice
that
it
consists
of
four
files
in
a
directory.
The
package
JSON
and
yarn
lock
files
provide
a
minimal
set
of
files
needed
to
run
a
JavaScript
dependency.
Skin.The
j/s
repository
Jason
and
NPM
repository
JSON
files
contain
the
vulnerability
data
for
the
retired
j/s
scanner.
These
files
can
also
be
hosted
on
an
internal
web
server,
but
will
include
them
directly
in
the
repository
to
make
the
process
easier.
A
The
node
modules
directory
was
added
to
simplify
the
configuration
process
in
a
normal
air
gapped
environment.
It
would
be
necessary
to
set
up
a
private
NPM
registry,
but
we
can
just
add
the
node
modules
directory
to
our
repository
to
avoid
doing
this.
Now
that
we
have
our
skeleton
JavaScript
project,
we
can
start
downloading
all
of
the
required
files
needed
for
running
in
offline
mode.
A
A
A
However,
this
will
be
different,
depending
on
your
configuration
to
make
things
easier,
we'll
use
the
same
tags
used
by
the
remote
images.
The
tag
of
the
image
is
the
part
after
the
colon,
for
example,
for
the
dependency
scanning
container.
The
name
of
the
image
is
on
the
left
side
of
the
colon,
and
the
tag
is
on
the
right
side
of
the
colon
and
in
this
case
the
values
too.
A
A
Now
that
we
have
all
of
the
required
dose
tada
our
internal
docker
registry,
we
can
begin
configuring,
our
CI
environment.
In
order
to
do
that,
we
need
to
pay
special
attention
to
one
of
the
docker
containers
we
downloaded,
which
was
the
git
lab
runner
helper.
This
is
a
custom,
get
lab
specific
container
which
handles
get
artifacts
and
other
operations
and
is
required
for
our
local
git
lab
instance.
To
funk
properly,
we
need
to
edit
our
gitlab
docker
run
or
configuration
file
to
reference
this
helper.
A
A
First,
we'll
include
the
dependency
scanning
template
next,
we'll
override
some
of
the
variables
and
directives
from
the
dependency
scanning
template
to
reference.
Our
internally
hosted
files
and
docker
containers.
This
custom
image
value
will
override
the
docker
image
to
point
to
our
locally
hosted
image.
A
Notice
that
we've,
given
this
image
and
explicit
alias
value
this
is
necessary
because
the
dependency
scanning
template
expects
that
the
darker
and
darker
service
will
be
accessible
on
the
docker
host
name.
Now
that
we've
set
up
the
custom
image
and
service
values
it's
time
to
override
some
of
the
dependency
scanning
template
variables,.
A
We
need
to
set
the
SP
version
to
the
same
tag
that
we
use
for
our
locally
hosted,
docker
images,
if
you
recall
back
to
when
we
tagged
our
images,
we
use
two
as
the
tag
value,
so
this
SP
version
needs
to
be
the
same
as
this
value
we
used
here
next,
we'll
override
the
retire
j/s
advisory,
DB
and
retire.
Je
s
note
advisory,
DB
variables
to
point
to
the
locally
accessible
vulnerability
files.
These
files
were
downloaded
from
the
retired
je
s
repository
if
we
browse
a
retired,
je
s
source
and
navigate
to
the
repository
directory.
A
Next,
we
need
to
override
the
security
scanner
image
prefix
variable
to
point
to
our
internally
accessible
docker
container
registry
and
finally,
we
need
to
configure
the
gymnasium
DB
remote
URL
to
point
to
the
locally
accessible
URL
for
the
gymnasium
DB.
If
you
recall,
we
imported
the
gymnasium
DB
project
to
our
local
git
lab
instance.
So
now
we
can
click
on
the
clone
button
and
copy
the
URL
for
the
repository,
which
we
can
then
paste
here
now
that
all
of
the
required
variables
and
configuration
directives
have
been
overridden.
A
If
we
scroll
further
down
we'll
see
that
the
retired
yes
analyzer
recognize
that
we've
overwritten
the
Advisory
DB
and
node
Advisory
DB
environment
variables
and
uses
the
locally
accessible
versions
of
these
files,
instead
of
fetching
them
from
the
Internet.
If
we
scroll
to
the
bottom,
we
can
see
that
the
dependency
scanning
job
has
completed
successfully.