►
From YouTube: Multi-layer hardening in Kubernetes by Kavya Rengaraj
Description
DevSecOps for Kubernetes: With the increasing adoption of Kubernetes, the universal control plane, its complex architecture and default insecure configurations establish a strong foothold for multi-layer hardening. This requires a good understanding of the attack surface and security aspects of Kubernetes components as even a small misconfiguration may lead to a serious attack with huge impact to the organization. In this session, Kavya Rengaraj will discuss on understanding multi-layer hardening, the industry standards to follow and toolsets (KubeScore, KubeScape, Kubebench, KubeLinter, Falco) to the rescue aiming to improve the overall security posture by adopting DevSecOps practices like shift left, right and both. A reference DevSecOps pipeline with a unified view of the toolchains will be discussed.
A
A
My
name
is
kavya
rangaraj
and
I'm
a
software
engineer
working
in
product
solutions
in
the
research
and
development
team,
and
my
work
includes
exploring
and
developing
applications
using
next-gen
technologies
like
machine
learning,
natural
language,
processing,
website,
coops,
blockchain
and
so
on.
The
agenda
for
today's
session
includes
introduction
to
multi-layer
hardening
and
how
to
improve
the
security
portion
of
your
kubernetes
cluster
through
multi-layer
hardening
by
following
a
three-step
approach
and
the
reference
pipeline,
incorporating
all
the
tool
chains
and
guidelines
you
need
to
follow
at
each
and
every
layer
with
a
unified
view.
A
The
key
takeaways
of
this
session,
which
I
believe
are
the
understanding
of
multi-layer
hardening
and
the
key
components
to
secure
at
each
layer
and
a
unified
view
of
your
kubernetes
cluster
in
terms
of
security
and
how
to
adopt
devsecops
to
your
application,
starting
with
what
is
multi-layer
hardware,
so
multi-layer
hardening,
is
a
concept
of
securing
multiple
layers
of
entities
under
consideration.
That
means
an
entity
could
be
an
application,
a
database,
an
infrastructure
or
a
kubernetes
cluster.
A
So
you
consider
an
entity
and
identify
all
the
layers
in
the
entity
and
you
harden
or
you
secure
the
entity.
But
what
is
the
purpose
of
hardening?
The
purpose
of
hardening
is
to
improve
the
overall
security
portion
of
the
entity
and
it
makes
difficult
for
an
attacker
to
get
control
of
your
entity.
So
if
you
are
hardening
a
kubernetes
cluster,
the
purpose
is
to
improve
the
security
of
your
kubernetes
cluster
against
various
attacks.
Hardening
doesn't
confirm
100
security.
It
just
makes
difficult
for
an
attacker
to
get
control
of
the
cluster.
A
So
if
you
take
an
application,
there
are
multiple
layers
like
presentation,
layer,
business
logic
and
database
layer.
Likewise,
if
you
take
a
kubernetes
cluster,
there
are
multiple
layers
in
a
cluster
like
cloud
layer
where
you
run
your
kubernetes
cluster.
It
may
be
an
on-prem
data
center
or
it
may
be
a
cloud
environment
by
any
of
the
cloud
service
provider
and
followed
by
the
cluster
layer.
A
The
attack
surface
is
also
increasing.
The
attack
space
is
also
expanding,
which
is
opening
a
room
for
opening
the
room
for
more
security
incidents
and
new
type
of
security
incidents
to
happen
right,
and
this
strongly
establishes
the
need
for
a
multi-layer
hardening
in
a
kubernetes
cluster.
So
let's
talk
about
how
to
implement
multi-layer
hardening.
What
are
the
process
you
need
to
follow?
What
are
the
steps
you
need
to
follow
in
order
to
implement
multi-layer
hardening
in
a
kubernetes
cluster?
A
The
first
step
includes
the
understanding
the
attack
surface.
Be
it
the
cluster
layer
meet
a
code
layer,
a
container
or
a
cloud
player.
You
need
to
understand
the
attack
surface,
the
components
that
are
present
in
the
surface
and
how
they
interact
with
each
other,
followed
by
you
need
to
comply,
comply
each
and
every
layer
with
industry
standards
and
best
practices.
A
If
you
ask
me
most
of
the
hardening
work
is
in
this
second
layer,
you
comply
you,
you
need
to
comply.
Your
entity
beat
a
kubernetes
cluster
or
an
application
with
the
industry
standards
so
that
you
are
safer
from
various
attacks
and
over
the
period
of
time
you
evolve
it
into
a
deficit
for
kubernetes
approach
into
your
sdnc.
A
So
these
are
the
three
steps
we
can
follow
in
order
to
achieve
multi-layer
hardening.
So
now,
let's
talk
about
the
cluster
layer
in
the
kubernetes
architecture.
Why
is
security
the
biggest
concern
in
the
cluster
layer?
So
here
you
are
seeing
the
kubernetes
architecture
containing
the
control
plane
and
the
worker
nodes.
The
control
plane
has
components
like
api
server,
etcd,
scheduler
and
controller,
whereas
the
work
nodes
runs
your
application
and
workloads
as
parts,
and
they
have
components
like
cubelet
and
q
proxy
right.
A
The
more
general
idea
why
security
is
the
biggest
concern
in
a
kubernetes
cluster
is
because
of
the
complex
architecture.
You
have
various
components
and
you
need
to
maintain
security
of
all
these
components,
so
it
seems
to
be
very
complex
right
and
the
second
idea,
which
makes
the
security
a
biggest
concern
in
kubernetes,
is
supply
chain
dependencies
say
you
have
an
eptcd
component
and
you
are
storing
the
secrets
in
it
is
cd
unencrypted.
A
So
if
in
case
they
are
exposed,
it
may
lead
to
a
serious
attack
right.
So
even
the
small,
less
secure
component
or
a
misconfiguration
can
lead
to
a
serious
attack.
So
this
supply
chain
dependency
is
one
of
the
reasons
why
security
is
the
biggest
concern
when
it
comes
to
kubernetes
and
kubernetes
is
a
promising
target
right
once
an
attacker
is
able
to
get
hold
or
get
control
of
the
kubernetes
cluster
and
get
and
can
control
the
underlying
resources.
A
The
attacker
may
run
a
mining
mechanism
inside
a
inside
of
capacitor
right,
so
they
can
use
this
crypto
jacking
where
they
run
the
mining
mining
algorithms.
As
a
along
with
your
application
workloads,
and
that
may
go
unnoticed
right.
They
may
even
keep
a
similar
name
for
the
mining
workflow,
like
code
dns,
followed
by
some
id.
So
you
don't
even
notice
that
there
is
a
new
or
there
is
an
unauthorized
workload
that
is
running
in
your
cluster
right.
A
So
these
are
the
reasons
why
security
is
the
biggest
concern
when
it
comes
to
a
kubernetes
cluster
at
a
higher
level
to
add
more
granularity,
we
can
see
the
major
causes
of
the
security
incidents
in
our
cluster
are
misconfigurations.
Kubernetes
components
are
by
default.
They
are
misconfigured
by
default.
That
means
they
are
open
and
they
are
insecure.
So
this
these
misconfiguration
needs
to
be
handled
at
the
initial
stage.
So
if
these
misconfigurations
are
not
handled,
they
can
lead
to
a
serious
impact
and
failed
audit.
A
So
the
cluster
needs
to
be
frequently
audited
against
various
standards
and
benchmarks
in
order
to
avoid
supply
chain
attacks.
So
it
doesn't
mean
when
you
develop
an
application.
You
scan
all
the
code,
you
scan
all
the
containers,
the
images
and
you
just
deploy
it
in
the
kubernetes
cluster.
Your
security
doesn't
stop
there.
It
actually
starts
there
for
kubernetes,
so
you
have
to
connect
frequent
audits
in
order
to
make
sure
your
cluster
is
in
a
secure
stage
and
also
runtime
security
incidents.
A
So
if
you
have
containerized
images
for
your
applications
with
vulnerabilities
that
doesn't
follow
any
best
practices
or
lacking
some
some
best
practices,
either
in
the
code
stage
or
in
the
image
stage
on
the
container
stage,
it
may
lead
to
runtime
security
incidents
and
the
last
one
is
the
failing
compliance
most
of
the
kubernetes
clusters,
which
are
attacked,
are
somewhere
failing
the
compliance
with
the
industry
standards.
They
are
not
adhering
to
the
industry,
standards
or
compliance
frameworks.
A
So
let's
just
see
how
we
can
overcome
all
these
questions,
one
by
one,
starting
with
a
misconfiguration,
so
the
national
security
agency
or
the
nsa.
It
has
provided
certain
recommendations
to
harden
the
kubernetes
cluster
against
the
attackers.
That
means
nsa
has
released
certain
guidelines
and
categorized
it
into
into
these
categories,
like
port
security,
network
separation,
upgrading
and
application
security
practices,
audit
logging.
So
under
each
category
say
you
take
the
category
network
separation.
There
will
be
a
guideline
that
you
have
to
make
sure
you
the
access
to
the
control
plane.
A
Components
is
secured
through
a
firewall
and
you
have
to
enable
role
based
access
control,
whereas
if
you
take
the
audit
logging,
you
have
to
enable
the
audit
logging
and
also
the
order
blogging
for
your
application.
You
have
to
have
full
observability
of
your
application
right
and
also
upgrading
and
application.
A
The
next
framework
would
be
the
my
tray
adversarial
tactics
and
techniques
and
common
knowledge
frameworks.
So
it's
a
knowledge
framework
containing
the
tactics
and
techniques
an
attacker
will
use
to
to
attack
your
kubernetes
cluster
to
get
control
of
your
cluster
right.
So
it
lists
all
the
techniques
or
it.
It
elaborates
the
techniques
in
which
an
attacker
can
use
to
get
control.
So
you
can
evaluate
your
cluster
against
these
techniques
and
make
sure
where
your
cluster
can
be
compromised
and
you
can
improve
the
security
portion
by
enforcing
adequate
detections
and
mitigation
mechanisms.
A
Right
and
here
is
the
threat
matrix
of
the
same
framework.
So
you
can
see
it
starts
with
an
initial
access,
how
the
attacker
gains
initial
access
to
a
cluster,
so
it
may
be
using
cloud
credentials.
You
have
exposed
your
cloud
credentials
or
you
haven't
enabled
that
much
authentication
or
authorization
mechanisms,
and
it's
it's
just
exposed
to
the
public,
and
you
have
this
application
vulnerability
which
we
have,
which
may
form
as
a
initial
stage
for
an
attacker
to
get
into
your
cluster.
Once
an
attacker
gains.
A
The
initial
access,
the
the
attacker
can
run
their
own
scripts
right,
their
own
containers
into
your
cluster
and
they
need
to
be
persist.
That
is,
they
need
to
stay
in
the
cluster,
even
though
the
initial
foothold
is
lost,
so
they
can
escalate
on
privileges,
for
example,
if
they
got
access
to
a
container
and
through
this
container,
if
that
container
is
a
privileged
container
and
through
this
container
they
can
get
access
to
the
nodes
or
other
containers
right
and
attacker
also
follows
a
different
evaluation
mechanism.
A
They
can
name
the
port
or
container
similar
to
that
of
the
kubernetes
control,
plane,
components
right
and
it
can
progress
till
they
they
can
explore
on
what
are
the
type
of
workloads
you
run
and
what
resources
you
use,
how
your
cluster
is
capable
of
handling
and
handling
the
workloads,
and
what
are
the
secrets
you
have
stored
inside
the
etcd,
so
all
these
things
may
lead
to
either
data
destruction,
resource
hijacking
or
denial
of
service.
In
all
these
case,
your
cluster
becomes
compromised.
A
Having
said
that,
these
misconfigurations
are
used
to
either
evaluate
or
harden
your
cluster
against
a
serious
attacks
right,
but
how
do
we
implement
them
in
practically?
So
there
is
a
tool.
There
are
various
tools
available
in
the
industry
to
scan
your
cluster
against
the
nsa
framework
nsa
guidelines,
and
this
might
reframe
work
right.
One
such
tool,
which
I
would
recommend
is
you
a
tool
called
cubescape
by
armor
security,
which
actually
scans
your
kubernetes
cluster
against
the
nsa
guidelines
and
the
threat
matrix.
A
Now,
once
you
have
secured
your
cluster
by
following
all
the
guidelines
and
configured
it
in
the
correct
way
right.
The
next
issue,
which
we
saw
a
major
cause
for
a
security
incident,
is
the
failing
compliance
right.
So
you
have
to
follow
to
follow
the
industry
standards.
Your
cluster
have
to
adhere
to
industry
standards
right.
So
the
most
widely
used
and
widely
followed
industry
standard
is
the
cis
benchmark
that
is
from
center
for
internet
security.
A
So
they
list
all
the
secure
configurations
and
the
best
practices
to
secure
your
cluster
right
and
you
have
to
comply
your
cluster
with
this
benchmark
so
that
you
reduce
the
vulnerabilities.
You
reduce
the
attack
space
of
your
cluster
and
there
are
again
so
many
tools
to
do
this,
and
one
such
widely
used
tool
to
check
for
compliance
against
these
benchmarks
in
your
cluster
is
the
cube
bench
tool
here.
You
can
see
the
result
of
a
cuban
stool
scanning,
a
kubernetes
cluster
right
scanning,
every
component
right,
yeah
and
followed
by
deployment.
A
So
you
can
see
we
are
actually
like
backtracking
from
cluster
to
deployment
to
container
all
the
way
through
code
right.
We
are
hardening
it
from
the
cluster
till
the
code
level
right
so
starting
with
the
deployment,
so
deployment
deployments
are
like
files
which
you
use
to
apply
to
kubernetes
cluster
in
order
to
create
a
resource
like
service
or
or
any
other
type
of
resources.
A
So
here
is
a
classical
example
of
a
deployment
file
which
you
in
which
you
use
to
apply
it
to
kubernetes
cluster,
so
that
it
creates
a
service
and
a
container
starts
running
right,
but
is
there
any
issue?
Do
you
see
with
this
file?
No
right?
If
you
take
this
file
and
simply
apply
it
to
your
cluster,
it
will
run
successfully.
It
will
create
a
service
right,
but
the
problem
is
in
the
security
aspects.
If
you
see
it
from
the
security
point
of
view,
it's
lacking
all
these
specifications
say
container
resources.
A
So
the
amount
of
resource
this
particular
container
named
app
container
can
access
is
not
specified.
The
memory
limit
or
the
cpu
limit
is
not
specified
and
there
is
no
network
policy
explicitly
defined,
which
means
it
can
communicate
with
all
other
containers
and
works
right,
and
there
are
no
privilege
checks
whether
it
is
running
as
a
auto
user,
whether
this
container
will
run
as
a
root
user
or
how
it
maintains
access
to
its
file
system,
and
there
is
no
security
context
specified
right.
A
So
now
we
are
going
to
see
about
how
image
of
container
security
is
very
important,
so
we
have
seen
how
to
handle
this
misconfiguration
and
failing
compliance
right
in
the
cluster,
followed
by
the
deployment
files
which,
which
can
also
become
a
serious
cause
of
a
security
incident.
Now
we
will
see
about
how
this
container
security
is
a
a
big
concern
in
the
kubernetes
cluster
layers.
A
So,
as
we
can
see
here,
56
of
developers,
currently,
they
are
not
even
scanning
their
containers
and
98
of
organizations.
They
need
container
security
with
runtime
security,
topping
their
list
right.
So
there
is
definitely
a
need
for
container
security
and
this
container
security,
as
well
as
the
cluster
security.
That
is
the
environment
in
which
your
cluster
is
running,
comes
under
the
runtime
and
security
incidence.
A
The
images
in
which
your
containers
are
referring
to
right
and
also
the
environment
say
your
cluster
is
running
in
an
environment
and
you
have
certain
sensitive
files
and
you
need
to
manage
the
access
of
those
files
right
and
the
network
connections
of
your
environment,
the
inbound
outbound
connection
and
see
if
there
are
any
privileged
containers
if
there
is
any
unexpected
or
unusual
network
connections
or
activity
happening.
So
all
these
things
needs
to
be
monitored
continuously,
so
the
solution
for
this
would
be
definitely
the
continuous
monitoring
right.
A
So
the
continuous
monitoring
of
environment
as
well
as
the
container
needs
to
be
done
and
again
this
there
is
a
tool
called
falco
which
does
this
continuous
monitoring.
It's
a
widely
used
tool
and
it's
an
open
source
tool.
It's
now
an
incoming
a
cnc
of
incubating
project
right
and
it
uses
the
system,
calls
your
kubernetes
audit
blocks
and
your
container
logs
as
input.
So
all
these
will
be
emitted
as
even
and
these
events
will
form
an
input
to
the
falco
rule.
Engine
right
and
falco.
A
Has
this
powerful
rule
engine
which,
with
default
rule,
as
well
as
an
option
to
apply
some
custom
rules?
So
if
any
of
these
events
is
violating
those
rules,
falco
raises
alleges
of
varying
severely
yeah.
As
you
can
see,
you
can
pass
a
system
called
kubernetes
order.
It
locks
even
cloud
activity
logs
to
falco
and
if
you
can
see,
if
there
is
any
rule
that
is
being
violated
by
the
event,
it
raises
the
outlets.
A
So
say
you
have
a
pod
or
a
container
running
in
a
user
space
right
and
you
have
the
logs
and
you
want
to
scan
all
these
clocks.
So
what
you
can
do
is
you
can
deploy
a
falco
engine
to
your
user
space
and
this
falco
engine
will
be
scanning.
All
those
locks
will
be
taking
these
logs
as
input
and
checking
against
the
rules
and
giving
you
the
alerts,
whereas
it
for
system
calls
falcon
uses.
A
So
here
you
are
seeing
the
dashboard
of
site,
which
shows
what
are
the
rules
that
have
been.
You
know
violated
in
the
given
time
range
and
the
events
which
caused
the
rule
violation
like
who,
who
is
the
user
of
that
event
and
which
name
space
that
event
has
occurred.
All
the
information
will
be
locked
here.
You
can
see
it
can
visualize
all
the
information
in
this
using
this
falco
site,
so
this
runtime
security
it
can
be
used
for
for
two
things.
A
Right,
like
one
is
to
scan
the
running
containers
as
well
as
to
scan
the
environment
in
which
your
cluster
is
running.
So
we
have
seen
from
all
the
way
from
cluster
security
how
to
secure
from
miss
configurations
and
then
to
deployment
then
to
containers,
and
now,
let's
go
to
the
image
security.
So
image
security
is
like.
Your
containers
will
obviously
be
referring.
A
Some
images
right
and
the
image
security
itself
is
a
multi-layered
defense,
because
when
you
create
an
image,
you
need
to
know
what's
inside
your
application
or
when
you
are
referencing
other
images
in
your
image.
You
need
to
know
where
it
came
from
the
authenticity
of
the
of
those
base
images
and
who
modified
it
right
and
you
need
to
ensure
the
images
adhere
to
the
industry
standards
like
cis
benchmarks
right
and
you
need
to
scan
your
registry
whenever
you
push
your
images
to
a
registry.
A
An
automatic
scanning
mechanism
needs
to
happen
so
that
you
don't
push
any
vulnerable
image
to
your
registry
and
you
need
to
sign
your
images.
So
this
image
security
itself
is
a
multi-layered
defense.
So
here
are
some
of
the
tools
you
can
use
to
ensure
your
images
are
secure,
like
docker
bench,
which
scans
against
the
cis
benchmarks,
and
there
is
a
tool
called
trivia
and
clear
which
can
scan
the
images
for
various
vulnerabilities
right.
So
now
you
have
come
to
the
code
part
right,
so
this
code
part.
There
are
three
components
we
can
secure.
A
One
is
the
open
source,
libraries
or
third-party
packages.
You
can
you
use
in
your
code,
and
this
may
also
cause
serious
issue.
For
example,
you
already
aware
of
the
recent
block
4g
attack
that
happened
right,
so
it's
an
apache
opportunity.
It's
an
open
source
package
and
a
small
glitch
in
that
open
source
package
led
to
a
serious
issue
right,
so
software
composition,
analysis,
frequency,
software
composition.
A
Analysis
needs
to
be
done
in
order
to
ensure
the
packages
which
you
use
are
secure
and
up
to
date,
and
also
the
application
code
needs
to
be
tested
against
various
best
practices
depend
depending
on
the
languages
like,
so
it's
called
static
application,
security
testing
and
end
points.
You
also
need
to
scan
the
end
points
against
various
attacks
like
denial
of
service
right,
and
this
comes
under
dynamic
application
security
testing.
A
So
when
it
comes
to
as
a
whole
layer
hardening,
it's
not
only
about
the
cluster
layer,
it's
about
the
cluster
layer,
the
cloud
layer,
the
code
layer
as
well
as
the
container
layer,
and
here
you
can
find
some
of
the
tool
set
recommendations
depending
on
the
language
of
your
choice.
Right,
if
it's
a
software
composition,
analysis
and
if
it's
a
python,
you
use
tools
like
safety
and
if
it's
a
code,
security
analysis
for
python,
you
use
tools
like
sonarqube,
bandit
right
and
so
on.
A
So
for
every
programming
language
we
have
different
set
of
tools
that
we
have
different
tools
at
recommendations
right
yeah.
Now,
to
summarize
we
have
seen
to
in
order
to
harden
the
cluster
layer.
We
are
following
the
nsa
hardening
guide,
the
mitre
framework,
the
cis
benchmarks,
the
static
analysis
of
deployment
files
and
runtime
security,
using
of
this
clustering
environment
using
tool
called
falco,
and
these
are
the
tools
which
we
are
used
in
the
above
stages
and
coming
to
container
and
image
security.
We
need
to
scan
the
image
layers,
the
image
register.
A
We
need
to
sign
your
images
and
check
on.
We
need
to
check
if
they
are
header
with
css
benchmarks
and
also
continuous
monitoring
of
running
containers
needs
to
be
done,
and
these
are
some
of
the
tools
which
can
make
sure
all
these
things
are
right
and
coming
to
code
part.
So,
in
the
code
part,
we
have
a
code.
A
We
have
to
check
your
code
against
best
practices
through
a
technique
called
ssd
check,
all
the
packages
open
source
packages
and
libraries
through
sca
and
scan
the
end
points
through
dist,
and
these
are
some
of
the
tools
which
we
use
in
order
to
scan
your
code
now.
So
we
have
this,
we
have
all
these
layers
like
we
have
all
these
layers.
A
We
have
seen
how
to
harden
each
and
every
layer,
but
how
to
apply
it
as
a
whole,
how
to
consolidate
or
incorporate
into
a
single
view
right,
and
that
is
through
dev
seconds
so
before
going
into
the
reference
pipeline.
That
is
incorporating
all
the
tools
which
we
have
seen
now,
let's
just
start
with
some
introduction
to
devsecops
and
then
go
with
the
reference
pipeline.
A
So
the
main
aim
of
devsecops
is
to
give
a
secure,
stlc
right.
The
purpose
of
device
is
to
give
a
secure
software
development
lifecycle
so
that
your
application
is
secured
right
and
it
evolved
from
this
like
earlier.
We
used
to
do
security
test
just
before
we
go
like
just
before
we
deploy
in
production.
We
do
the
security
test
right,
but
that
is
not
insufficient
in
today's
ecosystem.
So
yeah
we
have
to
shift
our
security
practices
to
left.
A
That
is
incorporated
into
the
earlier
stages
of
rstlc
by
following
an
approach
called
shift
left,
so
shift
left
means
you're,
incorporating
security
into
earlier
stages
of
your
stlc,
but
isn't
shift
left
alone.
Nf,
not
really
you.
You
also
need
to
follow
the
shift
right
approach
which
does
continuous
monitoring
of
your
application,
as
well
as
the
environment
as
well
as
the
cluster,
because
only
in
continuous
monitoring
you
can
know
about
the
runtime
security
incidents
which
are
about
to
happen,
and
you
can
you
can
do
a
proactive
remediation.
You
can
identify
patterns
in
your
logs.
A
So
all
these
layers
will
have
various
tools
and
all
these
tools
will
output,
different
security
reports
or
security
results
right,
and
we
need
to
incorporate
it's
very
tedious
to
scan
each
see
each
and
every
report
right
and
then
come
into
a
conclusion
of
the
security
portion
of
your
cluster.
So
in
to
to
avoid
that,
to
make
that
easier,
there
are
various
tools.
There
are
various
vulnerability
management
tools
that
can
incorporate
results
from
various.
You
know
tools
and
provide
you
a
single
view.
A
One
such
tool,
which
I
recommend
is
called
defect,
dojo
it's
an
open
source
tool
which
can
incorporate
various
types
of
security
tools
which
can
incorporate
reports
from
security
tools
and
give
you
a
dashboard
of
what
are
all
the
you
know,
vulnerabilities
that
are
found
by
each
and
every
tool
and
how
is
the
security
portion
of
your
cluster
or
your
container
or
any
such
layer
right?
So
it's
like
you,
you
can
run
the
reference
pipeline,
which
I
have
shown
and
while
running
the
pipeline
parallely,
the
security
results
gets
published
to
this
defect.
A
Dojo
and
you
can
view
all
the
findings
that
are
coming
under
individual
tools
like
if
there
is
a
bench
scan.
What
are
the
compliance
that
has
failed
and
what
are
the
complaints
it
has
passed
and
you
can
also
ensure
risk
acceptance
and
you
can
incorporate
sla
management
and
you
can
also
send
these
alerts
to
various
platforms
like
teams,
jira
and
mail
and
so
on.
Right,
and
so
the
aim
is
to
bring
out
this
reference
pipeline
like
which
follows
this
multi-layer
hardening
and
provide
you
a
unified
view.