►
From YouTube: It's Dangerous To SLSA Alone Out There! Take This Artifact... - Mihai Maruseac & Michael Lieberman
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. 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.
It's Dangerous To SLSA Alone Out There! Take This Artifact Knowledge Graph! - Mihai Maruseac, Google & Michael Lieberman, Independent
Speakers: Mihai Maruseac, Michael Lieberman
By now, we’re getting bored of hearing the “am I affected by X vulnerability?” question. However, as supply chain attacks become more sophisticated, answering just this question is insufficient. Instead, we need to think about: “If TravisCI was compromised, which software is affected? With a bad actor in your supply chain, what's the blast radius?” There is a ton of information today in SBOMs, in-toto/SLSA attestations, etc. However, these documents observed individually provide limited information, but when put together and related, super-additively expand the knowledge base of our software supply chain. We built a supply chain knowledge graph tool to help better understand the relationships between artifacts and their metadata/identities. Through this high-fidelity graph, we not only answer the hard questions posed earlier, but also make new discoveries. For example, we found that most build-systems rely not only on obvious dependencies like gcc, but often overlooked projects like libpcre and sed.
A
All
right
so
we're
going
to
be
talking
about
an
artifact,
Knowledge
Graph
that
we
built
out
and
we're
calling
guac
just
a
couple.
A
little
introduction
to
myself
so
I'm
Mike,
Lieberman
I'm,
a
CTO
and
founder
co-founder
of
kusari
supply
chain
security,
startup
and
I
do
a
lot
of
work
with
the
cncf
I'm.
A
security
tag
lead
I,
helped
co-lead
the
cncf,
secure
software
Factory
reference
architecture
as
well
as
a
maintainer
on
Fresca,
an
openssf
project.
B
A
All
right,
so,
what's
the
problem
right?
What's
the
problem
here
that
we're
trying
to
solve?
Well,
you
know,
there's
all
this
stuff,
that's
happening
in
your
software
supply
chain
right.
You
know
you
keep
hearing
about,
hey
I
need
I
need
to
be
generating.
Salsa
I
need
to
be
consuming.
Salsa
I
need
to
be
generating.
S-Bombs
I
need
to
be
making
sure
that
everybody
else
has
s-bombs.
I
need
to
be
analyzing,
those
s-bombs
and
all
that
great
stuff
right.
But
one
of
the
big
problems
that
people
keep
bringing
up
is
okay.
A
A
Some
of
this
stuff
is
stored
in
you
know,
rest
apis,
random,
buckets
in
oci
and
all
that
sort
of
stuff,
and
usually
when
you
even
pull
down
a
package,
you
know
you
might
be
pulling
down
a
salsa
attestation
for
that
particular
package.
But
what
about
its
dependencies?
You're,
not
pulling
information
down
there
and
like
this
is
similar
to
some
of
the
stuff
we
saw
with,
for
example,
log4j
where
it
was.
A
The
compromised
versions
of
log4j
were
really
deep
in
your
supply
chain
right
where
you
thought
no
I'm,
not
using
log4j,
but
it
turns
out
you're
relying
on
some
Library,
which
relies
on
some
Library,
which
relies
on
some
library
that
does
use
a
compromised
version
of
that,
and
so
once
you've
got
into
go
two
or
three
layers
in,
as
you
can
kind
of
see
there
in
the
red,
it's
like
I,
don't
know,
am
I
pulling
stuff
in
does
it
exist.
I
have
no
idea.
A
A
So
that's
stuff,
like
s-bomb,
salsa,
attestations,
Vex,
all
sorts
of
other
in
Toto
attestations
as
well,
and
so
then
we
have
sort
of
aggregation
and
synthesis
right.
You
want
to
be
able
to
then
consume
all
that
data
analyze
it
make.
You
know
be
able
to
then
go
into
the
next
piece,
which
is
like
you
want
to
figure
out
insight
and
then
generate
policy
that
can
make
decisions
based
on
that
data
that
you've,
aggregated
and
synthesized,
and
so
guac
fits
in
on
that
green
box.
There
for
aggregation
and
synthesis.
A
So,
okay,
so
what
exactly
is
guac
right?
So
guac?
It's
a
background
name
for
graph
for
understanding,
artifact
composition
naming
is
hard,
but
it
is
a
knowledge
graph
of
software
metadata
to
answer
security
and
supply
chain
questions
right.
So
the
idea
here
is,
as
I
mentioned
previously
right.
You
have
all
this
data.
How
do
I
actually
ingest
it
and
start
asking
like
broader
questions
about
the
problem.
A
So
let's
talk
a
little
bit
about
how
it
works
so
at
a
very
high
level,
we're
consuming
all
sorts
of
records
from
stuff
like
Sig
store
and
that
are
stored
in
things
like
recore
or
oci
or
buckets,
or
you
know,
whatever
we're
ingesting.
You
know
various
things
from
you
know,
s-bombs
that
are
generated
by
various
tools:
we're
ingesting
vulnerability,
data
from
various
streams.
A
And
now
what
does
this
look
like
right?
So,
a
few
slides
ago,
I
showed
you,
you
know
what
was
implicitly
there
in
your
supply
chain
right.
There
are
all
these
artifacts
and
there
might
be
some
documents
here
and
there
and
it's
not
very
clear
where
all
that
stuff
lives,
but
what
guac
allows
us
to
do
is
guac
allows
us
to
actually
build
out
a
graph
with
those
relationships
so
that
we
know
you
know
this.
S-Bomb
was
you
know
we
have
records
inside
of
a
database
of
hey.
A
We
also
now
have
a
bunch
of
additional
metadata
about
the
actual
artifacts
and
not
just
about
the
about
a
bunch
of
additional
artifacts
we're,
including
stuff
like
Vex
and
who
might
have
signed
off
on
that
Vex,
and
we
plan
to
sort
of
also
include
all
sorts
of
other
metadata
as
well
right,
and
so
it's
a
record
of
those
ingested
documents.
We
also
then
sort
of
parse
those
ingested
documents
allowing
us
to
then
generate
the
relationships
between
them.
A
You
know
a
graph
that
allows
us
to
sort
of
make
it
easier
to
sort
of
query
about
information
about
what
depends
on
what
who
attested
to
what
actual,
what
what
actual
piece
of
information
we
also
plan
to
sort
of
include
sort
of
temporal
data
like
assertions
on
vulnerability
scans.
So
you
know
one
of
the
big
things
is
like
hey,
yeah
yeah.
We
we
scan
that
artifact
yeah,
you
scanned
it.
B
So
we
have
a
local
instance
of
guac
that
we
ingested
several
documents
and
we
have
several
nodes
already
in
the
neo4j
database.
We
are
going
to
use
the
neo4
geographical
interface
for
queries
at
the
moment,
but
we
plan
in
the
future
to
actually
create
apis,
so
that
would
give
you
graphql
results.
Instead
of
opening
the
neo4j
interface.
So
now,
I
will
type
A
neo4j
queries
in
here
to
just
see
what
we
ingested
from
South
Side
stations
and
spdx
and
so
on,
but
in
the
next
release
in
the
future,
release
we'll
have
a
proper
queries.
B
Okay,
so
for
this
one
we
have
in
our
graph,
we
have
artifact
nodes.
We
have
package
nodes,
this
one
is
a
scorecards.
So
if
you're,
it's
it's
an
artist,
it's
an
attestation,
so
the
scorecards
I
think
it's
this
one.
The
metadata
and
this
one
is
the
Builder
so
like
when
you
are
using
cell
sites,
the
salsa,
Builder
and
so
on,
and
there
are
all
of
the
relationship
in
them.
All
of
this
is
detected
based
on
what
we
parsing
documents.
B
B
So
first
thing,
just
a
simple
graphql
query:
to
see
how
many
nodes
we
have
so
we
ingested
around
70
documents
and
in
total
we
have
8
000
nodes
out
of
all
of
these
types
that
we've
seen
before
and
now
we
can
go
and
explore
what
we
have
here:
I'm
not
going
to
type
the
queries
again.
So
let's
try
first
to
explore
kubernetes
cluster.
B
So
if
I,
actually,
let
me
begin
with
a
simple
package:
node
and
return
just
that
one
and
because
I
don't
want
to
return
all
of
them.
I
will
return
just
10..
So
the
graphql
interface
here
offers
multiple
options
to
look
at
the
results.
One
is
as
a
table
with
jsons
and
the
other
one
is
as
a
graph,
we'll
probably
use
the
graph
representation
most
of
the
time,
because
it's
easier
for
visualization,
but
in
some
cases
the
table
one
would
be
better
Suited
so
for
distant
notes
that
we
limited,
we
have
all
of
the
attributes.
B
And
then
there
is
the
stacks
that
we
have
so
so
that
we
can
identify
which
are
binaries
artifacts,
which
are
container
Docker,
container,
artifacts
and
so
on.
So
now,
let's
look.
Let's
explore
the
kubernetes
container.
I
am
expanding
this
query
so
I'm
taking
a
package
where
the
Pearl
contains
kubernetes
controllers
manager
and
I'm
returning
that
node.
So
it
should
be
image.
B
I
think
I
deleted
something.
Yeah
I
deleted
one
dash
here,
okay,
so
this
one
has
several
nodes
and
I
can
zoom
all
of
them
into
the
graph.
We
will
pick
one
of
these
versions,
so
let's
say:
if
I
look
at
them,
each
one
of
them
has
a
different
version,
so
this
is
one
24
4,
124,
5
and
so
on.
We
can
pick
1246
and
now
we'll
have
just
one
single
node.
B
And
now
we
want
to
ask
queries
about
this
one.
So
one
way
we
can
ask
queries
is
select
the
node
and
expand
all
of
the
relationships,
but
this
definitely
doesn't
work
because
there
are
so
many
dependencies
on
this
project
on
this
container.
Another
one
is
to
actually
run
the
queries
ourselves,
so
I
will
copy
this
one
where.
B
B
B
Sorry,
one
of
them
is
the
go
Runner
I,
look
at
the
name,
so
one
that's
one
binary
and
the
other
one
is
the
cube
controller
manager
and
now
I
want
to
see
which
of
these
binaries
has
attestations
on
them.
So
what
I
can
do
I
can
expand
this
query
to
also
look
if
I
have
metadata
or
attestations
in
them.
Let
me
copy
this
bigger
query.
B
Okay,
so
now
out
of
all
of
those
nodes,
I
can
also
rotate
them
around
to
make
them
look
better.
So
I
have
this
attestation
that
refers
to
this
node,
if
I
scroll
to
the
name
to
the
cube
controller
manager,
but
this
other
dependency
that
was
the
go
Runner,
doesn't
have
any
other
station
in
this
container.
So
some
policies,
that
would
say
I
only
trust
stuff
that
has
attestations
with
flag
this
container,
which
say
this
doesn't
follow
the
policy
rejected.
B
B
B
Where
I
am
looking
for
this
Debian
node
that
I
have
what
are
its
dependencies
and
then
what
are
other
packages
that
also
depend
on
those
and
then
I
order
based
on
the
dependencies.
So
I
have
several
containers
that
have
a
lot
of
shared
dependencies
in
common,
like
1500
and
so
on,
but
then
I
also
have
smaller
images
that
only
have
one
single
dependency
in
common,
so
with
guac,
it's
easy
to
determine
which
are
slim
dependencies
which
are
harder,
bigger
ones
and
so
on
and
finally
another
query
that
we
might
want
to
look
is
for
log4j.
B
B
So,
in
my
case,
I
have
two
artifacts
that
contain
op4j.
One
of
them
is
has
been
generated
from
spdx
vulnerable.
So
it's
it's
an
image
that
we
know
has
been
vulnerable
in
our
document.
The
other
one
has
been
generated
from
spdx
statement
that
says
that
the
image
has
been
fixed.
However,
if
you
look
at
this
image,
you
see
that
both
of
them
depend
on
the
same
log
for
J
packages,
so
the
fixing
actually
didn't
contain
a
fix
for
log4j
contain
the
fix
for
some
other
vulnerability
and,
if
I
replace
this
log4j
with
the
Apache
commands.
B
Okay,
so
in
this
case,
I
have
two
containers
with
each
one
of
them,
depending
on
another
container
that
is
fixed,
so
actually
the
spds
that
was
fixed
was
fixing.
The
Apache
container
was
not
fixing
the
lock
for
tray,
so
it's
very
easy
to
go
out
to
identify
what
got
fixed.
What
didn't
you
can
also
write,
bigger
queries
to
identify
what
is
the
plan
to
fix
what
what
dependencies
you
need
to
update
to
fix
to
update
after
a
vulnerable
dependencies,
and
so
on
back
to
you.
A
So
yeah
just
a
highlight
there
we
showed
a
little
a
few
things
off
for
guac
there
and,
as
mihai
mentioned,
it
was
only
like
70
or
so
documents
that
we
had
ingested
for
that
specific
thing.
But
we
have
been
testing
this
out
with
you
know
ingesting
tens
of
thousands
of
documents
related
to
you
know
tens
of
thousands
of
different
artifacts
packages,
images
and
so
on.
A
It's
kind
of
a
little
hard
to
demo
that
just
given
how
big
that
is
right
now,
but
wanted
to
sort
of
show
you
you
know
we
are
sort
of
looking
at
that
and
and
seeing
a
lot
of
interesting
relationships
between
packages
between
artifacts,
between
attestations
for
those
things
and
and
so
on,
and
then
the
other.
You
know
nice
thing,
that's
kind
of
coming
out
of
some
of
the
things
that
we're
seeing
here
is.
A
Is
we
found
in
certain
cases
like
certain
you
know,
a
lack
of
information
about
certain
artifacts,
but
then
you
start
to
ingest
other
documents
and
then
all
of
a
sudden
those
documents
might
have
some
additional
information.
And
you
know
if
you-
and
if
you
trust
that,
let's
say
the
person
producing
that
document,
then
you
can
kind
of
ingest
that
and
immediately
you
get
a
much
better
understanding
of
your
supply
chain
all
right.
So
what
what
are
some
of
the
challenges
we're
having
as
we're
building
this
out?
A
So
once
again,
this
this
thing
here
is
is
very
much
pre-alpha
at
this
point.
You
know
we're
doing
a
lot
of
work
on
it,
but
it
is
going
to
take
a
while
for
it
to
mature
so,
but
while
kind
of
building
this
out,
what
are
some
of
the
challenges
right?
So
one
of
the
big
ones
is
data
quality
right
so
without
a
lot
of
different
attestations
from
a
lot
of
different
sources
and
good
high
quality
documents.
So
you
know
it's
going
to
be
hard
to
sort
of
I.
A
A
Another
thing
we
noticed
is
a
lot
of
document
generation
doesn't
actually
follow
the
specifications,
a
lot
of
things
that
are
generating
s-bombs
generate
like
90
to
the
spec,
but
that
kind
of
leads
to
a
problem
where,
if
two
different
documents
don't
generate
the
correct,
let's
say
s-bomb
or
the
correct
salsa
attestation,
then
it's
almost
impossible
for
guac
to
ingest
it
because
then
we'd
have
to
support.
You
know
a
tool,
A's
sort
of
spdx
implementation
or
whatever
and
that's
kind
of
very,
very
difficult.
A
So
that's
one
big
big
challenge
that
we're
dealing
with
right
now.
Another
big
challenge
is
actually
the
quantity
of
the
metadata
and
also
the
completeness
of
the
metadata,
so
we're
seeing
in
a
lot
of
documents.
You
know
a
lot
of
documents
and
we
get
it
right.
You
know
this
stuff
is
still
relatively
new
relatively
nascent,
but
for
a
lot
of
folks
you
know
they're,
including
the
bare
minimum
in
the
salsa
attestation
or
the
bare
minimum
in
the
in
their
s-bomb
and
the
less
data.
A
That's
there
the
less
valuable
it
is
overall
and
generally
you
know
just
given
how
new
a
lot
of
this
stuff
is.
Is
that
you
know
there's
some
documents
that
are
starting
to
sorry.
There
are
some
artifacts
and
packages
that
are
generating
attestations
and
s-bombs,
and
all
that
good
stuff,
but
but
that
needs
to
increase
drastically,
because
without
that,
then
you
know,
there's
not
going
to
be
a
lot
of
data
to
then
use
to
analyze
your
supply
chain.
A
Another
big
issue
is
also
sort
of
interoperability,
and
this
is
something
that
you
know.
We
we
noticed
is
there's
lots
of
different
software
identifiers
right,
and
that
also
includes
different
hash
algorithms.
So
if
one
document
refers
to
a
hash
by
shot,
256
and
another
document
refers
to
that
same
artifact,
but
using
sha1,
it's
not
going
to
line
up
unless
you
have
some
understanding
of
yeah.
Actually
those
that
is
the
same
literal
thing
and
that
kind
of
you
know
obviously
causes
a
lot
of
challenges
there
and
then
also
with
stuff.
A
Like
you
know,
Pearl
right
stuff,
like
the
hash,
is
optional
in
Pearl
and
so
there's
also
a
lot
of
stuff
of
hey.
These
two
things
are
claiming
to
have
be
the
same
package,
but
are
they
actually
the
same
package?
It
can
be
very
difficult
to
figure
out
and
then
also
obviously
scalability
right.
The
ecosystem
is
very
large
and
you
know
we're
looking
to
see
how
can
we
make
it
easy
to
ingest
lots
of
different
artifacts,
especially
in
that
open
source
space?
A
You
know
what
what
are
the
ones
that
make
the
most
sense,
and
how
do
we
make
sure
that
you
know
if
we
begin
to
ingest
hundreds
of
thousands
of
artifacts,
this
whole
thing
doesn't
fall
over
so
now
we
can
talk
about
a
little
bit
about
the
next
steps
right.
So
for
us,
the
big
thing
for
us
is
we
really
want
to
work
with
the
community
more
right.
We
want
to
ingest
a
lot
more
document
and
metadata
types
as
well
as
other
sort
of
interesting
metadata.
A
You
can
sort
of
query
something
like
guap
to
see
if
there
is
a
Vex
for
that,
we're
also
looking
to
integrate
with
sort
of
vulnerability
streams
like
osv
and
all
those
sorts
of
things
to
sort
of
figure
out.
You
know
to
pull
in
additional
information
at
a
given
time,
we're
also
looking
to
sort
of
integrate
with
some
other
stuff
like
git,
bomb
and
gitoid,
so
that
we
can
have.
You
know
the
git
object.
A
Id
is
a
pretty
useful
sort
of
software
identifier
and
so
we're
looking
to
sort
of
integrate
with
that.
We
also
want
to
help
Harden
existing
types,
so
we
want
to
work
with
the
community
in
you
know,
on
on
salsa
and
I'm,
a
steering
committee.
Member
of
salsa,
but-
and
you
know,
we
also
have
a
bunch
of
folks
who
are
maintainers
on
some
of
the
s-bomb
specifications
as
well,
we're
looking
to
kind
of
figure
out
like
what
can
we
do
to
make
it
easier
to
make
sure
that
all
of
these
identifiers
can
help?
A
A
We
also
want
to
create
a
lot
of
new
relationship
types
like
certification,
so,
like
hey,
did
an
organization
or
an
auditor
actually
certify
this
particular
application,
or
this
particular
package.
We
want
to
also
be
able
to
you
know,
pull
in
stuff
like
build
inputs
where,
whether
it's
like
a
build
info
file
or
information
from
a
salsa
s-bomb,
we
want
to
say
for
like
open
source
code.
A
Okay,
this
is
how
it
was
claimed
to
have
been
built,
and
then
you
would
be
able
to
then
pull
that
information
out
of
guac
and
potentially
run
that
build
yourself
and
some
short-term
goals
for
us
or
short
to
medium
term.
Goals
for
us
are
one
is
we
want
to
do
a
and
sponsored
by
Google
a
public
service
for
querying
a
subset
of
Open
Source
packages,
so
the
idea
would
be
this
would
run
as
a
public
service
similar
to
something
like
a
Sig
store
and
you'd
be
able
we'd
ingest.
A
You
know
and
we're
not
taking
the
name
chips
we're
just
like
it's
cute
for
this
presentation,
but
we
we
have
a
little
set
of
little
utilities
and
Tool
plugins
that
we
plan
to
build
for
stuff
like
vs
code
and
plugins,
for
the
package
managers
that
can
then
be
used
to
then
query
guac
about
some
of
that
information
and
either
give
warnings
or
also
be
used
in
conjunction
with
policy,
to
say:
oh
wait.
We
actually
discovered
all
of
this
really
weird
information
inside
a
guac.
A
Maybe
you
don't
want
to
install
that
and
to
just
give
a
very,
very
quick
here's,
a
screenshot
of
something
that's
still
very
much
under
heavy
development,
but
it's
like
hey.
We
have
an
s-bomb
and
in
that
s-bomb
we
can
actually
go
in
it
parses
that
s-bomb
and
then
you
can
click
in
and
it'll
automatically
query
into
guac
for
additional
information,
and
we
plan
to
do
the
same
for
stuff
like
requirements.txt
files,
Go
mod
files
and
so
on,
where
you'll
be
able
to
then
just
be
able
to
see.
Okay.
A
This
is
all
the
packages
we
discovered.
We
can
click
in
there.
We
can
go
and
then
look
at
all
the
stuff.
We
can
then
go
and
look
at.
You
know
if
there's
any
interesting
information,
if
there's
any
known
vulnerabilities,
if
it
matches
the
local
policy
and
finally
a
call
to
action
right
so
we're
on
GitHub,
you
know
github.com,
you
could
also
just
take
a
snapshot
of
the
QR
code.
A
A
C
E
A
D
So
thanks
for
this
talk,
I
was
just
wondering.
So
what
is
guac
actually
so
is
it
a
I
saw
it's
a
concept.
It's
a
schema.
It's
maybe
it's
it's
a
bunch
of
ingestion
tools
to
build
up
the
graph.
You
said
it's
pre-alpha
there
there's
plan
to
be
a
service
that
you
can
query.
So
what
what
is
guac?
Is
it
the
idea
of
using
a
graph
to
query
it?
Will
it
be
the
database
that
you
build
up
centrally?
So
what's
your
vision
for
this
yeah.
A
You
could
run
your
own
fulsio
if
you
wanted
to
and
whatever
you
could
run
your
own
guac,
and
we
sort
of
expect
that,
like
folks
who
you
know,
you're
not
going
to
be
ingesting
your
private,
you
know
software
into
the
public
walk
as
well
as
there
might
be
a
bunch
of
extra
data
that
you
want
to
pull
in,
that
the
public
service
might
not
be
ingesting,
and
so
that's
really
what
it
is.
And
then
it
would
be
essentially
just
the
apis
that
make
it
very
easy
to
both
ingest
documents
as
well
as
query.
It.
B
F
All
right,
so
this
is
a
really
interesting
talk
and
I
think
this
is
really
needed
in
this
space.
I
there's
a
couple
of
problems
that
you
have
when
you
have
things
that
have
sort
of
rich
schemas
and
description
types,
there's
the
advantage
of
having
a
schema
where
you
a
tool
like
walk,
understands
what
a
lot
of
the
s-bomb
metadata
means,
but
there's
also
a
problem
that
you
know
the
example
you
would.
F
You
pointed
out
with
the
shaw
hashes
think
of
a
slightly
different
example,
where
one
person
representing
shot
256
like
a
256,
shot,
hash,
writes
shot
to
another
person
right
shot,
256,
another
person
says
shot
2-256
bits.
Have
you
seen
or
heard
of
any
kind
of
normalization
of
schemas
in
this
space?
That
would
make
your
life
easier.
B
A
Yeah
and
I
believe
there's
some
effort
from
like
the
in
Toto
side
on,
what's
being
called
sort
of
a
predicate
dictionary
that
could
hopefully
help
out
with
a
little
bit
of
that,
but
a
lot
of
it
I
think
is
also.
A
lot
of
work
needs
to
be
done
in
the
community
space
to
help
sort
of
build
that
unified
data
model.
I
was
actually
in
a
conversation
yesterday
with
some
folks
from
Docker
who
were
saying
exactly
the
same
thing.
A
Is
that
hey
it's
great,
that
there's
all
these
specifications
all
these
schemas,
but
without
sort
of
having
some
way
to
help
standardize
the
data
model
a
little
bit?
Then
you
end
up
with
a
situation
where
it's
really
difficult
to
know,
even
when,
like
you
call
it
name
and
other
another
person
says
package
but
they're,
both
the
name
of
the
package
yeah,
it
becomes
a
mess.
I.
E
G
Hey
great
talk
thanks.
What
is
the
query
language,
either
now
or
or
in
the
future
plans
for
around
the
query
language,
and
then
also
is
that?
Is
it
something
that
can
be
like
scriptable
I'm,
imagining,
for
example,
having
a
job
in
a
CI
pipeline
that
is
going
to
use
API
calls
to
guac
and
and
make
make
decisions
based
on
that?
Is
that
something
that's
in
the
in
the
roadmap.
A
Yeah,
so
the
plan
is
probably
something
like
graphql
for
that
sort
of
front-facing
end
user
stuff.
We
do
plan
to
make
it
flexible,
especially
for
folks
who
are
running
it
internally,
right
as
a
public
service,
we'll
probably
have
to
restrict
what
type
of
queries
can
get
run,
because
we
don't
want
queries
that
are
just
so
enormous
that
that'll
kill
the
service,
but
I
think
for
for
that,
and
we
I
think
we
plan
to
make
it
flexible.
I
think
do
you
have
anything
I.
H
Hi,
thank
you
very
much
for
the
talk.
It's
a
I
I
agreed
much
needed.
Have
you
considered
using
ontologies,
or
you
know
things
like
shackle
the
shapes
language
to
kind
of
help
with
some
of
the
you
know,
instead
of
normalizing
to
one
schema
for
all
things,
kind
of
building
up
an
ontological
understanding
of
what
the
meaning
of
these
things
are
and
what
other
names
they
could
be
referred
to
by
it
seems
like
we
could
take
some
some
things
from
the
the
semantic
web
work.
That's
been
happening
over
the
last
good.
B
Long
while
so
I
can
take
a
little
bit
of
that
that
if
we
use
the
donologist
directly,
then
we'll
have
too
many
edges
between
nodes
and
that
would
overly
complicated
the
query
part
because
then
the
answer
in
the
queries
will
become
too
much
too
slower,
too
much
slower.
So
it's
better
to
encode
the
ontology
representation
inside
the
parser.
So
when
we
parse
a
document,
we
encode
addiction
information
like
this.
Are
this
shuttle
to
256
and
Chateau.
They
mean
the
same
thing,
so
we
are
always
connecting
them
to
the
same
metadata.
A
Yeah
and
I
think
also
a
big
challenge
that
that
we
are
looking
to
do,
which
is
part
of
that
sort
of
predicate
dictionary
as
well.
Some
of
the
other
things
is
we're
trying
to
also
figure
out
ways
to
make
sure
that
we
can
ingest
new
document
types
that
still
match
that
beta
model
even
like,
so
that
we
don't
have
to
recompile.