►
From YouTube: MR DevSecOps Concept Sync
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
Okay,
we
should
be
seeing
the
overview
page
and
our
primary
focus
was
to
at
a
high
level
point
out
what
is
blocking
a
merge
request
and
that's
essentially
it
what,
and
so
we
want
users
to
be
able
to
see
like
what
do.
I
need
to
do
to
move
this
forward
and
we
brought
various
elements
of
the
UI
together
and
removed
others
in
a
way
to
facilitate
that
concept
of
what
do
I
need
to
do
to
merge
this.
A
So
at
first
glance,
you'll
see
an
overview
tab
and
the
Mr
status.
The
status
is
at
the
top
and
it's
got
a
list
of
blockers
right.
So
we
have
the
threads
approvals
pipeline,
failed
and
security
blockers
and
those
right
away
can
indicate
to
an
author
or
viewer
that
work
needs
to
be
done
prior
to
handing
this
off
to
the
next
step.
A
So
right
away,
users
can
go
and
view
the
blockers
if
they
choose
to
or
they
can
go
and
check
out
the
changes
in
line.
But
following
this
workflow
we
can
view
the
blockers.
Likewise,
we've
added
this
merge
check
summary,
which
allows
users
to
see
like
a
comprehensive
status
of
the
checks
and
what
has
passed
and
what
has
failed.
So,
for
example,
Performance
like
load
performance
passed,
so
you
can
kind
of
go
down
into
nitty-gritty
and
you
can
also
download
these
aspects
to
account
for
our
non-ultimate
users.
Hey.
A
Blockers
are
anything
that
violate
a
rule
or
have
failed
in
the
system.
I
threw
some
definitions
into
our
agenda
to
help
with
that
so
quickly.
We
could
see
these
blockers
right.
There's
unresolved
threads
there's
an
additional
approval
required
a
pipeline
has
failed
and
there
are
five
security
blockers.
What
this
amounts
to.
So
we
go
to
the
checks.
A
Tab
you'll
see
an
aggregate
view
of
everything
that
is
getting
in
the
way
of
merging
this
code
and
these
changes
so
a
pipeline
job
failed
users
can
go
and
view
that
job
and
rerun
it
a
vulnerability,
was
detected
that
is
blocking
so
there's
a
rule
created
to
say
this
vulnerability
cannot
be
merged
and
must
be
removed,
non-in-line
vulnerability.
We
call
that
in
a
dependency
or
a
secret,
a
denied
license
as
well
as
missing
an
approver.
A
A
C
Yeah
I
think
that's
a
whole
bunch
of
scenarios
all
together.
They
might
be
helpful.
You
don't
have
to
do
this
for
this
discussion,
but
it
might
be
helpful
to
split
some
of
them
out
so
put
it
in
a
real
context
of
here's,
an
MR,
here's
three
things
that
got
thrown
right,
they're,
either
blockers
or
Warnings,
and
then
take
us
through
the
the
author
path,
as
well
as
a
review
or
path
like
separate
those
out,
so
that
we
understand
who's
doing
what
and
when
and
why.
A
Okay,
well,
so
that
this
entire
experience
is
defined
throughout
the
code
review
process
right,
so
an
author
and
reviewer
can
be
doing
both
of
these
things
and
author
before
they
pass
off
their
code.
Changes
to
a
reviewer
can
come
in
and
see
these
things
have
happened.
So
there
are
five
security
blockers.
I
can
attempt
to
address
those
and
I
can
see
them
by
viewing
them
by
viewing
the
blockers
as
well
as
all
the
other
things
that
need
to
happen.
A
For
me
to
hand
this
off
to
the
review
is
that
this
is
mid
review,
and
this
comes
back
to
me
as
an
author.
I
can
continue
working
down
this
list.
If
I
handed
this
off
to
a
reviewer,
the
reviewer
would
come
in,
they
would
see
the
merge
is
blocked.
All
checks
must
pass.
They
can
go
and
review
the
code
and
make
comments
on
the
code
itself
either
the
code
hygiene,
which
is
something
we
want
users
to
be
able
to
do
with
code,
quality
or
SAS.
C
Yeah-
and
it
could
be
just
that-
it's
there's
so
much
right-
I-
think
that
might
be
what's
I'm
I'm
trying
to
get
in
your
brain
a
little
bit,
Christie
I,
think
that
might
be
what
is
a
challenge,
because
there's
just
so
many
blockers
or
so
many
warnings
that
are
being
thrown-
and
this
is
just
an
example
right-
there
are
going
to
be
situations
where
there's
going
to
be
even
a
higher
volume
and
it's
hard
to
take
in
it's
hard
to
know
which,
by
the
way,
I
really
appreciate
I
love
this
overview.
C
So
let's
do
some
positives
really
quickly.
I
love
this
overview,
having
the
the
section
where
the
status
is
with
merge,
blocked,
and
it's
giving
you
a
list
of
exactly
what
you
need
to
do
in
order
to
move
the
Mr
forward,
I
think
now.
What
we're
talking
about
is
is
a
separate
problem
is
why
is
so
much
being
thrown
into
NMR
right?
Why
are
so
many
things
being
presented
that
must
be
resolved.
D
D
They're
going
to
see
a
lot
so
like
there
are
going
to
be
some
checks
that
show
up
no
matter.
What,
like
you,
need
your
pipeline
to
succeed,
but
most
of
the
other
things
I
feel
like
I
I,
don't
know,
I
almost
feel
like
that
would
be
worth
a
separate
conversation
and
I'm,
not
even
100
sure
how
much
we
reasonably
could
do
there
other
than
just
to
enable
organizations
to
you
know
it's
really
up
to
them.
How
many
checks
they
want
to
enforce.
I
feel
like.
C
Yeah
I
agree
I,
just
when
you
know
going
through
this
I
can
just
imagine
someone
feeling
overwhelmed
and
part
of
a
designer's
responsibility
is
to
remove
some
of
that
complexity,
but
happy
to
address
that
in
a
different
conversation.
E
I
think
there's
also
an
aspect
here
of
like,
for
example,
threads
must
be
resolved.
That's
under
the
checks.
That's
also
in
the
upper
right
hand
corner
then
there's
pipeline
job
fail.
That's
also
right
below
it.
There's
approvals
required,
that's
also
in
the
widget,
so
there's
some
duplication
and
then
I'm
not
sure.
A
Right
so
I
mean
essentially
the
use
case
you're
seeing
is
this
is
gitlab,
but
we've
turned
on
rules
for
security
right,
there's
going
to
be
duplication
on
in
this
widget,
when
these
items
are
violating
a
rule,
they're
not
biting
violating
a
rule
like
all
the
approvers
are
given
great
it'll
go
away,
and
then
you
can
act
here
right.
The
same
thing
with
the
mergerpus
pipeline
failed.
Sometimes
things
fail
and
they're
not
required
to
pass
or
they
pass
with
warnings.
A
A
Given
we
give
users
summaries
here
to
see
what
is
and
what
isn't
blocking
so
we
show
them
their
Branch
rules,
everything
that
must
happen
in
the
branch,
all
the
security
and
compliance
objects
that
may
be
failing
or
blocking
or
even
succeeding,
and
then
they
can
go
to
the
pipeline
report.
So
we've
Consolidated
everything
down
into
three
tabs
and
what
items
need
to
be
addressed.
A
E
So
for
the
status
section
on
the
overview,
if
I
see
that
my
pipeline
has
failed
and
then
that
first
I
I
guess
the
second
line
that
says
merge,
result
pipeline
failed
one
hour
ago
and
then
I
can
also
see
that
under
checks
is
it
necessary
like
can
the
status
just
have
the
checks
like
the
the
things
that
are
blocking
or
does
it
need?
Is
there
a
reason
we're
putting
it
in
three
places?
I
guess
it's
my
question.
A
So
we
have
our
Focus
view
right.
That's
why
we
chose
to
put
it
in
here
things
that
are
blocking.
We
don't
want
to
create
an
experience,
that's
only
for
security
right
or
only
for
one
type
of
very
focused
individual.
This
is
just
these
are
the
things
that
are
blocking.
The
merge
request
will
take
you
here.
A
E
A
E
A
A
C
But
I
I
get
what
you're
saying
because
there's
a
difference
between
or
maybe
there's
a
difference
between
a
status
of
something
and
then
the
requirements
that
you
must
fulfill,
and
so
this
widget
combines
the
two
of
those,
and
some
of
them
are
the
same,
but
some
of
them
are
not
so
deploy
to
would
also
be
an
exception
right.
So
you
have
merge.
C
Result
pipeline
failed
one
hour
ago,
deployed
to
and
approved
by
those
are
separate
from
the
things
that
must
be
done,
and
so
maybe
creating
some
visual
separation
between
those
and
not
including
them
in
this
widget.
That
is
meant
for
or
I
believe
that
it's
meant,
for
these
are
the
things
that
you
have
to
succeed
in
order
to
move
the
Mr
forward.
D
D
The
merge
request
pipeline,
especially
the
terminology,
have
failed
and
where
that
is
it's
so
interconnected
with
whether
or
not
it
can
be
merged.
It
seems
like
that's
really
the
biggest
area
of
duplicity
here
and
almost
if
we
just
took
that
out
or
represented
that,
perhaps
in
a
different
way,
then
we
wouldn't
have
any
real
duplicate
content.
Here
we
would
show
where
it's
deployed,
who
it's
approved
by
and
What's,
blocking
the
merge
request.
Those
all
seem
to
fit
under
the
status
heading.
E
A
E
Yeah
so
I'm
not
I'm,
not
trying
to
like
get
into
like
all
the
details,
but
I'm
just
trying
to
provide
feedback
that
the
hierarchy
feels
kind
of
off,
and
it
wasn't
clear
to
me
that
the
top
section
of
this
widget
is
things
that
are
blocked
and
the
bottom
section
are
statuses.
I
didn't
get
that
connection,
so
whatever
we
do
with
that
feedback
that
just
that's
just
how
I
interpreted
it,
which
was
wrong.
Apparently.
D
So,
just
a
couple
notes
that
I
wanted
to
talk
through
from
that
I
put
in
the
dock
ahead
of
time.
I
mean
overall
Andy
I
feel
like
this
is
a
really
good.
Improvement
I'm
actually
really
excited
to
see
this
I
I
have
just
sort
of
a
couple
minor
points
of
feedback
that
I
feel
like
we
may
need
to
adjust,
but
overall
I
think
it's
looking
really
really
good
one.
D
Is
that
the
security
anything
related
to
security
that
might
block
a
merge
request,
actually
is
a
type
of
approval
today,
and
so
breaking
that
out
into
its
own
thing,
actually
makes
me
feel
really
really
confused
and
it
doesn't
line
up
with
what
we
do,
because
I
would
actually
expect
to
have
seen
what
you
have
here,
but
I
would
expect
security
to
be
like
a
sub
thing
under
approval,
so
we
would
have
security
approvals.
We
have
license
approvals,
we
have
external
status
check
approvals
and
those
are
the
security
and
compliance
related
ones.
D
And
then
you
also
have
code
owner
approvals,
and
then
you
also
have
I,
don't
know
what
to
call
them.
Somebody
who's
better
at
naming
than
me,
but
just
your
generic,
like
you
know
your
generic
approvals
that
is
sort
of
the
fifth
category,
so
I,
actually
I,
really
like
this
I
just
would
expect
to
have
seen
sort
of
a
nesting
of
security
under
that
approvals
category,
and
probably
those
five
sub-categories
underneath
that.
But
that's
probably
my
biggest
point
of
feedback
here.
A
So
so
what
are
Concepts
actually
going
to
be
introducing
is
a
new
action
for
the
rules,
so,
instead
of
require
approval,
it
will
be
block
the
Mr
we
wouldn't
today
with
how
we've
laid
it
our
system
out.
We
aren't
shifting
left
we're
bringing
security
people
into
the
developer
flow
and
that's
not
what
they
want.
They
want
to
be
able
to
control
and
gate
not
have
to
go
into
every
Mr,
where
there's
a
vulnerability
and
approve
it
right.
A
A
D
This
is
all:
maybe
we
need
to
talk
through
that
separately,
because
I
think
we've
got
some
at
least
some
philosophical
misalignment
in
that
approach
there
and
sounds
like
there's
a
lot
to
talk
through,
so
maybe
maybe
I'll
schedule.
Another
conversation
there
just
to
to
work
through
that
outside
of
this
group.
If
that's
okay,.
A
D
Yeah
not
necessarily
so,
and
that's
why
why
there
we
have
that
approval
option
as
sort
of
a
an
alternate
workaround.
So
it
might
be
that
the
vulnerabilities
are
false
positives,
but
a
lot
of
organizations
don't
want
to
allow
the
developers
to
just
mark
them
as
false
positives.
They
want,
if
it's
a
false
positive.
They
want
that
to
be
verified
by
a
member
of
the
security
team
before
allowing
it
to
be
merged
in
so
that
would
be.
D
One
scenario
is,
is
the
false
positive
scenario,
the
other
scenario,
which
is
an
edge
case,
but
it
is
like
we
can't
ignore
it.
Just
because
it's
an
edge
case
like
it
does
absolutely
come
up,
is
that
sometimes
code
needs
to
be
merged
in
like
if
you're
you
know
amazon.com,
and
your
main
production
website
is
down
you're
losing
money
every
second,
that's
down
and
honestly
I
don't
care
if
there's
a
security
vulnerability.
D
And
so
you
know
that
sort
of
thing
happens
and
that's
why
customers
that
we've
seen
who
just
flat
out
fail
their
pipelines
as
sort
of
the
workaround
to
do
what
you're
describing
tend
to
eventually
run
into
that
where
they
have
a
problem
where
there's
no
way
to
bypass
it
or
to
say
okay,
but
for
this
merge
request,
we
need
an
exception
and
we
need
an
approval.
D
D
Think
the
one
consideration
that
I'd
also
want
to
see
is
met
here
is
that
we
still
need
to
provide
a
way
for
the
security
team
to
come
in
and
essentially
bypass
either
certain
vulnerabilities
or
bypass
the
check
under
certain
conditions,
to
let
the
merge
request
be
merged
in
without
having
the
only
way
for
it
to
be
merged.
In
is
for
the
vulnerability
to
be
fixed.
A
A
But
if
we
turned
on
this
forget
lab,
the
appsec
team
would
quit
because
they
would
be
they'd
have
to
go
into
every
Mr
instead
of
ones
they're,
just
pinged
it
and
say
I'm.
Having
trouble
with
this.
Can
we
merge
this
and
that's
the
allow
override
aspect
you
could
even
tie
that
to
who
can
dismiss?
If
you
have
a
group
of
people
who
can
override
you
can
tie
that
to
okay,
these
people
are
the
only
ones
that
can
dismiss
a
vulnerability.
B
Andy
I
really
like
that
you're
thinking
about
shifting
left.
That
seems
really
important
when
I
asked
for
a
scenario
like
that's
the
kind
of
thing
I
was
looking
for,
like
tell
me
a
little
story
here
about
what
I'm
seeing
and
why
and
why.
This
is
important
and
how
I'm
going
to
go
through
this
flow
and
how
it's
going
to
impact
this
part
of
the
team
and
that
part
of
the
team
and
I
think
that
would
help
us
all
to
kind
of
understand
what
you're
thinking
is
here.
B
B
The
request
is
going
to
be
to
deliver
a
couple
of
iterative
improvements.
Improvements
pardon
me
against
this,
so
this
does
not
mean
the
entire
thing
has
to
be
delivered
in
Q3,
but
just
like
I
think
we're
delivering
one
little
piece.
This
quarter.
We
need
to
deliver
a
couple
more
pieces
next
quarter,
so
I
want
to
get
y'all
thinking
about
that
now.
D
B
I,
don't
think
so
because
David
made
Hillary
and
made
the
owners
on
this,
so
that
could
be
a
conversation
to
have
that
I'll
say
that
is
not
I
I,
don't
allocate
development
resources
so
I
don't
want
you
to
think
that
I'm,
the
the
like
the
final
word
on
this,
but
that
is
not
the
impression
I
have
I.
F
Andy
in
your
conversations
with
Kai
and
that
team
has
he
given
you
any
indication
of
if
he
believes
that
this
is
falling
within
the
scope
of
the
Court
review
team
or
his
understanding
that
this
is
falling
within
the
scope
of
government?
Do
you
know.
A
D
I
think
we
need
to
be
really
crisp
about
defining
the
ownership
there
like
if
we're
talking
about
the
you
know
improving
just
that
security,
merge,
request
widget,
like
that's
the
piece
that
currently
falls
under
govern.
If
it's
Within,
you
know-
and
this
is
a
redesign
right
so
that
widget
doesn't
really
exist
anymore.
So
I
guess
we'd
have
to
figure
out
how
and
where
do
we
draw
those
lines
in
the
future?
D
Is
it
just
that
security
tab
under
the
checks,
tab
that
that
would
belong
to
govern
or
something
else,
I
think
we
should
figure
that
out?
It
seems
like
the
the
first
iterations
of
the
new
structure
would
be
generic,
though
across
all
types
of
checks.
So
that's
why
I
was
suggesting
that
it
seems
like
it
would
be
a
much
better
fit
to
put
that
under
create,
but
I
guess
we
could
see,
if
maybe
there's
some
piece
of
that.
That
would
make
sense
independently
for
government
to
work
on.
B
C
Yeah,
just
real
quick,
my
number
one
priority
would
be
data
accuracy,
it's
a
six
month.
Long
thing,
that's
projected
would
love
to
see
that
accelerated.
If
we
want
to
do
UI
specific
changes,
then
overview
refinement.
Specifically
the
Mr
merge
widget
that
we've
been
talking
about
here
and
then
Andy's
been
talking
about
establishing
a
setting,
so
I
would
recommend
those
two
things.