►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Welcome
to
pull
request
or
it
didn't
happen,
and
we're
really
excited
to
kick
things
off
today,
I'm
going
to
play
a
bit
of
an
mc,
and
I
have
two
very
esteemed
guests
who
are
going
to
join
this
conversation,
raj,
who
he's
the
senior
platform
security
manager
at
actblue,
and
we
have
jack
zaras
who's
here
at
ksoc,
he's
our
director
of
sales
engineering.
So
welcome
to
the
two
of
you
and
you
know
we
we
are
doing
something
a
little
different
today,
we're
not
going
to
flip
through
a
bunch
of
slides.
A
We
have
some
conversation
points
we
want
to
hit
and
we
also
want
to
engage
with
you
all
who
took
the
time
out
of
your
day
to
to
attend
this.
So
again,
welcome
I'm
going
to
stop
sharing
my
screen,
so
you
could
see
our
lovely
tired
faces.
I
think
we
are
all
parents
of
young
children,
so
none
of
us
sleep
very
well
at
night,
yeah.
B
A
We'll
get
going
so
let
us
kick
things
off
and
we
are
going
to
start
that
by
setting
the
stage
we're
here
to
talk
about
remediation,
get
ups,
there's
there's
some
buzzwords
and
some
acronyms
involved,
but
I
think
they're
really
important
ones,
and
I
think
it's.
We
have
the
right
team
here
to
kind
of
discuss
these
topics
so
off
the
bat
this
one's
for
you
raj.
A
What's
getups,
what
are
you
doing
at
act?
Blue?
That's
that's
different!
How
do
you
embrace
this
whole
notion
of
get
ops
and
what
does
it
mean
for
your
security
team
that
you're
building.
B
B
Current
time
is
cncf
sort
of
blessed
golden
path
to
ensure
that
you
can
codify
your
workloads
and
your
clusters
for
kubernetes,
encode
and
operationalize
that
code
in
a
way
that
gets
the
things
out
into
production
right,
and
that
generally
means,
I
think,
right
now-
flux
customize
a
little
bit
of
terraform
cloud
independence,
some
sort
of
standardization
on
like
what
you
expect
to
be
codified
in
the
code
bases.
B
What
do
you
expect
to
not
happen
with
your
infrastructure
that
sort
of
stuff,
but
I
want
to
like
before
I
like
end
it-
is
that
idea
of
getting
things
statically
defined
as
early
as
possible
and
having
your
production
infrastructure,
be
represented
by
static
definition
and
have
your
production
infrastructure
be
able
to
be
spun
up
somewhat
programmatically
and
by
static
definition.
That
is
like
what
I
just
think
about
when
I
think
git
ops
and
like
just
to
share
these
concepts.
These
are
not
necessarily
super
new
lots
of
organizations.
B
I've
been
a
part
of
have
aspired
to
get
to
these
sort
of
things
like
way
back
to
like
the
etsy
days,
where
we
shipped
all
the
things
and
like
we
had
it
just
generally
running
relatively
well,
where
infrastructure
could
be
like
spun
up
statically,
where
we
codify
infrastructure
as
the
os
that
was
installed
on
the
bare
metal.
The
lamp
stack,
essentially
because
we
were
way
back
in
the
day.
B
We
actually
had
lamp
stacks,
like
that,
did
all
the
stuff
that
were
codified
via
chef
and
a
little
bit
of
python
and
a
little
bit
of
just
bash,
doing
some
funky
stuff
and
then
operationalizing
like
this
orchestra
that
we
had
in
in-house
right
all
the
way
up
to
like
mid
career.
Where
you
know
I
was
spotify,
we
used
a
lot
of
puppet.
We
were
a
little
bit
more
native
dot,
a
little
bit
more
native
with
docker,
but
not
kubernetes.
B
So
we
like
had
our
own
orchestration
layer
called
helios
and
not
kubernetes.
But
again
we
codified
things
in
code
and
we
relied
on
that
and,
like
we
were
relatively
confident.
If
we
poked
into
a
random
production
box,
we
would
see
something
that
exists
there
and
know
how
to
map
it
back
to
somewhere
was
statically
defined
and
we're
confident.
That's
you
know.
That
is
the
state
of
truth.
So
that's
what
I
think
about
get
ops.
B
C
So
I
for
me
it's
looking
more
from
the
security
side.
I've
worked
as
a
sales
engineer.
I've
worked
as
a
product
manager
and-
and
we
talked
about
this
a
little
bit
a
bit
earlier,
where
security
was
somewhat
detached
from
the
actual
work
of
securing
the
application
and
they
didn't
they
didn't
have.
I
want
to
say
that
probably
accountability
would
be
the
right
word.
C
So
from
the
security
side,
that's
where
I
see
a
remediation
of
this
code
playing
is
security
now
having
skin
in
the
game
rather
than
they
give
they
give
you
reports.
They
tell
you
what
you
know
the
development
team,
what
they
should
be
doing
instead
they're
actually
making
the
changes
themselves
through
the
ci
cd
pipeline
via
via
via
get
and
having
that
all
audited.
C
So
I
I
I
see
that
you
I
could
see
ring
going
like
you
have
thoughts
on
about
it.
Go
go
yeah.
B
So
what
you're
saying
is
gitops
is
an
opportunity.
We
didn't
even
plan
that,
but
that's
like
totally
exactly
the
thing
right.
Gitops
is
an
opportunity.
What's
the
opportunity,
it's
the
opportunity
for
a
security
team,
perhaps
to
more
easily
and
more
effectively
get
involved
on
the
engineering
side
on
the
deployments
of
remediation
side,
because
perhaps
in
a
world
that
in
an
organization
that's
not
strongly
adopted,
get
ops
paradigms,
it
may
be
unreasonable
to
assume
your
security
engineer
can
do
direct
cube,
cuddle
commands
against
the
production
infrastructure
for
to
affect
the
change.
B
It
may
be
unreasonable
for
your
security
engineer
to
go
in
and
tweak
a
sql
config
in
your
production
database,
because
you
don't
have
that
experience.
You
don't
understand
the
other
side
effects,
but
in
a
world
where
you
are
living
in
an
organization
that
does
adopt
git
ops
forward
paradigms,
it's
more
reasonable
to
expect
a
security
engineer
to
understand
the
tool
chain
that
implements
git
ops
as
per
cncf,
namely
customize
and
flux,
and
it's
actually
maybe
more
reasonable
to
expect
a
security
engineer
to
learn
it
and
to
not
feel
that
that's
a
wasted
skill.
B
It's
not
like
they're
going
to
leave
that
organization
and
have
to
relearn
a
new
stack
where
you
know
for
an
sre,
maybe
that's
an
expected,
like
skill
set
to
be
able
to
learn
new
stacks,
but
for
secure
nature.
Learning
git
ops,
like
modern,
git,
ops,
technologies
and
languages
is
not
a
skill
that
is
wasted,
so
we
can
expect
our
security
engineers
to
learn
it
and
then
to
through
the
process
of
learning
it
pr
directly
against
it.
That's
what
I
heard
you
say
that
sounds
good
to
me.
So.
A
Does
that
starts
to
sound
a
lot
like
security
engineers
should
be
able
to
read
and
write
code.
C
C
Maybe
not
maybe
not
java,
maybe
not
maybe
not
python,
but
infrastructure
is
code
code
networking
as
code
code,
you
and
I
talked
about
this
yesterday-
jimmy
you
getting
through
a
kind
of
a
sales
engineering
lens
like
how
many
sales
presentations
have
you
sat
in
on.
I
know
every
sales
presentation
I've
been
handed
always
had
either
a
circle
or
a
figure
eight
like
with
the
this.
C
Product
fits
into
your
pipeline
automatically
feeds,
but
usually
what
it's
doing
is
it
finds
a
security
issue
and
it
just
notifies
somebody.
It
doesn't
actually
complete
any
circle.
Somebody's
got
to
do
work
to
complete
that
circle
to
to
finish
it,
but
but
feeding
the
remediation
as
code.
When
you
find
an
issue,
I
it
just
occurred
to
me.
Essay
like
that
actually
does
complete
the
loop
it.
Actually,
you
find
a
security
issue.
C
You
check
in
what
you
think
the
remediation
is
via
a
pull
request,
and
it
you
know,
can
fix
that
issue.
It
actually
can
come
in
reality,
start
to
complete
that
circle,
rather
than
it's
just
a
marketing
slide.
B
C
No
you're
right
you're
right,
so
maybe
it's
dip
your
that's
the
goal.
Typically,
the
security
engineers
know
things
like
like
networking
security.
That's
that's.
One
of
the
places
they've
been
in
most
often
are
os
security
patches
things
like
that
and
that's
the
first
step
is:
is
security,
understanding,
infrastructure's
code
networking
is
code
with
the
goal
of
getting
to
applications
actual
application
code.
C
B
There's
another
opportunity
right:
yes,
like
the
other
opportunity,
then
is
yes
and
just
I
mean
hedging
bets
like
hedging
it
a
little
bit
a
little
bit
here.
One
big
reason:
I'm
super
excited
about
being
a
an
advisor
for
you
all
is
because
I
get
to
hopefully
and
encourage
certain
types
of
philosophies
on
on
how
you
solve
the
problem.
B
One
philosophy
that
I'll
bring
up
right
now
is
the
tool
that
is
ksoc
when
providing
remediation
as
code
is
also
providing
a
safe
guardrail
for
security
engineers
to
not
mess
it
up
too
badly,
because
you've
spent
all
the
time
already,
hopefully
recommending
a
potential
fix
in
code
that
you
are
relatively
confident.
You
understand
the
side
effects
you
probably
will
have
some
training
behind
it.
You'll
probably
be
able
to
help
the
security
engineer
through
the
usage
of
the
tool
become
a
better
builder.
B
So
the
idea
is
that,
like
for
other
tools
out
there,
not
just
like
iac
type
things
like
this,
but
if
you're
talking
about
like
first
party
code
scanning
tool,
suites
that
are
like
machine
learning
enabled-
and
you
know-
find
like
little
signal-
source
ratio
and
like
an
auto
remediate
stuff.
Even
there,
the
way
I
think
about
those
sort
of
partnerships
is
like.
B
I
want
the
remediation
to
be
able
to
teach
my
security
engineers
a
little
bit
of
code
as
well
help
them
out
build
the
confidence
that
this
is
fine
and,
like,
I
think,
that's
the
the
cool
thing
here
with
k-sock.
Is
it's
not
going
to
be
overnight
that
we
expect,
or
we
think
the
industry
will
expect
all?
Let's
just
say,
infrastructure
engineers
to
be
able
to
pr
directly
against
your
get
ops,
repo
and
deploy
to
prod.
B
C
You
caught
me,
you
totally
caught
me
there
because
I
exposed
my
own
personal
trepidation
like
infrastructure
code.
Networking
is
code
totally
I've
been
playing
in
that
arena
for
for
quite
a
while,
but
actually
you
know
I
can.
I
can
read
application
code,
but
I
would
be
a
little
hesitant
to
to
propose
to
actually
roll
out
fixes,
but
I
think
that
gets
to
the
point
in
get
ops,
you
propose
a
change.
It
gets
basically
peer,
reviewed
and
checked
and
audited
before
it
gets
before
it
gets
sent
out.
A
Let
me
give
a
concrete
example,
as,
as
we
are
a
a
relatively
new
company,
we
had
to
build
our
own
infrastructure
right
and
you
see
steve
wade
in
chat
here.
He's
he's
our
senior
principal
all
things
platform,
engineer
and
and
back
end
engineer,
and
he
brings
more
iac
and
github's
experience
to
the
table
than
I
have
ever
really
encountered
in
my
career.
Thus
far.
So
as
a
as
a
green
field
opportunity,
we
we
codified
everything
right
like
you,
can't
even
create
a
github
repository
without
it
being
as
part
of
terraform.
A
It's
a
kind
of
a
running
joke.
Adding
users
we
have
all
of
the
aws
accounts
set
up.
Everything
is
checked
in
as
code
and
while
that
may
seem
overkill,
it
really
isn't.
Because
now,
when
I
need
a
git
repository,
the
process
isn't
a
point-and-click
kind
of
operational
snowflake
event:
that's
happened.
It's
actually
going
through
the
rigor
of
linting,
it's
going
through
all
sorts
of
pre-commit
hooks.
We
have
security
checks
to
make
sure
you
don't
have
secrets
stored
in
in
a
particular
git
commit.
We
have
peer
review.
A
We
have
this
this
process
that
is
really
powerful
to
make
sure
that
that
is
a
rebuildable
solidly
sound
like
sound
infrastructure
from
ideation
to
production
and
that
to
me,
as
you
know,
watching
it
kind
of
come
up
from
from
nothing
from
signing
up
for
the
first
aws
account
at
a
company
to
something
that
lets
developers
and
security
teams
safely.
Deploy
an
application
or
microservice
or
a
config
to
an
api
gateway
is,
is
really
confidence
inspiring
right.
A
So
on.
B
That
something
I
want
to
like
well
before
you
get
too
far
from
that
go:
go
yeah
at
some
point:
ksock's
going
to
be
a
two
billion
dollar
company
with
like
30
employees,
and
some
will
point
later
in
the
future.
It'll
be
a
100
billion
dollar
company
with
3
000
employees,
let's
say,
and
at
some
point
you're
going
to
have
a
security
team
and
your
security
team
is
going
to
be
charged
with
making
sure
that
something
good
is
happening
and
at
some
point
you're
going
to
have
a
danger,
who's,
gonna
say
hell.
B
I
have
no
idea
how
to
follow
this
paradigm
and
use
this
cookie
cutter
template
and
then
deploy
this
thing
that
has
convention
all
over
the
place.
I'm
just
gonna
go
make
a
security
aws
account
and
be
a
like
a
little
snowflake
off
to
the
side
and
solve
the
problems.
That
way,
and
at
some
point
someone's
gonna
have
to
be
okay
with
that
or
not
be.
Okay
with
that,
and
I'm
saying
that
as
like
that
is
going
to
happen,
no
matter
how
awesome
you
jimmy
think
your
developer
experience
is
right.
B
I
call
it
out
every
single
time
now,
and
it
does
mean
that
I
tell
them.
I
see
so
it's
going
to
take
us
a
week
to
add
a
subdomain
because
we're
learning
how
to
do
it,
because
our
developer
experience
is
something
that
we're
not
we're
not
accustomed
to.
But
I
hold
a
specific
value.
Important
to
me
start
building.
Do
the
building
you'll
get
faster
at
it
and
you'll
be
a
partner
with
your
devx
teams
to
improve
it
myself
or
yourself
so
like
I'm,
just
throwing
it
out
there.
A
The
scale
is
so
there's
one
way:
I've
seen
this
kind
of
sort
of
work.
In
my
past
life
I
was
at
a
kind
of
consumer
mobile
app
company.
We
had
a
very
large
infrastructure
and
we
would
do
it's
basically
introducing
chaos
experiments.
A
You
know
we
didn't
call
it
that
but
repaving
where
we
would
take
down
infrastructure
at
random
times,
and
it
put
the
fear
of
god
in
in
development,
because,
if
you're
building
something
on
the
security
side,
if
it
wasn't
in
git
it
didn't
go
through
we're
using
puppet,
it
didn't
have
all
the
the
pieces
and
you
were
kind
of
ssh'ing
and
making
your
own
configs.
There
was
the
real
chance
that
that
night,
it
could
all
be
gone
and
your
work
would
just
go
away.
A
A
Obviously,
it's
a
it's
an
extreme
end
of
that,
but
I
think
culturally,
it's
it's
important
to
to
have
kind
of
like
evangelists
inside
that
are
helping
people,
because
it's
hard
when
you're
introduced
to
terraform
in
a
big
organization
and
all
you
just
need
to
make
like
a
c
name
change
or
something
like
yep.
I
will
admit
it
is
not
the
most
approachable
subject,
so
you
need
advocates
who
are
going
to
help
you
get
through
that
and.
B
A
Because
you're
going
to
take
more
time
and
the
first
six
months
are
going
to
be
harder
than
click
ups,
like
click
ops,
will
always
win
for
speed,
but
there's
a
resilience
factor
to
get
ops
that
can't
be
understated.
So
the
you
know
the
last
thing
that
the
thing
we're
working
on
at
k-stock,
at
least
in
the
context
of
kubernetes,
is,
is
drift.
Detection
right
drift
is
it's
really
important
to
understand.
A
What's
happening
in
code
typically
is
not
one-to-one
with
what's
happening
in
run
time.
Whatever
that
run
time
may
be,
we
enable
that
in
kubernetes
because
cube
cube,
control
right
or
whatever
somebody
ssh
to
some
machine
introduced
a
couple
new
workloads
for
a
test
environment.
A
They
somehow
made
it
into
production
and
they're,
not
reflected
back
in
the
actual
yaml
manifests,
that's
a
that's
a
security
finding
and
if
you're
doing
this
right
right,
it's
like
you
don't
want
snowflakes,
because,
ultimately,
that
cluster
will
go
away,
the
nodes
will
go
down,
workloads
will
get
shifted,
moved
and,
if
they're
not
tracked,
they're
they're
as
good
as
gone.
So
I
think
drift
detection.
A
You
know
it's
kind
of
early
days
like
using
that
in
security,
but
it's
something
we're
working
on,
because
you
should
be
closer
to
one
to
one
from
code
to
runtime
and
there's
a
big
gap
there
today.
C
So
the
reality
is
that
every
once
in
a
while
forget
about
the
the
person
who's
like-
I
don't
have
time
for
this,
I'm
just
going
to
do
it
myself,
I'm
going
to
I'm
going
to
do
it
the
manual
way,
if
production's
on
fire-
and
you
need
to
make
a
change
fast
like
I
don't.
I
don't
have
literally.
We
do
not
have
time
for
this,
and
we
need
to
temporarily
give
somebody
act.
Direct
access
to
the
environment
to
make
run
time
changes.
C
That's
that's
something
we're
working
on
as
well
to
say:
okay,
we're
gonna,
allow
that,
but
we're
going
to
temporarily
allow
that
kind
of
access
and
fully
audit
it.
When
we
give
you
that
access
so
yeah,
you
can't
completely
close
the
window
because
there
are
times
when
it's
not
just
somebody,
I
don't
want
to
say
lazy,
but
they're,
just
they
want
to
get
their
job
done.
They
want
to
get
it
fast.
Yeah,
there's.
B
And
I
mean
I'll
say
this:
socks
regulations
are
a
boon.
I
think
when
it
comes
to
something
like
this,
because
if
you
actually
have
to
do
real
socks
stuff
and
like
also
some
like
real
pci
stuff,
the
idea
is
like
auditing
and
tracking.
It's
not
necessarily
blocking
right.
B
So
sometimes
it's
easier
to
block,
but
sometimes
it's
just
as
effective
to
detect
and
to
allow
exception,
use
cases
and
like
if
you
are
implementing
pci
back-ends,
like
obviously
I
work
at
blue,
so
there's
pci
stuff,
because
there's
money,
lots
of
money,
lots
of
credit
cards
if
you
worked
at
any
publicly
traded
company-
and
you
have
to
make
sure
you
can
ensure
that
all
your
plays
are
like
very,
very
accurate,
because
you're
spending
money,
it's
material
impact
like
you're,
doing
sock
stuff,
if
you're
a
technologist
in
these
places,
you
start
to
build
this
intuition
a
little
bit
better,
where
actually
it's
not
about
making
it
impossible.
B
It's
allowing
for
exception,
use
cases
allowing
for
auditability
trails
and
as
a
builder,
in
those
places
that
starts
to
become
relatively
natural.
What's
interesting,
I
would
highlight
is
as
a
security
engineer
on
most
secure
teams.
I've
been
on,
we
like
avoid
all
the
regulation
stuff,
so
we
never
get
to
build
that
intuition.
That's
someone
else's
job,
that's
a
grc
person's
job
and
a
grc
developer
person's
job,
and
they
build
that
intuition
and
all
we
see
is
like
wait.
B
You
can
deploy
to
you
can
force
force,
push
to
master
that
your
that's
not
allowed,
because
there
are
assumptions
we
should
block
it
as
opposed
to
okay,
you
can
force
push
the
master
assuming
there's
a
link
you're
a
ticket
that
is
of
this
type.
That
has
a
acceptance
flow
that
was
over
here.
That
we
know
is
like
going
to
be
audited
and
then
on
a
trail
is
like
locked
down.
B
You
can't
mess
with
autrial
like
you
build
those
intuitions
when
you
are
a
builder
when
you
are
forced
to
be
you
know,
building
things
in
these
environments
and
like,
I
think,
that's
amazing,
to
think
about
all
the
time.
Every
time
you
think
about
protective
controls
like
is
it
really
doesn't
need
to
be
protected?
Can
it
be
more
detective?
B
Can
it
be
protective
with
with
escape
routes,
because
you
understand,
like
your
business,
that
needs
to
be
agile
in
incidents
that
sort
of
stuff
only
yesterday
we're
good
opsifying
some
parts
of
our
stack
right
now
like
we're
we're
an
18-year-old
plus
company.
So
we
didn't
have
git
ops
even
like
the
initial
definition
of
get
ops.
When
we
first
started,
it
was
like
click,
ops
and
console
apps
and
whatever.
B
Call
it
for
a
long
time
we're
good
optifying
some
things
right
now
and
one
thing
I
had
a
conversation
with
one
of
the
engineers
and
that's
doing
this
right
now.
We're
like.
I
really
love
that,
like
it's
fully
automated
the
documentation
shows
the
fully
automated
like
workflow,
but
before
we
consider
this
done,
can
you
also
provide
me
documentation
on
if
we
need
to
manually
cut
a
tag
and
push
something
to
that
environment?
What
are
the
what's
the
run
books?
Can
we
even
do
that
and
if
we
can
do
that,
how
are
we
double
checking?
B
That's
on
the
audit
trail
as
well,
like
the
project
is
not
done
until
that
piece
is
also
there.
This
is
a
conversation
we
had
yesterday
and
that's
how
we
we
keep
it
going
like.
We
make
sure
every
option
we
have
as
leaders.
We
convey
these
ideas,
like
don't
be
too
lazy
like
we're
the
ones
that
could
be
more
lazy
than
anyone
else
saying
that
looks
secure
enough,
that's
safe
by
default.
That's
in
the
paradigms
that
any
oas
top
10
webinar
thing
will
talk
about.
We
need
to
make
sure
like.
B
C
I
mean
we're
all
we're
all
engineers
here.
If
we
have
a
break
class
moment
where,
like
look,
I
need
to
go
around
the
the
approval
process
or
the
normal
process
of
doing
things
to
get
my
job
done,
because
it's
an
emergency
and
you're
not
and
you're.
Blocking
me
I'm
going
to
find
a
way,
and
it's
going
to
be
a
way
that
you
don't
like,
but
it's
going
to
get
the
job
done,
provide
an
escape
patch,
a
release
valve
that's
approved.
That
goes
through
that
audit.
You,
it
behooves
you
to
make
that
available.
A
So
raj,
how
do
you
build
a
team
around
this?
Your
your
your
task
at
hand
at
actblue.
Is
you
know,
platform
security?
How
do
you
take
an
existing
security
team?
How
do
you
hire
what's
the
what's
the
leadership
mentality
that
your
head
is
in
to
actually
embrace
this
sort
of
new
newish
paradigm.
B
Yep
so
I'll
say,
there's
a
couple
things
there
ooh.
I
didn't
prepare
this
one.
This
would
be
fun.
Let's
see.
B
Yeah,
I'm
sure
so
I'll
say
this:
I'm
lucky
that.
B
B
So
that's
the
currency,
so
it
act
blue,
so
that
one
thread
means
that
there's
at
least
some
value
alignment
between
myself
and
the
person
who
I
am
reporting
to.
So
there's
that
thing
there's
value
alignment
and
what
are
those
values
they're
aligned
because
of
the
etsy
stuff
they're
aligned,
because
we
all
have
alumni
slack.
So
we
we've
been
keeping
up
and
keeping
in
contact
through
our
career
growth
and
we've
been
comparing
notes
regularly.
B
So
not
only
is
there
value
alignment
because
we
started
at
the
same
place,
there's
been
continual
value,
as
we've
meant
have
we
compared
notes
and
chatted
different
places
again
so
like
why
that's
important,
like
I
knew
already
that
this
sort
of
concept
is
something
that's
there's
an
appetite
for
in
the
existing
security
leadership
at
act,
blue.
So
there's
that
now
that
doesn't
mean
like
you
can
still
get
it
right
because,
like
that's
just
the
one
okay
you're
allowed
to
do
it
essentially,
so
then,
how
do
you
do
it
successfully?
B
You
need
more
more
pieces
of
the
puzzle
here.
Other
pieces
of
the
puzzle
are
relevant
are
through
my
career
journey.
I
tend
to
be
the
one
who
deployed
things
to
production.
As
an
engineer
I
have
totally
like
I
totally
brought
down
etsy
one
time,
because
I
was
doing
a
crypto
thing
and
I
used
up
all
the
entropy
on
our
web
servers
and
tls
just
broke.
I
did
that.
I
rigged
it
up.
It
was
fun.
It
was
interesting.
I
did
that.
I
I
was
at
an
embedded
systems
company
and
that
camera
over
there.
B
I
was
the
one
who
specked
out
the
definition
on
the
atmel
chip
on
it
to
do
some
basic
crypto,
off-boarding
stuff.
I
was
allowed
to
do
it
so
I
did
it.
I
cost
some
devs
some.
What's
it
called
manufacturing
cycles
that
were
messed
up
because
I
I
messed
it
up,
but
they
allowed
me
to
do
it.
So
that's
another
piece
of
the
puzzle
as
a
doer.
I
also
had
the
values
of
building.
So
now
I
knew
it's
possible.
B
So
now,
as
a
leader,
I
decided
that
when
I
hire
a
team
and
when
I
interview
for
a
team,
I'm
very
forward
with
the
idea-
I
I
expect
all
of
us
to
build-
I
expect
us
to
develop.
I
expect
us
to
push
codexpress's
recode
and
during
that
process
of
interviewing
people
fall
out
of
the
funnel
because
they
don't
want
to
do
that
and
there's
organizations
that
you
don't
need
to
do
that.
B
But
sometimes
when
you
do
that
early
in
the
funnel
some
people
like
click-
and
they
are
very
excited
about
that,
they
change
the
way
they're
even
present.
Coming
to
the
interview
now,
they're,
leading
with
projects
not
hacks
they're,
leading
with
bills,
not
cves,
and
it's
like.
Oh,
this
is
really
cool
so
now
you're,
acting
as
a
sieve
to
like
build
an
organization
that
values
some
of
these
priorities
and
and
there's
that,
but
there's
also
this
other
thing.
You
can
do
a
lot
more
internal
hiring.
B
Now
you
can
find
people
in
the
organization
who
don't
want
to
be
the
sre
anymore.
They
don't
want
to
be
the
director
of
infra
anymore.
They
maybe
want
to
be
a
mid-level
security
person
and
what
my
job
is
there
is
to
be
like.
You
can
teach
me
a
ton
about
building.
I
hopefully
can
teach
you
a
ton
about
offensive
mindset,
let's
put
our
brains
together
and
codify
a
project
that
will
mix
these
things
up
and
at
act
blue.
That's
our
that's!
My
current
strategy,
I'm
lucky!
B
I
have
like
two
amazing
people
on
the
team
that
deployed
our
get
ops
and
like
have
been
long-term
engineers
of
the
organization
and
really
know
our
infrastructure.
I
learned
from
them
every
single
day
about
like
the
ways
you
should
think
about
like
flux
and
customize,
and
I
also
have
people
on
the
team
who
are
like
really
really
badass
like
pen
testers
and
we
work
together.
We
plan
a
roadmap
out
six
months
on
what
we
want
to
build.
B
We
know
that
the
building
part
of
our
roadmap
is
probably
only
half
of
the
amount
of
time
we
contribute
to
the
company.
The
other
half
will
be
ad
hoc
things
that
pop
up
bug,
bounty
security
architecture,
reviews
ad
hoc
code
reviews
that
sort
of
stuff-
and
that's
it.
We
we
execute
on
that
plan
for
a
year
and
see
what
we
need
to
do
next,
that's
my
long
answer
to
that
question.
A
That's
good!
No!
I
liked
your.
I
liked
all
the
stories
yeah
I
mean,
I
think
it's
it's
getting
getting
out
of
the
internal
consultant
mindset
that
we
always
talk
about
where
you
kind
of
have
this
list
of
issues.
A
You
present
them
in
some
format
and
you
go
about
your
day
and
you
know
to
plug
what
we're
kind
of
building
at
k-stock
is
that
is
that
pull
request
like
the
title,
pull
request
or
didn't
happen
and
there's
a
lot
there's
a
big
difference
between
a
pull
request
with
a
first
pass
at
an
actual
fix
than
a
kind
of
outstanding
ticket
in
the
backlog
that
may
or
may
not
be
addressed.
The
pull
request
is
where
the
conversation
happens
with
the
right
stakeholders.
A
It's
where
the
you
know
the
the
sre
comes
in
and
does
some
regression
testing
it's
where
you
can
actually
have
multiple
levels
of
peer
review
and
everybody
can
see
the
code
now
do
tools
automatically
generate
perfect,
pull
requests
that
can
automatically
be
merged
to
every
environment
without
looking
at
them.
Absolutely
not,
but
the
the
conversation
that
happens
in
the
fixes,
the
the
different
the
commit
history
is
your.
Is
your
audit
trail
right,
like
the
audit
trail,
is
as
clean
as
it
can
be
when
it's
in
the
form
of
code?
A
So
that's
what
we're
trying
to
build
for
for
kubernetes,
because
it's
a
messy
complex
system
and
if
you're
already
relying
on
git
ops,
we
should
have
a
path
to
fix
the
code
for
you,
or
at
least
give
you
that
really
strong
starting
point
so
and.
B
B
That's
going
to
be
very
important
for
all
of
us,
so.
C
A
C
That's
not
I'm
gonna
put
you
on
the
spot,
jimmy
so
that
journey
you're
talking
about
so
let's
say
we.
We
create
a
pull
request
for
remediation
as
code
to
fix
an
issue,
and
you
know
whatever.
Whatever
suggestion
we
make,
that
or
remediation,
we
we
include
is
not
the
same
as
what
actually
gets
implemented.
C
What's
the
process
for
then
adjusting
that
in
the
future
that
remediation
that
that
automated
remediation,
if
that
same
issue
pops
up
again,
how
do
we
feed
that
that
that
journey,
that
learning
of
oh?
Actually,
this
wasn't
exactly
what
we
did.
B
A
The
the
beauty
of
it
we're
gonna
go
inception.
Style
here
is
like
the
rem.
The
remediation
is
actually
code.
Two,
so
you've
have
a
place
to
go
back
to
the
remediation
that
created
the
the
code
that
created
the
remediation
and
you
can
you
can
tweak
your
your
parameters
right
and
you
go
through
the
same
process
over
there.
It's
a
new
pull
request
against
the
remediation,
and
it's
you
know
specific
now
to
your
use
case.
So
that's
it.
A
It's
code,
all
the
way
down
right,
there's,
no
special
magic
box
that
creates
remediations
that
aren't
isn't
backed
by
something
itself
and
git.
So
you
have
the
conversation
over
there
when
you
need
to
improve
on
remediations.
A
So
it's
it's
it's
very
kind
of
mind-boggling,
but
when
you
embrace
that
it's
the
changes
live
there
and
the
conversation
happens
there.
I
think
yeah,
that's
that's
the
future.
So
that's
how
I
would
answer
that.
I
think
we're
coming
up
on
time.
Raj
wants
hot
takes.
I
I
mean
you
know
we
we've
for
some
reason.
I
said
a
few
days
ago
we
were
prepping
for
this,
put
the
put
the
engineering
back
in
security
engineering.
A
So
you
know,
I
think,
that's
that's
the
take
it's
getting
better
over
the
years,
but
if
you
haven't
learned,
if
you're
attending
this
particular
session,
security
folks
need
to
understand
the
systems
they're
dealing
with,
I
think
that's
a
hill
we're
willing
to
die
on
as
a
group
here
now
you
don't
have
to
be
a
you
know
some
sort
of
kind
of
graybeard
pearl
programmer
java
programmer
that
only
deals
with
you
know
the
ins
and
outs
of
the
application
every
day,
but
there
is
importance
in
giving
security
teams.
A
Autonomy
to
you
know,
use
these
systems
deployed
to
them
break
stuff.
I
mean
I've
broken.
I
took
down
a
third
of
giant
mobile
application,
car
buying
site
they're
they're
by
installing
a
security
tool
that
I
didn't
understand
well
enough
at
the
time
right
and
it
broke
everything.
We
lost
a
lot
of
money
this
was
years
ago,
and
that
was
on
me
but
like
how
else
are
you
going
to
learn
right?
So
I
think
that's.
That's
kind
of
the
closing
note
and
and
raj
and
jack
have
anything
else.
A
You
want
to
say
now's
the
time
because
we're
going
to
wrap
things
up.
B
I
would
say
you
do
things
to
change
your
philosophies
and
and
like
learn
new
philosophies,
I
don't
think
you
say
you
change
philosophy
and
then
do.
I
think
what
I
would
say
is
just
start
doing
just
as
a
security
leader
or
a
security
engineer,
so
your
leader
asks
people
to
build
something
and
deploy
something.
As
an
engineer
tell
your
manager,
hey,
I
want
to
build
something,
deploy
something
see
how
it
feels
and
then
see
what
happens.
C
Well,
from
the
security
engineers
side
embrace
embrace
the
way
your
developers
are
working
because
that's
the
way
the
whole
organization
should
be
working,
the
accountability,
the
auditing,
the
understanding,
all
aspects
of
of
the
application,
not
just
the
application
itself,
but
the
infrastructure
as
well.
It's
all
required
for
for
these
applications
to
work,
and
nobody
should
be
in
a
silo
anymore,
yeah
sure
everybody
has
their
areas
of
expertise,
I'm
not
going
to
start
developing
code,
but
I
should
understand
by
looking
at
what
it's
doing.
C
A
On
that
note,
cooper's
gonna
close
out
the
session
and
thank
you
all
for
coming
and
bearing
with
the
technical
difficulties
we
appreciate
being
here
and
check
us
out
at
ksoc.com
or
you
can
find
any
of
the
fine
folks
here,
maybe
not
on
twitter.
I
don't
know
if
jack's
there,
but
you
can
find
them
somewhere
on
the
internet.
My.