►
From YouTube: Govern: Security Policies Group Discussion - 2023-02-28
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
And
all
right,
hello,
everyone!
This
is
our
weekly
call
for
government
security
policies.
First
quickly
call
after
alignment,
so
our
team
is
a
little
bit
bigger.
Now
I
wanted.
We
didn't.
We
don't
have
anything
to
discuss
today.
I
sell
nothing,
I
mean
nothing
to
discuss
in
terms
of
like
product
changes
or
anything
like
that.
I
would
like
just
to
use
that
time
to
to
just
say
hello
and
welcome
to
everyone
to
join
us.
I
wanted
to
ask
each
of
you
to
say
just
few
words
about
yourself.
A
Even
if
you're,
like
a
new
team
member
or
already
joined
the
team
and
that's
the
first
thing,
I
want
to
start
with
so
I'm
going
to
start
with
myself.
My
name
is
Alan
purseski
I'm,
based
in
support
Poland
in
Central
Europe
I
am
I
used
to
be
staffed
back
in
engineer
for
container
security
team
and
threatened
sites
before
that
and
and
others
right
now,
I'm
interim
engineering
manager
soon
to
be
engineering
manager
without
the
the
prefix
and
yeah.
A
B
Sure,
yeah,
hello,
everyone
I'm
excited
to
be
joining
the
security
policies.
Team
I've
been
a
PM
at
gitlab
for
I
guess,
roughly
nearly
a
year
and
a
half
I'm
coming
over
from
the
Integrations
team,
where
we
were
working
on
our
slack
integration
and
some
of
the
jira
Integrations
but
yeah
looking
forward
to
join
the
team.
B
I
don't
know
if
I
have
much
else
to
share
today,
but
we'll
have
plenty
to
share
in
the
future.
All.
C
Sure
I'm
Sam
white
I'm,
the
group
product
manager
for
govern
I
previously,
was
also
the
PM
for
this
group,
so
I'm
in
the
process
of
transitioning
that
over
to
Grant.
D
Yeah
I'm,
originally
based
out
of
in
Chennai
in
India,
currently
I'm
living
in
Netherlands
and
Amsterdam,
so
I'm
working
as
a
backend
engineer
at
the
security
policies
team
back
then
it
was
container
security
I'm
almost
here
for
about
two
years
now
so
yeah
exited.
Have
you
all
here.
B
Hey
Sashi,
so
I
used
to
actually
work
with
a
group,
a
group
of
engineers
in
Chennai
in.
D
D
About
it's
awesome,
oh
and
also
Bala,
he's
from
tonight.
So
maybe
he
can
oh
cool.
E
Yeah
and
then
I'll
go
next,
probably
going
to
the
floor.
I've
been
with
kitlab
for
the
last
one
year
and
seven
months
and
coming
over
from
the
release
team
yeah,
like
we
discussed
I'm
from
Chennai
yeah
I
live
with
my
family
here,
yeah.
F
A
Great
okay,
thank
you.
Thank
you.
All
we
have
more
Engineers
coming
to
our
team.
We
should
have
like
three
more
back-end
one
more
content
and
one
full
stack
engineer
joining
next
week,
so
our
team
will
be
much
bigger
than
it
used
to
be
because
it
used
to
be
like
only
three
people.
Now
it
is
nine,
so
yeah.
It's
really
amazing
to
see
to
see
that
growth,
but
also
it's
a
huge
challenge
for
all
of
us.
Okay,
I
wanted
to
ask
you
about
their
planning
issue.
A
I
already
created
that
a
week
ago,
if
you
have
any
concerns
or
anything
like
that,
I
know
this
month
is
a
little
bit
slower
because
we're
doing
this
whole
transition.
Some
people
still
have
open
Mrs
in
previous
groups,
so
I,
so
they
will
finish
them
that
soon,
I
just
wanted
to
make
sure
that
will
aware
what
we
want
to
deliver
in
this
Milestone,
which
is
one
thing,
is
like
a
technical
debt
that
we
want
to
pay
off.
A
A
My
patient's
quick
dish
for
my
screen,
and
the
second
thing
is
this:
epic
support,
role-based
approval
action,
so
I
know
this
process
is
more
or
less
finished.
We
are
waiting
for
a
few
backend
improvements
and
changes
there,
but
it's
also
our
goal
to
to
release
it
this
Milestone
and
also
continue
to
roll
off
the
future
flag
for
license
approval
policies.
So
there
are
like
lots
of
things,
lots
of
different
features
that
you
would
like
to
deliver
in
next
Milestone,
so
I
just
want
to
make
sure
that
we're
all
aware
of
that.
A
Okay,
all
right,
so,
as
you
know,
if
you've
been
the
group
for
some
time,
we
haven't
been
using
this
call
a
lot
since
we're
already
collaborating
asynchronously,
so
we
usually
ended
up
as
having
a
coffee
chat
instead
of
having
like
group
call,
and
then
we
decide.
Okay,
let's
do
it
bi-weekly,
because
it
makes
more
sense,
as
we
have
Grant
as
we
have
more
people
joining
our
team.
A
I
wanted
to
to
change
it
to
be
weekly,
call
and
see
if
there's
anything
that
we
need
to
discuss
in
terms
of
like
the
product
or
technical
decisions,
or
anything
like
that.
So
that
will
be
our
opportunity
to
do
it.
It
will
be
nothing
to
to
work
on
and
nothing
to
to
discuss.
That
would
be
great
because
we
can
leave
it
as
the
coffee
chat
for
all
of
us,
or
we
can
just
do
it
bi-weekly
and
and
just
talk
when
is
there
need
to
talk,
so
that
would
be
great.
A
All
right,
that's
all.
There
are
two
read-only
items
that
we
don't
have
to
talk
about
right
now.
You
can
read
it
in
the
agenda.
E
B
I'll
raise
a
question
just
as
I'm
kind
of
getting
up
to
speed
I've
been
trying
to
to
get
a
better
sense
of
of
the
plans
on
changing
the
name
of
the
scan
result.
Policies
to
I
think
it's
a
merge
request.
Approval
policy,
so
I
wanted
to
get
a
better
sense
of.
Is
that
a
decision
completed?
Is
that
a
priority,
and
maybe
that's
more
for
Sam,
but
that
was
something
I
I
was
reserving
to
ask
you
Sam,
but
maybe
it
would
be
a
good
one
for
the
group
here.
C
Yeah,
that's
a
great
question:
it's
not
slated
for
this
Milestone,
so
the
priority
I
think
is
still
a
little
bit
to
be
determined.
We'll
probably
want
to
do
that
before
some
of
the
other
items
in
our
priority
list,
like
once,
we
add
in
I,
know:
Camellia
has
been
working
through
the
designs
for
all
of
that,
but
once
we
do
change
what's
currently
a
scan,
a
result
policy
to
be
able
to
select
any
merge
request
instead
of
just
license
scanning
or
security
scanning.
C
That's
really
the
point
where
we're
going
to
want
to
consider
renaming
that,
because
it
no
longer
only
applies
to
scanner
results,
it's
going
to
apply
really
to
any
security,
merge
request,
approval
type.
So
if
you're
like,
are
you
thinking
about
changing
the
name
like
instead
of
merge,
request
approval
policy
or
are
you
just
wondering
like
when?
Is
that
scheduled
for?
Because
it's
not
really
scheduled
right
now
at
the
moment,
yeah.
B
Well,
it's
a
little
bit
of
both
because
it
looked
like
as
we're
going
through
some
of
these
designs
that
it
I
was
wondering
if
it
was
kind
of
being
lumped
into
the
designs
and
and
some
of
the
planning
so
yeah
just
trying
to
get
a
better
sense
of
like
timeline
of
when
that
change
happens,
and
then
I
I
am
trying
to
understand
some
of
the
decisioning
around
how
we
name
it
because
it
seems
like
it
could
be
as
generic
as
security
policy
approval
or
security
approval
policy.
B
However,
we
want
to
say
it
or
it
could
be.
Merge,
request
approval
policy,
but
yeah
I
just
want
to
kind
of
make
make
sense
of
that
and
like
what
our
customers
will
be
seeing
and
how
it
applies
to
their
workflows
because,
as
I
was
reading
through
it,
I
was
also
wondering
if
code
review
approval
might
be
more
aligned
with
kind
of
the
step
in
the
process.
They're
they're,
making
they're
doing,
implementing
or
requiring
approvals
in
the
code
review
step
and
then
are
there
other
steps
where
we
might
use
different
terminology.
B
Or
is
this
generic
in
that
the
future
plans
Will
Roll
under
security
approvals,
and
we
should
use
maybe
where
we're
like
the
term
that
we're
leading
towards
so
maybe
even
more
generic
than
merge
request
approval
if
it's
potential,
if
there's
a
potential
for
approvals
to
happen
outside
of
the
merge,
request,
flow
or
code
review
process,
if
that
makes
sense,
so
yeah
just
trying
to
wrap
my
head
around
all
the
possible
areas,
approvals:
Could
Happen?
What
are
these
security
policies
get
enforced
and
then
just
the
terminology
that
we're
using.
C
Yeah,
those
are
all
good
questions
and
good
things
to
Think
Through.
So
right
now
it's
inside
of
this
overarching
Epic
of
allow
compliance,
enforcement
of
security
policies
and
right
now
the
whole
thing
is
still
in
design.
So
it's
definitely
not
finalized.
Yet
like
it.
There
certainly
is
room
to
change
that
the
way
the
scans
or
the
way
the
policies
work
right
now.
It
really
only
applies
to
merge
requests.
I
think
there
are
going
to
be
places
where
we
may
want
to.
C
You
know,
have
policies
apply
outside
of
merge
requests,
but
it's
not
likely
to
follow
the
same
format.
So,
for
example,
we
might
have
some
sort
of
push
rule
that
says
you
know,
reject
all
pushes
that
have
certain
secrets,
you
know
critical
or
higher
secret
detection
scans
run,
or
you
know
we
might
reject
things
on
push.
We
might
reject
things
on
deploy
into
production,
but
gitlab
as
a
whole
doesn't
have
like
a
great
approval
workflow
for
those
sorts
of
things,
and
so
it
would
be
really
hard
for
that
to
fit
into
the
current
policy
set.
C
Maybe
you
can
get
it
to
fit
in
I.
Don't
know
you
probably
will
need
to
consider
a
different
policy
type
for
those
things,
but
those
are
good
questions
to
ask
as
so
yeah.
It's
definitely
not
finalized.
You
can
still
change
the
name
there's
another
name
that
you
think
is
better.
Besides
merge
request
approval
policy
and
then,
as
far
as
timeline
I,
don't
think
we
actually
have
this
Epic
in
our
list
in
our
priorities
list
I'm,
not
quite
sure,
I.
C
C
B
C
B
And
so
when
it
comes
to
the
ux,
should
we
also
kind
of
batch
the
ux
to
for
the
independent
effort,
like
the
engineering
effort?
That
will
not
include
the
change
to
the
name
like
so
I?
Think
in
some
in
some
cases,
we'll
see
like
here
are
a
lot
of
changes
happening.
Here's
all
the
ux
and
one
Epic,
but
then
you
know
it
may
not
be
time
to
implement
the
the
name
change.
So
maybe
we
need
to
like
I,
don't
know
just
step
like
increment
the
designs
to
make
sure
we
know
what
we're
focusing
on
yeah.
C
So
we've
been
doing
our
design
a
little
bit
differently
compared
to
the
rest
of
the
organization
in
in
the
secure
and
protect
stages.
So
we've
been
doing
our
designs
in
what
we
call
ux
themes
and
that's
to
allow
the
designer
to
design
more
comprehensively,
instead
of
just
thinking
about
one
little
change
at
a
time.
C
It
allows
them
to
think
about
the
entire
experience
and
make
sure
that
that
all
works
together
and
then
once
this
ux
theme
issue
is
done,
then
that's
when
Camellia
will
go
and
split
it
out
across
all
of
these,
so
that
the
relevant
designs
for
each
iteration
are
on
each
individual
epic.
If
that
makes
sense.
Yes,.
C
So
yeah
we
have
basically
this
overarching
epic
and
then
it's
split
out
into
each
individual
iteration
that
we
can
release
independently
because
yeah,
like
I,
said
you
know,
some
of
these
changes
don't
have
anything
to
do
with
that
name
change,
and
so
we
can
make
this
independently
and
you
know
eventually
it
kind
of
all
ties
together,
but
yeah.
Those
designs
will
get
split
out
across
all
of
these
epics.
A
Right,
if
there
is
nothing
else,
thank
you
for
joining
enjoy.