►
Description
#demodays #GitHub
1:20 - Welcome everyone!
11:39 - Let's talk DevOps and DevSecOps
DevSecOps, shifting left, and GitOps: you’ve probably heard all of these terms recently, but you might not be sure about what they mean. The reality is that these practices share a lot of the same principles—to reduce the time developers need to spend on security, while achieving better outcomes. And who doesn’t want that? Let’s clear up some confusion and deconstruct what these terms mean, and how they apply to your security and development teams.
Thomas Hughes, Senior DevOps Engineer, talks through key DevOps concepts and how it isn't just about tooling.
Resources:
Resource Round-up: https://github.com/learn/devops/#resources
Myths and Misconceptions: https://github.blog/2020-10-07-devops-definition/
Guide to DevSecOps: https://github.blog/2020-08-13-secure-at-every-step-a-guide-to-devsecops-shifting-left-and-gitops/
Contact us: https://enterprise.github.com/contact
A
Hello,
everyone
wow
chat
is
busy.
Today
looks
like
a
bunch
of
you
have
found
us
hi,
hi
wow,
amazing,
welcome
to
the
season
finale
of
demo
days,
trying
some
different
things
today.
Typically,
this
is
a
stream
that
is
only
on
twitch,
but,
as
some
of
you
have
noticed,
we
are
somewhere
else
today
too
nice
to
see
all
of
our
twitch
regulars
joining
us
today
and
also
nice
to
see
all
of
our
new
friends
super
excited.
A
A
I
see
so
many
cool
folks
and
yes,
definitely
benjamin
it
is
almost
the
weekend
and
for
those
of
us
in
the
us,
it's
also
going
to
be
perhaps
an
even
longer
weekend
with
a
holiday
coming
up
yeah,
so
relax
grab
a
tasty
beverage,
hello
from
the
ukraine.
I
see
people
from
the
ukraine
if
anyone
happened
to
join
us
for
the
international
community
events
that
we've
been
holding
recently.
Let
me
know
too,
I
see
brazil.
I
see
austria
wow
amazing.
A
A
A
If
we
can
actually
help
you
with
something
specific
that
you
need
help
with
all
right,
so
to
get
to
what
we're
actually
going
to
be
doing
today,
we
are
going
to
be
talking
about
what
is
devops
and
what
is
devsecops
right
and
thomas
is
going
to
join
me
really
soon
and
take
you
through
an
amazing
demo
and
talk
about
like
what
is
this
concept?
How
do
I
get
started
with
it?
How
do
I
understand
it?
You
know
what
are
the?
A
What
are
the
tools
that
I
need
to
to
get
started,
so
I'm
super
excited
that
we've
got
such
a
global
audience
today.
Mexico
is
in
the
house
as
well.
I
see
ghana
here
right
now
and
given
the
timing,
you
know
good
morning
good
afternoon,
good
evening,
good
night,
this
is
pretty
serious.
I
I
see
someone
saying
that
there's
a
little
bit
of
echo
and
I'll
fix
that
shortly,
but
for
the
moment
just
hang
out
listen
to
music.
Let
me
know
what
you'd
like
to
see
all
right.
A
I've
got
a
question
here,
this
hoodie
yeah.
Unfortunately,
it's
it's
kind
of
special.
It
is
a
fun
hoodie
and
unfortunately
it
is
not
available.
Sorry
gotta
gotta
keep
the
the
drip
tight,
keep
the
keep
the
swag
on
lockdown,
but
there
is
plenty
of
swag
that
you
can
get.
All
you
have
to
do.
Is
google
github
shop
and
you'll
be
able
to
see
what's
going
on
there
all
right.
A
I
really
want
to
go.
We've
had
some
events
in
brazil,
like
even
virtual
events
recently,
so
keep
an
eye
on
that.
We
have
a
meetup
group
for
it.
You
can
check
things
out
and
we
have
events
in
brazil
held
in
brazilian
portuguese.
Just
for
you.
So
hopefully
I'll
see
you
there,
but
in
the
future,
we'd
love
to
go
there
in
real
life
and
that's
when
things
will
definitely
get
exciting.
A
A
A
Oh
me,
I
am
from
san
francisco
and
so
I'm
holding
it
down
pretty
close
to
where
github
started.
But
you
know
the
even
my
team
is
globally
distributed
if
you've
ever
seen,
mish
manor's
stream
on
twitch.
She
is
my
colleague
we're
on
the
same
team
and
she's
in
australia
if
you've
ever
seen,
koran
stream
as
well.
He
is
my
colleague
in
india.
My
boss
is
martin
and
he
is
in
northern
ireland.
We've
also
got
paul
in
seattle
and
anisha
in
also
in
seattle.
A
A
I
think
I'm
gonna
kill
the
music
and
thank
you
everyone
for
the
compliments
on
music
and
I'm
also
going
to
switch
my
mic,
because
you
know
just
the
way
the
stack
is
you
gotta.
You
gotta
make
things
just
right
and
there's
that
thanks
for
bearing
with
me,
this
is
all
brand
new
stuff
that
we're
trying
and
I'm
gonna
bring
on
thomas
who
is
going
to
be
our
host
for
today.
Well,
I
guess
I
am
the
host,
but
thomas
is
going
to
do
the
demo
and
talk
about
dev,
devops
and
devsecops,
hey
thomas.
What's
up.
B
A
Yeah,
it
was
funny
like
thomas
and
I
were
just
talking
yesterday
about,
like
you
know,
it's
it's
going
into
a
holiday
over
here
in
in
the
u.s
and
it's
getting
later
into
the
month.
I'm
I'm
pretty
sure
it's
going
to
be
a
quiet
demo
day
stream
today
and
I
was
absolutely
wrong
like
this
is
incredible.
It's
awesome
to
see
everyone
here
and
I
really
hope
that
you
enjoy
what
thomas
has
brought
for
us
today
and,
like
I
said
earlier,
tell
me
what
you
need
to
know
about
about
github.
A
B
B
B
Cool
okay,
well,
everyone
thanks
for
coming
out,
like
aj,
said,
there's
way
more
people
showing
up
than
we
initially
thought
here.
So
pretty
excited
about
that.
I'm
thomas
hughes,
I'm
a
devops
engineer
with
github
and
been
here
about
three
years
now.
I
just
mentioned
it
a
minute
ago:
I'm
based
out
of
the
austin
texas
area
might
be
moving
soon,
not
too
sure
yet,
but
we'll
see
how
that
goes.
I've
seen
people
from
all
over
the
place
from
india,
the
uk
we
have
germany,
italy.
B
B
B
B
You
know
it's
kind
of
an
assumed
level
of
knowledge,
so
my
goal
with
this
is
to
kind
of
give
that
rough
idea
of
what
devops
is
as
a
whole
and
then
now
the
newer
thing
that's
been
coming
out
in
the
last
few
years
is
devsecops
movement
and
how
does
that
look?
And
basically,
what
that
has
to
do
with
our
software
development
life
cycles
or
the
sdlc
that
you're
doing
and
how
that
kind
of
all
plays
together.
So
that
said,
let's
go
ahead
and
get
started.
So
again.
B
B
B
If
we
look
at
how
software
has
been
developed
over
time,
so
we're
going
to
start
with
just
kind
of
a
quick
story
of
kind
of
what
many
developers
looked
at
when
you
know
in
a
pre-devops
world,
as
well
as
what
security
teams
kind
of
looked
like
beforehand,
we're
going
to
talk
about
and
identify
some
of
the
problems
that
were
in
these
old
models,
which
spawned
kind
of
this
shifting
left
movement,
another
buzzword,
and
what
that
shifting
left
movement
is
how
it
solves
problems.
How
devops
comes
into
play?
B
What
is
that
devops
exactly
you
know?
What
does
security
do
when
we
add
security
to
devops
and
then
how
github's,
helping
with
this
too?
One
of
the
things
I'm
excited
about
at
the
end
is
just
I'm
going
to
give
it
just
a
few
pro
tips,
kind
of
like
roll
out
plan.
Ideas
of
of
you
know
hey.
This
is
how
you
can
start
implementing
devops
and
transform
your
own
organization,
so
that
all
said,
I'm
seeing
git
commands
and
everything
in
the
chat.
That's
great
hello
from
tunisia,
greece,
yeah
all
over.
B
You
know
you
have
these
same
basic
pieces
here
right.
So
we
have
a
code
piece.
We
have
some
type
of
testing
going
on.
We
have
deployment
sometimes
into
a
few
different
environments
and
in
this
case
on
this
screen,
I'm
showing
a
deployment
for
like
a
dev
qa
area,
a
pre-production
area
and
then
a
production
area,
and
the
key
part
that
I
want
to
call
out
here
is
this
is
how
a
development
looked
is
with
these
kind
of
barriers
between
these
different
processes.
B
So
a
lot
of
times
we
had
developers
that
were
working
solely
on
code
and,
of
course
there
were
front
end
developers
back
in
developers,
and
you
know
this
whole
full
stack
thing
was
kind
of
a
new
idea.
They
wanted
to
have
more
specialized
people
moving
into
you
know,
after
I
finish
my
coding
I'd,
send
it
to
a
dedicated
qa
team
often
and
that
qa
team
would
do
all
the
testing
oftentimes
very
manual.
You
know,
maybe
they
were
using
some
ui
test
tools
or
something
like
that.
B
But
you
know
it's:
it's
not
not
the
best
basically,
but
they
were
kind
of
in
their
own
little
silo
or
their
own
world,
and
they
would
say:
okay,
let
me
deploy
this
to
a
dev
environment
or
a
qa
environment.
I'm
gonna
go
ahead
and
run
some
additional
testing.
I'm
gonna
do
performance
testing
and
all
that
this
looks
good.
So
let
me
go
ahead
and
pass
it
to
the
operations
team.
Now
we
have
the
operations
team.
B
They
decide.
Okay,
we're
going
to
put
this
in
a
pre-production
environment,
so
we're
going
to
do
our
deployment
now
and
hopefully
everything's
working
along
this
process
here,
because
I
am
siloed
off
from
the
rest
of
this
team.
I
am
siloed
from
the
qa
people,
I'm
siloed
from
the
dev
team
right
and
now
operation
says:
okay,
we're
ready
to
finally
put
this
in
production,
we're
going
to
go
into
our
final
deployment,
we're
going
to
monitor
things
and
and
all
of
that
right,
so
pretty
straightforward.
B
You
know
this
process,
like
I
said,
is
something
that
you
still
do
today,
of
course,
in
more
modern
practices,
but
the
idea
is,
we
want
to
try
to
start
removing
those
barriers
between
the
teams.
So
where
do
we
look
at
from
or
where
do
we
come
from
on
the
security
side?
Instead
right,
so
security
kind
of
had
their
own
little
silo
thing
going
on
and
in
some
ways
it
was
even
worse.
B
Also
had
silos,
we
had
someone
that
would
do
manual
scanning
of
code,
someone
that
would
create
reports
based
off
of
you
know,
network
logs
or
something
like
that.
They
would
review
those
reports
and
maybe
that's
a
different
person
too,
and
then
we'd
have
some
configuration
or
policy
change.
We'd
have
a
policy
team,
we
have
a
configuration
team
and
all
of
these
things
would
be
separate
pieces
that
don't
really
work
well
together
because
of
the
nature
of
the
structure,
that's
been
on
the
teams
and
the
the
idea
or
concept
of
of
way
security
worked.
B
The
other
thing
is
all
of
this:
pretty
much
happened
after
the
code
was
in
production
right,
so
we
would
deploy
code
out
there
and
then
we'd
say:
oh
hey.
There
is
a
security
vulnerability.
We
got
to
take
care
of
that
now,
so
pretty
crazy,
right,
pretty
crazy,
so
you've
taken
a
quick
look
at
chat.
It's
moving
so
fast,
but
I
see
okay,
yeah,
more
people
from
warsaw,
bitbucket
rules-
bitbucket,
hey,
you
know,
teach
their
own
cool
all
right.
Well,
I'm
gonna
go
ahead
and
move
on
here.
B
I
don't
see
any
initial
questions
popping
out
yeah,
so
you
know,
as
I
think
it's
pretty
clear
here,
there's
some
obvious.
You
know
silos
right
and
these
silos,
I'm
representing
with
literal
brick
walls
between
teams,
because
sometimes
it's
that
bad
and
there
are
companies
that
still
struggle
with
this
today,
even
when
they
think
they've
implemented
some
modern
process
or
new
tooling,
and
things
like
that.
B
At
the
end
of
the
day,
it's
it's
people
that
are
really
involved
here
and
across
the
process
right,
whether
you're
a
developer,
you're
a
qa
person
you're
in
security
you're
in
operations,
you
know
or
you're
doing
kind
of
a
bad
trick
of
everything
right.
There's
people
involved
with
it
and
I
think
that's
where
a
lot
of
companies
have
made
mistakes
in
the
past.
It's
not
recognizing
this
problem
that
was
actually
being
solved
with
devops.
B
It's
not
just
the
new
buzzword,
but
there's
actually
a
reason
for
it
so,
like
I
said
it
should
be
pretty
clear,
but
the
developers
were
pretty
siloed
off
from
qa
teams.
In
most
organizations,
qa
and
developers
were
often
siloed
from
the
security
team,
who's
also
styled
from
the
operations
team
and
these
pieces.
Just
don't
work
well
together,
so
you
know
what
problems
does
this
come
from
or
cause
right?
Well,
the
problems
that
we
see
is
you
know
people
will
then
start
having
issues
with
like
oh
well.
You
know
this
is
a
developer
problem.
B
Why
is
the
qa
team
handling
it
or
the
qa
team's
like?
Well,
hey,
that's
a
security
thing!
That's
outside
of
our
realm!
I'm
not
going
to
test
about
that!
You
know
operations
is
like.
Oh
what
the
heck.
This
code
doesn't
even
work.
How
can
qa
pass
this
right?
So
there's
kind
of
this,
this
problem
of
of
disconnect
and
the
reporting
structure
in
a
lot
of
organizations
when
they're
formed
with
these
silos
like
this,
do
not
allow
for
inner
team
collaboration
very
well.
B
There
really
is
some
like
literal
boundaries
here,
so
it's
something
to
to
take
note
of
and
something
that
we
want
to
make
sure
that
we
kind
of
keep
track
of
here.
So
I
do
see
that
asked
to
speak
a
little
slower.
I
apologize.
I
get
excited
about
these
topics
so
yeah.
Basically,
you
know
again
just
this
idea
of
of
silos
and
really
trying
to
hit
that
point
home
that
that
stops
communication.
B
It's
turns
into
a
blame
game
right.
We
start
blaming
it
on
other
teams
and
and
all
of
that,
so
you
know
what's
the
other
problem
that
we
see
here
well,
github
actually
had
a.
We
have
a
data
science
team
that
did
an
analysis
of
70
million
lines
of
code
in
all
the
major
open
source
projects
over
the
last
five
years,
and
what
this
chart
is
showing
is
that
kind
of
purple
trend
on
top?
B
Is
the
lines
of
code
increasing
over
time
so
over
the
last
five
years
from
april
april,
for
this
report
and
what
we
see
is
the
number
of
security
threats
trending
right
along
with
it
and
at
times
it's
at
a
higher
acceleration
or
a
higher
growth
rate
than
the
lines
of
code,
which
means
that
you
know
just
because
we're
putting
more
code
out
there.
This
kind
of
makes
sense
they're
proportional
to
each
other,
where
we
put
more
code
out
there.
B
More
security
threats
are
possible
now
because
there's
more
code
to
exploit
right,
so
it's
really
really
interesting,
there's
kind
of
a
bilateral.
You
know
y-axis
chart
on
here
security
threats
on
the
scale
on
the
right-hand
side,
with
lines
of
code
on
the
left,
but
you
know
basically,
what
we
found
is
for
almost
70
70
million
lines
of
code,
there's
around
10
000
security
threats
where,
when
we
had,
you
know
if
I
just
pick
a
different
intersection,
42
million
lines
of
code,
there
were
7
200
right.
B
B
So
what
do
we
do
to
solve
this
right?
Well,
this
was
a
recognized
problem.
People
started
talking
about
these
siloed
off
areas.
Just
aren't
working.
We
we
need
to
find
a
way
to
bring
the
teams
together
work
better
together.
We
can't
wait
till
the
end,
for
you
know
qa
or
we
can't
wait
till
the
end
for
security
or
something
like
that.
We
really
need
this
feedback
faster.
B
You
know,
as
movements
came
out
like
agile
and
lean,
and
all
these
other
things
we
need
to
find
a
way
to
allow
these
types
of
things
to
happen
between
teams
a
little
bit
better,
so
I
will
have
to
pull.
I
see
a
few
people
asking
what
constitutes
a
security
threat
for
that
previous
slide.
Here,
great
question:
I
don't
know
the
answer
off
the
top
of
my
head,
but
maybe
aj
or
someone
can
can
check
for
me
on
that
I'll
see.
If
I
can
get
that
answer
for
you
for
sure.
B
Okay,
so
that
said,
though
I
apologize,
I
don't
have
that
right
away.
I'll,
definitely
look
for
that.
So
shifting
left
is
kind
of
the
the
solution
that
we
came
up
with,
or
I
should
say
the
industry
came
up
with
as
a
fun
buzzword.
That
kind
of
means.
You
know
we
need
to
take
this
qa
and
security
process
and
move
it
left
that
is
earlier
into
our
development
process.
B
So
the
idea
is,
you
know
why
don't
we
bring
qa
earlier
into
the
process?
Why
don't
we
bring
security
earlier
into
the
process
and
there's
a
few
reasons
why
we
want
to
do
that?
You
know.
Part
of
the
reason
is,
of
course,
these
silos
that
I've
been
talking
about,
but
there's
really
a
lot
of
other
real,
tangible
reasons
why
we
would
want
to
do
this.
It
increases
collaboration.
B
It
allows
the
teams
and
people
to
work
more
fluidly
with
less.
You
know,
blame
and
pointing
back
and
forth,
because
they're
involved
in
the
whole
process-
and
we
get
to
you-
know
kind
of
see
well
I'll,
go
to
the
next
slide.
I
guess
because
I
have
some
some
reasons
here
on
the
why?
But
we
get
to
see
these
benefits
of
shifting
left
and
kind
of
seeing
where
that
goes
to.
So
you
know
one
thing.
B
Obviously
I
think
everyone
knows
qa
and
security
are
both
going
to
ensure
your
software
works
properly,
which,
at
the
end
of
the
day,
we
all
want
to
ship
higher
quiet,
higher
quality
code
faster
and
more
securely
right.
No
one
wants
to
put
code
out
there.
That's
going
to
cause
some
big
problem,
or
something
like
that.
B
So
you
know
that's.
That's
kind
of
the
first
piece
is
recognizing
that
qa
and
security
really
are
paramount
to
this
entire
development
flow.
You
know
doing
the
shift
left
thing
also
allows
you
to
do
a
few
other
buzzwords
out
there.
You
get
to
fail
earlier
right,
so
failing
early
means
that
you
know,
maybe,
while
I'm
in
the
initial
feature
development,
I
have
a
unit
test
fail.
That
tells
me
I'm
breaking
something.
B
Instead
of
waiting
for
that
code
to
go
all
the
way
through
to
a
qa
team
and
them
telling
me
later
and
having
to
hand
it
back
right
and
then
there's
a
disconnect
between
the
qa
team
and
the
developer
and
trying
to
find
out
what
the
actual
bug
was
and
all
of
that
fun
stuff
right.
So
there's
obviously
limits
to
this,
but
the
more
early
testing
we
can
do
on
both
the
security
and
qa
front,
the
better.
B
We
can
feel
about
deployment
confidence,
the
the
better
it
is
in
terms
of
a
lower
cost
to
fix
the
problem.
It's
much
easier,
while
I'm
developing
a
feature
that
isn't
in
production
to
find
a
bug
and
fix
it
than
it
is
for
that
to
go
out
to
production.
Have
a
user
come
in
and
tell
me
about
the
bug?
Maybe
that
bug
was
some
type
of
crazy
exploit,
exploit.
Excuse
me,
or
you
know
something
that
broke
the
shopping,
cart
completely,
and
now
my
sales
are
completely
dropping
until
this
is
fixed
right.
B
B
B
I
was
a
software
development
engineer
and
test
an
sdt
right,
a
qa
engineer,
whatever
you
want
to
call
it
there
and
the
company
had
two
week
sprints
and
in
every
sprint
they
had
to
reserve
20
hours
per
developer
on
each
team
to
handle
the
the
bugs
that
were
coming
in.
They
had
so
many
interrupters
that
they
couldn't
contrib
or
commit
to
certain
items
in
their
sprint
because
they
just
they
knew
they
were
going
to
have
bugs
come
up.
B
Yes,
we
have
a
huge
amount
of
debt
now,
but
if
every
time
you
fix
a
bug,
you
write
a
test
you're
slowly
chipping
away
at
that,
so
it's
just
kind
of
helping
us
by
reducing
that
down
by
having
that
process
earlier
into
the
the
equation
here
right,
so
you
know
what
does
that
do
then?
Well
that
then
allows
me
to
ship
faster.
So
I'm
confident
in
my
deployment,
that's
coming
up
because
all
the
code
that
I
have
is
past.
You
know
all
these
checks
that
I
have
for
security
and
qa
integration
testing.
B
I
had
container
scanning.
You
know
all
these
things
right.
Well,
I
can
push
the
code
out
a
little
bit
faster
because
I'm
more
confident
now
in
that
code,
if
I
have
10
percent
coverage
of
my
code,
you
know
90
of
that
application
has
never
been
tested
or
maybe
had
someone
manually
going
through
clicking
things,
there's
probably
a
higher
chance
of
a
bug
showing
up
or
security
issue
than
if
I
had
you
know,
90
of
the
code
base
covered
right.
B
The
the
last
thing
is
kind
of
a
fun
one,
but
also
not
at
the
same
time,
because
it
could
have
been
quite
terrible
but
shifting
left
and
this
idea
of
getting
better
quality
and
security
could
literally
help
prevent
lawsuits
such
as
a
few
examples.
I
listed
here
death
and
even
nuclear
war
right,
and
let
me
explain
those
here
because
you
might
think
nuclear
war
wow.
What
are
we
talking
about?
Well
verse,
2,
the
therap-25
and
panama
city
are
fairly
similar.
B
At
this
point
same
thing,
they
had
a
timing
bug
the
the
idea
is
that
it
shoots
a
missile
to
interrupt
an
incoming
missile,
so
they
blow
up
in
the
air
instead
and
if
the
timing's
off
well,
it's
just
going
to
fly
right
past
that
missile
and
that
happened
it
hit
a
military
base.
I
think
there's
something
like
100
people
got
injured
in
that,
so
it's
pretty
crazy,
pretty
crazy
for
sure
and
the
last
one-
and
maybe
I
shouldn't
say
fun,
but
most
interesting
case
is
this
idea
of
nuclear
war.
B
B
So
this
actually
happened.
This
is
something
you
can
look
up.
Their
detection
system
said,
there's
a
nuke
and
they
called
the
officer
on
duty
immediately
said:
should
we
go
ahead
and
go
through
and-
and
you
know,
retaliate
basically
and
the
guy
said
you
know,
I
think
if
the
u.s
attacked
us,
they
send
more
than
one
nuke.
So
this
must
be
a
bug
and
literally
his
decision
stopped
what
could
be
nuclear
war
right.
So
you
know
this
idea
of
quality
and
security.
There's
there's
really
like
tangible
reasons
why
we
we
care
about
this.
B
B
So
you
know
this
is
not
just
about
you
know:
saving
the
company
money
at
the
bottom
line,
type
thing:
you
know
there's
instances
of
of
recalls
of
like
intel,
computer
cpus
that
had
to
be
recalled
because
of
software
bugs
that
cost
millions
of
dollars,
but
you
know,
outside
of
just
the
monetary
part,
there's
people's
lives
that
are
involved
in
these
things
and
I
think,
that's
kind
of
an
important
piece
to
to
call
out
here
as
well.
So
how
do
we
prevent
all
of
this?
B
B
You
know,
I
guess
definitions
of
devops
and
how
people
can
define
it
with
different,
tooling
and
people
teams-
and
you
know
all
this
fun
stuff,
but
at
the
end
of
the
day,
connecting
people
and
teams
together
to
increase
collaboration
is
what
we
kind
of
define
devops
as
within
github
and
within
the
industry
as
a
whole.
So
you
know
what
does
what
does
devops
bring
to
the
table?
How
does
it
solve
some
of
these
problems
for
us?
So
you
know,
first
of
all,
it
allows
for
more
consistency
in
all
of
our
operations
processes.
B
Right,
you've
probably
heard
of
this
as
code
type
phrasing
before
infrastructure
as
code
pipeline
as
code,
you
know
we
have
well
policy
is
code,
configuration
is
code,
there's
there's
so
many
different
versions
out
there
now
and
you
know
what
devops
has
done
is
we
say:
okay,
hey
developer,
let's
help
automate
and
standardize
some
of
our
operations
and
processes,
and
this
is
going
to
be
the
same
now
each
time
because
we
have
set
code
right.
That
code
also
goes
through
pull
request
processes.
B
It
gets
code
reviewed,
so
any
change
to
even
a
policy
can
be
reviewed
and
has
more
collaboration
across
the
teams
that
the
policy
team
gets
to
jump
into
that
now
the
developer
gets
to
help
write
some
automation
for
it.
Maybe
the
qa
team
says
how
the
process
should
look,
so
there's
there's
a
lot
more
involved
there.
B
Finally,
this
kind
of
reduces
that
friction
as
well.
You
know,
if
I
mentioned
silos,
I
showed
the
brick
walls
between
teams
earlier.
So
this
friction
between
the
teams
is
a
real
problem
and
there's
a
lot
of
blame
that
gets
put
back
and
forth.
That's
not
my
job!
That's
the
qa's
team
to
do
that.
That
type
of
thing
so
devops
bringing
all
these
processes
together
and
allowing
better
collaboration
really
allows
for
that
friction
to
reduce
as
well
and
lets
everyone
work
better
together.
B
So
you
know
that
said
what
does
then
security
happen
when
we
go
into
devsecops
now
the
latest
of
the
the
buzzwords
in
the
devops
world
right
so
devops
specifically
is
kind
of
this
developer
operation.
Connection
devsecops
is
simply
adding
the
devops
principles
of
automating
and
standardizing
things
into
the
security
realm
right.
So
we're
going
to
allow
now
security
teams
to
also
be
involved
in
this
process
of
working
throughout
your
entire
software
pipeline.
B
I
want
to
be
involved
earlier
in
the
detection
phase,
whether
it's
through
code
scanning
or
secret
scanning,
or
something
like
that,
I'm
going
to
be
going
into
the
kind
of
middle
qa
stage
where
we're
testing
out
like
dependencies
and
and
you
know,
does
this
actually
go
out
there?
Is
there
any?
I
don't
know
sql
injection
issues
or
something
like
that,
and
then
you
know
moving
forward
security,
also
tests
things,
of
course,
after
it's
out
in
production,
checking
logs
and
ensuring
that
things
like
you
know,
hackers
coming
in
or
or
ddos
attacks.
B
B
What
does
that
do?
For
us
too
well,
of
course,
it
reduces
potential
leaks
of
maybe
a
secret
in
my
code.
It
could
help
prevent
a
breach.
If
my
code
has
some
type
of
known
vulnerability
that
gets
caught,
it
helps
you
collaborate
on
configuration
and
policy.
So
you
know,
security
teams
also
have
lots
of
configuration
and
policy
concerns.
It's
not
just
operations
working
on
infrastructure.
B
Excuse
me,
a
lot
of
security
personnel
are
also
network
agents
or
not
agents.
I
guess
network
engineers
right
and
they
have
to
do
things
like
configuring,
their
switches
or
firewall
policies
right
and
if
we
make
that
all
in
this
devops
world
of
putting
that
as
code
right
now,
we
have
policy
and
configuration
as
code.
So
having
things
like
puppet
chef,
terraform
plans,
you
know,
arm
templates
for
azure
aws
has
something
similar
to
that.
Oh
terraform.
B
I
already
said
it
so
you
know
these
types
of
of
things
are
really
modernizing
these
processes
and
and
bringing
it
to
a
whole
new
realm
where
it's
not
just.
You
know
one
security
person
doing
these
manual,
configurations
and
manual
reports
and
stuff
like
that,
but
we
actually
have
automation.
That's
doing
all
of
this.
For
us
and
we're
getting
into
such
a
better
place
now
where
we
can
find
out
more
than
just
relying
on
a
manual
process
right,
so
it's
it's
quite
fun,
quite
fun.
B
B
So,
first
of
all,
you've
probably
heard
about
the
whole
github
advanced
security
thing,
but
if
you
haven't
it's
kind
of
our
feature
set
that
is
constantly
evolving
getting
better
all
the
time
it
seems
to
be,
and
it
includes
things
like
code
ql,
a
query
language
that
allows
you
to
scan
your
code
for
static
code
analysis.
It
works
for
quite
a
few
different
languages
right
now.
I
think
there's
some
like
container
scanning
parts
of
it
as
well.
It's
it's
hard
to
keep
track
because
it's
constantly
getting
better,
which
is
great.
B
You
know
secret
scanning,
that's
another
thing!
So
how
many
times
have
you
maybe
used
the
environment
file
and
it
wasn't
part
of
your
git
ignore
so
guess
what
you
did
a
git
commit
and
then
now
suddenly
I
have
a
secret.
That's
out
of
my
code
base,
it's
in
my
git
history,
it's
on
a
public
repo,
because
I
was
trying
to
do
open
source
and
now
everyone
has
my
token
right.
So
secret
scanning
is
allowing
us
to
detect
those
earlier
invalidate
those
secrets
where
appropriate.
B
So
there's
some
questions
right
now
about
how
devsecops
works
and
if
any
tools
hooked
into
github
can
be
ran
to
detect
vulnerabilities
what's
available
for
various
programming
languages.
So
that's
that's
what
I'm
going
over
right
now
is
you
know
codeql,
I
don't
remember
the
full
list.
I
want
to
say
it's
five
or
six
of
the
major
languages.
At
the
moment
I
think.net.
B
Oh
gosh.
Excuse
me
dot
net
c-sharp
java
javascript.
I
don't
remember
what
else
I
think
ruby
is
in
there
as
well
and
a
few
others.
Many
of
the
the
major
programs
are
are
being
covered
by
that
right
now.
So
many
of
your
programming
languages,
I
should
say,
excuse
me
so,
okay,
so
we're
covering
some
secrets,
we're
doing
some
static
code
analysis.
Now
you
know
what
about
open
source
like
I
am
consuming
open
source
products.
B
We
see
more
and
more
threats,
so
it
seems
like,
if
I'm
dependent
on
all
these
open
source
projects,
there
needs
to
be
some
checking
there
to
make
sure
those
products
are
not
introducing
vulnerabilities
that
I
didn't
even
code
it's
just
because
I
use
some
other
module
or
some
other
package
or
something
like
that.
You
know
I
wound
up
introducing
a
vulnerability.
I
didn't
know
about
so
dependency
insights.
B
We
actually
have
something
called
dependable
and
dependable
will
go
out,
scan
your
dependencies,
for
you
know,
let's
say
npm,
for
example,
and
it
will
look
for
new
versions
to
come
out
and
where
it
can
it'll
even
open
a
pull
request
to
bump
the
version
number
for
you
if
it
thinks
it
won't
be
like
a
major
impact.
Of
course,
you
still
want
to
test
that
you
know
changing
the
version.
Number
of
a
dependency
doesn't
break
your
code
or
anything,
but
the
idea
is
we're,
alerting
you
to
hey.
You
have
dependencies
that
now
have
known
vulnerabilities.
B
You
need
to
know
about
this.
We
need
to
take
care
of
this.
This
is
something
we
want
to
call
out
to
you
and
part
of
that
process
of
calling
it
out
came
with
what
we
have
security
policies
now
too,
so
there's
a
security
tab
on
the
repository
where
you
can
set
a
space
for
people
to
report
vulnerabilities
in
your
code,
and
you
can
discuss
these
privately
without
a
public
setting
at
all.
Even
if
it's
a
public
repo,
the
security
tab
stuff
is
private.
B
Instead,
this
information
you
can
put
there
on
you,
know
how
you
can
report
a
vulnerability
and
then
there's
also
again
that
full
internal
discussion
and,
of
course,
the
great
thing
about
github
and
having
all
those
discussions
on
github,
is
you
get
to
chat
about
the
vulnerability
right
where
the
vulnerability
was
reported?
You
don't
have
to
go
to
some
separate
software
or
something
like
that.
B
You
know
another
thing
that
we
have
for
security.
We've
had
it
for
quite
a
while.
Now
is
that
the
branch
protections
I'm
sure
you've
seen
those
have
gotten
better
over
the
years
too.
But
basically,
you
can
do
things
like
not
allow
force
pushes.
I
saw
some
people
doing
a
git
push
dash
force.
I
think
in
the
chat
earlier,
so
you
know
blocking
that.
So
people,
don't
just
you,
know,
force
push
to
their
main
default
branch.
That
wouldn't
be
a
good
thing.
B
You
know
having
these
security
advisories
having
this
the
security
policies
in
place,
just
all
of
it's
allowing
people
to
collaborate
on
this
full
piece
of
security.
Now
in
a
much
better,
automated
way,
you
know,
there's
always
going
to
be
room
for
improvements.
There
might
be
other
tooling
that
you'd
use
as
well,
but
github's,
trying
to
be
part
of
more
of
the
tool
chain
to
really
help
people
get
set
up
and
just
built
into
one
platform.
B
So
last
thing
I
have,
I
just
wanted
to
talk
about
the
audit
logging,
some
too.
So
you
know
as
an
organization
on
github
there's
a
lot
more
logging
efforts
going
into
things.
Now
you
get
audit
logs
of
people
being
added
or
removed
from
repositories,
access,
changes,
repositories
being
deleted
or
created.
B
I
get
to
talk
about
the
code
changes
and
the
documentation
changes
right
in
line
where
the
change
happened,
which
is
pretty
awesome.
I
like
that
aspect,
the
most
I
think
so,
okay,
we
talked
about
quite
a
bit.
I
am
you
know,
pretty
sure
everyone's
probably
bought
into
the
idea
of
devops
devsecops
wanting
to
get
all
these
pieces
put
together.
How
do
I
do
this?
Well,
I
do
have
some
pro
tips
for
you.
B
I
wanted
to
to
cover
a
few
things
that
I
recommend
based
on
customers,
that
I've
worked
with
over
time
enterprises.
I've
helped
implement
these
devops
transformations
and
you
know
just
kind
of
things
that
I've
done
even
on
a
personal
level
before
I
was
at
github,
so
the
first
thing
is,
I
will
give
a
shout
out
to
simon
sinek.
He
wrote
a
book
called
start
with
why,
if
you
ever
get
a
chance
to
read
it,
it's
great.
B
Well
now
I
have
to
learn
a
new
tool
as
well
as
a
developer,
so
it's
kind
of
like
this
constant
pain,
point
of
just
pushing
that
information
out
there
and
really,
if
you
start
with
why,
instead,
which
is
more
of
what
I
tried
to
do
here,
you
know
in
this
presentation,
even
of
you
know,
what's
the
problem,
what
are
we
fixing
here
before
you
tell
me
what
we're
doing
to
fix
it?
It's
a
lot
more
impactful
to
developers.
B
Well
write
a
test
and
let's
hope
that
it
doesn't
come
up
again
now
and
then
you
can
actually
work
on
more
meaningful,
impactful
things
where
you're
not
getting
burnt
out
by
just
doing
bug.
Bug
fixes
constantly
right
so
giving
that.
Why
is
impactful
and
I'd
highly
highly
recommend
that
remembering
that
people
are
the
core
of
this,
and
this
isn't
just
a
tooling
change,
this
is
a
culture,
change,
you're,
doing
a
devops
transformation
or
a
devsecops
transformation.
You
know
we
are
literally
changing
the
way
we
develop
software
within
our
organization
right.
B
So
there
are
people
involved
in
that,
and
sometimes
that
gets
lost
when
the
cto
of
a
company
says:
hey
we're
gonna
start
doing
devsecops.
We
just
bought
licenses
for
all
these
different
tools,
so
go
do
it
and
you
know
that
that's
not
really
fair
to
the
people
at
the
end,
who
are
actually
doing
the
work
so
having
this
kind
of
slow
rollout
process
really
making
sure
that
they
understand
why
this
is
happening,
how
it's
improving
their
day-to-day
livelihood.
You
know,
no
one
wants
to
read
blogs
all
the
time.
If
I
can
automate
something
to
parse.
B
My
logs
to
you
know,
call
out
the
things
that
I
care
about.
Instead
of
me,
scrolling
through
logs
by
myself.
That's
going
to
make
my
job
better
right.
I
can
do
more
fun
things
now,
because
my
automation's
taking
care
of
it.
You
know
we
want
to
keep
that
idea
in
mind.
Basically,
you
know
so
what's
another
way
we
can
do
this,
then.
So
I
talked
about
slow
rollout.
B
One
thing
that
we
say
where
I'm
at
in
the
professional
services
side
of
github
is
we
talk
about
a
lighthouse
team,
so
a
lighthouse
team
is
that
symbol
that
beacon
on
the
engineering
team.
Maybe
they
have
a
smaller
project
or
a
new
project
that
doesn't
have
a
bunch
of
legacy
stuff.
That's
going
to
get
you
stuck,
you
know
having
to
worry
about.
Oh,
is
this
compatible
or
not?
B
I
don't
know
because
I'm
working
in
clearcase
or
something
like
that
and
you
get
to
have
this
lighthouse
team
kind
of
pilot
the
program
for
you
hey,
you
know,
can
you
guys
start
writing
more
tests
and
let's
see
how
that
goes,
and
then
they
start
doing
that
better.
They
see
the
improvements
they
go
through.
The
pain
points
as
well
right
and
they
see
okay
yeah.
Well.
B
I
noticed
that
writing
tests
actually
did
open
up
a
lot
more
bandwidth
for
me
to
do
personal
skill
development
or
to
do
feature
development,
and
I
got
to
do
this
know
this
new
proof
of
concept-
that
for
a
new
shopping,
cart
that
I
wouldn't
have
had
time
to
do
and
it
got
accepted
and
now
we're
going
to
build
a
new
shopping
cart
for
the
website.
I'm
really
excited
about
that
right.
B
So
you
have
this
lighthouse
team
that
kind
of
gets
through
the
initial
barriers
and
they
have
less
barriers
or
lower
barriers
of
entry,
because
they're,
usually
smaller
teams,
smaller
projects
or
you
know
again,
newer
projects,
even
that
can
be
a
little
bit
more
flexible
and
all
of
this
together
is
again
not
going
to
work.
If
your
people
can't
collaborate-
and
I
mentioned
this
some
earlier
with
the
the
silos-
but
I
was
talking
about
organizational
structure
literally,
not
allowing
people
to
collaborate.
So
that's
a
very
important
thing.
B
You
know
you
can
have
all
the
best
tooling
out
there.
You
can
have
all
the
modern.
You
know
newest
coolest
thing
out
there,
but
if
you
weren't
letting
the
people
talk
to
each
other
you're
still
not
going
to
be
able
to
implement
this
idea
of
devops
devsecops
right,
we
still
need
people
to
be
able
to
chat.
We
need
the
developers
to
talk
to
the
operations
and
monitoring
teams.
We
need
security
to
work
with
the
developers
along
the
process.
B
We
need
our
qa
folks
that
maybe
are
embedded
with
developers
now
or
maybe
still
a
dedicated
group
of
people
to
work
very
closely
with
our
development.
We
need
to
be
able
to
get
that
feedback
right.
So
you
know
allowing
people
to
collaborate
here
is
is
going
to
be
kind
of
my
final
tip
of
just
you
know
you
can't
just
roll
out
process
you
have
to.
You
have
to
see
all
the
pieces
to
it.
Basically
right,
it's
not
just
a
tully
problem:
it's
not
just
a
process
problem.
B
It's
an
overall
people
thing
where
we
really
need
to
change
the
culture
here,
so
that
all
said
coming
up
to
the
end
of
this
here,
one
to
wrap
it
up,
just
kind
of
recap:
everything
we
talked
about
over
the
last
45
minutes
or
so
so
you
know
where
we
came
from.
Is
this
problem
of
a
very
firm
silos
right
developers
didn't
talk
to
qa
qa,
didn't
talk
to
the
operations
team?
No
one
talked
to
security,
because
no
one
wanted
to
have
to
fix
anything
so
just
hard,
hard
silos
right
and
that
caused
problems.
B
So
this
idea
of
shifting
left
came
out
to
to
do
that
and
shifting
left
is
really
what
started
spawning
this
devops
movement
right.
So
again,
this
is
all
outside
of
things.
You
can
do
waterfall.
You
can
have
devops
in
waterfall,
devsecops
and
waterfall.
A
lot
of
people
think
agile
is
devops
and
that's
not
the
case.
You
know
devops
is
the
people
and
the
people
involved
in
collaboration.
B
Yes,
they
use
different
tooling.
Yes,
they
have
means
of
doing
things
and
processes
to
follow.
However,
the
people
collaborating
is
really
the
core
piece
here
and
allowing
those
devops
principles
to
go
into
devsecops
has
allowed
security
to
now
be
involved
in
this
collaboration
effort,
the
automate,
the
boring
things
right,
there's
a
really
good
book
on
python
called
automate.
The
boring
things
with
python,
I
believe,
is
the
title
super
good.
B
You
know
there's
just
a
lot
of
a
lot
of
exciting
things
that
can
happen
when
this
is
done
well,
and
you
have
this
kind
of
well-oiled
machine
going
on.
So
you
know
we
talked
about
how
github's
helping
so
again
there's
the
things
like
the
basically
the
the
sorry,
the
dependent
bot,
the
code
scanning
secret
scanning,
all
those
fun
pieces
and
you'll
probably
hear
more
about
that
at
github
universe.
B
In
a
few
weeks
here,
I
think
it's
december,
8th
through
the
10th,
so
you
know
we're
doing
what
we
can
to
try
to
be
more
involved
in
the
full
pipeline,
not
just
the
code
piece
anymore.
We
want
to
be
more
involved
in
the
in
the
pipeline
and
allow
developers
to
collaborate
across
everything
here
and
lastly,
you
know
we
talked
about
these
rollout
plans
right.
B
So
just
remembering,
I'm
again,
simon
sinek,
I
love
that
book
start
with
why
telling
developers
or
the
people
at
the
end,
why
we're
making
a
change
before
you
roll
out
a
change
and
showing
them
that,
because
of
this,
this
is
going
to
help
you.
You
know
not
have
to
do
as
many
bug
fixes
and
the
way
we're
going
to
have
you
not
do
as
many
bug
fixes
is
by
having
this
new
tool
called.
You
know,
n
unit
or
something,
and
then
n
unit
is
going
to
allow
us
to
write
more
unit
tests.
B
But
you
start
by
saying
that
the
real
reason
here
is
that
we're
going
to
reduce
the
amount
of
bugs
that
you
have
to
fix
right,
and
that
gives
it
a
lot
more
of
a
an
appeal
to
developers
is
doing
something
like
that.
So
just
kind
of
keep
that
in
mind
that
the
people
are
kind
of
your.
You
know
your
key
asset
here
as
we
talk
about
things.
So,
if
you
want
to
read
more,
we
have
quite
a
bit
of
content
on
devops
and
devsecops
within
github.
B
B
You
know
whether
I'm
doing
a
two-week
sprint
or
doing
kanban
or
extreme
programming
or
waterfall
that
doesn't
necessarily
matter
as
much
in
the
sense
of
just
devops
specifically
and
what
devops
is,
and
we
actually
talk
about
that
a
little
bit
more
in
some
of
these
blog
posts
that
I
have
linked
here.
So
these
will
be
in
the
description
of
the
video,
I
believe
on
youtube.
B
So
this
is
being
recorded.
It
will
be
uploaded
to
youtube
on
the
github
youtube
channel,
so
you'll
be
able
to
see
these.
But
if
you
go
to
the
github
blog
there's,
you
know
what
is
code
scanning.
Why
is
it
awesome
how
to
achieve
devsecops
maturity,
there's
a
myths
and
misconception
devops
post,
which
is
pretty
cool.
My
my
former
manager
actually
wrote
that
one
we
actually
have
a
whole
roundup
of
devsecops
resources
that
are
really
neat.
B
B
It's
actually
going
to
be
with
the
google
cloud
team
and
they're
going
to
be
talking
about
how
they've
done
continuous
integration
and
delivery
ci
cd
using
github
actions
for
the
google
cloud
platform,
so
should
be
a
pretty
cool
talk
as
well.
I
won't
be
in
that
one,
I
don't
think
other
than
maybe
just
a
viewer,
but
definitely
encourage
you
to
sign
up
for
those
as
well.
So
with
that
said,
I
think
we're
going
to
go
ahead
and
move
to
questions
here.
Let
me
go
ahead
and
see
what
we've
got.
B
I
do
see
one
question
that
was
saved
earlier.
Thank
you,
aj.
Let
me
read
it
real,
quick
here:
okay,
so
how
much
should
automated
security
and
qa
process
related
to
checking
primary,
primarily
external
things
like
libraries
being
imported
or
used
in
the
file
system?
So,
okay?
How
much
should
we
use
automated
security?
Qa
practices
against
external
versus
internal
things?
Is
the
question
basically
so
there's
curiosity
around
what
tests
and
automated
pipeline
processes
would
look
like.
So
that's
that's
the
thing
right
is
the
more
you
do
this.
B
You
don't
want
to
slow
down
your
developers
too
much
right
as
we
shift
left
and
we
put
more
on
those
early
processes.
You
know
you
could
almost
go
too
far
too
quickly,
where
you
don't
have
these
well-defined,
like
pipelines
set
up
just
yet.
So
you
know
as
a
rough
example
just
because
you
asked
for
kind
of
an
example
pipeline.
I
might
see
something
where
the
developers
are
writing
their
own
unit
tests
and
they
can
run
those
tests
locally
or
they
can
deploy
their
code
to
a
dev
environment
to
run
locally.
B
If
they
needed
to.
There
is,
then,
maybe
a
little
bit
of
a
higher
level
of
qa
done
on
like
a
staging
environment
or
something
like
that.
Where
we
do
things
like
our
integration
tests,
we
can
run
our
static
code
analysis.
We
can
do
all
of
that
piece.
I
guess
even
before
that
secret
scanning
would
already
catch
as
the
developers
pushing
code
up
if
there's
any
tokens
in
the
code
or
anything
like
that.
B
So
let's
see
doing
this
off
the
top
of
my
head,
so
I
apologize
if
I'm
jumping
a
little
bit
but
yeah,
probably
secret
scanning
on
that
piece
for
security
and
then
in
that
kind
of
qa
environment.
Before
we
push
out
to
a
production
or
a
staging
area,
we
would
talk
about,
like
our
static
code,
analysis
dependencies,
just
kind
of
making
sure
that
all
of
our
our
ducks
are
in
a
row
here
and
there's
not
any
major,
a
wasp.
B
You
know
top
10
security
vulnerabilities
or
something
like
that,
and
then
you
know
I
would
say
from
there.
If
we
get
like
the
green
light,
I
I
don't
like
the
continuous
delivery
portion
so
much
where
people
are
or
continuous
deployment
where
people
are
constantly
putting
out
code
instantly
without,
like
a
manual
check
to
click
a
button.
I
think
that
that's
possible
in
some
situations,
but
it's
pretty
tough.
So
I
would
say
that
the
final
check
would
be
like
your
acceptance,
testing
just
kind
of
your
your
last
rundown
did.
B
We
have
anything
weird
happen
with
our
manual
testing
that
happened
or
a
ui
test,
or
something
like
that,
and
then
we
can
go
and
push
it
out
to
production.
So
the
way
github
does
that
is.
We
actually
have
all
of
our
double
developers.
Writing
our
own
tests
unit
and
integration
testing.
We
have
a
performance
test
person
who
does
a
lot
of
performance
testing
for
us,
of
course,
on
on
how
things
are
doing.
B
We
push
a
lot
of
code
behind
feature
flags
that
allows
us
to
test
things
in
a
live
environment
or
in
a
dev
environment
without
having
to
have
everyone
get
access
to
that
code
and
then,
basically,
our
security
processes
are
through
all
of
that.
So
the
things
that
I've
talked
about
secret
scanning
dependency
management
through
dependabot
all
of
those
pieces
are
all
kind
of
involved
in
that
too.
So
it's
pretty
cool.
Let's
see
here,
I
see
a
few
other
questions.
B
Let's
see,
what's
the
industry
standard
for
an
os,
I'm
not
sure
that
question
completely
actually,
but
I
guess,
as
far
as
like,
where
I
would
be
testing
things
and
stuff
like
that,
probably
like
a
linux
or
yeah,
I
mean
linux
or
windows.
I
guess
if
you're
doing
like.net,
but
probably
a
linux
environment,
let's
see,
I
believe,
the
fact
that
devops
and
devsecops
is
more
of
a
culture
that
one
should
nurture
in
the
workforce
and
enjoy
the
essence
of
it
absolutely
so
that
was
a
rune
yeah.
Absolutely
it's
a
culture
movement.
B
This
transformation
is
not
just.
We
bought
new
tools,
it's
not
just
hey.
We
need
testing,
it's
it's
really
a
culture
movement
and
an
adaptation
that
needs
to
happen
from
your
development
teams
from
your
qa
teams.
Your
security
teams-
let's
see
here,
see
some
folks
talking
about
like
switching
like
github,
instead
of
tfs
totally
easy
to
do.
B
B
Let's
see,
can
we
do
all
these
pipelines
that
I
talked
about
in
yaml
script,
depending
on
what
you're
using
to
run
your
your
scripts?
Yes,
yaml
is
totally
one
of
the
standards
out
there
that
a
lot
of
pipelines
use
travis
circle,
ci
and
actions.
Github
actions
are
all
in
yaml
jenkins.
I
think
you
can
do
yaml,
but
a
lot
of
people
do
groovy
script
instead,
so
just
kind
of
depends
on
what
you
want
to
use
there.
B
Let's
see
get
guardians
also
good
at
scanning
potential
security
threats,
yeah,
there's
a
lot
of
tooling
out
there.
It's
actually
pretty
interesting,
there's
a
lot
of
startups
who
have
come
up
recently,
who
have
built
like
entire
businesses.
Basically
on
on
security
testing.
You
know
obviously,
there's
there's
black
duck,
but
there's
also
ones
like
encore,
who
was
on
stage
at
github
universe
last
year
for
container
scanning
there's.
You
know
twist
lock
code
to
see,
there's
a
bunch
of
them
out
there
and
devops.
B
B
But
one
of
the
great
things
about
github,
in
my
opinion,
is
our
ecosystem,
is
so
strong
that
you
know
pretty
much
any
tool
that
is
being
adopted
in
any
any
space
really,
but
especially
in
a
wider
adoption
is
going
to
integrate
with
github
in
some
way,
because
people
know
that
you
know
github
is
where
so
many
developers
are,
and
all
of
that.
So,
let's
see
here.
B
B
Let's
see
formulating
the
plan
on
how
we're
gonna
roll
this
out,
so
I
talked
about
rollout
plans
as
far
as
things
like
you
know,
finding
a
few
teams
that
can
maybe
adopt
some
of
these
principles
and
having
them
go
through
the
pain,
points
and
and
kind
of
documenting
that
process,
and
that
will
help
me
standardize
the
process
to
then
allow
for
a
greater
adoption
throughout
the
organization.
So
you
know,
if
I
have
one
team,
that's
my
pilot
team
that
is
going
to
go
through
and
find
all
these
issues.
B
B
So
that's
kind
of
how
I
would
do
it
it's
just
this
kind
of
very
planned
out,
slow
understand
it's
a
culture
change
that
takes
time
and
remembering
that
there's
people
involved
that
are
impacted
by
the
changes
that
you
know
you're
making
as
a
leader.
So
let's
see,
I
guess
just
kind
of
wrapping
up
here
I'll
see.
If
I
can
take,
maybe
one
more
question.
B
You
know
why
not
find
a
way
to
automate
that
instead
a
real
quick
example
this
morning,
what
I
was
working
on
is
we
do
things
like
this
demo
day
or
hackathons
and
stuff
like
that,
so
I
actually
set
up
a
serverless
function
to
handle
registration
for
hackathons
and
it's
all
completely
agnostic.
It
will
work
with
any
repository
that
we
set
up
to
kind
of
handle
our
registration
and
things
like
that.
So
that
was
a
manual
process
of
setting
all
those
things
up
before
now.
It's
automated,
I
never
have
to
touch
it
again.
B
A
That's
right,
I'm
gonna
get
it
up
on
youtube
as
soon
as
possible,
but
definitely
like
thanks
thomas.
This
has
been
an
amazing
talk,
and
I
know
that
a
lot
of
folks
have
gotten
a
lot
out
of
it
in
the
chat
they
seem
to
be
super
into
it,
and
I
also
want
to
thank
everyone
in
chat
for
joining
us
today.
It's
it's
pretty
amazing.
I
know
that
it
is
definitely
like
the
wee
hours
for
some
of
you
folks,
especially
in
india.
A
This
is
this
is
time
when
you
should
be
sleeping,
but
you're
here
with
us,
and
so
I
definitely
appreciate
that.
I
I
know
folks
are
having
their
their
evenings
and
they've
decided
to
join
us
today
and-
and
I
I
definitely
want
to
respect
that,
you've
all
taken
out
the
time
to
come
and
listen
to
us
today
and
want
to
do
what
we
can
to
bring
you
really
valuable
content
coming
in
the
future.
A
Things
have
been
a
little
complicated
today,
because
this
is
a
new
way
for
us
to
stream,
and
so,
like
I've
been
dealing
with
having
chat,
show
up
in
two
different
places,
and
you
know
all
this
other
swimming
duck
stuff
that
you
don't
necessarily
need
to
care
about,
but
we
are
trying
to
make
things
easier
for
you
to
find
so
we'll
work
on
that.
Thank
you
again.
Everyone
we'll
see
you
soon.
Oh
that's!
My
cue.