►
From YouTube: Govern Stage Strategy Review - December 2022
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
Welcome
to
our
December
govern
stage
strategy
review
just
to
get
started
here,
I'm
going
to
go
over
our
organization
chart
since
the
governed
stage
is
still
fairly
new.
We
now
have
the
compliance
group
under
govern,
as
well
as
the
security
policies
group
and
the
threat
insights
group,
and
as
part
of
that,
we
recently
added
a
new
dependency
management
category
under
threat
insights.
So
that's
the
current
team,
myself
Derek
and
Matt,
and
we're
going
to
each
be
going
through
the
areas
for
our
respective
groups
before
we
get
started.
A
We
are
going
to
be
covering
a
lot
of
roadmap
information,
and
so
you
should
be
aware
that
any
roadmap
information
that's
presented
is
just
for
is
not
for
purchasing
or
planning
purposes,
and
it
is
subject
to
change
to
get
started
with
the
security
policy
group.
Some
of
the
highlights
over
the
last
six
months
include
delivering
scan
execution
policies
at
the
group
level
in
the
15-2
release,
and
then
we
just
recently
followed
that
up
with
group
and
subgroup
level
scan
result
policies
in
the
15.6
release.
A
Both
of
those
were
pretty
big
features
that
allow
organizations
to
manage
their
policies
centrally
at
the
group
level
and
have
those
policies
flow
down
to
all
of
the
projects
inside
of
their
group.
We've
also
made
some
progress
on
our
vision
towards
adding
support
for
all
of
the
different
types
of
scanning
by
adding
support
for
dependency
scanning
in
15
6.,
and
we've
made
it
easier
to
use
by
adding
a
number
of
different
UI
features.
We
added
the
ability
to
view
policies
listed
in
the
Mr
settings
in
15.0.
A
We
added
an
interactive
policy,
editor
validation
in
15
3,
to
help
catch
errors.
If
you're
making
mistakes
before
you
create
your
policy
and
then
we
also
added
a
rule
mode
in
155
for
scan
execution
policies,
so
that
users
who
want
to
just
edit
in
a
UI
without
having
to
edit
in
and
yaml,
can
do
that.
A
Coming
up
on
our
roadmap,
we
have
a
number
of
different
improvements.
The
first
one
is.
We
have
plans
to
add
support
for
running,
scan
execution
policies
on
Runners
that
have
specific
tags,
whereas
right
now
they
just
run
on
the
default
shared
runners
or
untagged
runners,
we're
also
working
to
introduce
license
approval
policies.
This
is
a
rather
large
undertaking.
A
It
also
will
pave
the
way
for
us
to
be
able
to
support
managing
those
policies
at
the
group
level,
so
they
can
be
managed
centrally
and
it
provides
a
full
audit
log
of
all
changes
that
are
made.
And
lastly,
it
allows
compliance
teams
to
have
an
approval
workflow
in
place
for
anyone
who
wants
to
make
changes
to
the
policy
itself.
So
that
way,
they
can
be
confident
that
no
one
person
is
going
through
and
making
changes
to
the
policy
without
permission.
A
Also
coming
up
on
our
roadmap
are
a
number
of
improvements
to
the
scan
result
policies
we
want
to
add
support
for
role-based
approvers.
So
if
you
want
to
require
approval
from
either
a
developer
or
maintainer
in
the
project,
rather
than
from
the
security
and
compliance
team,
you
can
do
that.
We're
also
working
to
add
a
lot
of
additional
scan
result
policy
criteria,
including
things
like
filtering,
based
off
of
the
age
of
the
vulnerability.
So
that
way,
if
you
have
slas
that
you
need
to
enforce,
you
can
do
that
by
setting
up
a
policy.
A
Some
of
the
other
policy
functionality
there
that
we're
looking
at
introducing
includes
things
like
filtering
on
labels
such
as
whether
or
not
a
fix
is
available
and
whether
or
not
the
vulnerability
has
been
marked
as
a
false,
positive
and
then.
Lastly,
we're
working
to
be
able
to
limit
group
policies
only
to
projects
that
have
specific
compliance
framework
labels
and
that's
another
step
towards
our
long-term
vision
of
bringing
security
policies
and
compliance
framework
labels
together
into
one
single
solution.
A
With
that
I'm
going
to
be
turning
it
over
to
Matt
to
cover
our
threat.
Insights
group.
B
Thanks
Sam,
so
we'll
start
with
our
first
category.
Vulnerability
management,
the
last
six
months
and
really
the
better
part
of
this
calendar
year,
has
been
a
lot
of
focus
on
stability
in
Enterprise
Readiness
from
the
thread
insights
group.
We
have
continued
to
make
a
lot
of
behind
the
scenes,
changes
to
improve
things.
We
call
error
budget,
that's
how
we
Track
Performance
internally
and
we're
at
a
place
where
we're
really
very,
very
close
to
meeting
the
the
thresholds
that
we've
set
out.
B
At
the
same
time,
we've
seen
our
large
increase
in
utilization,
so
we're
making
sure
that
we're
scaling
for
not
just
what
we've
got
today,
but
what
we
expect
usage
should
be
in
the
future.
We
have
two
very
large
projects
which
are
maintenance
or
re-architecture
projects
that
are
nearing
completion.
The
first
is
storing
findings
in
the
database,
so
findings
are
really
anything
that
the
security
schemes
detect
in
merge
requests
or
Pipelines.
B
Once
we
move
to
the
database
back
model,
we
should
see
a
number
of
improvements
not
just
to
Performance,
but
laying
the
groundwork
for
future
features
like
letting
us
track
non-default
branch
locations.
So
you
could
have
feature
branches.
It
could
be
a
tag.
Etc
we'll
have
that
information
in
the
database
so
that
we
can
expose
that
on
the
vulnerability
report.
B
We
are
also
also
nearing
the
completion
of
a
critical
re-architecture
which
it's
pretty
down
in
the
weeds,
but
it
essentially
is
something
that's
blocking
a
lot
of
our
top
features
from
moving
forward
vulnerability
management,
this
redesign
model-
we
are
hoping
we'll
finish
in
the
next
Milestone
or
two-
and
this
is
going
to
block
a
lot
of
our
priority-
features
that
we've
got
waiting,
also
a
big
milestone
for
us,
the
effort
to
align
all
of
the
Mr
widgets
in
a
new
framework.
There's
a
new
design
framework,
we've
refactored
our
security
widget.
B
So
it
has
the
new
design,
new,
look
and
feel
I
think
it
looks
great
and
glad
to
see
that
we're
wrapping
up
and
moving
forward
onto
our
roadmap
over
the
next
six
months.
So
these
are
two
of
these
top
projects
that
are
waiting
on
that
re-architecture
work.
This
has
kind
of
been
at
the
top
for
a
while,
but
these
are
still
very
important,
so
the
first
is
Auto
resolving
irrelevant
vulnerabilities.
B
This
is
going
to
save
teams
a
lot
of
time
operationally,
because
these
are
things
that
they
wouldn't
have
to
spend
time
triaging
and
manually.
Resolving
the
other
is
enhanced
filtering.
This
is
a
actually
has
kind
of
expanded.
Our
scope
a
little
bit
we're
looking
a
little
bit
more
holistically
at
How,
We
Do
filtering,
not
just
in
the
vulnerability
report,
but
in
gitlab
itself
we're
essentially
trying
to
figure
out.
How
can
we
make
a
more
extensible
model
for
adding
a
lot
of
additional
Advanced
filters
to
something
that
has
so
much
information
like
the
vulnerability
report?
B
B
B
B
This
is
a
foundational
piece
for
continuous
vulnerability
scans,
which
is
a
much
larger
cross
group
effort,
and
it
also
allows
us
to
start
creating
things
like
group
level
dependency
lists,
so
you
can't
see
dependencies
in
the
product
today
that
would
have
been
technically
challenging
and
not
very
performant
to
try
to
aggregate
all
of
those
different
job
artifacts
across
multiple
different
projects,
the
group
level.
So
this
is
something
we
can
start
moving
forward
with
now,
I
did
want
to
note.
The
functionality
is
still
behind
a
feature
flag.
B
We
did
enable
this
in
a
limited
capacity
and
noticed
it
was
creating
more
database
records
than
anticipated.
So
we've
taken
the
step
to
do
a
refactor
before
we
turn
that
flag
on
by
default
and
rolled
out,
but
we're
hopeful
that
in
the
next
Milestone
we'll
have
that
result
and
it
will
be
ready
in
in
place.
B
So
over
the
next
six
months,
first
step
is
obviously
to
get
the
feature
flag
enabled
for
gitlab.com
and
have
that
on
by
default
for
self-managed.
So
we
will
have
the
full
database
packed
model.
We
are
also
going
to
start
transitioning
the
dependency
list,
the
page
the
UI
to
the
database
backed
this
is
going
to
be
a
phased
approach,
because
we
also
have
to
incorporate
very
similar
projects
going
on
with
license
data,
as
well
as
matching
up
the
dependencies
to
the
vulnerability
data
in
the
database.
B
C
All
right,
thanks
Matt,
so
looking
at
what
the
compliance
group
has
been
doing
with
audit
events,
we
added
some
custom
HTTP
headers
for
streaming
a
lot
of
events.
This
allows
for
better
integration
with
the
different
Sims
or
other
places
that
you
might
want
to
stream
your
audit
events
and
and
helps
with
the
authentication
and
authorization
for
the
incoming
streams.
C
We
also
did
the
ability
to
add
custom
verification
tokens
to
these
these
streaming
audit
events,
as
well
as
displaying
those
tokens
in
the
UI.
C
We
also
went
with
adding
more
audit
events,
both
regular
audit
events
in
the
UI
and
streaming
audit
events.
This
is
an
ongoing
effort,
so
we
will
be
continuing
to
add
more
of
these,
but
these
are
the
ones
that
we've
added
in
the
last
six
months
and
within
those
things
like
the
git
operations,
are
particularly
useful
that
will
log
any
git
operations
and
stream
that
out
to
wherever
you
need
to
ingest
these.
C
So
let's
look
at
the
roadmap
for
audit
events,
and
one
thing
that
we're
going
to
be
doing
is
adding
type
information
for
both
the
streaming
and
non-streaming
audit
events.
This
will
provide
more
information
about
the
type
of
event
that
is
going
on
and
we'll
provide
more
ways
to
categorize
this
information
we'll
be
adding
filtering
both
with
the
API
and
the
UI
for
streaming
audit
events.
C
This
will
help
with
being
able
to
get
just
the
audit
events
that
you
want
and
look
at
what
you
need
to
to
specifically
hone
down
what
what
events
you
wanted
to
see.
We
will
be
working
to
add
more
audit
events.
C
This
exact
list
is
something
that
we
are
constantly
refining
so
the
roadmap
right
now
we
do
not
have
exactly
what
we'll
be
adding,
but
as
we
go
through
and
prioritize
the
different
parts
of
git
lab
to
see
where
we
need
the
audit
events
most
we'll
be
adding
those
in
one
big
feature
that
we
will.
We
are
looking
at
adding
right
now
the
audit
events.
There
are
two
places
that
you
can
look
at
to
see.
Those
one
of
them
is
the
stream
dot
of
events.
C
Moving
on
to
compliance
management
in
the
last
six
months,
we've
added
a
few
things:
adding
Mr
approval
rules
for
all
protected
branches,
supporting
failed
external
status
checks
before
the
we
were
only
supporting
it.
When
it
came
back
as
successful
now,
you
can
see
the
failed
status
check
on
the
Mr.
C
We
have
released
blocking
merge
Mr
if
there
are
failed
external
status
checks.
So
this
allows
you
to
check
an
external
system
make
sure
that
all
the
components
are
in
place
for
nlr
to
be
merged,
and
if
they
aren't,
then
you
can
block
that
on
and
then
another
thing
that
we've
added.
That
starts
to
move
us
towards
more
group
level
management
for
compliance
Frameworks.
Is
we
added
the
ability
to
apply
a
default
compliance
Frameworks
framework
for
new
projects
at
the
group
level?
C
C
We're
going
to
be
adding
the
ability
to
filter
on
the
compliance
report,
violations
to
policies
by
looking
at
all
the
branches
or
all
protected
branches.
C
The
biggest
thing
that
we
are
going
to
be
focusing
on
in
the
next
six
months
is
the
group
level
management
of
compliance,
Frameworks
and
pipelines
to
apply
to
the
projects
at
that
group
level
rather
than
going
into
each
project
individually.
So
this
will
allow
you
to
apply
a
framework
to
remove
a
framework
to
filter
and
get
a
report
on
which
projects
are
using
which
compliance
Frameworks.
So
it
should
be
very
useful
to
anyone
who
has
more
than
a
few
projects
within
a
group
as
a
part
of
the
external
status
checks.
C
We
are
going
to
be
adding
a
retry
button
for
the
failed
checks.
This
allows
you
to
go
in
and
retry
those
those
status
checks
to
see
if
the
external
systems
are
ready.
This
is
extremely
useful
for
things
where
the
Mr
is
blocked.
Based
on
that
failed
status
check,
it
allows
you
to
just
go
quickly.
Retry
one
of
the
big
issues
that
we've
seen
with
compliance
pipelines
is
the
fact
that,
when
a
gitlab
CI
yaml
file
is
missing,
it
causes
problems
with
those
compliance
pipelines
being
run
within
the
project.
C
So
we're
going
to
be
working
on
ways
to
mitigate
that
and
to
handle
those
missing.
Git
live
ciml
files
and
then
also
focusing
on
group
level
management
we'll
be
adding
in
the
group
level
settings
for
the
merger
process,
approval
rules
to
apply
to
the
child
projects
so
that
you
can
manage
that
in
a
single
place
within
the
compliance
configuration,
and
that
is
all
for
the
compliance
group
back
to
Sam.
A
Thanks
Derek
there's
one
other
area
that
govern
works
on
that
I'll
be
covering
here
in
that
software
supply
chain
security.
This
is
an
area
where
we
don't
have
a
dedicated
group
or
dedicated
Engineers
working
on
this.
Rather,
this
is
an
area
that
gitlab
has
a
direction
for
the
spans
across
all
of
the
entire
product
across
all
of
gitlab,
and
so
really
we've
been
working
to
Define.
That
direction
in
conjunction
with
the
product
managers
for
their
respective
groups
to
see
that
come
to
fruition
for
the
gitlab
platform
as
a
whole.
A
Recently,
we
added
support
for
salsa
level,
2
compliant
attestations.
These
can
be
generated
automatically
by
the
gitlab
runner
simply
by
setting
a
CI
variable
to
turn
the
feature
on
and
it'll
produce,
basically,
a
Json
output
in
the
salsa
II
standard
format
that
describes
all
of
the
inputs
that
came
into
the
build
and
how
it
was
produced.
A
Also
thanks
to
an
engineer
here
in
gitlab,
who
spent
some
of
their
time
outside
of
their
normal
working
hours
to
basically
develop
a
community
contributed
feature.
We
now
have
support
for
SSH
commit
signing
in
gitlab
I,
think
that
says,
15
6
I
think
it
actually
should
be
15
7.,
if
I'm
not
mistaken,
so
we're
coming
out
with
that
this
release,
but
that's
another
kind
of
signing
that
makes
it
much
more
convenient
if
your
developer
who's
trying
to
sign
your
code
also
coming
up
in
the
future,
we're
working.
A
We
have
another
Community
contribution,
that's
working
to
add
open,
pgp
signing
of
commits
done
in
the
gitlab
UI.
So
traditionally
we
allow
for
signing
at
the
get
console
or
on
the
get
command
line.
But
if
you
go
into
the
web
UI
or
you
make
a
suggestion
on
a
merge
request-
and
you
apply
that
those
commits
are
usually
not
signed
today,
so
we've
been
working
with
that
Community
contributor
to
add
support
for
openpgp.
A
Also
in
our
future
plans
is
we're
looking
at
adding
keyless
commit
signing
where
gitlab
would
be
able
to
automatically
sign
those
commits
without
using
a
dedicated
key
and
instead
just
using
the
git
lab
identity.
A
The
third
one
that
we're
looking
at
is
automated
signing
of
build
artifacts,
where,
if
you
produce
a
build
through
your
CI
CD
system,
you
not
only
want
to
have
that
attestation,
but
you
also
want
to
have
that
signed
so
that
you
can
be
confident
that
it
hasn't
been
modified
or
tampered
with
after
the
attestation
or
the
build
itself
was
produced.
That's
a
large
undertaking.
We
don't
really
have
an
end
timeline
on
that,
but
we
have
been
working
to
get
some
of
the
prerequisites
unblocked
so
that
we
can
make
that
possible
just
to
wrap
it
up.
A
I
want
to
highlight
some
of
the
overarching
roadmap
themes
that
I've
seen
across
all
three
of
our
groups.
If
we
look
holistically
across
all
of
those
areas,
we
see
a
large
theme
of
standardization
and
unification
of
features
where
we're
working
to
bring
alignment
and
future
parity
across
the
board
and
make
things
consistent
and
simple
to
use.
A
We
also
have
a
number
of
projects
related
to
scalability
and
performance,
specifically
moving
things
to
the
database,
where
we're
moving
both
our
findings
and
our
dependencies
to
be
stored
in
the
database
for
better
performance
and
scalability
in
the
future,
and
then
lastly,
we
see
a
general
focus
on
usability
across
our
stage
where
we're
making
it
easier
to
manage
things,
especially
at
the
group
and
subgroup
levels,
whether
that's
your
dependencies,
your
policies
or
your
compliance
labels.
So
that's
all
we
have
for
today.