►
From YouTube: Govern:Security Policies group discussion 2023-01-17
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-
this
is
govern
security,
pulse
this
weekly
group
discussion
and
let's
get
started
with
the
items
from
the
agenda:
hey
Camellia,
so
the
first
item
is
from
Alexander
and
that's
the
demo.
So
the
first
demo
is
that
the
renewed
push
on
super
troll
based
approval
action
for
Scandal
policies.
This
is
very
long
name,
but
you
can
take
a
look
at
the
group
and
the
project
book
on
staging
and
you
can
verify
how
they're
working
so.
B
A
And
Alexander's
status
is
that
there
is
an
EMR
to
support
existing
policies
and
he's
working
on
the
ux
box
for
this,
depending
on
the
state
of
the
back
end,
he
may
release
the
ux
refactor
by
itself
and
then
released
Edition
after
all
selection
afterwards.
So
keep
in
mind
when
we're
gonna
take
a
look
at
these
things.
So
in
terms
of
planning
breakdown,
there
are
three
items
ready
for
planning
breakdown
and
we
can
talk
about
them
today.
C
C
This
is
a
pretty
large
epic,
and
actually
we
probably
want
you
know.
When
we
go
through
refinement,
we
probably
are
going
to
want
to
break
it
down
into
some
smaller
sub-opics
I
assume,
because
some
of
these
pieces
can
be
released
individually,
I'm
having
trouble
sharing
my
screen,
but
basically
there's.
The
first
part
is
a
pretty
large
front-end
refactor
and
that
actually
can
be
done
without
the
back
end
at
all.
So
you
know
we're
looking
to
just
redesign
the
way
those
rules
are
created
and
edited.
C
You
know
you
notice
the
really
the
new
content
here
is
the
age
and
attribute
sections.
So
we
could
potentially
split
this
up
and
just
do
a
front-end
refactor
of
everything
above
that
point
and
then
add
in
the
agent
attribute
afterwards
a
couple
other
things
as
well
like
we
found
even
recently,
it's
been
really
confusing
to
users
filtering
based
off
of
vulnerabilities
that
are
newly
detected
versus
previously
existing,
and
so
that's
why
we're
splitting
those
into
two
and
right
now
our
newly
detected
just
captures
everything.
C
We
don't
have
an
option
to
pick
between
new
newly
detected
and
needs
triage
or
newly
detected
and
dismissed,
because
you
can
actually
dismiss
a
vulnerability
right
there
within
the
merge
request
itself
and
we
aren't
able
to
differentiate
between
ones
that
are
dismissed
in
the
merge
request
versus
not
so
actually
I'm.
Realizing
this
drop
down
doesn't
show
it,
but
under
that
top
one,
the
new
it
would
only
have
two
options
there,
because
you
can't
have
things
that
are
confirmed
or
resolved
that
are
not
yet
in
the
default
Branch.
C
C
I'm,
assuming
that
you
know
I,
don't
really
know.
This
is
kind
of
an
open
question
after
the
team,
but,
like
I,
don't
know
what
fields
are
available
to
us
currently
on
the
for
the
vulnerability
report,
but
ideally
would
be
able
to
say
okay,
this
has
been,
you
know,
detected
and
has
existed
in
the
default
Branch
for
30
days,
and
now
we
want
to
start
blocking
new
merge
requests
from
coming
in
until
they've
there's
a
merge
request
that
fixes
it.
C
And
then
the
last
one
is
adding
in
just
some
other
freeform
attributes,
and
these
are
a
little
bit
tricky
because
they
don't
all
apply
to
all
types
of
scanning.
So
I
think
we
have
like
a
tool
tip
to
help
clarify
this,
but,
like
fix
available,
for
example,
isn't
really
applicable
for
certain
types
of
scams
like
desk
scans,
I.
Don't
think
you're
ever
really
going
to
see
a
fix
available
for
a
dast
scan.
C
You
know,
so
the
fix
available
would
only
apply
to
I
believe
it's
only
container
and
dependency
scanning,
but
we
might
want
to
just
double
check
on
that,
but
I'm
pretty
sure
that
that
would
be
the
only
thing
that
that
would
apply
to
so
I
think
we
have
a
tool
tip
to
make
that
clear
in
the
UI
and
then
false
positive
would
be
based
off
of
that
false
positive
flag,
which
right
now
with
vet,
we're
able
to
identify
false
positives
for
sast,
and
then
we
also
have
some
partners
that
you
can
use
with
gitlab
that
can
identify
false
positives
for
container
and
dependency
scanning
Auto
resolved.
C
C
C
I
think
that's
all
I've
got
for
this
one.
Unless
there
are
questions
here.
C
Yeah,
okay,
so
yeah
this
next
one
also
is
this:
one
is
almost
entirely
front
end,
so
we've
caught
a
lot
of
front
end
work
going
on
right
now.
This
is
where
Camellia
is
redesigned
the
look
and
feel
for
our
scan
execution
policies,
and
so
we're
switching
things
up
instead
of
rules
and
actions
were
replacing
it
with
actions
and
condition.
It
looks
like
is
what
we
decided
on
and
then
you
know
just
some
other
ux
changes
here,
you'll
see
as
part
of
this
design.
C
There's
you
know
this
area
that
says
require
a
cim
will
block
to
run
again
like
the
way
we're
doing.
Design
now
is
for
that
the
end
State,
and
so
that's
actually
out
of
scope
for
this
particular
one,
because
that's
net
new
functionality-
and
we
have
a
separate
epic
to
add
that
in,
but
this
is
just
showing
how
the
design
would
work
with
all
of
these.
You
know
different
scenarios,
so
this
one
is
just
focused
on
redesigning
the
ux
to
align
it
with
the
monks.
C
C
All
right,
so
this
one
right
now,
it's
a
little
bit
tough
for
users
to
write
a
policy
that
accurately
identifies
the
right
Branch
because
you
know,
especially
if
you're,
creating
a
group
level
policy.
C
If
you
define
something
that
says
well,
I
want
this
to
work
against
the
main
branch
their
Branch
could
be
named
Maine,
it
could
be
named
Master.
It
could
be
named
something
else.
You
know,
and
so
it's
really
hard
to
know
what
that
is.
Plus
users
can
rename
those
branches,
and
so
this
is
kind
of
the
first
step
in
a
two-step
process,
to
help
solve
this.
C
Okay
right
now
we're
adding
in
the
ability
to
select
default
Branch.
So
this
is
the
main
addition
with
this
one,
where
it
doesn't
matter
what
that
branch
is
named,
but
we
just
always
are
able
to
have
the
policy
applied
to
the
default
Branch
whatever.
That
is
the
next
step
after
this
would
be
to
add
in
a
new
feature,
to
also
be
able
to
select
all
tracked
branches,
and
this
is
a
much
larger
effort.
So
we
we
have
this
split
up
into
two.
C
We
can
kind
of
talk
about
this
separately,
but
as
part
of
that
first
effort,
we're
probably
going
to
want
to
redesign
the
way
we
do
the
yaml
and
it
might
be
a
little
bit
tricky
because
we
need
to
think
about
how
we
can
do
it
without
introducing
a
breaking
change,
but
likely
we're
going
to
need
to
change
that
branches.
You
know
we
somehow
we
need
to
add
in
a
field
there
where
users
can
pick.
C
Oh
I
want
this
to
apply
to
the
default,
Branch
or
all
protected
branches
or
all
tracked
branches
or
I
want
to
list
out
specific
branches.
So
we
need
to
like
introduce
another
field
there,
so
that
users
can
pick
which
type
they
want
to.
You
know
which
type
of
branches
that
they're
looking
for
and
then
they
can
identify
either
specific
branches
or
exceptions
or
things
within
that.
So
we
might,
you
know,
step.
C
While
we're
on
this
I'll
just
speak
to
the
tracked
branches
as
well,
so
again
we
have
a
lot
of
challenges
because
users
are
able
to
circumvent
policies
as
a
maintainer,
because
you
can
just
go
in
and
unprotect
a
branch
or
you
can
rename
a
branch
and
then
you
can
apply
the
protection
again
and
so
we've
actually
seen
you
know
in
the
real
world
cases
where
maintainers
do
that
unprotect
they'll
merge
something
in
and
then
they'll
go
and
protect
it
again
and
that
way,
they're
able
to
bypass
the
policy
and
from
a
compliance
perspective,
that's
very
problematic,
because
now
you
have
to
go
through
your
audit
log
and
identify
all
instances
where
that
happened
and
like
it's
a
really
big
headache
for
users.
C
You
know
compliance
teams
to
go
and
follow
up
on
all
of
that,
and
so
this
new
concept
of
tracked
branches
is
that
once
a
branch
is
made
protected,
it
becomes
tracked
and
it's
tracked,
Forever
After
there's
no
way
to
make
a
branch
not
tracked
once
it's
tracked,
so
it's
a
one-door
one
directional
thing:
there's
no
undo
button.
In
other
words
like
once
you
make
a
branch
track,
protect
it.
It's
always
tracked,
and
so
it
shouldn't
matter
if
the
branch
is
renamed
or
if
it's
unprotected
or
anything,
it's
always
tracked.
C
You
know
the
only
thing
that
would
get
rid
of
that
is
actually
deleting
the
branch
entirely
and
so
because
we
that
really
solves
all
those
work
around
loopholes
that
you
know
users
are
able
to
go
through
to
unprotect
branches,
but
of
course
it
comes
with
the
risk
of
somebody
protecting
a
branch
on
accident,
and
then
they
unprotect
it.
But
now
it's
tracked
and
now
that
security
policies
apply
when
they
shouldn't,
and
so
the
proposal
here
is
to
allow
users
to
Define
exceptions
as
part
of
their
security
policy
again.
C
So
that
way
we
have
full
separation
of
Duties.
The
development
project.
Maintainers
can't
add
the
exceptions.
It's
only
the
security
and
compliance
team
that
can
authorize
exceptions
to
the
list
of
tracked
branches.
Anyway,
that's
a
lot.
I
have
recovered
like
four
epics
here
today,
but
I'll
stop
for
a
minute.
Any
thoughts,
comments,
questions
on
that
roadmap.
A
Yeah
with
tracked
branches,
we're
still
talking
with
source
code
group
because
they're
developing
something
similar
and
we
probably
had
something:
we're
gonna,
either
reuse
that
or
actually
like
use
the
whole
feature
that
they're
building
so
I,
don't
know
if
it'll
be
blocker
for
this
epic
or
not,
but
we'll
have
to
evaluate
that.
But
we
have
ongoing
discussion
with
them
about
it.
A
But
yeah
like
the
the
first
epic
that
we've
discussed
the
dri
for
this
sashy
and
the
last
two
the
dri
is,
is
Dominic
and
Alexander
is
derived
for
every
front-end
stuff
that
we're
currently
working
on
all
right.
I
have
no
more
questions,
especially
Camelia.
C
Yeah
I'll
just
add
on
that
last
topic
that
my
best
understanding
of
what
they're
doing
is
that
they're
just
refactoring
the
code,
so
that
and
I
could
be
wrong.
But
as
best
I
understand
it,
branches
and
protected
branches
are
currently
being
tracked
as
two
separate
objects,
instead
of
one
and
so
they're
making
it
so
that
branches
is
just
a
single
object
and
then
whether
or
not
it's
protected
is
an
attribute
of
that
object.
C
So
you're
right
that
very
well
may
be
a
blocker,
because
you
know
we
don't
want
to
introduce
a
third
object
of
tracked
branches
like
that.
That
would
be
a
lot
instead.
This
will
likely
just
be
an
attribute
on
the
Branch's
object
once
they
consolidate
those
two.
B
B
C
So
it's
a
one
door
thing.
So
as
soon
as
you
make
a
branch
protected,
it
becomes
tracked.
Forever
After.
C
But
if,
at
the
top
you
selected
instead
of
all
protective
branches,
you
could
pick
default
Branch,
where
you'd
have
a
new
option
there
for
all
tracked
branches,
and
that
way
it
would
include
not
only
the
protected
branches,
but
it
also
include
unprotected
branches
that
had
been
protected
in
the
past
yeah,
but
yeah
like
that.
Yeah.
B
I
think
those
are
like
actions,
but
the
least
here
is
individual
Branch.
If
user
choose
one
and
they
will
just
change
to
one
so
I'm
thinking
like
that,
they
make
sense
to
like
also
indicate
here.
If
it's
like
important
for
users
know
which
branch
is
tracked
and
which
branch
is
protected.
C
C
You
know
yeah,
that
is
the
idea
exactly
and
then
users
would
be
able
to
Define
exceptions
to
all
tracked
branches,
so
it
does
work
a
little
bit
differently
than
some
of
the
others
where
you're
saying
these
are
the
branches
I
want
to
to
apply
the
policy
to
now
you're
saying
I
want
to
apply
it
to
all
track
branches,
except
for
these
named
branches.
So
it
is
a
little
bit
different.
A
All
right,
thank
you,
so
from
other
discussions,
one
important
thing
that
we
need
to
talk
about
this
license
approval
policies.
I
just
want
to
emphasize
that
I
believe
this
is
them
also
that
we
need
to
have
something
shipped
right.
This
or
next
milestones.
C
15
9
yep,
so
this
one
but
the
next
one
that's
starting.
Maybe
it
starts
today,
I'm
not
sure
the
59
milestone.
A
So
at
least
it
should
have
the
same
features
we
don't
have
to
add
additional
features,
but
at
least
just
to
replicate
the
same
features
using
this
kind
of
result.
Policies.
That's
our
goal
for
this
Milestone
I
will
take
a
look
at
the
at
the
Epic
I'll.
Take
a
look
at
all
the
issues,
just
to
make
sure
that
it's
all
stated
there
that
we're
focusing
now
on
on
just
having
the
same
functionality
and
then
improving
this
in
the
next
Milestone.
A
So
yeah
Alexander
is
saying
that
Fernando
is
not
a
part
of
of
this
doc,
so
I'll
need
to
talk
to
him
and
make
sure
that
his
work
is
finished.
But
I
was
reviewing
some
of
his
Mrs
recently
and
I
believe
like
most
of
it.
It's
finished
so
as
soon
as
we'll
find
something
new
during
our
work
on
the
back
end,
we'll
have
to
talk
with
him
and
and
discuss
what
we
need
to
improve
on
the
front
end,
but
I
don't
believe
there
will
be
anything
based
based
on
what
I
saw,
but.
C
A
Now,
as
soon
as
you
have
kind
of
policies,
it
should
be
disabled
for
you
to
have
license
check,
or
we
should
just
say
that
in
documentation
that
you
cannot
use
both
because
it's
I
know
it's
dangerous
and
it
may
guide
you
to
some
wrong
actions
in
terms
of
your
approvals,
like
I.
Just
wanted
to
clarify
that
so.
C
That
was
the
same
thing
that
we
did
for
vulnerability
check
when
we
removed
it,
because
we've
designed
all
of
these
to
be
additive
like
they
don't
actually
conflict
with
each
other.
So
you
can
have
your
license
check
and
you
can
have
a
license
approval
policy
and
they
should
be
able
to
both
apply
to
the
merge
request
simultaneously.
It's
just
one
additional
approval.
A
Yeah
yeah,
the
one
thing
that
we'll
probably
have
to
work
on
is
once
you
have
something
config
license
approval
configuration,
it's
called
the
result
policies.
A
Then
it
will
show
up
in
the
project
settings
now
in
approval
sections,
but
you
should
not
be
able
to
edit
that
remove
that
the
same
as
we
as
we
did
for
for
account
finding
approval
rules,
because
it
will
work
only
like
one
directional
like
it
will
be
visible
on
this
page,
but
you
should
not
be
able
to
edit
that
using
like
license
check
as
soon
as
you
are
using
the
this
controlled
policies
with
license
approvals,
enabled.
C
No
so
they're
two
separate
totally
separate
things.
Okay,
so
you
can
still
edit
license
check.
We
should
have
no
change
to
the
license
check
functionality
that
exists
today.
That
should
just
continue
to
exist,
like
I
said,
with
zero
changes
and
maintainers
can
still
change
it
and
like
you
should
be
able
to
have
a
license
approval
policy
and
edit
your
license
check
policy
too.
A
Okay
got
it
got
it.
Thank
you
all
right,
so
that
was
the
last
item.
I
believe
yeah.
The
right
amount
I'll
stop
recording
to
talk
about
the
other
item.
Okay,
so
thank
you.
Everyone
and
let's,
let's
stay
for
a
minute,
to
discuss
the
last
item
on
the
agenda.