►
From YouTube: Govern Stage Strategy Review
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
Yeah,
hello,
everyone
and
Welcome
to
our
govern
stage
strategy
review
today,
we'll
be
talking
through
our
structure.
Our
strategy,
as
well
as
some
features
that
we've
recently
released
and
our
upcoming
roadmap,
presenting
today
with
me,
I,
have
Derek
who's
running
our
compliance
team,
Grant,
who's,
running
security,
policies
on
Alana,
who's,
running
thread,
insights
and
also
in
the
scope
of
govern.
A
We
have
the
software
supply
chain
security
working
group
which
helps
to
contribute
supply
chain
security
features
throughout
the
entire
scope
of
gitlab
within
govern
I
know
govern,
is
a
fairly
new
stage
and
so
I
wanted
to
provide
an
overview
of
some
of
the
markets
that
we
play
in
as
well
as
some
of
the
personas
that
we
target
So
within
govern.
We
play
predominantly
in
the
application
security
testing
Market.
This
is
the
market
that
we
really
Target
directly.
There
are
a
couple
other
markets
that
we
play
in
a
little
bit.
A
One
is
GRC,
which
is
governance,
risk
and
compliance,
and
we
play
in
that
market
to
some
degree
as
far
as
it
overlaps
with
devsecops.
Some
of
the
solutions
in
that
space
are
really
a
broad.
You
know
cross-cutting
Universal
compliance
solution
and
that's
not
something
that
we're
trying
to
become
another
Market
that
we
play
in
a
little
bit
is
the
asoc
market,
and
we
also
partially
play
in
that
market.
We
provide
a
good
overview
of
vulnerabilities
in
gitlab's
platform.
A
We
don't
yet
do
good
correlation
of
vulnerabilities
for
multiple
different
sources,
but
we
do
consolidate
them
into
one
View,
and
so
we
do
at
least
partially
participate
there
and
then
on
the
Persona
side,
especially
in
govern.
We
target
a
really
wide
variety
of
personas
that
are
listed
here
and
there's
a
lot
of
overlap
between
all
of
those
and
their
jobs
to
be
done.
One
of
the
big
ones
is
the
compliance
team.
Another
big
one
is
the
application
security
team.
A
Those
are
probably
the
biggest
two
personas
that
we
target,
but
we
also
develop
features
for
development
teams,
legal
teams
and
infrastructure
security
teams,
as
well
I,
see
three
themes
that
have
emerged
and
that
we've
especially
focused
on
in
identifying
some
of
the
key
areas
that
we
need
to
improve
on
related
to
helping
our
customers
adopt
our
security
features.
One
of
those
is
top
down
security
controls.
A
The
next
theme
is
no
compromises
with
compliance.
This
means
that
we
really
need
to
tighten
things
down
and
close
out
all
the
ways
that
users
can
get
around
security
scanning
and
compliance
controls
that
are
in
the
product.
Today.
We
need
to
be
able
to
give
our
customers
the
confidence
that
they're
able
to
turn
on
gitlab
and
use
it
and
know
that
when
they
enforce
their
control
or
turn
on
a
control
that
it's
going
to
be
applied
strictly
across
the
board
without
any
way
to
circumvent
that
now,
the
last
one
is
coordinating
security
across
gitlab.
A
This
comes
back
to
that
integration
point
that
I
was
discussing
earlier,
but
helping
to
integrate
our
workflows
deeper
into
the
broader
devsecops
life
cycle.
A
So
with
that
understanding
of
our
basic
strategy,
we're
going
to
be
discussing
some
of
our
recent
highlights
of
features
that
we've
released,
as
well
as
some
of
our
upcoming
roadmap
capabilities,
so
I'll
be
turning
it
over
first
to
Alana
to
talk
about
some
of
the
things
we've
released
in
threat.
Insights
recently.
B
C
I'll,
take
over
from
here
I've
got
a
couple
of
highlights
from
the
security
policies
group
that
I'll
speak
to,
and
the
first
is
enforcing
compliance
through
license
approval
policies,
and
what
we've
seen
is
that
legal
and
compliance
teams
have
have.
You
know
struggled
with
being
able
to
translate
their
license
approvals
or
license
requirements
into
enforced
policies
in
Gale
lab.
So
what
you'll
be
able
to
do
now
is
actually
create
a
granular
policy
to
control
these
policies
directly
in
the
software
development
life
cycle.
C
So
what
you'll
be
able
to
do
is
require
approval
when
licenses
are
identified
in
a
scan
that
are
explicitly
denied
by
your
policy
or,
alternatively,
you
can
define
a
policy
to
require
approval
for
any
licenses
that
are
not
explicitly
approved.
These
approvals
can
be
defined
for
newly
detected
or
pre-existing
vulnerabilities,
and
then
management
of
these
policies
ensures
complete
separation
of
Duties.
So
only
legal
or
compliance
team
members
would
have
access
to
make
changes
here
and
you
can
require
two-person
approval
to
track
that
that
you
are
getting
four
eyes
across
every
change.
C
That's
being
made
that
there's
an
audit
Trail
to
all
changes.
The
next
item-
item
I,
wanted
to
speak
to
is
role-based
scan,
result
policy
approvers.
This
is
another
recently
added
feature
with
this.
C
In
addition
to
existing
controls
to
be
able
to
set
approvers
as
individuals
or
at
a
group
level,
you
can
now
actually
set
a
role-based
approval
policy,
and
this
may,
for
example,
allow
you
to
to
set
a
project
maintainer
as
a
required
approver
anytime,
a
security
or
license
policy
violation
is
detected,
and
this
will
be
especially
useful
when
paired
with
future
plans
for
compliance
of
security
policies,
which
will
enable
enforcement
of
two
person
approvals
on
all
changes
going
into
production.
D
Yeah,
so
one
thing
that
we
have
recently
released
is
the
ability
to
manage
compliance
Frameworks
at
the
group
level,
so
we
introduced
a
new
tab
on
the
compliance
report
that
gives
you
a
list
of
all
your
projects
and
lists
all
the
Frameworks
that
have
been
applied
to
them,
and
so
at
this
point
you
can
do
a
bulk
change
rather
than
going
to
each
project
individually
and
applying
the
compliance
framework.
So
this
makes
it
much
faster,
especially
for
users
who
have
hundreds
or
thousands
of
projects
that
they
need
to
go
through.
D
So,
as
always,
I
need
to
say
that
we're
talking
about
things
that
are
upcoming,
so
it's
important
to
use
this
information
for
informational
purposes.
Only.
Please
don't
rely
on
this
information
for
purchasing
or
planning
purposes.
We
reserve
the
right
to
make
changes
to
the
timing
or
the
feature
set
or
anything
else
about
what's
presented
here.
That's
our
sole
discretion
so
and
that's
the
disclaimer
that
I
need
to
give
you
for
this
and
moving
into
one
of
the
big
things
that
we
have
going
on
in
compliance
is
the
compliance
adherence
report.
D
So
with
this
we
want
to
be
able
to
take
a
look
at
your
gitlab
instance
groups
and
projects
and
start
to
tell
you
how
well
you
are
doing
in
terms
of
complying
with
specific
standards
or
regulations,
we're
going
to
be
starting
with
the
salsa
standard,
but
we'll
expand
that
out
to
others
in
the
future,
and
so
this
will
tell
you
exactly
what
the
checks
are
that
we're
looking
for
what
the
description
is
for
those,
so
that,
if
you've
never
thought
about
it,
you'd
be
able
to
read
about
it
there
and
then,
whether
or
not
you
pass
or
fail
those
checks
and
what
you
can
do
to
remediate
it.
D
D
You
can
stream
anything
and
then
for
the
UI,
we'll
also
be
providing
more
options
for
filtering
now,
so
that
you
can
look
at
what
the
type
of
event
was
or
what
the
object
was,
or
the
project
or
IP
address
and
produce
more
consistent
details
like
the
event
type,
so
that
these
audit
events
are
grouped
correctly.
D
All
right
and
I
will
pass
it
back
over
to
I
think
this
is
this.
B
Is
me
perfect,
so
we
are
going
to
be
adding
the
dependency
list
at
the
sub
group
and
group
levels.
We
found
that
users
really
want
to
be
able
to
see
across
multiple
projects,
and
so
after
we
do
the
group
and
subgroup,
we
are
also
going
to
be
adding
this
to
the
organization
level
and
in
addition
to
that,
we'll
be
adding
more
abilities
for
searching
and
filtering
through
dependencies.
So
you
can
quickly
see
what
those
dependencies
are
across
a
broader
range
than
just
a
project.
B
And
then,
on
the
vulnerability
report,
we
will
also
be
adding
more
advanced
filtering
to
be
able
to
quickly
add
multiple
chains
of
filtering
beyond
what
we're
able
to
do
today.
The
way
that
the
current
design
is
there's
a
lot
of
limited
space,
and
we
wanted
to
shift
that
so
that
way,
users
can
chain
together
exactly
what
they
want
to
see
with
those
filters.
B
C
Yeah,
so,
as
you
can
see,
filtering
is
a
common
theme
here
as
we're
looking
at
more
granular
security
approval
policies.
We
know
that
Security
Professionals
and
compliance
professionals
are
dealing
with
large
volumes
of
vulnerabilities
that
they
have
to
sift
through
today
and
so
we'll
be
adding
additional
filters.
That'll
help
you
to
narrow
the
focus
on
which
vulnerabilities
are
actually
actionable,
so
the
first
filter
we'll
be
adding
is
around
the
age
of
the
vulnerability.
C
We'll
also
be
adding
filters
to
identify
whether
or
not
a
false
positive
is
detected
or
if
a
fix
is
or
is
not
available,
and
this
will
enable
you
to
set
rules
to
address
fixes
with
a
certain
SLA
based
on
severity,
as
well
as
filter
out
false
positives
or
vulnerabilities
for
dependencies
that
don't
currently
have
a
fix
available,
which
can
greatly
reduce
the
noise
for
your
team
and
we'll
move
to
the
next
one,
which
is
compliance,
merge,
request,
approval
policies,
and
while
we
know
that
security
and
compliance
policies
today
encourage
the
right,
behavior
and
start
to
enforce
the
right
Behavior
to
prevent
vulnerabilities
from
reaching
business
operations,
it's
also
critical
that
we
can
guarantee
and
trust
and
that
these
policies
can
be
upheld
to
scrutiny
when
it
comes
to
compliance
of
the
policies
themselves.
C
The
unified
solution
for
enforcing
scan
execution,
and
we
know
that
customers
today
are
really
challenged
when
they're
trying
to
determine
when
to
use
compliance
pipelines
or
when
to
use
security
policies.
There
are
pros
and
cons
and
advantages
and
limitations
in
both
cases.
Fortunately,
we're
planning
to
bring
the
power
of
compliance
pipelines
into
security
policies
for
a
more
unified
experience.
C
Policies
will
be
able
to
be
linked
up
to
your
compliance
Frameworks,
making
it
easier
to
conceptualize
which
rules
you're
applying
across
which
projects.
This
will
also
give
you
the
flexibility
to
apply
compliance
framework
labels
across
multiple
projects
and
start
to
reuse
policies
where
they
overlap,
while
also
getting
that
Precision
to
Target
the
right
policies
with
the
necessary
requirements
and,
additionally,
as
you
do
Define
these
policies
you'll
be
able
to
Define
custom
yaml
to
enforce
any
custom
requirements
as
you've
done
in
compliance
policies
within
a
security
policy.
C
A
Great
thanks
for
that
and
then
shifting
over
to
the
work,
that's
being
done
by
our
software
supply
chain
security
working
group,
which
we
just
recently
stood
up.
We
currently
have
the
ability
to
generate
a
salsa,
II
compliant
attestation,
for
those
of
you
who
may
be
unfamiliar
with
what
an
attestation
is
or
why
it's
important.
This
is
a
document
that
gets
generated
alongside
a
build
artifact
as
part
of
your
CI
Pipeline,
and
it
contains
a
list
of
all
of
the
inputs,
ideally
as
well
as
information
about
the
output
of
that
build
job.
A
So
any
input
parameters
that
contain
the
information
about
the
architecture
of
the
runner
which
Runner
was
used,
which
commits
Shaw
of
the
git
repo,
was
pulled.
What
the
entry
commands
were
and
then
it
also
contains
like
a
Shaw,
an
identification
for
the
final
build
artifact
that's
produced,
and
that
in
theory,
would
allow
you
to
take
that
attestation
and
go
reproduce
that
build
bit
for
bit
on
a
separate
machine.
A
So
we
have
that
ability
to
produce
an
attestation.
Currently,
however,
we're
not
signing
it
yet.
So
there's
no
guarantee
that
that
attestation
itself
hasn't
been
modified
or
tampered
with.
So
what
we're
working
on
on
the
roadmap
is
to
add
the
ability
to
sign
that
attestation
automatically
just
inside
of
the
gitlab
runner
users
can
sign
artifacts
on
gitlab
today,
however,
there's
a
lot
of
complexity
around
that
they
have
to
maintain
typically
a
key
management
system.
They
have
to
rotate
their
keys.
A
That
will
only
last
like
10
minutes
that
will
eliminate
the
need
to
rotate
your
keys
or
to
store
them
in
any
way
and
then
we're
planning
on
using
that
key
inside
of
the
gitlab
runner
itself
to
sign
that
attestation,
so
that
that
happens
by
default
without
any
additional
configuration
on
the
end
of
part
of
the
end
User,
it's
a
very
ambitious
goal
and
we're
just
starting
into
it.
But
that's
our
vision
and
that's
where
we're
headed
for
that
area.
A
So,
just
to
summarize
up,
we
have
a
lot
of
really
big
things
coming
out:
everything
from
adding
like
group
and
subgroup
level
dependency
list
to
more
unified
auditing
that
help
with
our
top-down
security
theme.
We
have
features
around
compliance
adherence
report,
as
well
as
enforcement
of
compliance
level
policies
against
merge,
requests
that
focus
on
or
no
compromises
for
a
compliance
theme
and
then
throughout.
We
have
plans
to
integrate
more
tightly
into
the
depth.
Tech
Ops
life
cycle
and
make
sure
that
we're
continuing
to
shift
security
left.