►
From YouTube: Using GitLab to Deploy a .NET Application on AWS
Description
Table of Contents:
00:00 - Introduction & Agenda
01:20 - DevOps
02:39 - AWS Development Tooling
06:00 - Demo: .NET App to Elastic Beanstalk
14:09 - Why Use Beanstalk?
16:17 - .NET on AWS
18:55 - GitLab for All of DevOps and GitOps
21:11 - 109 Monthly Releases of GitLab
21:52 - Integrate Your Tools with GitLab
22:30 - Fully Automated Vulnerability Management
23:10 - GitLab Rich Change Controls for Workflow
28:28 - GitLab AWS Integrations
29:56 - Vulnerability Remediation Habit
36:02 - Demo: Zero Effort Review Environments
37:57 - Demo: Feature Branch Findings Delta
41:20 - Demo: Lean Security Oversight
42:26 - Demo: Collaboration On Individual Vulns
46:42 - Prefabricated CI / CD in GitLab
47:40 - Demo: EKS on the Backend
49:30 - High Context = Security Engagement
52:34 - Shifting Remediation Responsibility with Motivation: Full Context is King
52:35 - Resources to Explore
52:36 - All-in-one DevOps Meets all-in-one Cloud
53:12 - Wrap up and Social Links
- GitLab and AWS (https://youtube.com/playlist?list=PL05JrBw4t0Ko30Bkf8bAvR-8E441Fy2G9)
- GitLab Alliances Tech (https://youtube.com/playlist?list=PL05JrBw4t0KqaWCrU4avIY6TQveKTDMso)
- DarwinTheorizes at GitLab (https://youtube.com/playlist?list=PL05JrBw4t0KoH74CcAtP0Ze7JXjX7zT6g)
A
B
Hey
it's
great
to
be
here
with
ahmet.
My
name
is
darwin
sonoy,
I'm
a
senior
solutions
architect
for
git
lab
today
we're
going
to
be
taking
a
look
at
better
together
using
gitlab
to
develop
and
deploy
apps
onto
aws.
We're
going
to
take
you
through
several
different
topics
here.
So
we'll
cover
a
quick
agenda
to
get
you
oriented,
we'll
lead
off
with
a
devops
primer
by
amit
he'll.
Take
us
through
some
of
the
core
principles
of
devops.
B
Then
he'll
drop
into
some
aws
development
tools,
information
about
all
the
different
kinds
of
development
tools
that
are
available
to
develop
for
aws,
then,
finally,
he's
going
to
do
a
demo
of
deploying
a.net
web
app
into
aws
using
kit
lab
after
that
I'll
pick
it
up
with
some
information
about
gitlab's,
rich
git,
ops,
controls
and
security
scanning.
A
value
add
that
gitlab
adds
to
this
development
process.
B
Then
we'll
also
have
a
demonstration
on
fostering
the
continuous
remediation
habit
in
the
developers
daily
workflow.
Finally,
we'll
have
some
additional
resources.
Ebooks
links,
repositories
that
you
can
use
in
order
to
get
started
on
this
journey
so
ahmet.
Why
don't
you
take
it
away
and
give
us
your
devops
primer.
A
A
If
you
have
to
get
so
your
software
into
millions
of
into
the
hands
of
millions
of
developers,
it's
just
a
download
away
and
here's
one
thing
that
I'm
depicting
here
on
the
left.
You
have
engineering,
think
of
it
like
the
sdes
and
s
dates
on
this
side
and,
on
the
right
hand,
side.
It's
the
customer.
A
A
A
Let
me
just
go
over
a
couple
of
highlights
on
the
top
left
the
ci
cd
tools
ci
as
in
continuous
integration
cd,
as
in
continuous
deployment,
our
purpose-built
solution,
services
for
ci
cd
on
aws,
including
integrations
with
our
compute
services,
to
name
a
few
ec2
elastic
bean
stock,
lambda
containers
towards
it.
Its
right
is
our
infrastructure
as
code
solutions
that
allow
you
to
define
your
applications
and
architectures
in
code
in
ways
that
make
entire
organization
more
productive.
A
A
A
So,
to
give
an
example,
let's
say
instead
of
aws
code
build
you
want
to
use
jenkins
voila
integrate
with
it.
Let's
say
as
part
of
your
ci
cd.
You
want
to
do
performance
testing
and
you
want
to
use
let's
say
blaze,
meter
voila,
we
integrate
with
it.
So
it's
a
plug
and
play
model.
You
do
not
have
to
use
all
the
aws
codes
with
services.
Depending
on
what
your
enterprise
organization
uses.
You
can
integrate
different
partner
tools
with
aws
code
suite
services,
and
that
brings
me
to
our
partner
gitlab.
A
A
Okay,
before
I
go
into
ci
cd
pipeline
based
demo,
I
just
wanted
to
quickly
highlight
a
visual
studio.
Aws
toolkit
feature
right
inside
visual
studio.
Once
you
have
the
aws
toolkit
for
visual
studio
installed,
we
give
you
ability
to
right
click
and
deploy
application
onto
beanstalk,
ecs
lambda,
and
here
I'm
quickly
going
through
creating
a
new
bean
stock
environment.
A
A
A
Okay,
so
the
same
application
is
now
deployed.
As
you
can
see,
it
has
successfully
deployed
and
launched.
So
if
I
hit
that
url,
I
see
the
same
message:
aws
and
gitlab
better
together,
we
need
to
stress
on
this
message.
As
you
can
see,
I
mean
visual
studio.
Toolkit
has
a
pretty
neat
integration
where
you
can
see.
What's
happening
under
underlying
resource,
I
can
see
the
the
monitoring
information
I
can
integrate
with
x-ray,
which
can
give
us
correlation
and
traceability.
A
Now,
let's
go
into
gitlab
ci
cd,
goodness
I'm
going
to
show
you
via
gitlab.com
gitlab,
ci
cd
is
configured
by
a
file
called
dot,
gitlab
dash,
ci,
dot,
yaml,
and
this
file
creates
a
pipeline
which
runs
for
changes
to
the
code
in
repository
I
think
of
pipeline
as
set
of
stages,
and
each
stage
has
set
off
jobs
or
scripts
who
runs
those
it's
basically
gitlab
runner
agent.
So
you
have
the
agent
configuration
agents
can
be
specific
or
it
can
be
shared.
A
A
Demo,
okay,
so
here
I
am
on
gitlab.com
I
mean.
Usually
when
you
start,
you
start
with
a
new
project.
You
specify
the
project
name,
visibility,
level.
You
could
actually
create
a
project
from
the
templates
and
gitlab
provides
you
a
good
amount
of
templates
to
get
started
pretty
quickly.
So
that's
what
I
did.
I
took
a
net
core
template
and
got
my
first
repo
created
here
is
my
gitlab
ci
yaml.
In
this
case,
if
you
see
it
has
two
stages
and
each
stage
has
two
commands
dotnetbuild.net
test.
A
A
Okay,
so
it
looks
like
it's
finished,
build
and
test
stage.
Let's
see
what
happened
so
build
it
actually
printed
the
message
and
then
did
the
dotnet
build
right,
succeeded
it
uploaded
the
artifact
that
could
be
downloaded
test
again,
the
same
thing
it
executed
and
did
the
test.
So
can
I
download
that
pipeline
artifact
yeah?
So
as
part
of
the
pipeline,
you
get
the
ability
to
download
the
artifact
and
I
did
download
the
output
here.
Is
the
output
of
this
now?
Let's
see
second
one.
A
Okay,
so
now
we'll
see
a
project
where
we
connect
git
lab
with
aws.
So
here
is
a
sample
pipeline
in
this
case,
I'm
using
python
image
and
this
pipeline
has
three
stages,
build
test
and
deploy,
and
if
you
see
a
build,
I'm
creating
a
file
and
and
kind
of
printing
that
file.
The
content
of
the
file
is
coming
from
a
variable
options,
creating
an
artifact
so
that
this
can
be
downloaded
once
the
pipeline
finishes
and
then
in
the
test
stage.
A
A
Specified
for
s3
bucket-
and
in
this
case
I
have
specified
a
bucket
git
lab
runner.
So
what
I'll
do
is
I'll?
Just
show
you
the
last
run
for
this
pipeline.
Here
is
the
pipeline
that
I
ran
and
if
you
see
the
deploy
stage
here
is
the
command
configured
upload
and,
let's
just
see
the
gitlab
integrate
2020
onto
my
aws
account
here
is
the
folder,
and
here
is
the
file
okay,
so
we
saw
a
sample
pipeline.
A
The
glue
is
dot,
gitlab,
ci,
dot,
yaml
right
it
has
different
stages.
Each
stage
has
a
different
set
of
jobs.
Each
job
is
a
kind
of
a
set
of
script
and
that
gets
executed
by
gitlab
runner
right
here
is
a
sample
that
we
just
ran
through
the
glue
is
the
variables
the
access,
key
and
secret
access
key
that
connects
to
the
aws
account
and
then
running
the
cli
command.
A
Now,
let's
see
how
we
can
do
an
end
to
end
app
deployment,
asp.net
mvc,
core
application
onto
aws
elastic
bean
stock
right
here,
I'm
just
quickly
referring
the
commands
that
I'll
be
using
here
is
aws.
Elastic
beanstalk
create
application
version,
specify
the
name
of
application
version
source
bundle.
This
is
the
key,
and
this
is
where
the
marriage
will
happen
between
the
s3
bucket,
where
we
will
have
the
artifacts
produced
as
part
of
the
ci
cd
and
the
elastic
bean
stock
application
right.
A
A
I
want
to
just
quickly
run
it
to
show
you
what
actually
this
this
application
is
very
simple,
asp.net
mvc
code
based
app,
which
has
a
message,
aws
and
gitlab,
better
together,
absolutely
agree
with
it,
and
once
we
have
the
pipeline,
let's
quickly
see
the
pipeline
three
stages,
build
is
filled
test.
I
mean
tests
are
right.
Now
it's
very
light
I
mean.
Obviously
you
would.
You
would
do
a
good
amount
of
unit
testing
system
testing
integration
testing
as
part
of
your
pipeline
for
this
demo.
A
A
Let's
see
the
publish,
because
that's
where
the
meat
of
the
information
is
so
here
is
the
upload
and
that
upload
succeeded
right,
and
this
is
calling
the
elastic
beanstalk
application
version
that
created
and
here's
the
response
of
that
api
call
and
then
updating
the
environment
with
the
latest
version
right.
So
it
succeeded
there.
So,
let's
go
ahead
on
to
aws
and
see
my
application
here
is
my
gitlab
sample
webgitlab
demo-
and
here
is
my
url:
that's
the
application,
gitlab
and
aws
better
together.
B
A
Yeah
elastic
bean
stock,
why
did
I
use
in
my
demo
another
service?
I
know
there
is
so
many
services
elastic
bean
stock
to
start
with
it's
it's
a
fully
managed
service
for
hosting
web
applications
and
services.
It
is.
It
is
kind
of
a
very
good
starter
service.
It
gives
you
a
near
pass-like
experience.
I
may
actually
go
on
saying
that
elastic
beanstalk
has
been
doing
for
last
10
years.
What
containers
have
tried
to
do
recently?
What
do
I
mean
by
that?
I
mean
it,
gives
you
a
near
pass
like
experience.
A
It
gives
you
automated
app
deployments.
It
gives
you
automated
platform
updates.
It
gives
you
automated
app
health
monitoring.
You
see
the
undifferentiated
heavy
lifting
that
you
would
have
to
do
if
you
are
let's
say
easy
to
based
hosting
the
applications
it
goes
away.
It
gives
you
by
default.
All
you
have
to
do
is
deploy
the
application
to
beanstalk
and
it
takes
gives
you
out
of
the
box
dashboard
traffic
engineering,
taking
care
of
spawning
the
underlying
resources,
so
good
amount
of
undifferentiated
heavy
lifting
work
is
done
for
you.
A
Hence
I
recommend
customers
to
start
with
elastic
bean
stock
and
from
there
you
can
actually
see
different
paths
to
modernization,
be
it
re-platforming
from
windows
to
linux,
be
it
creating
an
end-to-end,
ci
cd
flow
with
either
our
container
stack
or
integrating
with
our
ci
cd
tool
sets
or
partners
or
modern
modernize.
Your
existing
workload
and
towards
containers
containerize
the
application
and
beanstalk
pretty
much
have
has
integration
end
to
end.
B
A
A
A
We
also
integrate
with
other
ides,
like
visuals
visual
studio
code,
jetbrains
writer.
We
have
programmable
sdk
dot
net
framework
based
as
well
as
dot
net
core.
We
have
aws
cdk4.net,
I
personally
don't
like
templating.
I
would
rather
write
c
sharp
code
that
generates
the
templates.
Aws
ctk
comes
handy
for
the
same.
We
integrate
with
several
ci
cd
services,
aws
code,
suite
services
and
partners
like
gitlab,
any
customer
looking
to
migrate
and
modernize
their
legacy.net
based
applications.
We
provide
tools
like
app
to
container
to
containerize
the.net
applications
onto
aws.
A
We
provide
tools
like
portingassistantfor.net
to
analyze
their
legacy.net
framework
based
applications
and
understand
the
level
of
effort.
It
would
be
to
actually
import
it.
To.Net
core,
hey
darwin,
I'm
familiar
with
gitlab
as
a
source
code
management
solution,
but
I've
been
hearing
a
lot
about
how
it
helps
with
the
entire
devops
life
cycle
like
end
to
end
as
dlc
management.
B
That's
a
great
question:
let's
dig
in
a
little
bit
to
that.
So,
as
we
all
know,
the
beginning
of
devops
was
the
idea
of
a
methodology
that
would
automate
things
from
end
to
end,
so
the
concepts
of
agile
could
be
embraced
by
the
entire
cycle
of
development
and
operations,
and
that
that
feedback
cycle
of
agile
that
normally
happens
inside
of
iterations
now
starts
to
happen
all
the
way
back
from
production
and
we
get
a
smooth
flow.
Now.
B
When
this
methodology
first
came
out,
there
wasn't
products
or
tools
that
tried
to
address
the
entire
realm
of
devops.
Basically,
we
took
a
lot
of
tooling
and
knitted
it
together,
so
that
it
could
work
together
and
we
could
create
this
new
way
of
approaching
our
technology
and
our
application
and
development
life
cycle.
So
some
of
the
challenges
that
have
come
up
over
time
is
that
all
of
this
tooling
tends
to
be
knit
together
by
some
fragile
automation.
B
We
have
multiple
user
databases
in
each
of
these
tools,
so
the
the
password
management
and
security
management
becomes
challenging.
There's
risk
involved
because
we
have
a
lot
of
different
stacks
that
need
to
be
patched
and
maintained,
and
we
have
a
hard
time
getting
a
global
view
of
what's
going
on
in
the
system.
So
one
of
the
things
that
gitlab
has
added
on
to
source
code
management
is
really
a
full
devops
single
application
that
provides
for
all
the
different
aspects
of
devops.
B
Now,
of
course,
that
starts
with
source
code
management
and
that's
how
gitlab
got
into
this
space.
But
the
essential
idea
behind
this
is
that
we
no
longer
need
to
have
all
of
these
individual
systems
having
different
data
storage
mechanisms,
different
user
interfaces,
different
security
definitions,
different
patching
cycles,
and
so
we
can
get
a
much
more
global
view
of
what's
going
on
in
the
system
as
well
as
manage
it
more
securely
and
manage
it
better.
B
Interestingly,
if
you
think
about
like
formula
one
race
drivers,
they
could
be
their
own
mechanic
and
maintain
their
own
car
if
they
wanted
to.
But
it's
actually
better,
you
know
to
have
them
specialize
in
what
they
do
best
race,
the
car,
while
the
actual
car
itself
is
maintained
by
someone
else,
and
so
in
a
way.
B
So
I'd
like
to
dig
a
little
bit
deeper
into
the
history
of
gitlab's
feature
development.
One
of
the
interesting
things
that
we
share
with
amazon
is
a
strong
desire
to
have
continuous
feature
releases
at
a
cloud
scale.
So
over
the
last
five
or
six
years,
gitlab
has
added
entire
stages
of
product
capability.
B
Then
we
continuously
improve
that
capability
as
time
goes
forward,
so
new
functionality
is
being
added
to
all
of
these
areas
as
time
goes
forward.
So
we
kind
of
follow
in
the
footsteps
of
amazon's
example
in
that
regard,
and
when
you
invest
in
gitlab
you're.
Investing
in
a
strong
future
of
additional
features,
as
time
goes
on,
just
want
to
cover
something
else:
that's
really
important
to
most
customers,
and
that
is
integrations
migrations
and
consolidating,
so
gitlab
provides
out-of-the-box
functionality
for
all
the
major
devops
stages.
However,
we
completely
understand
that
organizations
have
complicated
needs
historical
systems.
B
They
have
to
move
slowly
when
migrating,
and
so
because
of
that
we
integrate
with
a
lot
of
products
that
integration
also
facilitates
migration
to
gitlab
over
time
to
consolidate
cost.
But
we
recognize
there's
a
lot
of
situations
where
you
might
need
to
keep
existing
tooling.
Gitlab
is
really
strong
in
this
area.
B
B
Git
lab
has
not
only
taken
what
capabilities
it
had
in
this
area
in
terms
of
workflow
controls,
but
it
also
has
had
to
enhance
them
as
customers
say:
hey,
you
know
what
we
need
to
do
deployments
in
this
way.
We
needed
deployments
in
that
way:
hey
the
concept
of
environments
which
isn't
really
something
in
normal
git
and
scm.
We
need
that
concept
to
be
built
in
and
preserved
throughout
the
entire
system.
The
interesting
thing
about
it
is
that
also
flows
right
over
into
source
code
management.
B
So
these
enhanced
controls
start
to
give
you
additional
controls
for
the
normal
use
of
source
code
management.
So
we'll
look
here
at
some
of
the
workflow
controls
you
have.
We
also
have
the
whole
collaborative
piece.
There's
lots
of
features
in
gitlab
for
the
actual
collaboration
around
code,
but
we'll
just
talk
mostly
about
the
gating
controls.
So
you
get
a
view
of
the
richness
of
the
scm
that
gitlab
is
in
development.
B
We
have
our
feature
branches
coming
into
the
system
and,
of
course,
we're
going
to
eventually
get
into
that
integration
branch
there
now
git
lab
has
some
standard,
git
type
of
controls.
One
of
them
is
push
rules.
Another
one,
that's
kind
of
interesting
with
git
lab
is
verified,
committers
and
signed
commits
so
between
these
two.
You
can
make
sure
that
developers
locally
sign
their
commits
or
they
won't
be
accepted
and
that
the
identity
information
inside
the
commit
matches
the
user
id
with
which
they
try
to
push
the
commits.
B
So
you
essentially
get
assurance
right
back
to
the
developers
workstation
that
they
indeed
were
the
ones
who
authored
that
code
and
it's
not
been
messed
with,
since
it
was
committed
so
sort
of
a
full
authorship
guarantee.
We
also
have
locked
files
and
directories,
then
within
gitlab,
cicd
is
used
for
checks
for
merge
requests.
So
it's
triggered
right
away
because
we're
not
waiting
to
create
a
build.
We
might
want
to
do
a
bunch
of
checks
and
find
out.
B
When
we
run
this,
though,
we
have
the
capability
to
stand
up,
dynamic
review
environments
on
every
developer
branch,
and
what
this
lets
us
do
is
a
lot
of
additional
testing.
Specifically,
we
can
now
do
dynamic
or
dashed
security
testing
on
every
commit
to
every
feature
branch
and
create
that
little
review
environment.
So
this
is
pretty
interesting
capability
that
opens
up
a
lot
more
checks
that
we
can
do
on
our
application
and
das,
being
you
know
a
core
one,
then,
when
we
go
to
merge
our
branches,
we
have
a
bunch
of
additional
controls.
B
One
of
those
controls
in
the
code
review
kind
of
stage
is
the
ability
to
have
branch
protections
as
well
as
tag-based
protections,
and
also
merge
approvals
for
that
kind
of
capability.
Now
merge
approvals,
the
the
little
tags
here
are
showing
the
addition
of
git
lab.
You
need
merge
approvals
in
the
in
the
starter
edition
of
git
lab
are
one
set
of
merge
approvals
for
all
branches.
B
Then
we
can
also
have
ci
cd
hooked
up
to
this
branch
and
also
have
a
different
environment
attached
to
it
and
also
do
all
kinds
of
checks
that
we
need
to.
So
this
is
a
weight
for
developers
on
their
everyday
branch
before
they
merge
to
a
shared
branch,
really
do
as
much
assurance
and
fixes
as
possible
and
then
move
that
forward
into
shared
branch.
B
B
One
is
called
auto
devops,
which
demonstrates
some
of
these
capabilities,
but
you
can
really
build
pipelines
to
do
any
kind
of
deployment
you
want
just
as
long
as
you
use
a
few
simple
variables
and
the
data
inside
the
system
in
order
to
build
that
pipeline
out
now,
as
we
move
forward,
git
ops
has
the
idea
that
when
we
move
to
environments
we
use
merges
to
branches
in
order
to
deploy
to
an
environment.
So
we
don't
just
use
code
branches
for
actually
getting
our
code
ready.
B
We
also
use
it
for
deployments,
and
in
this
case
these
merge
approval
gates
can
also
be
used
for
deployment.
Now
in
the
premium
and
up
versions
of
the
products,
we
have
the
capability
that
you
can
define
multiple
merge
approval
rules
for
different
branches,
so
each
branch
can
have
a
different
set
of
merge
approvals.
B
B
Here
that
I've
just
depicted
a
small
sampling
of
the
various
aws
services
that
we
can
deploy
to,
you
can
see
lambda
aws,
amplify
kubernetes,
ecs
elastic
bean
stock,
which
we
saw
and
also
code
deploy
and
code
deploy,
is
a
gateway
to
a
lot
of
other
amazon
services.
Gitlab
can
deploy
natively
to
some
of
these
solutions,
such
as
eks,
ecs
and
recently
ec2
using
code
deploy
any
other
aws
solution.
B
We
can
also
integrate
with
simply
by
using
the
command
line
interface
for
that
service
and
triggering
its
deployments
and
in
the
case
of
amplify
git
lab
is
one
of
the
scm
providers
listed
on
the
deployment
capabilities
of
amplify.
So
we
have
a
lot
of
integrations
to
getting
to
amazon
services
and
it's
improving
more
and
more
every
day
and
then
in
a
typical
git
ops
or
what
we
call
git
lab
flow.
B
We
would
continue
this
cycle
for
as
many
as
environments
as
we
wanted
to
use
to
assure
that
our
software
deployment
is
going
to
go
smoothly
until
we
eventually
get
to
production,
so
this
is
kind
of
a
view
into
how
rich
this
has
become
inside
of
git
lab.
It's.
You
know
much
more
than
source
control
management.
It's
really
entire
devops
environment
management
as
well.
A
B
B
So
if
you
think
of
a
developer
in
their
average
daily
workflow
they're
going
to
create
some
sort
of
code
change
and
update
the
shared
repository
and
in
most
organizations,
this,
of
course,
is
going
to
trigger
build
activities
and
a
lot
of
times
checks
now.
Gitlab
does
a
lot
of
checks
and
you
can
extend
it
with
all
kinds
of
custom
checks.
We're
going
to
really
focus
on
security
in
this
particular
illustration
here.
So
we
have
a
lot
of
static
checks,
sas
secrets
dependencies
license
scanning.
B
All
of
that
kind
of
scanning
goes
on
which
can
largely
go
against
your
code.
We
also
have
container
scanning,
which
has
to
go
against
your
built
container,
and
so
that's
also
part
of
the
whole
process
here,
and
then
I
mentioned
that
we
can
have
those
dynamic
review
environments
that
are
built
transparently
for
the
developer
without
any
effort
on
their
part.
B
If
you
think
about
review
environments
that
are
stood
up
in
order
for
dynamic
testing
a
lot
of
time,
they're
they're
off
of
a
shared
branch,
they're,
a
standing
environment,
there's
manual
procedures
or
waiting
in
order
to
get
an
application
deployed
to
them
with
gitlab,
that's
happening
inside
of
every
developer
branch
with
no
activity
on
their
part.
In
order
to
stand
that
up.
So
all
of
this
information
is
brought
back
into
the
merge
request.
The
merge
request
is
very
interesting
in
terms
of
how
gitlab
deals
with
security
in
the
merge
request.
B
The
developer
is
seeing
security
findings
for
code
that
they
just
changed.
So
it's
literally
a
delta
of
the
code.
They
have
changed
with
their
branch
and
what
that
does.
Is
they
it's?
A
very
direct
connection
between
the
code
changes
that
they've
made
in
the
security
findings
that
are
extant
and
so,
of
course,
most
of
us
want
to
be
good
citizens,
and
if
we
know
that
information
is
directly
attached
to
our
activities,
we're
more
than
willing
to
to
dive
in
and
address
it.
B
There's
some
capability
to
collaborate
on
individual
vulnerabilities
without
creating
an
issue,
but
when
you
create
an
issue,
you
get
kind
of
the
best
experience
in
terms
of
collaboration,
because
there's
a
lot
more
rich
collaboration.
Capabilities
on
an
issue
developers
can
also
determine
that
they
want
to
dismiss
the
vulnerability
and
potentially
give
a
reason
for
that.
Now,
when
we're
enabling
developers
to
have
this
kind
of
opportunity
to
remediate,
the
other
interesting
thing
here
is
that
the
alarming
or
the
alerts
are
only
at
the
developer's
merge
request
level.
B
So
we're
not
sending
out
alerts
to
the
whole
organization
or
to
security.
Saying
there's
been
a
problem
found
because
a
developer
might
end
up
resolving
it
in
minutes
when
they
see
that
they've
got
an
old
library
or
something
like
that.
However,
if
they
dismiss
a
vulnerability,
that's
a
time
at
which
we
might
want
security
to
be
involved.
Yet
we
don't
want
to
have
to
have
security
coming
in
here
all
the
time.
B
Looking
at
every
code
change,
so
gitlab
also
enables
lean
security
oversight
and
security
can
be
pulled
in
when
or
if,
and
only
if
a
developer
tries
to
dismiss
a
critical,
high
or
unknown
severity,
vulnerability
that
they
that
have
not
previously
been
accepted
into
that
next
branch.
So
this
really
allows
the
security
to
also
have
their
oversight.
Be
leaner.
B
At
this
point,
security
can
also,
you
know,
say
hey.
We
need
to
have
that
fixed
by
asserting
a
vulnerability
issue,
and
then
we
have
a
code
fix.
That
would
happen
by
the
developer.
Potentially
get
lab
is
also
embracing
automated
solutions.
So
when
there's
solutions
suggested
in
the
actual
vulnerability,
those
are
easy
to
find.
We're
also
embracing
some
auto
remediation,
where
possible.
So
using
yarn
for
npm
packages
is
an
example
where
you
can
just
single
click
and
upgrade
an
included
dependency
so
that
it's
fixed
with
a
version
that
is
known
not
to
be
vulnerable.
B
Interestingly,
normally
doing
things
like
that
would
be
very
disruptive
to
developers
if
they've
already
merged
their
code
into
a
shared
branch.
So
this
is
why
there's
a
lot
of
heartburn
around
saying,
hey,
you
got
to
upgrade
these
things
or
other
things,
because
all
the
testing's
been
done,
but
if
you
think
about
it
right
now,
the
developer
just
added
some
code
and
they've
found
a
vulnerability
and
they
still
need
to
keep
developing
the
code.
It's
a
lot
more
malleable
time
to
go
ahead
and
say:
hey.
You
know
you
really
need
to
fix
this
upgrade
this.
B
This
particular
source
code,
library
or
whatever
the
problem
is,
and
because
the
next
thing
we're
going
to
do
is
commit
it
and
go
through
another
ci
cycle
and
have
all
those
checks
run.
If
we've
got
really
good
qa
testing,
we
would
immediately
uncover
if
upgrading
that
component
caused
a
problem
that
now
needs
to
be
resolved.
So
what
this
all
does
is
encourages
developers
to
get
into
a
continuous
remediation
habit.
It's
part
of
their
everyday
work,
because
it
happens
within
the
everyday
habit
workflow
that
they
have.
B
In
addition,
it
presents
lots
of
rich
context,
information
to
make
engaging
in
remediation
a
very
easy
step
to
take.
So
that's
kind
of
how
git
lab
is
pushing
security,
not
just
left
but
hard,
left
or
left
and
down
so
that
the
developers
aren't.
We
don't
just
detect
vulnerabilities
early
and
assert
to
people
that
they
should
be
dealt
with
early.
We
detect
them
early
and
then
provide
them
with
lots
of
rich
tools,
lots
of
rich
context
in
order
to
engage
into
actually
doing
those
remediations.
B
Now,
for
most
of
my
demo,
I'm
going
to
have
to
work
off
of
pre-built
assets
so
that
we
can
move
quickly
through
the
various
things
we
want
to
take
a
look
at,
but
I
did
want
to
take
a
moment
to
show
you
how
quickly
and
seamlessly
developers
have
review
environments
when
creating
new
branches
against
an
eks
cluster.
So
I'm
going
to
create
a
new
issue
here
and
say:
quick
bug
fix
and
then
I'm
going
to
submit
this
issue
once
issue
is
set
up.
B
I
will
then
hit
a
button
here
to
create
a
merge
request
and
when
it
creates
a
merge
request,
it's
also
going
to
create
a
branch,
and
so
this
merge
request
has
been
created,
I'm
going
to
hop
over
to
ci
cd
pipelines,
and
we
should
see
that
git
lab
is
already
deploying
a
pipeline
with
the
baseline
contents
of
that
branch.
So
this
is
actually
with
no
changes
and
that
pipeline
once
it's
deployed
at
the
far
end
of
it.
It's
going
to
deploy
a
review
environment
right
into
kubernetes,
so
I'll
actually
have
a
copy.
B
So
now,
let's
hop
into
taking
a
look
at
some
actual
workflows.
So
I
have
a
repository
here
called
simply
simple
notes
and
in
here
is
a
net
core
application.
I
am
configured
to
send
this
application
to
aws
eks.
So
a
kubernetes
cluster
with
aws's
elastic
kubernetes
service
as
the
back
end,
we're
going
to
take
a
look
at
the
git
lab
flows
that
a
developer
might
go
through
now.
B
B
So
this
is
all
the
findings
in
the
default
branch,
so
this
is
sort
of
like
the
traditional
tools
that
do
security
management
out
of
bands.
You're
looking
at
scan
results
after
coding
has
happened
and
you're
trying
to
manage
them.
Maybe
assert
that
remediations
need
to
be
done
so
gitlab
has
that,
and
this
is
the
list
we
have
695
of
them.
So
I
wanted
to
show
you
this
so
that
when
we
go
into
the
merge
request,
you
can
see
that
we're
only
seeing
the
results
for
the
codes
that
we
have
changed.
B
B
So
here's
my
production
and
right
here
I
click
to
open,
live
environment
and
we
can
see
we
have
a
simple
application,
it's
operational.
So
if
I
want
to
delete
number
six,
it
deletes
number
six
and
now
we
only
have
five.
So
this
is
production
and
then
once
we're
inside
of
a
merge
request
automatically
without
any
action
on
the
part
of
the
developer.
We
have
a
review
app
that
has
been
set
up
so
that
we
can
do
desk
scanning,
but
you
could
also
use
it
for
anything
else.
B
B
Now,
as
we
look
through
our
merge
request,
we
can
see
that
we
also
have
our
approvers
section.
We
have
our
pipeline
information
as
well,
so
our
pipeline
passed.
I
just
want
to
draw
your
attention
to
a
couple
special
merge
approvals
here,
so
we
have
a
merge
approval
for
the
sre
team,
which
means
that
the
sre
team
will
need
to
approve
this
every
time,
so
they'll
have
to
come
and
look
at
the
code.
Changes
make
comments
and
make
an
approval
eventually,
but
these
two
here
are
special
vulnerability.
Check
and
license.
B
Check
are
only
only
happen
if
we
have
encountered
new
vulnerabilities
that
are
not
previously
seen
so,
basically,
anything
that's
critical,
high
or
media
or
unknown
severity
that
we
have
not
seen
before,
and
you
can
see
here.
It's
wanting
one
at
least
one
approval
here.
You
can
see
this
one's
optional,
because
apparently
we
have
not
run
into
any
licenses
that
have
not
been
previously
seen
or
that
are
denied.
B
If
we
go
down
here,
we
can
see
that
we
have
no
changes
to
code
quality.
Now
container
scanning
is
actually
one
thing
that
does
scan
everything
at
a
time,
because
every
time
we
build
a
container,
it's
a
new
artifact,
and
so
it
is
showing
all
the
vulnerabilities
in
the
container.
That's
out
there
right.
A
B
So
that's
that
operates
a
little
bit
differently,
but
if
we
get
down
to
secret
scanning,
we
can
see
here
we
have
four
critical
severity
vulnerabilities
because
there's
an
aws
api
key
in
the
code.
When
we
click
on
a
vulnerability
here,
we
can
interact
with
it,
so
the
developer
can
dismiss
it
with
a
comment,
and
we
could
also
see
if
there's
other
interactions
on
here.
So,
for
instance,
if
someone
had
already
dismissed
it,
maybe
a
project
lead
or
security
themselves
had
already
dismissed
this.
B
We
would
see
that
there
we
can
also
create
an
issue
which
will
copy
over
all
this
vulnerability
information,
including
the
location
where
it
is
in
our
code,
and
we
can
then
start
to
collaborate
at
that
point
or
schedule
that
work
if
it
needs
to
be
done
so
that
is
kind
of
the
developers
heads
up
panel.
They
get
these
vulnerabilities
handled,
they
are
in
the
developer's
workflow,
so
you're,
not
getting
a
nice
clean,
build
as
long
as
you
have
the
vulnerabilities
that
are
not
acceptable
license.
B
Management
is
also
part
of
this
there's
a
ton
of
other
kinds
of
scanning.
In
fact,
I
will
just
quickly
window
over
to
a
different
one
and
we
can
see
here
a
whole
bunch
of
other
types
of
scanning
on
this
particular
repository
have
been
triggered.
In
addition,
it
has
some
license
findings,
so
you
can
see
that
there
can
be
quite
a
bit
of
data
that
flows
into
this
flow
for
developers
to
resolve.
B
B
Now,
let's
take
a
look
at
some
under
the
covers
of
the
gitlab
cicd
pipeline.
This
information
we
mentioned
about
the
review
app
and
there
is
a
special
review
app
just
for
this
branch.
So
every
time
we
do
something
here,
eks
environment
is
fired
up.
A
namespace
is
created
and
the
application
is
deployed
there,
so
it's
isolated
from
other
versions
that
you
might
be
working
on
in
other
branches
or
that
other
individuals
are
working
on.
Let's
also
take
a
look
at
the
pipeline
here
now,
in
this
case
it's
an
auto
devops
pipeline.
B
Today
to
start
a
new
project,
you
have
a
command
line
that
you
execute
and
it
will
lay
out
the
project
and
all
of
its
assets
in
that
opinionated
way
that
that
particular
language
framework
likes
to
see
its
best
practice
projects,
and
that's
why
heroku
can
recognize
and
build
these.
So
these
individual
stages
here
are
part
of
autodevops
and
we'll
talk
in
just
a
minute
about
what
what
you
can
do
with
that.
Let's
just
dig
into
one
of
these,
where
we
can
actually
see
the
individual
log
of
the
container
that
ran
to
do
that
stage.
B
In
this
case,
these
are
all
happening
on
containers.
You
can
also
use
shell
runners,
a
traditional
shell
runner,
which
runs
all
the
jobs
on
individual
instances
as
opposed
to
within
containers,
whatever
whatever
works
for
your
workflow
best,
we
can
see
here
all
the
logged
details
of
what
happened
during
this
phase
of
the
build.
B
If
we
go
back
up
to
the
auto
devops
pipeline
level,
we
can
also
see
results
from
various
stages
here,
and
these
are
the
pipeline
level
results,
not
the
merge
requests.
So
we
can
see
all
the
security
scanning
results
for
this
branch
as
opposed
to
the
security
scanning
results.
Just
for
the
mr
now,
let's
also
take
a
look
at
the
ci
cd
code
that
backs
this
in
this
case
we're
using
autodevops.
So
it's
going
to
be
very
light,
because
autodev
also
is
able
to
recognize
what
kind
of
project
this
was
build.
B
B
Can
have
includes
so
all
of
auto
devops
is
actually
built
on
gitlab
ci
cd.
You
can
see
here,
though,
that
I'm
customizing
through
parameters
and
even
custom
ci
stages,
so
gitlab
has
this
concept
of
autodevops,
which
you
can
think
of
as
a
prefabricated
assembly
line
for
manufacturing
software,
but
we
also
have
big
chunks
like
gitlab,
deploy
that
you
can
include
in
your
existing
ci,
cd
workflows
or
gitlab
security
scanning.
You
can
include
just
sas
scanning
and
use
that
fully
formed
component,
but
then
you
can
also
do
whatever
you
want
custom.
B
You
can
even
take
third-party
security,
tooling
and
code
it
up,
so
it's
its
information
will
be
uploaded
right
into
gitlab,
like
the
vulnerabilities
of
panel
that
you
saw
me
demonstrating
so
gitlab
has
full
capabilities
from
a
kind
of
a
completely
automated
mode,
all
the
way
down
to
building
anything.
You
can
build
in
any
other
ci
system.
Basically,
if
there's
a
command
line
interface
for
it
or
you
run
it
on
existing
ci
in
a
shell
runner
or
a
container
runner,
then
you'll
build
a
port
it
to
gitlab
with
very
little
problem.
B
In
addition,
I'd
like
to
quickly
show
you,
on
the
back
end
the
console
and
show
you
that
we
are
indeed
processing
against
a
kubernetes
cluster,
so
the
first
command
I'm
gonna
run
here,
is
going
to
check
out
my
cube
config
so
that
we
can
see
where
we're
pointed-
and
I
can
show
so.
The
little
star
here
indicates
where
I'm
currently
pointed
by
default,
and
so
it's
one
of
my
eks
clusters
and
then
I'm
going
to
do
list
out
my
various
pods
within
that
cluster.
B
Now,
because
autodevops
creates
individual
namespaces
for
every
branch
in
every
project.
If
you
have
it
configured
that
way,
you
can
control
it
as
much
as
you
need
to
to
to
suppress
that
if
necessary,
I'm
going
to
use
all
namespaces.
So
this
will
show
me
all
the
projects
in
the
cluster
you
can
see.
I
have
several
other
projects
pointed
here,
but
down
here
simply
simple
notes:
net
is
all
of
the
various
pods
that
have
to
do
with
that
project.
B
Shows
you
that
this
capability
to
deploy
to
kubernetes
and
to
have
very
dynamic
review
environments
that
allow
you
to
do
das
scanning.
In
this
case
we're
pointed
at
an
eks
cluster
and
it
works
very
well
with
eks,
so
that's
kind
of
the
wrap
up
on
the
demos
of
gitlab
ci
cd
and
a
little
bit
of
the
workflow
that
goes
along
with
getting.net
into
an
eks
cluster.
B
So
let's
just
take
a
quick
look
at
what's
going
on
here.
Basically,
git
lab
is
shifting
the
whole
psychology
of
how
security
vulnerabilities
are
presented
and
when
they're
presented,
so
we're
going
to
talk
a
little
bit
about
what
that
looks
like
in
this
chart.
So
basically
with
within
the
everyday
developer
workflow
for
code
changes
made
moments
ago,
only
newly
introduced
vulnerabilities
are
immediately
visible
and
directly
associated
with
the
individual,
with
a
semi-private
remediation
opportunity.
B
So
since
we're
just
at
the
mr
level
right
now
we're
not,
we
haven't
tried
to
merge
we're
not
announcing
to
everybody
that
hey
there's
a
vulnerability
here,
because
a
developer
might
be
able
to
resolve
it
fairly
quickly,
where
they're,
accompanied
by
next
step
and
next
steps
information.
So
those
solutions
whenever
they're
available,
as
well
as
obviously
the
basic
vulnerability
information,
and
then
we
have
a
per
vulnerability,
asynchronous
auditable
actions
and
communications
record.
So
we
have
that
little
capability
to
interact
right
on
the
vulnerability.
B
But
if
we
create
an
issue,
then
we
get
gitlab's
full
collaborative
capabilities
and
a
lot
of
individuals
don't
understand
that
in
the
gitlab
issues,
a
lot
of
the
items
that
are
entered
there
are
immutable.
So
once
you
have
a
log
entry
in
there,
someone
checked
off
a
checkbox
or
added
something
it
can't
be
removed
from
that
log,
and
this
eliminates
that
constant
frustration
of
not
knowing
if
everyone's
talking
about
the
same
vulnerability
from
a
spreadsheet
from
three
weeks
ago,
from
a
specific
scan.
B
Instead,
we
have
a
collaborative
capability
that
we're
used
to
in
source
code
management
is
brought
right
into
vulnerability
remediation
management.
Now,
if
we
compare
that
to
traditional
remediation
management,
which
I
showed
you
gitlab
still
has
that,
because
it's
still
needed
for
sprint
planning
and
for
paying
down
security
debt,
but
some
of
the
challenges
of
it.
If
you
only
have
it
are
as
follows.
So
many
times
it's
an
addendum
process
that
can
be
forgotten
or
skipped.
The
introduction
moment
for
our
vulnerabilities
is
unknown
and
all
vulnerabilities
in
the
code
are
scanned
in
a
shared
branch.
B
There's
delayed
scanning
and
reporting
visibility
is
very
common
after
developers
have
said.
Oh
great,
my
code
is
working
and
sent
it
down
the
line.
Then
they
get
their
vulnerability
report.
The
un,
the
coding
authoring
responsibility,
can
be
unclear
because
a
lot
of
times
it's
happening
on
a
shared
branch
and
multiple
developers
may
have
changed
the
same
line
of
code
or
they
may
not
recognize
what
line
of
the
code
they
have
changed
after
so
many
changes
have
been
merged.
B
I
can
also
end
up
alerting
everyone.
If
you
take
one
of
these
tools
and
turn
them
loose
on
every
developer
branch,
which
can
be
a
challenge
that
creates
a
lot
of
noise,
there's,
possibly
not
as
much
additional
information
or
any
automated
solutions,
and
then
we
get
into
that
manual
per
vulnerability,
communication
racket.
So
we're
going
back
and
forth
on
emails
meetings,
documents
spreadsheets,
trying
to
make
sure
we're,
even
just
on
the
same
page,
let
alone
talking
about
doing
the
same
thing
with
regard
to
a
given
vulnerability.
B
B
As
we
get
wrapped
up
here,
just
a
couple
resources
for
your
consideration.
Gitlab
recently
published
this
ebook
five
aws
customers
who
depend
on
gitlab
for
devops
workflow.
So
I
encourage
you
to
take.
Take
us
up
on
that
ebook.
Then
we
also
have
some
additional
resources
from
both
git
lab
and
the
aws
side,
some
helpful
links
and
repositories
and
other
documentation
that
relate
to
what
we
covered
today
and
then
finally,
just
want
to
extend
a
great
big.
A
Thank
you.
Darwin
thanks
a
lot
thanks
for
the
opportunity,
thanks,
everyone
who
could
join
us
for
this
webinar
we
at
aws
are
continuously
learning
iterating
from
the
feedback.
Customers
like
you
gave
us
90
to
95
of
aws
roadmap
is
driven
by
your
feedback,
so
please
keep
them
coming.
We
are
eager
to
hear
listen
from
you
guys
and
in
partnership
with
gitlab.
Just
got
better
have
a
wonderful
day
evening
week.