►
Description
https://gitlab.com/groups/gitlab-org/-/epics/4598
context: 0:00 - 1:40
ideation: 1:40 -10:30
A
Hi,
this
is
just
some
early
ideation,
the
the
product
management
and
product
design
team
for
the
new
forms
protect
and
the
on-demand
das
team
is
collaborating
on
creating
a
new
mvc
policy,
so
policies
are
currently
in
threat,
monitoring
the
current
ux's
in
security
and
compliance
and
threat
monitoring,
and
these
only
relate
to
container
network
security.
A
So
these
are
actual
policies
for
container
network
security,
and
if
you
want
to
edit
them,
you
can
or
see
more
details
about
them.
You
can
open
up
a
side
drawer
here
and
then
you
can
create
a
new
policy
from
here.
It's
a
sort
of
conditional
statement,
but
also
the
ability
to
direct
directly
do
it
in
the
ml
mode.
So
this
is
the
current
ux.
What
this
is
this
epic
is
about
is
actually
the
mvc
to
add
a
another
policy,
and
that
policy
would
be
a
recurring
dashed,
on-demand
scan.
A
What
makes
it
a
policy
is
the
recurring
aspect
of
it.
If
it's
just
a
one-time
scan,
that's
not
considered
a
policy
even
if
it's
a
one-time
scheduled
scan,
that's
not
a
policy,
but
since
it's
recurring,
that's
what
in
this
nbc
we're
considering
it
as
a
policy
in
future
mbcs,
there
may
be
same
sched
the
ability
to
schedule
other
scanners,
but
for
this
one
it's
just
focusing
on
desk
and
making
a
recurring
one.
A
Okay,
so
thinking
through
some
of
the
changes
that
this
would
be
some
of
the
questions
around
it
across
the
teams
that
I
have
for
the
task
team,
anna
bell
and
derek
just
to
think
about.
This
is
again
just
focused
on
some
ideation
and
and
some
changes
that
would
result
in
in
this
nbc
one
would
be
information,
architecture,
here's
the
current
one
that
we
see
today.
I
just
want
to
point
out
a
related
one
in
issue,
two
one,
five,
six
three:
five,
which
actually
merges
the
dependency
list
and
license
compliance
list.
A
So
it
just
sort
of
tightens
up
that
area.
There's
a
discussion,
that's
ongoing
with
that
somewhat
related.
Only
also
because
license
compliance
also
has
a
policy
section.
So
there
may
be
that
aspect
that
eventually
merges
into
the
protect
policies:
future
npcs,
okay,
let's
say
that
doesn't
happen
or
it
happens
later
or
what
not
just
looking
at
the
current
information
architecture.
A
A
Some
of
the
columns
may
not
work
like
environment
may
not
be
relevant
for
that
or
there
may
be
another
relevant
data
point
there
for
that,
like
what
the
pro,
what
url
the
the
profile
is
targeting,
I'm
not
sure
if
it
would
go
under
that
and
then
how
status
is
so
as
we
grow
these
policies
and
as
we
merge
different
like
network
policies
and
then
adding
the
ability
to
schedule
scans,
we'll
just
have
to
think
about
how
these
columns,
like
the
data
that
we're
showing
to
identify
these
policies,
how
it
scales,
because,
as
we
add
new
things,
there
may
be
areas
like
this
environment,
one
where
maybe
it
doesn't
scale
so
well
or
it's
relevant
for
one
rule
and
not
relevant
for
another.
A
So
the
questions
I
have
here
as
for
death
stream
is
what
might
be
most
appropriate
for
the
naming
convention
for
the
task
policies
and
I'm
sorry
this
shouldn't
be
showing
overview
here.
That's
that's
just
a
state
quickly,
building
this
out,
but
some
other
questions
too,
is
that
the
as
we
saw
in
the
prototype
there
was
when
you
look
at
policies,
there's
a
fly-out
drawer.
That
gives
you
some
summary
details
if
we
were
to
follow
that
same
pattern.
A
Here
is
what
are
the
key
details
that
we
would
need
for
the
profile
of
the
recurring
views,
so
it's
just
taking
a
look
at
what
the
current
edit
page
looks
like
on
on
demand
and
bring
that
into
to
this,
and
it
may
may
require
linking
to
a
dedicated
page,
but
just
listing
out
some
of
those
details
would
be
helpful
for
that
to
know
what's
next
in
terms
of
the
actual
creation.
A
A
If
they
chose
that
one,
then
we
just
need
to
identify
what
are
the
key
inputs
that
they
need.
There's
two
different
directions
here
there
may
be
an
already
existing
profile
so
somewhere
we
can
identify
that
and
then
create
the
rule
and
but,
but
I
think
the
other,
the
other
scenario
would
be
if
they
need
to
create
a
new
profile.
A
A
I'm
not
sure
I
I
want
to
just
go
back
and
focus
on
what
those
required
inputs
are,
and
then
we
can
come
back
to
the
ui
elements,
but
just
wanted
to
point
these
out
as
kind
of
some
ideation
around
it
and
then
also
with
the
creation
process.
I
think
that
the
main
thing
to
focus
on
now
is
just
the
actual
conditional
statement
so
going
back
to
the
prototype
here
for
a
second
is
we
have
the
conditional
statement
for
runtime
container
policies
and
it
it
goes
like
this.
A
If
this,
then
this
so
looking
at
scheduled
scans-
and
this
is
just
the
prototype-
it's
not
the
suggested
one,
but
just
to
get
an
idea
for
how
it
works.
It's
like
schedule,
the
br
branch
environment
to
be
scheduled,
then,
and
then
down
here.
You
can
select
yes
well,
that
that
doesn't
really
it's.
It
won't
work
so
well
because
each
scanner
may
require
different
sort
of
conditional
rules.
So
just
looking
at
it
like
this
in
in
this
way,
I
I
think
can
help
us
identify
that
first
sentence.
A
We
have
so
I
grade
out
the
parts
that
are
not
part
of
this
mvc
and-
and
these
could
be,
this
could
be
the
first
selection,
and
so
the
only
selections
here
since
this
would
be
the
only
new
rule.
That's
there
for
the
scheduled
scan
is
schedule
das
and
then
profile
name.
This
could
be
the
area
where
we
get
that
input
from
the
user.
Now
we'll
have
to
think
of
once
we
get
to
the
user
interface,
we'll
have
to
think
about
the
flow
to
create
a
new
one.
A
If
a
profile
doesn't
exist,
that's
going
back
to
maybe
that
modal
or
whatnot,
I'm
not
sure,
if
that's
the
right
one,
but
just
just
kind
of
focus
on
the
conditional
rules
so
schedule,
das
profile,
name
to
be
scanned
and
then
weekly
daily
hourly.
A
The
questions
here
is
maybe
for
the
mvc
is:
what
is
our
introduction
mvc,
which
one
makes
most
sense?
Do
we
need
to
cut
this
down?
A
Do
should
we
just
have
scheduled
das,
then
the
only
input
is
profile
name
to
be
scanned
weekly
or
where
are
we
on
capabilities
for
the
scheduling
and
recurring
of
it
could
be
a
question
for
the
das
team,
but
also
a
question
for
for
sam
or
kind
of
a
question
for
all
of
us
and
on
how
we
want
to
do
that
and
what's
within
the
scope
here
like,
I
said,
these
ones
that
are
grayed
out
kind
of
just
show
later
iteration
so
license
scanning
could
have
a
similar
pattern,
but
the
inputs
may
be
different.
A
For
example,
one
that
comes
to
mind
is
container
scanning
the
inputs
and
not
wouldn't
be
profile
name,
but
maybe
it
could
be
what
emit
what
container
image
that
it's
to
target?
Maybe
all
of
them
there
could
be
cases,
multiple
images
just
to
show.
So
I
would
say
that
this
would
be
the
key
focus,
and
then
we
can
go
back
to
the
ui
and
take
a
closer
look
at
that.
A
Okay,
then,
the
fifth
aspect
of
focusing
on
is-
and
maybe
we
can
adopt
the
pattern.
That's
in
existence
for
on-demand
scans
is
how
are
we
displaying
the
results
when
they're
when
they're,
when
the
scheduled
scan
has
done
so
since
there's
a
recurring
one?
Let's
say
it's
weekly,
you
know
we'd
want
to
show
log
of
those
weekly
recurring
ones
and
what
is
sort
of
the
audit
trail
or
what?
Where
can
the
results
be
seen?
I
understand
that
I,
I
think
that
it
goes
view
results
now
and
then
they
can
go
to
the
pipeline
page.
A
So
it's
just
adopting
that
pattern
and
then
I'm
just
showing
the
details
page
here
again.
Maybe
this
is
where
we're
showing
the
log,
because
if
it's
recurring
what
if
they
want
to
go
to
the
one
that
was
three
weeks
ago,
if
it
was
weekly,
for
example,
so
just
some
thoughts
around
that
in
the
ui,
and
we
can
probably
just
you
know,
adopt
what
and
where
those
results
are
being
shown
currently
for
the
on-demand
desk
hands.
A
Okay,
so
that
that
is
the
rundown,
that's
where
the
ideation
is
so
far,
and
this
is
just
the
head
of
any
synced
meetings.
Okay,
thanks.