►
From YouTube: Deterministic vs Probabilistic Security - Steve Giguere (StackRox) OpenShift Commons Briefing
Description
Deterministic vs Probabilistic Security: Leveraging Everything as Code
Guest Speaker: Steve Giguere (StackRox)
Recorded: 2021-02-19
#TransformationFriday #DevSecOps
OpenShift Commons Briefing hosted by Diane Mueller (Red Hat)
https://commons.openshift.org/events.html
Link to Slides:
https://github.com/openshift-cs/commons.openshift.org/blob/master/briefings/slides/LayerCake2-SG.pdf
Abstract:
We’re all bakers. For some, it’s a celebration cake in the final of the Great British Bake Off and for others and a layering of complex technology flavours and ingredients. We all have recipes. Be it a graham cracker or a public cloud biscuit base, we build in layers. As we move to cloud native, we find ourselves layering in declarative models with the idealism of “”everything as code””. Through this, we can create repeatable results through a breadth of languages which represent our desired state and through cloud native technologies like Kubernetes we can enforce that state. Only 5 years ago code was for applications. Code that relied on our imperative or human controlled provisioning of hosting technologies. Security focused on honing detection and response skills to determine what wrong looked like. This approach to security was probabilistic where cloud native can help us be more deterministic to enforce what is right.
Shifting left isn’t just for developers anymore.
In this OpenShift Commons Briefing, StackRox’s Steve Giguere discusses Deterministic vs Probabilistic Security and and shares his experiences from the field.
A
We
have
a
kind
of
a
leaning
this
past
couple
of
weeks
towards
security
and
devops
and
devsecops,
and
we're
really
thrilled
to
have
steve
jager
from
stackrocks
with
us
to
give
us
his
layer,
cake
approach
to
security
and
I'm
going
to
let
him
introduce
himself
and
talk
for
as
long
as
he
likes
and
then
we'll
have
live
q
a
at
the
end
so
welcome
and
welcome
steve.
I'm
really
pleased
to
have
you
here
this
morning.
B
Do
all
right,
good
yeah,
all
right
thanks
for
watching
this
is
layer
cake.
My
name
is
steve
jager.
I
am
a
cloud
native
security
advocate
with
stack
rocks,
and
what
I
want
to
talk
about
today
is
how
we
can
move
security
to
be
more
deterministic
over
probabilistic
now,
first
thing
I'll
do
is
introduce
myself
because
you
may
not
know
who
I
am.
B
My
actual
title
is
director
of
solution,
architecture
and
community
building
for
mia,
but
as
I
am
kind
of
the
only
technical
guy
here,
I
do
a
lot.
I
wear
a
lot
of
hats
on
the
screen.
You
can
see
my
you
can
follow
me
on
twitter.
That
is
a
I'd
like
to
live
dangerously.
That
is
a
qr
of
my
linkedin.
So
if
you
want
to
connect,
let's
be
friends,
I
have
a
podcast
called
the
continuous
security
podcast.
You
can
check
it
out
on
any
good
podcast
source.
B
I
also
run
a
meetup,
along
with
some
friends
from
stackrocks
called
computer
security
check
it
out-
and
I
also
am
a
huge
beer
fan.
You'll
see
that
it'll
be
part
of
my
presentation,
be
friends
untapped.
Why
not?
I
also
have
a
youtube
channel
where
I
talk
about
beer
if
you're
really
geeky.
That's
that's
extreme,
though
all
right,
so
the
first
thing
I'd
like
to
really
get
into
is
kubernetes
transformative.
B
It
wouldn't
be
a
presentation
about
involving
kubernetes
at
all.
Unless
I
had
some
kind
of
nautical
themed
photo.
I
like
to
have
a
picture
of
a
containers.
Shipping
containers
that
joke
word-
clouds
are
great.
People,
have
word
clouds
and
then
I'll
talk
about
how
it's
changing
the
world
amazing,
but
which
I
actually
am
going
to
do.
B
I
am
going
to
talk
about
how
it's
changing
security,
but
I'm
going
to
have
to
put
that
into
the
context
of
the
people
who
have
to
deal
with
security
and
in
our
case,
as
kubernetes
and
openshift
enthusiasts,
the
people
handling
security
is
often
the
infosec
team.
There
is
kind
of
a
separation
in
security
of
apps
like
an
infosec.
B
Are
the
idea
of
tooling
being
noisy
so
they're
looking
for
a
needle
in
a
haystack
versus
not
noisy,
in
which
case
it
feels
dangerous
like
what
are
we
missing,
primitive
versus
expensive,
and
I
think
I
might
change
primitive,
but
it's
more
like
when
you're
trying
to
cobble
something
together
on
a
budget
versus
buying
some
epic
security
platform
and
then
wondering,
if
you're
getting
value
out
of
it
right.
This
is
a
common
struggle.
B
The
historical
security
in
the
space
has
been
a
little
bit
reactive
as
opposed
to
proactive,
and
that's
not
intentional
developers
have
control
over
the
app.
They
didn't
used
to
really
factor
security
again
we're
trying
we're
trying
to
shift
left.
So
the
result
was
generally
here's
an
application,
it's
running
on
a
vm
or
a
data
center.
How
do
I
watch
it
really
closely
and
make
sure
that
nothing
bad
happens,
so
the
struggle
generally
isn't
that
they
don't
want
to
be
proactive?
B
It
ends
up
being
probabilistic
versus
deterministic
or
probability
versus
certainty,
and
it
comes
down
to
changing
the
equation,
so
risk
equals
likelihood
times
impact
if
we
can
change
either
likelihood
or
impact
or
ideally,
both
then
we're
off
to
a
fantastic
start,
and
we
can
do
that
with
everything
as
code.
This
is
the
nirvana.
Have
we
achieved
it?
Well,
kinda
I'll
get
a
high
five
for
that.
B
There
are
a
lot
of
standards
at
the
moment
for
creating
everything
as
code.
Different
platforms
have
different
ideals
and
different
and
different
people
have
different
levels
of
expertise.
I
mean
you've
got
your
terraform,
your
cloud
formation
yaml,
everyone
loves
the
animal
and
then
you've
got
interesting
changes
like
cdkates
and
paloomie
and,
of
course,
helm
and
ansible,
and
all
the
other
ones
that
people
know
and
love
and
I'm
sure
there
will
be
more
in
years
to
come.
B
Why
do
we
need
everything
as
code,
though,
because
of
humans?
Humans
are
we're
idiots,
we're
our
biggest
own
problem?
We
make
mistakes,
we
produce
non-repeatable
results,
no
change
control,
we
love
tribal
knowledge
and
many
other
reasons.
Humans
don't
tend
to
make
good
decisions,
so
we
need
to
change
the
battlefield
and
I
feel
I'm.
I
think
I
stole
that
from
the
art
of
war,
but
I'm
not
sure
what
we
want
to
do
is
reduce
likelihood
of
risk.
We
can
do
that
by
employing
checks
earlier
and
often
you
may
have
heard
that
before.
B
B
Can
we
reduce
impact?
Absolutely
what's
great
about
declarative
environments,
and
particularly
kubernetes
is
that
we
can
leverage
chaos,
engineering,
we
don't
have
to
cuddle
all
of
our
pods
and
our
nodes
and
our
clusters.
We
can
embrace
that
cattle
versus
pets,
analogy
and
I'll
apologize
to
the
vegans,
because
that's
kind
of
a
brutal
analogy.
We
need
a
new
one.
Add
comments
if
you've
got
a
better
one,
but
the
overall
idea
is
that
we
want
to
be
able
to
utilize
the
context
of
that
deterministic
and
declarative
definition
when
we're
looking
at
risk-
and
we
can
do
that.
B
The
importance
of
context
now
what's
fun
is
that
I
can
see
in
the
guest
list
for
this
that
there's
byron
on
byron
is
watching
this.
This
is
a
true
story.
I'm
stitching
him
up
by
saying
that
we
were
in
a
morning
meeting
one
time
and
he
was
telling
me
that
he
had
a
beer
last
night
and
he
feels
terrible-
and
I
thought
oh
okay.
Well,
that
doesn't
seem
so
bad.
What
beer
was
it.
It
was
this
imperial
stout
and
this
one
on
the
screen
is
from
brew
by
numbers.
B
It's
me,
it's
amazing
tell
me
more
about
it.
He
went
all
right.
Well,
you
know
it's
a
delicious
stout.
It's
got
american
oak
barrel
aged.
I
mean
this
all
sounds
amazing
right.
I
was
10,
maybe
and
like
okay
right,
that's,
that's
a
factor.
That's
important!
It
kind
of
made
me
feel
like
that's
like
the
vulnerability.
That's
the
cvss
10
in
the
container
right,
but
doesn't
matter
it
still
didn't
make
sense
why
it
was
a
problem
any
so.
We
explained
the
situation.
B
Let's
take
a
look
at
his
deployment
animal.
So
it's
the
bamboo
bpa,
it's
the
imperial
stout
and
the
dinner
he
had
that
night
was
a
salad
he's
trying
to
ease
off
on
the
christmas
indulgence.
You
know
what
I'm
saying
there
were
three
replicas.
He
left
that
detail
out.
He
was
watching
this
super
surreal.
Tv
show
called
american
gods,
which
is
only
45
minutes,
which
means
he
what
he
had
basically
a
bottle
of
wine
in
45
minutes
like
that's,
not
good,
and
it
was
a
break
from
dry
january.
B
Everything
about
this
is
a
disaster
that
is
a
that's
an
actual
risk
and
that's
kind
of
what
I
mean
when
I'm
talking
about
vulnerabilities
versus
risk
vulnerabilities
are
indicators
only
all
right.
Let's
get
started
talking
about
the
layer
kick,
but
first
another
prerequisite
of
these
sort
of
infrastructures.
Code
talks
is,
I
have
to
say,
get
ops
three
times
get.
Ops
is
great,
and
I
really
like
that.
Weaveworks
has
acknowledged
vitor
silva,
who
normally
tweets
in
portuguese.
B
His
his
get
ops
in
one
sly,
which
is
essentially
get
as
the
single
source
of
truth,
get
as
the
single
place
where
change
happens,
which
is
yes,
it's
great
and
we
are
gung-ho
on
it.
It's
a
little
odd,
though,
like
being
somebody
who
wrote
code
since
the
90s,
I've
been
writing
code,
putting
it
in
source
code
control,
creating
pull
requests
like
this
is
not
new.
B
It's
just
funny
that
now
that
it's
using
used
for
infrastructures
code
and
for
just
everything
is
code,
it's
like
a
wild
new
cool
thing,
but
it's
a
good
necessary
thing
all
right
now
we're
in
the
layers
the
big
moment.
Look
at
that
cake.
Isn't
that
good?
I
made
that
cake.
It's
not
a
picture.
I
downloaded
off
the
internet,
that's
it!
I
made
it
all
right,
let's,
let's
talk
about
the
layers
and
then
we'll
go
through
each
one
and
talk
about
what
we
can
do
at
each
phase.
B
B
The
pipeline
is
number
one,
so
the
pipeline
itself
that
ubiquitous
part
of
our
entire
supply
chain,
the
application,
the
application's
friends
and
dependencies,
the
image
the
image
goes
into
a
deployment.
The
deployment
goes
into
our
runtime.
Those
are
our
phases.
So
let's
talk
about
what
we
can
do
layer
0.
We
can
secure
the
base
infrastructures
code.
There
are
tools
for
making
that
happen.
There's
and
I'm
being
wide
open
about
this,
like
open
source
tools,
you
can
get
for
free
and
some
are
built
in
like
check
off
kicks
tara
scan
these
all
work.
B
There
are
free
tools
for
maintaining
the
for
maintaining
state.
Opencspm
is
one
they
all
claw.
The
gartner's
definition
is
cspm.
If
you
don't,
if
you're
watching,
you
don't
know
that
cloud
security,
posture
management
and
there
are
other
ones
out
there
now.
Why
do
we
need
this
again?
Humans
are
creating
the
code,
so
verification
prior
should
be
standard.
We're
used
to
doing
this
with
code
we
write,
and
yet
we
feel
like
we
have
to
say
it
for
code,
that
is
infrastructure's
code,
but
that's
probably
more
important
than
the
actual
code
all
right.
B
So
there
are
tools
we
can
use
and
there's
just
a
quick
run
through
on
how
easy
it
is.
So
what
I've
done
is
I've
downloaded
this
probably
super
dodgy
terraform
for
aws,
okay
and
I've
just
picked
one
at
random
and
it
I
like
that
this
one
actually
outputs
a
variety
of
formats
by
the
way
human
json,
all
the
machine
consumables.
It's
all
really
good
and
it's
as
easy
as
running
terra
scan
in
this
case
and
checkout's
the
same
and
whatever
the
terraform
is
in
the
directory.
B
B
I
can
go,
find
the
low
hanging
fruit
that
I
know
I
need
to
fix.
Ssh
port,
open,
yeah,
okay.
That
seems
bad.
I
am
wondering
actually
now.
Why
is
that
open
in
a
wordpress
aws
like
it?
This
is
a
great
example
of
don't
just
download
stuff
and
use
it.
Okay,
scan
it
with
stuff
and
take
a
look
I
can
go
down.
B
I
can
just
delete
that
because
I
don't
understand
why
that's
there
in
the
first
place-
and
I
just
run
a
quick
scan
to
make
sure
that
my
highs
go
from
four
to
three
and
we're
good
right.
So
that's
the
idea
is
it.
I
could
just
take
a
few
more
seconds
and
I
can
go
through
the
rest
of
this
and
I'm
done
so.
B
B
The
pros
of
doing
it,
of
course,
is
code
controlled
and
observed
great,
so
infrastructure's
code
is
chaos,
engineering
friendly,
because
if
we
just
destroy
our
cluster
or
our
node
or
our
pods,
we
should
be
able
to
put
it
back
exactly
in
a
known
state
and
it
reduces
the
dependence
on
tribal
knowledge.
This
is
why
infrastructures
code
is
good,
and
this
is
why
we
should
check
it.
B
It
can
be
an
amalgamation
of
stack,
overflow
cut
and
paste
and
github
clones,
and
just
like
the
one
I
just
went
and
got
I
just
googled
wordpress
terraform,
and
that
was
the
first
link
right,
which
is
kind
of
what
people
do
there
and
there
are
some
bad
defaults
in
there.
Another
thing
that
we're
starting
to
see
is
that,
if
say,
a
template
that,
like
that
became
standard,
people
will
do
what
they're
already
doing
with
images.
They
will
template
squat.
B
Another
thing,
which
is
more
operational.
This
kind
of
code
can
age
over
time
because
it's
not
getting
as
many
updates
and
feature
driven
changes
as
actual
application
code.
So
you
have
to
make
sure
you
keep
on
top
of
it
and
you
don't
have
an
application
of
some
iec
that
is
secure
one
day
and
insecure
the
next
due
to
changes
in
your
cloud
provider
so
worth
knowing
all
that
layer.
One
supply
securing
the
pipeline.
What
I
mean
by
that
is
software
supply,
chain,
integrity
and
providence.
This
is
your
internal
supply
chain.
B
B
Well,
I
don't
know
if
you
know
how
that
breach
happened,
but
that
is
a
supply
chain
compromise
where
malware
was
installing
malware,
because
it
was
able
to
inject
during
the
build
by
watching
a
build
its
own
pre-built
package
that
had
malicious
intent
it
it
was
possible
for
them
to
not
just
hack
solar
winds
that
would
be
small.
It
was
it
was.
They
were
able
to
manipulate
their
signed
result
and
therefore
deploy
malicious
malware
to
a
much
larger
audience.
B
Now.
What
could
they
have
done
to
prevent
that?
Well,
something
but
probably
not
enough.
It's
not
a.
There
are
tools
out
there
like
in
toto
record
graphics.
These
things
are
looking
at
your
supply
chain
and
in
total's
easy
to
demo.
It's
a
cncf
project,
it's
really
cool
and
it
can
prevent
a
man
in
the
middle
attacks
like
that,
but
it's
hard
to
deploy
at
scale.
B
So
I'm
giving
you
the
honest
cons
about
it
right
in
order
for
your
supply
chain
to
be
managed
for
each
component,
each
developer,
everyone
has
to
buy
into
a
deployment
like
that.
You
can't
just
pick
and
choose
and
that
could
be
problematic
to
do.
But
there
are
options
to
make
it
happen.
It
would
be
cool
to
see
people
work
more
on
things
in
this
space.
B
Securing
the
code
familiar
territory
right.
These
are
these.
These
kind
of
scanners
are
called
sas
static,
application
security,
testing
tools
in
the
code
pipeline,
I've
singled
out,
you
see,
I've
got
ide
sas
there,
I've
singled
that
out
intentionally,
because
I
just
don't
think
there's
enough
attention
to
that.
B
There
are
many
many
things
you
can
put
into
your
ci
pipeline,
which
can
scan
all
the
code.
You
wrote
in
a
variety
of
languages,
great,
but
developers
kind
of
hate
those
tools
because
they
slow
things
down
or
they're
poorly
implemented.
What
they
would
really
like
is
something
that
integrates
directly
into
their
their
environment,
their
ide
or
their
vs
code,
or
whatever
they're
using
and
just
tells
them
as
they
go
in
an
unintrusive
way.
That's
the
ideal
and
there's
just
not
enough
good
good
answers
to
that.
B
B
It
doesn't
take
long
to
get
to
one
thousand
lines,
so
it's
worth
doing
what
are
the
pros?
Some
really
obvious
ones.
Many
open
source
commercial
offerings
are
available
and
I've
got
one
there.
I'll
show
you
in
a
minute
now
that
I
really
like
cost
benefits
finding
anything
early
developers.
Finding
problems
that
there's
numerous
reports
on
like
100x
cost
differences
between
finding
something
in
development
versus
finding
it
in
testing
versus
pen
testing
versus
support
case
versus
a
breach
the
last
one
being
probably
the
rarest
support
case
is
probably
being
the
most
common
super
expensive.
B
And
lastly,
people
don't
talk
about
this
enough
static
analysis.
Checking
is
one
of
the
few
ways
you
can
automatically
traverse
all
your
paths.
Testing.
Rarely
does
this
pen
testing
doesn't
do
it.
It's
a
really
interesting
thing,
and
even
if
you
run
a
static
analysis,
slow
out
of
band,
occasionally
it
has
high
value.
Because
of
that,
what
are
the
cons,
slow
and
potentially
disruptive
has
a
bad
rap.
I
didn't
write
that
down,
but
it
kind
of
does
there
can
be
a
lot
of
false
positives.
B
Implementation
is
difficult,
particularly
in
a
modern
microservice
organization,
where
the
tech
stack
can
be
in
multiple
hands
and
can
be
different
and
security
choices
are
are
in
the
developers,
hands
and
you
can't
impose
something
like
this.
So
finding
a
one-size-fits-all
solution
for
static
analysis
is
very
hard.
B
B
B
A
B
The
master
to
see
what
it
would
find,
which
is
great
and
again
by
the
way
I
did
this.
This
is
all
yesterday
like
where
I
went
and
did
this
and
I
can
see
obvious
sql
injection.
I,
like
that
integrated
directly
with
my
github,
showing
me
really
bad
things,
and
it's
got
some
integrations
out
of
the
box.
If
you
need
them,
I
can
look
at
my
scan
history
and
see
whether
it's
recent
I
can
see
what
I'm
scanning
when
I'm
not
scanning
it's
just
like.
B
I
was
blown
away
that
this
was
here
and
I
could
just
do
it.
I
was
even
more
blown
away
at
the
breadth
of
languages
that
it
covers.
It
was
cool.
I
tried
a
lot
of
them.
The
kubernetes
in
the
terraform
one
was
not
that
good,
so
other
tools
are
available.
We
just
looked
at
one
and
we're
gonna
look
up
another
one
in
a
moment.
B
So
it's
really
pretty
impressive.
All
right
layer,
three
we're
gonna,
get
there
securing
the
open
source
supply
chain.
This
is
what
I
referred
to
earlier
as
the
application's
friends,
the
dependencies
or
the
family.
This
is
referred
to
mostly
in
the
industry
as
sca
or
software
composition,
analysis
or
just
dependency.
Checkers
people
call
it
free
and
open
source
solutions
are
available,
which
is
awesome.
A
lot
of
these
kind
of
things
are
becoming
embedded
into
certain
areas.
Why
do
we
need
this?
B
I
could
so
there
are
some
commercial
solutions
on
there
and
they
make
great
reports.
I
I
like
any
company
that
makes
awesome
reports
is
great
and
they
all
kind
of
agree
that
about
eighty
percent
of
a
modern
software
application
is
open.
Source
open
source
vulnerabilities
are
known
to
the
bad
guys
even
the
script,
kitties
that
just
like
to
go
to
showdown
and
exploit
db
and
just
try
and
write
stuff
and
mess
with
you
they're
out
there,
and
really
we
have
to
deal
with
them.
B
The
pros
we're
finding
the
known
vulnerabilities,
that's
more
important
than
the
unknown
ones.
Everyone
knows
about
them,
it's
the
low
hanging
fruit
and
something
we
really
should
do
the
cons,
and
there
always
are
being
completely
open
about
this.
It
can
be
difficult
to
prioritize
the
results
of
these
things.
B
B
B
B
You
can
also
also
tools
out
there
for
checking
docker
file,
best
practices
and
there's
open
source
like
when
I
say,
docker
file,
best
practices,
there's
a
lot
there's
a
lot
of
articles
out
there
I
just
chose
a
couple
like
using
an
ad:
instead
of
a
copy
is
bad
leaving
the
default
user
in
which
is
root.
Like
january,
I
think
2019
was
the
run
c
vulnerability
that
if
the
image
is
left
running
as
root,
you
could
swap
run
c
out
and
get
remote
code
executed
on
the
host
as
root
really
bad.
B
Why
do
we
need
this?
Well,
as
I
just
indicated,
defaults
can
be
dangerous.
Images
are
introducing
user
space,
open
source
operating
system
dependencies
that
have
critical
vulnerabilities.
It's
a
for
me.
It's
a
must
do
well
the
pros
once
again
we're
finding
vulnerabilities
and
we
can
do
it
anywhere
and
it's
really
quick.
B
It
teaches
you
developers
best
practice
when
done
right,
so
they
get
better
and
you
get
less
noise.
It
does
some
of
that
sca.
I
think
the
kind
of
like
the
bare
minimum
critical
sca
a
lot
of
good
tools,
though
certainly
the
commercial
ones
can
do
that.
Just
be
perfectly
honest.
Does
that
it's
good
plenty
of
open
source
free
tools
are
available
and
that's
great
for
getting
started.
B
Cons
image
scanning
can
become
a
bit
of
security
theater
because
because
it
seems
to
do
so
much
some
organizations
start
thinking
all
right.
Let's
scan
our
images
and
they
scan
a
big
bloated
registry
and
it
becomes
overwhelming
because
they
don't
have
context,
so
nothing
happens
so
worth
knowing
that
when
you
start
context
again
is
important
that
can
it
can
confuse
vulnerability
management
if
you're
using
an
sca
tool
and
because
you
get
overlap.
B
Let's
take
a
quick
look
at
how
easy
this
can
be.
I
I'm
most
familiar,
I'm
not
not
being
biased,
but
I'm
just
very
familiar
with
trivi.
I
like
it
because
it
works
on
the
desktop
it
scans
images
you
can
see
on
a
file
system.
You
can
scan
a
github
repo.
You
can
put
in
quiet
mode,
so
you
can
bet
it
into
your
ci.
B
It
kind
of
has
all
the
bells
and
whistles
that
I
need
for
doing
the
basics,
but
I
am
going
to
show
caveat
in
a
moment,
so
let's
scan
an
alpine
313,
which
I
think
is
the
latest
and
it
maintains
its
own
database.
So
sometimes
it
takes
some
time
and
I
thought
that
was
going
to
have
nothing
because
normally
alpine's
the
safe
bet,
but
those
are
pretty
new
vulnerabilities,
so
there
we
go
two
modules
with
the
same
ones
fixed
version
available.
So
I
could
take
action
on
that.
B
I
would
imagine
there'll
be
a
new
version
like
seconds,
but
if
I
try
and
scan
something
a
little
larger,
this
is
where
we
as
a
developer.
We
get
into
trouble.
This
is
kind
of
why
you
know
the
ocean.
The
notion
of
depths
like
opposite
shift
left
can
be
troubling
for
a
developer,
because
if
they
do
what
you
want
and
they
use
something
like
trivia
there's
a.
I
hate
that
tar
vulnerability.
B
So
if
we
take
a
look
at
the
top
of
this
to
see
what
we
might
have
to
contend
with
and
we'll
get
like
the
total
of
what
all
of
them
are,
we
can
see
that
okay,
a
bunch
of
vulnerabilities,
one
critical.
So
maybe
I
should
look
at
that
right
and
what
I
like
about
this
is
that
it's
using
w-
and
I
can
see
I
like-
that
it
shows
me
the
the
base.
B
So
if
I
clear
the
screen-
and
we
look
at
the
latest-
but
I'm
gonna
filter
on
that-
just
the
critical
vulnerability
and
I'll
get
rid
of
that,
because
I
it's
not
going
to
blast
through
the
whole
screen
and
it's
warning
me:
you
should
never
use
the
latest
tag.
Bad
practice
do,
as
I
say,
none
as
I
do
cv
2019.
Unless,
so
what
would
I
do
with
that?
As
a
developer?
B
B
But
you
see
what
I
mean.
This
is
one
of
those
sort
of
eternal
conundrums
when
we
start
pushing
security
in
the
hands
of
developers
all
right,
so
I'm
going
to
stop.
Let's
all
go
to
the
lobby
and
think
about
where
we
are
right.
Now
we
hopefully
have
scanned
our
infrastructure's
code.
We've
cleared
everything
off.
We
provision
our
resources.
B
Hopefully
we've
got
something
looking
at
our
application.
Maybe
we
have
something
in
our
supply
chain,
making
sure
that
we've
got.
We
know
that
the
ingredients
to
our
cake
are
the
same
ingredients
we
put
in
the
cupboard
earlier,
probably
we're
scanning
the
application
most
likely
we're
doing
image
scanning
great,
so
we're
we're
starting
to
amass
a
certain
amount
of
vulnerabilities
and
that's
where
vulnerability
management
can
come
become
a
bit
of
a
burden.
B
So
let's
talk
about
how
we
can
get
some
risk
context
here.
How
can
we
add
that
securing
the
deployment?
What
can
we
do
here?
Well,
the
same
as
we
did
for
that
terraform
scan,
we
can
learn
best
practices
for
kubernetes
objects,
both
operational
risk
and
security
risk
why
we
can
bring
essential
context
to
image
deployment
and
vulnerability
management,
because
defaults
once
again
can
be
dangerously
insecure
and
I'll.
Show
you
what
I
mean
by
that.
B
First,
what's
great
many
open
source
tools
are
available.
I
I
love
that
and
there's
a
few
there
kublender
cube
score
check
out
blah
blah
blah.
There's
a
whole
bunch
right.
A
few
weeks
back,
I
think.
Well,
there
there's
a
great
demonstration
on
kubliner
I'm
going
to
give
you
the
two
second
version
of
it.
B
So
kublainer
is
super
easy
to
use
you
stall
again
with
brew.
So
if
you're
on
a
mac
that
easy-
and
if
you
want
to
know
how
to
use
it,
there's
not
a
lot
of
options.
So
you
can
digest
this
pretty
quick.
If
you
want
to
see
what
the
checks
that
exist.
Are
it's
easy
just
write,
checks
list,
you
can
see
the
things
you're
looking
for
things,
you
would
expect
unset
cb
requirements,
ssh
port
again
like
we
had
before
run,
is
now
root.
You
see,
some
of
them
are
true.
Some
of
them
are
false.
B
I
like
that,
actually,
because
the
default
not
all
of
them,
are
on
by
defaults,
but
the
must-haves
are
so
it's
kind
of
a
good
way
of
doing
it.
I
think
if
you
want
to
scan
it's
very
similar,
you
just
type
google
enter
lint,
you
pick
your
file
and
you
can
see
I've
got
one
called
rushed.
This
is
typical
of
a
yaml.
B
Why
is
it
rushed?
Well?
Did
I
put
the
cpu
request?
No,
no
one
does
that
when
they're
rushing,
I'm
I'm
not
wasting
any
servers,
sit
and
run
like
not
set
to
run
as
root.
That's
really
bad.
I
like
that.
I
get
some
information
and
a
link,
so
I
can
go
over
here
and
I
can
go
right.
Okay,
set
security
context
for
the
pod.
Probably
the
single
most
missed
section
of
yaml
is
the
security
context,
makes
me
sad.
B
So
what
I've
done
already?
I'm
not
gonna
go
fix
it.
I
fixed
it
already,
and
I've
got
the
one
that
I
should
have.
I
scan
it.
No
errors
are
found
and
if
you're
wondering
what
changes
I
made
I'll
show
you
the
difference,
it's
nothing.
Hardly
I've
got
some
resource
requests
in
there
they're
a
little
bloated
at
the
moment,
but
I'll
adjust
them
later
and
I've
got
a
security
context
that
makes
me
safe
by
default.
Amazing
super
easy
to
do.
B
I
do
have
a
caveat
for
that.
When
I
talk
about
scanning
yaml
files,
there
are
some
growing
popularity
of
abstraction
layers,
so
cdks
is
one.
I
think.
Plume
is
another
one
where
you
can
embed
the
generation
of
kubernetes
right
into
some
code.
It
sounds
awesome.
I
see
these
things.
I
get
super
excited
because
I'm
thinking
I
can
type
typescript
and
I
can
create
a
service
in
my
typescript
and
I
can
interact
with
it
like
live.
That's
neat.
B
I
like
that
until
I
start
thinking
about
security,
what
if
I
could
enter
the
resulting
yaml
and
there
are
insecure
defaults?
How
do
I
translate
the
results
back
into
the
other
code?
I
wrote
it's
kind
of
there's
a
bit
of
extra
security
headache
going
on
there.
If
we
do
that
so
worth,
knowing
that
the
same
thing
happens
when
you're
writing
javascript
for
the
browser,
you
might
write
it
in
typescript,
you
generate
the
code
that
goes
into
the
browser.
You
find
mistakes
there.
What
does
it
look
like
in
typescript?
There's
all
this
mapping?
B
You've
got
to
do
it's
a
pain,
so
that
was
the
one
caveat,
but
the
reality
is
many.
Open
source
tools
are
available,
the
cons
and
it
would
be
cool
if
we
did
this
more
in
open
source,
but
maybe
I
should
write
an
open
source
project
that
does
it
steve
few
if
any
of
the
open
source
tools
combine
the
scanning
for
image
vulnerabilities
with
the
linting
of
the
ammo.
Wouldn't
that
be
cool
because
the
images
are
there
they're
called
out.
If
we
could
double
that
in
and
use
that
context,
that
would
be
pretty
nice.
B
B
Why
is
it
cool
to
get
the
context
just
like
the
can
of
beer
with
the
10
percent
that
that
that
poor
byron
had?
If
I
know
the
vulnerability
is
going
into
test
only
and
not
going
into
prod?
That's
the
changes
that
it
changes
the
risk
profile.
If
I
know
the
criticality
of
the
app
based
on
insisted
in
metadata,
if
I
know
whether
it's
running
privilege,
that's
really
bad.
If
I
know
if
it
has
access
to
certain
secrets,
I
know
it's
blast
radius,
because
there's
a
load
balancer
in
front
of
it.
B
I
know
it's
a
simple
pod
with
an
easily
characterizable
process
process.
I
don't
know
very
simple
app.
Nginx
is
a
good
example.
Then
I
can
characterize
it.
I
know
what
an
anomaly
looks
like
all
these
things
matter,
because
if
we
think
about
a
cvs
as
9.8
in
a
back-end
service
with
no
external
connectivity,
not
privileged
with
a
recorded
small
baseline
of
activity
cool,
I
actually
might
let
that
go.
B
If
there's
a
7.6,
that's
in
my
front
end
api
find
a
load
balancer
with
an
exposed
port
by
accident,
a
complex
base
image
that
maybe
has
all
those
tools,
hackers
love
like
curl
and
wget
nmap,
and
all
those
right,
that's
so
much
worse,
but
the
prioritization
of
vulnerabilities,
just
based
on
cvss
score,
wouldn't
agree
with
me.
So
this
is
why
we
need
to
start
looking
at
the
context.
We
need
to
focus
on
deployments
in
yaml.
B
Look
at
things
in
the
context
of
kubernetes
objects,
all
right
layer,
six,
the
icing
on
the
cake,
the
run
time,
maintaining
the
state
of
security.
This
is
also
great.
There
are
some
very
cool
things
out
there.
Ebpf
driven
like
balco
was
awesome
tracy
from
aqua
anomalies,
as
kubernetes
objects
can
be
found.
Prevention
by
admission
controllers
via
policy
securities
policy,
with
things
like
oppa
and
kyburn
I
just
started
playing
with,
is
pretty
neat.
B
All
of
this
is
a
great
move
to
run
time.
Why
do
we
need
to
do
it?
Well,
there's
only
so
much
we
can
do
in
layers
zero
to
five
right.
We
shouldn't
do
nothing.
We
want
to
make
as
little
happen
here
as
possible,
and
we
want
to
get
as
much
information
so
that
when
we
are
making
runtime
decisions
on
alerts,
we're
making
them
data
driven,
zero-day
exploits
and
new
attack
vectors
are
going
to
happen.
We
need
runtime.
B
What
are
the
pros
of
runtime?
Okay.
This
is
a
cynical
pro,
but
infosec
people
understand
things
that
edr
and
ideas
they
they
understand
the
world
of
runtime
so
when
you've
got
runtime
and
you're
speaking
of
it
in
terms
of
kubernetes,
this
speaks
the
language
of
infosec
and
it
goes
down
very
well
zero
days
of
anomaly.
Detections
are
still
required
and
it's
an
essential
safety
net
for
all
the
things
you
didn't
do
in
zero
to
five
the
cons.
B
B
B
Shifting
middle
people
are
starting
to
say
this.
Actually,
a
recent
report
called
bsim
11.
I
think
it
was
called
the
shift
everywhere,
which
I
kind
of
like
it's
all
wears
off
simpler
checks,
but
more
often-
and
this
is
what
I'm
trying
to
convey-
it's
actually
all
the
things
I
just
showed.
You
are
pretty
easy,
because
they're
just
little
things,
it
seems
like
a
lot
of
things,
but
they're
all
little
easy
things
and
they
mean
that
when
you
get
to
runtime
a
lot
of
the
easy
stuff's
gone
context
is
a
huge
advantage.
B
B
Everything
this
code
is
great,
reduces
imperative
intervention,
but
remember
the
same
security
concerns
are
there
that
were
there
for
when
we
wrote
application
code,
as
are
there
for
when
we
write
infrastructure's
code
code,
we
should
scan
it.
We
should
put
it
in
git
and
control
it
treat
it
with
the
same
respect,
get
ops
from
plus
kubernetes
enables
us
to
do
that,
and
declarative
equals
deterministic
equals
less
probabilistic
deterministic
security
by
through
kubernetes.
So
that
is
the
end.
Thank
you
very
much.
That
is
me.
A
You
know
part
and
parcel
of
the
dna
of
any
workflow
or
any
deployment
pipeline,
and
that's
really
been
one
of
the
the
mantras
that
we've
had
in
some
of
the
conversations
we've
been
having
about
devsecops
and
the
shift
left
conversations
too,
and
I
you
know-
and
I
really
think-
and
I
think
and
the
more
we
talk
about
context
is
king
or
queen.
Shall
we
say
that
I
think
is
the
key
here?
A
Is
that-
and
I
forget
which
slide
it
was
you
were
on
where
you
were
talking
about
combining
chekhov
and
kublenter
and
a
few
other
things
to
create
that
solution
or
something-
and
you
know
those
those
are
the
things
that,
because
cvs
are
so
noisy,
there
are
so
many
of
them
out
there.
It's
the
context.
A
But
you
know
that
many
of
the
tools
that
you
have
there
are
pieces
of
it,
but
creating
an
environment
and
workflow
that
takes
advantage
of
it
and
doesn't
notify
me
at
two
in
the
morning
that
some
new
thing,
yeah
and
as
mike
is
saying
observability
is
key
and,
and
that's
really
that
that's
another
key
piece
of
it.
So
I
think
that
that
that's
a
wonderful
thing
and
I'm
so
glad
you
know
that
stack,
rocks
and
red
hat
are,
you
know
they're
going
to
be
working
together
closely.