►
From YouTube: Secure container development workflows with Anchore and GitHub Actions- GitHub Universe 2019
Description
Presented by Zach Hill, Principal Architect, Anchore, and Steve Winton, Senior Partner Engineer, GitHub
Containers are a driving force behind code reuse for businesses of all sizes, allowing developers to choose from a variety of software sources when they’re building an application. However, containers can sometimes introduce unwanted security and compliance flaws. GitHub’s Steve Winton and Anchore’s Zach Hill will discuss how users can now check containers for known vulnerabilities and configuration issues automatically, thanks to Anchore and GitHub Actions. Plus, they’ll show you some ways you can integrate this new product into your development pipeline.
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
A
Everyone
hope
you're
all
doing
well,
thanks
for
coming
to
this
session,
secure
container
workflows
with
Angkor
and
github
actions-
glad
you
all
could
make
it.
My
name
is
Steve
Winton
I
am
a
member
of
the
partner
engineering
team
at
github,
where
it's
my
pleasure
to
work
with
github
x'
many
wonderful
partners
and
help
them
and
work
with
them
as
they
bring
new
products
and
services
that
work
with
github
to
market
for
our
shared
customers.
A
B
So
my
name
is
Zack
Hill
and
I'm,
the
principal
architect
at
Angkor
and
looking
forward
to
kind
of
showing
you
this
new
angkor
container
scan
action
and
how
you
can
use
that
to
bring
security
to
your
container
based
workflows.
So
today,
we'll
start
off
talking
about
some
of
the
opportunities
and
challenges
that
arise
in
these
new
container
workflows.
I'll
then
talk
about
the
capabilities
of
the
Angkor
can
scanning
system
and
how
it
does
container
scanning
analysis
and
policy
evaluation.
B
Then
I'll
cover
quickly
the
Anker
container
scan
action
itself
so
how
it
works
and
what
it's
doing
in
your
actions
workflow
and
then
we'll
see
how
to
add
that
scan
action
into
your
own
workflow,
so
that
you
can
be
scanning
the
container
artifacts
that
are
coming
out
of
your
actions,
pipelines.
So
at
a
high
level,
we
really
like
containers
right,
they've,
they've,
really
helped
us
increase
development
velocity
by
providing
things
like
reusability
isolations.
You
can
run
many
versions
of
an
application
right
next
to
each
other.
Without
worrying
about
configuration,
conflicts
right,
it
enables
faster
testing.
B
You
can
test,
you
know
multiple
versions
or
multiple
sets
of
dependencies
all
at
the
same
time,
and
it
provides
a
consistent
development
experience
all
the
way
from
say,
onboarding
new
developers,
where
you
can
quickly
spin
them
up
with
your
application,
stack
on
their
laptop
all
the
way
through
the
CI
testing
and
ultimately
deployment,
and
this
this
consistency
and
brings
significant
ease
of
ingress
for
new
technologies.
So
it's
much
easier
now
to
bring
in
new
applications
or
component
of
your
application
stack
and
get
them
directly
from
testing
and
into
production,
and
so
overall
this
is
increasing.
B
The
development
velocity,
which
is
great
so
development
and
DevOps
teams,
feel
empowered
kind
of
move
fast
and
be
able
to
break
stuff
because
they're
confident
that
they
can
push
out,
updates
quickly
and
reliably
without
having
to
babysit
their
infrastructure
and
worry
about.
You
know
how
hard
is
it
going
to
be
to
roll
things
back
so
we'll
kind
of
show
that
in
action
here
so.
A
As
well
as
my
day,
job
at
github
I
also
have
a
bit
of
a
side
project
going
at
the
moment
where
I'm
a
web
developer
for
a
new
enterprise
called
top
socks,
which
perhaps
many
of
you
have
heard
of
it's.
Basically,
the
top
destination
for
socks
on
the
internet,
I'm
sure
you've
heard
of
us,
if
not
check
us
out
I,
have
been
working
in
my
spare
time
really
really
hard
on
a
new
feature.
That
is
pretty
important
to
my
marketing
team.
There's
quite
a
lot
of
pressure
around
this
to
get
us
out
the
door.
A
It's
an
animated
gift
service
and
it's
gonna
power.
All
of
the
animated
gifts
of
our
marketing
team
needs
on
our
e-commerce
front
end
something
working
super
hard
on
this
I
need
to
get
out
the
door
ASAP,
and
here
is
the
the
repository
now.
Fortunately,
I
had
the
foresight
to
wrap
this
service
in
a
container.
So
it's
all
neatly
containerized
here,
as
we
can
see.
A
The
deploy
step
here
involves
pushing
it
to
get
hub
packages
where
then,
a
separate
process
will
see
that
it
will
pick
up
that
new
container
and
it
will
push
it
off
to
production
for
me.
So
it's
all
fully
automated
really
repeatable
a
really
reliable
process,
and
this
is
going
to
help
me
move
fast,
which
I
really
need
because,
like
I
said,
there's
a
lot
of
pressure
to
get
this
done
right
now.
So
here
I
am
with
my
pull
request.
A
That's
like
90%
of
the
way
there
opening
this
pull
request
is
actually
going
to
trigger
off
all
of
my
actions.
All
of
my
checks
to
run
for
me,
and
it's
going
to
give
me
that
kind
of
added
amount
of
confidence
to
make
sure
that
it
all
goes
well.
So
here
we
see
the
the
checks
now
are
being
kicked
off
for
my
pull
request
and
we
can
jump
in
and
check
out
the
details
and
make
sure
it's
going
okay.
A
So
this
should
all
start
running
here
in
a
second
and
if
anything
does
fail,
then
that's
going
to
block
my
pull
request.
I
won't
be
able
to
merge
anything
checking
out
the
code
that
pass.
Don't
expect
that
to
fail
I'm
cashing
my
node
modules,
which
gives
me
a
little
bit
of
a
performance
boost.
If
anything
does
go
wrong,
I
need
to
do
it
again.
I
won't
need
to
do
that
step
again.
It
looks
like
this
time
we
do
need
to
install
those
packages.
Take
a
couple
of
seconds
to
do
that.
A
And
then
my
tests
are
going
to
run
I've
got
some
tests
in
there.
I
could
probably
boost
those
a
little
bit
with
my
coverage
and,
most
importantly,
my
audit
step
here
so
zero
vulnerabilities
and
almost
almost
900,000
packages.
It's
crazy,
but
yeah
zero
vulnerabilities
there,
which
is
awesome
so
I'm.
You
know
with
every
green
checkmark
that
I'm
getting
here
I'm
just
getting
increased
confidence
in
the
quality
of
this
release.
So
my
image
is
being
built
now.
I
do
see
a
few
warnings
there,
but
I
don't
think
I
need
to
be
too
concerned
about
that.
A
I
saw
the
same
thing
on
my
development
machine
and
it
was
fine.
So
let's
just
wait
for
the
bill
to
complete
here
and
just
a
second
okay
and
right
because
we're
on
a
full
request
here:
I'm
not
actually
going
to
do
a
deployment
once
that,
once
this
pull
request
emerges
will
do
the
deploy
at
that
step
on
from
master.
So
this
is
all
green
now,
I'm
feeling
pretty
good
about
this,
so
I
think
I
can
hit
that
merge
button.
A
A
Thinking
about
it,
let's
merge
do
this
yeah
here
we
go
yeah
and
there's
my
email
address
so
and
we
can
delete
the
branch.
We
don't
need
that
anymore.
So
yeah,
like
I,
said
now.
This
has
been
merged
to
master
that
merge,
commit
we'll
run
another
scan
on
that
merge,
commit
and
then
that
will
get
pushed
out
to
production,
get
picked
up
by
a
separate
process
which
will
do
the
actual
deployment.
A
So
all
that
to
say
this
process
of
running
automated
checks
of
running
an
audit
on
my
packages
of
running
my
tests
pushing
the
container
out
to
get
our
packages.
This
allowed
me
to
move
fast.
It's
allowed
me
to
get
this
new
service
out
to
production
really
quickly,
basically
I'm
pretty
happy
at
this
point,
I'm
going
to
tell
my
marketing
team
that
the
new
service
is
ready,
they'll
be
ridiculous,
that
they
wanted
it
yesterday,
but
I
think
there'll
be
amazed
that
it
landed
today
in
production
and
I.
Think
at
this
point,
I
can
pretty
much
relax.
A
B
Done
but
I
too
am
moonlighting
for
top
stocks,
and
my
job
is
security
and
I,
say
great
job.
Steve
I
was
very
happy
that
to
see
that
NPM
audit,
but
what
we
deployed
was
actually
a
container,
and
so
what
I
didn't
see
is
any
understanding
and
analysis
or
or
policy
around
what
can
be
in
that
container
itself.
A
Okay,
so
maybe
I
haven't
finished
my
day
just
yet
so
I
guess
my
my
security
officer
might
have
a
point.
Maybe
there
are
some
additional
things
in
my
container
that
I
might
have
overlooked,
even
though
my
900,000
packages
didn't
have
any
vulnerabilities
yeah.
Perhaps
there
is
something
else
in
there,
but
you
know
I'm,
just
a
developer.
I,
don't
really
have
time.
I'm
trying
to
you
know,
meet
our
business
requirements
I'm
trying
to
keep
my
Marketing
team
happy
I
feel
like
now.
A
I've
got
the
security
officer
kind
of
asking
me
to
direct
your
things
as
well,
I'm
already
doing
all
of
this
stuff,
and
it's
kind
of
getting
a
bit
overwhelming
like
what
all
these
choices
that
I
need
to
now
make.
What
is
a
good
base
image
to
start
building
from,
but
I,
don't
really
know
to
be
completely
sure.
I
want
to
be
able
to
ship
confidently
and
with
high
velocity,
but
I
feel
like
this
is
going
to
just
slow
me
down
all
this
kind
of
additional
complexity.
B
So
that
that
feeling
is
kind
of
emblematic
of
some
of
the
security
challenges
that
we
see
with
these
containerized
workflows
and
more
generally,
this,
this
ongoing
transition
from
dev,
dev,
ops
and
dev
SEC
ops
right
as
developers,
are
getting
the
tools
to
move
very
quickly
and
push
things
through
to
production
very
fast.
It's
also
actually
making
the
choices
that
are
made
earlier
in
the
development
process,
even
more
important
in
terms
of
what
actually
gets
deployed
in
production,
so
an
early
decision
by
developer
to
just
grab
a
random
image.
You
know
I
need
a
database.
B
I'm
gonna
grab
this
and
stick
this
into
my
deployment
template.
Suddenly.
That
makes
it
all
the
way
through
to
production
without
the
proper
checks
and
maybe
violating
a
lot
of
different
security
or
compliance
requirements
that
the
organization
has
so
this
kind
of
leads
to
the
question:
what
about
security
review
and
where
does
security
reviews
fit
in
these
workflows?
Who
owns
them?
And
how
do
you
scale
these
processes
for
micro
service
architectures
that
are
becoming
so
popular
right?
You
might
be
pushing
tens,
hundreds,
even
thousands
of
services
out
with
multiple
updates
per
day
right.
B
You've
got
a
very
polished
deployment
pipeline.
Every
merge
is
going
and
resulting
in
a
new
commit
a
new
version
of
the
software
being
pushed
out
to
your
customers,
and
so
this
overall
leads
to
a
really
large
inventory.
So
you
have
a
bunch
of
container
images
out
there,
potentially
lots
of
churn
and
even
more
specifically,
a
really
short
container
lifecycle.
B
So
a
given
version
of
your
software
may
only
be
running
four
days
or
a
week,
and
that
has
implications
on
the
back
end
when
you're
looking
when
you
need
to
do
security
audits
and
security
reviews
for
understanding
kind
of
what
was
running
and
where-
and
so.
Ideally,
we
want
to.
You
know,
assist
this
with
tooling
and
the
first
step
in
this
tooling
and
helping
kind
of
bridge.
This
gap
is
understanding
the
container
content
kind
of
in
a
deep
way,
and
we
don't
want
to
have
to
do
this
with
a
manual
process
or
a
manual
review.
B
But
it's
important
to
understand
that
there's
a
lot
that
goes
into
these
containers,
besides
just
the
application
code
right,
so
there's
build
metadata.
That
comes
in
from
the
docker
file
during
the
build
step
and
we
saw
a
fairly
straightforward,
docker
file
there.
But
you
know
it's
not
uncommon,
to
see
docker
files
that
are
50
hundred
lines
with
lots
of
different
operations.
B
You
know
pulling
in
tar
balls
from
various
sources
within
the
organization
and
dropping
those
into
the
container,
for
example,
that
includes
the
software
packages
that
get
installed
during
your
build,
as
well
as
any
underlying
what
I'll
call
OS
packages,
but
usually
they're
things
like
Lib
C
right
there,
they're
user
space,
libraries
that
are
needed
to
run,
maybe
your
language
framework
right,
node
or
Ruby
on
Rails
those
have
low-level
dependencies
as
well.
There's
also
configuration
files
that
will
define
how
these
various
processes
run
the
OS
files
themselves
and
even
in
some
cases,
application
data.
B
So
things
like
machine
learning
images.
We
see
that
often
get
front
loaded
with
a
pretty
big
corpus
of
data
during
the
container
build
itself,
and
so
all
this
means
you
have
a
lot
of
different
classifications
of
things
that
are
in
the
container,
and
you
need
to
understand
that
and
be
able
to
do
the
appropriate
security
checks
against
all
of
those
things
to
make
sure
that
what
you're
pushing
into
production
meets
all
of
your
requirements
for
security,
compliance
and
audit.
You
know
security
is
more
than
just
scanning
a
thing
for
vulnerabilities.
B
It's
about
understanding
the
audit
trail.
So
where
did
things
come
from?
Where
did
they
run,
which
commits
of
code
resulted
in
which
containers
and
which
artifacts
eventually
ended
up
into
production?
It's
also
about
enforcing
organizational
best
practices
in
configuration,
so
things
that
help
your
processes
further
down.
The
line
say
required
labels
in
your
docker
file,
right
that
are
used
to
track
deployment
later
on
or
specific
health
checks
that
you
want
to
ensure
every
container
has
and
so
enforcing
this,
and
that
can
impact
your
security
stance
as
well.
B
So
the
best
way
to
address
this
overall
is
through
policy
and
automation
right.
So
you
want
to
make
sure
that
you're
scanning
and
verifying
the
you
that
you're
actually
deploying
which
in
these
cases
is
the
container
itself-
and
this
has
a
couple
of
other
benefits
as
well,
because
you
can
use
the
same
approaches
for
things
that
are
runtime
dependencies
of
your
application.
Stack.
Your
databases,
message,
brokers,
caching
systems.
All
of
this
can
be
analyzed
the
same
way,
even
though
they're
delivered
as
containers
but
they're,
not
actually
your
source
code.
B
So
that's
where
anchor
that
the
container
scan
action
comes
in,
so
what
we've
done
is
we've
built
a
scan
action
that
you
can
execute
in
your
github
actions,
workflow
that
takes
the
anchor
technology
which
I'll
go
over
momentarily
and
embeds
that
into
your
actions.
We
floo
so
that
you
get
a
consistent
policy
based
approach
to
validating
the
containers
that
are
moving
through
your
pipelines.
B
So
Angkor
at
its
heart
is
a
container
analysis
and
policy
evaluation
tool
and
platform,
so
it
takes
containers
it
cracks
them
open,
tries
to
classify
and
understand
all
the
content,
that's
in
them
and
then
provides
a
policy
language
where
you
can
define
checks
an
audit
trail
on
each
of
those
aspects
so
that
you
can
both
focus
your
security
and
compliance
efforts
as
well
as
get
a
nice
audit
of
what
was
found
in
the
container.
So
first,
the
thing
that
most
people
understand
right
away
is
vulnerability.
B
Let's
say
you
define
checks
on
the
results
of
that
scan,
so
things
like
best
practice,
validation.
Looking
at
the
docker
file
that
you
was
used
to
build
the
container
and
then
ensuring
that
it
has
certain
best
practices
or,
for
example,
white
listing
or
black
listing
application
package,
maybe
NPM
s
or
OS
packages.
You
want
to
make
sure
that
lib
SSL
is
at
least
some
version
or
greater
right.
You
can
enforce
that
in
the
container
scan
itself.
B
So
it
provides
a
rich
and
kind
of
very
flexible
policy
layer
that
lets
you
define
the
acceptance
criteria
and
what
you
want
to
check
for
each
of
these
kind
of
aspects
of
The,
Container
content
itself,
and
here
next
I'll
provide
a
really
short
example
of
the
kind
of
policy
rule.
So
anka
our
policies
are
just
json
documents
and
they
have
love
sets
of
rules
and
they
have
parameters.
B
So
here
this
is
extracted
from
the
default
policy
that
ships
with
the
container
scan
action
that
we're
talking
about
today
and
at
the
top
there
you
see,
the
the
action
is
stopped.
So
if
this
rule
fires
it
will
will
block,
it
can
block
a
build
and
then
there's
some
parameter.
So
you
see
there's
a
gate
that
we're
checked
that
we're
evaluating
the
thing
that's
doing
is
a
vulnerability
check
at
the
bottom.
I
should
have
changed
the
ordering
here,
the
bottom
it's
triggering
on
packages.
B
So
it's
looking
for
vulnerabilities
in
packages
within
your
container
and
then
there's
a
bunch
of
parameter.
So
what
kind
of
package
should
it
match
against?
What
kind
of
comparison
should
it
use
for
the
severity
of
the
vulnerability
and
a
limit
on
severity?
So,
but
this
one
is
actually
describing
is
a
stop
action
for
any
vulnerability.
B
That's
found,
that's
either
high
or
critical
severity
and
for
which
for
which
a
fix
is
available
so
that
last
parameter
that
name
value
pair
at
the
bottom
says
fix
avail
was
true,
so
this
is
helping
us
reduce
the
set
of
thing.
You
know
the
noise
in
the
system,
two
things
that
you
can
actually
resolve
because
there's
a
fix
available
and
you
can
update
the
update
your
container
to
resolve
that
issue.
B
The
anchor
policy
has
several
features
that
we
think
make
it
really
useful
in
terms
of
identifying
actionable
issues
and
and
helping
you
build
better
images
as
a
result,
and
not
just
ingesting
a
giant
list
of
vulnerabilities
that
somebody
has
to
manually
filter
through
later
and
figure
out,
whether
those
27
medium
vulnerabilities
actually
matter
to
your
application
or
not,
and
that
and
that's
around
the
the
parameterization.
So
you
can
kind
of
specify
the
kinds
of
checks
that
you
want.
The
parameters,
including
things
like
cbss
severity,
whether
or
not
a
fix,
has
been
available.
B
How
long
a
fix
has
been
available?
How
long
an
image
has
had
a
vulnerability,
there's
grace
periods,
all
kind
of
these.
These
parameter
help
you
focus
in
on
what
matters
most
for
your
organization.
We
also
consider
support
inline
comments,
so
for
each
rule,
you
can
set
a
comment
that
helps
you
provide
context,
so
anybody
reading
that
policy.
They
can
see
that.
This
is
why
this
rule
is
in
place.
B
We
also
have
a
capability
of
doing
whitelisting
directly
in
the
policy,
and
this
is
important
because,
as
we
know,
no
policy
will
ever
be
perfect.
There
will
always
need
to
be
exceptions,
and
this
lets
you
track
and
if
those
exceptions
to
the
rule
within
the
policy
directly
and
again,
ideally
tying
this
directly
into
your
the
source
repository,
that's
building
the
container
itself
and,
lastly,
the
way
ankhor
evaluates
policy
is
very
audit
friendly,
so
it
will
evaluate
every
single
rule
in
the
policy
and
give
outputs
for
every
single
rule.
B
Whether
that's
a
stop
action,
as
we
saw
anchor,
also
supports
two
other
types
of
action
which
are
go
and
warns.
You
can
craft
the
messaging
for
the
output
of
that
policy.
Maybe
you
just
want
to
run
a
bunch
of
checks
and
record
the
results,
but
not
actually
block
your
CI
pipeline.
So
it's
very
flexible
and
audit
friendly
in
that
way.
So
how
does
it
actually
work
like?
What
is
Ankur
actually
do
so?
B
Anchora
engine
is
an
open
source
project
that
provides
a
stateful
service
that
you
make
API
calls
and
tell
it
to
analyze
images
and
it
fetches
those
images
from
docker
image,
registries
analyzes
them
and
provides
an
API
for
asking
questions
about.
Did
it
pass
policy?
What
it
does
it
have
in
it?
You
know
you
get
a
notification
if
there's
a
change
in
the
vulnerability
status
of
an
existing
image,
etc,
etc.
So
it
contains
a
powerful
set
of
reports
and
queries
and
eventing,
and
it
you
can
integrate
it
into
an
existing
action.
B
Workflow
using
API
calls,
but
often
for
a
lot
of
github
users.
This
isn't
going
to
be
sufficient
because
they
don't
want
to
run
yet
another
stateful
service
that
they
have
to
expose
on
the
internet
somewhere
so
that
their
their
github
action
workflow
can
access
it,
and
so
we've
wrapped
that
around
what
we
call
the
inline
scan,
which
takes
all
of
that
logic
and
and
composes
it
so
that
we
can
run
it
entirely
locally.
That's
kind
of
a
command
line,
so
you
just
say
do
the
thing
and
give
me
the
output
alright.
B
So
that
makes
it
much
more
consumable
and
it
doesn't
have
any
external
dependencies.
You
don't
have
to
do
any
call-outs
to
any
other
API,
as
no
external
services
are
required,
but
it's
still
fully
featured
in
term
it's
metadata
and
the
vulnerability
checks
and
for
the
scan
action
itself.
The
thing
you
actually
run
in
in
your
actions,
workflow,
we've
wrapped
that
in
line
scan
around
some
inputs
and
outputs.
So
what
actually
happens
when
you
invoke
the
ink
or
container
scan
action?
B
Is
it's
gonna
pull
down
a
docker
image
from
our
docker
hub
repo
that
contains
all
the
vulnerabilities
and
those
get
updated
nightly?
So
you
always
have
fresh
vulnerability
data.
Then
it
does
an
unpack
and
deep
scan
of
your
container.
That
you've
told
it
scan
this
container
on
my
localhost
or
in
the
github
workflow,
and
then
it
will
do
the
security
scanning
and
then
take
those
outputs
and
pass
all
that
through
the
policy
engine,
ultimately
giving
you
a
pass
or
a
fail
and
again
to
reiterate
this
runs
entirely
within
your
CI
or
in
your
actions.
B
Workflow
and
there's
no
external
prudential
assistant
hit
any
other
service
running
outside
of
the
workflow
at
all.
So
no
data
leave
your
pipeline,
so
I'll
just
quickly
touch
on
some
of
the
input
parameters
for
the
action
itself
and
well
and
Steve
will
show
us
kind
of
later
how
we
actually
use
this
thing,
but
high-level
I
just
want
to
highlight
at
the
very
top
there.
The
image
reference
is
really
the
only
thing
you
need
to
give
it.
B
You
can
call
the
action
say
analyze
this
image
right
with
this
tag
that
I
just
built
locally,
and
it
will
do
the
rest.
There's
other
things
you
can
set
like
whether
you
want
to
fail
the
actual
actions
build
or
not,
based
on
the
result
of
the
policy,
whether
you
want
to
include
a
custom
policy.
So
we
we
have
a
default
policy
that
ships
with
the
action.
B
You
can
always
build
your
own
policy
document
and
use
that
instead,
and
so
you
have
that
level
of
flexibility
and
the
outputs
when
it
when
it
completes
or
a
bill
of
materials
which
is
all
the
packages
specifically
that
it
found,
we
don't
dump
the
full
file
system,
yet
that's
a
little
little
too
verbose
for
most
workflows.
The
list
of
vulnerabilities
and
the
output
of
the
policy
check
and
the
intent
here
is
that
you
can
use
these
downstream
in
your
actions
workflow
to
do
other
logic.
B
Maybe
you
want
to
file
an
issue
because
of
some
output,
or
you
want
to
initiate
a
different
kind
of
deployment,
push
it
to
a
quarantine
or
push
it
to
a
staging
environment,
those
kind
of
things
and
as
an
example
of
the
scan
action
output
itself,
I've
included.
This
is
just
a
snippet
out
of
one
of
the
actual
builds,
and
this
is
where
the
audit
ability
comes
in
here.
We
can
see
that
that
at
the
top
we
actually
have
the
image
digest
that
was
built,
so
you
can
trace
that
through
your
system.
B
We
have
a
status
which
is
passed
here
and
then
actually
showing
the
kind
of
output
of
each
of
the
policy
rules
organized
here
by
this
gate
and
trigger,
and
then
some
detail
so
with
this
particular
output
is
showing
us
is
that
one
of
our
metadata
checks
has
raised
a
warning
that
your
dockerfile
looks
like
it's
indicating
that
the
container
should
run
as
root
and
that's
generally
considered
against
best
practice.
We
want
to
run
as
non-root.
So
that's
that's
an
example.
B
The
default
policy
that
we
include
with
the
action
will
fail
on
critical
and
high
vulnerabilities
with
fixes
available.
So
again
it's
it's
things
that
you
can
take
action
on
directly
and
immediately
without
a
lot
of
noise.
Of
course
you
can,
you
can
expand
this
and
customize
it
as
much
as
you
need
to
later
on,
and
it
will
give
you
warnings
for
dockerfile
best
practices
such
as
the
the
one
we
just
saw
around
the
non
root,
but
also
for
missing
health
checks
or
if
it
finds
anything
in
the
container.
A
Play
cue
Zak,
so
that
was
quite
an
education
for
me
and
I.
Think
I
want
to
incorporate
this
new
capability
into
my
workflow
to
get
a
more
secure
development
process
through
policy
and
automation.
So
I
found
the
action
here
on
github
market
place.
The
anchor
scan
action
and
I
want
to
definitely
incorporate
this,
get
the
additional
analysis
and
have
added
security
in
in
added
sorry
confidence
in
the
security
of
my
releases.
A
A
The
the
scan
action
that
I've
added
in
between
my
build
step
and
my
deploy
step
so
after
a
successful,
build
we'll
do
a
scan
of
the
image
I'm
using
the
latest
version
of
the
action
here,
we're
passing
in
the
image
reference
which
is
required
so
that
the
action
can
actually
inspect
it.
I
want
to
set
the
fail,
build
option
to
true.
So
if
there
are
any
policy
violations,
then
that
does
actually
prevent
the
pull
request
from
merging
and
also
I'm
passing
in
the
path
to
my
dacha
file.
A
So
we
can
do
an
analysis
on
the
dock
file
as
well.
So
everything
else
is
the
same
as
before.
The
only
thing
that
we've
added
here
is
this
additional
scan
image
step.
So
here's
a
previous
run
against
the
code.
That's
currently
on
master
and
we
can
see
everything
is
green
as
it
was
before,
but
it
looks
like
so
caching
installing
testing
the
order
at
the
build
is
all
green,
but
it
does
look
like
the
scan
image
has
reported
a
policy
violation
which
is
unfortunate,
so
let's
jump
in
and
see
what
it
found.
A
So
yeah
that
that's
unfortunate,
but
at
least
I
do
have
the
confidence
now
that
we
can
catch
these
earlier
in
our
release
process
and
also
generated
from
the
action
we
have.
A
couple
of
outputs
are
quite
useful.
We
can
see
them
at
the
bottom
there.
So
we
have
this
bill
of
materials,
which
is
a
JSON
report
of
kind
of
a
list
of
everything,
that's
included
in
my
image
and
then
our
list
of
vulnerabilities
and
also
that
policy
check
fail.
So
it's
great
that
these
are
exposed
as
outputs
by
my
action.
A
But
for
now
I
think
what
I
want
to
do,
because
my
marketing
team
is
getting
a
little
panicky
now
I
think
what
I
want
to
do
is
just
try
and
address
this
vulnerability
to
see
if
we
can
get
a
pass
here.
So,
let's
see,
if
we
can
do
that,
I
have
a
pull
request
as
before.
That's
that
I've
started
here.
I've
I've
got
a
single
commit
on
this
pull
request.
At
the
moment.
A
It's
just
an
empty
commit
that
I
used
to
just
trigger
a
rebuild,
and
we
can
see
that
that
is
also
failing
and
now,
if
I
scroll
further
down,
then
because
the
CI
is
failing,
I'm
actually
blocked
right
now
from
merging
this
pull
request,
which
is
actually
kind
of
what
we
want
wish
I
had
this
before.
But
let's
see,
if
we
can
fix
this
so
I'm,
going
to
jump
into
my
branch
here
and
I
think
a
sensible
place
to
start
would
be
the
dockerfile
so
I'm
going
to
open
that
up
and
I
see.
A
One
of
the
first
thing
that
jumps
out
at
me
is
that
I'm
building
on
top
of
this
node
eight
Alpine
base
image,
but
I.
Don't
actually
update
any
of
the
software
packages
that
are
on
that
image,
so
that
seems
like
some
some
low-hanging
fruit
there
I
think
I'm
going
to
start
there.
So
it's
edit
this
file
and
because
this
is
an
Alpine
based
image
to
update
there.
I
just
need
to
run
a
command
which
is
the
8
using
apk.
So
let's
run
apk
type,
Thank
You,
APK,
update
and
apk
upgrade
is
the
cart
command.
A
We
want
to
run
so
just
check
that
looks
good
and
yep.
We
want
to
bake
that
bake
that
in
now
to
our
container
image,
so
let's
commit
that
and
I'll
commit
it
directly
back
to
that
address
security,
vulnerability
branch.
So
let's
commit
that
and
jump
back
to
our
pull
request
and
there's
our
new
commit
saying,
update,
docker
file
and
again
this
is
going
to
trigger
our
CI
process,
which
is
in
the
queued
state.
A
So
let's
jump
into
the
details
and
see
how
this
is
going
so
because
this
our
time
is
precious
I'm,
going
to
temporarily
suspend
the
constraints
of
time
and
space
and
we're
gonna
jump
through
some
of
this
stuff,
so
that
audit
has
passed
again.
We
are
this
time
in
the
build,
we're
updating
the
OS
packages
on
their
build
pasts-
everything
as
green
as
before.
We
can
see
that
the
caching
step
meant
that
we
could
skip
the
installation
step,
which
is
nice
and
now
that
we're
away
and
scanning
our
image
and
looking
for
any
policy
violations
here.
A
Okay,
so
this
time
I'm
pretty
pleased
to
say
that
the
scan
has
passed
and
I
see
that
there
are
a
still
a
few
warnings
in
here.
But,
most
importantly,
there
are
no
policy
violations.
I
think
you
know
maybe
for
a
future
version
of
this
workflow.
It
would
be
nice
to
maybe
consume
these
reports
consume.
Those
warnings
maybe
create
issues
in
my
repo,
so
I
can
track
those
later.
But
for
now
everything
is
green.
A
It
looks
beautiful
right.
I
also
got
a
plus
one
from
my
colleague
Thomas
who's
on
the
team,
so
I'm
glad
someone
else
has
also
reviewed
my
pull
request
thanks,
Thomas
I
appreciate
that
and
bad
I'm,
not
in
this
alone.
So
everything
is
green.
I've
got
my
approval
from
my
team
I've
built
my
container
I've
run
my
tests.
I've
done
an
audit
and
I've
done
a
scan.
Okay,
now
I
do
actually
feel
really
confident
in
this
release.
So
this
time,
gonna
merge
with
added
confidence,
delete
that
branch.
A
Again
we
don't
need
that
anymore
and
yeah,
so
you
know
I'm
feeling
really
comfortable,
really
confident.
Now,
with
this
deeper
insight
into
my
release
process,
it's
still
fully
automated
still
really
repeatable,
but
it's
also
much
much
deeper
before
so.
We
have
confidence
not
only
in
the
quality
of
our
release,
but
also
also
the
security
of
it
so
just
to
take
a
step
back
for
a
moment
and
to
review
what
we
just
saw
there.
This
is
kind
of
a
secure
container
workflow
that
we
would
advocate
as
a
best
practice.
A
So
even
though
I'm
not
a
security
expert,
I'm,
a
developer
I
can
still
ship
with
confidence
and
with
high
velocity,
be
confident
in
the
security
of
my
release
and
the
quality
thanks
to
the
ankle,
scan
action
and
github
actions,
and
just
to
recap
how
to
grab
this,
it's
a
simple
three-step
process
navigate
to
get
a
marketplace.
That's
github.com,
stash
marketplace,
use
the
search
there
for
Angkor
and
you
want
to
add
the
ankle
scan
action
step
to
your
workflow.
B
Great
thanks
Steve,
so
for
more
information
on
Angkor.
You
can
find
us
at
the
link
above
check
out
more
information
on
the
github
actions
for
for
more
interesting
and
sophisticated
things
you
can
do
in
your
workflows
and
if
you
want
to
engage
us
for
the
container
scan
action
itself,
that's
also
open
source
and
you
can
find
that
on
github
as
well
in
the
marketplace,
which
will
then
also
link
to
the
actual
source,
so
check
us
out
there
and
or
find
us
after
the
talk
cool.