►
From YouTube: Sec Section PM / Field sync - February 2023
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
All
right
cool
all
right.
Well,
thanks
we'll
say
you
Chen
for
joining
Sam
and
I
at
the
early
timed
sko
overlapping
kickoff,
not
a
whole
lot.
The
product
update
side
today
from
me.
A
A
This
applies
to
gitlab,
as
well
as
any
partner
or
integrated
homegrown
third-party
tools.
So
if
you
have
customers
that
are
potentially
using
something
we
may
not
be
aware
of,
they
should
be
getting
warnings
today
about
the
schema
with
16.
We
will
stop
ingesting
them
and
they
will
become
errors.
They
will
not
not
produce
findings.
B
Yep,
so
these
are,
we've
got
some
really
big
changes
around
license
compliance
coming,
so
we're
going
to
be
dropping
support
for
a
license
check
that
should
be
replaced
with
license
approval
policies
and
we're
also
dropping
support
for
the
license
scanning
CI
job,
and
that
will
be
replaced
just
by
running
the
dependency
scanning
job
in
your
pipeline
will
give
you
everything
you
need
to
get
that
license
data,
so
you
know
some
big
changes
there.
B
Please
make
your
customers
aware
if
they
want
to
use
our
new
license
gaining
capability
early,
they
just
need
to
make
sure
that
they're
not
running
the
license
scanning
CI
job,
otherwise
will
default
to
that
as
the
old
method,
but
I
definitely
recommend
that
they
take
those
jobs
out
of
their
pipeline
as
soon
as
they
can
just
because
our
new
method
tends
to
be
it,
at
least
from
all
of
our
internal
testing.
A
See
him
one
that
is
a
fairly
recent
item.
I,
don't
think.
We've
talked
about
this
before
so
I
have
been
talking
with
Hannah
Suiter,
who
is
on
our
authorization
and
authentication
group,
and
her
team
is
actually
doing
the
work
to
help
separate
out
a
vulnerability
management
permission
for
customer
permission.
So
we're
going
to
start
by
limiting
access
to
the
vulnerability
report.
A
The
way
that
custom
roles
are
being
approached
right
now
from
that
group
is
they
are
going
with
an
additive
model,
so
you
can't
take
an
existing
role
and
subtract
a
permission.
You
can
clone
a
lower
role
and
add
to
it.
So
it's
not
going
to
be
a
full,
a
full
way
to
restrict
access.
Let's
say
from
like
the
developer
role,
for
instance,
because
you
can't
take
it
out,
but
you
can
do
things
like
using
the
reporter
base
and
adding
vulnerability
report
access
to
it.
A
I
know
that's
something
that
comes
up
from
time
to
time
with
customers
is
they
want
an
absec
role
that
can
do
vulnerability,
triage
and
management,
but
that
doesn't
have
access
to
the
repositories,
so
that
would
allow
that
to
happen.
So
that
should
be
the
first
of
hopefully
many
permissions
that
are
going
to
start
moving
over
from
the
security
side.
C
Yeah
actually
one
question
about
that:
one
and
it
about
the
previous
items
as
well.
If
it's
better
routed
to
the
auth
team,
just
let
me
know,
but
just
be
very
explicit.
There
is
not
going
to
be
a
quote
unquote
out
of
the
box
role
called
appsec.
This
appsec
role
will
be
created
by
adding
permissions
to
a
role
that
currently
does
not
have
the
view
vulnerability
report
is
that
an
accurate.
A
Statement
from
my
understanding,
yes,
for
now,
the
way
that
they're
trying
to
increment
forward
is
they're,
allowing
you
to
clone
an
existing
role
and
then,
where
work
has
been
done
like
this
to
sort
of
carve
out
a
feature
into
a
standalone,
I,
guess,
assignable
permission:
you
will
be
able
to
add
into
these
lower
roles,
I
think
long
term.
The
vision
is
to
go
fully
custom.
A
C
Okay,
that's
cool
I've
had
some
conversations
with
the
op
team
about
how
far
addition
should
go
with
the
gestural.
Obviously,
there's
a
lot
of
considerations
there,
but
I
will
say
that
this
change
is
highly
welcome,
because
one
of
the
big
ass
from
my
customers,
who
are
security
Centric
is
you
know,
there's,
for
example,
Auditors
that
just
want
to
look
at
the
vote
report
and
don't
we
don't
don't
need
access
to
the
rest
of
the
information
in
the
project.
So
that's
awesome.
A
Actually
I
did
want
to
say
so
what
you
mentioned
there
about
the
Auditors.
There
actually
is
an
issue
in
the
backlog
to
address
that
specific
limitation.
So
I
think
that
was
something
that
was
actually
just
overlooked
during
the
development
of
some
of
the
vulnerability
management
pieces.
Is
the
auditor
should
have
access
in
a
read-only
view,
from
my
understanding,
everything
in
git
lab,
but
you
do
have
to
sort
of
code
in
to
that
role,
and
so
that
wasn't
done
so
that
is
actually
I
would
say.
C
Okay,
I
see
so
there's
a
separate
user
story
out
there
or
ethic,
perhaps
for
the
auditor
role.
But
what
we
have
just
discussed
here
and
is
greater
abilities
Beyond
view
only
for.
C
C
Let's
see
there
and
yep
I
see
the
link
so
I'll
give
that
a
gander
afterwards,
one
just
FYI,
it's
much
appreciated
for
me
personally,
at
least
I
won't
speak
for
you
know
everybody
on
the
team
and
how
they
may
or
may
not
healed,
but
I
love
the
fact
that
we're
using
layman's
terms
rolling
license
scanning
into
dependency
scanning,
because
I
think
that's
how
I
have
always
conceived
it.
C
C
So
I
think
that
consolidation,
if
we
will,
is
much
appreciated
and
it
will
fall
in
line
with
the
thinking
of
Washington
market
and
folks
who
are
accustomed
to
perhaps
other
solutions
they
use,
invest
so
a
thumbs
up
on
that
one
and
a
quick
question
about
the
license:
check,
drop
of
support
for
the
license
check
user.
C
Just
because
that
you
know
I
would
say
there
is
I,
can't
give
you
a
sense
of
what
percentage
of
my
customers
depend
heavily
on
it.
But
I
would
say
this
much.
Those
who
do
depend
on
the
license.
Check
user
do
use
it
as
a
very
strong
dating
function,
typically
for
legal
teams,
and
if
it's
in
the
documentation,
I
haven't
read
it.
So
just
tell
me
to
read
it,
but
I
was
wondering
what
should
the
behavior
that's
expected?
C
C
If
it's
simply
going
to
be
bypassed,
so
I
was
curious
once
we
drop
support,
is
there
going
to
be?
You
know
a
banner
that
says:
hey.
We
don't
support
this
anymore.
Please
read
the
documentation.
Is
this
going
to
be
bypassed?
Is
there
more
you
can
share
enough
right.
B
B
and
then
once
we
actually
remove
it
in
16.0,
it
will
just
go
away.
So
if
they
had
it
configured,
it
will
be
gone
completely.
It
will
no
longer
get
Mrs,
it
won't
be
there
in
the
product.
There
will
be
no
way
to
set
it
up
and
if
license
check
was
previously
enabled
it
won't
be
there
anymore.
So
you
know
they
have
kind
of
this
time
window
between
15,
9
and
16.0
to
move
over
to
the
new
solution
so
that
they
don't
lose.
That
coverage.
C
Do
we
know
at
this
time
whether
let's
say
I
am
an
individual
user
who's
been
assigned
to
do
the
license?
Checks
would
I
receive
a
notification?
Perhaps
that
says
hey
this
is
you
are
no
longer,
you
know
leveraging
the
license
check,
feature
I.
B
Guess
no,
you
would
not
receive
like
an
email
notification.
No,
so
we'll
be
posting
it
like
we
do
with
all
of
our
deprecations
and
removals,
we'll
be
posting
it
on
our
deprecation
page.
So
if
they
go
there
they'll
be
able
to
read
the
details
of
it
and
then,
like
I,
said
also
in
1510,
we're
working
to
add
a
banner
at
the
top
of
any
projects
that
are
using
license
check
just
to
warn
users
of
that
change.
B
So
if
they
visit
their
project,
page
they're
likely
to
see
that
Banner,
but
we're
not
planning
on
like
pushing
out
email
notifications,
that's
not
really
something
that
we've
done
historically
at
gitlab.
You
know
we
don't.
We
don't
even
necessarily
have
all
of
that
information,
because
you
know
it's
hard
for
us
to
pull
that,
because
we've
got
a
large
base
of
self-managed
users
and
you
know
going
out
and
emailing
them
it.
It
gets
really
difficult
to
email
the
correct
folks
and
to
do
that
across
our
entire
customer
base.
B
So
no
there
will
be
no
notification
that
way
going
out.
However,
if
users
do
want
push
notifications
of
breaking
changes,
we've
set
up
an
RSS
feed
that
they
can
subscribe
to
and
that's
what
will
give
them
push
notifications
of
all
Breaking
changes.
So
if
they
come
back
and
they
say
well,
you
know
all
of
this
was
poll
like
I
had
to
go
to
the
documentation,
page
or
I
had
to
go
to
the
project
and
I
had
to
happen
to
see
this
Banner
right.
B
If,
if
they
want
notifications,
it's
an
opt-in
process
and
they
can
subscribe
to
our
RSS
feed
to
get
those
proactively.
You
know,
rather
than
it
being
more
of
a
reactive
process.
On
their
end,
very
cool
I'll
drop,
a
link
to
that
here.
In
the
note
stock.
C
All
right,
you're,
pretty
answered
by
a
final
question:
there
yeah
that'd,
be
much
appreciated.
Just
since
you
know
a
couple
of
edge
cases
right,
like
maybe
there's
a
dangling
Mr,
that's
been
left
around
for
some
time
or
just
the
folks
are
busy
right
and
not,
or
some
folks
may
have
turned
on
the
feature
without
the
knowledge
of
their
account
team.
So
of
course,
there's
some
things
that
might
be
overlooked,
so
cool.
C
That's
all
I
had
I
think
all
of
these
changes
will
be
very
much
appreciated.
I
mean
they're
really
going
to
simplify
some
of
the
ways
that
we
think
about
the
product.
C
That's
my
20
questions
for
for
today.