►
From YouTube: On-demand DAST scan issue walk-through
Description
The DAST team walks through the issues/epics needed to bring DAST On-demand scans to life.
A
Since
there's
been
some
confusion
and
also
just
to
make
sure
that
everybody
is
on
the
same
page,
so
I'm
gonna
walk
through
what
we
have
and
how
its
laid
out
and
if
there
are
any
questions,
just
go
ahead
and
bring
them
up
a
no
reason
to
wait
until
the
end.
The
the
one
thing
that
I
do
want
to
say
is
that
there
are
a
couple
of
ways
that
that
we've
gone
through
this
and
I
haven't
been
able
to
kind
of.
A
And
then
you
can
see
what
I,
what
I
would
be
okay,
delivering
in
multiple
iterations
and
by
saying
that
they
are,
you
know,
iteration
one
iteration
to
iteration
three
I'm,
not
necessarily
saying
that
these
have
to
be
delivered
in
separate
milestones,
so
I
kind
of
want
to
go
through
a
more
of
like
a
Kanban
type
of
style.
Of
delivering
these
and
saying
that
you
know
this
is,
for
example,
with
the
psych
profile.
This
is
what
I'm,
okay,
delivering
to
a
customer
as
a
as
an
MVC.
A
A
So
right
now,
I
don't
have
specific
milestones
assigned
to
anything
other
than
the
first
iteration,
because
we've
decided
you
know
some
of
these
we're
going
to
deliver
in
13
and
then,
like
the
scanner
profile,
we're
going
to
deliver
in
13
3,
so
the
first
iteration
has
a
milestone
it
assigned
to
it
the
rest
of
them.
That
is
up
for
a
debate
and
I
didn't
want
to
arbitrarily
say
you
know
now:
iteration
3
has
to
be
assigned
to
13
for
even
though
you
all
think
that
you
can
get
it
into
13
3.
B
A
B
C
A
A
A
So
there
are
some
inter
dependencies,
but
in
general
yeah,
like
the
reason,
the
only
reason
that
this
is
even
in
iteration
one
right
now
is
because
you
know
we
push
the
initial
delivery
of
the
on-demand
scan
milestone
and
now
you
know
it's
being
developed
alongside
of
the
the
site
profile.
So,
theoretically,
we
could
get
this
with
just
the
form
being
in
the
scan
page
rather
than
being
able
to
select
the
profile.
So,
theoretically,
the
initial
delivery
is
independent
of
getting
a
psych
profile
done.
B
B
Other
piece
that
I
just
want
to
highlight
is:
if
you
look
at
the
top,
we've
got
these
issues
and
then,
if
you
scroll
down
under
site
profile,
iteration
those
are
epics,
so
you've
been
playing
around
with
whether
these
should
be
issues
or
whether
they
should
be
epics,
and
then
we
should
have
sub
issues,
there's
not
necessarily
a
consensus
just
yet
so
bear
with
us,
and
certainly
I,
think
the
question
is
coming
out
of
this.
What
the
best
way
to
organize
this
work
is
I.
Certainly.
C
B
A
And
that
was
a
question
that
I
I
was
going
to
have
for
all
of
you
once
we
go
through
these.
What
makes
the
most
sense
to
you
and
how
it's
best
laid
out,
and
so
I
was
starting
to
to
change
these
into
two
issues,
or
you
know
to
get
them
into
the
same
paradigm
as
the
rest
of
these,
but
then
I
thought
it
actually
might
be
good
to
go
through
the
two
different
ways
of
looking
at
them
and
get
input
from.
A
A
Okay,
so
I'm
gonna
start
with
the
on
demand
area,
and
these
are
broken
down
to
me.
The
on
demand
area
is
independent
of
the
profiles
in
the
configuration
we
could
have
thought
or
we
could
have
decided
to
use
the
profiles
in
the
CI
CD
pipelines
first
and
just
have
that
form
in
the
on
demand
area.
So
to
me
they
are
totally
separate.
I.
Don't
want
anybody
to
think
that
the
profiles
will
only
ever
be
used
in
the
on-demand
scans.
A
A
Is
basically
what
you've
all
seen
I,
don't
think,
there's
anything
new
in
this.
The
design
does
need
to
be
updated
if
we're
going
to
be
using
the
site
profile
to
show
the
selection
of
the
site
profile.
But
this
was
the
initial
delivery
that
we
had
thought
of
so
I.
Don't
think
we
really
need
to
go
through
this
and,
let's
just
let
that
one
I
know.
B
B
A
A
A
Click
on
new
on-demand
scan
for
the
first
iteration
I
think
that
actually
yeah
she
created
one
specifically
for
the
MVC,
so
this
one
actually
is
for
the
MVC.
So
it
shows
you
what
the
scan
settings
are.
This
is
before
we
have
the
scanner
profile,
so
you
can't
change
these,
but
you
can
create
a
new
psych
profile.
A
So
if
you
don't
have
any
profiles
created,
you
can
click
here,
create
the
name
add
in
the
target
site
and
then
again,
this
is
this
particular
area
for
the
creating
the
profiles
is
kind
of
a
final
version,
because
the
first
version
doesn't
have
the
authentication
in
it,
but
you
can
go
through
and
create
all
the
different
options
that
you
need
create
the
profile
when
you
create
it.
It'll
flip
you
back
over
to
this
page.
You
can
select
the
profile
and
then
see
what
settings
have
been
set
in
that
profile.
A
There's
still
some
cleanup
to
do
here,
for
example
like
the
password
won't
be
in
clear
text
and
then
there's
some
wording,
things
that
need
to
change,
but
in
general
this
is
what
you've
got
when
you
create
a
profile
and
and
select
it
to
use
in
the
on-demand
scan
you
hit
run
you
see.
So
this
is
again
kind
of
a
final
version.
You'll
see
the
list
of
on-demand
scans,
I.
A
A
C
A
B
One
of
the
things
that
you'll
see
in
here
is
this
word:
save
draft
we're
getting
rid
of
that
right
because
you're
just
gonna
save
that
information.
There's
no
there's
no
such
thing
as
a
draft.
You
can
save
a
site
profile
and
have
the
website
not
validated,
and
then
we
just
won't
run
a
scan
if
the
websites
not
valid
and
you're
trying
to
run
an
active
scan.
So
at
run
time
we'll
calculate
whether
that's
validated,
but
we.
A
A
A
A
B
B
So
and
the
idea,
once
we
have
this
site
profile
or
the
scan
profile
at
some
point
in
your
CI
Yama
file,
instead
of
putting
in
all
those
environment
variables,
you
could
just
say,
use
this
site
profile
or
use
this
scan
profile.
So
you'd
have
basically
two
environment
variables
that
would
go
into
your
Yama
file,
the
site
site
profile
on
the
scanner
profile,
and
then
our
scanner
would
actually
get
all
this
data
from
the
database
and
then
bring
that
in
as
opposed
to
having
to
set
all
that
in
your
Yama
file.
A
Yep
so
yeah,
when
you
click
on
security,
compliance
configuration
you'll,
see,
will
break
out
under
desk.
What,
for
now
we'll
have
on
demand
and
you
can
manage
the
profiles
and
then
this
wording
is
going
to
change,
but
it'll
basically
be
the
ccd
pipeline
and
you'll
be
able
to
just
see
what
you
can
write
now
and
see
the
documentation
of
how
to
enable
it.
A
B
A
B
B
C
Okay,
because
it's
running
on
master
they'll
also
display
on
the
security
dashboard
right
yep.
That's
great!
Yes,
and
you
know
that
when
a
new
pipeline
is
triggered
on
master
for
any
particular
reason,
maybe
they're
just
building
and
testing
like
they
normally
are,
which,
let's
assume
it
doesn't
run
dust
in
their
pipeline.
All
the
vulnerabilities
that
were
found
in
the
on-demand
scan
will
come
up
on
the
security
dashboard
and
say
this
vulnerabilities
know
the
present.
C
B
Yep
this
I
I'm
saying
it's
a
known
issue:
I
know
it's
an
issue,
but
it
is
really
important
for
people
to
understand
like
if
you
run,
and
we
have
this
problem
on
I-
think
it
lab
right.
If
you
run
the
the
pipeline
for
documentation
all
of
a
sudden,
it
wipes
out
your
vulnerabilities
because
it
looks
at
the
last
byte
blind.
It
was
documentation,
everything's,
fine
documentation
didn't
find
any
scan
and
it
wipes
it
out.
Yeah.
A
D
Just
on
that
point,
I'd
done
some
work.
That
meant
that
when
we
run
one
of
these
on-demand
scans,
it
doesn't
contribute
to
last
ref
status
so
say,
for
example,
you've
got
an
a
scan
and
you've
run
around
the
minds
kinda
it
doesn't.
It
doesn't
mark
that
risk
that
statuses
past
so
I,
don't
know
if
that
has
any
impact
on
this.
D
B
B
B
D
For
note,
it
does
have
to
run
against
a
branch
they
exist,
but
there
was
some
discussion
on
the
marriage
request
with
the
CI
team
to
say
that
we
might
want
to
kind
of
create
an
ephemeral
branch,
so
it
it
doesn't
necessarily
have
to
be
something
that
doesn't
exist.
We
could
create
it
and
then
just
discard
that,
after
that,
okay.
A
A
Also
is
that,
typically,
if
you're
running
a
desk
scan
like
an
on-demand
desk
and
you're
gonna
be
running
it
against
something
that's
deployed
somewhere,
since
you
can't
really
run
it
against
review
app
at
this
point,
so
it's
typically
gonna
be
either
staging
or
master
that
the
code
that
it's
running
against
you
can
kind
of
assume
that
it's
one
of
those
those
two
and
we
chose
master
for
now,
because
not
everybody
has
a
staging
branch.
I.
A
Theoretically,
but
also
with
DES
whenever
so
one
of
the
issues
with
that
we
run
into
just
as
a
desk
scanner
and
every
desk
scanner
has
this
problem.
It
is
correlating
where
the
issues
are
in
your
code
right.
So
if
and
that's
why
I
wanted
the
user
to
be
able
to
select
which
branch
they
are
running
it
against,
because
if
you're
running
this
against
a
branch
that
you
may
be
deployed
on
whatever
you
know,
cloud
service,
you've
got,
but
it's
a
development
branch.
A
Maybe
this
vulnerability
does
not
exist
in
master
yet
so,
if
we're
running
it
against
master,
maybe
it's
already
been
fixed
in
a
different
bridge.
That's
why
eventually
I
do
want
them
to
be
able
to
select
which
branch
it's
running
on
so
that
they
can
correlate.
This
vulnerability
was
found
in
this
version
of
the
site
or
the
Apple
occasion,
so
that
we
know
that
we
don't
have
to
go
looking
through
all
the
different
branches
just
to
find
where
that
vulnerability
resides
yeah.
C
B
B
I'm,
not
sure
people
are
gonna,
run
scans
and
always
pick
the
right
branch
in
the
future
right
I.
Think.
That's
me,
I
think
that's
my
ideal.
I
stink
of
like
hey
I,
go
run.
This
scan
and
I
know
the
branch
is
deployed.
Let
me
match
up
those
branches,
ideally
that's
what
they
would
do,
but
I
don't
know.
If
that's
what
would
happen,
I
think
for
us
having
the
scan
the
URL
and
the
time
and
date
it
ran,
may
be
enough
for
customers
as
they
say.
Oh
I
ran
this
against
this
URL
on
this
date.
A
And
it
definitely
could
be,
and
that's,
but
that's
also
where
you
know
I
can't
force
anybody
to
use
a
product
correctly,
yeah
yeah,
you
know,
and
even
right
now
with
desks,
you
can
put
in
a
target
URL.
That
has
nothing
to
do
with
your
code
right.
So
it's
a
something:
that's
deployed
somewhere
completely
different.
We
just
assumed
that
they're
scanning
their
own
sites,
so
you
know
we
can't
really
force
users
to
use
it
correctly.
A
The
second
iteration
is
being
able
to
use
the
scan
profile,
which
also
I
should
mention.
We
are
changing
the
name
of
this
from
scan
profile
to
scanner
profile
for
user,
facing
anything
user
facing
because
of
the
fact
that
you
have
your
desk
scan
and
then
we're
also
saying
scan
profile.
Seth
brought
up
that
it
could
be
confusing
when
you're
talking
about
the
two
different
areas,
and
so
it
might
be
better
to
use
scanner
profile,
so
we're
changing
the
name
to
scanner
profile.
I
mean.
B
B
A
A
So
this
is
gonna
have
a
dependency
this
one.
The
second
part
of
it,
is
getting
that
page
that
lists
when
you
click
on
on-demand
scans.
It
only
lists
the
Ottoman
scans,
rather
than
switching
you
over
to
the
pipeline
page
to
see
what's
running,
it'll
just
list
those
scans
on
that
page
and
then
the
final
thing
is
getting
usage
pin,
so
that
we
can
actually
track
how
many
people
are
using
this
and
how
many
scans
on-demand
scans
are
being
run
so
that
we
know
there's
a
difference
between.
C
A
B
B
B
And
my
high
level
understanding
of
it
is
the
usage
ping.
Is
it's
a
job?
Basically,
that
will
run
against
your
get
lab
instance
on
a
periodic
basis,
I
think
on
by
on
a
monthly
basis.
So
it's
just
every
month.
It
goes
through.
Your
database
looks
at
what
you're
using
sends
that
over
to
get
lab
where
my
understanding
of
snow
plow
is
snow.
Plow
is
much
more
event
based.
So,
as
these
activities
occur,
it
sends
that
data
up
to
up
to
get
labs
host
wherever
it's
storing
that
data
right.
B
A
Bright,
the
design
show
whenever
you
select
a
profile
in
the
on
demand
page.
It
shows
you
the
information,
the
configuration
information
about
that
profile,
underneath
it
I
think
that
that
is
something
that
is
not
necessary
in
the
initial
release
and
getting
these
profiles
and
could
come
later.
If,
if
it's
something
that
will
take
more
time
or
I
guess
cause
issues
with
implementing
personally
I
mean
if
you
know,
you
think
that
it
can
be
pulled
in
into
a
previous
iteration,
and
we
can
get
it
at
the
same
time
as
using
the
profile
in
the
on-demand
scan.
A
B
Just
want
to
point
out
the
way
that
those
are
linked
is
we've
got
a
single
issue
for
all
those
sorry,
an
issue
for
each
item.
It's
not
broken
up
into
back
end
or
front
end,
and
it's
there's
no
epic
there
right,
which
I
think
the
next
section
derp
shouldn't
go
through.
We
have
epics
set
up.
Yes,
that.
A
All
right,
so
the
second
one
is
the
site
profile.
So
this
is
just
creating
the
profiles,
so
these
are
all
of
the
different
options
on
that
form.
So
this
is
the
one
that's
broken
down
into
individual
epochs
and
I
haven't
created
one
for
the
site,
kala
Dacian
there's
a
designed
epoch,
but
there
is
no
implementation
right
or
a
design
issue.
There
is
no
implementation
right
now,
so
that
will
be
added
here
in
the
next
day.
In.
B
C
B
A
Reason
that
I
put
it
in
the
scanner
profile
is
because
it
is
a
behavior
of
the
scanner
versus
a
property
of
the
site,
and
so
you
could
have
multiple
sites
and
maybe
where
a
site
is
deployed,
makes
a
difference
as
to
that,
the
time
out
so
I
guess
that
could
be
a
argument
for
being
in
the
psych
profile.
But
the
reason
I
was
putting
it
in
here
is
because
it's
a
behavior
of
the
the
analyzer
of
the
scanner
versus
an
actual
property
of
the
site.
Yeah.
C
B
I
get
the
longer
time
and
then
they'll
be
fine
and,
and
that
could
be
a
problem
and
we'll
see
that
if
people
create
one
site,
one
scanner
profile
another
site,
another
scanner
profile.
If
it's
it,
if
people
create
a
one-to-one
relationship,
then
we
know
where
we're
creating
some
problem.
The
idea,
if
this
is
done
properly,
it
should
be
a
one-to-many
of
one
website
and
then
like
five
different
scans
right,
an
active
she
and
passive
scan,
one
where
you
exclude
all
the
rules
so
on
and
so
forth.
A
Yep
yeah
so,
and
that's
something
eventually
I'd
like
to
get
much
better
analytics
on
how
people
are
using
this
and
be
able
to
track.
You
know
the
number
of
not
any
details
about
like
what
their
URL
is,
because
we
don't
want
to
have
any
privacy
issues,
but,
just
like
you
know,
for
project
how
many
site
profiles,
how
many
scanner
profiles
and
then
kind
of
a
genericized
way
of
figuring
out
what
the
options
are
that
they're
using
just
so
that
we
can't
so
that
we
don't
reveal
any
private
data.
A
This
is
where
we
had
the
discussion
before
about.
You
can
still
do
some
damage
on
a
site.
If
you
are
running
a
passive
scan,
that's
authenticated,
I,
don't
know,
I
go
back
and
forth
on
it.
I
personally
am
not
sure
whether
it's
worth
it
to
do
authenticated
passive
scans
that
you
can
still
do
damage
just.
B
It
sure
write
to
me
and
we
can
discuss
this
kind
of
a
seriously
I,
don't
think
you
should
be
able
to
run
a
passive
skin
on
an
authenticated
website.
To
give
you
an
example
like
if
I
plug
in
my
gitlab
credentials
to
get
lab,
comm
I
authenticate
that
spider
and
all
of
a
sudden
that
spider
is
gonna,
go
click
on
delete
project,
delete,
project,
delete,
project
and
I
was
like
well
I
just
did
what
stuff
could
do
and
I
didn't
really
process
exactly
how
much
damage
it
could
could
do.
So.
B
That's
why
I
think,
if
you're
plugging
in
credentials,
because
once
you're
authenticated
into
a
website
links
which
are
you
know
just
what
the
spider
is
gonna
follow.
It
can
be
very,
very
damaging
if
you
have
links
that
can
be
damaging
on
an
unauthenticated
website
and
Google
and
every
other
spider
is
probably
doing
that
damage
to
your
website
already.
But
people
don't
know
that
damage
is
possible
because
you're
never
off
entik
ating
Google
into
your
website.
So
what.
B
A
It's
so
Paul
originally
created
issues
for
the
front
end
and
back
end
and
put
in
this
information.
So
Neal
pulled
it
up
into
this
epic
level
and
put
both
of
the
front
end
and
back
end
issues
under
this
epic
to
kind
of
contain
them,
but
in
this
one
it's
just
the
URL
and
the
profile
name
and
then
there's
the
implementation
plan
and
then
you've
got
the
front
end
and
back
end
issues
within
this
epic.
A
So
just
these
two
iteration
two
is
adding
just
the
the
authentication
or
I
guess
this
would
be
iteration.
Three
sorry
iteration
2
would
be
the
site.
Validation,
iteration
3
is
the
authentication
and
request
headers.
So
this
also
this
needs
to
be
updated
to
include
being
able
to
switch
between
website
and
API.
Until
we
get
the
request,
headers
you,
it
probably
doesn't
make
too
much
sense
to
use
the
API.
Some
people
may
have
unauthenticated.
The
API
is
out
there
that
they
could
scan
and
so
I
guess.
A
B
C
B
So
I
that's
funny.
I
was
about
to
say
that,
because
one
of
the
questions
is
like
the
way
we
displayed
the
front
end,
we
may
want
to
be
very
deliberate
about
how
those
fields
get
laid
out
right.
So
one
way
is
you
just
get
a
data,
dictionary
and
output,
all
of
them
and
say
fill
in
all
these
fields
and
I
think
we
want
to
be
deliberate
about
the
way
that
those
fields
are
grouped
right.
B
So
log
in
we
have
authentication,
so
we've
got
a
login
field,
a
password
field
and
then
the
the
HTML
input
name
for
both
of
those
those
probably
want
to
get
clustered
together.
The
request
headers
might
want
to
be
independent,
and
then
you
know
we
may
just
want
to
have
very
specific
grouping
of
that
and
not
do
that
automatically
on
the
front
end
or
basically
hard
code.
The
way
that
they
get
out
put
it
on
the
front
end
yeah.
C
Because
there's
different
kinds
of
both
indication
like
in
future,
you
could
have
a
script
yep,
there's
also
a
field
missing
on
this
I
think
submit
form
field
potentially,
but
we
cannot
go
through
these
details
in
a
bit
more
detail,
yeah,
okay,
the
only
other
thing
I
think
about
this
is
that
request.
Headers
and
password
could
have
sensitive
information.
C
A
B
A
So,
typically,
what
the
way
that
I
have
done
it
in
the
past
is
to
add
some
sort
of
salt
to
the
to
the
password
and
then
encrypt
it,
so
that
only
the
our
website
knows
what
that
salt
is.
So
you
can.
You
would
have
the
encrypted
password,
plus
whatever
some
random
thing
that
was
added
to
it,
so
so
that
only
you
know
how
to
unencrypted
that
password.
Yeah.
A
B
A
C
B
A
This
is
kind
of
why
I
wanted
to
show
two
different
ways
of
looking
at
this
because
to
me
this,
even
though
it's
kind
of
what
we
had
talked
about
before
after
looking
at
it
and
seeing
it
implemented.
This
feels
overkill
to
me
to
have
an
epic
for
a
single
form
field.
I
feel
like
it
makes
more
sense
to
have
an
epic
for
the
final
deliverable
of
the
final
feature
and
then
have
each
of
these
in
issues.
A
B
A
So
yeah
we
can
change
the
names
I'm
totally
fine
with
that
all
right.
So
within
this
app,
which
is
the
scanner
profile,
epic
you'll
see
there's
the
designs
and
then
the
implementation
order,
since
this
is
really
like
a
pretty
simple
form
in
general,
there's
no
thing
like
the
site,
validation
that
is
interactive
where
you
go
through
a
different
workflow.
This
is
just
adding
in
form
fields.
A
What
I
did
was
create
each
of
these
as
individual
issues
and
then
added
in
a
design
that
shows
you
just
the
fields
that
would
be
implemented
and
then
I
assigned
this
first
one
to
a
milestone,
but
then,
after
that,
I
assigned
it
to
just
the
next
four
to
seven
releases.
So
if
this
can
be
pulled
into
whatever
milestone,
we
can
review
this
each
each
milestone.
We
can
review
these
issues
and
decide
what
gets
pulled
into
what
milestone,
and
so
we
can
pull
in
more
than
one.
A
A
And
again,
I
would
be
super
happy
if
all
this
could
be
implemented
in
a
single
milestone,
but
I
didn't
want
to
force
the
entire
profile
to
be
delivered
in
one
milestone.
So
you
all
will
tell
me
I
have
to
tell
me
what
can
be
done
in
what
order
or
what
milestones
this
one
is
adding
in
the
rule,
exclusion,
the
CLI
options
and
the
alpha
roll
set
and
the
last
one.
A
C
Yeah
cool,
so
that
debug
one
will
need
to
work
out
what
that
means,
because
we
have
dust
runs
two
processes
that
runs
the
dust
python
and
the
Zap
server
and
we'll
need
to.
At
the
moment.
We
have
two
different
two
bug
options.
You
can
debug
either:
okay,
maybe
to
Parkman's
debug
the
entire
thing.
Where
was
debug?
That's
yep.
B
C
Configuration
options
does
currently
have
is
turn
the
dust
pipe
and
debug
on
or
off
turnes
app
server,
debugger
on
and
off
and
complete
configure
the
deaths.
Sorry
there's
that
Python,
so
you
might
want
to
see
all
the
HTTP
messages
as
an
example,
but
we
can
go
into
this
detail
later.
I'm,
just
throwing
out
of
commission
sure.
A
B
B
B
A
B
A
Yeah,
so
some
of
this
is
fluid,
but
we'll
figure
that
out
this
is
exert
akin
directly
from
the
environment
variables
and
just
trying
to
figure
out
which
one's
going,
which
one's
apply
to
the
site
as
a
property
and
which
one's
apply
to
the
scanner
is
a
setting
all
right
and
then
the
last
one
is
the
library
which
an
epoch.
For
here
this
is
broken
down
into
three
iterations.
A
The
first
iteration
is
just
creating,
and
this
one
we
can
update
the
titles
as
well
to
reference
what
they
do.
It's
being
able
to
see
the
sites,
the
site
profiles,
create
the
site
profiles
and
delete
site
profiles.
So
in
the
first
iteration
the
since
is
planned
for
13.
The
scan
profiles
will
not
be
available
yet.
A
C
D
A
A
So
that's
the
first
iteration
of
that.
The
second
iteration
is
being
able
to
do
the
same
thing
with
the
scanner
profiles
and
as
well
edit.
The
profiles
really
I
feel
like
this,
and
this
is
kind
of
what
what
I
talked
about
with
Neil
originally
was
to
get
the
Edit
ability
in
the
next
iteration
after
the
the
profile
library
is
delivered.
A
I
could
pull
this
out
into
its
own,
basically
its
own
issues,
because
it's
separate
piece
of
functionality,
then,
then,
what
we
originally,
what
we
would
have
for
the
scanner
profiles
and
being
able
to
view
create
and
delete.
So
if
you
all
think
that
it
should
be
in
its
own
issue,
I
can
create
an
issue
for
that.
I.