►
Description
Implementing security into your software development cycle can no longer fall to the wayside. What does work really look like when we add security to all parts of a project? Join GitHub Enterprise Sales Manager Elio Gambetta and GitHub Field Security Specialist Nick Liffen as they facilitate an interactive discussion with attendees on why security is essential for enterprises. You’ll leave this session with your questions answered and an understanding of which data and tools help prioritize developer-first security.
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
B
B
B
B
F
A
So
this
is
gonna,
be
interesting,
isn't
it
you
know
how
to
help
developers
prototype
securing
their
software
development.
Terribly
important
topic.
You
know
go
to
the
days
where
you
can
just
willfully
not
worry
about
putting
usernames
and
passwords
into
code
and
yeah.
It's
gonna
be
fine,
real,
real
kind
of
big
important
topic,
so
it
should
be
a
very
interesting
session.
B
Yeah,
I
think,
for
so
long.
Security
has
been
like
a
second-class
citizen
in
the
software
development
model
and
like
developers,
they
haven't
always
resisted
security,
but
it's
always
been
something
which
has
been
it
causes
friction.
So
I
think,
like
the
topic
of
today,
is
to
help
how
to
help
encourage
developers
to
actually
prioritize
security,
so
I
think
won't
get
into
too
much
now,
but
there's
hopefully,
some
golden
nuggets
that
people
are
going
to
be
able
to
take
to
take
away
to,
hopefully
help
developers
be
a
bit
more
mindful
and
when
it
comes
to
security,
yeah.
A
And
we'll
say
it
again
in
a
moment
when
we
actually
kick
off,
but
please
make
sure
you.
This
is
an
interactive
session.
We
want
you
to
ask
questions
in
the
chat
press.
The
button,
if
you
want
to
join
us
on
stage
to
ask
your
question,
write
it
in
the
chat
press,
the
button,
so
you
want
to
join.
We
do
want
this
to
be
interactive.
We
have
some
polls
that
we'll
be
doing
to
kind
of
ask
for
your
opinion
and
your
answers
and
your
thoughts
on
things
so
yeah.
A
A
B
A
A
So
nick,
let's
kick
off
welcome
everyone
to
day
two
of
in
focus.
It's
the
last
session
of
the
day
where
we
are
prioritizing
on
security
and
we've
had
other
interesting
topics
yesterday
and
and
tomorrow,
but
today
has
all
been
about
security,
and
this
session
is
going
to
be
how
to
help
developers
prioritize
security
in
software
development,
I'm
melio,
gambetta,
look
up
the
enterprise
accounts
and
public
sector
out
of
the
uk,
and
my
co-host
nick.
B
Yeah
I'll
just
do
a
quick
introduction,
so
my
name
is
nick.
I
am
one
of
the
sort
of
like
field
security
architects
here
at
github,
so
really
focusing
on
one
of
our
solutions
called
github,
advanced
security.
So
super
excited
for
this.
For
this
conversation
today,
I'm
really
hoping
that
you
find
find
it
useful
too.
A
Excellent
and
as
we've
said,
please
ask
questions
in
the
chat.
Please
raise
your
hand
and
there
will
be
polls
that
will
come
up.
That
you'll
be
selecting
your
answers
in
this
area
of
the
screen.
I
am
mirrored
so
I'm
pointed
the
wrong
way
when
I
look
at
myself,
but
that's
where
you
should
be
seeing
them
and
if
you
want
to
request
a
demo.
Please
also
do
so.
There's
the
button
at
the
top
there
to
do
that.
A
B
B
I
I
absolutely
started
as
a
developer
still
do
the
software
development
today,
if
you
check
out
my
my
github
nick
gliffin
you'll,
be
able
to
see
see
some
of
the
developments
so
not
not
not
per
se,
fully
focused,
but
I'm
absolutely
still
doing
doing
development.
So
hopefully
I
will
be
able
to
relate
and
you
will
hopefully
be
able
to
relate
to
to
the
conversation
today.
I
think.
A
B
B
One
because,
like
did
you
set
time
in
your
sprint,
for
you
to
be
able
to
actually
fix
this
vulnerability,
and
one
of
the
biggest
problems
that
we
see
today
is
to
like
developers
actually
don't
have
the
time,
and
they
don't
have
the
ownership
from
management
from
leadership
to
actually
say
hey
as
part
of
your
sprint.
You
have
some
time
to
actually
set,
let's
set
aside
to
fix
in
whatever
alerts
or
problems
come
out
in
in
these
security
tooling.
So
I
think
like
to
write
secure
software
as
a
developer.
B
One
of
my
first
things
that
comes
to
mind
is
it's
the
capability
and
enablement
to
be
like
to
be
able
to
actually
have
the
time
to
fix
these.
These
alerts
because
it
can
sometimes
feel
like
developers,
are
very
rushed,
and
I
think,
for
me,
one
of
the
key
foundations
is
whether
you
work
in
agile
or
whenever
you
work.
However,
you
work,
you
enable
your
developers
to
have
the
time
to
say
that
if
a
vulnerability
comes
up,
they
maybe
don't
understand
or
maybe
have
to
learn,
they
have
the
underlying
characteristics
to
be
able
to
say
yep.
B
I
I
have
the
time
and
like-
and
I
have
the
stories
dedicated
in
my
sprint
to
be
able
to
actually
fix
it.
So
I
think,
like
that's
one
of
the
first
things
that
comes
to
mind
at
least
like
for
life
for
me
and
when
I
was
a
developer
and
when
I've
worked
in
in
software
projects.
I
think
the
first
thing
is
really
focused
on
making
sure
that
you
have
the
foundations,
elliot
keem,
keen
to
get
your
thoughts
on
that
yeah.
A
A
You
know,
you
know,
coding
in
an
agile
manner,
sometimes
means
that
you
will
start
with
a
little
demonstrator
that
you
kind
of
mock
up
quite
quickly
to
kind
of
see
if
it's
working
in
the
way
you
expect
and
I'm
guessing
one
of
the
challenges
is
that
sometimes
in
those
quick
sprints
and
the
kind
of
the
quick,
let's
get
something
done
to
see.
If
it's
right,
you
may
cut
some
corners
and
I'm
guessing
that
over
time
they
then
get
forgotten
about
and
they
come
and
bite
you
on
the
rear.
At
some
point
in
the
future.
B
Yeah-
and
I
think
like
like
someone
asked
a
great
question
in
the
in
the
chat
saying:
is
it
delegating
the
security
of
software
to
the
end
developer,
that
the
the
the
best
experience
and
and
and
and
the
best
approach
are
in?
I
think
we're
gonna
answer
that
in
one
of
our
our
sort
of
topics
and
slides
coming
up
later,
because
I
think
like
up
front,
the
answer
is
yes
like
up
front,
I
think
everyone
was
like
yeah
like
we're.
B
D
B
A
And
I
guess
an
important
point,
for
that
is
that
developers
have
to
have
the
tools
at
their
disposal
to
allow
them
to
kind
of
operate
in
a
secure
fashion,
and
it
is
still
their
responsibility
to
make
sure
they
utilize
them
not
bypass
them.
And
to
be
aware
that
you
know
as
part
of
general
coding
practices,
you
are
making
sure
that
you're
validating
before
you're
doing
database
updates
and
all
that
kind
of
stuff
yeah.
But
there
are
kind
of
the
softer
side
of
things
as
well.
B
D
B
Summarize
the
answer
of
of
this
question
here,
so,
I
think,
like
a
lot
of
it,
comes
down
to
tools.
Tools
are
great
tools,
are
a
mechanism,
but
if
you
don't
lay
down
the
right
cultures
and
processes
behind
it,
are
you
foundationally
going
to
be
in
the
right
place
to
even
start
adopting
these
tools?
And
I
think
that's
where
trust
and
autonomy
really
come
into
play?
I
think,
like
one
of
my
answers
again
to
this
question
around
what
does
it
mean
to
even
write,
secure
software
as
a
developer?
B
It
means
you
have
the
the
the
trust
from
the
security
person
and
the
security
organization
that
you,
what
decisions
you
make
are
in
the
best
interest
of
the
company,
and
you
don't
have
someone
always
looking
over
your
shoulder,
like
you,
feel,
autonomous
and
empowered
to
be
able
to
make
good
security
decisions,
because
one
of
the
hardest
things
that
that
we
see
especially
for
developers
is
security,
has
always
been
a
very
security
organization
and
it's
always
been
very
security.
Driven
now.
B
Years
we've
seen
that
become
more
developer,
focused
right,
that's
something
which
has
been
like
huge
as
just
shift
left
has
happened.
I
think
the
companies
that
have
done
this
well
have
laid
the
foundations
to
say,
like
developers
like
you
have
our
trust
like.
Yes,
we're
going
to
verify
what
you
what
you've
done
is
in
the
best
interest
of
the
company,
but
we
trust
you
like
we're
we're
going
to
provide
automation,
we're
going
to
give
you
the
tools
and
the
capabilities
to
run
this.
C
B
This
makes
it
hard
for
developers
to
prioritize
security
again,
going
back
to
one
of
my
first
points
of
they're
working
in
these
sprints.
They
have
all
these
user
stories
and
they
come
up.
They
come
across
a
pull
request
that
gets
blocked
purely
because
there's
a
security
bomb
ability.
Well,
if
there's
friction,
we're
going
to
take
one
or
two
days
to
get
the
data
and
then
there's
friction
to
go
ahead
and
fix
it.
A
So
maybe
that's
an
interesting
thing
that
people
can,
you
know
either
raise
their
hand
or
put
a
comment
into
the
chat.
Are
people
seeing
more
or
less
kind
of
code
reviews
being
done
by
other
developers
to
kind
of
validate
the
code
that's
been
written?
Is
that
something
that's
happening
more
so
or
less
so
these
days.
B
Yeah
like
like,
and
I
I
think
that
there's
like
that
second
support
to
bottom
point:
devs
also
need
to
know
where
they
can
go
for
help.
That
is
such
a
good
topic
and,
like
I'm
sure
we
we
can
likely
dive
into
that.
But,
like
what
you
traditionally
see,
is
you
have
these
security
tools
that
are
fantastic,
letting
you
know
what
a
vulnerability
is,
but
they
often
don't
tell
you
how
to
fix
that
vulnerability
and.
F
B
Every
vulnerability
like
I
wouldn't
know
how
to
fix
every
volume
vision
like
and
then
the
tool
even
needs
to
be
able
to
give
you
very
language,
specific
examples
or
you
need
to
have
a
security
organization,
or
you
need
to
have
some
way
where
people
are
able
to
reach
out
to
other
developers
and
again
you're,
reducing
the
friction
in
ensuring
that
developers
can
find
who
they
need
to
talk
to.
So
I
think
fantastic
question
and
yeah
and
I
think,
like
people
are
obviously
doing
code
reviews
which,
which
is
great
fantastic.
B
A
So
who
said
it
was
me,
you
want
to
raise
your
hand,
come
on
stage
and
ask
the
question:
it's
all
about
you
know
is
delegating
security
of
software
to
the
end
developer,
the
best
approach,
great
to
kind
of
hear
what
your
thoughts
are
on
that
I
guess
you
know,
nick
as
a
lot
of
people
have
been
saying
unless
you're
really
a
security
expert,
you're,
very
aware
delegating
it
to
someone
that
isn't
necessarily
fully
aware.
Maybe
isn't
the
kind
of
the
safest
thing
to
do.
D
B
Hey
we
we,
we
don't
have
like
like,
have
had
that
knowledge
and
and
like
have
a
way
for
people
to
be
able
to
ask
questions
and
find
out
each
way,
and
I
think
maybe
one
one.
One
final
point
on
this
before
before
we
move
on
to
the
poll-
and
I
think
it
has
two-
it
has
two
sort
of
thumbs
up
is:
if
it
isn't
encouraged
by
management
code.
Reviews
are
not
going
to
be
taken
seriously
and.
B
Fantastic
point
and
I
think
like
as
developers,
this
is
something
which,
which
I
try
and
put
on
like
myself
like
if
I'm
writing
code,
and
maybe
management
in
a
prior
life,
hasn't
like
understood.
That's
where
you
as
a
developer
community
can
really
come
together
to
again
explain
the
value
and
again
there
are
some
great
articles
out
there.
Maybe
we
can.
We
can
link
to
a
few
in
the
chat,
but
I.
A
So
nick
one
of
the
things
that
we
hear
is
that
if
things
have
to
be
done
manually,
then
they
don't
get
done,
they
get
skipped,
they
get
kind
of
sidestepped.
So
automation
is
a
very,
very
key
part
to
ensuring
that
you
have
a
smooth
process.
So
let's
ask
everyone
we'll
be
doing
the
first
poll
on
that
side
of
the
screen.
Do
you
enable
developers
to
run
security
scans
autonomously.
B
A
B
B
A
B
A
So
rather
interestingly,
it
started
off
with
the
vast
majority
saying
yes
and
then,
as
the
rest
of
the
results
came
in
it
kind
of
more
evened
out
so
about
half
saying
that
they
do.
They
don't
need
to
contact
anyone.
It
is
autonomous,
but
quite
a
few
people
saying
no,
they
don't
and
some
people
say
I
guess
it
depends
in
the
scenario
you're
in
certain
maybe
areas
of
development
it
does
happen
and
others
it
doesn't
so
very
interested
if
anyone's
got
any
comments
about
that
nick.
B
Yeah,
I'd
love
to
get
again
for
the
people
that
that
put
know
there
like.
I
would
love
to
maybe
and
then
for
the
people
that
put
yes
like
like.
If
you
feel
comfortable
like
you,
can
click
like
the
raise
raise
a
hand
button
and
come
on
to
stage
like
I
think
that
would
be.
That
would
be
a
fantastic
way
just
just
to
get
get
people's
thoughts.
A
B
B
B
B
I
think,
like
one
of
the
best
phrases
that
I
that
that
I
have
seen
is
this,
so
this
is
a
quote
which,
which
I
got-
and
I
think
it
sums
it
up
perfectly
like
no
single
person
or
or
like
or
organization,
is
responsible.
It's
responsible
of
everyone,
and
that's
why
or
like
autonomous
and
trust
is
so
so
important,
because,
like
the
more
that,
you
try
and
would
like
like
reduce
people
to
be
able
to
run
security
scans
themselves,.
B
And
I
I
hope
this-
this
person
provokes
a
lot
of
conversation.
There's
been
some
great
conversation
in
the
chat.
I
would
love
to
have
someone
come
on
stage
and
maybe
a
developer
who
uses
security
tooling
again
like
please
feel
free
just
to
click
the
the
razer
hand
button
and
come
on
stage,
because
this
is
something
which
is
really
important
to
me,
and
I
think
this
is
something
which
ensures
that
developers
are
going
to
prioritize
security.
So,
in
this
whole
shift
left
market.
B
What
we've
gone
ahead
and
done
is
we've
gone
ahead
and
taken
tools
and
we've
shifted
them
left
right
and
now
developers
are
doing
more
and
more
security,
but
when
we
think
about
what
that
has
actually
gone
ahead
and
done,
is
we've
gone
ahead
and
again
five
six
years
ago,
security
was
really
meant
for
security
people
right.
So
these
tools
are
really
meant
for
the
security
persona,
but
shift
left
happens
and
what
we
done
was
we
took
them
tools,
we
shifted
them
left
and
we
put
it
in
front
of
the
developer
and
said:
hey.
C
B
Luck,
we've
shifted,
left,
life
is
success,
life
is
brilliant
and
what
we
realize
is
companies
weren't,
getting
the
adoption
that
they
thought
and
going
back
to
what
I
mentioned
earlier.
Security
was
still
being
the
second
class
citizen,
and
one
of
the
biggest
reasons
being
is
developers
find
it
hard
to
use
tools
that
aren't
meant
for
them.
These.
B
Were
meant
for
security
personas,
and
I
think
one
of
the
biggest
problems
that
that
we've
seen
is
developers
find
it
hard
to
use.
There's
a
lot
of
friction
and
people
often
don't
think
about
the
experiences
that
these
tools
actually
cause
and
again
like
again,
as
I
mentioned
it
earlier
around,
these
talks,
like
totally
give
you
lots
of
information
about
what
the
vulnerability
is,
but
developers
really
want
information
around.
How
do
I
fix
this
vulnerability?
B
So
I
think
one
of
the
biggest
impacts
that
security
tooling
has
from
a
software
developer
standpoint
is.
It
creates
these
experiences
that
maybe
were
unknown
and
the
main
one
being
a
lot
of
these
tools,
weren't
meant
for
developers,
so
they
do
find
it
quite
quite
hard,
quite
hard
to
use
and
and
like
I
think
it
like.
It
would
be
like
I'd
love,
to
get
again
people's
thoughts,
because
that
was
one
of
the
biggest
shocks.
When
I
first
started
using
security
tooling
from
a
software
developer,
standpoint
was
like.
B
A
You
know
absolutely,
I
was
just
gonna
point
out
so
stephen
I
mean
you
know,
feel
free
to
raise
your
hand
and
come
on
stage.
You
know
you
talked
about
looking
to
do
security
scans
with
pull
requests,
but
equally
you've
said
that
you
can,
if
you're
new
to
the
journey,
so
it'll
be
interesting
to
understand
how
you're
finding
it
have.
You
got
the
right
information
to
learn
and
to
to
progress.
A
G
Can
you
hear
me
we
can
yeah,
so
I've
only
just
recently
started
looking
into
security
tools.
I
just
began
my
journey
by
just
reading
literature
on
google
scholars
and
everything.
So
that's
how
I've
begun.
I
work
for
groundwater,
a
company
that
prints
on
the
on
sunny
surfaces.
So
it's
a
new
style
company,
so
I'm
trying
to
introduce
security
tools
to
help
establish
us
yeah.
G
I
know
developers,
love
acronyms
but
like
you're,
seeing
sas
sas
teen
and
dust,
and
it's
really
confusing,
because
you
don't
really
know
what
particularly
which
tool
is
doing
for
what,
and
it
was
only
just
until
recently,
the
last
podcast
or
you
had
today
that
I
realized
that
sas
was
like
sql
injection.
So
there
is
still
a
lot
learning
gap,
but
I
feel
like
we
need
to
make
clearer.
A
And
yeah,
absolutely
I
mean
you
know:
education
awareness
is
is
very
often
one
of
the
key
things
to
helping
developers
be
aware
of
what
they're
doing
and
why
they
have
to
be
careful.
You
know,
for
example,
having
a
web
form
without
validating
your
data
inputs
and
then
potentially
updating
them
to
a
database
does
leave
you
very
vulnerable
to
sql
injection.
That
type
of
vulnerability
has
actually
been
around
for
for
years
and
years
and
years,
but
just
being
aware
of
the
things
to
protect
yourself
against
is
is
an
important
part
of
the
process.
B
B
Different
types
of
security
right,
there's
daz,
there's
sas,
there's
secret
scanning,
there's
like
sea
like
and
I
think
that's
a
really
that's
an
item
which
maybe
I
hadn't
considered,
but
I
think
for
people
that
are
new
to
security
like
what
one
should
you
run
like
like
like?
Where
do
you
go
to
find
it?
So
I
think
the
impact
is
greater
than
the
experience
of
the
tools
it
actually
comes
before
that
it
comes
around
actually
like
what
tooling
do
I
even
need
to
use.
A
F
B
Yeah,
that's
the
stuff,
I
think
fun
fantastic
points
I
think
like
I.
I
really
appreciate
you
sort
of
like
sharing
that
there
is
so
much
knowledge
out
there
finding.
It
is
probably
the
hardest
thing,
so
I
think
really
appreciate
you
sharing,
and
hopefully
people
in
the
chat
will
actually
like
take
take
that
link
down
and
hopefully
it
it
will
help
people
so
really
do
appreciate
you,
you
sharing
that.
A
Thank
you
guys,
yeah
thanks
a
lot.
John
gustav
you've
got
an
interesting
point
there.
You
say
that
you'd
rather
choose
a
skilled
developer.
You
know,
rather
than
he
saw
do
you
want
to
come
on
to
discuss
that
a
little
bit
more.
It's
a
big
challenge
as
organizations
try
and
expand
what
they
do
as
they
try
and
hire
more
developers.
You
know
sometimes
cost
constraints
aren't
easy
to
always
have
the
most
experience,
but
it'd
be
great
to
kind
of
hear
some
of
your
thoughts
on
that.
A
A
B
But
I
think
that's
why
we've
seen
a
lot
of
shift
to,
and
just
as
that
point
mentions
last
in
the
chat
we've
just
seen,
the
shift
in
the
market
being
like
man,
false
positives
suck-
and
I
think
like
that-
is
that
that's
sort
of
where
the
the
market
is
going
is
like
number
of
alerts
is
now
not
success.
The
results
are
now
are
now
really
the
success
and
the
quality
of
the
results.
B
Again,
if
you
have
a
tool
that
gives
you
a
thousand
results,
but
97
of
them
are
false,
positives,
you're,
going
to
lose
trust
in
the
tool
and
you're
no
longer
really
going
to
look
at
the
results,
and
that
is
sort
of
where
over
the
last
sort
of
like
especially
the
last
year.
A
lot
of
these
security
tokens
have
now
gone
and
said
we
would
rather
produce
less
results
that
are
a
lot
more
accurate
because
it
means
the
developer's
going
to
do
something
about
it.
B
So
again,
going
back
to
my
previous
example
like
you
could
have
a
tour
that
gives
you
a
thousand
alerts,
but
if
you
only
fix,
if
you
only
look
like
look
through
three
percent
you're
only
really
going
to
fix
a
few
of
them.
If
you
ever
told
me
if
you're
30
and
you
look
through
30,
you
are,
you
are
more
more
aware
and.
A
I
think
donna
makes
a
great
comment
there
in
the
title.
You
can't
join
us
on
stage
connor,
because
you're
making
lots
of
good
comments,
absolutely
the
more
kind
of
false
positives.
You
have
people
kind
of
go
like
you
know
what
this
is
just
noise.
It's
nonsense!
I
I
wouldn't
even
know
where
to
start
I'm
just
going
to
ignore
it.
A
I
just
want
to
say
darwin:
if
you're
gonna
join
us,
you
make
a
comment
there.
What
about
security
provided
by
github
isn't
sufficient?
I
mean
happy
to
you
to
come
on
stage
press
the
button
and
just
kind
of
see
what
you
mean
there,
because
there
is
a
lot
of
tooling
that
we
provide
that
others
provide
security,
sometimes
can
be
a
bit
of
an
arms
race.
I
mean
I've.
I've
seen
things
in
the
past
where
I've
spoke
to
an
organization
and
they've
seen.
Oh
sorry,
you
can't.
Okay,
that's
shame
but
yeah.
A
It's
good
good
comment
there
in
the
chat
and
they're
preventing
something
happening
and
they've
blocked
something
happening,
and
then
within
a
week
or
so
you
know
whether
it
was
a
kind
of
a
particular
type
of
attack.
They've
noticed
that
they
were
being
spotted
and
monitored
and
they've
changed
the
attack
vector.
So
it
is
a
bit
of
an
arms
race.
A
It's
not
always
about
kind
of
trying
to
pare
down
the
number
of
tools,
but
making
sure
you
have
sufficient
coverage,
and
you
know
there
will
be
overlap
from
one
tool
to
the
next,
but
the
best
solution
is
often
to
have
as
complete
coverage
with
many
lenses
on
the
problem
that
you
can
have.
But
yes,
nick,
let's
go
to
the
next
poll.
A
Yeah
I
mean
how
many
security
tools
do
your
developers
use.
So
is
it
one
or
two?
Is
it
10
or
20?
Is
it
you
don't
know
because
you
don't
know
what
tools
are
available
to
you,
because
sometimes
you
use
them.
Sometimes
you
don't
so
it'll
be
interesting
to
know
from
a
developer
standpoint
across
many
different
organizations.
B
Yes-
and
I
think
th
this
one,
I
am
because
I
think
we
we
like,
we
should
see
a
a
varied
number
here
and
the
answers
are
like.
I
think
this
is
gonna
like
hopefully
like
get
people
thinking,
because
I
think,
like
we're,
gonna
see
a
range.
I've,
hopefully
arranged
between
none
and
like,
unlike
and
and
multiple
so
and
tallinn
is
often
kind
of
like
companies
rely
on
tallinn,
a
lot
more
than
they
should.
Maybe
talking
is
a
great
way
of
getting
there,
but
I'm
super
excited
to
see
the
the
outcome
of.
A
B
A
So
yeah
I
mean
if
anyone
wants
to
kind
of
come
on
stage.
Azan
you've
got
a
great
comment
in
there
used
to
also
make
a
good
comment.
If
someone
wants
to
join
us
and
and
say
what
you
have
seen
in
your
organization
about
some
of
the
challenges,
why
they're
having
no
tools
or
having
just
too
many,
it
would
be
great
to
hear
you.
D
B
C
C
B
B
H
H
So
there's
somebody
having
me
in
the
background
yeah.
One
of
the
main
things
is
just
that
we
have
quite
a
big
drive
for,
like
new
features,
etc
that
things
such
as
even
bug
fixing
it
very
much
takes
a
backstage
over
implementing
what
our
customers
want
and
supporting
them
in
the
usage
of
the
software,
and
I
think
in
the
three
months
I've
been
at
this
company.
I've
only
seen
we
use
agile,
so
I've
only
seen
really
one
or
two
security
related
tickets
and
those
are
both.
A
H
H
G
A
C
Right
I'd
like
to
address
daniel's
question
there
he's
saying
all
the
tools
have
a
severity
rating
and
why
don't
developers
understand
what
they
need
to
fix.
In
our
case,
we
had
a
private
network
and
the
open
channel
and
we
didn't
know
the
systems
engineers
knew
like
we
knew,
but
the
developers
didn't
know
and
that's
why
devsecops
is
a
an
amalgamation
of
everything
and
we
knew
what
sort
of
problems
could
arise
in
that
system,
but
not
in
the
code.
C
F
C
A
B
And
I
just
want
to
like
one
one.
I
know
that
we
need
to
move
on
one
massive
shout
out
to
that
comment
at
the
moment,
and
hopefully
we
can
get
you
on
stage
on
on
the
next
section
fantastic
comment,
I
I
I
think
that
definitely
sums
it
up
nicely,
and
so
hopefully
we
can
absolutely
get
you
on
stage.
The
way
that
I
like
to
frame
up
just
final
point
on
on
tooling
tooling,
is
important.
The
experiences
they
they
create
is
so
much
more
important
and
the
way.
B
This,
if
you
went
for
surgery
tomorrow,
you
would
want
your
surgeon
to
use
tools
and
apparatus
that
were
meant
for
a
surgeon.
I
think,
as
we
start
to
think
about,
like
developers
like,
I
think
that
sums
it
up
so
perfect
like
did
like
you,
would
want
your
developers
to
use
tournaments
that
are
meant
for
developers
too.
You
wouldn't
want
your
search
interviews
and
tools
that
are
meant
for
someone
else.
You
wouldn't
get
a
good
success.
H
B
B
A
Well,
this
kind
of
brings
it
really
to
a
head
in
terms
of
the
discussions
around
the
tooling,
and
should
it
be
the
developer
and
kind
of
so
where
does
this
all
live?
Where
does
it
kind
of
where'd?
The
bucks
somewhat
stop,
you
know
what
should
the
developers
be
responsible
when
it
comes
to
application
security
nick?
Do
they
own
it
all?
Do
they
rely
on
the
tools?
Where
do
we?
Where
do
we
sit
with
this.
B
Yeah
and
again,
please
like
like,
like
developers
or
or
or
people
in
this
call
like
I
would
love
love
to
get
your
thought
so
one
of
the
biggest
things
which-
and
this
probably
this
aggravates
me
from
a
dev
standpoint-
is
when
someone
says
okay,
you're
responsible
for
all
security
on
this
out
on
this,
like
appalachian,
fix
everything
and
you're
like
but
like
what
should
I
fix
first
like
do
I
do
my
sales
scan?
Do
I
do
dad
do
I
need
to
look
at
data
from
across
everything
like
what
about
a
junior
day?
B
It
so
goes
untalked
about,
and
it
so
goes
missed
and
it's
like,
and
it's
probably
as
important
like
as
the
culture
conversation
that
we
spoke
about
earlier,
and
that's
why
like
like-
and
this
is
where,
like
my
thoughts
on
this
and
again,
I
would
love
love
to
get
other
people's
thoughts.
It's
like,
like
the
responsibility,
can't
be
like
everything
all
at
once,
like
responsibility,
you
need
to
almost
think
of
it
like
a
matrix
around
like.
Are
you
a
junior?
Are
you
a
senior?
What
role
do
you
have,
but
also
like
like?
B
A
So
nick
there's
been
some
great
comments
and
connor.
Thanks
for
your
comments
there
as
well
show
you
can't
join
us.
You
know
it's
a
bit
like
giving
a
new
driver
that
just
passed
their
driving
test
the
ferrari.
The
outcome
is
likely
to
be
expensive
and
damaging.
So
you
know
as
part
of
the
way
organizations
organize
themselves.
Maybe
this
is
also
more
of
a
management
and
a
senior
developer
responsibility
to
help
guide
how
this
should
be
done,
because,
quite
rightly,
how
would
a
junior
developer
know
how
to
prioritize?
B
So
you
start
very
specific
and
you
get
teams
used
to
using
a
used
to
using
a,
and
I
think
lars
might
look
like
again.
Hopefully,
I'm
saying
that
right,
you,
some
are
very
very
nicely
to
that
point
like
birth,
is
just
blaming
something
someone
for
saying
just
fix
out
like
everything
you
start
in
these
incremental
sort
of
like
a
phased
approach
when
it
comes
to
a
per
se
security.
Adoption.
A
So
nick
it
does
sound
like
policies
of
an
important
thing
to
help
provide
guidance
if
you've
got
a
good
set
of
policies
that
are
well
thought
out,
they
can
guide
people
that
are
less
less
less
experienced.
We
have
15
minutes
to
go.
We
have
one
more
poll
to
do.
Let's
switch
to
that
just
to
see
people's
thoughts.
B
B
I
am
very
hoping
that
that
that
people
pick
a
varied
number
of
answers
and
there's
one
that
I
have
my
answer
to,
but
really
keen
to
get
up
to
get
other
people's
answer
to
to
this
poll
too,
because
the
others
have
been
very.
This
is
how
how
we
do
it.
This
is
very
much
now
focused
on
like
what
what
people's
thought
thought
thoughts
are.
A
F
B
Now
maybe
elliot
mean
you
could
can
can
give
our
answers
and
people
in
the
chat
too.
My
answer
is
actually
a
little
bit
of
the
bottom
two
like
it's,
a
combination
of
probably
older
than
fruit,
free
things
and
so
much
more
like,
but
not
more
from
a
they
need
to
do
like
do
more,
but
it's
more
from
like
a
planned
approach.
So
I
would
have
put
my
answer
between
is
a
combination
of
above,
but
like
it's
just
a
a
foundation
in
into
the
oven.
B
I
think
there's
a
comment
on
on
the
bottom
around
like
nothing
needing
to
be
fixed.
A
lot
of
companies.
Take
that
approach
like
a
lot
of
companies
say
for
the
first
two
or
three
months,
don't
fix
anything
just
get
used
to
using
the
tool
like
just
get
used
to
using
the
like.
Is
it
the
right
tool
for
us
and
they
will
say,
there's
no
mandate,
there's
no
enforcement
to
fix
anything
just
get
used
to
the
experience
and
and
they're
the
companies
that
we
see
12
months
down
down
the
line
actually
get
that
high.
A
A
So
I
think
really
the
thing
with
this
poll
was
trying
to
kind
of
gauge
what
people's
thoughts
were.
I
mean
the
reality
is,
is
that
you
don't
want
to
introduce
new
vulnerabilities,
but
that
often
happens
when
you
maybe
are
bringing
new
third-party
modules
into
the
code
you're
needing
to
expand
a
certain
capability.
A
You
found
a
module
that
does
it
you
bring
it
in
bang.
You
have
a
whole
new
series
of
vulnerabilities
and
equally
there
may
be
some
some
vulnerabilities
that
you
have
not
got
the
ability
to
mitigate,
because
you
are
reliant
on
that
particular
module
because
of
a
piece
of
infrastructure
that
requires
it
to
be
at
that
version,
and
you
have
other
dependencies
that
are
needed
to
be
met
before
you
can
upgrade.
B
B
To
the
12
factor
up
yeah
from
a
for
a
way
of
building
the
twelve
five
has
now
probably
been
around
for
ten
ten
twelve
years
now
and
even
today
it
is
absolutely
still
still
still
relevant.
So,
yes,
I
think
if
people
haven't
heard
of
the
12
factor
app,
it's
a
fantastic
mechanism
and
to
at
least
learn
the
foundations
of
almost
building
blocks
of
good
architectural
design.
A
I
tell
you
what
someone
could
put
a
link
in
and
share
it
in
the
chat,
that'd
be
even
better
there.
You
go
brilliant.
Thank
you!
Nick!
Do
you
want
to
put
up
one
of
our
last
slides
because
we
we'll
hold
it
up
there
and
we'll
we'll
run
for
the
last
six
seven
minutes
with
q,
a
yeah,
so
just
that's
able
to
join
us
on
stage
more
than
happy.
B
D
Sure,
because
I
I
totally
piggybacked
on
good
stuff,
I
have
nothing
original,
no
hi.
My
name
is
mina
yeah.
I
I
must
say
that
you
know
application
security.
Wasn't
really
a
big
thing
for
me
for
a
while,
and
that's
just
because
of
you
know
a
function
of
where
I
worked
and
people
I
worked
with,
but
in
taking
responsibility
for
my
career,
I've
realized
that
you
know
I.
I
can't
expect
anybody
to
secure
my
shitty
code.
D
To
be
blunt,
so
I
you
know,
I'm
not
like
I'm
not
really
amazing
at
application
security,
but
you
know
it's
it's
all
about
improvement
and
I
definitely
agree.
I
think
the
12-factor
app
is
is
useful
for
anybody
at
any
point
in
their
career,
because
otherwise
it's
easy
to
build.
You
know
monoliths
and
you
end
up
building.
I
can't
even
say
you
write
bad
code.
You
just
write
code
that
you
know
you
just
haven't
thought
about
it.
D
I
think
good
code
is
intentional
code
and
I
think
that
when
it
comes
to
application
security,
the
worst
thing
is
when
a
bug
comes
up
in
like
staging
or
even
worse,
in
production,
and
it's
been
missed
because
you
know
the
usual
stuff
you
maybe
you
know,
I
signed
off
a
pr,
but
I
I
I
didn't
test
it
properly.
You
know
I
didn't
look
for
edge
cases
or
I
didn't
really
kind
of
poke
holes
in
something
or
that
I
just
was
too
trusting
of
the
person
who
wrote
I'm
like
oh
yeah.
D
He
knows
what
he's
doing
he'll
be
fine,
it
won't
break
in
production
and
you
know,
make
us
sit
back.
You
know
sit
in
the
office
on
a
friday
past.
You
know
5
p.m.
You
know,
so
I
think
that
very,
very
I'm
gonna
wrap
up
here,
but
what
has
really
helped
me
in
my
career,
the
past
I'd
say
four
months
five
months.
D
Even
is
this
idea
that
it's
in
a
ted
talk
and
I'll
link
to
it
in
the
chat
called
extreme
ownership
by
yacht
something
I
can't
I'll
get
his
name,
but
it's
this
idea
that
you
know
I
take
ownership
for
everything,
even
when
it
should
be
perhaps
somebody
else's,
but
because
the
code
is
it
is
you
know
it's
got
my
name
on
it
in
the
commit
signature,
I'm
I'm
ultimately
responsible.
I
can't
be
like.
D
A
E
Well,
I
I
think
that
it's,
it's
quite
simple,
that
the
developers
they
build
the
app
they
are,
the
ones
who
knows
it,
ins
and
outs,
the
more
that
we
can
empower
them
to
think
about
security
in
a
good
way
better.
It
is-
and
we
have
loads
of
examples
where
we
teach
developers
at
ikea
to
do
threat
modeling
and
they
threat
model
something
before
they
build
it,
which
means
that
they
don't
build
a
risky.
You
know
api
interface
or
whatever
to
expose.
E
You
know,
god
forbid
our
customer
data
and
if
they
don't
build
it,
we
don't
have
businesses
processes
around
it,
which
would
become
a
lot
of
problems
to
remove
so
wherever
we
can
empower
our
developers
to
make
them
think
critically
about
what
they're
building
that's
when
we
get
a
lot
of
things
and
we
can't
scale
security
by
just
adding
more
security
engineers,
we
need
skills
engineer
from
the
from
the
get
go
so
yeah.
I
think
that's
you
know
and
tools,
tools
help,
but
you
know
having
skill
developers.
That's
number
one.
A
The
at
the
end
of
the
day,
the
best
tools
on
the
planet
are
only
as
good
as
the
people
that
are
using
them
exactly
thanks.
Everyone
for
coming
on
stage
with
us
thanks
everyone
that's
come
on
stage
today,
it's
all
about
being
interactive
and
about
discussing
things
and
talking
things
through
nick.
If
we
just
put
up
the
slide
with
the
key
takeaways
and
also
the
survey.
B
So
again,
like
we're
not
gonna,
there
are
there's
so
many
more
key
takeaways
that
we've
spoke
about
that
didn't
even
get
into
these
key
takeaways.
So
I
think
the
key
takeaways
that
I
wanted
people
to
take
away,
and
maybe
not
what
you
see
on
this
slide
deck,
because
the
conversation
was
was
was
so
good.
So
I
think,
like
these
are
probably
the
four
examples
that
I
would
say
to
take
away.
A
Perfect,
thank
you,
everyone.
Let
us
know
what
you
think.
It's
very
very
important
to
ask
that
we
get
feedback
on
these
sessions.
If
you
want
me
to
wear
a
blue
t-shirt
next
time,
then
say
it
in
the
comments.
We
really
genuinely
would
love
to
hear
what
you
think
is
the
format
right.
Did
we
cover
the
right
topics?
Are
there
other
topics
that
you
want
to
cover
us
to
cover
in
future?
Did
we
go
to
technical?
Did
we
not
go
technical
enough?
Please,
please.
A
Your
feedback
is
important
to
us
scan
the
qr
code.
If
you
want
to
request
a
demo,
I've
now
got
this
right
point:
the
opposite
direction.
Click
the
request,
a
button
demo,
but
thank
you
everyone
for
participating.
It's
been
a
pleasure
to
talk
to
you
all.
If
there
are
any
last-minute
questions
in
the
chat
that
we
can
address,
we
more
than
we'll
do,
and
there
is
always
tomorrow,
won't
be
half's
called
it
is
today
was
nick
and
I
are
not
presenting
the
only
joke.
Of
course
it'd
be
brilliant.