►
From YouTube: UX Showcase: Security Workflow Iterations
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
A
Is
a
recording,
jackie,
okay,
cool
hello,
I'm
kyle,
I'm
on
the
secure
and
defend
team,
and
today
we
are
talking
about
some
security,
workflow
iterations
that
we're
making
and
I'm
really
just
focusing
on
a
couple
of
core
workflows
that
we
work
on
and
secure.
A
A
The
development
team
will
have
to
review
through
this
dig
through
false
positives
and
then
they'll
all
decide
what
to
take
action
against
now.
The
problem
with
this
traditional
workflow,
which
is
familiar
to
a
lot
of
teams,
is
security,
is
really
an
afterthought.
So
there's
vulnerabilities
in
production
and
the
only
way
to
know
about
is
going
through
this
and
it
being
in
some
pdf
or
excel
spreadsheet
somewhere,
and
it's
reviewed
in
production.
A
A
Well,
it's
commonly
referred
to
as
devsecops,
and
what
we're
looking
at
is
really
the
core
workflow
that
makes
up
the
secure
features
now,
first
I'll
mention
that
the
prerequisite
to
all
this
is
a
proper
configuration
of
five
scanners
and
that's
growing,
such
as
more
recently
updating
with
secrets
detection
but
sas,
which
is
static.
Analysis.
Das
is
dynamic.
Analysis
for
in
production,
environments,
dependency
scans
against
your
dependencies
in
your
project.
Files
licenses
are
related,
open
source
licenses,
so
more
related
to
compliance
and
then
container
scanning
related
to
say,
docker
image.
A
Once
the
configuration
is
is
properly
made,
then
they
have
the
access
to
these
great
features
and
what
happens
with
this
is
the
developer
commits
code?
The
scanner
is
then
in
the
ci
pipeline,
and
then
the
results
are
shown
in
the
merge
request.
So
the
developer
is
aware
of
vulnerabilities,
they
may
be
introducing
and
they
can
remediate
it
and
then
from
there
it's
merged
into
production
and
can
be
seen
on
the
security
dashboard
dependency
list
and
license
list
just
to
name
a
few
areas
from
that
point
on
the
remediation
process
can
take
place.
A
So
this
is
really
the
core
workflow
here.
It
also
highlights
the
importance
of
configuration,
so
I
want
to
point
out
that
becca's
been
really
continuing
some
iterations
there
on
sas
configuration
directly
in
the
ui,
so
we
want
to
improve
that,
and
while
this
is
our
core
workflow
where
it's
configured
and
then
it
commits
code
and
pipeline
runs
and
so
on,
there's
also
camellia's
looking
at
on-demand
scan.
A
So
it's
a
little
bit
outside
of
this
workflow,
where
it's
more,
when
you
want
to
sort
of
click
the
button
and
then
do
on
demand
scan
outside
of
this
workflow.
So
that's
a
bit
of
context
around
this.
Let's
look
at
a
scenario,
though,
when
let's
say
that
a
team
creates
a
new
project
and
then
configures
a
scan
type,
and
so
what
we're
looking
at
is
how
these
scan,
how
that
scenario
relates
to
the
git
workflow.
A
So
we
see
the
default
branch
here
and
subsequent
feature
branches.
Have
the
security
checks
applied
henceforth
from
that
down,
but
that's
a
brand
new
project
created
how
about
a
project?
Let's
say
that
we
have
customers
who
upgrade
newly
to
ultimate
or
they
already
have
an
existing
project.
What
happens
then
after
configuration?
A
So
in
this
view,
looking
at
the
default
branch
as
sort
of
a
timeline?
Let's
imagine
that
configuration.
This
is
an
existing
project.
Configuration
takes
place
here
in
this
timeline
and
henceforth
the
feature
branch
and
the
default
branch
have
security
checks
in
them.
So
that'll
go
back
to
the
workflow,
where
it
displays
the
security
findings
and
the
merge
request
and
then
also
in
the
vulnerability
list
and
other
places.
I
showed
you,
but
how
about
those
feature?
Branches
that
were
done
prior
to
configuration?
A
We
see
here
that
it's,
it
would
be
merged
and
it
could
be
targeting
the
default
branch
and
it
could
be
merged.
It
could
be
merging
vulnerabilities
without
any
scan,
so
there
would
be
no
detection
of
it
and
it
would
be
introducing
vulnerabilities
to
production
and
it
would
not
show
up
on
on
any
of
the
in
production
remediation
areas
like
the
security
dashboard
and
so
on.
A
So
this
is,
you
know,
a
sort
of
ux
bug
and
it's
not
fulfilling
the
promise
that
we
made
to
the
customer
of
making
sure
it
scans
or
their
post
configuration
so
we're
mediating.
This
indirectly
is
we're
not
putting
the
burden
on
the
customer
developer.
A
We're
gonna
notify
the
developer
when
this
case
is
happening
when
they're
targeting
a
a
branch
that
has
scans,
but
their
source
branch
does
not
and
we're
leveraging
the
rebase,
which
will
help
with
this
situation
and
the
way
that
this
will
help
is
a
rebase,
basically
rewrites
history
and
takes
that
feature
branch
and
will
bring
it
to
the
head
of
the
default
branch
and
so
from
there.
Since
it's
on
the
default
branch,
it'll
therefore
run
a
security
security
check.
So
you
know
part
of
this
workflow.
A
The
importance
here
is
making
sure
we
bridge
the
gap
of
these
loopholes
and
and
fulfill
the
customer
expectations.
Because,
again,
you
know
not
having
a
scan
when
expecting
a
scan
is
worse
than
a
vulnerability
finding,
because
if
you
find
a
vulnerability
at
least
there's
an
audit
trail,
at
least
you
can
remediate
it
at
least
it's
on
the
security
dashboard.
A
Okay,
so
the
next
workflow
I
want
to
zoom
in
on
having
looked
at
the
context
of
traditional
workflow,
our
devsec
ops,
workflow,
that's
built
into
the
developer
environment
is
then
going
to.
The
next
step
is
once
it's
in
production.
What
does
the
remediation
process?
Look
like
one
of
the
things
we're
focused
on.
Is
we
really
want
to
automate
that
process
as
much
as
possible?
A
So
this
is
related
to
our
feature
called
the
auto
remediation
feature
also
called
suggested
solutions,
and
the
reason
why
we
call
it
suggested
solutions
is
that's
more
appropriately
where
we're
at
now,
because
we
are
able
to
suggest
solutions,
we
don't
have
a
fully
automated
remediation
process.
So
that's
why
just
a
separation
of
terms
there?
A
A
They
can
go
through
them
dismiss
false
positives
where
there
may
be
some
and
then
also
investigate,
positives
and
then
create
a
merge
request
with
fixes
with
the
development
team
and
then
merge
to
production.
So
we,
this
is
a
high
level
sort
of
workflow
of
what
that
would
look
like
now.
As
I
said,
there
are
cases
where
we
have
suggested
solutions
that
are
fixes
to
known
vulnerabilities.
Well,
what
could
these
be?
There
could
be
known
patches
to
dependencies
that
are
well-known
vulnerabilities
with
patches.
A
We
have
those
and
we
suggest
them
today,
but
it
could
also
be
version
updates
for
a
docker
container.
Maybe
you
need
to
do
the
latest
update
or
the
version
you
have
has
been
detected
as
a
vulnerability.
We
know
what
the
fixes
are
in
some
cases
and
what
we
want
to
do.
A
We
did
the
discovery
around
this
is
we
want
in
those
cases
where
we
know
as
where
there's
a
patch
available
or
a
version
update
that
we
know
of,
we
not
only
want
to
suggest
it,
but
we
want
to
create
a
merge
request
with
that
fix,
and
so
what
that
does
is
that
just
removes
this
whole
process.
So
in
this
workflow
we
see
with
this
new
suggested
solution,
auto
creation
of
a
merge
request.
A
A
One
of
the
results
that
was
not
positive,
you'll
see
here,
is
that
the
merge
request
is
created
by
the
system.
Indeed,
however,
it
would
be
authored
by
the
user
who
configured
this
feature.
This
was
really
a
temporary
solution.
We
wanted
to
propose
for
expediency
to
get
the
mvc
out
and
then
to
do
some
fast
follow-ups
on
it,
but
we
didn't
really
have
a
ghost
user,
an
alternative
user
to
to
use.
A
So
that
was
another
downside
to
this
and
when
they
came
to
opt
into
it,
the
user
who
opt
into
it
would
be.
The
author
of
the
automatically
created
merge
requests.
Okay,
so
we
got
some
feedback
that
users
were
not
comfortable
with
that.
We
also
had
some
time
in
between
development
which
we're
currently
it's
in
a
future
flag.
Now
for
release
for
13
4,
13
5,
I
believe-
and
we
were
we
were
able
to
do
a
discovery
around
finding
an
alternative
user.
A
Now
the
results
of
that
was,
let
me
introduce
you
to
the
gitlab
security
bot
now
the
way
that
this
is
going
to
work
and
we
partnered
with
the
security
team
to
make
sure
that
we
were
mitigating
any
security
concerns
here,
and
it
was
a
really
great
cross-functional
effort
to
get
this
together,
but
ultimately,
after
exploring
a
number
of
different
options,
what
we
landed
on
is
it'll,
be
an
out
of
the
box
user
at
the
instance
level,
so
whether
it's
public
projects
or
ultimate
customers,
this
out
of
the
box
user,
will
be
here
and
one
of
the
things
we
really
wanted
to
make.
A
Sure
of
is
being
abundantly
clear
that
this
is
a
system,
but
this
is
some
feedback.
We
got
that
there's
a
lot
of
confusion,
sometimes
about
bots,
whether
it's
their
bot,
whether
it's
our
bot
or
so
on,
and
so
we're
being
abundantly
clear
with
that.
You
see
in
the
instance
lever,
there
are
no
options
for
this
body.
It
is
standard
to
the
instance
and
then
the
other
thing
that
this
really
helps
with
is
that
it
was
opt-in
by
default.
So
no
further
configuration
required
once
either
or
container
or
dependency
scanning
are
configured.
A
This
works
immediately,
so
it's
actually,
they
would
have
to
opt
out
of
it
if
they
wanted
to
not
use
it
and
that's
aligned
with
our
convention
over
configuration
goal
for
for
how
we
design.
A
This
is
just
looking
at
a
merge
request
with
the
gitlab
security
bot,
again
making
sure
we're
reinforcing
to
the
user
that
it
was
created
by
this
bot
and
another
major
helpful
item
that
this
is
a
user
is
that
it
gives
us-
and
it's
just
and
it's
sort
of
frugal,
because
it's
using
our
existing
working
patterns
of
having
a
user
profile.
But
by
having
this
pattern,
it
gives
us
an
audit
log
of
what's
the
activity
the
bot's
been
doing.
A
Another
great
thing
on
the
engineering
side
is
that
the
only
activity
that
this
bot
can
do
is
create
a
merge
request.
It
can't
merge
a
merge
request.
It
can't
do
other
activities,
so
if
it
ever
did
get
hacked,
that's
the
only
activity
it's
restricted
to
doing
so
that
worked
with
some
of
our
security
teams
concerns
as
well
that
we
work
through
the
next
step.
Here
is
actually
to
show
what
projects
are
related
to
the
spot
so
to
help
further
the
audit
log
of
if
the
users
want
to
know
at
the
instance
level.
A
A
So
today
we
have
the
support
and
alert
bot
and
soon
we'll
have
the
security
bot,
but
jeremy
did
the
avatars
for
this,
and
I
think
that
they
are
really
amazing,
so
big
shout
out
to
jeremy
there.
Thank
you,
okay.
So
where
does
this
get
us
at
with
our
new
workflow?
So
once
it's
merged
to
production,
the
gitlab
security
bot
will
create
the
merge
request
automatically
when
solutions
are
available
for
either
container
dependency
scanning.
The
developer
can
review
the
finding
or
the
merge
request
here
and
then
merge
it
to
production.
A
The
next
couple
steps
that
we're
going
to
be
looking
at
and
doing
discoveries
around
oops
a
little
too
quickly
is
shifting
left
more
it's
a
common
devsec
ops
term
and
what
that
means
is
just
bringing
it
more
to
the
develop,
bringing
security
more
to
the
development
side
and
we're
already
exploring
options
to
commit
fixes
right
there
in
the
merge
request.
A
Our
first
step
may
just
be
surfacing
that
the
the
patches
available
for
download,
so
that
the
developer
could
at
least
commit
it
locally,
but
this
is
the
next
step
is
focusing
on
the
merge,
request,
experience
and
removing
these
vulnerabilities
or
updating
these
out
of
date
dependencies
before
it
even
gets
to
production.
The
next
step
also
is
if
it
is
in
production,
the
gitlab
bot
creates
the
merge
request
and
then
merges
the
fixes
as
well.
So
that's
what
we're
the
team's
working
on
now!