►
From YouTube: Secure, Protect, Compliance Sync
Description
A discussion about Security Orchestration's Policy UI and Compliance's roadmap
B
Correct
so
I
just
wanted
to
give
just
to
start
this
off.
I
wanted
to
give
a
recap
of
what
our
road
map
is
currently
and
just
make
sure
that
we're
fully
aligned
around
what
that
is
and
how
it
relates
to
compliance
and
where
we're
working
together
and
make
sure
that
there's
no,
you
know
that
we're
fully
complimentary
in
everywhere
we
can
be
so.
B
Yes,
let
me
share
my
screen.
I've
got
a
lot
of
details
on
our
direction
page,
but
I
don't
necessarily
expect
you
to
read
all
of
that.
The
short
summary
is
that
we're
trying
to
provide
both
an
alert
dashboard
and
a
policy
ui
to
let
users
manage
their
security
policies
and
their
security
alerts.
So
on
the
alert
dashboard
side,
we're
collaborating
with
sarah
we're
actually
using
all
of
the
backend
monitor
team
code,
but
implementing
it
on
the
front
end.
B
So
it's
specific
for
security
alerts
as
opposed
to
the
alerts
that
show
up
now
there
are
centered
around
like
cpu
and
memory.
You
know
usage
errors,
things
that
a
knock
would
take
on
rather
than
a
sock,
so
that's
kind
of
where
we're
segmenting
between
the
two
of
us
there
on
the
alert
dashboard
side
and
then
on
the
policy
side.
B
We
actually
have
some
policy
ui
now,
but
we're
planning
to
add
that
out
to
support
scans,
the
most
salient
and
most
near-term
of
these
are
scan
execution
policies
and
scan
results,
policies
where
scan
execution
policies
govern
when
a
scan
is
run
and
then
scan
results.
Policies
govern
what's
done
after
that
scan
is
complete
and
has
presumably
either
found
some
findings
or
not,
and
we
want
to
do
this
for
all
of
the
different
scanners.
B
So
we
get
kind
of
this
big
matrix
of
things
that
we
want
to
take
on,
and
we
want
to
do
this
not
only
at
the
project
level,
but
at
the
group-
and
I
know
there
is
no
instance
object,
but
we
want
to
provide
a
way
to
apply
these
settings
to
your
entire
gitlab
instance
across
all
of
the
groups
that
you
own
as
well.
So
we
do
have
a
rough
prototype
of
this.
B
The
idea
is
that
this
would
be
a
new
navigation
item
in
the
in
the
security
and
compliance
nav
area.
So
you
would
come
here
you're
going
to
get
a
list
of
the
policies
that
you've
set
up.
This
particular
view
is
on
the
project
level,
but
we're
going
to
replicate
it
for
the
other
areas
as
well
and
depending
on
where
things
go
with
what
melissa's.
Looking
at
with
workspaces,
we're
hoping
that
we
have.
B
That
says
you
know
if
a
pipeline
is
run
say
against
the
master
branch,
then
I'm
going
to
require
das
scans
to
run
with
this
configuration,
you
know,
scan
a
or
scan
v,
so
that
configuration
is
going
to
is
stored
in
the
database
for
das
today,
and
this
ultimately
would
generate
a
yaml
file.
So
we
do
want
to
preserve,
like
the
infrastructure
is
code
paradigm,
so
you
would
get
the
yaml
representation
of
this
policy
and
you
could
all
optionally
switch
over
into
yaml
mode
and
just
edit
that
yaml
directly.
B
B
You
could
also
come
in
and
schedule
things
on
like
a
daily
or
weekly
basis,
depending
on
you
know
what
you,
whatever
you
want
to
do
here
and
you
could,
you
know,
send
yourself
an
alert
or
send
a
slack
notification.
Saying:
hey,
you
know,
a
scan
was
kicked
off.
Your
weekly
job
was
kicked
off
if
you
wanted
to
just
keep
tabs
on
it.
So
it's
very
flexible.
You
have
this
sort
of
generic.
If
this,
then
that
framework
and
then
on
the
scan
results
side,
this
is
all
about
what
happens
when
scans
complete.
B
So
you
could
say
if
any
scan
finds
a
critical
vulnerability.
I
want
to
fail
the
pipeline,
and
I
want
to
require
approval,
and
I
want
to
you
know,
also
send
an
alert
and
a
slack
notification,
so
you
can
kind
of
you
know,
get
that
same
workflow,
but
customize
it
depending
on
you
know
what
you're
looking
at.
If
it's
license
compliance,
you
know
maybe
you're
just
looking
for
certain
licenses
that
are
showing
up
at
the
end
of
the
day.
Like
I
see
this
is
very
complementary
to
what
we're
doing
already.
B
We
are
planning
to
move
things
out
of
the
ci
yaml
file
as
much
as
we
can
and
into
the
database.
However,
we
don't.
Our
current
plans
are
not
to
replace
the
getlab
ci
workflow,
so
users
would
still
be
able
to
configure
it
with
their
gitlab
ci
aml
file,
but
anything
configured
in
this
policy
ui
would
take
precedence.
B
If
the
developer
is
borked,
their
gitlab
ci
yaml
file
or
introduced
weird
afterscripts
that
could
potentially
disable
the
scanning,
this
is
going
to
come
in
and
essentially
override
that
so
that
it
still
runs
anyway
and
that
policy
is
enforced.
So
that
way,
once
you
have
a
policy
set
up,
you
don't
have
to
keep
checking
on
that
gitlab
ciaml
file
and
say:
hey
did
anything
change.
Did
anyone
break
it?
No,
it's
it's
gonna
work!
If
you
set
it
up,
it's
gonna
work
every
time,
no
matter
what
what's
in,
that,
ciam
will
follow.
B
So
that
way,
there's
a
little
bit
of
separation
of
duties
there.
We
would
still
let
the
developers
view
the
policies
but
the
long-term
vision,
and
this
isn't
going
to
happen
immediately,
but
the
long-term
vision
is
that
you
would
actually
have
a
separate
security
approval
workflow
for
changes
to
those
policies
outside
of
like
your
developer,
workflow,
where
you
don't
necessarily
need
a
developer,
maintainer
approving
those
changes.
B
Instead,
you
need,
you
know,
a
security
personnel,
approving
changes
to
your
your
scan
jobs
and
when
they
run
it
is
going
to
get
a
little
bit
dicey
when
we
up
level
to
group
and
instance,
simply
because
some
of
the
configuration
settings
need
to
be
set
at
the
project
level
like
they're
project
specific,
for
example
like
which
sas
scanner
you
run.
Or
you
know
for
das,
which
url
you.
You
start
the
scanner
against.
B
But
we
are
trying
to
do
some
research
and
we're
still
thinking
through
exactly
how
that's
going
to
work.
But
the
idea
is
that
you
would
still
be
able
to
say
at
a
group
level.
I
want
das
to
run
for
all
of
the
projects
under
it
and
maybe
for
the
projects
under
that
you
would
have
like
a
default
configuration
or
something
like
that
that
it
pulls
in
so
again.
B
It's
going
to
be
a
ways
out
before
we're
fully
done,
but
we
do
want
to
leverage
the
immutable
label
work
that
you've
done
to
at
the
instance
level
say
you
know,
I
want
to
only
scan
projects
that
have
that
are
marked
compliance
or
that
are
marked.
You
know
san
scan
for
sas
and
again
you
don't
want
a
developer
to
go
and
accidentally
remove
that
label.
So
the
immutable
label
thing
works
perfectly
with
that
idea,
where
you
could
just
write
a
policy
that
says
the
project
level.
B
You
know
when
a
pipeline
runs
against
the
default
branch
for
any
project
with
the
compliance
label
like
then
require
sas
scans
to
run,
and
that
way
it's
a
one
and
done
like
I
configure
this
once
it
applies
to
my
entire
instance,
and
if
I've
got
1400
projects
out
there,
you
know
I
don't
have
to
go
into
each
one
individually
and
constantly
check
up
on
it.
So
that's
where
we're
headed.
That's
our
roadmap.
I've
probably
talked
too
much,
but
is
that
consistent
with
what
you
expected?
Is
that
different?
How
does
that
align
with
your
current
plans?.
A
A
Maybe
those
are
just
kind
of
my
initial
thoughts
in
terms
of
sort
of
the
original
catalyst
for
this
discussion
around
the
product,
the
product
leadership
off
site.
I,
like,
I,
don't
see
detrimental
overlap
or
friction
in
any
way.
I
think
when
you-
and
I
last
spoke
about
it-
my
perspective
was
yes
like.
Do
this
thing
that
you're
working
on,
I
see
a
lot
of
value
for
it,
especially
or
particularly
for
the
security
stakeholders.
A
A
A
Let's
do
that
stuff,
natively
and
some
of
it
we
can
and
are
doing
now,
but
there
that's
that
still
won't
convince
an
organization
to
offload
entirely
these
complex
systems
and
workflows
that
they
have
so
we're
trying
to
pull
some
of
it
out
with
things
like
api-based
approval
rules
on
the
merge
request,
but
then
there's
stuff
that
has
to
happen
after
the
merge
request
is
merged.
That's
still
part
of
that
auditor
compliance
program.
A
I
think
scanning
is
one
of
them
because
scanning
some
organizations
have
said
that
they
do
it
both
during
the
like
that
that
build
and
merge
window,
but
they
also
do
it
after
the
fact
to
make
sure
that
there
hasn't
been
any
changes
or
something
unaccounted
for,
is
sort
of
that
like
risk-averse
double-check
yeah.
So
I
I
think
it's
fine.
I
don't
think
there's
overlap.
I
think
at
some
point
like
in
maybe
a
year
and
a
half
or
more
all
things
remaining.
A
The
same
we
might
have
to
circle
back
and
say:
okay
now,
how
do
we
unify
this
experience
at
some
point
so
that
we
don't
have
two
very
different
dashboards
which
are
ultimately
benefiting
the
organization
in
that
security,
compliance
umbrella?
And
maybe
that's
still,
okay,
but
I
suspect
we
might
have
to
unify
it
at
some
point.
I
think
that's
far
off,
especially
as
we
start
evolving.
These
features.
B
Yeah
absolutely-
and
I
mean
right
now
as
far
as
dashboarding
goes
like
you
know,
some
use
cases
that
we're
not
really
showing
today
are
that
we're
not
tackling
our
answering
questions
like
when
we're
scans
last
run.
You
know
we're
not.
My
category
anyway
is
not
delving
into
dashboarding.
I
know
matt's
got
his
vulnerability
dashboard,
but
I'm
focused
just
on
you
know,
managing
security
alerts
and
security
policies,
and
so
you
know
if,
from
a
compliance
perspective,
you
wanted
to
get
like
a
report
of
when,
when
were
all
the
projects
last
scanned
right.
B
That
would
be
outside
of
where,
where
we're
tackling
anyway,
so
I
agree
100
on
board
with
you.
I
view
these
things
as
very
complementary.
I
don't
think
there's
a
huge
amount
of
overlap.
I
think
there
are
areas
where
we'll
be
able
to
jointly
leverage
what
each
other
is
doing.
Probably
the
nearest
term.
One
is,
you
know
us
leveraging
the
forced
labels
or
the
immutable
labels.
B
Work
that
you've
been
doing
will
probably
be
the
earliest
thing,
but
yeah
timing,
wise
it's
a
brand
new
category,
we're
gonna,
be
it's
gonna,
be
a
while
before
we've
got
a
lot
of
substance.
There,
anyway,
so
we'll
circle
up
and
we'll
certainly
stay
in
touch
and
continue
that
collaboration
as
it
evolves,
because
you
know
maybe
more
touch
points
in
the
future.
A
And
just
to
just
I
don't
know,
wave
away
that
that
horse,
because
I
don't
want
to
use
a
violent
term,
but
just
to
pet
that
horse.
I
think
that's
the
exact
perfect
example
of
we
have
an
open
issue
to
see.
I
think
it's
a
project
security
grade
or
something
like
we
just
want
to
take
that
high
level
data,
and
so
the
other
data
point
would
be.
A
When
was
it
last
scanned,
and
I
know
that
was
something
that
had
sid's
interest
as
well
as
far
as
customer
feedback
and
just
being
a
high
level
data
point,
that's
important,
so
yeah
exactly
what
you
said.
We
will
end
up
taking
some
of
that
data
and
complementing
the
compliance
dashboard
and
vice
versa.
So
sounds
good
to
me.