►
From YouTube: Secure UX review: license compliance policy discovery
Description
The Secure team reviewing the current state of license compliance feature, discussing priorities, and outlining next steps.
License compliance list issue: https://gitlab.com/gitlab-org/gitlab/issues/13582
Discovery, license policy MVC: https://gitlab.com/gitlab-org/gitlab/issues/12941
A
The
objective
of
the
discovery
is
to
make
license
policy
visible
to
all
project
participants
in
the
UI
and
we'll
see
why
that
support
in
a
moment
improve
the
information
in
architecture.
We
have
some
UX
research
underway
at
the
moment.
Actually,
we've
had
just
a
couple
tests
today
where
we're
trying
to
test
how
the
navigation
is
going
with
that
we've.
Some
interesting
findings
so
far
and
simplifying
the
UI
to
accommodate
the
user,
with
different
permissions
and
jobs
to
be
done
and
we'll
get
in
to
why
that's
more
important.
A
So
currently,
our
UI
right
now
is
when
it
comes
to
license
compliance.
It's
just
in
the
merge
request
alone
and
I
just
want
to
verify
where
we're
now
recording
this
meeting
right,
because
I
know
those
something
from
last
time
we
were
yes,
okay,
cool,
so
you
can
always
see
this
feature
in
the
merge
request.
There
is
currently
some
work
being
done
on
clarifying
that
and
making
that
a
little
bit
better
experience
in
terms
of
what
is
being
seen
here,
but
that's
pretty
much
all
that
a
developer
might
see.
A
Otherwise,
a
project
maintainer
would
need
to
go
to
settings
in
a
project
and
then
go
to
like
CI
CD
and
then
license
compliance
and
that's
found
here
and
that's
the
extent
of
our
feature
at
the
moment.
So
that's
why
this
issue
here
of
that
we're
doing
an
implementation
right
now
is
a
big
deal
because
we're
bringing
it
we're
surfacing
the
licenses
we're
leveraging
our
license,
scan
something:
that's
okay,
yeah!
A
So
this
that's
that's
what's
happening
now,
something
that
makes
us
interesting
and
I
made
an
earlier
point
into
consolidating
our
UI
at
so
having
as
little
UI
as
possible
to
accomplish
many
jobs
to
be
done
for
as
many
different
users
as
possible,
a
thing
that
makes
it
a
little
bit
challenging
and
the
reason
why
license
compliance
is
separate
from
the
dependency
list
is
because
we
have
a
dependency
scan
and
the
license
scan
and
Tatiana
has
been.
Actually.
A
If
you
look
at
the
discussion
and
in
this
one,
she
actually
merges
some
of
the
findings
together,
because
we
in
the
last
milestone
added
the
ability
to
see
licenses
and
dependency
lists,
so
that's
coming
from
license
scanning
them
and
vice
versa.
So
we're
gonna
run
into
some
challenges
and
they
are
as
follows:
some
lists
that
we
see
in
one
list
or
the
other
may
not
may
not
have
the
components
linked.
So
that's
one
issue
and
actually
that's
a
wrong
link.
A
They
may
be
under
the
impression,
then,
that
these
lists
should
be
combined
because
we're
showing
licenses
wine
and
licenses
on
the
other
there's
cases
where
a
dependency
list
would
be
filled
up
and
a
license
list
would
be
empty.
So
we
want
to
try
to
get
ahead
of
that.
That
is
down
the
road,
though
I'm
just
adding
that
sort
of
complexity.
Another
thing
we've
been
doing
is,
we
have
ideated
from
you
may
remember
from
previous
sessions
on
some.
This
is
the
wrong
issue,
but
there's
a
classification
issue
out
there.
A
We
had
some
classification
terms
that
we
landed
on
the
most
essential
thing.
There
is
that
we
don't
want
to
use
the
term
approval
for
a
license,
because
we
don't
want
it
to
get
confused
with
the
approval
feature.
So
it's
a
pretty
I
would
say
that
this
kind
of
links
to
like
some
things
that
you
know
we
really
want
to
consider
things
that
are
happening
now.
A
So
the
user
has
gone
the
C
sed
in
settings
and
an
applied
policy
to
different
licenses,
and
so
now
that
we
have
a
list,
that's
shown
to
all
developers,
we
want
to
bring
what
that
policy
may
have
been
applied
to
that
list.
So
that's
gonna
be
one
thing
that
we
want
in
terms
of
it
showing
to
all
participants,
but
we
could
also
leverage
that
same
list
to
improve
our
information
architecture
and
simplify
our
UI
by
making
that
same
list
to
the
maintainer,
the
ability
for
them
to
apply
policy.
So
now
they
can.
A
They
experiences
a
lot
easier
because
they
can,
if
they
have
everything
configured
correctly
and
it's
supporting
languages
and
so
on.
The
maintainer
can
come
and
see
licenses
that
are
already
in
a
project
and
apply
classifications,
and
then
they
could
also
proactively
add
licenses
that
may
be
out
of
compliance
or
add
compliance.
A
So
that's
our
goal
with
this
discovery.
I
had
very
Kulemin
area
discussions
with
no
and
his
thoughts
were
immediately.
You
know
that
we
will
probably
need
to
break
these
up
into
different
issues.
I
will
know
more.
We
have
a
sink
Moe
and
Fernando
and
I
later
or
scheduled,
so
we'll
figure
out
what
that
game
plan
is,
but
some
of
the
considerations
that
kind
of
came
up
that
I
think
researching
and
product
we
could
maybe
get
together
and
figure
out
is
like
who
is
our
ideal
customer
for
this?
Since
so
much
is
out
there?
A
Who
do
we
want
to
prioritize
our
efforts
for
and
yeah?
This
is
like
I'm
saying
for
Moe,
but
what
I
mean
by
that
is
for
using
get
loud
as
a
test
project
like
let's
say
get
lab
was
our
customer.
After
talking
with
the
compliance
team
and
stuff,
we
have
some
technical
challenges
why
they
don't
use,
license
compliance,
but
let's
say
that
they
could
use
us
and
that
we
wanted
to
make
these
licenses
here.
A
That
gitlab
says
are
unacceptable
if
we
wanted
to
add
those
to
a
project
at
a
project
level,
it
wouldn't
be
such
a
terrible
experience
cuz.
This
is
just
for
the
get
lab,
ee
and
so
get
lab
could
go
to
that
project
and
apply
those
just
those
projects
and
those
could
be
blacklisted
or
whatever.
But
if
we're
going
for
larger
customers,
we
may
want
to
consider
thinking
about
adding
policy
at
a
group
level
or
yeah
where.
B
Is
that
issue
I
so
in
my
mind,
I
definitely
want
to
go
there,
but
I
sort
of
want
to
make
it
work
well
for
project
first
and
then,
as
soon
as
we
have
that
pattern,
I'd
love
to
then
see
like.
Can
we
roll
that
pattern
up
and
then
because
it's
gonna
get
more
complicated,
because
if
we
apply
it
at
the
group
level,
there's
gonna
be
a
couple
of
considerations
like
the
first
one
is:
am
I
setting
a
default
or
am
I
setting
a
force
and
what
I
mean
by
that?
B
Obviously,
there
needs
to
be
a
better
terminology,
but
if
I
set
something
in
a
group
level,
maybe
I'm
just
trying
to
set
like
a
default
and
you
can
change
it
at
the
project
level
or
maybe
I'm
saying
like
no
y'all.
This
is
company
policy.
This
is
the
minimum.
You
know
that
you
have
to
have.
You
can
add
more
at
your
project
level,
but
this
is
the
minimum,
as
opposed
to
the
default,
so
I
sort
of
want
to
have
a
pattern.
B
C
Agree
with
that
direction
as
well,
because
I
think
it'll
be
even
more
than
just
the
policy
stuff
I
think
security
scans
as
well
will
fall
into
that
as
we
start
selling
and
having
customers
at
larger
and
larger
enterprises.
The
individual
users
who
are
actually
using
the
project
building
things
are
going
to
be
different
than
the
people
setting
know.
Thou
shalt
use
SAS
license
compliance.
B
I
actually
consider
that
to
that
question
right
there
Sam
that
you
brought
like
you,
brought
up
an
excellent
point:
who's
the
user
who's.
The
target
customer
is
the
question
yes
and
I
think
it
really
depends
on
the
setting
the
policy
portion.
That's
going
to
be
like
a
compliance
audit
person,
so
I
their
security
analyst
and
in
charge
of
complaints
are
on
it,
whereas
all
the
mr
stuff,
the
primary
person,
is
a
developer.
A
Okay,
that
makes
sense,
and
thanks
for
that
feedback
because
we'll
take
that
back
to
our
discovery
and
do
it
in
that
direction.
But
I
did
want
to
surface
that
as
well.
Yeah
and-
and
you
know,
going
with
the
group
level-
has
its
own
challenges
just
like
we
found
out
with
a
group
dashboard,
for
example
like
how
do
you
know
which
ones
are
even
configured?
So
if
you
have
ten
projects
in
this
one,
you
have
a
configuration
problem
just
like
we
had
here
and
just
showing
that
this
is
what
we
did
for
for
that.
A
B
Actually,
had
people
specifically
ask
this
type
of
question
sales,
people
and
account
management
people,
so
what
I
think
could
potentially
be
interesting
if
you
are
able
to
do
this
is
get
a
whole
bunch
of
like
medium
to
high
five
mock-ups
together
ping
account
management
and
sales
people
be
like.
So,
if
have
people
asked
about,
you
know
policy,
and
you
know
company
policy
enforcement
around
licenses
or
dependencies,
as
you
can
say
like
right
now,
we
don't
quite
do
you
know
both
but
we'd
love
to
talk
to
them
and
see.
C
Mm-Hmm
I
have
to
imagine,
there's
probably
some
internal
customers.
We
could
use
here
as
well.
Olivier
might
know
specifically,
but
I'm
thinking.
Engineering
managers
would
probably
have
input
on
this
or,
if
there's
someone
inside
of
engineering
or
another
department,
that's
responsible
for
compliance
and
license.
B
Well,
I
think
our
compliance
department
is
responsible
for
compliance
and
licensing
so
they're.
Definitely
our
internal
customer
they've
already
told
us
like
we
don't
love
you.
So
we
definitely
they're
number
one
people
to
ask
and
they
know
we've
talked
to
them
once
and
we'll
talk
to
them
again,
but
I
think
for
additional.
So.
A
It
was
with
legal,
it
is
on
the
compliance
and
right
now
official
answers,
we're
figuring
it
out.
Security
I
went
to
the
office
hours
and
security
compliance
office
hours,
and
they
are
not
dealing
with
this
at
the
moment
and
they
redirected
us
back
to
development,
so
the
best
resource
that
we
do
have
about.
What
we
have
here
is
is
this
page?
Actually,
that's
really
great
how
we
handle
license
compliance.
We've
used
omnibus
I'm
gonna
talk
to
more
in
I'm,
trying
to
get
a
hold
of
him
because
he
built
it.
A
So
I
will
follow
up
on
that,
just
just
because
it
would
be
great
to
start
doctoring
this
in
some
level,
especially
since
we
have
now
the
disallow
feature
I'm.
Sorry,
where
is
that?
So
we
actually
have
licenses
here
granted
they're
in
different
versions
and
will
actually
come
to
something
about
that
in
a
moment.
But
there
is
a
dogfooding
opportunity
here
and
let's,
let's
keep
let's
keep
sniffing
it
out,
but
but
Candice
is
it's
a
work
in
progress.
So
the
last
point
that
I
have
on
here
is
like
sorry.
D
Okay,
yeah
sorry
to
interrupt
I
just
wanted
to
raise
again
that
there
have
been
a
new
group
created
we
in
the
manage
stage,
which
is
a
compliance
group.
So
thinking
about
all
this
compliance,
we
would
see
workflows
and
they
should
probably
be
a
bubble
up
to
that
group,
because
we
might
have
a
generic
approach
for
all
the
features
of
the
product.
A
B
Actually,
I'm
scheduling
a
call
with
that
team
next
week
or
the
week
after
I
can
see,
see
you
in
case
you're
free
to
attend.
I
expect
this
actually
to
continue
and
to
actually
increase,
because,
honestly,
security
is
not
a
standalone
thing.
Security
is
baked
into
every
single
stage,
so,
as
each
stage
gets
more
mature
and
as
we
get
more
mature,
there's
gonna
be
tons
more
overlap,
so
we
definitely
need
to
be
having
more
discussions
and
then
kind
of
figure
out,
like
you
know,
how
do
we
work
together
on
some
of
these
items?
A
quick.
D
Distinction
between
packages
and
what
we
are
doing
in
the
dependency
list
is
the
package
is
capabilities.
Allow
you
to
create
package
like
create
a
ruby
gem
from
your
project,
create
and
PM
package
from
your
project
a
bit
like
you
can
create
docker
images
from
your
project
and
you
have
to
continue
registry.
On
our
hand,
the
dependencies
is
showing
the
packaging
that
your
project
is
using,
which
is
a
bit
different.
I
think.
B
A
This
meeting
should
we
move
on.
I
only
have
one
last
point,
and
that
is
that,
as
our
technical
capabilities
are
getting
much
better
mo,
did
a
great
write-up
last
milestone
about
that.
One
thing
that
could
help
this
situation,
because
there's
different
versions
of
licenses
and
so
on
is
there's
the
ability
to
actually
make
a
note
here
so
similar
to
how
we
do
it
with
vulnerabilities,
and
that
might
appear
something
like
this.
So
why
is
a?
Why
is
something
blacklisted
hey
in
this
situation
its
how
to
compliance
with
HIPAA?
Something
like
that?
A
Then
the
developer
has
some
idea
of
that,
so
that
can
kind
of
mitigate
some
of
the
complexity
that
we
have
with
not
being
able
to
specify
the
exact
versions
of
licenses
and
so
on.
So
I
don't
know
if
there's
any
other
thoughts
to
mitigate
that
or
that
could
be
helpful
one
or
just
any
other
thoughts
in
general.
Otherwise,
we
can
move
to
the
next
item.
I
mean.
B
I
think,
as
we
get
towards
maturing
the
dependency
scanner,
we're
going
to
be
allowing
hopefully
blacklisting
of
specific
dependencies,
which
is
I
think
where
we're
gonna
start
getting
into
versioning.
So
this
may
not
always
like
it
may
in
the
future,
be
like
a
layered
thing
like
I
can
ban
certain
licenses
and
then
I
can
permit
certain
licenses
that
ban
certain
versions
of
things.