►
From YouTube: Scan result policies code walkthrough
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
Hello,
everyone-
this
is
going
to
be
a
quick
walkthrough
through
the
many
through
the
couple
of
the
phases
of
the
code
related
to
the
to
the
scan
result
policy
we're
going
to
split
kind
of
in
three
phases.
A
One
phase
is
from
the
policy
Creation
in
the
EML
in
the
project
repository
that
started
as
an
EML
file
into
the
project
level,
approval
rules,
and
then
we
go
from
Project
level,
proof
of
rules
to
merge,
request,
approval
rules
and
although
I'm
gonna
mention
a
couple
of
times,
the
scan
execution
policy,
that's
not
the
scope
of
this
walkthrough
and
I'm
going
to
be
mainly
focused
on
the
back
end,
because
the
front
end
May.
Basically,
it's
the
shared
code
between
scan
execution
policy
and
scan
result
policy.
A
So
let's
get
it
going
so
here
we
have
and
just
another
remark:
I'm
I'm,
basing
this
presentation
on
the
latest
Mrs
that
are
still
open:
they're,
not
merged
those
Mrs
they're
extending
scan
result
policy
to
a
group
level,
and
so
then
we
are
going
to
show
a
little
bit
of
project
level
and
group
level
as
well.
So
here
we
are
on
the
group
level
and
we,
when
we
go
to
new
policy,
we
have
two
options:
let's
go
to
scan,
result
policy
and
also
just
a
quick
request.
A
We
have
a
remote
and
EML
mode
in
the
remote.
We
can
use
the
cup
of
components
to
kind
of
make
the
generation
of
EML
file
automatically.
So
here,
I'm,
just
gonna
keep
adding
a
couple
things.
So
then
we
we
go
through
the
first
phase.
That's
we,
we
are
going
out
from
room
mode
to
into
the
merge
request,
relate
to
this
project
and
also
another
remark
for
for
people
who
are
not
who
have
haven't
been
looking
to
the
code
too
much.
There
are
basically
two
projects.
A
One
project
is
what
we
call
project
and
the
other
project
is
what
we
call
security
project
and
recently
we
also
allow
having
a
security
project
linked
to
a
group
as
well.
So
those
are
things
to
keep
in
mind
here,
hopefully
I'm
able
to
keep
the
nomenclature
consistent
across
the
presentation.
So
basically,
we
went
through
that
real
load
component
page
and
we
generated
a
merger
request
with
a
EML
change
before
changing
AML
file.
A
That's
exactly
the
same,
how
it
works
for
scan
execution
policy
I'm
just
showing
here
that
up
to
this
point
there
is
nothing
happening
in
the
back
end
related
to
the
s-cam
result.
Policies
after
this
murder
request
is
merged.
Then
there
is
a
couple
of
things
that
I
would
like
to
show
you.
So
let's
go
back
to
the
editor
right
now,
yeah.
So
here
the
goal
of
first
first
point
here:
is
this
sync
scan
policy
worker?
That's
the
thing
that
we're
looking
for
and
these
workers
called
in
two
places.
A
This
is
the
first
place
here.
This
was
the
part
initial.
As
soon
as
we
had
this
scan
policy
code
base,
the
the
the
the
only
case
that
we
were
running
the
synchronization
worker
was
whenever
we
had
up
to
date
configurations-
and
this
is
the
scope
that
we
have
for
this,
so
we
cap
it.
A
But
right
now
we
just
traversed
the
outdated
configurations
and
we
call
async
worker
for
syncscan
policies
worker,
but
there
is
another
place
that
calls
this
worker
as
well,
and
that's
what
I
want
to
show
you
about
that
is
the
post
merger
request
service
that
so
what
happens
here
is
that
it's
still
in
the
conception,
it's
still
using
the
concept
of
configuration,
so
we
are
not
going
for
a
project.
We
are
going
per
configuration
similar
to
the
one
before
here.
It
reverse
the
configurations,
not
the
projects.
A
So
then,
if
I
go
here
to
show,
remember
we
have
this
Mr
here.
If
we
get
merged,
then
we
would
trigger.
There
is
a
existing
hook
for
triggering
both
emerge
jobs
and
that's
the
case
that
we
wanna
as
soon
as
we
have
a
change
in
the
configuration
policy.
We
wanted
to
be
able
to
execute
this
code
here
that
that
was
the
initial
reason
for
having
this,
so
that
in
this
case
here
we
would
avoid
the
10
minute.
A
A
So
that
was
just
one
thing
and
then
let's
look
inside
the
sync
scan
policy
worker
policy,
worker
yeah,
it's
just
a
simple
worker
that
queries
the
the
configuration
based
on
the
configuration,
ID
and
call
this
method
here.
Update
policy
configuration,
that's
just
a
concern,
that's
again
the
main
code
that
we
are
going
to
look
for
now.
A
At
this
moment,
update
policy
configuration
deals
with
scale,
result
policy
and
scan
execution
policies.
Overall,
here,
there's
not
too
many
things
happening
here.
What
we
are
doing
is
that
we
are
deleting
the
existing
resource
for
both
scan
results,
policy
and
scans
efficient
policies,
and
then
we
we
update
the
configuration
so
then
the
next
time
that
the
job
the
create
orchestration
policy
worker
runs.
It
doesn't
include
this
one
anymore
and
then
we
are
generating
the
new
resources.
A
This
part
here
from
9
to
14,
to
line
18,
it's
it's
going
to
it's
going
to
call
process
rule
search
that
we're
going
to
look
up
there.
This
is
sorry
this
we
are
not
going
to
look.
This
is
the
one
related
to
this
kind
of
execution
policies,
and
then
we
we
call
this
syncs
can
result
policy
serves
here
and
just
just
has
the
configuration
as
a
parameter.
That's
the
one!
A
That's
going
to
that's
the
one
that
we
go
to
include
everything
related
to
scan,
result
policies
and,
as
I
mentioned
before,
this
is
based
on
the
the
Mrs.
There
are
still
open.
Things
might
change
a
little
bit
if
they
change
drastically
I
I'm
happy
to
record
Another
feature.
A
So
just
a
quick
recap
on
this
file,
then,
if
the
configuration
is
not
valid,
we
just
get
rid
of
all
the
existing
resources
and
if
it's
valid,
then
we
are
going
to
call
this
process.
Rule
serves
for
the
scan,
execution,
related
resources
and
we
are
going
to
call
these
other
serves
just
for
screen,
result
policy
and
still
we
still
have
to
update
the
the
configuration
time.
So
then
it
doesn't
keep
running
over
and
over
again.
So
then,
let's
look
inside
this
sync.
A
Here
we
are
basically
doing
three
things
which
you
have
the
feature
flag
on
the
on
the
recent
related
to
the
the
this
recent
feature,
but
this
is
going
away
after
we
we
tested
out
and
the
feature
flag
is
removed.
So
basically,
here
we
have-
let's
say
four
things
happening.
First
thing
is
that
we
delete
the
existing
resources.
Force
can
result
policy
similar
to
when
it's
invalid,
as
I
showed
in
the
previous
file.
Then
the
second
step
is
that
we
Traverse
this
can
result
policies
and
we
call
this
process
can
result
policy
serves.
A
We
are
going
to
look
into
into
it
later
on
and
then,
after
that,
we
are
going
to
call
sync
open,
merge,
request
service
and
then
a
sync
merge
request
had
pipeline
service.
So
let's
focus
on
those
three
from
now
on
the
first
for
the
first
one
remember
we
had
the
scan
policy
in
the
email
file
inside
the
security
project
process
can
result.
Policy
service
is
going
to
get
the
information
from
the
policy
EML
file
and
it's
going
to
generate
the
project
level
approval
rules.
So
let's
look
into
it.
A
A
So
here
what
we
are
doing
is
that
we
are
traversing
the
the
scan
finding
rules
and
then
we
are
creating
project
approval
rules.
This
this
approval,
rule
creation
service,
is
an
existing
one.
That's
using
some
other
parts
of
the
code
basis,
so
it's
not
ours,
so
we
are
creating
the
the
project
for
the
approved
project
rules
for
each
of
the
scan
finding
rules.
So
here
we
are
going
from
the
EML
file
from
the
repository
into
the
database
by
creating
approval
project.
A
A
And
it's
it's
grouping
and
then
it's
it's
generating
the
approval
rule
based
on
the
on
the
EML
file.
Let
me
see
here
a
couple
of
important
things,
so
we
can
have
multiple
rules
inside
a
single
policy.
So
for
that
we
we
append
a
different
name,
because
there
is
a
constrained
database
constraint
that
doesn't
allow
same
name
for
the
policies
in
this
scope,
but
that
that's
also
going
to
be
used
in
another
part
of
the
code,
I'm
not
going
to
mix
it
up
for
an
address.
A
But
for
now
we
have
a
name
for
each
of
the
rules
based
on
the
policy
and
then
we
we
also
query
user,
IDs
and
group
IDs.
This
is
these
are
these
like
for
for
the
approval,
approvers
information?
A
Okay,
so
that's
what
we
have
here
and
then
let
me
just
go
back
there
to
see
something
else.
Oh
yeah
I
forgot
to
mention
here
as
we
as
we
are
enhancing
the
support
from
just
project
level
to
group
level.
We
need
to
Traverse
each
of
the
projects
in
the
group
to
kind
of
go
through
these
services
so
before
they
were
just
on
a
group
project
level.
A
Now,
as
they
are
in
a
group
level,
we
need
to
Traverse
each
group,
sorry
each
project
for
the
group
in
order
to
generate
this
resources
because
those
resources
are
on
on
a
project
level.
A
Let
me
go
back
there,
okay,
so
then,
here
we
query,
we
go,
we
get.
We
get
the
email
information
we
parse
it
out,
and
then
we
create
a
brochure
rule
for
each
rule
in
the
email
file.
It's
a
little
bit
almost
like
on
a
one-to-one,
not
exactly
one
to
one
and
then
from
here.
Let's
go
back
to
the
so
that's
the
first
service.
A
It's
just
this
conversion
from
the
ml
file
to
project
level.
Approval
rules,
then
the
second
one,
the
second
one.
Actually
it's
also
an
existing
one
open.
It
here
show
there
before
that.
Let
me
just
go
back
here,
okay,
so
we
call
this
for
each
project
as
well.
It
sits
inside
of
the
loop.
Each
of
the
three
services
are
going
to
be
bound
to
this
scope.
A
So
then,
after
we
create
a
project
rules
for
each
of
the
the
EML
rules,
we
are
going
to
call
this
open
module
request
service
here,
because
we
want
to
get
for
each
open,
merge
request.
We
are
going
to
recreate
the
we
are
going
to
recreate
the
approval
rules
on
the
merger
request
level,
and
so
then,
for
each
open
merger
request.
We
are
going
to
Traverse
as
well
and
we
are
going
to
create
a
merger
requests
rules
based
on
the
project
level
rules.
A
This
was
a
an
existing
Services
as
well
that
call
this
method
a
synchronized
approval
rules
from
Target
project,
so
that
was
free
for
us.
For
for
us,
we
didn't
have
to
implement
that.
A
So
just
remember
that
now
after
running
this,
we
have
the
EML
rules
reflected
on
the
project
level,
not
on
the
project
level,
but
also
on
the
merge
request
level.
A
And
if
we
go
back
here,
we
had
this
third
service
here,
also
on
the
project
level.
Let
me
open
this
search
here.
This
calls
this
another
worker.
Here,
it's
called
sync
reports
to
report
approval
rules,
work
and
gives
the
head
back
line
as
a
parameter.
So
what
happened
is
that
imagine
that
we
had
a
scenario
that
we
had
a
there
was
a
pipeline
running
and
there
was
some.
There
was
no
vulnerabilities
matching
the
rules,
for
example,
as
we
we
deleted
the
approval
rules
on
a
project
and
merge
request
level.
A
A
It
includes
other
code
as
well,
but
if
we
go
here
and
sync
scan
finding
this
code
is
going
to
whenever
the
pipeline
has
run
it's
going
to
check
the
merge
request,
approval
rules
against
the
security
report
and
depends
on
how
depends
on
if
the
the
security
report
violates
any
of
the
rules,
then
these
rules
are
going
to
be
dismissed.
The
way
it
works,
that
we
cannot
hear
it's
here
yeah.
So
we
contrast
the
basic
report.
Sorry,
let's
start
back
a
little
bit,
we
had
the
had
the
pipeline.
A
That's
the
pipeline
that
just
ran
for
this
merge
request,
but
we
have
a
base
pipeline.
The
base
pipeline
is
going
to
be
the
pipeline
that
we
are
targeting
to
so.
The
logic
here
is
that
we
get
the
base
reports
related
to
the
base
pipeline.
We
get
the
report
that
it's
related
to
the
had
the
pipeline,
and
then
we
check
them
against
the
rules,
and
then
we
have
this
method
here,
violate
the
policy
and
violate
policy
against
it.
A
So
this
is
going
to
check,
depends
on
the
scanners,
vulnerability,
States
severity
levels
will
not
repeat
allowed,
but
also
contrasting
the
reports
against
the
base
reports
and
then
for
those.
A
If
the
rules
not
applicable
to
the
report,
let's
say:
if
that
there
was
no
vulnerability,
matching
the
rules
for
a
single
rule,
then
what
we're
going
to
do
is
that
we're
going
to
select
to
set
the
required
approval
to
zero
so
then,
later
on,
when
we
run
the
merge
request
to
widget,
the
rule
is
going
to
be
shown
as
optional,
because
it
didn't
violate
the
rules.
A
The
current
rules
for
this
measure
Quest
and
this
this
search
here
is
it's
it's
the
main
search
that
runs
whenever
we
have
a
a
new
commit
in
the
in
the
branch
or
we
we
create
a
new
merge
request
as
well.
The
pipeline
runs,
and
then
this
service
here
is
going
to
run
as
well,
just
to
mention
here
also
that
this
serves
include
also
coverage
rules
and
license
scanning
rules
that
the
similar
checks
to
to
the
scan
finding.
A
They
look
in
a
different,
different
variables
and
reports,
but
it's
the
same
logic
here.
They
contrast
the
basic
base
pipeline
head
pipeline
against
existing
rules.
A
See
what
more
yeah
there's
something
that
I
would
like
to
mention
as
well?
Is
that
let
me
go
to
the
orchestration
now,
what
is
configuration
yeah
or
credential?
Parts
configuration
is
like
the
general
model
for
the
policies,
but
then
there
is
like
a
two
concerns
here.
One
is
the
execution
policy,
the
other
one
is
the
scan
result
policy
that
I
would
like
to
show
you
now
yeah.
So
with
the
recent
changes,
there
is
something
that
I
would
like
to
mention
here.
A
One
thing
is
that,
as
we
move
from
Project
level
only
to
group
level,
it
was
required
to
have
an
association
between
the
configuration
record
and
approval
rules
that
that's
that's
needed
for
us
to
know
which
one
we
need
to
delete
and
which
one
we
need
to
update,
because
prior
to
that,
we
would
delete,
for
example,
as
soon
as
we
have
a
new
job,
we
would
delete
all
the
previous
ones
for
the
whole
project,
but
now,
as
we
can
have
multiple
configurations
for
the
same
project,
let's
say
if
there
is
an
inheritance
from
a
group,
and
then
you
have
a
couple
of
policies
coming
from
this
group,
but
then
the
project
also
has
is
associated
to
another
project
security
project.
A
Then
now
we
would
have
like
two
records
for
the
same
two
different
records
for
the
same
project.
A
So
then
this
Association
was
required.
So
then,
here
we
have.
We
can
query
them
back
from
the
association
so
from
the
configuration
to
the
rules
and
from
the
rules
to
configuration-
and
this
is
also
reflected
here
as
soon
as
we-
we
don't
have
this
as
soon
as
we
want
to
delete
it.
We
we
we
as
soon
as
the
configuration
is
deleted.
The
organization
project
configuration
is
deleted.
Then
we
want
to
delete
those
rules
as
well.
A
So
there
is
a
little
bit
of
code
here
that
we
need
to
remove
in
the
future.
The
reason
we
cannot
remove
right
now
is
that,
because
we
have
orphans,
there
is
a
background,
configuration
sorry,
there's
a
record
ground
job
running,
that's
a
background
migration,
that's
going
to
backfill
this
new
column
and
then,
as
soon
as
this
is
all
run,
I
think
that
might
be
by
the
time
that
we
have
the
the
feature
flag
removal.
A
So
then
yeah,
let's
just
do
a
quick
recap,
I
think
so
we
have
mainly
this
sinkscan
policy
worker.
That's
the
entry
point
for
the
scan
result.
Rules
scan
result,
policies,
it's
called
in
two
type
two
occasions:
one
is
whenever
we
have
this,
create
orchestration
policy
worker
running
every
10
minutes
or
so,
and
there
is
a
automatic
configuration.
It's
going
to
call
this
worker
for
this.
The
other
conditions
that
when
we
have
a
merger,
merge
request
merged
on
a
configuration
project.
A
We
also
call
it
for
all
the
configurations
related
to
this
configuration
file
and
then
from
there.
This
is
just
including
the
concern.
Let's
go
to
the
concern
once
again.
This
is
not
the
concern.
That's
the
concern.
Concern
is
going
to
consider
execution
policy
that
that's
the
middle
part
here
and
it's
going
to
consider
result
policies
in
this
line,
training
here
and
once
again,
let's
go
to
the
service.
A
A
One
serves
create
rules
from
the
EML
file,
just
project
level
rules
second
serves
is
going
to
create
the
merger
class
rules
based
on
the
Project's
level
rules
and
third
service
is
going
to
call
the
job.
That's
going
to
sync.
The
new
rules,
merger
request
rules
based
on
the
on
the
head
pipeline
for
each
of
the
open
merger
requests,
so
I
think
that's
it
for
now.
If
you
have
any
questions
just
feel
free
to
to
ping
me.
Thank
you
very
much
for
watching
this.