►
From YouTube: DAST Policy Sync
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
Awesome,
well
I'm
glad
we
could
find
a
time
that
worked
for
everyone
here.
We've
had
quite
a
lot
of
changes
to
our
implementation
plans
for
our
project
level.
Das
scan
execution
policies,
which
is
a
bit
of
a
mouthful
to
say
so.
I
just
wanted
to
walk
through
those
actually
before
I
do
that.
I
do
want
to
just
recap
some
of
our
permissions
requirements
for
policies,
especially
as
we've
started
to
do
this
problem.
A
If
you're
trying
to
enforce
a
policy
across
the
organization
that
you
must
run
a
das
scan
every
time
the
pipeline
runs,
or
you
must
run
a
desk
scan
once
a
week
like
making
sure
that
the
developers
don't
mess.
Something
up
for
thousands
of
projects
is
a
near
impossible
task,
and
so
some
of
the
requirements
that
we
have
in
place
for
our
policies
is
that
developers
can
view
it.
A
B
Just
a
good
question
on
that,
I
would
assume
that
the
security
team
would
have
to
be
a
maintainer
and
a
member
of
the
security
team,
so
you'd
have
to
have
that
that
those
two
two
permissions,
essentially
no,
not
necessarily
so
they
could
be
a
developer
like
we
don't
necessarily
care.
If,
as
long
as
they're
marked
as
a
member
of
the
security
team
yeah,
I
don't.
A
A
Thiago,
I
don't
want
to
put
you
on
the
spot.
Do
you
want
to,
but
are
you
comfortable
at
all,
through
some
of
the
changes
and
and
the
implementation
details
of
how
you're
proposing
to
handle
this?
The
engine
lanes
sure.
C
Sure
yeah,
so
we
we
last
time
we
met.
We
talked
about
using
database
implementation
to
store
some
of
these
policies.
How
they're
going
to
be
done?
There
was
before
we
had
a
spike
and
during
the
spike
we
were
hashing
out.
This
was
done
by
machia.
C
He
was
hashing
out
what
this
would
look
like
and
started
drafting
up
the
the
implementation
plans
for
it
as
an
alternative
to
database.
He
he
started
playing
with
the
with
the
yamo
solution,
so
the
the
challenge
when,
when
we're
doing
database
changes,
you
know
that
you
it's
gonna,
take
a
little
bit
longer
to
maintain
a
review
that
that's
that's
a
given,
but
in
something
that's
new
is
this
and
that
we
don't
have
complete
certainty.
What
it's
going
to
look
like
might
also
result
in
some
changes
down.
C
C
So,
for
example,
the
permission
and
the
auditability
of
changes,
it
does
make
permissions
a
little
bit
trickier
for
down
the
road,
but
for
mvc
it's
pretty
straightforward
you,
you
know
you
create
a
a
project
where
that
yaml
file
will
live
and
you
only
give
permission
to
the
people
who
are
allowed
to
change
the
policy
and
and
that's
it
complete.
C
You
you
could
do
these
things
in
a
single
milestone
and
that
now
you
have
something
to
iterate
on,
whereas
if,
if
we're
going
down
the
db
approach
very
unlikely
that
we
get
something
in
one
milestone,
maybe
not
even
two
right
by
the
time
you
get
all
the
database
changes
in
and
the
models
in
now
you
can
start
doing
the
the
actual
policy
and
apis
that
will
be
needed
for
the
front-end
to
talk
to
these
things.
B
So
just
a
quick
question-
and
you
guys
probably
went
through
this
you
mentioned
refactoring-
is
a
little
bit.
So
one
of
the
challenges
with
yaml
is,
if
you
change
the
structure
of
yaml,
it's
really
difficult
because
everyone's
got
their
own
yaml
file,
it's
written,
whereas
if
you
have
a
database,
you
just
rename
the
column
and
do
a
migration.
C
It's
a
good,
it's
a
good
call
out
yeah,
it
will
so
in
a
way
you
would
need
to
deal
with
a
sort
of
migration
right
for
the
ammo
either
you
need
to
do
something.
That's
backwards,
compatible
all
right.
This
person
wrote
in
that
old
version
or
you
break
it
and
say:
hey
yeah
I've
broke
your
yamo.
You
need
to
rewrite
it.
C
I
think
that's
a
that's!
A
choice
in
terms
of
you
know
what
we
wanna
optimize
for.
Do
we
wanna
call
this
alpha
in
mvc
and
get
a
chance
to
run
and
see
how
people
use
it
and
if
the
few
people
that
use
it
break
it,
then
we
we
need
to.
You
know,
rely
on
their
good
will
to
go
and
fix
that
or
do
we
want
to
put
the
effort
into
to
do
it,
but,
as
that
points
out,
it's
it's
treatable,
but
then
it
it
reduces
a
bit
the
advantages
so.
A
It
doesn't
have
to
be
yaml
but
yaml
or
json,
or
some
sort
of
code-based
way.
When
we
explored
this
with
users,
we
found
it
to
be
very
polarizing
with
very
strong
opinions.
You
have
people
like
you
know
that
are
die
hard.
I
will
only
do
this
in
code
and
I
don't
care
what
kind
of
ui
rules
editor
you
give
me.
I
just
want
to
do
it
in
code
and
that's
how
I
know
exactly
what
I'm
doing
and
then
you
have
people
on
the
other
end
of
the
spectrum.
A
That
say
I
don't
want
to
touch
the
code.
I
don't
you
know,
I
don't
understand.
Yaml
like
I
just
want
to
use
your
ui
and
I
found
it
was
about
50
50,
but
it
was
very
heavily
opinionated.
So,
even
if
we
did
something
in
the
database,
we
would
still
want
to
let
them
put
in
a
code
representation
of
that
rule.
A
So
I
think
we're
going
to
run
into
that.
You
know
it
might
ease
up
on
the
migration,
but
we
would
still
need
to
represent
that
in
some
way.
So
you
know
just
a
note
there.
C
Thank
you,
I'm
I'm
pretty
much
done.
I
mean
if
I,
if
I
keep
going
to
detail
here,
I'll
redo,
my
chase
demo,
there's
already
a
video
for
that,
so
anybody
watching
this
can
can
go
watch
that
instead,
if
there
are
any
questions
around
the
choice.
A
So
I
have
some
questions,
but
before
I
come
to
those,
I
just
want
to
highlight
some
of
our
future
plans
here
as
well,
because
you
know
well
thiago
highlighted
this.
Has
the
benefit
of
letting
us
iterate
fast
get
something
out
in
one
milestone.
A
It
does
come
with
the
drawback
that
the
user
experience
is
sub-optimal
so
down
the
road.
We
would
want
to
at
a
bare
minimum
auto-create
the
associated
policy
management
project
and
possibly
even
probably
hide
it
away
when
we're
dealing
with
those
permissions.
If
we're
trying
to
synchronize
things
maintainers
on
the
one
project
need
to
be
developers
on
the
other
project
like
that,
synchronization
is
going
to
get
messy
really
fast.
A
If
users
can
go
into
that
other
project
and
make
changes
like
how
do
we
do
a
two-way
synchronization
without
just
confusing
the
end
user,
so
we'll
probably
end
up
hiding
that
away
at
the
end
of
the
day
and
abstracting
it
away
so
to
the
user
for
the
user
experience
like
they
go
in,
they
create
the
policy
it
gets
submitted
for
approval,
someone
approves
it
and
it's
applied
and
they
don't
actually
see
or
know
or
care
about
where
that
underlying
data
is
being
stored.
A
A
So
I
I
do
have
some
questions
because
I
know
we've
also
got
overlap
with
the
das
team
and
your
plans
for
scheduled
scans,
and
I
think
this
is
an
area
that
we
probably
haven't
discussed
enough
anyway.
You
know,
regardless
of
where
we
store
it,
so,
whether
it's
the
database
or
here
we
want
to
make
sure
that
we're
working
together
in
that
regard
on
our
group
call
this
morning.
A
Allen
proposed
that
you
know.
In
the
past
we
were
talking
about
a
two-way
synchronization,
where
you
could
create
a
policy,
and
that
would
show
up
on
your
schedule
best
scans
and
you
could
create
a
scheduled
desk
scan
and
that
would
show
up
as
a
policy
derek.
I
don't
know
what
you
had
in
mind
for
permissions
on
that,
but
I'm
starting
to
wonder
if
we
want
to
rethink
that
and
possibly
only
have
the
our
policies
show
up
as
like
read-only
scheduled
scans.
D
Right
well,
that
was
one
thing
that
we
had
talked
about
was
that
those
policies
that
have
been
set
up
in
the
policy
editor
would
not
be
able
to
be
edited
in
the
das
schedule
area,
because
I
want
to
leave
it
open
for
developers
to
be
able
to
schedule
scans
from
that
ui
and
not
have
to
worry
about
going
through
any
maintainer
or
security
team.
Member
or
anything
like
that.
D
So
I
think
that
it
makes
sense.
I
I
don't
yeah,
I
don't
have
a
problem
not
showing
the
the
das
scheduled
scans
in
the
policies.
I
feel
like
that
that
we
don't
need
that
level
of
shared.
D
I
don't
know
to
me:
they're,
not
policies
they're
not
being
set
up
by
maintainers
or
security
team
members,
they're
not
being
set,
as
you
must
do
this,
it's
a
something
that
a
developer
is
setting
up
in
that
project
because
they
want
to
scan
while
they're
working
on
this
feature,
and
they
know
they're
deploying
code.
You
know
every
every
week
to
a
staging
server
and
once
they're
done
with
that
feature,
maybe
they
want
to
delete
their
scan.
I
mean
it's
not
really
a
policy
per
se.
D
D
A
A
So
I
mean,
if
we
do
that,
then
I
feel
like
that
mitigates
a
lot
of
the
challenges
that
we
might
have
as
well.
You
know,
if
you're
having
your
stuff
in
the
database
we're
having
ours
in
the
repository,
we'll
probably
move
to
the
database
at
some
point
in
the
future,
but
at
least
for
now
you
know:
we've
got
two
separate
data
stores.
Maybe
this
eases
that
problem.
D
Maybe
I'm
not
sure
and
and
I
don't
think
that
it
would
necessarily
be
a
hard
requirement
to
have
the
policies
show
up
in
the
desk
scheduled
scans
area
as
in
first
or
even
second
iteration,
and
it
to
me.
I
don't
feel
like
it's
absolutely
necessary.
I
think
it's
a
nice
to
have,
but
I
don't
think
that
it's
going
to
kill
any
of
the
user
experience
in
either
area.
A
Yeah,
I
agree
with
that.
Absolutely
that
could
be
that
could
be
kicked
down
the
road
pretty
far
yeah.
We're
really
talking
about
two
different
two
different
problems:
we're
trying
to
solve
right.
One
is:
let
the
developers
schedule
a
scan
for
their
own
benefit
versus
let
the
security
department
require
a
scan
to
be
run
every
week.
C
A
I
mean
we
don't
have
requirements
written
for
the
scan
results
policies.
Yet
so
we're
I'll
caveat
this
with
you
know
we're
still
figuring
it
out,
but
most
likely
we
would
want
those
policies
to
apply
to
all
scans
that
were
run
regardless
of
what
caused
it
to
run
so
we'd
probably
want
those
scan
results.
Ones
to
apply
to
any
you
know
any,
and
every
scan
that's
run
would
would
have
a
scan
results.
Policy
enforced
the.
D
The
difference,
though,
would
be
it
if
you're
looking
at
ci
cd
jobs
versus
on-demand
das
scans,
because
there
is
no
pipeline
to
fail
with
on-demand
scans
so
depends
really
on
how
we're
going
to
set
up
this.
The
policies
to
begin
with,
if
we're
going
to
set
it
up
as
a
ci
cd
job,
then
you're
really
going
to
have
a
separate
set
of
rules
that
you
could
apply
to
it
versus
the
on-demand
scans.
A
So
that
is
true
and
we
have
accounted
for
that
like
in
the
prototype,
you'll
notice,
and
I
mean
it-
it's
poor
man's
ux.
So
I
don't
know
if,
when
we
actually
have
ux
take
a
look
at
it
might
change.
But
we
just
have
a
note,
a
parenthetical
note
there
that
says
like
the
action
of
allow
and
fail
the
pipeline.
That
only
applies
if
it
was
part
of
a
pipeline
to
begin
with.
B
So
a
couple
of
things
just
to
note
so
on
demand
it
technically
does
run
on
a
pipeline.
It's
just
it's
a
pipeline
of
one
job,
but
one
of
the
things
to
think
about
is
the
jobs
have
their
list
of
vulnerabilities
and
they
don't
understand
what
vulnerabilities
have
already
been
managed
within
gitlab,
and
this
is
something
that
I'm
working
on
on
another
issue.
So,
for
example,
if
das
finds
three
vulnerabilities,
the
das
scanner
knows
that
it
found
three
vulnerabilities.
It
doesn't
know
that
those
three
vulnerabilities
had
been
dismissed
within
gitlab.
B
So,
if
you
say,
hey,
you
find
three
vulnerabilities
fail
the
job
or
throw
up
an
alert
or
whatever
it
doesn't
know
that
those
have
already
been
managed
somewhere
else,
and
this
is
one
thing
that
I
just
pointed
out
to
matt,
because
it
would
be
nice
that
what
we
do
is
we
take
those
three
vulnerabilities
and
the
scanner
just
sends
those
over
to
gitlab
and
says
hey.
I
found
these
three
vulnerabilities
and
gitlab
sends
back
a
message.
It's
like
great.
I
don't
care
about
those
they've
been
dismissed
until
we
have
that
in
place.
B
C
B
Yeah,
I
I
think,
as
you
say,
I
think
it's
fine.
I
think
you
may
end
up
with
a
major
usability
headache,
particularly
if
you
have
like
some
call
out.
That's
like
hey.
This
is
a
critical
vulnerability
and
someone's
like.
I
don't
care
about
that.
It's
it's
a
false
positive
because
of
the
false
positive
problem.
A
Yeah,
so
I
agree
with
that,
I
mean
I
just
want
to
kind
of
re
refocus
this
discussion,
because
I
I
fully
agree
with
what
you've
said
seth
but
like
right
now.
I
just
really
want
to
focus
on
because
we're
not
even
dealing
with
scan
results
policies
right
now,
I
think,
we've
kind
of
you
know
sidetracked
a
little
bit
right
now
we're
just
trying
to
make
sure
that
what
we've
got
will
work
for
these
das
scan
execution
policies
so
just
running
the
scanner.
A
There
actually
is
a
a
pretty
long
list
of
like
architectural
considerations
that
we're
gonna
have
to
work
through
when
we
get
to
the
scan
results.
Policies
like
customers
want
to
be
notified
only
for
new
vulnerabilities,
for
example
like
there's
a
lot
that
we
don't
support
today,
we'll
cross
that
when
we
get
there,
but
in
the
four
minutes
we
have
left,
I
just
want
to
double
click
on.
You
know,
engineering's
implementation
approach
of
using
a
repository
and
just
double
check
like
is
that
going
to
cause
any
problems
for
dast?
A
Is
you
know
like
with
with
these
changes
to
how
we
interact
with
those
desk
scan
schedule
policies?
Does
that
streamline
the
ux?
Basically,
I'm
asking:
are
there
any
other
outstanding
concerns,
or
are
there
areas
where
we
may
need
our
engineers
to
collaborate
on
a
deeper
level
to
make
sure
everything's
gonna
work.
E
Can
I
just
ask
a
quick
question
here:
stepping
back
a
little
bit,
I
was
pulling
up
the
designs
for
what
we
currently
have.
Are
we
deciding
kind
of
right
now
that
so
right
now,
we're
supposed
to
show
all
scans
that
are
created
in
the
on-demand
flow
are
going
to
show
up
in
policies
and
all
the
scans
created
in
the
policies
we're
going
to
show
up
in
the
on-demand
scans
area?
E
A
E
Okay,
so
in
this
design
that
I
originally
had
where
this
is
the
on-demand
scan
screen,
you
click
recurring
schedule,
and
it
would.
It
would
put
up
this
banner
that
says
you're
creating
a
policy.
E
Okay,
but
in
the
this
is
gonna
have
to
be
updated
a
little
bit,
but
if
these
are
created
via
policies,
it'll
show
something
that
says
hey.
This
is
a
policy
you
just
can't
edit
it
correct.
Okay,.
A
E
E
D
Right,
you
might,
but
it's
it's
fine,
because
the
permissions
are
different
and
as
a
policy
editor,
you
would
want
to
create
something
that
a
developer
couldn't
just
remove
when
they
wanted
to.
B
So
the
one
technical
thing
is,
there
won't
necessarily
be
data
integrity
between
the
policies
and
the
profiles.
So
because
the
policies
are
enamel,
you
could
say
site
profile,
a
and
say
profile
a
may
never
exist,
and
I
think
that
problem
would
show
up
at
run
time
when
that
schedule
goes
to
run.
It's
gonna
say
I
need
profile,
a
profile,
a
won't
exist
and
then
that
job's
going
to
fail.
D
Right,
I
was,
I
was
thinking
about
that
as
well,
and
that's
why
I
was
wondering,
if
maybe
as
an
mvc,
we
start
with
the
pipeline
jobs
for
policies
rather
than
on
demand
scans,
one
because
it's
easier
to
translate
to
the
other
groups
for
sas
or
any
of
the
others
and
they're
going
to
be
doing
pipeline
as
well,
but
also
yeah.
I
there
is
a
larger
chance
since
you're
not
relying
on
the
database
to
pull
in
dynamically.
What
profiles
we
have
yeah
you
could
either
you
could
delete
the
profile.
D
C
B
So
in
so
it's
defined
in
the
gamma
right.
So
let
me
see
here.
B
B
Scan
profile
whatever
and
that
doesn't
exist
when
this
yaml
is
created,
it's
not
necessarily
enforcing
that
those
profiles
exist,
understood
right
or
I
say,
scan
profile
a
this
is
managed
by
a
security,
professional
and
then
a
developer
goes
in
and
changes
scan
profile
a
to
scan
a
non-relevant
website.
So
right.
C
So
it's
similar
it's
it's
similar
to
to
what
I
was
actually
asking
from
from
your
own
question,
but
yeah.
I
think
the
answer
there
is
it'll
just
fail,
like
policy
is
broken,
but
do
we
wanna
do
we
wanna
do
anything
about
regardless
of
this
is
done
in
yaml
or
database?
There's
still,
the
the
the
question
of
a
developer
has
permission
to
change
any
profiles.
C
A
Yeah
that
does
concern
me
a
little
bit.
I
mean
it
would
be
nice
if
we
could
lock
down
some
of
these
profiles
or
maybe
if
a
profile
was
used
in
a
policy,
then
the
developers
could
not
edit
that
or
you
know
if
we
could
put
some
sort
of
restrictions
around
that
I
know
we're
starting
our
permission
model
is,
is
a
bit
rigid,
so
I
don't
know
how
much
we
can
do
there
easily,
but
that
way.
D
D
So
we
we
won't
know
if
you're
in,
if
you're,
using
the
yaml
in
this
other
project,
we
won't
know
that
this
profile
is
being
used
in
a
policy
necessarily
like
we'd
have
to
read
it
into
the
database
and
like
lock
down
that
profile
as
saying
hey,
there
was
a
every
I
I
mean
I
guess
it
would
have
to
run
on
a
schedule
itself
or
something
to
go
through
and
look
at
all
the
yaml
that
have
been
created,
because
if
you
can
create
these
outside
of
the
web,
ui,
then
you're
not
going
to
necessarily
know
that
a
policy
was
created.
C
I
I
don't
know
that
this
is
untreatable
problem,
derek
like
without
looking
at
the
code
and
going
too
much
in
the
detail.
If
somebody
is
about
to
change
a
profile,
there
could
be
a
hook
or
pre-check
that
says
hey.
Is
there
a
linked
management
project
for
policies?
Yes,
is
this
policy
part
of
one
that's
in
in
there?
Yes,
okay,
so
you're
not
allowed
to
do
this
unless
you
you're
a
developer
sure
yeah.
B
B
A
Cool,
well,
I
know
we're
up
on
time.
I
think
we'll
just
try
to
continue
to
iterate
asynchronously
on
that
question
about
permissions
for
desk
profiles.
Otherwise,
I
feel
like
we
made
some
good
progress,
made
some
decisions
today,
thanks
everyone
for
your
time.
If
we
need
to
sync
up
another
synchronous
discussion,
let
me
know
and
we'll
get
it
on.
The
calendar
sounds
good.