►
From YouTube: Secure UX, ideation: introduce group license compliance
Description
00:00-01:56 background context
01:56-03:07 problem and ideation
03:07-08:06 design review
Related issue: https://gitlab.com/gitlab-org/gitlab/issues/202224
Problem validation issue: https://gitlab.com/gitlab-org/gitlab/issues/7149
A
Hi
I'm
Kyle
from
the
secure
UX
team,
with
a
focus
on
software
composition.
Analysis
today,
I
just
want
to
take
a
look
at
some
of
our
latest
efforts
in
license
complaints,
and
this
issue
we're
looking
at
is
the
introduction
of
group
license
complaints.
This
stems
from
a
proposal
of
our
ongoing
efforts
with
problem
validation
on
on
license
compliance
at
a
group
level,
and
so
I'll
just
walk
through
some
of
this.
A
For
the
context
of
the
background
here,
the
problem
validation
is
really
trying
to
get
an
idea
of
what
direction
we
want
to
go
in
for
group
license
compliance
that
would
include
how
users
would
apply
license
policies
from
a
group,
or
instance,
level
how
that
would
affect
the
project
level,
given
the
current
functionality,
and
so
you
know,
how
would
policies
make
overrides
to
project
level
can
can
project
levels?
Do
that?
What
are
the
user
expectations
from
the
group
an
instance
level?
A
These
are
the
things
we're
looking
at
with
some
research
issues
here
and
we're
gonna,
take
a
look
at
an
opportunity,
canvas
and
and
keep
digging
into
how
we
can
dog
food,
but
in
the
meantime,
there's
actually
a
couple
things
that
we
can
do
to
build
a
foundation
for
this,
no
matter
what
direction
this
goes
in
like
I
say
here
there.
Let's
say
that
applying
policies
with
or
without
the
user
interface,
even
the
common
denominators.
We
want
to
bring
the
awareness
of
what
projects
have
license
scanning
and
what
the
policies
are.
A
A
If
an
organization
wants
to
see
what
projects
have
license
compliance
scanning
from
a
bird's
eye
view,
there's
no
way
to
do
that.
Currently
they
would
have
to
go
project
to
project
well,
the
prerequisite
is
that
license
scanning
is
even
configured
properly
at
the
project
level.
Then
they
would
have
to
apply
prod
policies
project
by
project,
so
at
least
at
the
group
level,
the
introduction
could
give
them
a
bird's-eye
view
of
what
projects
are
even
being
scanned
and
what
projects
are
not
being
scanned,
and
then
we
can
link
them
to
the
project,
license
compliance
page.
A
A
But
on
the
compliance
dashboard
we
see
here
that
it
it
specifies
projects
not
configured
with
license
compliance
more
and
for
me,
if
the
user
click
that
it
would
send
them
to
documentation
so
that
they
can
learn
how
to
set
it
up.
If
they
were
interested
in
doing
so,
and
if
they
click
the
respective
project,
it
could
take
them
to
the
project
as
expected.
A
But
if
the
configuration
page
if
and
when
that
is
able
to,
we
have
a
proposal
out
there
to
create
a
merge
request
to
set
it
up
to
set
up
a
certain
skin,
we
could
direct
them
right
there
to
to
set
it
up.
This
would
be
a
preferred
flow
because
they
would
see
that
it
was
untested
from
the
group
level.
They
would
then
navigate
here
and
then
from
here.
They
could
set
it
up
to
that
project.
A
Okay,
in
the
scenario
that
in
the
section
here
that
it
says,
testing
so
projects
that
are
testing,
we
could
link
them
directly
then
to
the
respective
projects
license
compliance
page.
The
benefit
here
is,
though
our
license
compliant
at
a
project
level
is
very
minimal.
We
linked
them
directly
to
this
page.
A
That
shows
the
scanning
result
in
the
policy
section
where
they
can
create
policies,
but
maybe
in
the
future
they
could
also
export
a
list
of
of
the
findings
as
well
for
auditing
purposes
and
then
also
put
down
here
and
we'll
see
how
this
is
kind
of
the
foundation.
For
it
is
this
aside.
However,
it
evolves
it
could
evolve
to
show
applied
policies
from
projects,
that's
something
we
could
actually
do
today.
Something
we
can't
do
today
is
showing
the
actual
license
scanning
results
at
the
group
level.
So
that's
why
linking
them
is
valuable
here.
A
If
we
wanted
to
show
it
license
scanning
results
at
the
group
level,
we
would
have
to
build.
Do
some
database
changes
there?
My
understanding
is
that
would
take
two
to
three
months
at
least,
but
we
haven't
even
valid
validated
if
that's
a
problem
or
a
customer
desire,
so
that
goes
back
to
the
problem.
Validation
that
we're
taking
a
look
at
is
that
desirable.
A
The
other
thing
is
that
would
be
would
be
helpful
at
this
level
is
to
show
what
projects
detected
out
of
compliance
licenses.
So
here
we're
just
telling
them
if
it's
testing
or
not
that's
a
small
step,
we're
taking,
but
in
the
future
if
policies
were
applied
and
if
projects
had
out
of
compliance
licenses
that
were
detected.
A
This
area
on
this
dashboard
could
communicate
that
and
at
least
link
them
to
that
respective
project,
and
then
they
could
identify
which
one
of
these
licenses
detected
were
out
of
compliance,
which
would
have
been
out
of
compliance
from
the
policies
that
were
assigned.
So
we
can
see
that
this
small
step
is
really
a
building
block
to
give
the
user
or
the
customer
better
a
bird's
eye
view
of
compliance
license
compliance
across
their
projects.