►
From YouTube: Secure your software supply chain using observability
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
Today,
on
our
webinar,
we're
going
to
be
talking
about
securing
your
software
supply
chain
using
observability
hot
new
topic,
so
we've
assembled
our
panel
of
experts
from
software
security
and
data
to
talk
about
observability
and
what
it
means
to
your
software
supply
chain.
So
when
we
talk
about
your
software
supply
chain,
we're
talking
about
all
the
steps
to
go
that
go
into
building
your
software,
all
your
third-party
dependencies,
your
open
source
data
and
we
and
there's
a
huge
amount
of
risk
involved
in
your
software
supply
chain.
Even
a
small
application
can
have
thousands
of
dependencies.
A
A
They
can
ask
hidden
questions
about
the
unknown
unknowns
hidden
in
your
data
and
what
we
want
to
know.
What
can
this
do
for
your
software
supply
chain?
Hopefully
it
can
help
us
secure
it.
So
today
we
want
to
hear
from
you.
We
want
to
hear
who
you
are
where
you're
coming
from?
What
kind
of
work
do
you
do?
Do
you
work
in
SRE
and
devops
and
software
development
to
let
us
know,
and
if
you
have
any
questions,
that's
pure
gold.
A
So
we
want
to
hear
all
that
if
you're
on
our
streaming
platform,
it's
really
obvious
what
you
do,
but
if
you're
on
Twitter
tweet
us,
if
you're
on
Facebook
YouTube
LinkedIn
comment
in
our
stream,
so
we're
going
to
be
conducting
posts.
A
few
posts
write
this
and
so
again
for
for
Twitter
tweetos
for
the
other
platforms,
just
comment
in
the
Stream,
so
our
moderate
today
Hillary
is
going
to
be
giving
those
questions
back
to
me.
So
we
really
want
to
hear
it
from
you.
A
We're
also
going
to
be
randomly
drawing
a
few
prizes,
there's
two
prize
packs
and
two
free
lunches
at
the
end
of
this
webinar.
So
stay
till
the
end.
If
you
can-
and
if
you
want
to
watch
this
on
demand,
you
can
go
to
casewoods.com
forward,
slash
blog
after
this
now.
So
let's
bring
up
our
our
three
guests.
This
is
who
we,
this
is
what
it's
all
about.
A
A
Hey
this
is
our
crack
team.
We
have
Claire
Byrne
from
the
data
World
she's
our
data
magic
practitioner,
she's,
a
software
security
she's,
a
security
data
engineer
from
elastic
working
in
Belfast,
which
is
also
a
community
organizer
and
collaborator
in
the
tech
industry,
she's,
the
founder
of
women,
Tech
women,
Tech
Bakers
Belfast,
and
the
co-organizer
of
security.
Besides
Belfast,
then
we
have
Tom
Gibson
our
senior
staff
engineer
from
cloud
Smith.
If
you
hear
his
dog
snoring
in
the
background,
don't
worry,
it's
actually
I
think
he's
wearing
his
earpods
his
airpods
today.
A
So
I'm
sad
to
see
you
and
then
last
but
not
least,
we
have
Josh
Brazzers
he's
the
VP
of
security
from
anchor
he's,
also
a
blogger
and
a
podcaster
from
open
source
security.
Podcast
and
he's
someone
who's
been
talking
about
your
software
supply
chain
before
it
was
cool.
So
thanks
everybody
for
joining
us.
We're
really
happy
to
have
you
guys
today
to
tell
us
about
what
you
think
of
observability
and
your
software
Supply
I
I,
actually.
A
So
if
anybody's
wondering
yes,
yes,
that
is
something
snoring.
Hopefully
it's
not
like
a
gas
story.
So
it's
so
you
know
it's
a
circle
so
before
we
let's
start
with
getting
some
feedback
from
our
people
listening
we
want
to.
If
you
can
participate
in
the
poll
and
again,
if
you're
on
Twitter,
you
tweet,
if
you're
on
LinkedIn,
if
you're
on
YouTube
or
Facebook,
you
just
comment
in
the
Stream,
so
our
first
polling
question
is:
are
you
currently
using
observability
or
monitorial?
And
if
so,
how?
Many?
A
Because
we
did
hear
that
people
are
using
like
a
good
few
monitoring
tools?
So,
yes,
we'll
we'll
get
that
from
you
and
we'll
talk
about
that
later.
So,
let's,
let's
crack
on
with
our
with
our
first
question,
so
I
thought
I'd
put
the
first
question
to
Claire.
So
I
want
to
know
like
what
is
observability
and
how
is
it
like
different
to
those
traditional
data
monitoring
tools.
C
Yeah,
so
observability
is
more
or
less
defined
as
being
able
to
judge
the
state
of
the
system
based
on
its
outputs
and
again,
our
actionable
insights
into
the
state
of
your
tools
like
root
cause
analysis
of
issues
and
context
into
why
your
software
is
behaving
like
it
is
so
for
most
observability
use
cases,
three
types
of
data
matter,
the
most
logs
metrics
and
traces,
because
these
can
provide
a
sort
of
holistic
picture
of
your
your
organization's
resources.
C
So
yeah,
as
most
of
you
already
know
like
logs
or
files,
that
record
events,
contextual
information
and
such
as
the
time
and
event
occurred
and
everything
so
they're.
An
excellent
source
of
visibility
and
metrics
are
like
quantifiable
measurements
that
reflect
the
health
and
performance
of
your
applications
and
infrastructure.
C
And
so,
for
example,
CPU
or
members
resources
and
traces
are
like
is:
is
data
that
tracks
an
application
request
as
it
flows
through
the
various
parts
of
an
application
so
like,
for
example,
recording
how
long
it
takes
each
application
component
to
process
or
request
and
pass
the
result
to
next
next
component.
A
Yeah
and
Tom,
like
software
Developers,
traditionally
use
these
kind
of
two
like
they're,
already
using
observability
tools,
I'm
sure
we
are
in
Cloud,
Smith
and
they're
kind
of
more
used
for
like
checking
if
you're,
available
and
sort
of
performance
issues
is.
That
is
that,
right,
it's
like
that's.
What's
the
the
main.
B
Yeah
I
think
it's
certainly
an
element
of
it,
like
certainly
our
own
internal
use
case,
as
is
the
case
with
many
many
other
organizations.
We,
we
rely
heavily
on
observability
platforms
to
help
indicate
to
us
the
health
of
the
service
and
use
it
almost
as
a
pointer
as
a
point
of
reference
when
it
comes
to
diagnosing
issues
trying
to
understand
the
performance
of
the
applications,
and
you
know
some
of
the
points
that
Claire
touched
on
and
mentioned
about
the
pillars
and
triuses
being
one
of
them.
That's
probably
our
bread
and
butter.
B
Aside
from
the
log
side
of
things
and
and
all
that
you
know
they,
they
the
influence,
our
our
approach
to
trying
to
understand
how
things
are
going
heavily
and
we
heavily
try
and
instrument
all
parts
of
the
service
and
leverage
distributaries
and
across
the
board,
where
we
can.
It
makes
makes
a
big
difference.
A
Yeah
like
and
if
you're
currently
like
tailing
logs
to
get
this
information
very
sad
like
is
it
hard
to
get
started
like
you
have
to
change
your
data
to
when
you're
when
it's
being
consumed
by
these
tools?
Or
do
you
have
to
tag
everything
what
you
have
to
do.
C
So
in
general,
you'll
want
to
you'll
want
to
send
your
logs
to
your
observability
tool,
but
in
general
it
will
perform
the
heavy
lifting
for
you.
It
can
like
Aggregate
and
filter
and
organize
your
gloves
or
whatever,
based
on
a
schema
that
you
define
so,
for
example,
in
elastic
there's
elastic
common
schema,
which
you
can
you
can
like.
Orchestrate
yourself.
A
Oh
cool,
so
you
can
set
up
your
own
schema
like
if
you
don't
need
to
change
how
you're
currently
logging
stuff
like
yeah
cool
okay.
So
now
what
about
in?
Oh,
we
have
some
results
back
so
about
how
many
tools
are
you
actually
using
for
observability?
So
most
people
are
using
an
observability
on
one
or
two.
So
that's
that's
pretty
good,
but
some
people
are
using
over
five
observability
shows.
That
seems
like
a
lot.
That's
a.
C
A
D
D
Everything
they're
doing
it's,
it's
a
fantastic
company
and
product,
but
when
we
think
about
observability
there's
often
this
kind
of
focus
on
logs
and
logs
are
super
important,
I'm,
not
going
to
say
they're,
not
and
obviously,
if
you
look
at
the
history
of
nearly
every
modern
observability
tool,
it
has
its
roots
in
logging,
but
we
also
realized
some
time
ago
that
we
can
start
ingesting
all
this
extra
data
you
can
bring
in
observability
data.
You
can
bring
in
things
like
data
from
your
sim.
Your
security
security
incident
event
monitor
I
forget
what
some
stands
for.
D
A
D
I
mean
okay,
it
is
easy
to
say
that,
but
I
don't
think
that
is
necessarily
how
this
has
worked
out
over
time.
If
we
look
at
I'll
pick
on
log
for
J
right,
because
that's
all
we
all
remember
log
for
J
like
it
was
yesterday
and
we
have
this
incident
and
then
everyone
says:
how
can
we,
how
do
we
know
we're
logged
for
James?
D
Why
didn't
we
know
this
before
and
that's
very
easy
to
kind
of
pick
on
and
say
we
should
have
known
this,
but
the
reality
is
I
mean
it's
just
part
of
maturing
every
organization
I
mean
there
was
a
time
we
didn't
have
logs
from
all
of
our
computers
right
all
of
the
servers
in
the
server
room.
No
one
knows
whatever
does
sshn
and
log
file.
It's
fine.
I
was
just
configured.
D
Exactly
exactly
that
and
that
doesn't
cut
it
anymore
right
and
that's
fine.
That
is
just
how
all
of
this
works
together
and
so
I
think
from
the
supply
chain
perspective.
It
is
relatively
new
and
we
have
a
lot
of
learning
to
do,
and
I
just
think
putting
all
these
pieces
together
is
is
the
next
step
where
don't
say
why
weren't
we
doing
this,
because
what
well
we
just
weren't
so
who
cares
like?
How
do
we
start
I
think
is
the
better
question
to
start
asking.
A
Yeah
and
so
Tom,
what
kind
of
data
should
we
start
federating
in
order
to
answer
some
of
these
questions,
yeah.
B
That's
a
good
question:
there's
there's
a
lot
there's
a
lot
of
work
in
this
space
right,
I
think
what
Joshua
said
is
very
much
the
case.
It's
a
it's
a
novel
area.
You
know
prompted
heavily
by
you,
know,
incidents
of
such
as
log
for
J
such
as
as
well
the
numerable
things
right,
but
we're
starting
to
to
try
and
take
a
an
understanding
of
what
goes
into
a
piece
of
software
and
and
what
that
actually
means
for
us.
So
today
you
know,
there's
there's
a
variety
of
ways.
B
We
can
do
that
that
some
of
our
audience
will
have
heard.
That's
our
Mass
bomb,
I'm
sure
Josh
knows
it
inside
and
out.
But
that's
you
know
s
bomb
is
a
is
a
really.
You
know
it's
a
good
starting
point
for
some
of
this
stuff
because
it
like
like
to
to
take
it
back
a
little
bit
we're
talking
about
a
bill
of
materials
for
software.
So
essentially
you
know
the
manufacturing
industry
and
I've
used
this
on
several
webinars
and
I
saw
apologies
for
anyone
else.
B
That's
seen
this,
but
you
know
the
manufacturing
industry
has
has
used
bills
of
materials
for
a
very
long
time.
You
know.
Yet
there
has
to
be
an
awareness
and
an
understanding
of
what
goes
in
to
build
a
product
manufacture
of
a
mobile
device.
For
example,
they
they
understand.
It's
made
up
of
a
of
a
display
of
some
sort
components
that
make
up
the
main
board
a
speaker
that
kind
of
thing
and
they'll
Source
those
components
from
external
and
some
of
them
still
build
in-house
software
is
no
different
in
that
respect.
B
We're
looking
at
pieces
of
software
that
can
be
sourced
from
the
public
domain
by
great
contributors
out
there,
as
well
as
other
organized
positions
and
the
wise.
That's
amazing.
It
also
brings
an
element
of
I,
wouldn't
necessarily
say
distrust,
but
certainly
deserving
of
a
bit
more
scrutiny
and
local
J
is
a
very
good
example
of
that.
You
know
it's
heavily
used
across
the
board
in
a
variety
of
different
projects
and
I
think
to
get
that
sort
of
information
into
your
observability
pipeline
bombs
are
a
really
good
place
to
start.
B
You've
got
information
in
there
containing
things
like
the
third
party
dependencies.
You
know
those
those
are
usually
referred,
using
identifiers
such
as
Pearl
or
swedes,
or
something
along
those
lines.
But
you
know:
there's
a
variety
of
other
other
approaches
as
well,
and
generally
kind
of
starting
at
the
source
is
probably
like.
They
talk
about
Chef
left
security
right,
you've
heard
it
many
many
times.
Many
of
us
have,
but
it's
true
in
the
sense
that
you
know
the
the
the
later.
B
Something
is
done
about
things
that
the
more
damage
that
it
tends
to
to
the
the
bigger
whack
that
it
tends
to
create
so
given
given
more
observability
into
this
stuff
from
the
outset
is
no
bad
thing,
and
you
know
we
can
such
information
vulnerabilities,
for
example,
about
about
third
party
dependencies,
the
number
of
third-party
dependencies.
This
is
all
information
that
tends
to
be
produced
by
these
future
reports
and
they
make
great
candidates
for
injecting
into
observability
and
you're.
Treating
like
anything
else
that
goes
into
those
platforms.
B
We
can
model
slo's
or
sorry
slis
about
those
we
can
track
things
on
alerts
and
alarms.
We
can
do
license
compliance
checking
all
this
kind
of
useful
stuff.
That's
very
useful
for
security
teams,
but
I
think
in
general
we're
starting
to
see
an
approach
that
security
doesn't
just
rest
with
security
teams,
we're
starting
to
see
it
that
it's
becoming
a
practice
across
both
security
data
and
Engineering
teams
as
well
and
disciplines
and
I,
think
that's
important
to
continue
practice.
A
D
I
think
there
is
I
think
we've
seen
a
definite
shift
over
the
last,
probably
10
to
20
years
of
it
used
to
be
very
much.
The
security
team
was
over
here.
The
developers
over
here
Dolan
likes
each
other,
and
so
we're
going
to
avoid
one
another
as
much
as
possible
and
and
that's
definitely
not
what
I
see
anymore
but
I.
D
Think,
more
importantly,
even
is
when
you
look
at
some
of
the
kind
of
smaller
and
and
new
startupy
type
organizations
that
might
have
only
a
dozen
people
you're,
seeing
the
developers
kind
of
doing
a
lot
of
this
leg
work
where
they're
they're,
you
know
running
the
vulnerability
scans
themselves
or
using
github's
dependabot,
for
example,
they're
they're,
the
ones
doing
the
work
and
I
think
what
I.
What
the
vision
I
have
is
that
we
make
a
lot
of
this
tooling
so
easy
and
so
good
that
you
don't
need
a
security
team
like
doing
all
the
work.
D
The
security
team
is
there
to
Define
policy
and
help
with
problems,
but
fundamentally
you're
going
to
see
the
developers
actually
kind
of
picking
this
up
and
I
mean
I'd.
Even
kick
this
over
to
elastic
is
this
is
exactly
what
you're,
seeing
with
with
just
the
amazing
product.
That'll
last
you
search
is
morphed
into.
C
Yeah,
it's
funny
because
you,
you
said
that
we
have
guests
here
from
the
data,
the
security
and
the
engineering
world,
I'm
all
free.
C
Problems
on
a
daily
basis
and
that
kind
of
reflects
that's
what
an
individual
basis
it
reflects
where
the
organization
of
elastic
is
going,
because
we
have
both
security
and
observability
tools
in
the
one
product
line,
and
it's
really
cool,
because
security
like
monitoring
security,
means
monitoring
your
data
nowadays,
because
there's
just
so
much
data
everywhere.
A
Absolutely
and
actually,
let's
start
our
next
poll
as
soon
as
we're
we've
kind
of
touched
on
vulnerabilities
I,
don't
know
my
trusty
sidekick
there
Hillary
in
the
background
there
you
see,
that's
it's
magic,
so
our
next
poll
is
on.
Are
you
happy
with
your
workflow
for
finding
vulnerabilities
in
your
software
supply
chain?
A
A
What
kind
of
questions
do
you
think
that
we'll
be
able
to
ask
and
observe
I'm
like
I,
see
an
observability
deal,
I
kind
of
think
it's
like
Alexa
be
like
am
I
vulnerable,
Alex
I,
don't
know
if
that
that's
my
dream
so
but
Clara
can
you
imagine
like
say
you
get
all
this
data
in
this
new
vulnerability.
Pops
up
are
these
kind
of
these
questions
that
you
can
ask
your
vulnerability
tool
that
were
not
necessarily
thought
of
as
you're
generating
the
data.
C
C
Yeah
exactly
but
one
cool
thing
is
that
you
can
ingest
security
data,
but
then
like
have
have
that
all
correlated
within
the
observability
product
so
like
it
can
tell
you
like
it
can
pinpoint
Glenn
exactly
a
vulnerability
like
was
introduced
into
your
into
your
security
into
your
supply
chain.
C
It
can
tell
you
like
if
that
vulnerability
was
exploited,
and
it
can
tell
you
like
who
exploited
it.
If
you
have
your
your
logging
and
observability
set
up
right,
but
it's
just
it's
really
cool
and
I
really
love
the
book.
I
really
love
where
observability
Tools
in
general
are
going
on
this
front,
because
I
think
it's
presenting
a
unified
way
of
like
just
collating
all
your
data
to
provide
a
defense,
basically
yeah.
A
And
do
you
find
in
elastic
that
you're
moving
away
from
the
sort
of
what
is
it
the
visualize,
not
not
moving
away
from
visualization,
but
these
dashboards?
Is
it
more
about
like
remediation
and
automation,
I,
suppose
something
actionable
rather
than
displaying
on
a
dashboard
and
have
someone
monitor
that?
How
like
is,
is
that
where
you
see
the
future
to
be
or.
C
Yes,
absolutely
so,
for
example,
in
elastic
security,
you
can
open
cases
and
like
Chris,
where
vulnerability
is
happening,
like
I
said
when
you
know
like
Vlog
like
data
as
you
find
it,
so
you
can
basically
set
up
a
security
remediation
case
like
as
you
as
you
find
it.
You
know.
C
And
it
means
that
analysts
don't
have
to
you,
know,
stare
at
dashboards
all
day
and
you
know
get
alerts
and
everything
so
that
kind
of
automation
is
really
really
useful
just
and
helps
to
provide
a
layered,
a
layer,
defense
model,
I
guess.
A
Yes,
yeah
so
and
Josh
do
you
think
like
in
the
future,
using
these
options,
observability
tools
that
would
actually
be
able
to
like
prevent
a
supply
chain
attack,
so
supply
chain
attack
is
something
that
it's
an
attack
on
your
supply
chain.
So
maybe
it's
malware
in
your
dependency
or
it's
a
vulnerability,
that's
exploitable!
So
do
you
think
that,
using
these
tools
having
this
visibility,
having
these
sort
of
like
machine
learning
tools,
could
they
prevent
an
attack
or
is
it
all
about
detection
and
fixing
it
as
quickly
as
possible.
D
So
I
would
answer
your
question
with.
It
depends,
which
is,
of
course,
the
favorite
answer
to
all
questions.
So
I
don't
see
a
lot
of
observability
tools
directly
stopping
an
attack
in
the
regards
you
might
think
of
where
an
attacker
is
actually
like
coming
in
and
doing
a
thing,
and
then
you
have
a
tool
paying
attention,
because
prevention
in
that
regard
is
actually
very,
very
difficult
to
do.
I'm
not
going
to
say
it's
impossible,
but
it
is
incredibly
hard,
but
I
would
say
from
the
concept
of
preventing
a
bad
thing.
D
D
Essentially,
and
then
I
mean
you
could
is
that
stopping
it
I
mean
we
could
argue
that
probably
for
hours,
but
there's
I
think
that
aspect
of
it
and
then
there's
also
the
angle
of,
for
example,
you
might
have
a
developer,
who
includes
a
dependency
that
then
pulls
in
hundreds
of
other
dependencies
beneath
it,
and
so
you
can
look
at
your
tools
and
say
whoa.
Why
did
did
we
just
pick
up
700
dependencies
yesterday?
A
D
I
I
think
everyone
I
know
as
soon
as
they
start
generating
s-bombs
and
they
look
at
the
data.
The
first
thing
they
say
is:
where
did
all
this
stuff
come
from
every
single
person
and
then
obviously,
but
again,
once
you
have
data,
you
can
start
asking
intelligent
questions
and
solving
problems,
which
is
why
data
is
Magic
and
it's
amazing.
A
D
A
You
yeah
so
that's
great,
and
so
it's
like
it's
like
five
minutes
to
go.
I
thought
that
time
absolutely
flew
by
I'm,
just
gonna
check.
If
we
have
our
oh
can
I
just
say
my
favorite
comment
was
he
from
Jason.
You
need
observability
to
observe
the
output
of
your
observability
skills,
which
is.
A
There's
that
it's
just
Turtles
all
the
way
down
so,
let's
see
Hillary,
can
we
get
a
winner
of
a
prize?
Is
that
it
is
that
it?
Oh,
oh
it's
coming
in
okay,
so
we
have
free
lunches
for
Judah,
Davis
and
Vinnie
mashion
I'm.
So
sorry,
if
I'm
messing
that
up
and
prize
packs
for
Mike
amea
and
Chrissy
Sutton-
oh
that's
so
nice,
so
that's
brilliant,
I,
I
hope
you
enjoy
your
free
lunch
and
your
prize
pack.
Apparently
the
price
pack
has
the
plasma
socks
which
are
much
coveted
in
in
that
Clay
Smith.
A
So
and
that's
pretty
cool.
So
thank
you
to
our
guests.
Today,
we
I,
like
loved
chatting
to
you
I,
could
talk
to
you
all
day.
Long
really
appreciate
you
to
come
in
for
all
your
insights
and
everything
and
I'd
just
like
to
say
thanks
to
everybody
for
for
listening
about
observability
I
hope
you
had
an
idea
about
how
you
can
use
observability
to
secure
your
supply
chain
and
learn
new
things
about
your
supply
chain
that
maybe
you
didn't
know
that
you
had
to
ask
when
you
collected
all
this
data.
A
So
thanks
so
much
and
thanks
for
everybody
for
for
coming
in,
listen
to
us
so
next
month,
we're
talking
about
oh
we're
if
we're
talking
to
new
clients
from
Red
Hat,
so
stay
tuned,
but
thanks
again,
so
this
is
a
proper
goodbye.
Now
so
bye
everybody
talk
to
you
later.