►
From YouTube: Building Sigstore policies from scratch
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi
everyone,
my
name,
is
John
Osborne
here
with
chain
guard
I'm,
going
to
give
you
a
quick
crash
course
on
the
six
door
policy
controller.
So
let
me
share
my
screen
here
and
I'll.
Tell
you
a
little
bit
about
wine
here
and
why
this
talk,
so
my
job
at
shin
guard
is
to
essentially
take
customers
from
the
Journey
of
I.
Want
to
you
know,
start
my
software
supply
chain
Journey.
A
But
now
what
right
and
you
know
I
noticed
there
was
a
gap
missing
in
terms
of
educational
content,
where
you
know,
customers
would
start
using
six
door
to
start
signing
their
artifacts
start
signing
their
code
start
signing
s-bombs
start
signing
various
attestations
or
security
scans
Etc.
But
you
know
there
wasn't
a
whole
lot
of
examples
out
there
around.
You
know
what
to
do
next
with
all
that
information.
A
There's
plenty
of
examples
in
the
six
door
docs
around
how
to
and
a
lot
of
other
places
too
around
how
to
verify
that
a
signature
exists
or
that
an
attestation
exists
or
that
an
s-bomb
exists.
But
if
you
actually
want
to
go
towards
that
next
step
of
creating
policies
around
your
custom,
tooling
around
the
content
of
some
of
these
attachments,
that
attestations
there's
not
a
ton
of
things
out
there.
A
So
the
goal
of
this
talk
is
to
give
you
a
little
bit
of
insights
into
a
six-store
policy
controller,
how
it
works
and
then
we're
going
to
do
a
little
bit
of
a
custom
attestation
by
example,
where
we
sign
a
code
review
and
then
validate
it.
One
step
at
a
time
and
kind
of
build
that
out
and
I
put
all
the
code
examples
on
a
on
a
GitHub
repo,
which
is
also
I'll
share
towards
the
end
of
the
deck
as
well
all
right,
I'm
not
going
to
cover.
A
This
is
more
of
a
201
little
talk
but
I'm
going
to
if
you're,
if
you're,
not
too
familiar
with
with
Sig
store,
I'm
going
to
give
just
a
quick
primer
before
I
get
into
the
policy
controller
aspect,
which
is
the
really
the
focus
of
this
presentation.
A
So
Sig
store
itself.
You
know
really.
If
we
look
at
a
lot
of
the
software
supply
chain,
threats
that
are
out
there,
where
Signet
Sig
store
comes
in
really
is
that
it's
very
easy
to
use
signing
service.
A
So
you
can
sign
and
verify
all
the
handoffs
and
verify
a
lot
of
the
dependencies
that
you're
pulling
into
your
organization,
and
the
idea
is
that
I
can
I
can
close
off
a
Threat
Vector
by
signing
something
and
then
verifying
on
the
on
the
receiving
end
that
something
hasn't
been
tampered
with,
because
I'm
going
to
check
the
signatures.
I
know
the
artifact
hasn't
been
tampered
with.
I
can
check
who
signed
it.
I
can
check
some
of
the
attached
evidence
to
it,
which
would
be
an
attestation,
for
instance,
a
security
scan,
etc,
etc.
A
So
that
was
very
quick.
But
if
you,
if
you
look
at
a
lot
of
the
supply
chain,
Frameworks
that
are
out
there,
salsa
nist
CIS,
there's
a
bunch
of
others
that
have
just
started
to
add
software.
Supply
chaining
software
supply
chain
guidance.
A
lot
of
it
really
is
around
signing
in
verif
and
verifying
a
lot
of
the
different
artifacts
and
handoffs
in
the
environment.
A
So,
at
a
high
level,
that's
where
a
six
door
can
come
and
help
because
it's
very
easy
to
use
and
it
can
be
automated
very,
very
easily
for
people
and
machines
to
use
so
the
whole
really
the
whole
purpose
around
six
door.
Is
that
it's
easy
so
that
developers
don't
have
to
really
have
to
manage
Keys
anymore?
So
in
this
case
this
is
just
a
screenshot
where
I'm
signing
a
random
yaml
file
and
the
way
it
works.
This
is
in
key
list
mode.
A
There's
plenty
of
ways
to
sign
with
with
Sig
store,
not
just
keyless
mode.
You
can
automate
with
a
KMS
backend.
You
can
automate
with
your
existing
Keys
a
number
of
ways
to
do
it,
but
with
keyless
mode.
What
happens
is
similar
to
using
any
third-party
app
it
logs
it'll
pop
up,
and
you
can
log
in
with
another
user
or
log
in
with
another
identity
provider
as
your
user.
So,
in
this
case,
you
can
log
in
with
Google
or
GitHub
and
then
what's
going
to
happen
on
the
back
end,
is
six
store?
A
Is
going
to
take
that
oidt
oidc
token
that
you
generated
and
it's
going
to
generate
you
an
x509
certificate
with
the
identity
that
was
vetted
from
the
oidc
token
and
that
certificate's
gonna
be
very
short-lived
in
a
lot
of
cases,
10
minutes
and
then
you
can
sign
your
artifact
and
the
signature
will
go
in
an
oci
registry
if
it's
a
container
image
it'll
go
in
the
git,
commit
if
you're
signing,
git
commit,
etc,
etc.
A
So
I
mentioned
something
called
git
sign.
That's
really
an
extension
of
sixstore
to
sign
git
commits
you.
Can
it's
under
the
six
store
get
signed
repo?
You
can
it's
very
easy.
You
can
essentially
just
enable
it
per
repo
or
per
for
all
your
repos,
and
that's
just
a
one-time
thing
and
then
every
time
you
do
a
git
commit
it'll
automatically
pull
up
that
pop-up
box
and
you
can
log
in
and
sign
your
sign.
A
Your
artifacts
on
your
git
commits
that
way
and,
as
I
mentioned,
it's
stored
in
the
signature
itself
will
actually
be
stored
in
the
in
the
git
commit,
and
that's
just
to
look
at
it
here
on
the
right.
I
took
a
screenshot
showing
the
git
log,
which
will
actually
print
out
some
of
the
some
of
the
information
related
to
the
signature
there.
A
Now
we
want
sixth
storing
and
to
be
very
easy
to
use,
so
we
can
sign
and
verify
all
these
things
so
I
just
put
together
a
quick
primer
on
what
the
commands
would
look
like,
but
ultimately,
what
you're
doing
here
is
really
generating
this
kind
of
supply
chain
metadata.
So
you
can,
if
you
sign
something,
you'll
have
a
signature.
If
you,
you
might
sign
certain
evidence
like
an
s-bomb,
for
example,
because
of
course
you
know,
an
s-bomb
is
no
good.
A
If
it
can
be
tampered
with
rates,
you're
gonna,
you
might
sign
an
s-bomb,
you
might
sign
an
attestation
around
provenance
which
is
really
how
your
code
was
built.
So
a
lot
of
tools
will
spit
out.
You
know
a
lot
of
information
like
the
git
commit
that
was
used,
or
you
know
some
of
the
parameters
and
flags
that
were
passed
as
part
of
the
build.
You
know
you
want
to
have
that
that
body
of
evidence,
as
your
you
know,
creating
all
these
handoffs
from
development
to
production,
and
it
could
be
something
as
simple.
A
As
you
know,
I
ran
a
trivia
scan
against
my
container
image,
or
a
sneak
scan
and
I
want
to
sign
the
output
right
because
later
I
want
to
verify
that
you
know
there
were
no
critical
cdes
at
the
time
of
the
time
of
scanning
or
just
that
I
to
know
that
I
just
did
the
output
or
I
just
did
the
signing
and
I
can
sign
off
on
that.
Also.
A
A
So
that's
huge
keyless
signings
is
great
just
because
you
can
work
it
in
with
a
lot
of
existing
workflows,
especially
for
people
adopting
salsa
in
these
Frameworks,
where
you
want
your
build
service
to
sign
the
artifacts,
so
you
can
have
cryptographic
evidence
that
something
came
from
the
build
service
and
it
hasn't
been
tampered
with
now
the
services
themselves
going
GA,
that's
huge,
but
you
know
one
of
the
things
that
people
might
miss
with
the
announcement,
which
is
probably
just
as
big
is
the
slos
and
on-call
rotation.
A
That's
happening
now
so
that
really
started
with
a
GitHub
announcement
and
partnership
to
back
in
August,
but
there's
a
lot
of
big
companies
helping
support
six
door
now
chin
guards
just
one
of
many,
and
so
it's
a
it's
a
great
project,
and
you
know
you
can
confidently
sign
with
and
use
six
door,
especially
if
you
look
at
all
the
the
rapid
adoption
and
and
and
high
availability
of
it.
A
Another
thing,
too,
is
you
know
now
that
six
door
has
gotten
really
just
you
know
generated
that
generated
that
momentum
behind
it.
I
wrote
a
little
script
that
pulls
a
lot
of
the
artifacts
off
artifact
Hub
and
they
actually
have
a
six-door
flag
in
their
API
now
so
the
last
time
I
checked
a
week
or
two
ago,
it
was
over
50
of
the
artifacts,
or
at
least
the
container
images
have
already
been
signed
by
six
door
and
there's
lots
of
programming
languages
too,
that
are
now
adding
signing.
A
You
know
we're
not
actually
re-betting
the
the
our
artifacts
make
sure
they
haven't
been
tampered
with,
and
the
fact
that
six
store
is
getting
used
at
such
a
high
rate.
You
know
that's
a
lot
of
artifacts
that
we
can
validate,
that
haven't
been
tampered
with,
so
okay,
so
on
to
the
policy
controller.
So
the
the
six
door
policy
controller
itself
is
really
a
kubernetes
admission
web
hook,
it's
a
it's
a
validating
web
hook
and
it
gives
you
that
go
or
no
go
aspect
to
it.
A
Now,
there's
a
lot
of
examples,
as
I
mentioned
in
the
beginning,
the
beginning
of
the
talk
around
you
know
signing
things
with
cosine
running
cosine,
you
know
verify
verify
to
verify
the
signature.
You
can
create
an
attestation
with
cosine
a
test,
and
then
you
can
verify
the
attestation
with
cosine
also
using
the
cosine,
verify
attestation
command.
But
ultimately,
if
you
want
to
get
more
complex
outside
of
just
saying
that
those
things
exist,
you
start
wanting
to
write
your
own
policies
that
might
match
you
know.
A
Whatever
things
you
have
going
on
with
your
security
posture
or
compliance
or
regulatory
Frameworks
Etc,
you
might
have
to
create
a
custom
policy,
and
that's
really
what
the
heart
of
this
talk
is
about
so
before
I
get
into
customization
just
want
to
throw
in
a
few
examples
of
what
this
might
look
like
now.
These
were
actually
public
examples
where
people
put
in
the
logs,
so
I
I
like
to
use
real
examples.
A
This
one
was
is
part
of
salsa
and
it's
really
where
I
think
a
lot
of
people
are
trying
to
get
to.
So
what
this
is
is
this
would
be
for
salsa
level
three
and
it's
an
authenticated
and
non-falsifiable
build
service.
So
what
that
means
is
that
there's
a
everyone
you
know,
CI
CD
is
not
necessarily
a
novel
idea
at
this
point.
A
You
know
a
lot
of
people
have
built
out
CI,
CD
pipelines
and
things
like
that,
but
especially
in
a
large
organization,
there's
a
lot
of
ways
to
get
into
the
front
door
and
a
lot
of
times
there's
not
necessarily
a
check
or
block
that
things
actually
went
through
the
pipeline.
So
what
this
would
do
is
you
you
sign?
The
build
service
will
actually
sign
itself.
A
Not
not
a
person
would
actually
come
from
the
build
service
and
then
on
the
receiving
end,
you
could
have
a
policy,
a
six
door
policy
that
says
I'm
using
the
policy
controller.
That
says
something:
I've
authenticated
that
there's
cryptographic
evidence
that
this
came
from
the
build
service
and
hasn't
been
tampered
with.
So
that
would
be
one
example.
A
Another
example
might
be
a
code
review.
This
is
part
of
salsa,
but
also
part
of
a
lot
of
other
Frameworks
PCI,
now
released
code
reviews
as
part
of
their
supply
chain
guidance
for
for
that
they
just
released
this
year,
and
this
isn't
a
standardized
format
yet.
But
this
is
just
one
example
of
it:
it
might
be
an
attestation
which
could
just
be
a
you
know,
yaml
or
Json
document,
and
then
you
could
validate
using
signatures.
A
So
later
you
have
cryptographic
evidence
that
a
code
review
was
done
for
certain
things
and
then
you
could
create
policies
around
this
also
last
example
s-bombs,
because
there
really
are
a
Hot
Topic,
especially
with
cves
that
are
that
are
out
there
now.
So
you
know,
I
can
sign
my
s-bomb,
which
is
great,
because
s-bombs
aren't
helpful
if
they
can
be
tampered
with
so
sign.
A
The
s-bomb
would
would
give
you
that
that
Integrity
aspect
to
it,
but
you
might
want
to
create
a
policy
that
says
the
s-bomb
exists,
but
then
also
actually
start
validating
the
content
of
the
s-bomb.
A
A
The
the
first
two
are
the
first
one's
very
simple:
it's
just
what
images
am
I
going
to
apply
this
policy
to
right,
and
so
that's
a
URI
to
point
to
a
registry
I
can
put
in
wild
cards
in
there
if
I
want
to.
The
second
piece
is
the
authority,
so
that's
actually
what
what
or
who
signed
them.
So
in
this
case
I'm
going
to
have
a
policy
that
says
it
had
to
be
signed
using
six
store.
It
doesn't
have
to
be.
You
know
using
the
keyless
signatures
in
here.
A
This
could
be
some
sort
of
pointer
and
automation
to
longer
lib
keys
or
KMS
using
you
know,
gcp
or
AWS
or
whatever.
It
may
be,
there's
a
whole
bunch
of
options
in
here.
The
other
piece
to
it
is
who
signed
it,
and
that's
really
important
and
I.
Think
I'll
just
pause
there
for
a
second,
because
I
think
that's
a
pretty
big
fundamental
difference
between
typical.
A
You
know
signing
that
you
may
be
used
to,
and
you
know,
moving
into
more
of
a
supply
chain
framework
component
to
it
so
and
what
I
mean
by
that
is
historically
the
way
things
have
normally
been
signed.
A
You
really
care
more
about
the
key
because
you're
managing
the
key,
so
you
care
more
about
the
private
key,
and
then
you
know
validating
that
with
the
public
key
when
you
go
into
adopt
a
supply
chain
framework
you're,
not
necessarily
managing
the
keys
all
the
time,
and
because
things
can
be
automated,
you
do
have
a
more
granular
identity
associated
with
the
key.
So
you
know,
if
we're
being
honest
in
a
lot
of
you,
know,
Enterprise
signing
scenarios.
You
know
up
until
now.
A
Probably
even
include
in
that
right,
A
lot
of
times
key
is
getting
issued
and
they're,
not
very
granular,
it
might
be
the
it
might
be.
You
know,
have
a
wider
net
as
the
entire
build
service
uses.
The
entire
pipeline
uses
the
same
key
right
and
a
lot
of
times,
especially
more
regulated
organizations.
They
probably
don't
even
trust
their
developers
with
a
key,
so
you're
not
really
validating
those
developers
signed
it.
A
You
might
be
validating
that
they
push
somewhere
and
did
something
else
right,
but
with
sixstore
you
can
get
a
lot
more
granular
than
that.
So
this
is
a
policy
that
we
use
internally
at
chain
guard
where
we
make
sure
that
if
you
want
to
sign
a
if
you
want
to
push
a
git
commit
to
any
of
our
products,
this
is
something
that
we
use.
This
is
actually
the
policy
that
we
use
is
you
have
to
authenticate
and
sign.
A
You
have
to
authenticate
with
Google
and
with
hingard.dev
email
address,
which
essentially
means
we
use
Google
as
our
authentication
provider,
so
essentially
with
our
identity
providers.
So
essentially
what
that
means
is
you
have
to
have
a
chain
guard,
Dev,
email,
address
and
and
sign
in
with
it
in
order
to
generate
a
valid
signature
now
the
third
part
is
the
optional
component
to
it.
A
Those
are
attestations
so
I
like
to
think
of
that
as
attachments
or
evidence
and
again,
that's
not
necessarily
a
mandatory
field,
but
if
you
wanted
to,
for
instance,
you
know
sign
in
spdx
document
and
then
you
could
create
attestations
around
that,
so
that
would
be
okay.
I
want
to
search
for
a
specific
cve
as
an
example.
That
would
be
an
attestation
that
you
could
sign
and
create
a
policy
around
now.
The
way
these
work
is
with
a
six
door
policy
controller
if
you
want
to
deploy
an
image
to
kubernetes.
It
essentially
works
like
this.
A
If
you,
if
a
single
a
single
policy
will
pass
if
any
Authority
has
signed
to
these
things
now
you
can
put
in
a
whole
and
why
why
I
say
that
is
because
you
can
put
in
a
whole
array
of
keys.
That
would
be
valid
and
attestations.
That
would
be
valid
if
any
of
the
valid
Keys
have
signed
any
of
the
valid
attestations
that
you
include
well,
then
it
will
pass
if
there's.
If
you
have
multiple
different
policies.
Well,
then
they
all
need
to
pass.
A
So
if
you
had,
you
know,
for
instance,
a
policy
that
says
everything
has
to
be
signed
by
chain
guard,
but
then
you
had
another
policy.
That
said,
don't
admit
anything
with
the
log
for
Shell
vulnerability.
Then
it
would.
It
would
block
and
I
put
a
couple
references
down
here
if
you
wanted
to
go
see
what
all
the
fields
could
be,
but
those
are
really
at
a
high
level.
It's
these
three
components.
What
am
I,
what
are
the
images?
What
are
the
signatures
and
what
are
the
attachments
really.
A
Now
the
way
you
turn
this
on-
and
this
is
somewhat
new-
also
so
in
kubernetes-
the
way
it'll
enforce
is
by
by
namespace
labels
and
that's
the
way
it's
been
done
since
early
on
in
six
store,
so
I
can
just
create
a
label
for
my
namespace
using
policy.
Sixstore.Dev,
slash
include
set
that
to
true
and
it'll
start
go
into
enforcing
mode.
If
I
wanted
to
do
a
break
glass
scenario,
for
instance,
you
know
coming
in
on
the
weekends
and
I
don't
want
anything
to
block
anymore.
A
Whatever
that
may
be,
I
can
just
remove
that
label
assuming
I'm
I.
Have
that
permission
set
up.
You
know
I'm
a
cluster
administrator,
and
that
can
do
that
now.
One
thing
that
just
got
pushed
within
the
last
few
weeks,
so
this
might
be
new,
even
if
you're
you
know
not
new
to
six
store.
You
might
not
have
seen
this
unless
you're
following
GitHub.
All
the
time
is,
there
is
a
more
granular
label.
A
Selector
now
so,
I
can
set
things
on
a
per
namespace
instance,
but
I
can
also,
you
know,
have
policies
that
apply
to
stateful
sets
or
deployments
and
and
I
can
get
a
lot
more
granular
with
that.
Also
now,
there's
a
lot.
There's
a
lot
of
images,
a
lot
of
examples
of
how
to
create
policies
for
images
that
are
Upstream.
Some
of
them
are
entering
spread
across
a
couple
repos
in
the
six
door.
Repository
we've
also
been
creating
a
lot
of
these
internally
for
customers.
A
Our
goal
is
to
push
all
these
Upstream,
so
look
for
that
in
the
near
future.
Also,
so
if
we
create
new
policies
for
specific
cves
or
other
things
that
are
that
are
out,
our
goal
is
to
start
just
pushing
these
all
into
the
six
door
repo.
We
don't
really
want
there
to
be
secret
sauce
around
that
it
should
be.
A
So
also
this
is
somewhat
new.
Also,
is
you
can
add
for
the
cluster
image
policy?
You
can
actually
add
different
modes
so
on
a
per
policy
basis,
and
this
will
be
new
for
a
lot
of
people,
but
you
can
actually
create
policies
around
what
you
want
to
do
when
something
does
match.
So,
if
you
label
the
namespace
I
think
by
default,
what's
going
to
happen
is
if
the
namespace
is
labeled
and
the
policy
fails?
A
Well,
then
you'll
be
denied,
but
you
can
set
that
to
one
mode
which
is
really
helpful
too.
If
you
want,
you
know
certain
policies
to
be
admitted
but
to
flag
a
system
somewhere,
but
you
don't
necessarily
want
to
block
or
slow
down
based
around
the
security
posture
right
so
that
that's
something
that
you
can
set
on
a
per
cluster
basis
or
an
A
per
policy
basis.
A
Now,
building
the
cluster
image
policy
you'll
see
that
there's
some
examples
that
are
out
there,
but
they're
pretty
rudimentary
I'd
say
you
know
you
can
look
at
these
first
two
examples:
there's
a
million
examples.
That'll
show
you
just
how
to
set
up
the
images
and
Authority
Section.
You
can
also
create
a
catch-all
if
you
want
to,
for
you
know,
static,
pass
fail
for
certain
things,
all
that's
built
in
there,
but
really
the
adaptations
is
where
I
want
to
focus.
A
Some
of
these
policies
using
queue
for
the
rest
of
this
talk
so
at
a
high
level,
now
I
think
one
of
the
things
the
gaps
that
it
exists.
Probably
if
we're
being
fair
in
queue,
is
that
it's
incredibly
powerful,
but
a
lot
of
the
things
that
you
can
do
with
it
are.
If
you
go
look
at
the
docs
or
I'll,
you
know
kind
of
lumped
together,
I
guess
you
could
say,
and
so,
if
you,
but
if
you
only
care
about
creating
six
store
policies,
you
really
only
care
about
using
Q
for
data
validation.
A
Now
it's
it's
really
powerful.
If
you
look
at
a
lot
of
the
examples
that
are
out
there
with
q,
q
can
be
used
to
generate
artifacts
like
terraform
modules
or
ansible
modules,
which
I've
seen
we're
actually
used
looking
at
it
internally
to
generate
some
of
our
artifacts
as
well,
but
for
the
Paul
for
the
point
of
six
door
policies,
you
really
only
care
about
doing
data
validation.
A
So
a
few
things
that
you
need
to
know
the
most
about
for
data
validation
is
that
first,
is
it's
a
superset
of
Json
and
that's
great,
because
then
you
can,
if
you
have
an
existing
Json
or
Json
schema
even
better.
It
becomes
incredibly
easy.
So
if
you
have
a
tool
that
has
a
Json
schema,
there's
actually
a
queue
import
commands
that
actually
gives
convert
that
entirely
to
Q.
A
If
you
want
and
then
validate
it
in
the
dock,
if
you
have
random
Json
that
you
want
to
match
against
the
policy,
the
Q
policy
for
data
validation
can
actually
just
be
raw
Json.
If
you
want
to
that's
perfectly
valid
to
do
that
also,
so
it
makes
it
very
easy
to
adopt
because
virtually
any
tool
will
output,
Json
or
something
that
can
be
converted
to
Json.
A
The
second
is
that
it
treats
types
and
values
the
same
and
you'll,
see
that
as
as
I
do
the
validation,
so
I
can
set
something
to
be
a
string
or
I
can
set
it
and
then
I
can
set
it
something
more
specific
like
for
instance,
you
know
the
string
might
be
my
email
address
right
and
then
I
can
create
policies
that
just
get
more
granular
as
we
go.
A
Another
piece
is
that
it,
the
order
is
irrelevant,
and
so
that's
actually
really
helpful
from
a
from
a
validation
perspective,
because
well
one
it
just
makes
it
less
brittle.
But
two.
If
you
get
something
really
complicated
and
there's
a
lot
of
inferred
values.
Well,
you
can
use
this
command,
which
I'll
demo
for
you
or
I,
get
a
screen
screenshot
at
least
called
trim.
A
Q
trim
there's
a
command
line
tool
for
Q
and
it'll,
remove
all
those
things
and
condense
things
very
nicely,
and
so
it's
a
lot
more
easily
readable,
and
then
you
know
Q's
just
very
flexible,
so
you
can
create
if
you
want
things
to
be
open,
for
instance,
which
you
know
if
you're
using
Json.
You
probably
do
because
there
might
be
more
Fields
later
or
you
can
be
very
specific
and
have
things
closed?
That's
really
all
up
to
you.
A
So
I
wanted
to
walk
through
a
specific
example
and
how
it
and
how
it
builds
out,
but
I'm
going
to
give
you
a
little
bit
more
material
just
so
you
can
validate
what
some
of
the
stuff
is.
So
Q
is
a
Json
superset.
That's
great
opens
up
big
big
ecosystem.
A
I'm
I,
don't
program
and
go
every
day
right.
So
there's
a
lot
of
go
extensions
where
it
can
take
a
lot
of
you
know:
open,
open,
API,
schemas
and
you
know
different
things
that
might
be
have
first
class
support
and
go
and
create.
You
know,
Q
data.
You
know
schemas
and
things
right,
that's
great,
but
I'm
not
a
go
programmer
and
I.
A
I
can
just
do
Q
output
and
it'll
output
Json
for
me,
and
then,
if
I
want
to
do
some
validation
without
using
my
images
or
anything
at
all,
just
to
you
know,
shift
left
and
get
get.
You
know
that
feedback
loop
to
be
really
kind
of
lightweight
I
can
just
use
qebell
and
evaluate
Json
locally
on
my
machine
also.
A
But
what
this
policy
is
doing
here
on
the
right
is
it's:
it's
checking
against
a
serif,
so
serif
is
an
oasis
standard
for
SAS
Tools
around
standardizing
some
other
output
and
some
some
security
scanning
tools
like
in
this
case,
I
use
trivia,
can
output
into
serif,
which
is
great
because
if
you
have
a
bespoke
tool,
you
can
write
your
own
policy
for
it
and
that's
easy
to
do.
A
But
if
you
have
something
that
puts
in
a
standardized
format
like
serif
well,
then
you
can
use
the
same
policy
to
validate
against
multiple,
different
outputs,
and
so,
in
this
case,
I've
got
a
tribute.
I
had
a
tribute
scan,
although
the
output
standardized-
and
it's
just
going
to
look
for
cves
with
this
score
higher
than
9.0,
which
would
be
a
critical
cves
and
just
since
the
the
order
is
ignored,
it's
really
helpful
because
it
can
reduce
a
lot
of
the
boilerplate
code.
A
You
don't
really
want
anything
to
be
any
uglier
than
it
than
it
already
is
right,
especially
when
we're
looking
at
Json
outputs
and
things.
We
want
things
to
be
concise
and
human
readable
and
then,
because
of
that,
you
can
also
run
Q
trim.
So
in
this
case,
I
ran
Q
trim
on
that
last
one
and
it
made
things.
You
know
a
lot
easier
to
read
here.
A
If
I
had
a
lot
of
inferred
values
here
well,
it
could
have
given
cropped
those
out,
so
it
could
even
crop
those
down
more,
but
in
this
case
I
I
pretty
much
always
run.
Q
trim
just
to
have
the
most
concise
policy
that
I
that
I
need
I,
don't
really
want
any
more
text
than
I
need
in
there.
A
Great,
so
let's
build
this
out
in
action.
I'm
gonna
go
slow
for
this
part,
but
I'm
not
expecting
you
know.
I
wouldn't
expect
anybody
to
learn
Q
just
from
this
presentation,
but
my
goal
is
to
help
you
learn
what
you
can
do
with
q
kind
of
what
it
looks
like
and
then
give
you
some
examples
and
really
just
get
you
started.
If
you
have
specific
examples,
you
know
feel
free
to
just
tag
me
in
the
six
door.
A
Slack
I'll
reply
in
there
I'm
happy
to
you
know,
help
anyone
that
gets
stuck
we're,
also
working
with
a
Q
team
to
get
more
examples
that
are
out
there,
but
we
want
I
think
a
good
goal.
What
I'd
like
to
get
to
is
to
the
point
where,
if
you
want
to
do
anything,
that's
not
you
know
completely
off
the
off
the
grid.
A
Then
there
should
be
an
example
for
at
least
to
start
with
and
and
generate
artifacts
based
around
that
you
should
be
able
to
Fork
something
essentially
and
make
minimal
changes
to
it
unless
you
want
to
get
really
deep
into
the
into
the
doing
something
really
custom.
A
So
in
this
case,
I've
got
a
code
review
format
which
this
is
just
a
sample
format
that
I've
created
and
essentially
we're
going
to
validate
three
things
incrementally
and
I'll
talk
about
how
to
do
that
and
what
this
policy
would
look
like.
So
the
first
thing
I'm
going
to
do
is
validate
this
repository
format.
A
So
in
this
case,
all
I'm
going
to
check
is
that
the
reviewer
was
not
the
same
person
as
the
author,
so
we
want
to
make
sure
that
the
review
is
independent
so
before
I
get
into
actually
checking
their
repo
I
wanted
to
point
this
out,
because
this
is.
This
is
very
important
if
you
plan
to
create
any
custom
policies,
make
sure
you
pay
attention
to
this
slide.
A
So
in
my
example,
and
if
I
click
on
this
log
here
it'll
take
me
to
the
public
recore
instance
where
you
can
see
where
I
signed
this
code
review
and
this
link
will
work
in
the
in
the
deck.
It's
also
in
the
readme
which
I
put
on
the
GitHub
repo.
With
all
these
examples,
in
it
too,
but
you'll
notice
when
I
sign
this
I
use.
If
I
go
back
a
sec
here,
I
ran
cosine
a
test,
so
cosine
the
command
line,
tool,
I
tested
to
this
and
I
gave
it.
A
The
specific
command
I
gave
will
be
on
the
will
be
on
the
readme,
but
and
then
I
passed
it
this.
This
Json
file
here
as
the
predicate,
so
what
it
did
was
it
put
took
that
Json
and
put
it
inside
a
in
Toto
attestation
and
when
I
want
to
validate
this
there's
really
just
two
Fields.
There's
this
data
field
and
there's
this
timestamp
field.
A
Now
this
might
look
a
little
new
to
you
if
you
use
cosine
of
test
before,
because
if
you
run
cosine
on
the
command
line
and
you're
testing
known
formats,
it's
not
going
to
be
all
packed
in
here,
but
the
purposes
of
custom
attestations
and
using
the
six
store
controller
everything
just
kind
of
gets
put
in
this
big
string.
But
don't
worry
it's
still.
It's
not
a
big
deal
at
all.
There's
built-in
tools
to
help
fix
that.
A
So
really
you
have
two
options.
Now
you
can
just
parse
that
string
out
using
Q,
so
you
can
create
a
policy
that
just
parses
the
string
on
the
left
in
this
case
I'm
just
using
a
regex.
So
you
know
wouldn't
expect
anyone
to
necessarily
know
regex
I
know
I
always
have
to
Google
regex
format,
pretty
much
off
the
top
of
offline,
but
on
the
left.
What
I'm
doing
is
I'm
just
setting
a
simple
policy
to
parse
the
string
there
now
that'll.
A
This
policy
on
the
left
will
fail
if
the
phrase
bad
bad
bad,
two
bads
are
okay,
but
three
bads
is
just
over
the
line,
so
it
all
fails
policy
if
it's
got
bad
bad
bad
now.
A
This
is
usually
good
enough
for
a
lot
of
things,
especially
for
people
just
starting
off,
because
they
might
just
want
to
validate
that
that
something
exists
in
the
attestation
or
doesn't
exist
in
the
attestation
and
a
lot
of
times
a
really
common
way
to
do
this
might
be,
you
might
be
checking
for
a
specific
version
of
software
or
something
in
your
s-bomb.
A
If
you
just
care
that
the
pattern
for
that
that
specific
file
or
thing
you
were
looking
at
was
in
the
s-bomb,
all
you
have
to
do
is
here
is
only
have
to
just
write
a
regex
that
checks
against
that.
So
it's
very,
very
simple,
but
if
you
want
to
check
that
things
are
nested
inside
element
inside
other
elements,
you
really
want
to
do
something
very
powerful
with
q.
Q
can
do
a
lot
more
things
and
Json
can
do
there's
logic
to
it.
There's
you
can
even
create
conditional
things
in
here.
A
That
would
you
know
potentially
do
for
loops
and
things
like
that,
but
there's
built-in
tools
to
do
that.
So
if
you
remember
it
was
just
one
big
long
ugly
string,
I
can
create
another
element
in
here
that
and
use
a
built-in
Json
encoder
that
comes
as
part
of
queue
and
create
a
Json,
what
they
call
a
struct
and
then
once
I
create
a
struct.
Well,
then
I
can
just
start
use
that
built-in
Q
package
to
create
the
Json
and
then
I
can
start
validating
it.
A
A
So
the
first
thing
I'm
going
to
do
is
validate
the
repository,
so
in
this
case,
I
want
to
validate
three
things:
I
want
to
validate
that
the
branch
is
set
to
either
main
or
origin.
Slash
main
that
is
just
in
queue
is
pretty
simple:
it's
just
that
or
bar.
We
should
all
be
familiar
with
that.
The
second
thing
I'm
going
to
do
is
I
want
to
know
that
the
URI
is
came
from
my
company,
so
I
want
or
my
organization
in
GitHub.
A
So
in
this
case
it's
going
to
be
the
URI
has
to
be
github.com
example,
because
that's
my
organizational
GitHub,
my
GitHub
organization
and
then
the
third
thing
is
that
type
which
you
can
see
in
the
example
is
set
to
get
I'm
going
to,
let
that
just
be
any
old
string.
That's
perfectly
fine.
A
Anything
can
be
put
in
there
because
I
don't
necessarily
know
what
that
type
might
I,
don't
know
all
the
options
that
type
might
be
so
I
just
put
that
little
question
mark
in
there
and
that'll
allow
for
that,
and
then,
since
this
is
a
I'm,
creating
essentially
a
schema
here
by
adding
the
what
they
call
a
definition
in
queue
with
this
hashtag
and
if
I
don't
add
these
dot
dot
dots
it'll
be
what's
called
a
closed
struct,
which
means
that
everything
has
to
match
exactly,
but
I
won't
be
able
to
add
more
Fields
later
so
typically,
what
I
like
to
do
is
add
the
dots
just
because
which
makes
the
definition
open
so
that
way,
if
you're,
if
you're
using
Json,
there's
a
good
chance
that
you
might
be
adding
more
things
to
a
schema
later
so
I
like
to
have
that
flexibility,
so
in
this
case
I'm
going
to
check
that
predicate
data,
so
I'll,
just
just
like
in
the
last
example,
I've
got
Json
data
here,
I'll
Marshall
it
and
then
I'll
just
make
sure
that
there's
a
repo
field
embedded
in
that
Json
that
matches
this
schema.
A
A
Sorry,
you
have
to
look
at
me
for
a
second
all
right,
so
I'm
just
going
to
write,
cosine
verify
I'm
going
to
add
the
repo
check,
which
was
the
which
was
the
queue
statement
that
I
just
showed
you
in
the
presentation
and
then
I'll
give
it
the
slash
type
for
custom
and
when
we
run
this,
it
should
verify
and
you'll
see
this
we'll
be
validating
against
the
queue
signatures.
Repo
Dash
check,
Dash
queue
and
then
there's
a
bunch
of
garbly
goop
down
here.
A
A
So
there
we
go
so
that
was
the
existing
Json,
which
you
saw
in
the
code
review,
and
this
part
of
the
validation
for
the
repo
check
is
just
checking
making
sure
that
the
repo
follows
that
format.
It's
got,
the
Json
needs
a
repo
struct
and
it
needs
to
have
a
type
field.
That's
set
to
anything.
It
needs
to
have
the
URI
set
to
github.com
example,
and
it's
got
to
have
a
branch
that
is
set
to
main
or
origin
mean
all
right.
Next
example.
A
So
second
one
is
a
lot
simpler
if
I
come
up
here.
All
we're
saying
now
is
just
the
author.
The
author
has
to
be
a
string
and
they
have
to
have
an
email
address
that
came
from
example.com
because
I
want
them
to.
You
know
be
someone
that
works
for
my
company,
of
course,
so
I
can
create
that
definition.
A
For
that
schema,
and
then
all
I'm
going
to
do
down
here
is
just
make
sure
that
this
Json
has
an
author
field
and
that
author
field
equals
the
author
structure
from
from
my
definition
here,
so
not
too
difficult.
A
A
File,
which
is
the
queue
this
is
just
for,
checking
locally
I'll,
show
you
how
to
move
this
into
the
into
the
repo
or
into
the
six-star
policy
controller.
When
we
get
towards
the
end,
and
you
can
see
yep
it
validated
against
that
key
policy-
author
Dash
email.
A
Finally,
the
third
thing
I'm
going
to
do
is
check
that
the
it's
an
independent
review,
so
I'm
going
to
check.
Take
the
author
field,
which
we
already
know,
is
a
string
from
the
previous
example
and
then
I'm
just
going
to
make
sure
that
this
reviewer
field
that's
also
a
string
and
that
they
don't
equal
each
other,
and
this
is
a
differentiator
between
Json
and
Q.
You
wouldn't
be
able
to
really
compare
Fields
just
doing
raw
Json
right.
A
You
just
be
able
to
know
if
they
had
certain
you
know
traits
about
them,
but
with
Q
I
can
make
sure
that
I
can
actually
compare
these
values,
which
makes
it
really
powerful.
So
I
have
a
reviewer
and
it's
going
to
not
equal
the
author
there
and
then,
when
I
put
this
embed
this
down
inside
my
Json
data.
All
it's
going
to
make
sure
it's
a
top
level
item.
So
it's
just
going
to
make
sure
that
all
the
Json
data
that's
there
follows
follows
that
format.
A
And
so
you
can
see
I'm
working
with
that's
the
example
from
the
slide
and
I
can
run
cosine
verify
again.
You
don't
have
to
necessarily
write
down
all
these
commands
they're
all
going
to
be
on
the
read
on
the
readme,
with
all
the
full
examples.
A
And
it
didn't
like
that,
it
said:
well,
I
got
an
error.
It
said
field
not
allowed
repo.
Okay,
this
is
actually
a
good.
You
know
this
breaking
is
not
a
is
not
a
bad
thing
to
be
showing
here.
So
why
did
this
break?
Well?
If
I
come
back
to
the
policy
here,
I'm
gonna
go
back
to
my
slide.
A
Come
back
to
the
policy.
What
it's
saying
is
independent
review.
Okay!
Well,
if
you
remember
I
said:
if
I
didn't
add
these
dots
down
here,
the
struct
is
closed.
So
that
means
the
repo
information
would
now
be
invalid.
Essentially,
it
would
say
expect
an
attestation
that
only
had
author
and
only
had
reviewer
so
I
can
make
this
struct
open
to
fix
this.
A
So
what
I'll
do
is
I'll,
come
back
to
my
independent
review
and
I'm
going
to
add
these
dots
here
and
that'll
allow
my
repo
data
and
I
will
run
this
again
and
that
should
work
perfect,
so
that
worked
and
before
I
forget
I'm,
going
to
come
back
to
my
example
here
at
the
end
and
make
sure
that
these
other
ones
also
are
validating
against
these
things.
Okay,
so
I
will
update
that
slide
screenshot
before
before
I
before
I
put
this
online
Okay.
A
So
that's
all
just
using
cosine
I
haven't
even
used
the
policy
controller
yet
but
I'm
trying
to
show
you
shift
left
and
just
validating
this
step
with
with
q,
and
once
you
have
done
that,
it's
incredibly
easy
to
use
the
six
Torah
policy
controller,
because
now
you're
just
actually
copying
and
pasting
so
I
can
take
all
those
definitions
put
them
all
together.
A
You
can
run
trim
if
you
want
to
not
mandatory,
but
it'll
help
that
that
stuff,
then
I
can
run
cosine
verify
if
I
wanted
to
use
cosine
to
double
check
that
it's
all
working
and
then
once
there
I
have
like
you
all
I
get
to
do
is
copy
and
paste
it
in
so
I
I
cropped
it
just
for
the
purposes
of
running
this
example.
But
I
can.
A
I'm
going
to
turn
on
enforcements
in
my
repo
and
then
I'll
put
all
these
things
together.
I'll
try
to
deploy
this
and
I'm
just
going
to
use
the
chain
guard
enforce
product
to
install
this,
but
it's
not
really
part
of
it.
You
could
have
installed
the
if
you
just
wanted
to
the
policy
controller
aspect
to
it.
You
could
have
done
this
separately
and
I.
Imagine
I
probably
got
logged
out.
Probably
this
point,
so
I'm
gonna
log
in
real
quick.
A
A
And
I
installed
the
policy
using
the
chain,
CTL
policies
aspect
to
it.
It's
got
a
policy
called
code
review
and
again
all
that
was
is
just
policies
we
created
already
copied
and
pasted
into
my
six
door.
My
cluster
image
policy
crd
and
it's
going
to
validate
the
predicate
it's
going
to
validate
the
repo,
the
author,
email
and
kind
of
review.
All
that
stuff.
You
don't
even
have
to
use
these
definition
Fields,
but
they're
helpful.
A
If
you
want
to
they're
helpful
for
a
lot
of
reasons,
one
you
could
create
these
as
packages
that
get
imported
into
different
policies,
you're
not
doing
a
bunch
of
boilerplate
things,
and
then
you
could.
You
know
if
you
had
multiple
authors,
for
instance
in
the
status
station.
A
You
just
have
to
cross-reference
them
once
so,
I
like
to
use
them
as
a
default,
but
if
you're
doing
something
simple,
they're
really
not
necessarily
necessary
at
all
and
if
you
want
to
just
validate
with
raw
Json
they're,
not
necessary
at
all
either
but
I
copied
and
pasted
that
in
there
and
then
I'm
going
to
that's
my
readme
and
it'll
come
back
here
and
then
I
will
try
to
run
this
and
I'm
guessing.
This
will
pass
because
it
does
have
that
attachment.
A
So
we
hope
it
passes
and
great
that
passes,
but
just
to
keep
us
honest,
let's,
let's
go
change
the
policy
and
you
know
we'll
mess
it
up
on
purpose,
just
to
make
sure
that
it's
working.
So
let's
see
I'll
delete
that
pod.
A
There
we
go,
you
can
see
it,
you
can
see.
I've
run
this
a
lot
of
times,
so
I
can't
remember
commands
so
there
we
go
group
ctOS,
leave
the
Pod
grace
period
equals
zero.
All
right
now,
just
to
keep
us
honest,
I
will
mess
up
the
policy
on
purpose.
We'll
say
that
the
example
has
to
come
from
example.org
an
example,
and
then
we
will.
A
Delete
that
policy
and
add
it
back
and
update
it,
but
just
to
be
doubly
sure
that
it's
gone
make
sure,
there's
no
policies
at
all,
and
then
we
will
install
the
policy
again
and
yo.
Now
it's
giving
us
a
warning
because
we
didn't
always
said
for
our
identity
was
that
it
had
to
be
signed
by
keystore,
because
we
didn't
necessarily
care
about
who's,
signing
it
for
the
purposes
of
this
demo.
A
But
if
you
wanted
to,
you
could
add,
you
know
that
had
to
be
signed
by,
you
know
had
to
become
from
your
GitHub
SSO
and
it
had
to
be
signed
from
a
chain
guard,
Dev,
email
address
or
whatever
your
you
know,
corporate
SSO
is
that's
all
information
that
you
can
set
in
there,
but
now
this
is
created
and
again
this
should
break
this
time
because
we
changed.
A
A
So
if
I
go
to
run
that
same
image
again
that
passed,
let's
hope
this
fails.
A
The
demo
gods
are
with
us
and
yes
that
failed-
and
it
tells
you
that
the
author
had
an
invalid
email,
because
the
value
was
example.com
and
that
was
out
of
the
bounds
we
expected
or
we
had
this
as
the
policy
example.org,
so
that
is
building
it
by
example,
and
that's
towards
the
end
of
my
presentation,
I
put
all
the
code
examples
that
I
used
for
this
on
six
door:
custom
policies,
GitHub
repo-
if
you
have
specific
examples
about
syntax
check,
the
Q,
spec
and
also
you
know,
feel
free
to
just
tag
me
in
the
slack
Channel.
A
There's
some.
If
you're
doing
some
basic
stuff,
you
just
go
to
the
sigster.dev
site
or
check
the
six
door
policy
controller
readme.
But
if
you're
trying
to
create
something
custom-
and
you
know
you're-
hitting
some
troubles,
you
know
feel
free
to
just
tag
me
in
the
slack.
Channel
and
I
can
point
you
on
your
way.
So
thanks
everyone
for
joining.
Let
me
see
back
to
my
original
appreciate
your
time
hope
this
was
helpful.
A
I
know
it
was
probably
a
little
bit
more
advanced
than
we
normally
cover
things
on
a
on
a
on
a
webinar
but
yeah
I
think
there's
been
enough.
Six
door
talks
out
there
that,
hopefully
you
can
grab
one
of
those.
If
you
just
want.
You
know
really
the
high
level
uses,
and
hopefully,
if
you're,
creating
policies
that
you
found
this
helpful.
But
if
there's
anything
else
you
want
to
see,
you
know
just
feel
free
to
reach
out.
So
thanks.
Everyone
talk
to
you
later.