►
Description
Are your CI/CD Pipelines Secure? - Angel Rivera, CircleCI
Speakers: Angel Rivera
Most CI/CD pipelines used by DevOps teams utilize integrations with services such as APIs, databases and other critical systems to complete their workflows. These integrations usually required the use of extremely sensitive secrets such as passwords, tokens or certificates and must be securely protected at all times. Unauthorized access of these pipeline secrets open these systems to threats from bad actors and illegal access of data. In this talk Angel will discuss common pain points in properly securing applications, CI/CD pipelines and protecting sensitive access gates to integration targets. Attendees will learn strategies to secure their applications, sensitive data and pipeline integration points. Attendees will leave with a better understanding of how to implement security layers that can improve their pipeline security posture.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
Currently,
I'm
working
for
circle
ci,
which
is
an
awesome
job
working
as
a
as
a
developer
advocate.
So
I
get
to
engage
the
developer
community
learn
how
people
are
using
technology
learning
about
some
of
the
awesome
things
they're
doing
with
the
technology,
as
well
as
some
of
the
obstacles
and
issues
that
they're
encountering
with
technology.
So
it's
a
nice
role
to
be
in
to
understand
you
know
throughout
the
whole
industry.
A
A
A
A
The
problem
with
the
waterfall
development
process
was
our
methodology
was.
Is
that
everything's
kind
of
interdependent
right,
so
tasks
that
are
doled
out
to
teams
have
to
be
completed
before
another
team
can
start
working
on
another
task
within
that
waterfall
development
methodology
right
so
everything's,
kind
of
interdependent
and
kind,
and
the
tasks
are
then
or
the
green
lights
for
tasks
are
then
cascading
right.
A
We
got
a
little
bit
smarter
and
we
realized
that
the
waterfall
methodology
was
slowing
us
down
way
too
much.
So
what
had
started
to
happen
was
developers,
you
know
in
the
space
and
and
thought
leaders
in
the
space
were
developing
these
new
ways
to
develop
software
that,
were,
you,
know,
faster
and
more
efficient.
A
So
that's
where
the
agile
development
methodology
was
kind
of
born
out
of
right
is
basically
the
ability
to
take
those
big
tasks
that
were
you
know,
kind
of
pushed
down
to
us
through
the
waterfall
development
process
and
breaking
them
out
into
smaller,
more
magic,
manageable
tasks
right.
So
it's
just
like
anything
right.
A
It's
almost
like
the
agile
methodology
can
be
at
least
I
I
kind
of
interpret
it
as
a
concurrency
right,
so
the
ability
to
leverage
concurrency
doing
things
at
the
same
time
multitasking
and
that's
essentially,
what's
at
the
heart
of
at
the
agile
development
methodology
right.
It's
the
idea
that
you
can
do
multiple
things
at
the
same
time
as
long
as
you
break
those
tasks
out
into
smaller,
more
manageable,
bytes
right,
so
you
can
get
more
productivity
out
of
developers.
A
If
you
can
look
at
this,
this
diagram,
you
can
see
a
lot
of
movement
right,
a
lot
of
circles
with
arrows.
A
lot
of
you
know
smaller
sub
bubbles,
I
guess
or
circles
that
are
attached,
but
all
the
while
everything's
connected
right.
So
you
know
again
with
the
advent
of
the
agile
development
methodology.
A
Things
just
got
done
faster
right
because
they
were
broken
down
into
smaller
chunks
and
again,
if
you
had
a
you
know,
pretty
good-sized
development
team,
you
you're
iterating
iteratively
working,
so
that
folks
were
just
you
know,
finishing
tasks
off
and
then
going
back
and
getting
another
one.
All
the
while
things
are
being
you
know,
pushed
through
the
whole
process
so
again,
right,
agile
versus
waterfall
waterfall
is
a
cascading
dependent
type
of
methodology
where
you're
blocked
generally.
A
If
something
is
not
completed,
the
other
teams
can't
get
started,
whereas
agile
everything
is
happening
at
the
same
time
and
speeds
things
up,
makes
things
more
efficient
overall.
So,
with
that
pattern
of
agile
software
development
came,
you
know
this,
this
new
concept
of
continuous
delivery.
So
not
only
are
we
developing
software
faster,
because
you
know
we
we
make
things
kind
of
we
broke
them
apart,
decompose
them
into
smaller
chunks,
and
then
people
can
work
on
them
and
then
they
iteratively,
you
know
changes
were
pushed
back
into
the
main
made
cone
branch.
A
Continuous
delivery
offers
us
that
same
kind
of
pattern
right,
so
we
were
able
to
now
take
what
we've
done
in
principle
with
software
and
then
apply
those
same
concepts
to
the
delivery
of
that
code.
Right
so,
in
a
technical
aspect,
once
we
start
building
the
code,
we
could
actually,
you
know
continuously
deliver
that
that
those
changes
right.
So
that's
where
that
continuous
delivery
kind
of
comes
from
and
then
from
there
continuous
integration
and
continuous
deployment
kind
of
was
born
out
of
right.
A
I
call
it.
The
continuous
integration
infinity
loop
right
and
you
can
see,
there's
tasks
right,
like
a
planning
code,
build
test.
Those
are
all
morph,
developer,
centric,
right
and
the
continuous
integration
side,
and
then
the
release
deploy,
operate
and
monitor
sections
kind
of
relate
to
the
operation
side
right
and
by
the
way
this
is
not
set
in
stone.
This
is
just
a
general
kind
of
concept
so
that
folks
can
visualize
and
understand
the
cicd
and
devops
relationship
so
with
a
continuous
integration
on
the
development
principles
right.
A
A
Diagram
that
I
shared
right,
things
are
constantly
moving
constantly
being
pushed,
and
a
lot
of
things
are
being
done
at
the
same
time,
so
taking
that
agile
methodology
pushing
it
down
into
the
way
we
collaborate
around
code
is
continuous
integration,
and
these
are
just
again
in
principle
only
right
right
now.
What
I'm
talking
about
just
principles?
A
And,
finally,
the
one
of
my
most
favorite
benefits
of
continuous
integration
is
fast
feedback
loops.
What
I
mean
by
that
is
being
able
to
understand,
what's
happening
with
your
software
know
as
quickly
as
possible,
when
you
have
issues
with
your
software
right.
So
that's
basically
continuous
integration
is,
is
again
right,
writing
and
committing
code
as
often
as
possible
to
a
shared
repository
testing
that
code
and
then
being
able
to
get
feedback
on
those
changes
as
quickly
as
possible.
A
With
continuous
deployment
like
again
more
more
on
the
operational
side
of
things
as
principles
go,
it
enables
you
to
create
these
release,
artifacts
right
for
your
for
your
deployment
processes,
and
it
also
allows
you
to
deploy
those
code
artifacts
right
or
those
artifacts
to
resources.
So
that
means
you
know
pushing
this
newly
changed
and
packaged
up
code
up
to
maybe
a
kubernetes
server
or
such
then.
A
So
again,
these
are
just
in
in
principle
right,
but
in
order
to
make
all
of
this
a
reality
right,
we
have
to
leverage
automation.
So
we
can
talk
about.
You
know,
sharing
code
and
collaborating
around
code
and
feedback
loops,
but
none
of
it
is
possible
without
automation,
which
means
we
have
to
put
some
sort
of
technology
behind
it.
A
And
that's
where
you
know
the
concept
of
ci
cd
pipelines
come
in,
so
we
talked
about
continuous
delivery,
continuous
integration,
continuous
deployment
and
I'm
sure
you've
heard
the
term
pipelines
and
that's
what
pipelines
kind
of
do
is
take
all
of
those
processes
that
you're
using
automation
on
right
or
using
to
automate
and
then
kind
of
lumping
them
all
together
in
a
in
a
logical
kind
of
grouping
right.
So
here's
what
a
continuous
integration
continuous
deployment
pipeline
looks
like
in
the
circle.
A
Ci
dashboard,
as
you
can
see,
there's
a
couple
of
blocks
of
things
there.
Those
are
jobs,
so
these
are
actions
that
need
to
be
need
to
take
place
in
my
ci
cd
pipeline
right.
So
this
is
what
I
talked
about:
adding
the
automation
to
my
processes.
This
is
exactly
what
I
mean
by
that
is
running.
You
know.
A
First,
you
have
to
code
up
or
configure
your
pipeline
to
to
basically
define
these
actions
and
then
running
them
through
the
automation
is
where
circle
ci
comes
in
and
provides
the
tooling
to
do
that,
and
you
know,
if
you're,
using
any
kind
of
tools
right
now,
you
may
have
a
different
kind
of
dashboard,
but
for
the
most
part
they
all
have
similar
dashboards
and
kind
of
notification
platforms.
Right
but
again,
this
is
just
a
ci
cd
pipeline
shown
in
the
servo
ci
dashboard.
A
Definitely,
you
know,
require
you
to
connect
to
external
systems,
some
of
them
being
right.
These
are
some
of
the
types
of
integrations
that
occur
within
pipelines.
You
know
app
code
coverage
tools,
so
you're
checking
your
code
within
those
toolings
you're,
doing
vulnerability,
scans
right
using
tools
within
your
pipeline.
A
Api
requests-
maybe
you're
calling
out
to
someone,
but
some
other
service
right
to
get
information
to
get
data
that
you
use
in
your
pipelines,
you
know
and
on
and
on
it
can
go
on
and
on,
but
basically
your
pipeline,
you
know
when
you're
using
the
automation
is
definitely
gonna
integrate
with
a
lot
of
other
things,
another
service,
so
I
talked
about
devops
lately.
But
what
I
want
to
jump
in
on
here
is
a
this
term
devsecops
right.
A
So
when
devops
was
or
yeah
being
adopted
or
implemented,
security
has
always
been
there
as
part
of
an
element
of
devops,
but
I
don't
it
wasn't
really
focused
in
on
right.
I
think
folks
were
just
you
know
getting
their
heads
around
this
culture
shift
in
this
devops
space
and
security
is
one
of
those
things
where
you
know.
A
I
don't
know
about
you,
but
I've
been
in
an
organizations
where
security
teams
and
and
or
you
know,
organizations
within
security
organizations
within
a
company
or
other
other
entities,
they're
kind
of
separated
out
right
for
whatever
reason,
they're
just
kind
of
on
their
own
and
almost
like
an
afterthought.
In
some
cases,
I
hate
to
say
that,
but
you
know
you're
generally,
security
practices
or
actions
are
taken
at
the
very
end
of
towards
the
end
of
a
software
release,
but
with
devsecops.
A
You
know,
there's
this
concept
of
kind
of
bringing
those
actions
to
the
forefront
of
things
right.
So
no
longer
are
you
waiting
to
the
very
end
to
perform
scans
and
and
such
on
your
on
your
code.
The
idea
of
shifting
left
means
moving
those
actions
to
the
forefront
right
so
to
the
beginning
of
your
ci
cd
pipelines
and
not
towards
the
end.
A
A
That
can
come
in
many
different
forms
right.
So
one
of
the,
I
guess
general
terms
I
use
for
that
is-
is
pipeline
security
scans
right.
So
now,
with
all
this
awesome,
tooling,
that's
coming
around
developers
are
now
more
educated
and
more
empowered
to
be
able
to
partake
and-
and
you
know,
be
a
little
bit
more
invested
in
ensuring
that
the
tooling
and
the
code
that
they're
writing
is
actually
on.
You
know
is
secure.
A
A
But
what
I
want
to
talk
about
now
is
actually
securing
pipelines
right.
So
what
I
talked
about
was
kind
of
more
code-centric,
which
still
I
consider
securing
pipelines,
but
again
it
was
more
of
a
focus
on
like
shifting,
left
and
understanding
what
that
means.
But
what
I
want
to
talk
about
now
is
one
of
the
most
painful.
A
Those
secrets
must
be
protected,
otherwise
you
risk
an
exposure
right
or
vulnerability
or
an
accident
where
bad
actors
can
gain
access
to
your
pipelines
and
your
operations,
which
is
which
is
pretty
bad
right.
If
that
happens,
some
of
the
problems,
though,
with
ci
cd
tooling
today
and
the
way
we
manage
those
pipelines
is,
is,
is
pretty
pretty
obvious
right
and
actually
not
very
new.
So
what
I
have
up
here
is
you
know.
A
Another
piece
that
is
is
something
that
I
I
kind
of
want
to
address.
Is
you
know
when
you
have
those
secrets,
even
like
let's
say
the
secrets
are
generally
stored
securely
in
these
cicd
platforms
and
again
right
your
pipeline
jobs?
Not
all
of
them
need
secrets,
but
some
of
them
do
and
the
ones
that
access
generally
the
ones
that
access
integration,
services
or
services
or
integrate
with
something
need
secrets
right
to
access.
A
One
of
the
things
that
is
currently
happening
within
pipeline
cicd
platforms
is
that
the
secrets
that
we
have
for
those
integration
points
are
stored.
You
know,
on
the
platform
securely
right,
they're
on
disk
at
rest,
they're
secure
when
the
ci,
cd
pipeline,
automation
or
or
the
jobs
need
any
secrets.
Then
they're
pushed
from
that
secure.
A
You
know,
sitting
at
rest
and
they're
pushed
through
the
wire
in
flight
they're
secure
as
well,
but
once
it
hits
the
run
time
where
your
your
cicd
jobs
are
running,
then
they
are
unencrypted,
obviously
right,
so
that
the
systems
can
then
leverage
those
credentials
and
pass
them
on
to
do
whatever
transaction.
They
need
to
do
against
that
system,
and
then
they
should
go
away.
A
A
So
you
know
you
store
your
secrets
in
this:
the
secrets,
management
tool
and
then
you're
able
to
then
have
your
pipelines,
call
that
tool
and
pull
in
secrets
when
it
needs
to
when
you're
leveraging
a
tool
like
that
right,
you're
gonna
be
able
to
do
things
like
generate
random,
strong
secrets
right
and
that's
a
really
cool
thing,
because
the
system
will
then
do
that.
For
you
right,
you
don't
need
to
have
a
manual
interaction
with
with
with
generating
these
secrets.
A
You
don't
you
know
you
won't
you
don't
have
to
create
something
that
you'll
memorize
you
just
let
the
system
do
that
for
you
and
the
system
will,
then
you
know
be
able
to
do
what
we
call
auto
rotation.
So
not
only
are
they
generating
strong
random
secrets
for
you,
they
can
actually
rotate
those
secrets
based
on
a
policy
that
you
you,
you
specify
right.
So,
in
one
case,
I
had
a
customer
tell
me
that
they
hadn't
changed
secrets
in
their
pipelines
in
five
years
and
when
I
asked
them,
why
why?
A
Why
would
you
let
that
you
know
last
for
that
long?
Their
response
was
well,
I'm
afraid
of
what
it
will
break.
If
I
change
those
secrets
right
so
again,
one
of
the
things
that
we
should
be
looking
for
is
you
know
refreshing,
generating
new,
strong
random
secrets
and
then
also
have
the
capability
to
auto
rotate
those
secrets
so
that,
when
your
pipelines
call
out,
you
know,
need
to
call
into
another
system.
You've
got
some
fresh
credentials
that
are,
you
know,
generally
rotated
out.
You
know
anything
right
now.
A
So
this
is
great
for
auditing.
If
you're
in
a
regulated
space,
which
I
think
anyway,
it
doesn't
really
matter
if
you're
on
a
regular
space
anymore,
you
definitely
want
to
know
if
you're
implementing
one
of
these
secrets
management
tools.
You
definitely
want
to
know
who's
got
access
to
what
and
control
that
access
right.
A
So,
with
the
secrets
management
tool,
that'll
help,
you
immensely
right
keep
can
keep
an
audit
trail
of
what
secrets
are
out
there,
how
the
secrets
are
being
doled
out
who
has
access
to
the
secrets,
as
well
as
being
able
to
revoke
any
secrets
that
maybe
get
exposed
right.
So
if
some
bad
actor
gains
access
to
a
secret
that
was
doled
out
by
this
system,
you
should
be
able
to
quickly
and
easily
go
in
and
revoke
those
and
reissue
a
new
control,
new
secrets
right.
A
So
basically
that
was
the
presentation
on
a
whole.
I
just
want
to
recap
some
of
the
stuff
I
talked
about.
Let's
talk
about
cicci
principles
for
the
most
part
right,
it's
when
you're
writing
and
committing
code.
Often
it's
a
great
way
for
your
teams
to
collaborate
around
code,
and
that
usually
means
that
you
have
to
commit
your
code
as
often
as
possible
into
a
shared
code
repository.
A
You
definitely
want
to
produce
some
sort
of
test
execution
on
your
code
on
every
commit
so
that
you
can
work
that
into
your
cicd
pipelines
and
then.
Finally,
my
favorite
feature
of
ci
is
the
fast
feedback
loops
right,
knowing
when
your
code
is
passing
or
failing
right,
but
failure
is
for
me,
I
think,
more
valuable,
obviously
than
passing,
because
when
you
have
a
failure,
some
people
take
it
as
a
negative
right
like
oh,
my
my
code
is,
is
jacked
or
whatever
I'm
here
to
tell
you
that
failure
is
good
right.
A
That
tells
you
that
something's
wrong
and
you're
not
pushing
bad
code
right
into
into
a
release.
So
look
at
look
at
failure,
as
a
good
thing
is,
is
my
advice
to
you
when
it
comes
to
continuous
deployment.
You
know
again,
that's
just
the
ability
to
create
release
artifacts
for
your
your
deployment
processes.
It
allows
you
to
validate
those
artifacts
right
and
ensure
that
you're
able
to
deploy
to
that
artifact
to
whatever
target
environment
could
be
a
kubernetes
cluster.
A
It
could
be
just
a
straight
up:
nginx,
maybe
a
a
lamp
server
somewhere
right.
Whatever
the
the
target
is,
you
know
you
can
use
continuous
deployment
mechanisms
to
again
validate
the
applications,
make
sure
your
services
are
functioning
and
also
help
you
to
achieve
the
application
state
that
you
desire
and
if,
if
time
permits
right,
you
can
add
a
layer
of
failover
or
recovery
right.
A
You
know,
shift
left
principles
and
security
to
scanning
containers
right
and
pretty
much
any
kind
of
transaction
within
your
automated
pipelines.
You
can
apply
devsecops
too
right
and
and
also
that
shift
left
mentality
and
then
securing
pipelines
right
really
simply
just
implement
a
secrets,
management
tool
right
and
and
adjust
it
to
to
use
the
policies
that
make
sense
to
you,
integrate
that
secrets
management
tool
into
your
ci
cd
pipeline,
so
that
you
can
use
that
to
generate
strong
random
secrets
and
or
credentials
right,
and
then
you
can
manage
those.