►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. 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.
Platform Driven Compliance with Sigstore at Autodesk - Jesse Sanford, Autodesk
Autodesk has a long history of producing software that commercial entities use to build and make the world around us. Trust in our software is critical to our success, and as we move to government sales, that has never been more true. Additionally, Autodesk’s software is now more than ever a hybrid of desktop and cloud based solutions. We must build and deploy software to both end user machines and public clouds. Existing software supply chain solutions must be augmented to meet these new system models and secure them wherever they live. In this talk Jesse Sanford will review how Autodesk is adapting it’s existing CI and CD tooling with the Sigstore project to meet current and future compliance needs. Jesse will speak in detail about the container provenance tracking solution built on Cosign with InToto vuln scanning attestations. A demo of our deployment governance solution will be shown which will block out of policy images from being allowed through the CD pipelines. If there is time, I will go into our future plans to implement a machine Identity solution with SPIRE for keyless signing with Cosign, Fulcio and Rekor.
A
Yeah
so
I'm
Jesse
I'm
a
senior
principal
software
engineer
here
at
Autodesk
and
I
work
between
our
security
and
compliance
teams
and
our
developer
enablement
team.
You
know
I,
think
developer.
Enablement
means
some
different
things
to
different
folks,
but
for
us
it
generally
is
the
glue
tooling
that
allows
our
software
Engineers
to
move
faster
as
they
build
the
software
that
our
customers
use
there.
We
go.
A
Which
is
actually
kind
of
why
I
wanted
to
talk
to
to
speak
with
you
guys
today,
because
I
feel,
like
the
six
star
tooling,
was
exact
exactly
what
I
needed
at
the
right
time
to
be
able
to
help
enable
some
of
our
software
developers,
as
we
kind
of
move
into
some
regulatory
environments
that
we
haven't
been
in
before
before
I
get
into
that
I
should
say
a
little
bit
more
about
Autodesk
and
why
our
workloads
are
unique.
You
see
we
are
a
software
engineering,
a
software
engineering,
company
building
software
for
engineers.
A
You
could
say
that
we
make
software
for
people
who
make
things
we're
a
leader
in
design
and
make
tools
for
a
wide
variety
of
industries,
from
entertainment
to
architecture
and
engineering
to
manufacturing
into
Construction.
Our
customers
workloads
are
pretty
unique.
They
do
have
one
thing
in
common:
they
depend
upon
our
software
to
do
all
the
building
and
making
and,
as
such,
our
software
engineers
require
and
depend
upon
our
platforms
to
to
build
and
make
that
software.
A
First-Class
citizen
inside
of
our
platform
here
in
developer
enablement-
and
this
has
been
especially
important
this
year
as
we've,
been
moving
towards
a
fedrap,
moderate
impact
environment
authorization
if
you're
not
familiar
with
fedramp
or
the
federal
federal
risk
and
authorization
Management
program,
I
know
that
many
of
you
probably
are,
and
specifically,
though,
the
moderate
and
high
impact
levels.
There
are
two
things
to
know:
Federal
has
a
continuous
auditing
process,
it's
not
done
once
and
done,
and
annually
it's
it's
evaluated
monthly
and
second,
that
the
federal
program
has
no
exceptions
allowed
you.
A
You
have
to
account
for
all
deviations
from
your
system
service
plan,
and
if
there
are
any,
you
need
to
follow,
what's
known
as
a
poem
or
a
plan
of
action
Milestones
which
affects
effectively,
you
know
as
a
finite
timeline
for
remediation,
and
some
of
you
who
do
know
are
probably
saying
well
what
about
deviation,
requests
well,
yeah.
There
are
deviation,
requests
but
they're
highly
scrutinized
by
the
by
the
government
of
the
joint
authorization
board
and
your
your
third
party
Assessor.
A
A
So
what
controls
make
up
fedramp
and
whose
responsibility
are
they
right?
You
actually
can
read
it
as
you
might
expect.
There
are
a
lot
of
them
from
systems
acquisition
to
cyber
security,
training
and
everything
in
between
and
in
the
Sankey
diagram.
You
can
see
a
mapping
of
the
FED
ramp
controls
to
the
parties
responsible
for
their
implementation
and
operation
for
us
at
Autodesk.
A
A
And,
as
you
know,
the
FED
is
beginning
to
pay
a
lot
of
attention
to
supply
chain
security
that
solarwinds
attack
in
2020
the
bite,
Administration
agencies
executive
order,
14028
that
you
know
targeted
notable
gaps
in
our
cyber
security
hygiene
of
particular
interest.
To
today's
talk
with
section
four,
which
speaks
directly
about
supply
chain,
risk
management
or
supply
chain
security,
and
with
that
order,
nist
or
the
National
Institutes
of
standards
and
Technology
issued
guidance
based
on
its
existing
work
and
additional
best
practices
and
controls.
A
That
guidance
is
starting
to
become
adopted
by
the
fedramp
program,
which
often
refers
to
this
special
publication
800
for
control
requirements
and
of
these
controls.
We
find
quite
a
few
that
lend
in
the
software
supply
chain,
like
those
of
800
161
and
the
new
ssdf
or
secure
software
development
framework
SP,
800
218..
A
A
The
same
time
in
the
private
sector,
we
have
Frameworks
like
salsa
or
supply
chain
levels
for
software
artifacts,
which
many
of
you
know
I'm
sure
this
diagram
looks
pretty
familiar
it's
from
from
the
docs,
and
we
can
see
numerous
links
in
the
supply
chain
that
need
to
be
fortified
all
those
red
letters
up.
There
are
vectors
waiting
for
exploit,
but
I
like
to
think
about
it
from
the
attacker's
point
of
view.
What
does
it
look
like?
What
does
a
kill
chain?
A
Look
like
in
the
cloud
for
a
cloud
product,
so
here
you'll
see
at
the
bottom.
We
have
an
attacker
crafting
a
package
for
the
nefarious
payload
that
Source
package
can
be
included
as
a
library
commonly
used
OS
package
or
a
container
base
image,
or
it
could
be
any
combination
of
of
those
three
I
can
imagine
payloads
lying
inactive
for
quite
some
time
until
they
are
combined
in
the
right
environment
right
for
the
picking.
A
A
That
git
commit,
will
then
trigger
our
CI
systems
and
then
contain
those
those
bundled
payloads
see.
I
may
iterate
on
that
a
few
times,
especially
you
know
in
environments
where
we
have
large
Suites
of
interdependent
software
and
those
libraries
could
be
built
in
such
a
way
that
their
the
CI
system
becomes
a
pivot
point
into
other
software.
A
A
And
then,
finally,
that
data
can
be
exfiltrated
to
any
number
of
mechanisms
right,
I'll
pause,
so
you
can
get
that
with
us,
the
full
Suite
all
right,
all
right,
so
scary
right
what
can
be
done?
How
can
we
start
to
get
ahead
of
these
threats?
These
are
the
things
our
developers
are
thinking
about,
but
like
do
we
want
them
all
to
be
thinking
about
that.
A
Can
we
take
some
of
that
off
their
shoulders,
so
at
an
Autodesk
we've
been
building
on
what
I'm,
what
we've
been
coining,
our
trust,
Telemetry
and
building
that
into
our
CI
CD
process
processes.
Trust
Telemetry
is
the
metadata
that
we
can
rely
reliably
produce
through
the
different
phases
of
our
sdlc
and
be
confident
that
has
not
been
tampered
with
or
altered
in
any
way.
You
might
think
that
this
sounds
like
attestations
right,
for
instance,
the
CI
phase.
A
When
we
build
an
artifact,
we
should
cryptographically
sign
that
artifact
and
ship
that
signature
to
a
secure
location
for
later
validation.
That
signature
is
now
a
data
point
in
our
trust.
Telemetry
in
each
data
point
on
its
own
might
not
give
enough
confidence
to
decide
whether
a
deployment
is
safe
for
production.
However,
that
relatively
weak
confidence
when
combined
is
additive
and
just
like
mining
metadata
in
other
places.
The
signals
start
to
make
themselves
clear
when
brought
together
in
the
aggregate,
and
we
can
monitor
those
signals
for
deviation
right
using
tools
like
machine
learning.
A
We
can
alert
on
outliers.
We
can
possibly
automatically
stop
our
build
or
deploy
processes
requiring
human
oversight
to
continue,
or
maybe
we
can
deploy
into
a
Sandbox
environment
instead
of
actually
going
all
the
way
to
production
to
do
additional
automated
testing
security
scanning
before
moving
on
to
production
and
the
strength
of
those
signals
when
mapped
to
our
risk
profiles
will
guide
our
Solutions.
A
So,
let's
take
a
look
a
little
bit
more
closely
at
what
these
signals
that
we're
dealing
with
are,
as
we've
moved
through
this
sdlc
process,
we
collect
trust
Telemetry
from
our
different
build
and
deployment
systems
in
this
diagram.
You'll
see
the
now
familiar
CI,
CD
lifecycle
and,
given
that
it's
Contin,
continuous,
let's
just
arbitrarily
start
with
the
plan
phase
plan,
often
involves
people
people
you
work
with,
and
hopefully
trust.
A
If
you
don't,
you
probably
should
not
be
making
plans
with
them
right
anyway,
the
plants
eventually
boiled
down
to
some
sort
of
requirements
or
specifications
of
what
should
be
built
and
when
those
requirements
or
specs
are
stored,
where
those
requirements
or
specs
are
stored
should
be
inspectable
and
trusted.
Let's
use
jira,
for
example,
its
issue
IDs
can
be
used
as
a
lookup
for
understanding
the
decision
making
around
a
change.
A
For
example,
a
commit
message
with
fixes
issue
foo123
were
foo123,
is
the
jira
ID
of
the
issue
being
fixed
should
be
a
part
of
the
merge
commit
when
that
work
is
done.
Unfortunately,
we
don't
have
time
to
go
through
all
these,
so
let's
just
jump
ahead
to
code
where
I
have
another
example.
Code
can
be
thought
of
thought
of
as
codifying
or
transcribing.
The
intent
of
a
software
engineer
as
such
the
engineer
is
an
employee
of
the
company
should
be
able
to
attest
that
his
intent
was
or
his
or
her
intent
was
true
or
good.
A
We
can
even
Force
the
commits
to
be
signed
by
not
allowing
them
in
without
being
signed
with
with
Branch
protection
and
then
later
in
the
CI
phases,
we
can
validate
the
commits
for
a
given,
build
we're
trusted
or
built
by
trusted
by
Engineers
of
the
company.
This
is
starting
to
sound,
secure,
looking
at
this
in
the
context
of
a
of
an
actual
CI
CD
pipeline.
A
The
purpose
is
to
retain
a
back
reference
through
the
commit
messages.
So
here
we
have
signing
commits
as
an
attestation
of
developer
intent.
Then
we
see
Branch
protection
only
allowing
for
signed
commits
and
then
also
that
we're
attesting
to
the
merge
checks
were
done
by
a
GitHub
app
or
action.
Possibly
and
next
we
have
the
validation
of
those
attestations
and
sign
commits
in
our
CI
phase
and
Jenkins.
A
And
after
that
we
attest
to
the
vulnerability
scanning
that
was
done
during
that
CI
phase,
and
also
that
the
image
provenance
is
based
on
trusted
images,
which
is
actually
the
the
steps
I'm
going
to
show
you
pretty
soon.
Here
we
also
signed
the
image
denoting
that
it
was
built
on
a
known,
good,
Jenkins
right.
We
need
to
know
that
it
was
actually
produced
at
Autodesk
and
then
moving
on
to
CD.
A
You
can
see
that
there's
a
natural
break
between
our
pre
and
post
deployment
checks.
You
might
wonder
why
the
need
to
perform
checks
multiple
times,
why
not
do
them
as
early
or
as
late
as
possible?
The
idea
is
similar
to
that
defense
in
depth,
right
trust
but
verify
the
earlier.
We
can
reject
something
the
better,
but
can
we
really
trust
that
that
thing
hasn't
been
tampered
with
the
rest
of
the
way
through
the
supply
chain?
A
Also,
why
allow
our
systems
to
be
polite
be
polluted
in
later
phases
by
bad
artifacts
and
side
effects?
We
should
we
should
fail
early
here
as
well,
and
if
a
bad
actor
does
get
something
deployed,
how
long
before
that
gets
cleaned
up
by
some
post
deploy
process.
How
long
does
it
take
that
attacker
to
Pivot
there's
a
little
bit
of
a
race
there.
A
Starting
to
sound,
familiar
I
bet,
a
lot
of
these
logos
look
familiar.
It's
probably
because
you've
been
watching
the
work
by
the
cncf
on
supply
chain,
software,
best
practices
or
the
secure
software
software
Factory
research
paper
or
the
Fresca
project.
Demos
right
A,
lot
of
these
things
are
dovetailing
these
days,
and
while
our
work
at
Autodesk
predates
many
of
these
Publications
and
prototypes,
we
are
watching
them
and
hoping
to
adopt
and
donate
back
where
we
can
and
one
of
the
first
places
we're
doing.
That
is
with
the
Sig
store
project.
A
The
trust
Telemetry
that
we're
generated
that's
generated
here
can
be
used
to
satisfy
our
fedramp
container
Harding,
hardening
and
provenance
standards.
That
you
saw
that
you
saw
in
one
of
the
earlier
slides
to
facilitate
this.
We
are
building
on
six
door
cosine
and
we're
using
in
total
attestations.
You
might
already
know
both
of
these
tools.
If
you
don't
I'm
sure
most
of
you
do
cosine
cryptographically
signs
the
container
images
stores
them
in
an
oci
compliant
registry
and
I'll
speak
about
a
little
bit.
A
Zooming
out,
you
can
see
our
full
CI
CD
process,
hope
it's
readable
and
we
can
follow
this
trust
Telemetry
as
it's
used
by
the
systems,
as
we
showed
in
the
last
Slide,
the
signatures
and
excitations
created
in
the
CI
phase
and
Jenkins
and
then
stored
in
oci
image
repo.
We
also
see
the
volt
scanning
service,
storing
the
image,
the
signatures
of
images
that
were
created
by
our
security
team
at
the
top
there.
A
A
A
So
overlaying
this
diagram
on
top
of
our
CI
CD
lifecycle.
Again
we
see
that
the
attestation
is
being
used
for
our
trust,
Telemetry
and
there's
more
work
to
be
done
to
build
access
stations
in
our
pre-ci
phase
in
the
planning
and
and
kind
of
like
build
up
to
actual
software
being
written
and
then
continuously
validate
those
attestations.
Post-Deploy.
A
You
know
in
the
former
we're
looking
to
create,
like
I,
said,
custom
and
Toto
predicate
types
for
things
like
change,
requests
and
rfps,
and
for
the
latter
we're
hoping
to
extend
some
of
our
existing
binary
authorization,
tooling,
that
we
have
in
the
cloud
for
support
for
Opa
and
cosine.
So
we
can
use
those
same
policies
in
both
places.
A
So
next
up
that
was
a
lot,
but
this
is
just
the
beginning.
You
know
we're
we're
doing
a
lot
of
research
into
supply
chain
security
internally,
especially
as
we
move
into
our
fed
ramp
ATL.
We
have
things
like
machine
identity
coming
as
we
move
across
Cloud,
especially
s-bombs
are
going
to
be
a
requirement
soon.
A
So
we
are
trying
to
get
in
front
of
that
too,
and
we're
adding
more
signing
and
Providence
attestations
to
artifact
types,
one
that
you
might
be
interested
in
that
I'm
doing
a
talk
on
tomorrow
is
our
IAC,
tooling,
and
so
we're
trying
to
help
build
six
store
products
into
cross
plane,
which
is
one
of
our
our
ISC
tools
that
we
use
that's
a
1155
in
the
kubecon,
secure
identity
and
policy
track.
Thank
you.
A
A
We
do
a
lot
of
mergers
and
Acquisitions
as
a
lot
of
large
companies
do,
and
so
we
have
a
little
bit
of
everything,
but
the
reason
that
we
attacked
Jenkins
first
was
because
most
of
our
Legacy
software
and
a
lot
of
our
Cloud
are
core
Cloud
products,
utilize
a
set
of
core
libraries
that
we
call
our
PSL
or
our
pipeline
shared
Library
actually,
and
so
it
was
a.
It
was
a
perfect
entry
point
to
actually
just
plug
this
stuff
in.
A
You
know
hundreds
of
millions
of
dollars
to
be
on
the
line
right
and
so
and
and
another
thing
that
you
might
may
or
may
not
know
about.
Fedramp
is
especially
when
you're
a
company,
that's
built
of
multiple,
smaller
companies,
and
you
have
you
know
a
Fed
ramp
environment
that
may
span
many
different
product
lines.
One
incident
in
one
product
repeated
in
another
product
is
a
repeat
of
the
same
incident,
and
that's
not
good
you're
not
allowed
to
do
that.