►
From YouTube: The Level Up Hour (E41): DevSecOps and Shift Left Part 1
Description
What does shifting security to the left mean for developers and individual contributors? Join us for a two-part live discussion around DevSecOps! In the first part of a conversation from In the Clouds, Kirsten Newcomer joins the Level Up hour to discuss the importance of a bottom-up approach to security. We often hear about shift left and DevSecOps in conversations about organizational culture and implementing new processes and policies, but it's important not to overlook what you can do to prevent security issues before deployment and how you can help encourage leadership to participate in a more secure software development lifecycle.
Follow us:
Langdon White https://twitter.com/1angdon
Chris Short https://twitter.com/ChrisShort
What is the Level Up Hour?
Every Wednesday at 9 AM ET we stream live demos on how Red Hat Enterprise Linux (RHEL) users and admins can benefit their organizations and improve their careers by learning how to use containers, Kubernetes, and Red Hat OpenShift.
Learn more at https://red.ht/leveluphour
How to participate in the The Level Up Hour:
Watch on YouTube every Wednesday at 9 AM ET
Chat with us on Discord https://discord.gg/5VMVGJt
Check out our GitHub repo https://github.com/level-up-hour/
About OpenShift:
Red Hat OpenShift is an open source container application platform based on the Kubernetes container orchestrator for enterprise application development and deployment.
https://www.openshift.com/
https://github.com/openshift/
#RedHat #OpenShift #tluh
A
A
A
A
B
C
Yeah
so
as
as
always,
I'm
langdon
white-
and
this
is
the
level
up
hour
where
we
talk
about
generally
speaking-
we
talk
about
containers
and
why
they're
interesting
and
why
they
can
be
interesting
to
you
as
like
a
system
administrator
or
a
developer,
just
kind
of
in
your
like
everyday
workflow,
not
to
mention
kind
of
all.
The
all
the
hype
is
right
around
like
using
them
in
production.
C
That
kind
of
thing,
but
I
think
a
lot
of
people
who
have
been
adopting
containers
use
them
all
the
time,
and
so
we
talk
about
all
those
different
kinds
of
usages.
But
then
we
kind
of
talk
about
other
things
as
well,
and
today
is
one
of
the
more
other
things
discussions
where
we'll
be
talking
a
bit
about
security.
C
B
B
C
Don't
know
sometimes
so
you
can
also
talk
to
us
on
our
discord
and
it's
the
link
is
there
and
I'm
sure
that
chris
will
in
the
chat
as
well,
and
so
today
we're
going
to
be
talking
about
some
new
ish
buds
words.
Devsecops
has
actually
been
around
for
a
while.
Now
I
think
and
then
shift
left.
If
you
were
maybe
maybe
actually
I
would
say,
is
it
I
would
say
it's
more
recent
than
devsecops,
but
whatever
we'll
get
into
that,
we
can
fight,
but.
C
Exactly
as
you
notice,
it
says,
part
one
and
the
reason
it
says
part
one
is
not
because
we're
gonna
do
a
part
two
on
this
show,
but
we're
gonna
do
a
part
two
on
another
show
called
in
the
clouds
which
I
wanna
say
is
in
a
couple
or
three
weeks.
I
had
meant
to
look
up
the
date
and
then
I
forgot,
so
I
think
it's
week.
C
A
C
Right
exactly
so,
and
and
kirsten
will
be
back
on
that
show
to
talk
about
the
same
subject,
maybe
from
a
slightly
different
perspective
and
then,
as
always,
show
notes.
From
last
time
we
have
on
the
github
repo
was
episode
40,
where
we
talked
about
serverless
and
why
you
want
some
serverless
servers,
but
we
won't
get
into
the
jokes
we
can
make
there
and
that
for
now
is
the
end
of
our
slides,
all
right
so
kirsten.
D
D
C
C
Also,
I
really
still
need
to
get
one
of
those
t-shirts
that
says
you
know
an
angel
loses
its
wings
every
time
you
set
set
and
force
zero,
but
so
I'm
much
much
better.
Now
I
use
se
linux
on
a
regular
basis.
You
know,
sometimes
I
run
into
problems
or
whatever
and
I'll
turn
it
off,
but
then
I
will
actually
figure
out
why
I
had
to
turn
it
off
fix
that
thing
and
then
turn
it
back
on
again.
C
So
let's
kind
of
talk
about
it
from
a
little
bit
of
the
perspective
of
containers
versus
other
kinds
of
you
know
kind
of
deployment.
Styles.
What
would
you
say
is
the
biggest
difference
between
a
security
in
this
kind
of
cloud
natively
world
versus
security
on
you
know
a
traditional
virtual
machine.
D
Security
should
not
be
an
afterthought.
It's
not
the
responsibility
of
the
security
team
just
for
operations.
It
really
should
be
integrated
throughout
that
devops
life
cycle,
but
people
forgot
and
some
of
the
reason
people
forgot
really
is
that
you
know
historically,
teams
have
been
siloed,
there's
been
the
development
team,
the
operations
team,
the
security
team.
You
know,
devops
people
heard
that
they
said.
Oh
we'll,
we'll
connect
the
development
and
the
operations
team.
They
didn't
always
remember
to
think
about
integrating
security
for
folks
who
haven't
seen
it
devops
shows
up
as
this
infinity
loop
right.
D
There
are
different
stages
in
it,
but
it's
really
intended
to
be
a
closed
loop,
because
it's
not
you're,
not
just
done
once
you've
deployed.
You
may
find
issues
during
a
production
environment
that
then
need
to
be
fed
back
to
the
development
team
so
that
those
issues
can
be
addressed
and
you
restart
that
cycle
again.
D
So
the
reason
that
I
see
devsecops
is
so
crucial
for
containers
is
that
containers
are
designed
to
carry
all
of
the
system
dependencies.
The
runtime
dependencies
with
the
application
code,
and
especially
in
a
kubernetes
environment,
you're
deploying
you're,
always
deploying
from
a
container
image
that
image
is
immutable
unless
it's
rebuilt
right.
So
when
a
problem
shows
up
in
production
and
again,
let's
say
we're
using
kubernetes,
we
said
I
want
three
instances
of
my
web
front
end
to
be
running
as
soon
as
one
of
those
instances
goes
down.
D
If
a
new
cve
is
discovered
in
the
code
in
that
image
and
you
step
into
a
running
container
and
and
fix
it
there,
you
lose
your
fix
as
soon
as
the
redeployment
happens
right
so
best
practice,
never
patch
a
running
container,
always
rebuild
and
redeploy,
and
and
this
yeah
sorry
so
that
really
just
means
you
need
that
infinity
loop.
You
need
dev
setups.
D
C
C
All
the
big
bad
ugly
bugs
that
we
discover
on
the
internet
right
so
or
in
anywhere
kind
of
in
in
software,
and
so
it's
gotten
a
shortened
a
cve.
But
if
you
think
about
it
in
terms
of
this
is
a
kind
of
a
known
bug
to
the
industry,
and
you
know,
hopefully,
there's
also
a
patch
that's
available
for
said
cbe,
but
not
always
right.
So,
just
like.
C
B
C
Should
be
as
as
I
like
to
say,
one
of
the
hallmarks
of
like
an
sre
or
a
devops
environment.
Is
you
fix
the
recipe,
not
the
cake
right?
So
when
you,
when
you
make
a
really
bad
cake,
you
can
sometimes
fix
it
with
frosting,
but
you
know
as
long
as
it's
not
the
flavor,
but
the
look
of
it
I
kind
of
mean,
but
you're
better
off.
C
If
next
time
you
actually
remember
to
grease
the
pan
right,
you
fix
the
recipe
so
that
you
can
make
the
next
cake
a
little
bit
better
without
having
to
cover
it
up
with
frosting.
So
in
kind
of
the
same
way
you
want
to
introduce
those
patches
into
your
container
environment
and
preferably
with
a
fair
amount
of
testing.
C
That's
where
we
get
into
that
continuous
integration
side
of
it,
so
that
you
know
that
you
don't
have
a
developer,
who
took
advantage
of
a
bug
and
did
some
sort
of
work
around
or
had
some
sort
of
cheat
code
that
allowed
them
to
solve
some
problem
and
doesn't
introduce
a
new
security
builder.
So
there's
all
these
things
to
think
about
the
point
being
is
that
you,
you
want
to
bring
those
those
patches,
those
fixes,
those
problems
into
the
the
base
of
your
deployment
environment
so
that
you
can
roll
that
out.
C
So
that's
so.
Basically,
I
think
what
you're
saying
when
you
say
devsecops
right,
is
that
it's
it's
a
first-class
citizen
right
and
that
you
you
want
you
want
it
in
the
catchphrase
right
so
that
it's
considered
just
a
part
of
doing
business.
It's
not
you
know
something
that
is
added
onto
the
side.
You
know
I
I
would
very
much
in
in
a
lot
of
ways
like
to
see
it
be.
You
know,
devsec,
qe,
ops,.
C
D
D
You
know
ci,
which
should
include
test
cd
operations,
etc.
There's
there's
a
whole
set
of
stages,
so
oftentimes
kind
of
with
traditional
architectures.
What
would
happen
is
the
developers
would
work,
work,
work
on
their
code,
they'd,
get
it
ready
to
release
it'd
be
ready
for
deployment,
and
the
security
team
would
run
an
analysis
on
it
and
then
they'd
feed
back
this
huge
list
of
unprioritized
information
back
to
the
development
team
and
the
dev
team
might
have
been
working
for
three
months
and
suddenly
right
they're
stopped
in
their
tracks.
D
C
C
Windows
has
always
had
a
long
habit
of
pushing
updates
automatically
and
the
problem
as
a
developer
is
that
it
came
in
in
an
uncontrolled
way
right.
So
I
would
just
turn
off
updates
until
I
was
ready
for
you
know,
quote-unquote
patch
day
right.
So
you
know.
If
I
was
in
the
middle
of
a
critical,
you
know
development
cycle.
I
would
try
to
bottle
all
that
up
into
one
step
towards
the
end
where
I
could
deal
with
all
those
changes,
good
and
bad
right
so
like
as
in.
C
I
could
then
contain
the
work
into
that
sort
of
scenario,
but
it
means
that
I
may
have
a
large
volume
of
it.
I
especially
now
we're
getting
so
many
attacks
right.
We
have
so
much
code
in
place.
You
know
I
have
my
kind
of
running
joke.
You
know
my
stupid
html
website
websites
running
on,
like
like
at
least
a
million
lines
of
code
right.
C
I
didn't
write
any
of
it,
but
it's
you
know
if
there's
a
ton
of
code
in
there
there's
tons
of
places
for
bugs,
and
so
it's
really
important
that
we,
even
if
we're
we
don't,
have
a
ci
system
or
things
like
that.
We
need
to
be
doing
continuous
integration
all
the
time
as
developers
right.
We
need
to
know,
hey,
there's
you
know,
there's
these
vulnerabilities
out
there.
We
need
to
be
incorporating
those
changes
all
the
way
along
as
we
go,
and
actually
that
might
be.
C
D
No,
absolutely,
and
and
honestly
it's
it,
you
know
as
as
developers.
You
want
that
code
to
get
out
there
so
that
your
users
have
access
right
and
so
anything
you
can
do
to
prevent
roadblocks
down
the
down.
The
road
is
to
your
benefit
right,
and
it
might
mean
you
need
to
learn
a
couple
of
things.
I
mean
one
of
the
things
so
part
of
my
history.
D
You
know
find
some
of
these
open
source
tools
and
incorporate
them
into
what
you're
doing
so
that
you've
saved
yourself,
the
hassle
of
hearing
down
the
road
that
something's
not
ready
or,
if
you
or,
if
it's
your
own
code,
you're
managing
your
own
deployment
right.
You
don't
want
to
deal
with
having
to
scramble
at
the
last
minute
to
address
now.
There's
no
way,
there's
no
way
to
predict
all
the
vulnerabilities
that
we're
going
to
be
dealing
with
right.
New
vulnerabilities
are
discovered
in
existing
code
all
the
time.
D
C
B
There
are
some
questions
we
have
somebody
that
is
very
new
to
devsecops
and
is
interested
in
what
kinds
of
tools
that
people
are
using.
I
mean
we
mentioned
claire,
already
dropped
a
link
to
that
in
chat,
but
kirsten.
I
don't
want
you
to
focus
necessarily
specifically
on
tools
but
classes
of
tools.
What
would
you.
D
Yep
great
question:
so
there
are
a
couple
of
things:
most
people
are
familiar
with
vulnerability,
analysis,
oftentimes.
You
know
it
used
to
be
that
that
a
lot
of
that
analysis
was
focused
on
packages
like
jar
files,
etc.
Now,
of
course,
there
are
plenty
or
binaries.
There
are
plenty
of
scanners
out
there
that
will
scan
container
images
when
you're
building
a
container.
You
always
need
a
base
image
with
your
os
dependencies,
so
you
still
need
a
container
image
scanner
and
that's
one
of
the
things
claire
does
right
and-
and
so
that's
key.
D
D
Those
are
kind
of
two
of
the
key
ones,
one
of
the
newer
things
to
think
about
in
a
kubernetes
environment,
again,
you're
not
just
deploying
a
container
image.
You
have
to
have
instructions
to
kubernetes
about
how
to
manage
that
deployment
and
that's
called
a
deployment
or
sometimes
an
open
shift,
a
deployment
config.
You
might
have
a
helm
chart
that
you're
using
you
might
have
a
kubernetes
operator.
D
Those
instructions
should
be
analyzed
as
well,
and
so
there
are
things
there,
that's
kind
of
an
emerging
space.
So
I
call
it
app
config
analysis,
it's
less!
It's
it's
newer,
but
there's
something
like
cube
linter,
which
is
an
open
source
project
where
you
can
assess
what
are
the
privilege
requests
that
are
being
made
in
those
deployments
or
those
helm
charts?
D
Are
they
appropriate
for
the
environment
if
you
want
to
get
so,
those
are
kind
of
the
the
three
basics
right
vulnerability
and
you
know
cve
analysis
or
sometimes
also
called
a
software
configuration
analysis
tool,
a
sas
tool
for
s
and
analyzing
your
code
and
then
analyzing
your
application,
config
data.
If
you
want
to
get
fancier,
there's
dynamic
application
security,
testing,
there's
runtime
application
security
testing,
but
I
would
start
with
those
those
minimum.
Three.
B
You
know
most
known
bad
security
practices
that
are
happening
out
in
the
world
and
oh
osp
is
trying
to
focus
people
to
mitigate
them
and
their
intention
is
to
build
every
you
know,
cycle
of
their
top
10
on
their
security
stacks
of
suggestions.
So
it's
a
great
question.
There's
a
lot
of
tooling
that
covers
that
entire
space
I
mean
I
will
link
to
the
cncf
landscape.
It'll,
give
you
an
idea
of
the
overwhelming
amount
of
tooling
that's
out
there,
but
that's
basically
the
the
gist
of
what
you
need
to
be
looking
for.
C
I
was
gonna
also
add
there
too.
Another
way
to
think
about.
It
is
like
there's
kind
of
like
looking
at
your
code
like
out
from
the
outside,
which
is
kind
of
the
vulnerability
analysis,
there's
kind
of
looking
at
the
code
from
the
inside,
which
is
kind
of
static
analysis,
and
then
there's
looking
at
the
code
from
where
it's
going
to
run
in
production,
which
is
the
right
computers
and
those
three
things
are
actually
important
in
any
development
environment.
Right
like
whether
you're
using
containers
or
not
containers
or
whatever.
C
It's
the
it's,
the
mechanics
of
how
you
do
that
or
where
the
where
the
stuff
lives,
or
how
many
of
the
places
can
introduce
new
problems,
which
is
the
difference
between
doing
that
in
bare
metal
or
doing
that
in
kind
of
containers.
You
know
it's
just
in
the
kubernetes
environment.
You
get
all
these
advantages
about
making
sure
that
you
know,
like
things
kind
of
like
around
uptime
right.
The
downside
is
that
you
need
to
be
really
much
more
aware
of
the
environment
in
which
that
container
is
playing
in.
D
So
yeah,
so
so,
first
of
all,
you
can
run
containers
on
bare
metal
right
right.
You
can
run
containers
anywhere.
Linux
runs
right
or
windows
if
you're
doing
windows
containers.
So
I
I
think
it's
actually
the
the
difference
that
I
would
call
out
between
a
traditional
environment
and
a
containerized
environment
is
in
two
levels
and
and
you're
absolutely
right
about
those
three
categories
applying
to
both
traditional
architectures
and
containerized
architectures.
D
The
the
difference
is
that
in
a
traditional
environment,
you
can
more
easily
step
into
that
environment
and
view
the
configuration
in
a
when
a
in
a
running
container.
It's
still
a
linux
process,
but
that
container
image
it
it's
one
of
the
that
container
image
is
not
as
it's
a
little
bit
more
opaque.
Initially,
when
it's
deployed
and
that
running
process,
you
can
still
step
into
it,
but
generally
it's
it.
You
you
don't
generally,
and-
and
so
it's
so
again,
there's
that
that
bit
of
opaqueness
and
the
tools
had
to
evolve
to
address
that.
D
Right
they've
been
used
in
traditional
environments;
they
needed
to
be
updated
to
be
able
to
understand,
container
images,
container
processes
and
kubernetes
and
and
a
lot
of
the
original
security
tools.
You
know
some
of
the
the
perimeter
tools,
etc.
They
they
assumed
that
a
a
an
application
was
running
with
a
specific
ip
address,
etc.
It
was
stat
in
one
place,
containers
if
they're
being
managed
by
kubernetes
they're
moving
around
you
don't
know
what
host
they're
deployed
on
they
don't
have
static
ip
addresses,
and
so
the
security
principles
for
traditional
and
containerized
apps
are
the
same.
D
D
There's
a
learning
curve
that
people
are
still
on
around
containers
and
kubernetes
and
there's
some
elements
about
the
amount
of
of
data
that
you
wind
up,
collecting
like
if
you're
following
an
audit
trail
to
debug
or
something
the
amount
of
data
and
the
context
that
you
need
to
really
pull
on
those
threads
in
a
container
and
container
and
kubernetes
environment.
That's
more
complex
for
sure!.
C
Yeah,
I
was,
I
was
also
kind
of
getting
at
the
the
the
thing
that
is
hosting
your
environment
is
also
significantly
more
complex,
so
there's
a
lot
more
opportunities
for
inadvertent
failure
because
of
poor
config
right,
it's
kind
of
like
the
difference
between
running
a
java
application
and
running
a
java
application
in
an
application.
Server
like
you're,
still
got
the
same
problems
just
that
the
the
volume
of
places
where
you
can
kind
of
screw
up
around
your
code
kind
of
has
gone
up.
C
I
don't
know
so
I
just
think
that
there's
and
that's
also
for
your
typical
developer.
It's
also
not
the
kind
of
thing.
I
guess
you
know
languages
programming,
whatever
you're
used
to
looking
at
right,
and
so
when
you're
looking
at
like
deployment
configs,
if
you
are
normally,
you
know
what
let's
say
a
c
developer.
You
know
every
day,
looking
at
a
deployment
config,
it's
not
your
normal
wheelhouse.
C
B
I
thought
you
were
done,
my
bad
so,
like
I
remember
walking
into
a
startup
that
I
worked
at
in
2015
and
I
ran
some
of
these
traditional
tools
against
their
repos
and
then
you
know
this
is
just
me
coming
in
with
my
knowledge
and
saying
all
right,
you
know
we
need
to
procure
these
tools
and
we
need
to
use
them
the
second
I
started
using
them.
The
developers
realized
that
everything
is
vulnerable
and
they
have
to
completely
change
the
way
they
develop.
B
Things
don't
be
surprised
if
you're
new
to
this
and
you
start
running
stuff,
that
there's
some
like
practices
that
have
to
change
and
people
will
learn
new
things
about
like
why
their
code
is
vulnerable.
You
need
to
be
able
to
educate
people
as
to
the.
Why,
behind
that,
so
it's
almost
as
hard
learning
the
stuff
as
it
is
explaining
it
to
others
that
they
have
to
change
some
way.
They
do
things
or
there's
a
new
tool
in
the
process.
B
That's
going
to
start
kicking
back
their
pr's
because
something's
wrong
right,
so
I
also
dropped
a
link
in
chat
to
our
97
things
for
cloud
native
environments.
I
can't
remember
the
name
of
the
book
to
be
honest
with
you,
but
I
contributed
to
it
if
that
counts,
for
anything
you
can
get
it
for
free.
It's
97
things.
Every
cloud
engineer
should
know
we
talk
about
containers
in
the
book.
There's
a
lot
of
you
know.
A
B
Friends
that
wrote
part
of
the
book
as
well
as
some
folks
that
have
appeared
on
the
channel
like
dr
holly,
cummings
and
kirsten.
I
think
you
contributed
to
this
book
too.
I
forget,
I
don't
know,
but
yes,
that
book
will
help
you
kind
of
get
that
high
level
overview
of
cloud
native.
You
know
security
and
your
your
must
haves
for
things
that
are
out
there
in
your
environment,.
D
And
and
then
as
you're
saying
right,
so
we
we
mentioned
owasp.org
earlier
right,
there's
there's
some
interesting
information
there.
The
linux
foundation
likely
has
some
good
content
as
well
for
kind
of.
How
do
you
learn
about
some
of
these
things?
Definitely,
looking
for
various
you
know,
various
places
to
get
educated
is
is
useful,
so.
C
B
C
D
C
And
you
know,
and
really,
if
you
start
to
see,
I
think
what
also
helps
is
this
is
where
the
experience
comes.
In
too,
is
the
more
you
see
of
like
how
things
like
the
os
top
10
work,
the
the
more
you'll
start
to
kind
of
incorporate
best
practices,
kind
of
into
your
own
coding
style,
where
you
you'll.
Second
guess
yourself
when
you
start
to
say
well,
maybe
maybe
I
shouldn't
approach
this
problem.
This
way
right.
A
D
Yeah
exactly
you
know
some
companies
actually
and
and
and
maybe
not
as
many
as
as
need
to,
but
some
organizations
really
have
started
to
embed
somebody
from
the
security
team
into
the
lines
of
business
so
that
they
can
participate
with
the
development
in
developers
at
the
app
dev
team
in
the
design
process
in
the
development
process
and
collaborate
and
and
honestly
this
has
to
be
a
two-way
street.
The
the
security
team
needs
to
learn
some
things
too.
D
In
that
you
know,
security,
there's.
First
of
all,
there's
no
such
thing
as
100
security,
there's,
there's
always
some
level
of
risk,
and
so
you're
really
looking
at
balancing
risk
and
business
benefit
or
or
you
know,
and
and
so
you
want
to
have
a
conversation
and
and
frankly,
because
of
some
of
the
historical
silos.
D
Why
is
security
asking
for
abc
and
you
as
a
developer,
can
think
about?
Well,
is
there
an
alternate
way
to
meet
that
goal
right?
You
can
still
get
to
the
use
case.
Maybe
it's
not
in
the
way
the
security
team
originally
thought
like
one
of
the
things
we
do.
I
do
see.
A
lot
of
right
is
there's
a
lot
of
prac.
There
are
a
lot
of
implementation
practices
or
security
guidelines
that
have
evolved
for
traditional
architectures
and
they
actually
create
some
challenges
for
for
kubernetes,
but
also
for
speed
to
delivery.
D
D
B
D
You
really
need
to
have
an
environment
where,
where
that
can
be
done
in
an
automated
fashion
and
so
to
meet
that
use
case,
there
are
tools
that
are
evolving
in
this
space
that
help,
but
but
that's
an
example
too,
where
the
the
use
case
of
self-signed
certs
are
bad
or
it
has
to
come
from
a
corporate
ca.
Those
are
tied
to
particular
architectures.
D
C
B
C
A
C
Into
that
part,
but
so
kind
of
the
idea
of
that
we,
you
know
the
more
perspectives
we
can
incorporate
into
our
software
development
and
deployment
and
operations
and
testing
the
more
likely
we
are
to
not
make
stupid
or
easy
or
even
hard
mistakes
right
like,
and
it
might
be
a
security
mistake.
It
might
be.
You
know
it
might
be
an
interpretation
mistake.
You
know
I
I
always
go
back
to
this.
You
know
to
the
face
recognition,
problems
that
they've
been
having
because
of
who
they're
testing
the
face.
Recognition
on
yeah.
C
C
Right
so
so,
but
the
the
kind
of
the
takeaway
from
that
right
is
like
the
more
people
that
you
kind
of
can
interact
with
about
kind
of
what
you're
working
on
and
how
you're
working
on
it
and
what
you
know
and
to
your
point
like
what
is
the
goal
behind
this
rule?
You
know
the
better.
You
will
be
as
a
you
know.
As
an
engineer.
D
C
As
an
administrator
or
even
as
a
security
person
right
like
all
of
those
different
perspectives,
you
need
to
you
need
to
be
not
just
living
in
your
little
world.
You
might
know
everything
that
olas
has
ever
said,
but
that
doesn't
mean
you
necessarily
to
your
earlier
point,
understand
the
goals
or
the
business
goals
of
the
application,
and
so
you
really
need
to
try
to
incorporate
as
many
perspectives
as
you
can
and
you
will
end
up
with
better
software,
and
I
think
that's
a
really
important
point
that
I
think
is
highlighted
by
security
in
particular.
Yeah.
D
And
you
know,
honestly,
it's
an
opportunity
for
security
teams
to
learn
as
well
to
your
point
about
you,
know,
yaml
and
helm
charts
these
things,
not
necessarily
being
things
developers,
learn
about.
You
know,
deployment,
etc
that
they
they
they
learn
about
earlier.
It's
not
their
main
focus,
they're
coding
in
java
or
in
you
know,
whatever
their
main
language
might
be,
security
teams,
often
haven't
needed,
haven't
been
asked
to
do
much
coding
either.
B
D
D
C
Right
right
and
one
of
the
things
I
mean
I
I
often
I
think
I
say
this
on
the
show,
but
I
kind
of
talk
about
it
in
general.
It's,
like
you
know,
remember,
our
industry
is
just
our
industry
is
ridiculously
young
right
and
so
not
very
long
ago.
Right
as
a
developer,
I
needed
to
know
how
to
pull
a
hard
drive
and
replace
it
right
right.
C
D
D
Linux
openshift
takes
care
of
that
for
you
right,
but
it
calls
out
the
need
to
really
simplify
to
assist
developers
with
security,
and
this
is
another
place
where
you
know
open
source
can
help
and
and
red
hat
has
been
investing
right
because
there
are
a
complex
set
of
interactions
between
like
some
of
these
terms,
may
not
mean
anything
to
to
our
audience
yet
secure
computing
profiles,
setcomp
it's
a
it's
a
linux,
os
thing
right,
c
groups,
se
linux.
All
of
these
things
that
in
linux,
help
to
protect
a
running
container
process.
D
But
how
do
I
work
with
those
as
a
developer?
What
do
I
need
to
know
about
those?
How
do
I
learn
about
those,
and
so
one
of
the
things
there's
this
open
source
project
called
udisa,
I
never
pronounce
it
u-d-I-c-a
and
and
and
it's
all
about
giving
developers
a
tool
that
they
can
use
to
create
an
se
linux
context
to
better
protect
their
container
image,
so
recognizing
nice
right
that
it's
not
and
and
that's
becoming,
I
think
that's
morphing
into
something
called.
C
C
Know
and
like
and
what
those
different
things
mean
and
how
sometimes
those
things
don't
work
actually
across
like
nfs
mounts
and
things
like
that,
you
know
so
se.
Linux
is
something
when
I'm
using
containers.
I
have
to
be
a
lot
closer
to
than
I
have
been
on
with
se
linux
as
a
developer.
For
quite
some
time.
You
know
the
nice,
the
really
nice
thing
about
how
sc
linux
in
particular
has
gotten
over
the
years.
Is
it
really
has
faded
into
the
background?
C
It's
just
doing
its
thing
and
it
doesn't
cause
me
problems
anymore,
right
or,
if
it
does.
I
have
this
cool
sc
troubleshooter
that
pops
up
and
says
you
know,
go
go
follow
these
things,
and
this
is
where
you
know
how
you
can
fix
the
problem
you're
running
into
so
I
I
really
look
forward
to
some
of
that.
You
know
that
stuff,
like
I
said
all
that
I
really
like
it
when
the
kind
of
security,
the
basics
at
least,
can
fade
into
the
background,
then
I
can
just
worry
about
my
stupid
mistakes.
D
D
C
And
for
pearson's
sake,
all
right,
so
we've
been
at
points
we
like
to
do
a
little
thing
on
the
show
that
we
refer
to
as
sweet,
sweet
internet
points
and
sweet
sweet
internet
points
are
have
no
extrinsic
value
whatsoever,
but
they
have
the
intrinsic
value
of.
You
are
awesome
if
you
have
gotten
a
lot
of
sweet
speed,
internet.
C
You
too
can
be
awesome,
and
right
now
we
have
on
our
leaderboard.
We
have
narendev
with
6100
points,
which
is
just
a
ridiculous
amount
of
points
followed
closely,
as
always
by
netherland
hackham
they've
gone
back
and
forth
a
few
times.
Noah
friction
still,
I
I
don't.
We
have
to
go,
find
out
what
happened
to
them,
but
we
they're
pretty
static
at
the
at
the
4000,
along
with
joe
fuzz.
C
However,
if
you
notice
detective
conan
kudo
has
actually
surpassed
joe
fuzz
with
400
points
and
megan
fork
tightly
behind,
and
so
we
look
forward
to
some
more
mixing
up
with
the
of
the
point
scale.
As
always,
there
is
the
activities
page
on
the
episodes
repo,
which
has
kind
of
how
you
can
earn
points,
but
one
of
the
ways
is
by
entering
this
code
that
you
see
right
here
on
the
screen
in
an
awesome,
awesome,
probably
very
secure.
C
B
But
but
so
here's
a
good
question
from
the
same
person
jessica.
Sorry,
if
I
say
your
name
wrong
that
prompted
the
you
know,
the
question
of
you
know
what
kind
of
tooling
we
need.
Are
there
any
playgrounds
where
people
can
practice
that
that,
like
because
there's
a
lot
of
tools
that
you
can
practice
with.
D
B
D
Git
lab,
oh
well,
styro
is
the
company
that
backs
opa
oppa
is,
is
you
know,
rigo
is
the
policy
language
opa
gatekeeper
is
an
admission
controller
right.
We
talked
about
security
tools,
kind
of
for
the
development,
the
ci
process.
We
didn't
really
talk
about
some
of
the
security
tools
that
that
are
available
to
gate
deployments
and
and
opa
gatekeeper
is
one
of
those,
but
I'm
wondering
whether
you
know
whether
a
get
lab
environment
might
be
a
place
that
you
could
play
around.
D
D
B
D
D
Yeah,
no,
and-
and
I
was
just
thinking
so
so-
certainly
you
know-
git
lab
kind
of
you
know-
has
that
whole
concept
of
shift
left
and
has
a
has
a
lot
of
good
information
kind
of
if
you
just
on
on
on
their
website
and
at
the
same
time
right.
That's
not
the
only
set
of
tools
you
can
use,
but
it
could
give
you
a
good
example
of
oh
and
they
do
have
integrations
potentially
with
with
other
solutions.
D
B
C
It
could
be
working
out
because
I
mean
I
do
know
there
are
places
where
you
can
kind
of
play
around
with
like
sql
injection
right
right.
You
know
like
where
you
can
just
kind
of
go:
try
it
out
and
see
what
it
feels
like
and
you
know
and
have,
or
have
things
do,
sql
injection
tests
against
your
site
so
like
it,
it
might
be
interesting
to
think
about.
How
can
we
open
it.
D
B
C
Well,
I
was
gonna
kind
of
say
was.
Maybe
this
is
a
good
point
to
wrap
up?
I
was
or
kirsten.
Is
there
any
other
like?
What's
the
what's
the
single
biggest
takeaway?
As
you
know,
I
hate
to
use
this
term,
but,
like
you
know,
when
I
see
right
an
individual
contributor
somebody
who
is
not
in
control
of
the
overall
organization,
what's
the
single
biggest
thing,
they
can
do
to
incorporate
secure
practices
into
their
workflow
or
their
work.
As
just
you
know,
somebody
who,
who
is
an
employee
at
a
company.
D
Yeah
so
so
I
think
we
we
kind
of
touched
on
that
a
little
bit
earlier,
but
do
do
your
best
to
learn.
I
think
I
think
check
out
owasp.org
check
out
the
the
book
that
chris
you
mentioned
earlier
and
you
know
for
anybody.
Who's
got
time
to
to
try
a
playground.
You
know,
I
think
the
get
lab
free
trial
would
give
you
an
idea
of
what
it's
like
to
incorporate
all
of
these
things,
and
actually
I
really
liked-
and
I
so
you
asked
for
one-
I'm
sorry,
I
don't
have
one.
B
C
And
just
also,
by
way
of
a
little
bit
of
context,
we
kind
of
gloss
over
devops
on
a
pretty
regular
basis.
If
you
aren't
that
familiar
with
devops
go,
read
the
fun
little
novel,
the
phoenix
project
and
you
know
kind
of
learn
from
there.
It's
it's
a
fun
little
book.
You
know
it
will
be
a
good
excuse
to
read
something
for
work.
That
is
not
boring.
Yeah.