►
From YouTube: DevSecOps is the Way (S1E1): Vulnerability Scanning Certification and real world impacts
Description
In this monthly series, learn how Red Hat weaves together DevOps and Security to master the force called DevSecOps. This show brings you Red Hat products and our security ecosystem partners to aid in your journey. March is Vulnerability month! In this episode, learn about Red Hat Product Security, a new Red Hat certification called Vulnerability Scanner Certification, and how vulnerability scanning impacts real world customers from both Red Hat and IBM’s X-Force Red’s experts. Bring your lightsaber and be prepared to train hard... may the DevSecOps be with you!
A
Good
morning,
good
afternoon,
good
evening,
wherever
you're
healing
from
welcome
to
the
series
premiere
of
devsecops
is
the
way
this
is
going
to
be.
An
awesome
show
the
one
that
I
will
thoroughly
enjoy,
producing
and
hosting
on
a
I
think,
monthly
basis.
Dave.
Do
you
want
to
take
it
over
and
maybe
explain
the
whole
program?
How
you
got
everything
set
up
right
now.
B
Yeah
yeah
thanks
chris,
so
devsecops
is
the
way
it
is.
You
said:
I'm
used
to
hearing
that
every
friday
night
in
the
fall,
but
we're
really
excited
to
bring
security
to
openshift
tv
every
month,
every
monthly
cadence
we've
actually
organized
a
bit
of
activities
around
a
monthly
cadence
of
security,
information
from
red
hat
and
and
our
ecosystem
partners.
B
So
I
get
the
pleasure
of
working
with
a
lot
of
great
partners
and
understanding
the
security
landscape
and
being
able
to
build
out
a
point
of
view
with
with
some
of
my
colleagues
at
red
hat
around
devsecops.
So
we
decided
to
have
this
monthly
new
series.
Devsec
ops
is
the
way
to
showcase
a
certain
security
topic
every
month.
B
B
So
you
can
see
here.
We
have
a
monthly
cadence
starting
this
month
in
march,
all
the
way
till
december,
with
different
topics
and
oh
by
the
way,
those
different
topics
are
specific
categories
that
we
have
worked
with
the
industry
and
with
our
partners
to
form
a
taxonomy
around
devsecops
and
the
security
methods
and
functions
that
you
would
need
to
think
about
when
you're
implementing
dead
secops.
B
So
every
month
you
can
see
that
topic.
If
you
want
more
information,
you
can
see,
on
the
left
hand,
side
there,
there's
a
url,
a
shortened
red
hat,
url,
red
dot,
ht,
devsec,
ops
and
by
the
way,
the
d
and
the
s
and
the
o
do
need
to
be
capitalized.
Don't
ask
me
why?
But
if
they're
not
capitalized,
you'll
get
a
404.
B
B
A
B
C
B
D
Absolutely
hi,
I'm
steve
osepic.
I
am
the
cto
for
ibm's
x-force,
red
team
and
our
our
job
we're
the
offensive
security
team
within
within
ibm,
and
we
work
with
our
clients
to
figure
out
how
attackers
get
in
so
have
a
lot
of
good
perspective
from
the
field
in
terms
of
these
container
vulnerabilities
we'll
be
talking
about.
A
B
To
yeah
jeremy,
to
start,
what
we
wanted
to
do
was
just
give
you
all
an
introduction
into
how
red
hat
handles
security
and
and
I'll.
Let
jeremy
do
that
and
then
we'll
talk
about
our
new
certification
program
and
steve
will
provide
a
lot
of
great
insights
around
real
world.
You
know
customer
situations
around
around
vulnerability
scanning
and
his
security
practices.
B
C
B
C
So
this
is
a
nice
little
graphic.
We
just
recently
put
together
to
better
describe
how
we
do
vulnerability
assessment
internally
here
at
red
hat,
we
have
a
process,
a
fairly
complex
process
of
identifying
vulnerabilities
out
in
the
market.
We
watch
mailing
lists
upstream
channels,
various
feeds.
We
pull
that
in.
We
create
tasks
to
take
a
look
at
those.
We
do
some
initial
triage
on
those
on
those
initial
tasks
to
determine.
You
know
if
the
vulnerability
actually
aligns
to
our
portfolio,
based
on
our
manifests
right
for
products
that
we
ship
and
build.
C
Our
analysts
then
do
some
some
verification,
along
with
engineering
and
kind
of
move
into
this
triage
and
coordination
phase.
I'm
gonna
pause
here
for
a
second
and
highlight
like
one
of
the
differences
between
how
red
hat
operates
and
how
maybe
some
other
companies
operate.
Product
security
for
us
is
a
kind
of
a
hybrid
process.
It's
not
a
we're,
not
a
standalone
product
security
team
here
at
red
hat.
That
does
everything
from
start
to
finish.
It's
a
company-wide
effort
with
within
our
research
and
development
department.
Right.
C
So
when
we're
doing
this
triage,
we
we
work
very
closely
with
the
engineering
team
who
work
very
closely
with
upstream
as
well.
So
this
is
part
of
what
you
see
here
in
that
red
section
on
that
coordination.
We
want
to
validate
and
verify
what
we're
seeing
with
our
engineering
peers.
After
that
verification
is
done.
C
We
we
work
to
remediate
these
vulnerabilities,
so
this
includes
filing
bugs
and
trackers
for
for
every
product
that
is
potentially
affected
so
like
we
have
a
huge
portfolio
and-
and
it's
important
for
us
to
to
track-
you
know
these
vulnerabilities
across
the
entire
portfolio
and
not
just
look
at
just
a
single
product.
So
when
we
get
a
request
that
comes
in
that
says,
hey
we
think
this
particular
component
is
affected
or
this
particular
product
is
affected.
C
You
have
to
drill
back
down
to
the
to
the
low
level
component
and
figure
out
which
products
consume
that
particular
component
and
which
version
of
that
component
was.
It
was
shipped
with
that.
I
think
a
big
selling
point
behind
the
the
methodology.
The
way
that
red
hat
does
analysis
is
because
we
build
our
products,
and
this
is
a
key
point
right,
because
we
build
our
products
a
certain
way
and
we
can
figure
them
a
certain
way
and
we
ship
them
a
certain
way.
C
It's
not
always
black
and
white.
From
a
from
a
vulnerability
standpoint
to
say,
yeah
you're
definitely
affected.
You
know
the
same
way
that
a
researcher
may
have
discovered
it
right
in
the
way
that
it
was
reported
up
through
our
national
vulnerability
database.
Our
we
may
actually
compile
out
the
the
the
cut
the
questionable
code,
and,
if
that's
the
case,
then
you
know
that
that
particular
product
isn't
isn't
affected
by
that
vulnerability,
because
code
isn't
present.
C
We
feel
like
that's,
that's
a
more
accurate
process
and
that
is
helping
our
customers
better,
determine
their
risk
and
whether
they're
affected
the
last
thing
that
you'll
see
here
in
the
green
section.
We
do.
We
do
a
lot
from
a
recovery
standpoint.
Communicating
this
up.
This
back
out.
We've
recently
launched
security
bulletins
to
improve
the
level
of
communication
regarding
major
major
incidents.
C
We
we
have
a
lot
of
tracking.
You
know
to
make
sure
that
we
any
of
these
trackers
any
of
these
products
that
are
affected,
but
it
gets
all
rolled
up
into
under
our
cve
pages.
I
think
a
lot
of
people
out
there
are
probably
familiar
with
the
red
hat
cbe
pages.
It's
got
a
lot
of
companies
similar
to
red
hat,
do
the
same
thing
and
we
roll
that
data
up
into
that
cve
page
based
on
all
of
this
tracking
and
communication
efforts.
B
I
do
have
a
question
so
how
much
of
this
do
you
think
is
done
by
the
and
I
don't
want
to
sound
like
I'm
being
mean
to
to
them,
but
the
national
vulnerability
database
right,
because
I
know
that
nvd
and
cvss
are
sometimes
seen
as
a
standard.
But
for
my
from
my
understanding
they
just
don't
have
the
resources
to
test
vulnerabilities
and
they
don't
have
the
products.
Obviously
that
we
own
to
know
if
they're
really
affected
or
not.
Is
that
accurate
statement.
C
Yeah
actually
a
couple
of
things
on
that
and
you
mentioned
quite
a
bit
there,
so
I'm
going
to
unpack
all
of
that.
First
of
all,
envy
the
nvd.
Don't
actually
do
the
vulnerability
assessment
themselves,
right,
they're,
they're,
a
storage
database,
a
communications,
a
coordination
kind
of
company
or
whatever
you
want
to
call
it
right.
C
So
it's
actually
independent
researchers,
companies
like
red
hat
across
the
world
that
that
submit
their
information
up
to
mpd
and
the
problem
with
this
is
that
you
take
a
piece
of
code
like
openssl,
for
instance,
and
it's
used
by
almost
every
software
vendor
out
there,
but
there
are
different
ways
to
exploit
that
code
based
off
of
how
that
software
vendor's
shipping,
the
code
or
configured
the
code
right.
So
the
problem,
the
fundamental
problem
with
a
single
score,
a
single
rating
out
there
in
mvd-
is
that
it
it's
it's
not
inclusive.
Of
of
those.
C
Many
temporal
characteristics
right.
So
I
think
that's
where
we,
where
we
run
into
some
challenges.
Sometimes
we
try
to
be
much
more
accurate
here,
red
hat
with
doing
our
analysis,
and
you
know
we
may
rate
something
as
like
a
moderate
issue,
because
we've
not
compiled
enough
that
bit
of
code.
Whereas
if
you
go
look
at
the
nvd
score,
it
may
be
rated
much
higher
and
you
know
from
the
flaw
perspective
itself.
That
might
be
true,
but
you
always
have
to
take
in
those
character.
You
know
those
temporal
characteristics
as
well.
C
The
other
thing
that
you
said
in
your
statement
and
then
I
promise
I'll
I'll
turn
it
back
over
to
you.
You
mentioned
standards
right,
so
this
is
a.
This
is
a
very
important
thing
for
us.
I
probably
same
thing
for
it's
true
for
steve
at
ibm
right.
We
leverage
oval
cvss,
cwe
cpe.
These
are
all
done
by
mitre
first.org.
C
D
No,
absolutely
I
mean
you're
bringing
up
a
really
good
point
about.
How
do
you
figure
out
the
attack
surface?
The
actual
you
know
the
way
that
the
packages
I
think
to
what
you
were
talking
about
are
by
default
configured.
Is
that
even
really
attack
surface
that
is
going
to
be
focused
on
you
know
by
the
attacker?
What
have
you
so
a
hundred
percent?
I
think
you
know
on
the
on
the
attack
side,
what
we're
always
trying
to
do
and
what
we,
what
we
use
intelligence
that
we
gather
to
do
in
x-force
red
is.
D
We
also
look
at
how
much
in
the
same
lines
and
what
you're
talking
about
cwe
and
these
others
capex.
You
know
another
minor
standard
and
minor
attack
and
we're
trying
to
you
know
we
we're.
We
have
intel
intelligence.
That
shows
us
how
much
attackers
are
weaponizing.
Those
exploits
and
and
to
those
exploits,
is
so
exactly
to
your
point,
when
you
have
a
whole
bunch
of
things
that
are
that
are
critical
or
coming
out
the
same
score
in
cvss.
What
do
you
focus
on
focusing
on
the
things
that
are
the
most
attacked
surface
right?
D
Absolutely
right
I
mean
that's
what
we've
really
built
a
lot
of
our
services
around
is
is
helping
clients
to
do
that
and
what
we
always
advise,
regardless
of
if
we're
working
with
them
in
this
capacity
is,
is
to
be
is
to
take
into
account
that
context
that
jeremy
was
talking
about
there's
what
they
call
the
temporal
factors
that
feed
into
cvss,
but
also
just
are
these
vulnerabilities
really
being
targeted?
Are
you
hearing
about
them?
D
D
Clients
still
have
that,
that's
that's
from
several
years
ago.
It
is
absolutely
the
thing
that
will
get
targeted
by
attackers
if
it's
there
and
so
ensuring
that
you're
not
just
always
chasing
the
the
newest
shiny
one,
but
focusing
on
vulnerabilities
that
you
that
we
know
are
being
heavily
targeted
by
attackers
in
the
past
and
really
you
know,
honing
in
on
those.
D
C
On
the
on
the
severity
ratings
themselves,
and
I'm
curious
to
kind
of
get
steve's
thought
on
this
as
well,
one
of
the
things
we've
noticed
was
that
the
industry
seems
to
have
kind
of
over
the
years
kind
of
incorrectly
started
using
those
those
severity
ratings
to
kind
of
gauge
risk
right.
When
really
like
our
position
on
it
is
that
it's
supposed
to
prescribe
some
kind
of
order
for
remediation
right,
absolute
prioritization,.
D
It's
it's
a
great
point
and
cvss
honestly
is
a
good
metric.
If
it's
used
right,
it's
a
it's,
it
is.
It
is
lingua,
franc,
franco
of
of
of
our
space.
However,
to
your
point,
it's
being
used
to
measure
risk
when
really,
as
had
a
number
of
cves,
that
I've
written
myself
and
vulnerabilities
I've
discovered
and
when
you
you
go
out
and
you
use
that
cvss
calculator,
everything
that
you're
doing
when
you
create
that
cvss
score
is
the
worst
case
scenario
you're,
not
measuring
how
much
time
it
takes
to
make
a
to
make
an
exploit.
D
And
frankly,
you
can
kind
of
shoot
yourself
in
the
foot
as
a
researcher
with
the
calculator,
because
when
it
gets
to
that
point,
it
says,
attack
complexity,
it's
very
easy
to
sort
of
pop
your
collar
and
say:
oh,
it
was
very,
very
complex.
It
was
very,
very
hard
for
me
to
break
into
this.
You
know
no
mortal
could
just
do
this
like
I'm,
I'm
the
one,
I'm
the
only
person
that
can
do
this
so
you're
going
to
set
the
attack
of
legacy
really
high,
which
is
going
to
bring
that
value
down,
but
think
about
this.
D
D
That's
the
piece
that
is
one
of
the
biggest
troubles
we
have
is,
if
you're,
just
using
cvss,
imagine
you're
taking
cvss
10s
that
were
privately
reported,
that
don't
have
any
public
exploit
code
and
saying
that
those
are
more
important
than
something
like
ms17010,
which
is
you
know.
It
has
has
a
very
high
complexity
of
attack,
not
that
hard,
if
you're
downloading
the
the
scripts
to
to
break
in
right,
which
of
course
all
attackers
are
doing.
B
And
I
would
say
I'm
glad
you
mentioned
the
calculator.
I
was
going
to
mention
that
as
well.
It's
right
there
on
the
on
the
nvd
site,
so
they
know
that
their
scoring
is
not
really,
you
know,
is
not
potentially
risk
for
you.
It's
it's
a
guideline
right.
It's
a
it's
a
recommendation
to
prioritize
and
then
you
know
add
in
your
own
environmental
and
temporal
metrics
to
figure
out
if
you're
really
exposed.
E
D
Frankly,
I
think
it
was
created
originally
to
take
from
the
researcher
and
give
to
the
vendor.
I
think
that's
what
his
primary
purpose
is
and
then,
as
you
know,
there's
that
little
bit
of
negotiation
that
happens
in
terms
of
how
how
high
is
this,
really
you
know
how
high
score
is
it
and,
of
course,
the
researcher's
always
going
to
think
it's
a
10
and
the
vendor's
always
going
to
think
it's
a
3.,
that's
somewhere
somewhere
in
the
middle,
you
figure,
it
figure
it
out
right,
yeah,.
B
C
Well,
I
think
you
know
first
thing
I'd
say
there
is
we
don't
have
a
different
scoring
system
so
to
speak
right.
We
need
the
same
low,
moderate,
high,
critical
that
that
the
industry
uses,
but
we
do
score
things
based
on
the
temporal
characteristics
we've
talked
about
just
previously.
We
do
score
things
differently
than
what
a
researcher
might
have
scored
it.
Now,
some
of
the
things
that
we
recognize
that
you
know
your
customer
you're
looking
at
this
information,
it
gets
very
confusing
right.
C
Our
team
works
very
closely
whatever
we
feel
like
you
know:
we've
we've
res
if
we've
scored
something
differently
and
I'm
talking
about
scores
for
a
second,
not
the
rating
right,
but
if
we've
scored
something
differently,
then
we
have
a
whole
process
where
we
reach
back
out
the
nbd
and
we
submit
our
proposal
right
and-
and
there
are
just
our
reasons-
why
not
based
on
just
on
the
red
hat
specific,
you
know
portfolio,
but
just
from
a
flaw
perspective
standpoint.
We
try
to
do
those
rescores
to
help
those.
C
The
nvd
scores
become
a
little
bit
more
accurate
as
well,
but
you
know
rating
wise
that
that
that
severity
score
yeah,
sometimes
they're,
going
to
be
a
little
bit
low,
and
so
we
we
have
statement
text
in
our
cve
pages,
where
we
try
to
to
clarify
that
on
why
I
just
looked
at
one
the
other
day
it
was
like.
Oh
well,
you
know
this
is
why
right
we
don't
include
that
bit
of
code
and
we
feel,
like
that's,
useful
and
helpful.
B
Yeah
absolutely
yeah.
Of
course,
all
this
stuff
is
pretty
publicly
accessible,
even
sometimes
bugzilla
cases
right.
You
could
log
in
and
see
see
what
the
developers
are
talking
about
or
how
it's
being
affected
so
yeah.
I
usually
find
those
pretty
helpful
and
understanding.
You
know
the
root
cause
or
why
why
red
hat
determined?
B
C
So
there's
do
you
like?
Yes,
these
these
questions
that
are
kind
of
you
know
big
big
arm,
correction
questions.
So
I
think
the
first
thing
to
say
with
containers
is:
it
was
a
different
shift
in
the
in
the
the
industry
right
you,
you
used
to
like
a
kind
of
a
box
product,
and
you
know,
containers
represent
this
bit
of
like
static
code
that
you
pull
out
from.
C
You
know
somewhere
else
right
and
you
bundle
it
up
and
create
an
image
and
how
you
handle
security,
for
that
becomes
a
little
bit
different
and
we've
written
several
blogs.
I
know
my
manager
here,
red
hat,
has
written
several
blogs
out
there
for
the
red
hat
blogging
blog
space,
to
kind
of
explain
this
a
little
bit,
but
we
took
a
different
approach
with
our
container
registry
and
how
we
were
scoring
scoring.
Is
we
instead
of
looking
at
it
from
a
vulnerability
standpoint?
C
We
look
at
it
from
a
time
standpoint,
because
containers
consume
that
content
from
something
else
that
and
that
those
where,
where
the
source
of
on
where
it
pulls
that
content,
that's
where
that
vulnerability
technically
lives
right
and
it's
patched
there.
So,
for
instance,
if
we
take
a
look
at
our
universal
base
image
right,
so
our
ubi
image,
it
pulls
heavily
from
rel
right.
The
vulnerability
is
patched
in
rel.
The
the
rel
content
then
is
then
pulled
into
a
spin
right,
a
rebuild
of
that
ubi
image.
C
So
what
we're
trying
to
display
with
our
container
health
index
is
we're
trying
to
tell
customers
how
what
what's
the
risk
from
a
standpoint
of
are
there
unpatched
vulnerabilities
right?
So,
if
there's
a
vulnerability
that
we
know
was
fixed
in
rail,
but
it
wasn't
applied
to
that
container.
Yet
then
that's
the
concern,
and
specifically,
how
long
has
it
gone
right?
Because,
again
it's
it's
and
I
think
I
think
my
manager
and
his
blog
use.
This
quote.
C
I
really
like
this,
like
you
know
it
ages,
like
milk,
not
wine,
right
wine,
it
ages,
really
well
milk,
curdles
sours
right.
So
the
idea
with
containers
the
longer
they
sit
out
there,
the
more
sour
they
become,
the
more
vulnerable
they
become
and
so
we're
trying
to
to
represent
that
in
the
container
health
index.
C
So,
for
example,
a
container
I'm
sorry
a
grade
a
there
is
no
known,
critical
or
important
vulnerabilities
that
have
been
unpatched
in
that
container,
something
that's
grade:
b,
you're,
looking
at
like
a
37
to
30
day
time
span
and
we've
got
these
published
right.
So
I'm
going
to
repeat
all
of
them
right,
but
we've
got
grade
b,
c
d
e
and
the
whole
idea
is.
You
can
look
in
a
container.
That's
like
a
grade
e
or
a
grade
d.
There's
a
significant
amount
of
risk.
There.
B
Yeah,
I
think
I
think
that's
a
great
point
and
something
I
learned
a
while
ago
as
well-
is
that
the
container
health
index
is
not.
You
have
a
container
that
has
these
known
vulnerabilities,
but
you
have
a
container
that
has
these
known
villain
abilities
with
known
fixes
and
aren't
applied
yet
correct.
E
D
Absolutely
you
know
this
topic
today
is
very
important,
because
this
is
the
primary
issue
you
know
before
we've
had
you
have
that
that
situation
with
containers
right,
they're
sort
of
the
new,
almost
vm
images
in
a
way
not
really
because
they're
limited,
but
it's
the
same
concept
where
you
get
something
that
works.
You
know,
as
the
developer
will
all
been
there.
You
have
this
base
image,
you
really
like
you're
gonna.
You
know
it's
got
everything
you
need,
it
has
redis
or
what
have
you
on
it?
D
You
you
that
to
run
your
application
in
it
and
you're,
just
you
get
very
attached
to
that
image
because
you
know
it
works.
You
know
the
version
that
it's
at
all
the
underlying
pieces
are
together
and
it's
using
all
these
different
libraries
that
you
know
are
sort
of
working
together
and
that's
static.
It's
a
terrible
thing
that
we're
like
that,
because
it
it
causes
us
to
reuse
the
base
image
over
and
over
and
over
and
over
again
and
any
time
you're
doing.
We
do
work
with
clients
who
are
doing
container
scan
tools.
D
You
know
like
claire,
that
are
that
are
checking
how
you
know
what
vulnerabilities
lurk
in
some
of
these
containers
and
it's
it's
always
those
base
images.
It's
always
those
old
versions
of
libraries
that
if
you
were
running
a
rel
server-
and
you
were
just
keeping
it
up
to
date
as
you
would
they
would
get
fixed,
but
the
container
image
the
base
image.
D
D
Underneath,
let's
say
in
what
you
said
of
one
of
those
d
or
e
grade
containers,
you
might
be
responsible
for
doing
all
that
detangling.
If
you
want
to
keep
using
it-
and
you
fix
one
thing,
that's
in
the
base
image
and
then
all
of
a
sudden,
your
your
reader
server
doesn't
work
anymore,
and
you
have
to
figure
that
out
and
that's
what's
great
about
having
the
scoring
system,
because
you're
you're
really
sc
the
the
how
well
maintained
it
is
because
it's
an
ongoing
containers
are
a
moving
target.
They
have
to
be.
D
B
B
B
By
the
way,
this
is
a
legal
photo
that
I'm
using
it's
actually
of
my
one
of
my
daughters
and
her
mom
was
actually
pulling
her
hair
out,
which,
by
the
way,
is
what
our
customers
feel
like
when
they
scan
containers
and
they
see
a
huge
list
of
vulnerabilities
and
then
they
might
compare
that
to
red
hat
and
red
hat
says
no.
No,
the
container
is
good,
and
this
is
this
is
actually
it's
not
tied
to
one
scanner.
B
You
know
there
is
a
happy
ending
same
same
daughter,
but
much
happier
and
there's
a
happy
ending
that
we
now
have
a
certified
vulnerability:
scanner,
certification
that
we
launched
on
february
23rd,
which
was
about
a
six-month
effort
with
our
partners
to
get
set
up.
We
took
a
good
number
of
them
through
a
pilot
phase
in
order
to
understand
what
they
needed
and
what
we
needed.
B
You
know
the
amount
of
discrepancies
when
our
partners
are
scanning
red,
hat,
supported
data,
and
you
can
see
that
we
announced
the
certified
partners
there
on
the
23rd
aqua
new
vector
systig,
and
you
can
see
the
other
partners
right
now
that
we're
working
with
encore,
j,
frog,
palo
alto,
sneak
and
synopsis
that
are
working
towards
certification.
We've
got
about
20.
Other
partners
that
we
know
of
that
are
out
there,
but
if
you
are
a
partner
and
you're
interested,
please
feel
free
to
contact
us
and
we
can
help
you
through
this
certification.
B
D
D
You
know
these
technologies
and
what
causes
a
lot
of
the
work
in
terms
in
the
field
is
when
those
scanners
will
maybe
look
at
a
container
registry
without
the
maybe
because
they're
just
not
armed
with
the
context,
I
think
you're
providing
in
some
cases
to
have
maybe
we'll
spot
something.
That
is
a
maybe
a
problem,
but
it's
not
as
much
of
a
problem
because
of
the
specific
red
hat
release
train.
So
for
some
of
the
you
know
the
context
that
jeremy
was
providing
earlier.
D
Sometimes
these
vulnerabilities
are
patched
in
a
way
where
you're
keeping
the
same
version,
for
example,
of
the
vulnera
of
the
system
or
of
the
package
that
is
listed
as
vulnerable
in
nvd,
but
because
of
certain
considerations
in
the
way
the
configuration
you
know,
configuration
is
done,
doesn't
have
the
same
attack
profile.
It's
not
the
same
thing
right,
it's
been
either
it's
been
either
patched
by
red
hat,
or
it's
been
changed
in
some
way.
D
Everything
with
vulnerability
management
is
about
getting
rid
of
those
false
positives
and
focusing
in
on
the
things
that
are
actually
the
most
important
from
a
risk
perspective,
so
the
more
context
that
those
that
those
scanners
can
have
going
in
the
better
they're
going
to
build.
That
contrast
and
the
easier
it's
going
to
be
for
the
for
the
consumer
for
the
client
working
with
those
result
sets
and
in
turn
for
us
helping
them
to
remediate
those
vulnerabilities.
C
Yeah
dave
can
I
can.
I
say
one
thing
on
that
like
and
I
suspect,
steve
will
completely
agree.
I
hope
containers
are
complicated
from
the
standpoint
of
understanding
the
software
bill
of
manifest
right.
The
what's
in
it.
I
think
part
of
the
challenge
for
our
scanning
vendors
over
the
years
has
been
to
identify
what's
vulnerable
and
what's
not
and
and
well
you
know
back
in.
C
C
It's
older
right,
simple
math,
with
a
with
a
container
these
days,
especially
in
the
context
of
you
know,
red
hat
tries
to
provide
maintenance
for
for
product
versions,
for,
as
you
know,
as
long
as
we
can
for
for
a
customer
right,
which
means
that
we
end
up
back
porting
a
lot
of
patches
back
to
a
particular
mainline
branch
of
code
right.
We
have
a
lot
of
different
branches
out
there
that
we
maintain
and
when
you're
a
when
you're
a
scanning
vendor.
C
C
It
was
like
empowering
the
scanning
vendors
with
more
of
that
context
to
say:
okay,
we've
done
a
lot
of
the
heavy
work
for
you,
we're
gonna,
we're
gonna
help
you
figure
out
how
to
identify
what's
actually
in
in
that
container,
and
then
we're
going
to
give
you
that
context
in
this,
in
the
form
of
like
oval
files
right,
so
that
o
file
file
has
tests.
It
has
information
on
the
rhsas
that
fix
it.
What
the
status
is
for.
C
D
C
D
Yeah
100
agreed
especially
about
the
complexity,
because
you
have
those
you
know
you
containers
as
being
just
a
singular
thing.
You
have
to
realize
you
know,
when
you're
building
one
there's
a
big
interplay
between
the
base
images,
what
you're
starting
with
and
then
then
adding
things
onto
it.
It's
like
a
lot
for
building
blocks
to
your
point.
If
it's
not
aligned
with
your
rhsas
and
that's
what
a
lot
of
the
certification
is
about.
Obviously
it's
it's,
they
say
it's
just
not.
Gonna
have
the
right
context
and
and
you'll
spend
a
lot
of
time.
D
E
D
D
B
They
have
the
intelligence
and
that's
their
value
to
help.
You
understand
risk
vulnerabilities
in
your
applications
outside
of
red
hat
scope
right.
The
certification,
though,
will
definitely
help
to
minimize
a
lot
of
frustrations.
Just
on
the
base
image,
I
mean
you
could
have
hundreds
of
cdes
in
a
base
image
and
wouldn't
it
be
great
not
to
have
to
go
through
all
the
ones
that
are
critical
and
high
to
ensure
that
you
know
they're,
you're,
not
vulnerable,
so
well,
cool
and
so
jeremy.
You
mentioned
obao
red
hat.
B
C
C
C
B
The
main
the
main
requirement
is
to
consume
that
those
files,
and
then
we
actually
you
know,
used
claire
and
the
clarity
was
very
helpful
in
helping
us
formulate
sort
of
the
details
on
recommendations.
We
didn't
we're,
not
the
experts,
the
scanner
experts,
as
our
partners
are,
but
we
use
the
clear
code
as
a
reference
to
say:
hey.
How
can
you
parcel
val,
you
know
to
show
red
hat
data
to
show
the
appropriate
red
hat
data
we
were
requesting.
So,
of
course
claire
is
open
source
and
you
can
find
all
that
information.
B
C
I'll,
just
I'll
also
mention
as
well
like
it's
important
for
us
to
make
sure
that
we
continually
evolve
all
right,
so
we're
we've.
We
consider
all
of
these
scanning
vendors
partners
with
us
and
we
meet
regularly
with
them
to
talk
through
challenges
that
are
still
ongoing
in
terms
of
how
to
better
identify
the
content
right
or
if
there
are
new.
You
know
standards
so
to
speak,
that
we
should
be
taking
a
look
at
so
yeah.
We
continue
to
meet
with
all
these
leaders
on
a
regular
basis.
B
Yeah
and
and
I'm
in
a
partner
team
here
at
red
hat,
so
I
talk
to
them
on
a
weekly
basis,
but
yeah
you
have
that
working
group
which
is
really
great
as
well
well
cool
yeah,
so
I
mentioned
you
know
this
month
is
vulnerability.
Analysis
there'll
be
another
openshift
tv
session
in
a
couple
weeks
and
then
we'll
be
dropping
three
podcasts
as
well.
B
B
Underneath
those
categories
you
can
see
all
the
different
items
there
there's
34
different
security
methods,
and
so
we
were
able
to
take
those
methods
and
work
with
the
industry
work
with
our
partners
to
plot
those
against
a
devops
pipeline.
Like
you
see
here,
life
cycle
and
which
serves
as
a
basis
to
understand
and
to
start
communicating
and
help,
our
customers
consume
this
information
a
little
bit
better.
You
know,
for
example,
if
you're
starting
devsecops
or
if
you
have
it,
we
can
come
in
with
a
solution.
A
B
Yeah
I'll,
I
guess
I'll
just
leave
this
up
as
an
ending
slide
here
this
month
again
vulnerability
next
month,
compliance.
So
if
you're
interested,
maybe
you're
in
the
federal
space
or
you
know,
you
have
to
worry
about
cis
benchmarks
or
pci
we're
going
to
have
some
experts
join
us
to
talk
through
compliance
as
well,
and
then
you
know
we'll
go
through
the
year
with
these
different
different
categories.
B
A
A
Fantastic
all
right!
Well,
folks,
let
us
know
if
you
have
any
feedback
about
the
show,
what
you
think
you
can
always
reach
me.
Seashore
redhat.com
and
I
can
ferry
the
the
information
back
down
and
if
you
want
to
follow
or
ping
me
on
twitter,
just
at
chrisshort
on
twitter.
That's
for
anybody.
You
know
out
there
that
has
any
questions
and
wants
me
to
you
know,
get
some
information
for
you
always
available
for
that
purpose.
So,
thank
you,
everyone
for
watching.
We
really
appreciate
you.