►
Description
Presented by: Stephanie Wong
GitHub Actions is the building block that allows Google customers to use Google Cloud products in a seamless way right from their source code. In this session, Google Cloud Developer Advocate Stephanie Wong will share some security principles and frameworks on how to take small steps to improve your security posture incrementally and how to incorporate these practices into your Actions.
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
A
Hey
everyone,
I'm
Stephanie,
Wong,
a
developer
Advocate
at
Google
cloud,
with
a
mission
to
blend
storytelling
and
Technology
to
inspire
developers
like
you,
we
have
a
team
of
folks
that
create
GitHub
actions
to
support
customers.
We
also
use
actions
and
workflows
internally
to
test
our
open
source
projects.
Just
like
you,
I
want
to
focus
on
features
or
writing
actions
and
workflows
that
help
customers
and
my
team
thinking
about
security
does
slow
me
down,
but
I
have
to
think
about
how
someone
might
use
my
work
or
my
testing
infrastructure
in
malicious
ways.
A
So
I
have
to
care
about
security.
I
want
to
help
you
think
about
all
of
the
ways
that
you
can
apply:
security
principles
and
Frameworks
to
writing
your
actions
by
sharing
our
experiences.
Now
this
is
a
101
level.
Talk,
so
I
won't
be
telling
you
how
to
secure
your
code
and
artifacts,
but
I
will
provide
you
with
an
introduction
to
concerns
to
think
about.
Let's
talk
about
infrastructure
security,
infrastructure
security
is
about
reducing
risk
to
the
Computing
environments,
production
or
testing
software
and
data
for
your
organization
from
har
term
theft
or
unauthorized
access.
A
Think
back
to
the
1983
movie,
War
Games
Seattle
high
school
student,
David
Lightman
used
a
computer
to
automatically
scan
and
dial
telephone
numbers,
one
of
those
numbers
connected
to
a
supercomputer
that
gave
him
access
to
what
he
thought
was
a
game.
In
reality,
it
was
a
simulation
that
was
feeding
incorrect
information
to
the
North
American
Aerospace
Defense
command.
While
this
was
a
movie,
this
was
a
common
Avenue
of
attack
in
the
80s
now
with
broad
internet,
interconnected
systems
and
software
created
by
many.
The
vectors
of
vulnerability
for
any
system
are
broad.
A
It's
not
just
the
live
system
in
production,
that's
vulnerable
to
automated
malicious
attacks.
Now
your
system
and
the
software
you
build
are
vulnerable
from
development
to
production.
It's
easy
to
focus
on
what
you're
Building,
without
considering
how
users
will
use
the
software
or
service
in
practice.
One
of
the
reasons
that
I'm
in
devrel
is
to
take
on
the
zeroth
customer
mantle
and
try
things
out,
but
I'm,
just
one
person
and
I
know
that
there
are
a
lot
of
of
other
ways.
People
will
use
things.
A
It's
not
enough
to
say
don't
do
that
when
it
comes
to
causing
harm
to
someone's
infrastructure,
and
so
we
try
to
take
a
systematic
approach
to
security
when
building
actions.
Additionally,
with
more
and
more
people
leveraging
the
benefits
of
ephemeral
resources,
for
example,
Docker
and
kubernetes,
the
value
of
attacking
instances
has
decreased.
There
is
no
guarantee
that
they'll
be
able
to
find
vulnerability
and
have
time
to
access
the
valuable
data.
Instead,
attackers
have
started
focusing
earlier
in
the
software
development
life
cycle
because,
instead
of
finding
existing
vulnerabilities,
they
can
insert
them
and
compromise
more
systems.
A
Let's
look
at
visualizing
the
various
components
of
building
software.
There
are
a
lot
of
places
that
a
malicious
actor
could
Target
your
software.
First,
a
malicious
actor
could
submit
pull
requests
to
exploit
continuous
integration
runs
that
have
excess
privileges.
They
could
compromise
their
software
Source
control
system
in
2021.
The
PHP
programming
language
maintainers
discovered
that
their
self-managed
git
server
had
been
compromised.
The
attack
targeted
the
popular
z-lib
Library,
turning
any
server
that
used
this
compression
Library
into
a
remote
web
Shell
through
which
attackers
could
execute
any
command
without
authentication.
A
This
led
to
the
PHP
team
migrating
to
GitHub
for
the
canonical
PHP
releases,
because
maintaining
their
own
git
infrastructure
was
an
unnecessary
security
risk.
Attackers
could
compromise
your
build
system
in
2020
software
updates
were
sent
out
to
solarwinds
customers
after
malicious
actors
injected
code
into
their
build
system.
Attackers
can
compromise
package
manager
accounts.
This
happened
to
an
npm
account
due
to
an
expired
domain,
and
the
attacker
reset
account
passwords
attackers
could
compromise
third-party
software
dependencies
that
your
software
relies
on
to
work.
An
example
of
this
is
typo.
A
Squatting
in
July
researchers
uncovered
a
widespread
campaign
to
install
malicious
npm
modules
that
would
Harvest
sensitive
data,
and
it's
even
more
complicated
than
this.
While
we
like
to
visualize
software
builds
as
a
linear
process,
they
are
not.
Each
project
has
multiple
dependencies
which
could
have
multiple
dependencies
of
their
own
each
one
with
their
own
build
and
release
practices.
A
vulnerability
in
a
dependency
in
any
one
of
those
systems
can
affect
everything
Downstream
and
have
huge
effects,
and
software
supply
chain
attacks
are
increasing.
A
As
I
mentioned,
it's
easier
and
more
valuable
to
insert
vulnerabilities
than
to
find
existing
vulnerabilities.
All
software
is
affected.
Commercial
and
open
source
software
alike,
there
has
been
a
huge
spike
in
these
types
of
attacks
over
the
last
two
years.
Examples
include
log
4J
code,
Cub
left
pad
Red
Lily
attacks
like
these
make
it
hard
to
consume
and
Trust
open
source
software.
So
how
do
you
reduce
your
risk?
You
can
start
by
taking
small
steps
and
improve
your
security
posture.
Incrementally.
Let's
look
at
a
few
of
these
steps
that
we've
taken.
A
We
we
start
by
securing
source
with
permissions,
set
up
organizational
policies
and
enforce
them
automatically.
Some
of
these
policies
might
include
requiring
two-factor
authentication
for
the
org
cleaning
up
maintainers
when
they're
no
longer
part
of
the
org
and
restricting
outside
collaborator
permissions
plan
for
security
incidents.
A
security
markdown
file
is
the
recommended
place
to
Define
your
policy,
so
users
can
securely
report
a
vulnerability
to
repository
owners.
The
open
source
security
Foundation
provides
templates
and
guides
for
a
coordinated
vulnerability
disclosure
use
a
tool
to
help
you
manage
and
upgrade
your
dependencies.
A
We
recommend
the
dependabot
or
renovate
bot
when
using
dependabot
be
sure
to
enable
the
alerts
and
security
update
settings
for
all
dependencies.
You
use
next
think
about
your
CI
infrastructure.
Here
are
a
few
steps
we
take
to
reduce
the
risk
of
our
infrastructure
from
being
used
maliciously.
The
principle
of
least
privilege
states
that
a
subject
whether
a
process,
user
or
program
should
be
given
only
the
Privileges.
They
need
for
it
to
complete
its
task
when
thinking
about
RCI.
This
means
restricting
GitHub
token
permissions
and
other
privileged
activities.
A
When
writing
your
workflows
by
default,
all
workloads
have
right
access
except
for
pull
requests.
This
leaves
a
really
broad
attack
surface.
So
a
first
step
towards
reducing
privileges
is
to
set
read
by
default
at
the
lower
level
for
new
repositories.
Then,
in
each
job
of
your
workflow
declare
the
additional
permissions
you
need
be
aware
of
the
pull
request.
Target
workflow,
trigger
by
default.
This
trigger
runs
with
read,
write,
repository
permissions
and
has
access
to
Secrets
even
from
Forks.
The
event
runs
in
the
context
of
the
base
branch
of
the
pull
request.
A
This
is
to
prevent
execution
of
untrusted
code
from
the
head
of
the
pull
request
that
can
alter
your
repository
or
steal
secrets
from
your
workflow.
This
event
is
most
useful
for
commenting
or
labeling
pool
requests.
If
you
need
to
access
the
code
to
check
out,
run
and
or
build,
you
should
use
the
pull
request
trigger
and
ensure
you
always
properly
vet
all
contributions
before
running
any
code.
Next
pin
all
third-party
GitHub
actions
by
commit
hash.
A
This
means,
instead
of
using
a
mutable
reference
like
at
Main
or
at
version,
for
example,
at
version
one
two:
three
for
third-party
action
to
use
a
commit
hash
to
lock
in
the
code
being
used,
for
example,
at
ABCDEF,
a
b
c
d
e
f.
In
this
example,
often
the
main
branch
and
version
tags
are
floating
labels
that
update
when
new
code
is
released
by
the
developer
by
pinning
to
a
commit
hash.
A
Instead,
you
reduce
the
risk
of
compromised
actions
being
automatically
used
by
your
workflow
without
reviews,
especially
in
privileged
workflows
that
have
write
permissions
or
secret
access.
This
also
has
the
added
benefit
when
doing
incident
response.
You
know
exactly
what
code
is
running
in
your
action
to
determine
if
you
were
affected
next,
be
aware
of
GitHub
context,
variables
that
are
vulnerable
to
command
injection
attack,
since
GitHub
Runners
do
string
substitution
on
variables
before
running
commands.
Any
variable
that
comes
from
user
input
could
allow
someone
to
inject
code
that
gets
executed
by
the
action.
A
Here's
an
example
workflow.
It
runs
on
a
pull
request
and
it
prints.
The
title
of
the
pull
request
seems
pretty
harmless
right,
but
this
creates
a
script
injection
vulnerability
that
could
allow
remote
code
execution.
Imagine
if
the
input
includes
a
semicolon.
This
would
signal
that
the
title
string
is
ended.
Then
everything
after
is
treated
as
a
command
to
be
executed
in
this
case,
sending
the
string
poned
to
the
remote
server.
What
if
they
printed
out
one
of
your
secrets,
this
code
runs
without
user
interaction.
They
just
craft
their
desired
command.
A
In
the
title
of
the
pull
request,
submit
the
pr
and
the
code
won't
run.
Have
you
noticed
this
workflow
does
not
declare
permissions,
so
they
default
to
write.
The
attacker
could
even
push
to
the
repository
to
prevent
this
use
environment
variables.
To
avoid
crafty
string
substitution
and,
of
course,
we
need
to
protect
Secrets
all
of
the
certificates,
passwords
or
keys
from
leaking.
Of
course,
the
easiest
way
to
not
leak
a
secret
is
to
avoid
having
a
secret
to
leak.
When
you
do
need
a
secret
understand.
A
The
limitations
GitHub
Secrets
do
not
have
a
scoping
mechanism,
so
they
are
accessible
to
all
branches
and
workflows
avoid
the
use
of
personal
access
tokens.
They
allow
access
to
the
GitHub
apis
as
if
you
were
the
user,
they
tend
to
have
right
access
with
the
default
of
one
year.
Expiration
use
ephemeral
tokens
such
as
the
GitHub
token,
as
much
as
you
can.
If
compromised,
there
is
low
risk
since
they
automatically
expire
after
the
job
and
GitHub
supports
openid
connect
oidc
to
authenticate
to
Cloud
providers.
A
A
workflow
can
now
exchange
oidc
token
for
a
cloud
provider's
short-lived
access.
Token,
that's
only
valid
for
a
single
job.
Finally,
you
can
also
Implement
secret
scanning
to
prevent
secrets
from
being
pushed
to
a
remote
repository,
but
when
you
do
need
Secrets,
Don't
store
them
on
disk,
avoid
using
them
directly
in
workflow
Scripts,
don't
pass
Secrets
as
CLI
arguments
and
definitely
don't
hard
code
them
into
your
source
code
or
log
them.
A
If
you
accept
contributions
from
various
contributors,
we
use
two-person
review
enforced
through
github's
Branch
protection
settings
to
protect
against
sabotage
from
someone
internal
to
the
project
and
to
increase
the
likelihood
that
unintentional
vulnerabilities
will
be
caught
before
being
merged
into
the
code
base.
In
a
sock
puppet
attack,
a
maintainer
uses
a
personal
account
to
send
a
PR
and
lgtm
it
themselves.
Bypassing
code
review
use
code
owner
for
different
parts
of
the
code,
especially
sensitive
areas
of
the
code
base
like
workflows.
It
reduces
work
for
maintainers,
which
ultimately
leads
to
better
reviews.
A
Vet
PR's
before
integration
tests
are
triggered
to
ensure
safe
access
to
resources.
The
usage
of
Auto
merge
should
be
reviewed,
since
this
gives
users
the
ability
to
push
code
directly
to
a
repo.
Now
we
need
to
package
our
code
up
to
be
released.
We
need
to
safeguard
our
release
process
and
the
resulting
artifact,
even
though
GitHub
actions
are
smaller
than
a
full
application.
Our
GitHub
actions
are
written
in
typescript
and
need
to
be
compiled
into
JavaScript
to
be
released,
using
GitHub
actions
to
build
and
release.
Our
actions
provides
us
with
a
way
to
script.
A
Our
build
and
an
ephemeral,
isolated,
build
environment,
external
from
developer
workstations,
so
our
disk
distributable
is
safely
built.
Other
recommendations
to
be
aware
of
are
isolating
steps
that
need
Secrets.
This
typically
means
isolating
the
build
from
publishing
to
a
package
manager
remove
unused
third-party
dependencies.
This
can
also
mean
any
extra
GitHub
actions
and
pin
the
dependencies
you
are
using.
Provenance
is
metadata
about
how
an
artifact
was
built,
including
the
build
process
top
level
source
and
dependencies.
A
Knowing
the
provenance
allows
software
consumers
to
make
risk-based
security
Decisions
by
helping
them
verify
that
the
binaries
were
built
from
your
repositories
and
that
when
they
run
them
it's
from
the
source
that
they
can
look,
you
can
use
the
salsa
Frameworks
salsa
GitHub
generator
GitHub
action
to
generate
provenance
for
your
artifacts.
The
salsa
team
also
provides
a
salsa
verifier
tool
to
validate
verify
the
signed
provenance.
A
Lastly,
a
few
steps
to
take
to
improve
your
use
of
Google
GitHub
actions,
use
the
Google
auth
action
or
actions
that
are
authenticated
via
oidc
or
open
ID
connect
previously
authentication
to
a
cloud
provider
required
downloading
credentials,
files
for
a
service
account
and
storing
it
as
a
secret.
These
credentials
are
long
lasting
and
do
not
allow
granular
control
over
the
workflow's
access.
Workflow
jobs
generate
a
unique
oidc,
Json
web
token
JWT
or
jot
per
workflow
run
a
cloud
provider
validates
this
token,
then
issues
a
short-lived
access.
A
Token,
that's
valid
for
only
a
single
job
and
automatically
expires.
This
works
with
all
our
actions
and
terraform.
You
should
also
remember
the
least
privileged
principle
to
redo,
reduce
the
scope
of
your
service.
Account
permissions
use
the
secret
manager
action
to
avoid
hard
coding,
Secrets
or
storing
them
on
disk.
Our
action
also
declares
the
output
variables
as
secrets
to
ensure
their
values
are
masked
in
log
output.
A
Limit
access
to
Secrets
by
following
the
least
privileged
principle,
specifically
the
secret
manager,
admin
and
accessor
roles,
have
permissions
to
view
the
secret
value
and
should
be
limited
to
only
those
who
need
it
prefer.
The
accessor
role
for
your
actions.
Service
accounts.
A
security
incident
is
not
a
matter
of
if
it's,
when,
if
you
set
yourself
and
your
team
up
to
apply
these
common
practices,
pursue
continual
learning
to
apply
to
the
development
of
your
software,
then
you
will
be
better
prepared
to
address
the
issues
that
you
do
discover.
Security
is
everybody's
job.
A
We
have
to
think
about
security
throughout
the
development
of
our
software
and
the
operation
of
our
systems,
rather
than
as
an
afterthought.
More
and
more
Frameworks
are
coming
out
to
help
set
standards
and
Technical
controls
you
can
adopt
to
improve
artifact
integrity
and
build
towards
completely
resilient
systems,
use
the
supply
chain
levels
for
software
artifacts,
pronounce
salsa
and
end-to-end
framework
for
accessing
the
Integrity
of
your
software.
Artifacts
salsa
helps
inform
your
users
of
the
choices
that
you
made
about.
The
software
you've
built
in
three
main
areas
build
source
and
dependencies.
A
Unfortunately,
infrastructure
security,
Is,
Never
Done.
Instead
of
trying
to
do
everything,
take
small
steps
to
continuously
improve,
take
some
steps,
we've
shared
in
this
presentation
to
get
started
and
avoid
anti-patterns
and
adopt
recommended
practices.
Thank
you
so
much
for
joining
our
session
today.
You
can
see
here
there
are
a
bunch
of
folks
here
at
Google
Cloud,
who
have
helped
to
maintain
and
produce
this
session
with
me
and
so
reach
out
to
them
for
more
information
about
Google
and
GitHub
actions
and
see
you
next
time.