►
From YouTube: From Security Testing To Deployment In a Single PR - Sarah Khalife, GitHub & Grant Griffiths
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
From Security Testing To Deployment In a Single PR - Sarah Khalife, GitHub & Grant Griffiths, Portworx
Speakers: Grant Griffiths, Sarah Khalife
Automating cloud native app development and incorporating security through a transparent and consistent process is key in building any production level applications. On a daily basis, think about how often you build your application and scan for vulnerabilities in the code. This is mostly an afterthought and not always considered as the easy part of developing any applications. However, the recent vulnerability exploits reinforced the need for a secure development lifecycle. Simplifying and automating the process all in a single pull request makes it much easier for any cloud app developer to add security! This talk will cover how to leverage available open source tooling to build and test a cloud native application, run security scans across it, and package it for shipping. For automation, we will have a step-by-step demonstration on how to set it up all within a PR to provide consistency and push the containerized application to a Kubernetes environment.
B
A
A
A
A
All
right,
first
production
and
overview
so
actually
previously
in
2020,
we
did
a
session
at
kubecon,
kubecon,
Europe
2020,
around
automating,
with
kubernetes
and
Docker
so
kind
and
building
out
your
CI
pipeline
in
a
single
PR.
So
we
talked
about
what
is
kind.
We
talked
about
how
you
can
actually
trigger
multiple
versions
of
kubernetes,
using
kind
to
run.
All
of
your
testing,
because
we
know
not
one
application
is
going
to
run
on
the
same
environment
in
every
in
every
deployment
that
there
is
so
this
year,
we're
kind
of
taking
that
to
the
next
level.
A
A
So
some
of
the
some
of
the
things
we'll
be
covering
today,
we'll
be
we'll
be
talking
about
some
of
the
simple
steps
to
automate
our
build
process,
we'll
be
leveraging
a
lot
of
the
open
source
capabilities
as
well
as
open
source,
tooling
and
free
tooling,
to
run
these
different
types
of
scans
that
we're
going
to
be
talking
about
and,
at
the
end
of
the
day,
we're
automating
automating
the
containerization
and
triggering
all
the
things
through.
Just
the
pull
request
and
some
of
the
other
types
of
automations
that
you
could
do.
A
Our
goals
are
to
run
integration,
testing
and
security
testing
within
the
single
PR.
We
want
to
make
sure
that
you're,
detecting
vulnerabilities
way
earlier
on
and
you're
fixing
them,
because
we're
actually
enforcing
some
strategy,
some
testing
some
validations
before
you
even
get
into
your
production
Branch.
So
we
want
to
enforce
that
and
block
the
merge.
If
there
are
vulnerabilities,
we
are
configuring,
Branch
protection
rules,
so
the
goal
with
Branch
protection
rules
is
to
make
sure
things
are
more
transparent.
A
We
understand
that
not
everybody
has
the
same
rules
across
the
board
on
how
they're
doing
their
deployments
and
how
they're
doing
their
management
of
their
application
and
their
automation
so
by
configuring.
The
different
branch
protection
rules,
at
least
we're
setting
that
standard
and
setting
a
transparency,
a
studying
and
standard
that
makes
it
more
transparent
to
what
the
requirements
are
to
go
into
a
production
environment
and,
at
the
end
of
the
day,
we're
talking
about
automation,
nobody
likes
doing
anything
manual,
especially
when
it's
mundane
and
continuous
things
that
you
have
to
do
all
the
time.
A
A
So,
what's
our
motivation
so
I
mean
I'm
sure
you've
all
heard
of
a
lot
of
the
recent
exploits
the
log.
4J1
was
a
pretty
big
one.
The
Harpley
Harpley
blood
heart
bleed
bug
and
the
solar
gate
ones
were
some
of
the
major
ones
that
I
had
to
deal
with.
For
my
day-to-day
work
is
the
last
couple
of
years,
so
going
back
and
fixing
a
lot
of
these
issues
can
be
very
tough.
It's
never
a
fun
process
to
go
fix
a
security
vulnerability,
I
mean
in
many
cases.
A
B
So
there's
a
lot
of
different
types
of
security
scanning,
there's
image
scanning,
where
you
kind
of
build
an
image
and
scan
it.
There's
dependency
checks.
So
a
lot
of
code
has
like
basically
it's
very
easy
to
scan
and
see
what
kind
of
dependencies
you're
using
your
application,
and
you
can
cross
check
that
against
like
a
known
list
of
cves
security
database
and
check
to
see
if
you're,
using
any
dependencies
in
your
program
that
are
vulnerable,
then
there's
also
a
static
code
analysis.
B
B
This
is
kind
of
what
a
typical
workflow
looks
like
for
a
developer
working
on
like
a
cloud
native
application.
So
your
developer
introduces
a
code
change,
maybe
they're,
working
on
a
feature
to
add
like
a
new
database
to
your
application.
This
will
immediately
kick
off
typically
like
a
build
job,
so
you
know
make
sure
your
code
compiles
it'll
run
all
your
tests
make
sure
you
know
a
test
is
all
good.
You
know,
you'll
get
a
review
from.
B
You
know
one
of
your
teammates
and
then
once
it's
all
good
you'll
go
ahead
and
you
merge
your
code
and
then
you
do
this
over
and
over
and
finally,
once
you
know
everyone's
fixed
all
of
their
issues,
they're
kind
of
fixed
all
their
features
or
implemented
everything.
It's
code
complete,
so
it's
Dev,
complete
and
everyone's
excited
to
start
releasing.
But
then
you
know,
QA
team
comes
along
or
security
scanning
comes
along,
maybe
late
in
the
release
process.
B
You
might
just
kind
of
run
your
security
scans,
maybe
there's
a
team
that
does
it
or
maybe
it's
someone
else
and
then
oh,
the
scan
failed,
so
you're
right
about
to
release,
and
now
your
scan
has
failed,
and
now
you
need
to
file
an
issue
and
assign
it
to
the
development
team.
Now
the
developing
scene,
of
course,
is
you
know,
that's
our
developer
in
the
bottom
right,
the
they
have
to
go
back
and
they
have
to
go
and
fix
all
these
bugs
and
vulnerabilities.
They
may
have
found
out
now
that
they're
using
a
bad.
B
You
know
SQL
server
or
they're,
using
a
bad
image
or
they're
using
a
client,
that's
out
of
date
or
something
like
that,
and
then
they
have
to
update
that
client
and
then
maybe
there's
API
changes
with
that
client
that
they
need
to
use
or
or
integrate
with
so
very
easily.
You
can
see
we
go
to
you
start
to
push
out
the
deadline
further
and
further
out
and
no
one's
happy
about
that.
B
So
this
is
the
kind
of
improved
workflow
that
we're
going
to
talk
about
today
and
how
you
can
utilize
a
lot
of
the
different
cncf
tooling
out
there
to
kind
of
improve
your
build
process.
So
it's
the
same
as
before.
You
know
you
introduce
a
change.
You
have
a
build
job,
but
then
what's
nice
is
then
you
can
do
vulnerability
scanning
inside
of
your
pull
request.
So
there's
a
lot
of
different
tools
out
there
in
the
cncf
ecosystem
like
I
mentioned,
but
today
we're
going
to
be
talking
about
just
a
couple
of
them.
B
B
Yeah,
all
of
them
are
open
source
and
free,
so
yeah
and
then,
after
all
of
your
code
chain,
all
of
your
code
scanning
finishes
running
and
you
get
your
pool
request
review
and
then
your
tests
are
passing.
You
know
that
when
you
go
to
release,
there's
not
going
to
be
any
vulnerabilities
because
you've
already
been
checking
all
along
instead
of
at
the
end
of
the
release
cool.
So
now
we're
going
to
get
into
a
live
demo.
B
We
just
want
to
kind
of
set
the
stage
first,
so
we're
a
demo
project
that
we're
going
to
do
is
a
project
that
I
use
it
work
day
to
day,
which
is
stork,
which
is
an
open
source
project
by
footworks
and
has
a
kubernetes
schedule
plug-in.
Does
snapshots
and
object
service
controller
open
source
so
go
check
it
out
if
you
want,
but
that's
the
demo
project
that
we're
going
to
be
using
today
and
what
we're
going
to
demo
is
a
open.
B
A
couple
open,
pull
requests
we're
going
to
show
a
couple:
failed
builds
as
well
as
Branch
protection
rules
on
how
you
can
prevent
those
from
being
merged
and
then,
as
well
as
we're
going
to
show
a
successful
PR
and
how
it's
How,
It
All
fits
together
cool.
So
first
thing,
I
think
Sarah
is
going
to
kick
this
one
off
and
we'll
go
through
this
change.
A
All
right
thanks
thanks!
So
as
Grant
mentioned,
we're
kind
of
working
through
the
pull
request.
I
think
this
is
where
can
I
actually
open
up
a
lot
of
the
conversation
you're
pretty
much
thinking
through
like
hey,
my
future
is
complete.
Let
me
create
a
PR
and
add
new
code
example
here,
I'm,
actually
creating
a
PR,
so
I'll
just
kick
this
off
where
I'm
adding
a
new
set
of
a
new
a
new
database,
so
I'm
creating
a
pull
requests
to
create
a
new
database
using
terraform
and
kick
off
that
pull
request.
A
Is
that
better
we're
already
kicking
off
a
lot
of
our
deployment
jobs
or
a
lot
of
our
integration,
jobs
and
a
lot
of
our
security
scans?
So
what's
really
important?
Most
people
think
like
let's
kick
off
our
integration
scanning,
but
why
not
incorporate
some
of
the
security
scans
right
then,
and
there
in
this
case
here
my
database.
Hopefully
it
will
show
that
it's
invulnerable,
because
it's
not
it's
not
good
code
I
copied
it
and
pasted
it
from
probably
somewhere
bad
somewhere
on
stack
Overflow
and
it
triggered.
A
A
You
can
see
connection
and
application.
Sorry
database
connection,
we're
applicable,
there's
a
couple
different
other
ones
that
just
kick
off.
Writing
your
pull
requests!
So
what's
really
nice
about
this?
Now
you
as
a
developer,
you
might
not
understand.
What
does
this
mean
you
can
go
and
have
that
conversation
with
your
teammates
that
might
have
gone
through
this
before
you
can
go
bring
in
your
security
researcher
and
say:
hey:
can
you
tag
them
in
and
say
hey?
Can
you
help
me
understand?
A
So
what
we've
done
really
is
kick
off
these
automations
through
the
pull
requests
and
how
do
we
enforce
them?
What
do
we
do
so
in
this
example?
Here
you
can
do
this
with
other
tools
as
well,
but
what
I've
done
specifically
is
set
Branch
protection
rules,
so
I'll
actually
just
jump
into
what
those
look
like
so
I've
set
Branch
protection
rules
that
require
a
couple
different
things:
I'm,
requiring
a
pull
request
to
happen
and
for
the
for
the
pull
request
to
kind
of
do
the
review
before
I
merge
anything
into
my
production.
A
What
I've
also
done
I've
required
a
couple
status
is
100
the
easiest
way
to
enforce
a
lot
of
these
settings
that
you
want,
or
a
lot
of
the
scans
that
you
want
at
the
pull
request
level
to
make
it
easier
for
a
developer
to
know.
What's
so,
if
you're
expected
to
be
able
to
build
your
job
every
time
you
create
a
PR,
if
you're
expected
to
run
it
should
test
successfully
that's
great,
but
why
not
integrate
some
of
the
security
scans
there?
A
If
you're
expected
to
do
those
anyway
before
you
go
into
production,
environment,
sorry
I
think
the
mic's
going
in
now
great.
So
what
I've
done?
I
set
a
couple
different
things
here,
so
I'll
go
back
into
not
only
what
we've
done
to
create
this,
but
how
did
we
do
this
in
this
example?
Here,
let
me
pull
up
there.
A
We
go
in
this
example
here
I'm
using
GitHub
actions,
it's
open
source
actions
that
are
created
by
a
lot
of
other
vendors,
not
just
GitHub
themselves,
so
it
makes
it
easier
to
understand
what's
going
on
in
that
code
base.
So
what
we've
done?
We
actually
looked
through
some
of
the
capabilities
that
we
can
pull
in
from
the
cloud
native
community,
so
Aqua
Aqua
security
was
doing
some,
creating
some
actions
to
do
the
TF
sex
scans
to
do
their
trivia
scans.
So
what
we've
done?
We've
kind
of
taken
that
and
built
it
out
into
a
code.
A
Ql,
slash,
trivia
dependency
scan
all
in
one
workflow,
so
you
don't
have
to
go
through
and
find
all
the
different
tools
that
you
have
to
work
with
together.
You
can
just
see
them:
All,
In,
One,
Security,
yaml
tool
or
not
tool,
but
security,
Yama
workflow.
So
in
this
example
here
we're
kicking
off
our
code.
Ql
codeql
does
a
code
analysis
of
the
code
and
it
understands
from
form
source
to
sync
where
the
vulnerability
is.
A
We're
doing
a
trivia
scan,
so
we're
scanning
here
not
only
for
vulnerabilities
across
the
board,
but
specifically
vulnerable
is
associated
to
an
image.
So
what
we're
doing
we're,
building
the
image
and
then
scanning
it
at
the
time
of
the
pr
and
then
with
tfsec?
What's
you
saw
earlier
with
the
vulnerabilities
being
posted
right
in
the
pull
request
is
what
we're
doing
is
scanning
terraform
or
infrastructure,
as
code
in
general,
with
tfsec
to
see
these
results
in
the
pull
request
once
more.
A
So
all
of
these,
and
actually
one
more
one
more
that
we're
actually
enforcing,
is
dependency
review.
So
we
want
to
ensure
that
any
dependencies
coming
in
are
also
secure,
so
I'll
pass
this
over
to
Grant
to
kind
of
walk
through
some
of
the
other
example,
pull
requests
that
we've
created.
So
you
can
see
the
vulnerabilities
there.
B
So
let's
say
we
want
to
add
port
in
store
to
basically
check
for
IDs,
maybe
in
in
webhook.go,
and
for
some
reason
we
want
to
store
these
in
a
SQL
database
or
maybe
query
our
database
to
see
if
we've
hit
a
request.
Id
like
something
like
that.
So
this
is
just
a
simple
PR.
What
it's
doing
is
we
have
a
go,
go
file
webhook.go
and
what
we're
doing
is
basically
importing
the
database
SQL
package
as
well
as
just
setting
up
a
database.
B
So
what
we're
doing
here,
we're
just
you
know
creating
a
new
connection
to
a
database,
checking
if
it
if
it
passed
and
closing
the
the
connection
later
on,
but
what
we're
doing
actually
is
we're
checking
the
ID
based
on
the
request
that
comes
in
to
this
function.
So
you
can
go
back
up
here
all
the
way
to
the
top.
B
What
this
is
is
actually
it's
actually
a
HTTP
request
in
the
in
the
header
right
here,
so
we're
taking
input
from
the
HTTP
request
and
you
it's
kind
of
hard
to
kind
of
see
that
through
GitHub,
typically,
but
what's
nice
is
that
inside
with
this
code,
ql
action,
what
you
can
do
is
actually
check
here
and
see.
You
know
this.
Is
you
know
this
is
where
the
query
is
happening
so
what's
happening.
Basically,
is
that
we
have
a
SQL
injection
vulnerability
here,
so
if
any.
B
Okay,
so
yeah.
So
this
is
the
code
ql
kind
of
vulnerable
vulnerability
that
we
found
so
with
code
ql.
It's
basically
detect
it's
gone
through
all
of
our
code,
all
of
our
go
code
and
it's
kind
of
scanned
through
everything.
It's
basically
set
it
in
a
format
and
code
ql
where
it
knows
how
to
kind
of
interpret
this
data
and
then
it
cross-checks
in
a
different
way
to
basically
see
to
basically
see
if
it's
one
of
the
known
vulnerabilities
in
go
in
in
this
case.
A
Sorry
yeah,
so
I
just
wanted
to
show
a
couple
of
different
things.
So
when
you
click
on
show
paths
in
this
step
here,
you'll
see
the
source,
which
is
where
it's
introduced
all
the
way
down
to
the
sink,
where
it's
being
exploited
in
this
case,
there's
only
two
steps,
but
in
many
many
other
cases
you'll
see
maybe
10
steps,
15,
Steps
20
steps,
so
that
here
for
you
as
a
developer,
to
understand.
Okay,
maybe
I
should
be
doing
sanitization
in
Step
number.
A
One
step
number
two
step
number
twenty,
so
it
makes
it
again
easier
for
you
to
understand
where
to
make
that
fix,
but
in
reality
I
mean
in
many
cases.
When
you
first
see
the
vulnerability
alert.
You
see
database
query
built
from
user-controlled
sources
who
understands
what
that
means.
As
a
developer,
I
mean
I
kind
of
understood,
but
I
really
didn't
know
you
make
it.
It's
not
an
easy
thing
to
understand
right
off
the
bat.
A
Until
you
see
a
lot
of
security
teams
will
come
in
and
say:
hey
you
have
a
SQL
injection,
okay
cool
I,
understand
that.
But
what
does
that
really
really
mean?
So
when
we
walk
through
the
analysis,
we
actually
see
that
the
SQL
injection,
what
is
an
example
of
the
SQL
injection,
what
are
some
of
the
recommendations
and
what
are
some
good
and
bad
examples?
B
Yeah
so,
as
Sarah
mentioned,
you
know
that's
kind
of
the
difference
between
myself.
You
know
like
I,
opened
the
poor,
Quest
I'm
familiar
with
that
function,
but
whoever's
reviewing
that
pull
request
might
not
know
that
in
the
beginning
of
that
function,
we're
taking
a
user
input
from
an
HTTP
request.
So
it's
really
just
taking
the
human
out
of
the
equation,
and
you
know
humans
are
vulnerable
to
mistakes,
and
you
know
robots
are
a
lot
less
so
cool.
So
that's
one!
That's
the
first!
B
That's
the
second
one
I
guess
we'll
show
the
next
one
that
I
want
to
show.
Is
you
know?
Let's,
let's
do
something
harmless,
let's
add
Swagger
support
to
our
application.
You
might
think.
Oh
you
know.
I
saw
this
example
on
a
Blog.
Maybe,
like
someone
said
you
know
you
should
add
Swagger
support,
so
they
kind
of
gave
a
code
snippet
on
like
how
to
add
Swagger
support,
which
is
a
very
common
thing
to
do.
You
know
developers,
you
know
everyone
knows
Wheatus.
B
You
know
copy
code
and
then
put
it
in
the
application
and
make
it
work
a
lot
of
times.
So
everyone's
everyone's
definitely
done
that,
and
so
this
is
an
example
of
you
know
what
that
might
look
like.
So
we're
importing
something
called
swago,
Slash,
HTTP
Swagger
on
GitHub
and
we're
just
setting
up
Swagger
we're
we're
adding
a
new
mux.
So
a
new
router
we're
setting
up
the
URL
to
handle
the
Swagger
requests
and
then
we're
just
starting
a
new
Swagger
server.
B
But
the
problem
here
is
that
we're
actually
importing
a
invalid
version
of
of
swagger.
That
has
a
vulnerability.
So
actually,
if
you
go
back
to
the
pull
request,
zoom
in
again,
you
can
actually
go
down
and
you
can
see
that
one
of
our
dependency
checks
failed.
So
it
checked
for
a
dependency
review
and
you
can
see
right
here
that
it
failed.
B
So
if
we
go
ahead
and
check
that
yeah,
we
can
see
that
the
dependency
review
failed,
but
we
can
also
go
back
and
so
now
we've
seen
that
our
dependencies
failed.
So
what
we're
going
to
do
is
go
over
to
our
go.mod
and
we
can
open
up
the
the
rich
text
View
and
we
can
see
that
there
is
actually
a
denial
of
service
and
vulnerability
in
the
version
of
swagger
that
we're
importing.
B
So
you
know
it
might
be
harmless
to
kind
of
expose
Swagger
on
your
API,
but
if
someone
knows
and
they
scan
it
and
they
see
they're
just
scanning
Swagger
endpoints
as
a
hacker
they
could,
they
could
do
a
denial
of
service
on
your
on
your
Swagger
and
if
that
Swagger's
running
on
your
API
server,
now
you
no
longer
can
serve
API
requests
in
your
application.
So
that's
could
be
you
know,
something
is
very
harmless.
Is
you
know
adding
Swagger
support
can
be,
can
add
a
denial
of
service.
So
that's
one
thing.
B
That's
another
thing
we
wanted
to
show
the
next
one
is:
let's
go
ahead
and
you
know
let's
change
our
base
image,
so
you
know
as
a
developer.
You
know
the
nice
thing
about
Docker
is
that
we
can
choose
whatever
base
image.
We
want.
You
know
a
lot
of
times,
we'll
pick
you
know,
whatever
base
image
is
kind
of
the
easiest
to
kind
of
run
our
application.
B
So
you
know
the
pull
request.
Is
you
know
it's
just
a
cleanup
PR
real
easy
as
discussed,
let's
switch
to
a
Ubuntu
Ubuntu
based
image.
It's
way
easy
to
use
right,
but
the
problem
with
this
is
that
we're
actually
importing
a
version
of
Ubuntu
that
has
some
vulnerabilities
in
it.
So
let's
go
ahead
and
see
what
the
vulnerability
scan
was.
B
So
in
this
case
it
actually
passed.
But
the
reason
for
that
is
that
the
vulnerabilities
that
came
up
were
immediate,
medium
and
low,
so
there
were
medium
and
low
vulnerabilities,
so
we
still
let
it
pass,
but
it's
still
important
to
know
what
all
of
the
different
security
vulnerabilities
are
when
you're
kind
of
doing
this.
But
let's
say
you
switch
to
a
base
image
and
there
were
high
vulnerabilities
in
that.
Maybe
it
was
an
unpatched
version
of
an
OS
or
maybe
it
was
a
less
known
kind
of
Base
image
that
had
a
lot
of
problems.
B
You
could
see
how
a
case
like
this
could
very
easily
make
your
Docker
image
vulnerable
to
attacks,
but
let's
quickly
go
ahead
and
show
that
this
one
there's
15
new
alerts.
So
in
this
case
it
didn't
it
didn't
fail
to
build
because
they're
only
medium
at
low,
so
we've
set
image
We've
set
that
build
process
to
only
fail
if
it's
a
high
or
critical
vulnerability.
But
it's
still
good
to
know
that
you
know
all
of
these
CVS
are
you
know
in
the
image
that
we've
seen
seen
below?
B
So
as
you
can
see,
yeah
there's
the
a
lot
of
problems
with
the
image
the
trivia
is
detected
as
well
as
code
scanning
so
yeah.
So
this
PR
introduced
that
cool,
so
I
think
that
was
one
of
the
last
ones.
Let
me
go
back
and
check
cool,
so
yeah.
Those
were
all
of
the
examples
that
we
wanted
to
show.
So
we
also
have
some
depend
about
oprs
open
as
well.
B
A
All
right,
so
what
what
we
just
demonstrated
are
four
different
pull
requests
that
were
triggered
just
with
one
one
yaml
file
like
one
automation.
We
didn't
have
to
do
too
much
work
to
enable
this.
This
was
just
a
great
example
of
how
you
can
just
automate
a
lot
of
these
pull
requests
or
automate
a
lot
of
these
scanning
within
the
pull
request
by
just
adding
one
or
two
or
three
components
within
your
security
scans
in
the
in
the
in
the
time
of
the
pull
request.
A
So
what's
really
nice
about
this
is
when
we
go
back
into
our
yaml
files.
Here
you
don't
have
to
do
this
only
with
GitHub,
but
with
GitHub
actions.
You
can
just
kick
it
off
right
off
the
bat
too.
So
you
can
do
this
with
Jenkins,
because
I'm
sure
a
lot
of
your
pull
requests
require
maybe
a
status
check
on
Jenkins
or
if
you're,
using
Circle,
Ci
or
Travis,
CI
and
so
forth.
But
what's
really
nice
is
that
it
makes
it
easier
to
understand
again
what's
required.
A
What
do
you
need
and
the
requirement
is
no
secure,
no
vulnerable
code
in
your
code
base?
What's
the
threshold
medium
high
low
can
I
push
some
code
with
medium
vulnerabilities,
your
security
team
might
say
yes,
but
at
all
times
when
has
as
you
as
a
developer,
when
have
you
actually
thought
of
integrating
security
earlier
on?
Have
you
done
that
and
raise
your
hand
if
you
have
Incorporated
some
of
your
security
scans?
That's
great!
How
often
do
you
work
with
your
security
team
to
understand
what
these
vulnerabilities
are?
A
Okay,
a
little
less.
So
what
does
that
mean?
It
means
there's
it's
not
always
a
shared
responsibility.
So,
at
the
point
of
time
you
have
a
lot
of
vulnerability
set
up
and
you're
getting
all
these
vulnerabilities.
You
might
get
be
getting
like
a
thousand
vulnerabilities
all
in
one
place,
but
how
do
you
make
them?
How
do
you?
How
do
you
only
see
them
but
actually
fix
them?
That's
that's
the
Crux
here
like
how
do
you
actually
get
to
fix
the
vulnerabilities?
A
So
if
we
go
back
to
our
slides
here
and
what
we
actually
showed
was
a
successful
workflow,
the
scans
running
at
that
time
and
merging
the
code,
but
some
of
the
takeaways
are
what
we
were
able
to
do
is
actually
fix
these
vulnerabilities
with
the
right
context
at
the
right
time.
If
you
are
actually
running
the
scans
on
the
pr.
What
you
probably
want
to
do
is
to
only
scan
the
new
code,
changes
that
you're
introducing
you
don't
want
to
scan
the
whole
code
base
every
single
time
and
give
a
thousand
responses
around
okay.
C
A
You
want
to
do
is
maybe
try
scope
down
what
all
the
new
changes
that
you're
making.
So
then
that
makes
it
easier
for
you
to
process
the
results
from
the
pull
request.
So
if
you
have
a
couple
of
results
being
able
to
understand
what
those
results
are,
that
means
you
are
able
to
fix
those
results.
So,
within
a
couple
of
minutes
or
a
couple
of
hours
within
one
pull
request,
you
are
able
to
have
the
right
context
and
have
the
information
at
the
right
time
to
make
those
fixes.
A
A
We
want
to
make
sure
that
there
are
some
Branch
protection
rules
or
some
rules
that
will
allow
you
to
enforce
certain
standards,
because
when
you
enforce
those
standards,
it
makes
it
more
transparent
what
the
requirements
are,
and
it
also
makes
it
easier
to
get
going,
not
just
being
blocked
on
certain
things
and
at
the
end
of
the
day,
we
want
to
make
it
easy
so
doing
at
the
pull
request.
It's
right
when
a
developer
such
as
ourselves,
wants
to
contribute
code
back
and
is
ready
to
receive
feedback,
but
that's
when
we
also.
A
We
want
to
incorporate
security
to
add
that
feedback
in
the
pull
request.
So
now
you
not
only
make
it
easier
to
collaborate
and
have
that
conversation
with
the
security
and
the
developer
teams,
but
if
somebody's
new
to
the
team
and
doesn't
know
how
it
was
done
before
they
can
go
back
into
support.
Since
you
were
where
it
happened
in
the
previous
session,
so
then
they
can
learn
from
that,
so
they
can
always
reference
back
to
it
and
with
that
I
think
we
have
a
couple
of
minutes
left.
So,
let's
move
over
to
q.
C
Yeah,
thanks
for
the
talk
actually
I,
have
a
question
regarding,
like
from
your
experience,
how
many
false
positives
have
have
you
been
seeing
with
these
checks
and
how
configurable
are
they
in
terms
of
like
the
transparency
as
a
platform
developer
or
a
security
engineer?
Like
can
I
just
pick
and
choose
like
what
are
all
the
checks
they
can
do.
Etc
Great.
A
Questions
very
configurable,
the
answer,
so
the
question
is:
how
is
it
to
how
easy
is
it
to
configure
if
you
don't
want
to
run
all
those
checks
and
if
there's
a
lot
of
false
positives?
So
when
we're
talking
about
code
ql
in
this
example
here,
let
me
pull
that
up
and
just
go
back
into
our
pull
request.
It's
actually
very
easy.
Most
of
the
capabilities
are
most
of
the
actions
and
the
flows
are
open
source.
A
So
what
you
can
see
here,
for
example,
into
the
example
here
when
you
see
oops
sorry
doing
it
on
a
different
laptop,
is
a
little
bit
harder.
When
you
see
the
results
here,
you
can
actually
jump
in
and
view
the
source
so
code.
Ql
queries
are
open
source,
they're
developed
not
only
by
GitHub
by
code,
by
Microsoft,
by
Uber,
by
Google
and
so
forth.
So
these
queries
are
open
source,
so
you
can
actually
take
them
and
customize
them.
B
Yeah
individual
actions.
They
also
have
a
lot
of
configurations
in
the
yaml
that
you
can
change
to
so
in
the
code,
but
also
they
off
like
expose
different
ways
to
do
scanning.
So
we've
configured
one
of
the
alerts
to
only
fail
on
high
and
critical.
So
that's
an
example
of
a
configuration
that
we
did
any
other
questions.
Yeah.
D
A
That's
a
good
question
so
depends
on
what
you're,
using
if
you're,
using
something
like
actions.
You
can
monitor
exactly
where
your
code
is
being
managed
and
where
it's
kind
of
being
pushed
you
can
monitor
the
in
ingressa
Negros
of
the
actual,
like
VM
or
Runner,
that
you're,
using
from
the
perspective
of
what's
going
on
in
the
actual
action
itself
like
the
actual
component.
All
of
them
are
open
source,
so
you
can
actually
run
validations
and
security
scanning
against
it.
A
For
example,
a
lot
of,
if
we're
talking
specifically
about
actions,
a
lot
of
the
actions
are
built
in
y'all,
going
to
the
open
source,
one
of
the
tf7,
for
instance,
or
the
trivia
one
here,
you
can
actually
see
exactly
what's
going
on.
So
if
you
go
into
this
trivia
action
here,
if
you
go
to
github.com.
A
Take
that
out
and
paste
the
action's
name,
you
can
actually
see
you
can
see
exactly
what's
going
on,
I
think
that's
the
again
power
of
community
is
that
you
can
it's
not
a
black
box.
You
can
go
into
it
and
see
it
and
then,
if
you're
doing
monitoring
of
your
Runners,
these
are
all
running
in
a
CI.
So
if
you're
doing
some
monitor
of
your
Runners,
you
can
see
all
the
information
flowing
in
and
out
of
those
Runners,
depending
if
you're,
using
like
Jenkins
or
Jarvis
or
so
so.
A
Sorry,
these
actions
here
that
we're
using
we're
actually
pulling
them
specifically
from
just
common
knowledge.
I
know:
Aqua
security
is
a
company
that
is
doing
a
lot
of
these
capabilities,
so
I
go
to
the
aqua
security
side
and
I
get
the
action.
I
might
not
go,
get
an
action
from
somebody
that
I
don't
know
if
it's
an
individual
user
without
me
doing
my
own
scanning
and
validation
of
that
action.
E
B
Yeah
I
know
specifically
the
code
QR,
one
I
think
you
can
definitely
check
and
only
to
run
the
check
against,
like
certain
packages
that
have
been
changed
so
I
know.
That's
definitely
configurable
with
that.
One
specifically,
but
we'd
have
to
check
on
all
the
individual
actions
and
see
if
they
support
that
I.
Think
yeah
we've
had
another
question:
yeah.
F
Hey
so
in
our
org,
we
do
a
lot
of
this
already.
So
we
have
this
as
the
build
in
PR
level.
You
got
your
all
sorts
of
scanning,
so
it's
very
familiar
to
me,
but
as
the
organization
scales
and,
as
we
add
more
Integrations
and
more
scanning,
naturally
the
more
smoothly
and
perfectly
everything
runs
right.
F
So
it
creates
a
load
on
our
devops
teams,
particularly
myself,
to
deal
with
all
the
failures
that
do
happen
and
developers
aren't
intimately
familiar
with
all
these
checks
right
so
where
my
head
is
at
is
I'm
thinking
about
shifting
that
even
farther
left.
So
you
have
like
your
IDE
extensions
for
like
sonar
Cube,
sonar,
Lane,
Snick
and
then
using
git
hooks
as
well.
Have
you
guys
thought
about
that?
Have
you
guys
thought
about
shifting
that
even
more
left,
so
developers
get
a
quicker
feedback?
Loop.
A
Great,
that's
a
wonderful
question.
Yes,
we
have
thought
about.
It.
I
think
that
there
are
certain
points
in
time
where
that
that
might
be
helpful.
What
we've
seen
is
that
developers
usually
get
frustrated
when
they're
getting
alerts
in
their
IDE
when
they're
trying
to
kind
of
go
with
their
flow,
like
they're,
trying
to
think
through
their
feature,
add
new
capabilities,
and
they
just
they're
not
ready
to
receive
a
lot
of
the
feedback
so
a
lot
of
times.
It
adds
more
friction.
A
So
at
the
pull
request
is
when
we
saw
there's
a
lot
more
acceptability
to
receive
feedback
and
that
that
point
of
feedback,
your
case
like
some
of
it,
is
because
there's
never
going
to
be
a
hundred
percent
accuracy
in
all
the
things
that
you
run.
So
if
there's
any
chance
of
as
false
positive,
then
running
in
the
ID,
it's
not
worth
it,
but
at
the
pull
request,
it's
a
little
more
flexible
because
people
are
ready
to
receive
feedback
and
then
they
can
follow
a
process
that
you
can
automate
some
of
the
processes
right
after
that.
A
Pre-Commit
pre-commit
Works
for
an
extent
of
time,
right,
pre-commit
works
when
it's
high
vulnerabilities
or
some
other
type
of
like
critical
ones,
not
necessarily
at
medium
or
low,
because
if
you
do
a
pre-commit
you're
blocking
every
single
time,
you're
blocking
a
developer
from
maybe
it's
not
a
vulnerability,
and
maybe
it
is.
But
maybe
the
developer
is
working
on
like
midnight
versus
working
at
like
6
a.m.
A
When
maybe
the
security
team
is
not
there
to
discuss
it
so
doing
it,
pre-commit
means
that
the
developer
never
pushes
their
code
into
your
environment,
so
pre-commit
Works
to
an
extent
I
think
what
works
for
pre-commit
is
if
you're
doing
Secret
scanning,
if
you're
scanning
for
secrets-
and
you
don't
want
to
expose
any
secrets-
that's
one
pre-commit
words,
but
for
code
scanning
specifically
and
vulnerability
scanning.
It
doesn't
always,
especially
when
you
talk
about
image
scanning
and
infrastructures
code
scanning.
That's
definitely
not
a
pre-commit
thing.
In
my
mind,.
A
Awesome
what
we
also
did
is
made
this
public,
so
you
can
go
see
what
we've
done
in
our
code
base
and
if
you
have
any
feedback
to
our
presentation.
I
know
a
lot
of
people
left
already.
But
if
you
have
any
feedback
for
a
presentation
feel
free
to
scan
the
QR
code,
I'm,
not
sure
if
you
can
see
it
anymore,
but.