►
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
so
for
this
I
don't
expect
any
decisions
or
anything
to
come
out
of
the
meeting.
Basically,
what
I
was
hoping
is
kind
of
a
quick
where
everyone's
kind
of
thinking
of
going
for
policies
and
rules
and
then,
if
possible,
later
populated
in
any
epics
or
issues
into
the
agenda.
So
this
way
anyone
who
feels
that
there
is
something
that
is
relevant
to
what
we're
they're
working
on
or
we'll
be
working
on.
They
can
keep
an
eye
on
it
and
then
I
put
a
read-only
for
an
asynchronous
discussion.
Just
kind
of
what
do.
A
B
B
One
of
the
features
we
implemented,
for
example,
was
merger
instance
level,
merge,
request
approval
rules
because
enterprise
customers
have
said
we
want
to
be
able
to
restrict
this.
We
don't
want
anybody
to
change
it
unless
or
an
admin
or
an
authorized
user
type
of
thing.
That
seems
to
be
the
general
trend,
except
moving
it
to
a
group
level
for
gillip,
comm
and
enterprise.
B
But
the
bigger
item
coming
down
the
pipe
is
trying
to
replace
forced
includes,
because
that's
currently
manifesting
right
now
as
some
sort
of
group
level
policy.
That
says
here
is
a
definition
of
the
required
jobs
that
have
to
run
as
part
of
our
compliance
program
and
then
making
sure
that
that
is
implemented
for
any
regulated
projects
in
the
group.
A
B
C
C
What
this
is
initially
is
just
the
ability
to
view
policies
that
have
been
created
for
cilium
and
do
you
enable
or
disable
those
policies
so
in
the
spirit
of
iteration
we're
starting
at
super
small
and
when
I
take
tucked
away
it's
intentionally
tucked
away
just
because
we
didn't
want
to
introduce
a
new
policy
page
that
was
a
little
bit
more
noticeable
in
the
UI
and
then
underwhelmed
the
users
with
our
MVC.
That
really
is
a
minimal
state.
So
the
plan
is
as
that
grows
and
develops
in
the
future.
C
You
know
we
really
envision
other
types
of
policies
going
into
that
same
page,
including
secure
policies
and
when
it
gets
to
that
point,
we'll
move
it
out
from
it's
sort
of
tucked
away
hidden
spot
and
make
it
more
of
a
proper
menu
item.
Dedicated
of
policy
management
for
four-year
security
policies
and
II
did
I
miss
anything
there
and
he's
designing
that
one.
C
A
A
The
kind
of
two
areas
that
I'm
looking
at
is
one
we've
got
a
low
list
and
denialist
going
on
for
license,
and
people
want
to
be
able
to
manage
that
at
the
group
level,
because
today
it's
at
the
project
level,
people
have
asked
right
now
for
the
dependencies
to
potentially
be
able
to
require
approvals
at
different
settings
right
now.
It's
only
critical
and
high,
so
we're
gonna
experiment
a
little
bit
more
and
see
what
exactly
they
want,
because
everyone
said
they
want
more
flexibility
in
that
policy
or
a
rule.
A
But
we
haven't
gotten
specifics
around
what
and
then
for
containers.
Today,
we
don't
other
than
the
critical
and
high
vulnerability
thing
just
like
dependencies.
We
don't
have
any
limitations
today
and
I
haven't,
had
any
requests
for
it,
but
I'll,
probably
piggyback
off
the
work,
we're
doing
for
moving
the
rules
to
the
group
level
and
just
allow
you
to
set
the
on
off
at
the
group
level
for
containers,
because
it
should
be
really
easy.
Carry
over
work,
but
I've
had
no
other
requests
to
date.
A
E
Sorry
had
to
get
off
mute,
we
don't
have
anything
specifically
planned
right
now,
because
we're
going
in
the
direction
of
creating
profiles
for
scan
and
site
settings
there's
some
discussion
about
whether
we
need
to
be
able
to
force
those
profiles
from
a
group,
or
instance
level
as
policies
to
make
sure
that
everybody
who's
scanning
their
their
code
or
scanning
their
site
is
in
line
with
the
corporate
policy.
So
this
is
really
more
useful
when
we're
talking
about
Enterprise
readiness,
so
I'm,
not
sure
right
now
we
were
really
focusing
on
on
the
individual
developer
level.
E
F
Okay,
so
in
a
high
level
we
have
a
lot
of
scanners
and
those
scanners
are
some
are
better
than
others.
They
also
in
consistently
had
various
feature
sets
so
we're
trying
to
think
of
how
do
we
create
abstracted
sort
of
layers
of
policy
around
it?
So
there's
sort
of
three
areas
that
I'm
interested
in
one
would
be:
how
do
you
force
scanners
to
be
required
to
be
run
for
different
projects
that
could
be
at
the
instance,
the
group
or
the
project
level?
F
So
having
a
way
to
say,
you
can't
do
anything
until
scanners
are
set
up
and
then
enforcing
that
over
time.
We
then
have
one
where
not
all
projects
have
the
same
risk
level.
So,
for
example,
like
my
authentication
service
might
have
a
higher
security
requirement
than
say
my
documentation,
repo
so
being
able
to
set
a
risk
level
for
different
project
and
have
that
impact
the
types
of
scan
severity
that
we
have
so,
for
example,
today,
our
mr
approvers.
F
They
only
work
with
hard-coded,
critical
and
high.
That
may
be
great
for
my
authentication
repo,
but
it
may
be
overly
harsh
for
my
documentation,
repo,
so
ways
to
be
able
to
enforce
that
at
different
levels
and
then
sort
of
related
to
this
is.
Who
am
I
allowing
to
change
my
configuration
settings
for
my
scanners?
This
is
to
prevent
people
or
developers
from
going
and
excluding
certain
things
that
maybe
they
do
or
don't
want
to
be
scanned
in
a
way
to
circumvent
a
security
policy
decision.
A
B
Know,
let's
yeah,
we
can
certainly
sync
up
about
that,
because
we're
trying
to
we
introduced
the
compliance
framework
labels,
one
for
reporting
on
kind
of
the
audit
and
compliance
management
side,
but
also
so
we
could
very
tactfully
target
things
like
what
you're
talking
about,
because
in
a
lot
of
cases,
as
you
all
know,
they
don't
want
it
for
all
projects.
I
mean
that's
a
rare
use
case.
They
want
it
just
for
the
regulated
ones,
and
that
was
our
answer
to
that.
So
maybe
it'll
be
helpful
for
you.
G
C
H
H
It
was
at
the
top,
so
I'm
assuming
you
did
I
wanted
to
add
something
for
defend,
and
that
is.
It
seems
like
one
of
the
key
things
that
would
be
really
helpful
and
I.
Don't
know
if
this
falls
in
defend
or
compliance
or
maybe
a
handshake
between
them,
but
would
be
the
ability
to
set
policies
that
cross
the
different
cloud
service
providers.
So
they
all
do
things
a
little
bit
differently
and
then
you've
got
containers
and
kubernetes
and
they
all
have
different
settings.
H
It
would
be
awesome
if
we
had
a
way
to
sort
of
an
English
like
language
set
policy,
and
then
that
translates
out
to
the
different
cloud
providers
and
kubernetes
and
and
whatever
so
that
they
only
have
to
know
get
lab.
They
don't
have
to
know
all
of
those
different
pieces
and
I.
Don't
know
like
I
said
where
that
fits,
if
that's
a
defending
or
a
compliance
thing
or
something
else,
but
food
for
thought
that
I
just
wanted
to
get
out
there.
C
Yeah
that
makes
sense
a
we,
the
policies
that
I'm
working
on
or
not
cloud
provider,
specific,
I,
guess
technically
they're
technology,
specific
so
being
specific
to
psyllium,
but
we're
trying
to
abstract
that
away
and
not
you
know,
put
it
front
and
center
that
he
I'm
creating
a
cilium
policy.
Instead
we're
focusing
on
what
the
policy
is
actually
doing,
but
it
will
just
be
one
set
of
policies
regardless
of
the
cloud
service
provider.
C
Yeah
so
wherever
they're
deployed,
if
they're
deployed
in
AWS,
then
it's
gonna
push
the
policies
there
so
deployed
ng
CP
it'll
push
them
there
actually
I.
Think
right
now,
with
psyllium
I
have
to
double
check
on
this,
but
if
I'm,
not
mistaken,
I
think
we
only
support
CCP
at
the
moment,
but
when
we
do
support
AWS
down
the
road,
there's
not
going
to
be
any
difference
between
the
two.
So,
whichever
cloud
provider
you
have
your
environment
set
up
to
deploy
to
you,
that's
where
the
policies
will
go.
Nice.
A
I
Going
to
bring
that
to
disabilities
I
think
we're
are
mixing
a
lot
of
notions
around
policies
here.
I
would
not,
for
example,
put
the
policies
that
are
tied
to
chrome
environments
or
cluster
with
the
police's
that
we
would
have
for
the
world
security
maturity
model,
for
example.
It's
something
that
is
really
different
to
me
and
I
know
it's
the
same
name
that
in
this
case
we
could
put
all
the
police
is
ready
to
be,
could
be
19,
for
example,
in
this
in
this
bucket,
so
think
we
should
start
defining.
I
A
Unfortunately,
at
least
from
my
experience,
our
users
use
rules
and
policies,
interchangeably
and
also
meaning
different
things,
which
I
think
is
the
beginning
of
the
confusion.
/
interesting
how
we're
gonna
have
to
choose
to
if
we're
going,
to
choose
to
have
particular
meanings
for
each
one
of
those
words.
C
I
mean
I
agree
that
some
of
the
things
that
we're
talking
about
here
don't
really
feel
like
the
way
that
I
would
use
the
word
policy.
You
know
like,
for
example,
Taylor.
You
know
we're
looking
at,
of
course,
requiring
or
forcing
scanners
to
be
enabled.
It
almost
seems,
like
you
know,
I
guess
now
we're
getting
into
semantics
and
terminology,
but
it
almost
seems
like
a
configuration
setting
more
than
like
a
policy
or
rule
and.
C
C
B
He
and
I
had
met
to
talk
about
how
at
least
a
compliance
group
could
leverage
that
type
of
work
to
say,
for
example,
one
of
my
requirements
I
defined
could
be
that
all
regulated
projects
run
this
particular
CI
job
and
I
suspect
that
could
probably
be
extended
to
include
defend,
secure
and
all
these
different
elements,
and
so
a
requirements
management
might
be
something
that
we
either
replicate
with
better
at
like
different
functionality
or
just
rebrand.
In
a
way,
that's
maybe
more
Universal,
like
policies
or
something.
A
C
B
And
then
you
get
into
the
discussion
of
policy
versus
process
and
I
think
for
the
for
the
customers
that
we're
all
typically
dealing
with
the
enterprise
kind
of
risk-averse
regulated
context,
ultimately,
their
policies,
the
way
that
I
think
about
it
I
think
is
aligned
with
Nicole
where
policies
are
aggregation
of
rules,
but
those
rules
are
based
on
the
legal
or
regulatory
framework
or
trying
to
adhere
to.
So,
if,
let's
say
sarbanes-oxley
stipulates
various
requirements,
they're
gonna
create
in
their
SDLC
policy
various
different
rules
that
comprise
that
policy
in
aggregate.
B
But
each
of
those
rules
is
meeting
a
particular
requirement
or
set
of
requirements
at
the
frame
are
like
the
compliance
framework
level.
So
I
wonder
if
we
can
leverage
something
like
that
to
say
you
know:
here's
some
binding
framework
which
manifests
as
policies
which
consists
of
rules,
workflows,
processes
that
you
can
then
translate
into
gitlab
and
maybe
there's
something
there.
G
So
that's
a
policy
coming
out
of
the
procedure,
but
the
process
would
change
like
Auto.
Devops
must
employ
tasks
for
them
for
them
to
be
compliant
so
I
just
think
we
we're
going
to
figure
out
how
to
you
know,
walk
that
fine
line
to
make
sure
we're
covering
both
sides
of
that,
because
I
think,
depending
how
you
worded,
it
sounds
like
it's
a
process
problem
versus
a
policy
problem
and
vice
versa.
A
We
could
also
try
out
a
couple
different
messages
and
see
which
resonate
better
because
we
could
say-
and
I'm
just
gonna
make
this
up.
I'm,
not
sure
that
this
would
be
a
good
one,
but
we
could
test
with
a
group
of
users
like
we're,
setting
up
policies
that
help
you
enforce
your
desired
processes
or
we're
setting
up
policies
that
help
you.
You
know,
enforce
your
desired
workflows
and
then
we
could
find
out
which
one
resonates
better
and
roll
with
that,
as
like
kind
of
our
explanation.
A
J
Yeah
I
think
evaluating
it
from
a
task
is
the
best
way
to
do
this.
I
don't
want
to
avoid
putting
up
words
and
getting
their
definitions
of
it,
because
I
think
you're,
right,
Nicole,
it's
gonna,
be
so
scattered,
so
get
lob
should
come
for.
The
point
of
view
of
this
is
how
we
intend
to
define
them,
and
then
we
just
see
if
that
makes
sense
and.
B
A
F
Just
say
that
a
duo
we
struggled
with
this
whole
language
thing
for
a
very
very
long
time
and
we
never
found
anything
that
consistently
worked.
It
was
more
of
decide
something
and
commit
to
it
consistently
and
let
anybody
else
who
has
whatever
framework
or
standards
or
language
they're,
using
reconcile
that
with
the
Atlanta
proach
I'm
trying
to
find
the
document
we
had
it
doooo,
it
might
not
be
public-facing,
but
basically
we
had
this
triangle
that
told
you
how
we
thought
about
various
compliance
needs
in
the
ways
that
we
supported
the
various
like
FedRAMP
PCI.
I
I
I
A
B
Yeah
I
don't
have
an
answer
for
that.
I
think
that
they're,
like
my
gut
feeling,
is
that
there
will
be
some
things
that
make
sense
to
put
together
in
a
single
location
and
then
other
things
will
likely
belong
in
their
respective
specialty
areas.
One
of
I
think
there's
a
conversation
I
had
with
maybe
I
think
is
Matt
Wilson
and
we
were
talking
about
I,
think
the
compliance
dashboard
versus
the
security
dashboard
and
things
like
that
and
you
know
for
the
compliance
dashboard.
B
We
want
a
surface
like
high
level
insights,
but
we
want
to
send
customers
over
to
the
security
dashboard.
If
there
is
something
more
granular,
they
need
to
understand.
I
think
maybe
that's
similar
thing
here,
where,
if
there's
high-level
stuff
at
use,
you
could
justifies
like
an
organizational
level
policy
or
whatever
language
we
use
that.
Maybe
that
belongs
in
a
unified
space.
But
then,
as
you
start
drilling
into
the
details,
logistics
or
like
implementations,
process,
specific
type
things,
maybe
that
belongs
elsewhere.
That's
just
my
general
rough
thoughts
on
it
right
now.
Personally,
I.
A
Mean
my
immediate
thought
was:
most
widgets
would
start
insecure,
or
at
least
the
sca
ones
would
and
then,
as
and
I
believe.
This
is
an
eventual
goal
where
there's
going
to
be
like
certain
things
like
NIST
or
whatever,
that
you're
gonna
try
to
help
users
with
and
as
you
get
there
that
cross-linking
effect
that
you
were
referencing.
We
could
start
working
with
you
on
that,
but
until
those
whiter
things
that
make
cross-linking
aníbal
I
was
thinking.
A
B
Think
it's
probably
worth
starting
those
discussions
now
at
least
lightly,
because
prior
to
discovering
the
work
that
mark
was
working
with
requirements.
Management
I
had
created
an
issue
to
rename
push
rules
to
policies
because
that's
where
we
also
have
the
merge,
request,
approval
settings
and
it
doesn't
make
sense
because
those
aren't
push
rules
and
then
I
I,
don't
I
think
I've
sort
of
put
that
on
the
backburner.
K
Would
it
make
sense
to
start
at
a
lower
level
first
like
at
the
project
level
and
then
push
up
because
it
I
guess
Matt
I
see
what
you're
working
on
is
much
more
instance
level.
So
you
know,
for
example,
if
we
are
defining
on
a
per
project
basis,
what
scans
need
to
happen
or
any
sort
of
and
I
like
mine,
about
the
only
one
that
I
have
would
be
a
yes/no
for
requiring
an
approval
for
a
dismissal.
K
The
vulnerability,
for
example,
because
it
seems
like
yours,
would
be
much
more
at
the
global
level
and
then
we
could
just
sort
of
aggregate
up.
So
you
would
have
a
global
policy
that
might
say
turn
on
and
one
of
the
NIST
compliance
flags
which
may
roll
down
into
our
stages,
but
could
have
factors
elsewhere,
PCI
something
at
eye
level,
and
would
that
make
sense.
K
B
C
Maybe
at
least
immediate
next
steps
would
be
for
Matt
you
myself
and
Andy
to
get
on
a
call
and
just
go
through
it
a
little
bit
more
detail.
What
we've
got
planned
in
your
term?
What
you've
got
planned
in
the
near
term,
I
mean
it
seems,
like
our
two
groups
are
the
ones
that
are
actually
getting
time
to
work
on
this.
The
soonest,
but
maybe
you
know,
as
long
as
we
think
up
for
now,
that's
good,
and
then
we
can
kind
of
cook
from
there
on.
B
Yeah
I
think
I
think
that's
good
I'll
also
say
too
that
the
compliance
group
is
typically
focused
on
taking
existing
project
settings
and
bringing
them
up.
I.
Think
I,
guess
kind
of
am
at
Wilson's
point
so
for
the
things
that
become
new
or
novel
project,
level,
settings
or
experiences
and
if
I
make
sense
for
those
respective
groups
to
take
those
on
and
then
maybe
the
compliance
group
comes
into
abstract
those
up
a
layer
or
two
but
I
think
definitely
worth
the
sink
to
figure
out
how
best
to
approach
that
yeah.
G
I
think
Sam,
your
biggest
challenge
is
gonna,
be
I.
Guess
the
route
peacemaking
antiseptic
old
minutes
ago,
like
where
do
you
configure
the
laughs
versus
you,
know
the
CBA
stuff
you're
working
on?
And
how
does
that?
Look
like
Matt
Gees
view,
because
they
all
use
PCI
and
like
he
probably
just
wants
to
show
a
checkbox
the
last
deployed.
You
know
like
a
little
happy
smiley
face
or
something
but
somewhere
below
that
you
actually
have
the
they
have
to
have
that
configuration
that
I.
Don't
think
these
would
be
exposed
at
his
level.