►
Description
Cyber threats consistently rank as a high priority for data center operators and their reliability teams. As increasingly sophisticated attacks mount, the risk associated with a zero-day attack is significant. Traditional responses include perimeter monitoring and associated network defenses. Since those defenses are reactive to application issues attackers choose to exploit, it’s critical to have visibility into both what is in your container library, but also what the current state of vulnerability activity might be. Current vulnerability information for container images can readily be obtained by using the scan action on Atomic hosts in your OpenShift Container Platform.
In this session we’ll cover how an issue becomes a disclosed vulnerability, how to determine the risk associated with your container usage, and potential mitigation patterns you might choose to utilize to limit any potential scope of compromise.
For the latest information on OpenShift 3.2 and available briefings, please visit http://commons.openshift.org or subscribe to the OpenShift Blog (https://blog.openshift.com).
The OpenShift Commons exists to provide a platform for customers, partners, developers and other open source technology initiatives to collaborate, share and accelerate the pace of innovation and adoption of OpenShift globally.
The OpenShift Commons represents a new open collaborative community model designed to facilitate communication and sharing of best practices, feedback and development across the many open source initiatives that integrate with OpenShift. The best way to get involved is to join the conversation today at http://commons.openshift.org
A
A
Good
morning,
everybody
and
welcome
to
yet
another
open
ship
Commons.
Thank
you
all
for
joining
us
again.
We're
sort
of
back
on
my
weekly
track
one
a
week
and
we're
happy
today
to
have
black
duck
coming
in
and
talking
about
vulnerability
management
and
the
hows
and
whys
of
that,
and
just
how
to
deal
with
that
in
the
context
of
open
shift
and
really
just
to
give
us
some
background
on
the
whole
topic
as
well.
We
have
with
us
Tim
mcnac,
II,
okay,
thank.
A
Please
ask
your
questions
in
the
chat,
there's
a
number
of
other
folks
on
who
may
be
able
to
answer
them
and
if
there's
some
really
great
questions,
I
may
repeat
them
and
get
them
verbally
answered
for
the
recording
of
this
and
after
this
is
this
session,
is
done,
it'll
be
posted
as
per
usual
in
the
open
ship,
Commons
YouTube
channel
and
on
the
blog
for
OpenShift
itself,
a
blog
or
a
bishop
comm.
So
without
any
further
ado
Tim,
why
don't
you
introduce
yourself
and
the
topic
and
we'll
just
go
on
and
get
into
it?
Cool.
B
Thank
You
Diana,
so
today
what
we're
going
to
talk
about
is
the
how
and
why
of
container
vulnerability
management
and
a
little
bit
about
myself
and
who
I'm
all
about
my
current
role
here
at
Black
Duck
is
as
Senior
Technical
Evangelist
I
do
still
code.
Occasionally
my
current
favorite
languages
actually
go
for
the
last
ten
years.
I
was
part
of
the
Citrix
open-source
business
office
and
was
the
community
manager
within
that,
so
things
related
to
virtualization
and
cloud
and
container
management
and
relatively
large
scale.
B
B
Vulnerability
management
fundamentally,
is
a
as
a
connection
to
data
breach
management.
The
Verizon
data
breach
report
from
2016
was
quite
telling,
and
it's
fifty
something
pages
in
length.
Eighty-Nine
percent
of
the
data
breaches
that
they
had
within
their
infrastructure
they
were
customer
base,
has
some
form
of
financial
or
espionage
motive
behind
them.
This
was
very
much
a
case
of
people
trying
to
go
and
do
a
couple
of
distinct
things.
B
You've
seen
talk
about
ransomware,
you've,
seen
talk
about
credit
card
access,
you've
seen
talk
about
activities
that
are
all
about
what
I
can
be
with
personally
identifiable
information
and
that's
what
they
saw
a
significant
portion
of
it
on
the
espionage
side
of
things.
I
was
state-sponsored
actors
who
were
out
to
do
malice
on
people.
B
That's
also
corporate
entities
that
are
trying
to
go
and
find
out
what
the
next
big
thing
is
for
somebody
else
when
they
distilled
all
the
data
behind
that
one
of
the
things
that
they
found
out
was
that
the
vast
majority
of
the
costs
associated
with
doing
data
breach
management
fellin
did
the
legal
side
and
the
forensic
side.
So
the
legal
side
really
was
a
case
of
gee
whiz,
but
I
need
to
hire
a
bunch
of
lawyers
to
go
and
tell
me
how
bad
this
is
going
to
be.
B
For
me
from
a
reputational
perspective
from
data
management
perspective
from
up
you
name,
it
get
the
lawyers
involved
and
have
them
give
some
opinions
and
the
forensics
form
exactly
how
bad
was
this?
How
much
of
the
data
got
access,
whose
data?
How
did
they
get?
What
were
they
doing
and
those
were
the
things
that
really
did
dominate
the
remediation
expenses
associated
with
data
breach,
and
this
is
like
a
simple
distillation
of
that
massive
report.
I
encourage
everyone
to
go
and
read
it
in
detail.
It's
definitely
well
worth
the
read
now.
B
Now,
if
I
was
an
attacker
and
I
managed
to
gain
access
to
some
quantity
of
police
data,
I've
effectively
got
three
possible
scenarios
available
to
me
number
one
I
can
decide
that.
Maybe
it's
not
my
best
off
interest
to
kind
of
upset
the
law
enforcement
people
out
there.
They
might
come
after
me,
so
kind
of
back
out
no
harm
no
foul
make
like
it
never
happened.
B
Option
number
two
is
to
just
kind
of
stayed
the
course
and
go
for
whatever
it
was
that
I
had,
and
in
this
case
the
ransomware
locked
down
all
of
the
evidence,
information
for
the
various
cases
they
were
working
on
and
so
number
three
might
be
well.
I
want
more,
in
this
case
the
rents
where
people
weren't
that
sophisticated
they
decided
to
kind
of
stay
the
course
and
they
went
for
their
$500
and
the
police
department
ultimately
paid
up
and
then
started
to
go
on
a
promotional
campaign
to
say:
look
if
this
can
happen
to
us.
B
One
of
the
other
things
that
the
Verizon
data
breach
report
saw
an
SATs
reown
research
supports
is
that
a
very
large
percentage
of
all
of
the
cyber
attacks
themselves
are
actually
happening
on
the
application
layer.
It's
those
applications
that
are
deployed
that
are
valuable,
not
necessarily
all
of
the
stuff
in
the
middle.
B
And
so
these
models
don't
necessarily
track
with
what
the
attackers
are
thinking
about.
And
so
no
security
talk
would
ever
be
complete
without
the
requisite
bad
guy
in
a
hoodie.
So
here
he
is
meet.
Bob
bob
is
going
to
go
and
create
an
attack
and
here's
the
methodology
that
he
actually
goes
through
he's
going
to
be
a
rise
against
a
variety
of
potential
scenarios
that
might
gain
him
value
from
the
thing
that
he's
attacking
he's
going
to
test
it
against
a
variety
of
platforms.
B
B
It's
all
well
and
good
for
Bob
to
go
and
have
his
own
attack
a
model,
but
he
wants
to
be
known
for
more
than
just
his
own
buddies,
so
he's
going
to
create
a
deployment
package
so
that
everyone
can
go
and
use
it
and
that
the
Blauman
package
has
got
to
be
documented.
Well,
so
he's
going
to
create
a
few
YouTube
videos
that
are
going
to
give
full
documentation
on
exactly
how
to
go
about
using
this
and
well
the
last
piece
and
if
you
can
get
it
just
right.
B
It'll
come
up
with
some
model
for
promoting
this,
because
the
press
do
very
much
love
a
catchy
vulnerability
named
Reed
Hartley,
shellshock
and
company,
and
so
this
is
essentially
the
model
that
an
attack
goes
through
and
if
this
looks
an
awful
lot
like
a
software
organization,
developing
a
new
product.
Well,
it
kind
of
is
and
the
point
here
being
that
the
attackers
themselves
are
significantly
more
sophisticated
and
significantly
more
creative
than
the
attacks
we
might
have
seen
a
few
years
ago.
B
So
one
of
the
things
that,
if
we're
operating
data,
centers
we
need
to
really
care
about,
is
understanding
what
the
scope
of
compromised
might
be.
So,
on
the
left
hand,
slide
we
have
our
shiny,
happy
people
and
our
shiny,
happy
people
are
the
users
of
our
application
and,
like
every
good
data
center
operator,
we've
got
some
firewalls
in
place
to
make
certain
the
shiny,
happy
people
only
see
the
things
that
they're
supposed
to
see.
Now
those
might
be
basic
load
balancers.
Those
might
have
some
content
awareness.
B
Those
might
be
doing
a
lot
of
caching
and
compression
doing
all
kinds
of
other
fun
things,
but
they're
fundamentally
a
firewall
protection
device,
and
you
have
a
stack
of
servers
that
we're
going
to
deliver
our
applications
from
and
I've
highlighted,
one
of
those
servers
and
that
server
is
going
to
be
running
a
virtualized
environment.
So
it's
got
some
form
of
hypervisor.
B
We
want
to
deploy
some
containers
and
so
we're
going
to
do
that
within
container
vm
and
we're
going
to
choose
some
minimal
operating
system
like
red,
head
atomic
and
we're
going
to
have
our
various
containers
that
will
be
deployed
in
their
respective
pods
and
we're
going
to
replicate
this
across
their
hypervisor.
So
we
end
up
with
n
VMs.
B
Well,
the
interesting
thing
happens
if,
if
I'm
attacking
an
application,
I
have
figured
out
a
way
to
attack
that
application
inside
this
highly
protected
fire
walled
off
Network
secured
environment,
and
so,
if
I
have
effectively
gained
control
of
that
one
container,
I'm
on
the
opposite
side
of
all
of
those
defenses
and
all
of
the
arms
race.
Acceleration
is
happening
on
the
network
firewall.
B
So,
first
and
foremost,
we
need
to
look
at
who's
responsible
for
code
and
security.
If
we're
in
a
commercial
environment
and
it's
a
closed
source
world
or
if
it's
a
highly
managed
commercial
software
operation,
there
will
be
periodic
security
updates
and
the
world
of
Microsoft
that's
become
known
as
Patch
Tuesday,
and
that
environment
has
a
dedicated
support
team
with
their
own
SLA
they've
got
their
own
dedicated
security,
researchers
who
are
focused
on
their
products
and
the
exploitability
of
their
products
and
the
things
that
are
built
out
of
them.
B
They
have
all
of
the
notification
infrastructure
in
place
to
make
this
work
in
a
very
seamless
fashion.
On
the
flip
side,
if
we
have
open
source
components,
it's
community
based
code
analysis
and
if
you
want
to
be
truly
aware
of,
what's
in
your
application,
it's
up
to
you
to
be
doing
a
lot
of
your
own
monitoring
and
ultimately
you're
responsible.
So
if
I
take
a
look
at
this
MediaWiki
announcement,
this
is
what
it
looks
like.
So
an
announcement
was
made
in
December
for
a
new
update.
B
They
also
made
an
announcement
in
that
same
post
that
this
version
marked
the
end
of
the
support
for
the
1.24
series,
and
they
also
highlighted
an
end-of-life
and
they
back
ported
a
bunch
of
fixes
because
they
thought
it
was
fair
to
fix
them.
Now,
if
I'm
dependent
upon
MediaWiki
for
my
environment,
I
have
to
be
monitoring
for
this
and
I
have
to
translate
all
of
the
various
notifications
that
are
going
to
come
out
of
the
engineering
team
to
determine
whether
or
not
this
is
a
fix
that
I
should
be
applying
now.
B
Little
over
nine
months
later
again
on
the
list
a
CVE
was
assigned
to
this,
and
that
assignment
was
our
CBE
2015.
Seventy
five,
forty
seven
and
this
assignment
occurred
on
the
16th
of
february
and
included
information
that
the
bug
was
introduced
in
g
Lipsy
to
dodge
so
from
July
of
20
2015
through
to
February
of
2016.
There
was
an
increasing
risk
because
there
was
some
awareness
that
was
out
there
that
a
buffer
overflow
was
present.
Normal
engineering
conversations
occurred
on
the
list
ago
and
determined
the
scope
and
the
issues
behind
it.
B
What's
interesting
is
that
that
disclosure
occurred
on
list
and
I
wasn't
until
two
days
later
that
the
bug
itself
on
the
CVE
itself
was
disclosed
through
the
National
vulnerability
database.
So
this
is
my
torg
representation
there,
a
couple
of
other
ways
getting
access
to
this
information,
but
this
is
typically
what
people
think
of
when
they
think
of
a
vulnerability
disclosure.
There's
a
CDE,
that's
been
put
out
there
and
there's
some
guidance
about
what
to
do
about
it.
B
If
I
read
the
overview
in
here,
it's
talking
an
awful
lot
about
DNS
management,
but
it
doesn't
give
me
any
prescriptive
guidance
as
to
what
to
do
next.
There
was
a
two
day
lag
between
that
nist
disclosure
and
what
was
on
the
list,
so
people
in
the
know
could
have
been
crafting
some
form
of
attack.
So
if
we
could
look
back
at
bob
bob
Sears
just
kind
of
picked
up
when
he
saw
that
and
he
started
doing
what
he
does
best.
B
Of
course,
if
you're
running
an
environment,
the
fact
that
there's
a
disclosure-
that's
cool-
well,
maybe
not,
but
that's
cool.
Ultimately
you
just
want
to
fix
it,
and
so
I
did
a
search
for
commercial
software
and
that
vulnerability.
That
CVE
and
the
first
thing
that
came
up
on
the
list
was
a
update
from
VMware
and
so
in
the
VMware
case
they
were
vulnerable
to
this.
They
disclosed
that
an
update
existed
for
ESXi,
five,
five
on
the
22nd
of
February
and
the
day
later
they
posted
an
update
for
ESXi,
600
and
so
normal
engineering.
B
We
need
to
determine
the
scope
of
the
impact
of
this
thing
and
we
need
to
go
and
figure
out
what
the
appropriate
fixes
for
us.
We
need
to
test
it.
So
a
couple
days
is
perfectly
rational
and
then
about
six
weeks
later
they
release
new
versions,
so
the
vCenter
server
appliance,
which
is
their
management
console,
which
was
also
impacted
by
this
and
so
patches
became
available.
You
figure
out
where
it
is
in
your
infrastructure.
You
fixed
it
and
now
you're
back
to
normal
for
one
vulnerability.
B
If
I
look
at
the
actual
details
behind
this
vulnerability
and
where
its
impact
was,
we
within
black
duck,
have
a
variety
of
data
feeds
in
case
of
this.
As
of
about
a
month
and
a
half
ago,
there
were
197
reports
of
this
eighty,
seven
of
which
were
vendor
specific.
But
if
you
look
about
a
third
of
the
way
down
the
list,
you
see
this
lovely
generic
exploit
URL.
B
So
if
I
flip
this
around
and
look
at
this
from
a
container
perspective,
production
use
of
containers
is
something
that
we
have
heard
consistently
throughout
2016.
There's
been
no
n
disturb
A's,
and
this
is
the
one
from
the
new
stack
showing
that
production
use
of
can
Tanner's
and
containerized
workloads
is
the
norm
today.
B
We
can
very
much
see
that
within
docker
surveys,
cluster
HQs
done
it,
but
most
recently,
data
dog
has
put
up
their
own
survey
in
their
own
analysis,
showing
in
the
last
year
amongst
their
roughly
10,000
customers,
strong
users
strong
world,
that
there's
been
a
30
percent
gross
growth
in
the
adoption
of
containers
for
their
monitoring
services.
So
that's
that
said,
a
huge
growth
and
even
though
the
attack
angle
might
be
kind
of
slowing
down
a
little
bit.
30
percent
is
something
that's
going
to
draw
in
anybody's
attention.
B
So,
let's
start
with
limiting
that
scope
of
compromised,
though,
first
and
foremost,
we
want
to
be
in
a
position
where
we're
enabling
the
Linux
security
modules.
There
is
no
meaningfully
good
reason
why
we
would
be
running
with
SELinux
today.
We
also
want
to
think
about
things
related
to
kernel
security
profiles
and
address,
load,
randomization
and
access
controls
of
every
shape
and
form.
We
also
want
to
take
a
look
at
exactly
what
the
kernel
capabilities
that
our
containers
need
are
so
within
docker,
there's
a
subset
of
about
a
dozen
kernel
capabilities
that
are
enabled
by
default.
B
You
can
reduce
it.
If
you
don't
need
them,
you
can
also
add
additional
capabilities
if
you
do
need
them.
But
if
you
go
down
the
path
of
adding
capabilities,
the
one
that
you
desperately
want
to
avoid
at
all
costs
is
cap,
underscore
sis
underscore
admin
because
for
practical
purposes,
that's
hey
guys.
I
need
root
and
trust
me
I'm,
good
and
I'm.
Wonderful
and
you
probably
don't
really
need
root
and
you've
probably
opened
yourself
up
to
a
world
of
hurt.
B
So
atomic
comes
from
upstream
project
atomic
and
when
it's
in
the
Red
Hat
Enterprise
limit,
Linux
atomic
host
version,
that's
really
an
optimizer
l7
variant
that
was
designed
for
use
with
docker
selinux
is
already
enabled
it
is
using
rpm
OS
tree
to
do
its
updates.
Oh
no
YUM,
and
the
benefit
of
that
is
that
you
do
get
upgrade
and
rollback
capabilities
for
any
updates
that
are
involved.
So
that's
a
huge
plus,
it's
also
pre-installed
with
docker
and
kubernetes.
So
you
get
the
all
the
base
framework
that
you
want
in
an
open
shift.
B
Environment
applications
are
just
defined
using
atomic
app
and
atomic
nuclei.
Nuclear
will
is
fundamentally
a
model
for
creating
a
multi
container
application,
and
so
that's
going
to
satisfy
the
requirements
of
a
full
pod
definition
in
a
kubernetes
and
openshift
world,
so
support
for
docker,
kubernetes,
openshift
and
mesas,
and
the
open
shift
artifacts
that
are
created
through
atomic
app
and
nucleo
can
run
either
natively
through
OC
new,
app
or
via
the
atomic
provider.
B
Interfacing
with
the
openshift
api
is
to
go
and
create
the
pods
and
associated
containers
within
it.
One
of
the
key
benefits
is
that
it
actually
provides
a
security
compliant
scan
capability
through
the
action
verb
atomic
scan,
and
so
it's
that
that
we
want
to
look
at
when
we're
talking
about
who
do
we
trust?
So
one
of
the
biggest
problems
that
exists
with
the
knurl
of
containers
today
is
that
anybody
can
create
a
container
and
anybody
can
post
a
container
anywhere
and
you
don't
necessarily
know
exactly
what's
inside
it.
B
You
can
kind
of
peel
it
back
and
you
can
look
at
some
of
the
elements.
But
do
you
really
have
a
trust
issue,
or
do
you
have
implicit
trust,
though
RedHat
curates
its
own
registry,
and
there
are
valued
containers
there?
You
can
also
create
some
with
atomic
app.
Those
will
also
be
present
within
the
registry.
You
can
create
your
own
private
registry.
You
can
pull
things
down
from
docker,
hub
or
docker
cloud,
and
you
can
consume
containers
that
come
from
somebody
else.
B
One
of
the
benefits
of
containerization
is
that
you
can
create
layers
of
applications
within
a
single
docker
image
and
then
move
them
forward
as
your
application
grows
at
a
falls.
But
the
last
question
to
ask
is
if
these
are
validated
and
curated
entities,
when
was
that
validation
performed
and
what
exactly
was
validated,
and
for
that
we
have
within
atomic
to
scan
capabilities.
One
is
open.
Scap.
An
open
SCAP
is
a
fantastic
solution,
we're
looking
at
the
compliance
environment
of
the
containers,
virtual
infrastructure.
What
have
you
that's
supporting
the
application?
B
So,
for
example,
if
you
have
a
PCI
DSS
environment
and
you
need
to
separate
the
personally
identifiable
information
from
that-
which
is
this
generic
information-
that's
on
the
backend.
You
can
set
up
a
set
of
profiles
within
OpenScape
that
include
everything
from
password
complexity
of
all
the
way
down
to
login
capabilities
and
one
of
the
components.
That's
part
of
that
compliance
environment
is
vendor
supplied
vulnerability
data,
so
Red
Hat
provides
it.
B
It's
also
available
for
a
handful
of
others
sources
and
it's
directly
integrated
within
atomic
itself
to
use
it
simply
run
an
atomic
scan,
scan
or
open
SCAP,
with
whatever
your
container
ID
did
earlier.
This
year,
at
Red,
Hat
summit,
Black,
Duck
and
red
had
announced
that
there
was
a
an
integration
between
the
black
hub
and
Red
Hat
atomic
and
one
of
the
values
of
value
propositions
that
this
brings
is
not
just
vendor
supplied
vulnerability
data
but
broad
vulnerability.
B
B
B
B
A
B
B
Now,
if
I
go
back
to
that,
Tom
capped
one
and
on
a
black
duct
scan
on
what
I
will
see
is
the
scanner
will
run
and
I'm
not
going
to
bore
you
with
the
results
of
waiting
for
this,
because
it
takes
about
ten
minutes
to
go
and
unwrap
that
entire
Tomcat
image
and
build
scan
and
true
cooking
show
model
I'm
going
to
go
up
here
and
pull
up
the
atomic
scan
of
Tomcat.
That
I
did
about
an
hour
ago
and
show
you
what
it
looks
like.
B
So
the
first
thing
we
see
is
that
we
have
security
risk,
license
risk
and
operational
risk
and
that
there
are
a
large
quantity
of
things
that
make
up
this
particular
container
and
all
of
the
dependencies
in
it
and
so
I'm
going
to
do
a
filter
on
just
new
things.
I'm
going
to
pick
on
the
new
sea
and
I
see
that
I
have
a
high
security
risk,
medium
operational
risk.
So,
let's
hover
over
the
operational
risk,
let's
see
what
this
is
all
about,
so
we
have
a
version
of
2.19.
B
This
version
was
updated
almost
two
years
ago.
It's
15
versions
behind
the
current
version
of
that
particular
component.
It's
a
very
stable
component
and
there
is
a
very
large
number
of
commits
that
are
happening
to
it,
so
it
is
truly
well
maintained,
so
the
operational
risk
on
this
is
medium
only
because
it's
so
far
behind
what
the
current
version
might
be,
and
so
we
see
Lo
and
we
see
hi
for
those
types
of
reasons
as
well.
I
click
on
the
security
risk
I
see
a
breakdown
of
what's
involved
in
it.
B
I
see
that
I've
got
it
in
a
number
of
locations.
Some
patches
exists,
some
are
new.
I'm
gonna
highlight
this
Volney
BP's
and
volunteers,
one
of
the
data
sources
that
we
take
in
order
to
determine
project
activity-
that's
out
there,
and
so
in
this
case
multiple,
not
a
number
of
functions,
string
handling
stack
based
buffer
overflow.
That's
what
this
vulnerability
is.
We
see
a
matrix,
that's
showing
how
exploitable
it
is
and
what
the
impact
is.
B
I
have
33
references
in
here,
nine
of
which
sorry
21
of
which
have
a
vendor
specific
URL
associated
with
them,
but
I
want
to
highlight
a
mailing
list
posts,
so
it'll
take
you
out
to
where
this
is
being
referenced,
so
preparing
a
fix
for
G
Lib,
C
2.23.
This
is
some
of
the
information.
That's
in
that
G.
Let's
see
post
I
look
at
the
next
one.
That's
actually
worth
a
read.
B
B
Are
using
to
run
docker,
so
that's
an
excellent
question.
It
can
be
either
based
on
docker
itself
or
on
atomic
or
if
you
have
access
to
the
raw
sources,
we
will
just
be
able
to
point
directly
at
that
project
and
consume
that
project
and
provide
a
report
on.
So
if
you've
got
an
upstream
consumption,
then
that's
a
way
that
you
can
get
it
through
either
atomic
or
docker.
But
if
you're
building
it
yourself,
you
can
see
where
that
code
is
coming
in
as
well,
so
excellent
question.
B
And
so
ultimately,
the
goal
of
running
a
secure
data
center
is
to
minimize
the
risk
associated
with
the
things
that
are
running
in
there,
and
so
I
mentioned
an
open
source
license
compliance
as
one
entity
if
you're
redistributed
or
have
a
requirement
to
redistribute.
Have
you
created
this
scenario
where
you
have
mutually
exclusive
licenses
and
understand
whether
or
not
those
dependencies
are
understood
if
you're
looking
at
open
source
component
inclusion?
B
Technology
focused
I've
mentioned
Blackduck
a
few
times
within
the
black
pipe
flow
go
down
in
the
bottom,
but
we
haven't
really
talked
about
who
we
are
we're
a
14
year
old
country
company.
That's
in
24
countries
we've
got
coming
up,
probably
close
now
to
300
employees
and
we're
consistently
growing
more
fantastic
company
to
work,
for
we
really
are
the
core
value
that
we
have
is
in
our
knowledge
base.
B
This
is
the
piece
of
the
heart
of
the
black
book
how
the
security,
when
it
starts
out
with
a
hub
skin,
and
that
hub
scan,
can
come
from
an
atomic
scan
that
hub
scan
can
come
through
docker
hub
scan
can
come
through
any
of
our
scan
agents,
which
can
be
integrated
into
other
tooling
for
SDLC
purposes,
creates
a
set
of
fingerprints
for
the
source
code.
That's
there
sends
it
up
to
the
hub
application.
All
that
stuff
is
on-premise
to
you.
B
All
that
we
do
is
we
can
we
transmit
those
signatures
up
to
our
knowledge
base?
That's
because
the
knowledge
base
is
so
huge.
We
you
wouldn't
want
to
be
in
a
position
where
you
were
having
to
continually
update
the
knowledge
bases.
New
vulnerabilities
came
out
could
be
latent
by
definition,
so
having
us
manage
that
it
is
a
huge
value
proposition,
but
we're
part
of
the
solution,
but
only
one
part,
knowing
what
you
have
running,
that's
huge,
knowing
why
you
have
running
it
is
critical.
Have
it
running
is
critical.
B
B
You
need
to
know,
what's
going
to
happen
once
you've
done
the
deployment
we
can
take
and
create
a
container
that
is
absolutely
pristine
in
terms
of
its
contents
and
have
a
reasonable
level
of
confidence
that
at
some
point
in
its
life
cycle,
somebody's
going
to
disclose
something
about
it,
that's
going
to
make
it
slightly
vulnerable,
maybe
a
little
bit
of
tarnish
on
it,
understanding
what
that
response
process
is
and
what
you
are
going
to
do
in
the
event
of
that
happening.
That's
the
critical
step
you
want
to
invest
in
defense-in-depth
models.
B
You
don't
want
to
be
in
a
position
where
you're
putting
all
of
your
energy
in
the
perimeter,
hoping
that
the
service
provider
is
going
to
have
all
of
the
answers
for
you,
relying
on
the
underlying
infrastructure
to
provide
your
security
is
an
important
part,
but
you
should
be
having
ownership
for
what
is
deployed
and
how
you're
going
to
to
work
with
it.
You
want
to
make
the
developers
and
the
office
team
is
part
of
the
solution.
B
We've
got
a
couple
of
free
tools:
we've
got
a
docker
container
security
scanner,
so
if
you
want
to
get
in
at
the
docker
level
by
all
means
take
that
URL
click
on
it
and
pointed
at
the
container
that
you
like
and
get
a
scan
result
back
at
in
a
few
minutes.
We
also
have
a
14
day
trial
to
the
hub.
You
get
all
the
power
of
the
hub,
including
the
integration
with
Red
Hat
atomic.
It's
all
leave
that
up
on
there
we've
got
any
other
questions.
A
That's
ok,
it's
pretty
pretty
awesome
presentation.
Thank
you
and
I
do
have
my
hoodie
on
today,
so
I'm
feeling
I
should
have
some.
You
know
real
good
attacker
questions,
but
I
have
an
Austin.
Thank
you.
This
was
great
for
me
because
basically,
I
create
containers
and
I
put
them
out
there
for
people
to
use,
and
then
you
know,
I'll
forget
about
somewhere.
A
I'll
leave
them
there
whatever
and
they
get
used
by
lots
of
people,
but
if
this
seems
to
be
a
preventative
thing
so
once
that
the
months
of
containers
deployed,
is
there
a
way
that
we
can
use
this
black
duct
approach
to
scan
something
because
containers
get
updated
while
they're
in
use
as
well?
So
it's
if
I'm
hearing
you
right,
you
you're
scanning
before
deployment,
but
then
after
containers
deployed
things
may
get
updated
in
there.
It
may
have
other
things
added
to
the
container,
especially
if
we
take
a
layered
approach
to
it.
So
is.
A
B
So
if
you
had
a
base
container
base
image
and
then
you
subsequently
are
adding
in
a
couple
of
extra
packages
or
components
in
order
to
build
out
whatever
it
is
that
you
want
to
deliver
as
those
pieces
are
version,
you
can
put
it
on
the
development
side,
but
the
scan
that
I
did
was
on
a
container
image
that
was
present.
And
so,
if
you
can
pause
that
image,
stop
that
image.
You
can
run
the
scan
at
that
point
in
time.
A
That's
great
so
I'm
definitely
gonna
have
to
give
this
a
try,
because
I've
only
used
the
base
OpenScape
one.
So
this
is
going
to
be
an
interesting
thing,
I'm
looking
to
see,
if
there's
anybody
else
out
there,
because
the
questions
you
can
type
them
in
the
chat
or
raise
your
hand
and
I
can
unmute
you
it's
more
complex,
give
it
a
few
more
minutes
and.
A
If
there's
no
more
questions,
I
will,
let
us
all
get
back
to
our
day
and
thank
you
very
much
Tim
and
the
whole
black
depth
thinker
for
making
this
happen
today,
and
we
will
talk
to
you
all
again
next
week
and
you'll
be
able
to
find
this
and
the
slides
on
Tim's,
SlideShare
and
we'll
post
all
of
this
on
the
OpenShift
blog,
probably
by
Monday,
thanks
again
Tim
and
for
the
entire
black
Becky.
Thank.