►
Description
Get your espresso ready for another EMEA OpenShift Coffee Break as we welcome Paul Smith, Solutions Architect at Sonatype, to talk about how Sonatype combined with Red Hat OpenShift creates synergies and an automated process that encourages component integrity and provides enhanced security features.
A
A
A
You're
already
on
the
second
round:
okay,
so
Paul
I,
don't
want
to
take
much
time
to
your
session
and
usually
I
I
like
to
start
with
the
what
what
we
are
going
to
talk
today
and
then
why?
Why
are
you
here?
Why
are
you
and
and
I
understand
that
asking
these
very
early
in
the
morning
could
be
tough
but
yeah.
B
Sure
sure,
so
what
we're
going
to
talk
about
today
is
we're
going
to
focus
on
a
joint
solution
created
by
red
hat
and
sonotype
around
generating
s-bomb
software
bill
of
materials
throughout
openshift
pipelines,
and
then
we're
going
to
expand
the
conversation
into
a
broader
topic
of
securing
your
and
managing
your
supply
chain
for
your
modern
software
Factory,
which
is
based,
of
course,
on
the
openshift
platform.
A
Cool-
if
just
few
words
about
that,
why
why
this
topic
is
so
relevant.
B
B
We
have
an
executive
order
where
you're
companies
are
not
going
to
have
a
choice
right,
it's
going
to
be
the
same
as
a
food
label,
you're
going
to
be
governed
you're
going
to
have
to
provide
a
bill
of
materials
for
what
you're
delivering
to
to
government
organizations
and,
of
course
this
is
going
to
have
widespread
effects
out
into
the
commercial
organizations
as
well,
so
it
you're
going
to
have
to
do
it.
B
So
that's
why
we're
here
to
to
discuss
that
both
sonotype
and
and
red
hat
with
openshift
is,
is
prepared
to
provide
that
for
their
clients.
Today,
yeah.
A
This
method
is
becoming
more
important
in
Europe,
because
I
think
there
are
a
lot
of
Regulation
coming
in
the
next
years.
That
will
have
a
strong
impact,
mainly
on
the
industry
like
fsci,
where
Bank
insurance
needs
to
provide
prove
that
they
that
the
Digital
Services
they
are
going
to
deliver
comply
with
some
regulations.
So
yes,
definitely
it's
not
for
only
for
the
USA,
but
also
for
Europe
European,
Community
UK,
so
that
definitely
that's
very
important.
Yeah.
D
C
This
is
incredibly
important
for
the
traceability
of
the
source,
material
and
the
traceability
of
the
actual
components.
So,
but
my
interest
in
this
is
slightly
different,
because
I
just
want
to
see
quicker.
Maven
builds
because
I'm,
tired
of
doing
demos
and
watching
made
them
download
the
entire
internet.
So
that's
my
interest,
but
please
please
carry
on
on
the
s-bomb
stuff.
B
Yes
and
I'll
be
sharing
we'll
go
through
a
few
slides.
Please
and
I'll.
Stop
sharing,
take
some
questions
and
then
we'll
share
again
and
I'll
actually
show
you
working
product,
so
we'll
actually
see
what
we
talk
about
cool.
Let
me
go
ahead
and
share
my
presentation
here.
Please,
please
tell
me
if
you
can
see
it
yeah,
we.
A
B
Right
great,
so,
first
off
just
a
brief
introduction
on
myself.
My
name
again
is
Paul
Smith
I'm,
a
sales
engineer
for
for
sonotype
I'm
really
excited
to
to
be
here
this
morning
and
discuss
this
joint
solution
and
the
broader
subject
of
how
we
secure
our
supply
chain
for
our
modern
software
Factory.
So
without
any
further
Ado,
let's
go
ahead
and
get
into
it.
B
So
a
little
bit
of
history
about
sonotype
we've
been
contributors
to
the
open
source
Community
for
a
few
decades.
Now
we
contributed
to
Apache
Maven.
We
are
the
stewards
of
Maven
Central,
and
this
is
important
because
it
gives
us
incredible,
Insight
and
and
how
developers
use
open
source.
B
Our
software
has
been
certified
on
our
department
of
defenses
Platform
One.
We
actually
have
an
air
gapped
deployment
option
so
just
to
give
you
a
little
bit
of
background.
We've
been
doing
this
for
for
quite
some
time
and
we're
really
happy
to
share
with
you
this
morning.
So
let's
get
into
the
the
subject
at
hand.
What
is
an
s-bomb,
so
this
is
very
wordy.
You
can
see
over
here
on
the
right,
a
formal
record
containing
the
details
of
supply
chain
relationships
of
various
components
used
in
building
software.
B
You'll
also
see
a
little
segment
over
here
on
on
the
left
that
I
pulled
from
from
a
European
paper
and,
like
I
said
these
are
going
to
be
mandated.
So
companies
are
not
going
to
have
a
choice
they're
going
to
have
to
provide
transparency
into
the
products
that
they're
building
and
what
they're
delivering
to
to
their
clients
and
great
news
is
today:
Red
Hat,
open
shift
clients
have
easy
access
and
ability
to
provide
software
bill
of
materials
for
what
they
are
building
today,
but
let's,
let's
make
it
a
little
bit
easier
right.
B
What
we're
really
talking
about
is
is
a
food
label
right,
so
we
can't
go
to
a
grocery
store
and
buy
anything
without
having
the
food
label
on
the
back
of
the
jar
or
the
Box,
and
the
reason
that
is
right
is
that
we
have
to
have
transparency
and
what
we're
going
to
consume
in
our
bodies,
and
so
it's
the
same
thing
with
a
software
bill
of
materials.
There's
two
prevalent
standards
for
software
Billet
material
out
there
today
spdx
they
focus
more
on
legal
and
licensed
compliance.
B
So
why
do
we
need
these
things?
Why
are
we
being
mandated
to
provide
these?
Well,
if
there's
a
mandate,
we
have
to
comply.
So
compliance
is
the
the
first
check
box
that
we
get
for
our
software
Factory,
the
others
you
know
benefit
from
a
software
bill
of
materials.
Is
it
gives
you,
transparency,
transparency
leads
to
Automation
and
then,
of
course,
remediation.
B
So
software
bill
of
materials
are
very,
very
important
today.
B
Another
really
important
question-
and
this
is
where
we're
going
to
kind
of
focus
on
today
and
and
when
I
demonstrate
the
the
technology
is,
what
do
I
do
with
s-box.
So
you
know,
s-bomb
is
really
becoming
an
overhyped
acronym
these
days
and
a
lot
of
our
clients.
They
they
hear
it,
but
they
really
don't
know
okay,
what
do
I
do
with
it?
So
there's
really
three
k
three
use
cases
around
dealing
with
s-bombs.
The
first
is
consumption,
so
you
know
how
do
I
receive
an
s-bomb
based
on
that
bill
of
materials?
B
How
do
I
identify-
and
you
know,
act
to
vulnerable
data
and
and
how
I
can
do
this?
Based
on
my
Enterprise
or
my
organizational
policies,
the
Second
Use
case,
we'll
talk
about,
is
actually
generating.
So
today,
with
this
solution,
openshift
clients
can
generate
the
s-bombs
we'll
do
this
automatically
and
this.
This
is
what
we'll
see
in
the
the
demo
today
and
then
the
the
third
use
case.
Is
you
know
how
do
I
store
and
manage
these
s-bombs
so
there
there
can
be
a
case
to
store
these.
B
Next
to
your
your
binaries
and
artifacts
in
a
repository,
Cyclone
DX
is
coming
out
with
the
an
s-bomb
exchange
server,
so
we
could
use
that
or
another
one
that
I've
I've
started
to
to
jointly
work
on
with
the
the
red
hat
team
is
ansible,
so
you
know
how
do
I
push
an
s-bomb
into
an
automation
platform
such
as
ansible,
so
that
I
can
maybe
sign
it,
maybe
store
it
in
a
vault,
a
number
of
automated
things
that
I
can
do
with
with
the
s-bomb.
B
If
you
look
on
the
left
side
here,
sonotype
has
been
a
very
active
participant
in
the
Cyclone
DX
s-bomb
specification
and
development.
We've
actually
been
supporting
s-bombs
for
for
a
little
while
now
kind
of
before
the
market
started
being
pushed
that
way.
We
can
any
any
anything
that
we
scan
or
look
at.
We
can
generate
and
Export
our
s-bombs.
We
have
apis
where
you
can
grab
those
and
also
we
can
consume
s-bombs
and
then
there's
some
links
here
to
the
executive
order.
The
Cyber
resilience
act.
B
That
I
spoke
about
some
best
practices
around
zero
day
vulnerabilities
and
a
really
neat
little
tool
that
we've
made
available
to
the
to
the
public
called
the
bomb
doctor.
So
you
can
get
quick
and
immediate
input
about.
You
know
how
your
s-bomb
looks
and
what
vulnerabilities
are
there.
B
So,
let's
talk
about
the
you
know:
securing
your
your
software
supply
chain
in
openshift,
so
I'm
going
to
introduce
you
here
to
the
Nexus
platform,
there's
basically
three
products
in
our
platform,
the
repository.
In
fact,
a
lot
of
a
lot
of
people
say:
oh
they're,
the
repository
company,
so
we
we
first
came
out
with
an
open
source,
Nexus
Repository
about
10
years
ago.
We
actually
have
a
pro
version,
but
it's
just
that
right.
It's
it's!
It's
a
repository
where
we
can
manage
our
libraries
and
build
artifacts.
B
B
Essentially
in
a
nutshell,
it
prevents
OSS
malware
right,
so
it
never
lets
any
of
the
open
source
malware
and
there's
more
and
more
of
those
nefarious
people
out
there
pushing
open
source
malware.
We
stop
it
at
the
front
Gates
of
of
your
cluster,
so
your
open
shift.
Customers
can
rest
assure
that
you
know,
based
on
their
policy.
No
developers
are
going
to
be
able
to
pull
in.
A
A
great
great
point,
the
fact
that
obviously
the
repository
it's
it's
a
key
element,
key
tool
for
in
a
software
development
life
cycle,
but
this
Nexus
file
I
think,
is
really
an
interesting
cause
of
the
fact
that
you
allows
to
take
control
or
really
what
is
going
to
be
released
in
in
an
environmental.
It
could
be
an
open
shift
cluster,
because
open
source
is
a
great
open
source.
Frameworks
are
great,
obviously,
but
that
great
Freedom
needs
also
a
great
responsibility
as
always.
A
So
the
fact
that
we
have
something
that
you
can
leverage
on
in
order
to
implement
this
sort
of
responsibility
is
great.
B
That
that's
right,
I
mean
look
again.
We
can
set
policy
and
we'll
see
this
in
the
demo,
so
it
so
that
at
least
you
can
ensure
that
the
really
really
bad
things
out
there
aren't
going
to
be
pulled
into
your
organization
right.
We've
we've
got
in
some
cases.
You
know
thousands
of
developers
at
our
client
sites
pulling
open
soft
open
source
software.
In
and
again,
if
you
use
a
a
repository
along
with
firewall,
I
I
mean
really
every
client
out
there.
B
Every
organization
should
should
own
firewall
and
I
will
say
we
are
the
only
ones
that
actually
have
this
capability
today
there
is
no
competition
for
for
nexus
firewall
and
then,
lastly-
and
this
is
really
the
brunt
of
of
our
s-bomb
solution-
is
our
life
cycle
product,
so
life
cycle
is
meant
to
you
know,
identify
detect.
You
know,
vulnerabilities
in
in
your
open
source
usage
provide
remediation
for
that
and
it's
actionable
across
the
entire
sdlc
right
from
source
to
your
build
to
your
release
and
even
out
to
production
right.
B
So
we
have
an
s-bomb.
What
we
do
is
we
like
to
continuously
monitor
those
key
s-bomb
applications,
because
we
say
you
know
open
source
age
is
more
like
more
like
milk
than
Wine
and
then
the
last
piece
there
is
the
intelligence,
I
I.
You
know
a
lot
of
people
will
label
Us
in
the
security
space.
I
really
think
we're
in
the
intelligent
space.
B
B
B
B
If
you,
if
you
go
to
a
military
base
right,
the
first
thing
you
have
to
to
go
through
is
that
that
outside
gate
you
know
they
search
under
the
car
pop
the
hood
all
of
those
things,
that's
what
firewall
is
going
to
do
for
us
right?
No,
no
one's
going
to
get
past
that
gate.
That
has
some
nefarious
intention
and
once
we've
pulled
it
in
now,
with
our
builds,
we
can
pull
from
a
repository.
A
B
B
This
last
slide
here
we'll
hand
out
the
slides
to
anyone
who's
interested.
This
is
really
just
the
cheat
sheet.
That
kind
of
gives
you
a
bulletized
list
of
the
capabilities
that
this
solution
will
bring
to
your
openshift
clients.
B
C
Yeah,
so
from
a
developer
perspective,
I'd
say
that
this
is
I,
say
that
I
mean
from
my
perspective.
Can
you
give
me
a
quick
overview
on
what
we
have
in
terms
of
the
currency?
So
when
you
talk
about
the
s-bomb
itself
compared
to
what,
for
example,
Nexus
stores,
what's
the
one-to-one
match
between
the
s
bomb
and
the
actual
artifacts
within
the
next
side,.
B
C
That
actually
maintained,
because
that's
very
important,
isn't
it
to
actually
lock
the
actual
artifact
components
into
the
s-bomb
itself.
B
That
that
great
great
question,
so
when,
when
life
cycle
scans
a
project,
we
walk
the
directory
structure,
so
we're
walking
the
entire
directory
structure
and
we're
actually
what
we
we
call
it
Advanced
binary
fingerprinting,
but
we're
basically
taking
a
hash
of
the
open
source
artifact.
B
So
we
walked
that
complete
tree.
We
do
a
hash
of
the
binaries
that
are
actually
in
your
project
right,
A,
lot
of
times
you
look
at
the
Manifest.
You
know
what
we
think's
in
it
oftentimes.
What
we
think
is
in
our
project
really
isn't
in
it.
When
we
do
a
build
you'll,
be
surprised
from
what
you
have.
You
know
what
what
you're
saying
in
your
palm.xml
or
your
package.json,
when
you
actually
do
the
build
and
the
install
there
might
be
a
different
set
of
of
artifacts
in
there.
B
So
we're
we're
actually
looking
at
the
the
binaries
artifacts
themselves
and
taking
a
fingerprint
again.
This
is
intellectual
property.
It's
a
key
differentiator
for
Red
Hat,
openshift
clients
right
where,
because
again
without
accuracy
of
data,
you
can't
automate
right
when,
when
you
don't,
when
you
have
bad
data,
your
pipeline
shuts
down,
because
we
got
to
figure
out,
you
know
where
to
go
wrong,
but
you
know:
if
we
have
accurate
data,
then
we
can
improve
our
automation
again.
We
are
providing
actionable
intelligence
around
the
usage
of
of
Open
Source.
B
Did
that
answer
your
question?
Yeah.
D
Yeah
so
I
I
have
few
questions,
but
I'll
I'll
refer
them
up
to
after
the
the
demo,
but
I
think
it's
really
interesting
to
see,
basically
how
you
can
generate
the
s-bombs
and
what
would
be
interesting
if
we
can
talk
about
that
afterwards
is,
is
how
you
make
use
of
the
S
bombs
afterwards
for
like
traceability
for
auditability,
and
things
like
that.
So
after
after
everything
has
been
generated,
how
do
we
make
sure
that
whatever
we
created
has
been
hasn't
been
tampered
with
and
such
things.
B
Sure,
and
and
those
are
great
great
questions
so
we'll
we'll
see,
are
you
guys
seeing
my.
B
Right
thanks
all
right,
so
I
want
to
start.
This
was
a
question
earlier
right
again,
and
this
is
the
beauty
of
this-
is
that
this
is
easy.
We
we've
made
it
easy
for
openshift
clients,
because
we
we
have
operators,
there
are
other
other.
We
have
certified
containers.
We
have
operators
we're
delivering
Helm
charts,
but
of
course
you
know,
operators
are
the
the
the
easiest
ways
to
get
started
here.
A
few
clicks.
B
You
actually
have
this
capability
up
and
running
so
you'll
see
here
we
have
Nexus
IQ
operator.
The
this.
This
particular
operator
supports
both
firewall
and
life
cycle
and,
of
course
we
have
our
repository
operator
that
supports
our
our
Nexus
repository
and
and
and
what
we've
done
here
is
we
created
a
pipeline.
B
I
can
show
you
real,
quick,
it's
a
very
simple
pipeline,
but
we're
we're
doing
a
clone
I
believe
we're
cloning,
a
web
goat,
we're
doing
a
maven,
build
of
that
and
then
we're
doing
a
scan
right,
so
that
scan
is
where
we're
going
to
generate
our
s-bomb.
If
we
look
at
this
run
here
and
I
look
at
the
logs,
you
can
see
that
we
did
the
Clone.
B
The
build
and
we
did
our
life
cycle
scan
where
we
generated
this
report
URL
now,
if,
if
I
go
to
that
report,
URL.
B
So
so
we
we've
generated
this
this
s-bomb,
you
can
see
here
that
we
can
actually
pull
down
a
PDF
or
we
can
pull
down
the
Cyclone
DX
s-bomb.
We
could
pull
that
s-bomb
from
API,
so
there
are
a
number
of
different
ways
to
to
grab
that
that
s-bomb
for
additional
or
further
usage,
but
today
that
pipeline
actually
builds
this
software
bill
of
materials.
B
So
if
we
come
in
here
and
just
take
a
look,
we'll
get
things
like
a
dependency
tree,
so
you
know
sometimes
we'll
see-
and
this
this
again
goes
back
to
our
conversation,
about
us
being
able
to
walk
that
directory
structure
and
you'll
see.
Some
of
these
are
like
four
or
five
levels,
deep,
where
we
might
have
a
vulnerability.
B
If
we
look
at
this
report,
we
can,
let's
see
we'll
pick
one
here.
You
can
see
we'll
we'll
tell
you
if
it's
if
it's
transitive,
whether
it's
direct,
we'll
even
tell
you
where
we
found
it.
B
B
What
sonotype
does
with
that
intelligence
platform
is
that
we
go
after
we
use
Ai
and
machine
learning
to
pull
in
from
about
130
different
data
sources,
and
we
filter
that
into
our
data
research
team.
Our
data
research
team
adds
the
rest
of
this.
So
we'll
add
explanations
we'll
provide
code
Snippets,
but
we're
we're
complementing
what
you
would
normally
find
out
there
in
like
an
nvd.
In
fact,
nvd
makes
up
I
think
only
about
30
percent
of
the
actual
data
that
we
have
stored
in
our
catalog
around
our
open
source,
binaries
and
artifacts.
B
So
we
look
at
the
security,
we'll
also
look
at
the
licenses.
You
know:
what's
the
effective,
what's
the
declare
what's
the
observed
license,
so
all
of
that
information
is
contained
in
this
software
materials.
It.
A
B
Sure
sure
and
that's
a
beautiful
segue-
it's
almost
like
we've
done
this
a
few
times
together.
So
so
everything
is
done
through
through
policy
right.
We
lifecycle
is
a
policy
enforcement
engine.
So
if
we
look
let's,
let's
look
at
a
couple
policies
here,
so
we
we
can
have
our
own
application
categories,
but
here's
a
security,
critical
policy,
all
right,
and
so,
let's,
just
let's
examine
policy
again
we're
going
to
create
this
policy
that
says:
okay.
This
is
a
10
right.
This
is
the
bad
stuff.
B
We
we
don't
want
to
let
this
this
move
through
our
pipeline,
and
so
we
have
these
constraints,
basically
we're
we're
creating
the
conditions
upon
which
we
would
trigger
a
violation
of
this
particular
policy.
In
this
case
we
say
if
the
vulnerability
severity
is
greater
than
equal
to
nine.
You
can
see
here
we
can
do
things
on
age,
on
hygiene
Integrity
license,
so
it
can.
Your
policies
can
be
based
around
legal.
It
can
be
based
throughout
architecture.
It
could
be
based
around,
of
course,
security
and
vulnerabilities.
B
So
we
build
this,
this
policy
out
right
and
if
there's
a
violation
and
then
you
remember,
I,
said
that
we
actually
give
provide
actionable
intelligence
across
the
sdlc.
So
here's
the
actions
right.
So
if
I
get
the
really
bad
stuff
in
my
application
or
my
project,
what
do
I
want
to
do
at
each
stage
of
my
sdlc?
Well,
here
you'll
see
proxy,
remember
firewall.
That
is
firewall
right.
So
this
is
where
you
know
this
component
would
not
even
come
into
my
pipeline
right,
because
I
would
fail
it
as
I
pulled
it
down
right.
B
So,
if
you're
trying
to
do
a
maven,
build
and
you're
trying
to
pull
this
component
in
your
build
is
is
not
going
to
go
well
because
we're
not
going
to
allow
you
to
pull
that
in
now,
usually
for
developers
and
for
build
stages.
We
do
warrants
because
develop
developers
don't
like
tools
breaking
their
bills.
That's
just
how
it
is
right
so,
but
we
want
to
give
developers,
warnings
to
say:
hey,
there's
some
potentially
bad
stuff
that
you're
you're,
sending
through
this
Pipeline
and
by
the
way
in
stage
release
and
operate.
B
It's
not
going
to
make
it
out,
so
we're
not
going
to
break
your
build,
but
we're
going
to
warn
you
that
you
know
you're
going
to
have
to
change
this,
so
no
no
build
break,
but
you'll
still
have
to
do
something.
You'll
still
have
to
address
it,
and
then
the
last
Point
here
is
who
or
what
should
I
notify
right
so
could
be
a
specific
email.
It
could
be
a
specific
role
that
you're
you're
assigned
through
ldap
or
it
could
be
a
web
hook.
B
So
maybe
one
of
the
things
I
want
to
do
when
I
get
a
particular
policy
violation.
Maybe
I
want
to
use
a
web
hook
and
call
out
to
ansible
my
automation
platform
and,
have
you
know
XYZ
done
depending
on
you
know
what
policy
and
what
I
want
enforced.
So
I
think
that
addresses
the
the
questions
you
just
had.
So
yes,
it's
all
customizable.
We
we
ship
with
I,
I,
think
I,
know
it's
like
25
or
so
policies
out
of
the
box
and
again
it's
all
customizable.
B
D
Yeah
thanks:
this
is
a
really
interesting
and
I.
I
have
a
follow-up
question
on
that.
So
the
fact
that
you
are
able
to
store
all
the
the
libraries
and
all
the
dependencies
in
your
Repository
that
gives
you
I
would
say
a
real
awareness
of
the
ecosystem
of
your
applications,
so
say,
for
instance,
we
have
detected
that
there's
a
vulnerability
on
a
specific
Library.
D
Do
you
have
a
way
to
to
map
that,
to
the
actual
applications
that
use
them,
or
or
maybe
even
to
in
our
case,
say
we
are
using
those
libraries
in
container
images?
Is
there
a
way
to
I
I'm
speaking
from
a
remediation
standpoint?
Yes,
that's
something
that
we
can
find
or.
B
Yes
excellent
question,
so
let's
just
take
a
real
life
incident
right.
It
happened
in
December
of
2021
a
little
thing
called
log4j,
yeah,
I'm
sure
everyone
is
familiar
right
sure.
So
so
so
we
we
actually
had
that
in
our
catalog
I
think
within
an
hour
or
two
of
when
it
was
actually
recognized.
So
if
you
were
one
of
our
clients
and
you
come
into
this
dashboard-
and
this
is
just
one
way
remember-
the
other
way
is
as
soon
as
it
gets
in
our
catalog.
B
B
All
right,
then,
here
right
we
could
say
we
want
to
you,
know
more
likely
we're
going
to
continuously
monitor
release
right
so
as
soon
as
that,
log4j
update
hit
our
catalog
and
you're.
Doing
continuous
monitoring
you're
now
going
to
violate
a
policy,
and
so
your
policy
enforcement
Springs
into
action
right.
So
it's
gonna,
it's
gonna,
make
the
email
notification,
the
role
notification
or
send
it
to
you
know
a
system.
B
It
will
give
me
all
of
the
applications
across
the
Enterprise
and
give
me
the
risk
breakdown
based
on
that
component
in
those
applications.
So
here
here's
the
really
great
thing:
log4j
was
a
non-event
for
our
clients
and
and
that's
an
incredible
statement.
If
you
think
about
how
many
people,
in
fact
you
know
again,
it
goes
back
to
us
being
you
know
the
the
stewards
of
Maven
Central
we
still
see
about.
30
of
the
downloads
of
log4j
are
vulnerable
versions
of
log4j.
B
Right
they're
still
in
their
their
CI
CDs
moving
forward.
So
it's
just
incredible,
but
but
our
for
our
clients,
blog
for
Jay,
was
a
non-event
which
is
really
really
incredible.
D
B
B
So,
let's,
let's,
let's
shift
a
little
bit
towards
and
again
you
could
see
that
this
is
you
know
our
operator
running
in
in
our
cluster
here
openshift
cluster,
let's,
let's
just
talk
about
repository
manager,
real
quick
right,
so
there
are
three
types
of
repositories
that
that
you
can
have.
One
is
a
proxy
right,
so
the
the
proxy-
and
you
can
see
here-
let's
let
me
go
back
here,
so
you
can
see
I'm
actually
pointing
to
the
npm.
B
Your
build
is
going
to
go
to
npm
proxy
and
it's
going
to
pull
from
proxy.
If
it's
already
cached
here
right,
you
don't
have
to
go
out
to
the
internet.
We've
already.
We've
already
pulled
that
into
our
repository,
so
this
is
this
is
where
all
your
development
toolings
are
typically
pointed
at
or
our
proxy,
because
we're
a
proxy
for
some
some
public
repository.
B
Then
we
have
a
hosted
capability,
the
hosted
capability-
that's
where
like
we
want
to
put
our
artifacts
after
the
builds
right
and
then
we
can
put
groups
so
maybe
I
have
like
four
or
five
proxy
repositories
and
I
don't
want.
You
know
when
you're
running
your
build.
I
don't
want
to
have
to
have.
You
have
to
go
to
five
different
prox
repositories,
so
I
can
group
those
all
in
one
so
you'll,
search
across
those
those
repositories
for
your
built,
build
artifacts
and
then
the
other
thing
I
want
to
bring
up
here.
B
So
firewall
has
you
know
when
I
did
a
npm
install
it
tried
to
pull
in
all
these
artifacts.
You
can
see
I've
actually
got
some
quarantined.
I've
got
these
alerts
here.
All
of
this
is
based
on
component
right.
So
we
can't
tell
you
you
know
where,
in
your
code,
we
found
it
because
it's
all
the
components
coming
into
the
repository
manager,
where,
with
life
cycle,
we're
actually
examining
your
application.
B
So
those
are
the
the
differences
between
firewall,
looking
at
just
the
components
that
we're
pulling
into
our
factory
and
we're
going
to
stop
all
the
bad
ones.
All
that
malware
where
life
cycle
is
being
used
across
the
sdlc
to
examine
and
detect
OSS
usage
in
your
application,
so
that
we
can
tell
you
where
we
found
it
and
all
that
information
of
what
you're
pushing
through
your
your
Pipelines.
B
D
Have
a
few
questions,
but
there
are
a
bit
specific.
So,
as
you
know,
red
hat
is
also
working
on
devsecups
patterns
to
to
imp,
to
Showcase
some
best
practices
around
making
your
software
supply
chain,
more
secure
interest,
trust
trusted,
I
would
say,
and
so
one
of
the
key
questions
there
is:
what
do
we
do
with
the
s-bomb?
So
we
see
that
you
can
have
like
the
nice
UI
to
navigate
with
that.
You
showed
that
you
can
also
generate
it
in
the
Cyclone,
DX
format.
D
I
think
there's
also
different
formats
spdx
as
well
or,
if
I'm,
if
I'm
correct,
but
okay,
so
you
have
generated
an
s-bomb.
So
first
thing:
is
it
stored
within
the
application
repository
or
do
you
store
it
in
Nexus
and
the
other
question
is
how
do
you
use
that
later
in
the
in
the
life
cycle?
So
so
say
you
have
built
your
s-bomb
from
the
source
code
right
now,
your
binaries
or
your
Java
application
gets
embedded
in
a
container
image.
D
Okay,
this
container
image
is
in
turn,
going
to
be
deployed
somewhere
at
a
later
stage.
So
first
is
there.
I
would
say
something
that
allows
you
to
compare
the
container
image
with
the
source
code
to
say
this
is
what
we
were
supposed
to
have
from
the
source
code
perspective.
This
is
the
s-bomb
that
comes
with
it.
Do
you
also
generate
s-bomb
based
on
container
images,
and
maybe,
if
you
are
using
container
images
that
in
turn
use
some
dependencies
that
do
not
come
from
the
the
code
that
comes
from
other
layers
of
the
container
image?
D
B
C
B
So
so
what
we've
looked
at
today
is
around
the
around
the
application
and
the
open
source
usage
in
an
application.
We
also
have
the
ability
to
scan
an
image
and
get
those
those
container
vulnerabilities.
Just
like
the
application
we
can.
We
can
get
that
as
well
now
now
the
application
once
you've
got
the
application
and
you're
going
to
release
that
or
you're
going
to
put
that
in
your
image
and
deploy.
C
B
Right,
that's
why
the
s-bomb
is
important
right,
because
at
that
release
point
you
want
the
software
bill
of
materials
and
what
I'm
going
to
do
is
continuously
monitor
that
software
bill
of
materials
right
I
could
also
take
the
the
s-bomb
for
your
container
right
and
continuously
monitor
those
so
that
if
something
in
that
image
that
you've
deployed
ages
like
milk
right,
it's
gone
sour
that
you
know
this
same
things
can
be
done
for
the
container
now.
I
also
know
you
guys
have
ACS
right.
B
So
ACS
is
an
ability
to
also
scan
and
you
can
generate
an
s-bomb
and
we
can
consume
that
s-bomb
right.
So
so
you
know
Red
Hat
openshift
has
the
solutions.
You
know
whether
you
want
to
use
us
to
scan
containers
or
you
want
to
use
you
know
ACS
or
Claire.
You
know,
there's
some
open
source,
tooling
it
it
doesn't
matter
right.
It's
we're
able
to
consume
those
s-bombs
we're
able
to
tie
those
to
your
application
s-bomb.
B
So
it's
it's
again.
It's
a
holistic
solution
for
a
software
Factory
powered
by
by
openshift
great
questions,
though,
when
I
was
putting
this
together
again
I'm
conscious
of
of
you
know,
ACS
and
your
ability
and
ACS
moves
into
production
as
well
right,
so
you're,
actually
monitoring,
Ingress
and
egress
of
of,
what's
going
in
and
out
of
your
your
pods
and
those
kinds
of
things
as
well.
B
So
again,
if
I'm
looking
at
an
openshift
software,
Factory
and
I
know,
I
can
create
a
holistic
software
bill
of
materials
for
the
container
the
application
and
then
I
can
still
apply.
Runtime
security
in
in
production,
I,
I,
think
I.
Think
openshift
provides
a
pretty
good
platform
for
a
soft,
a
modern
software,
Factory
yeah.
D
D
So,
if
you,
if
you
think
about
things
like
recore
I,
don't
know
if
you're
familiar
with
the
these
Notions
of
transparency
log,
where
you
say
basically,
we
have
done
a
couple
things
in
our
Pipeline
and
how
do
we
make
sure
that
what
we
are
we
have
in
the
end,
what
we
are
trying
to
deploy
is
actually
what
we
have
built
and
one
of
the
principles
is
that
you
are
going,
for
example,
to
sign
the
artifacts
and
be
able
to
verify
those
artifacts
later
on
in
the
Stingers
to
say
yes,
those
artifacts
that
we
produce,
whether
it
be
the
binaries
or
the
container
images
or
even
the
the
yaml
files,
are
exactly
see
what
we
have
built
and
it's
not
somebody
who
who
dropped.
D
You
know,
dropped
them
somewhere
in
between
and
is
trying
to
compromise
the
the
the
the
the
the
environments
where
we
are
running
the
applications,
and
so
it
was
more
towards.
Can
we,
for
example,
hash
that
s-bomb
sign
in
store
it
somewhere
and
once
we
do,
the
deployment
use
the
s-bomb
to
verify
its
trust
worthiness
or
something
like
that.
B
So
all
of
that
is
is
doable.
Yes,
if
you
remember
the
slide
right
so
will
when
we
generate
when
we
do
that
directory.
You
know
when
we
crawl
across
that
directory
tree
we'll
generate
that
s-bomb.
B
What
you
want
to
do
with
it
is
what
your
organization
policy
is
right.
Yes,
you
could
store
it
in
in
our
repository
manager,
next
to
your
artifacts
and
think
I
I
actually
think
that's
probably
a
good
idea,
or
at
least
one
but,
like
you
said,
maybe
I
want
to
sign
it
right,
store
it
in
a
vault
somewhere.
Maybe
that's
repository
manager
so
somewhere
else,
a
more
Secure
Vault
and
use
it
to
do
some
comparison.
B
I
look
at
that
as
where
ansible
can
play
a
big
role
for
for
openshift
clients
right,
because
you
know
it's
an
automation
platform,
so
you
know
I
can
trigger
ansible
and
ansible
could
sign
that
s-bomb
put
it
in
default.
Deliver
it.
However,
you
want
to
do
it
and
what
you
were
talking
about
is
you
know
we.
We
won't
say
that
hey
you're,
you're,
you're
s-bomb
back
here
in
development
had
x
y
z
and
now
you're
getting
you're
releasing
this
stuff,
and
now
it
has
wyc.
Yes,.
D
B
We
care
about
is
the
moment
in
time
that
we
inspect
what
you're
delivering
so
again,
if
you
remember
the
the
the
the
buckets
where
I
went
from
source
to
develop,
to
build
to
release
to
operate.
Well,
certainly
I
want
to
when
I'm
getting
ready
to
push
this
thing
in
deployment.
That's
where
I
want
to
do
another
scan
right,
I
want
to
do
another
inspection.
B
We
won't
be
able
to
say,
look
you!
You
are
using
this
component
back
then,
and
now
you're
using
a
different
component
or
a
different
version,
maybe
right,
but
what
we
will
be
able
to
tell
you
is,
if
there's
any
bad
stuff
in
which
you're
about
ready
to
push
out
into
production,
which
is
really
what
we
want
right.
D
D
D
From
the
automation
standpoint,
you
are
providing
apis,
for
example,
that
allow
you
to
pull
the
data
for
the
s-bombs,
or
things
like
that
to
to
be
able
to
to
use
that
in
an
automation
framework.
Is
that
correct.
B
That
that's
right
I
mean
that
that's
that
whole
policy
enforcement
engine
right,
it's
really
it's
it's
automating,
our
pipelines,
right
and
and
but
again
you
can
automate
unless
your
data
is
good
right.
That
intelligence
needs
to
be
good.
Just
like
anything
right.
If
you
take
any
security
measurements,
the
intelligence
we
pull
in
affects
the
decisions
we
can
make
and
if
we
we
know
it's
accurate,
then
we
can
automate
those
decisions,
which
is
exactly
what
life
cycle
does
for
openshift
clients.
C
C
I'd
like
to
say
I,
really
like
the
analogy
of
the
calories
and
the
food
count
and
stuff.
Does
that
mean
I
should
use
less
fat
jars
going
forward.
B
You
know,
that's
that,
that's
you
know
an
organizational
policy
right.
You
know
there
are.
What
we
don't
do
is
tell
you.
You
know
your
back
best
practices
of
Cody.
B
D
D
Like
the
analogy
of
you
know,
milk
aging
and
wine,
which
is
makes
perfect
sense
for
for
the
for
the
components,
we're
gonna
reuse
that
definitely
yeah.
C
I'll
tell
you,
for
me:
I
mean
what
I
picked
up
in
the
last
kind
of
20
minutes,
or
so
is
it's
all
down
to
temporal
standing
is
that
is
that
something
to
be
aware
of
that
anything
you
get
generated,
an
s-bomb
is
going
to
be
temporarily
stamped.
That's.
B
Right
that
that's
that's
a
very
accurate
statement,
I
mean
it
it's
a
moment
in
time,
yeah
what
and
log4j
right
when
those
applications
were
pushed
into
production.
There
were
no
vulnerabilities
and
then
December
2021.
B
Guess
what
and,
and
so
there
was
a
mad
Scramble
for
those
people
that
don't
have
tooling
such
as
what
lifecycle
provides
right,
because
you
know
just
doing
the
inventory
of
who
used
those
components
across
a
large
organization
is,
is
just
incredible
the
amount
of
time
and
effort
and
of
course
that
leads
to
Dollars
to
remediate
those
things
where
you
know
tooling,
that
either
gives
you
notification
or
you
can
quickly
find
where
those
artifacts
are.
D
D
So
I
would
have
a
final
question
and
I'm
sorry.
So
this
is
a
topic
that
is
very
close
to
my
heart,
because
I'm
I'm
working
on
the
devsecups
patterns,
so
that's
very
useful
information
for
me
as
well.
So
two
two
questions.
First
one
is
do.
Does
the
s-bomb
you
generate
have
a
metadata
information
about,
for
example,
the
application
release,
because
obviously
these
are
things
that
you
store
in
the
Nexus
repository.
You
say
this
is
going
to
be
cut
for
release
2.7
of
the
application,
not
speaking
about
different
zones.
D
For
example,
do
you
translate
transfer
those
metadata
information
to
the
s-bombs
as
well?
So
you
have
an
ID
of
this.
S-Bomb
corresponds
to
this
specific
release
of
my
application,
or
things
like
that.
B
There
is,
there
is
some
metadata
you
can
set
up
additional
metadata
inside
of
your
policy
enforcement
engine.
To
do
that,
you
know
we
will
provide.
You
know,
basically,
the
coordinates
or
the
Pearl
for
your
components.
We'll
also
provide
vulnerabilities.
Now
we
we
said
yeah.
We
just
talked
about
these,
be
in
a
moment
in
time.
B
Have
clients
that
want
the
vulnerabilities
in
an
s-bomb,
but
but
since
we're
talking,
Json
and
XML,
another
thing
that
ansible
could
do
right.
I
don't
want
the
vulnerabilities
in
my
s-bomb.
Well,
you
know
what
I'm
gonna
do.
What
is
a
JQ
or
you.
A
B
Xflt
I
think,
and
you
know,
I'm
just
gonna
get.
A
B
Have
and
then
that's
what
I'm
going
to
monitor
continuously
monitor
because
I
don't
care
about
the
vulnerabilities
in
a
moment
in
time.
A
B
That
is,
is
doable
and
also
I'll
bring
to
you,
I
I,
don't
know
why
I
can't
get
my
vs
code
and
share
that
I've
tried
it,
but
we
also
have
plugins
to
all
of
the
Ides
right.
So
what
you
could
do
is
basically
put
a
bill
of
materials
right
at
the
finger
fingers
of
your
developers
so
that
they
can
actually
see
as
they're
developing
in
their
IDE.
B
You
know
what
what
OSS
vulnerabilities
that
they
might
be
working
with
and
there's
some
ability
to
migrate
or
change
like
the
palm.xml
if
it's
a
direct
dependency,
but
everything
you
saw
on
that
s-bomb
and
that
report
I
showed
today
is
available
in
your
Ides.
It's
available
in
all
of
your
your
builds
right.
So
we
we
saw
today
we've
got
an
open
shift
pipeline
which
is
based
on
Tech
time
by
the
way
we're
the
the
only
vendor
in
this
space.
B
That
actually
has
you
know
a
a
tecton
approved
task,
so
you
can
go
to
the
tech
time
Hub
and
type
and
you'll
be
able
to
find
that
you
know
I've
created
some
videos
showing
how
to
set
this
up,
but
I'm
pretty
sure
the
red
hat
folks
are
are
pretty
Adept
at
setting
up
open
shift
pipelines,
probably
better
than
myself
yeah.
D
So
this
is
really
useful
because
the
the
pattern
that
we
are
actually
working
on
one
of
the
so
the
next
iteration
is
to
actually
try
to
embed
the
s-bomb
Generation
generation
from
sonotype.
So
that's
I
would
say
a
very
nice
situation,
iteration
that
we
will
add
in
there
to
to
to
present.
D
I
would
say
value
proposition
of
of
an
open
shift
with
with
solid
type
that.
B
That's
right,
I
mean
what
we're
doing
is
we're
providing
our
clients
jointly,
providing
our
clients
with
the
most
the
most
secure,
modern
software
Factory.
There
is
today
right,
I
mean
that
that's
why
you
would
choose
open.
That's
why
I
would
choose
openshift
over
kubernetes
right,
because
there's
a
lot
of
security
built
into
the
openshift
platform
that
I
don't
have
to
manually
do
right.
So
it's.
D
B
Tco
now
we've
got
operators
that
secure
and
manage
our
our
supply
chain
and
their
usage
of
Open
Source
right.
A
B
Click
click,
lower
TCO
works
together.
You
know
and
I
I
I
look
at
things.
I
try
to
make
things
simple:
I
worked
at
a
manufacturing
plant
in
that
plant.
We
had
a
paint
shop,
we
had
a
weld
shop,
we
had
a
wood
shop,
we
had
a
urethane
shop,
we
had
assembly
lines
so
when
you're
creating
this
Factory,
you
know
everything's
not
in
in
open
open
shift
right.
It
has
to
be
that
those
ecosystems,
those
Factory
Parts
brought
in
there
to
to
give
the
whole
software
Factory
right.
C
B
And
together,
I
really
think
we've
got
a
great
joint
solution
for
our
clients.
A
Paul,
just
briefly,
if
we
still
have
some
minutes
left
regarding
deployment
options
in
your
experience,
which
is
the
main
the
best
way
to
deploy
your
components
just
on
big
installations
on
openshift
HUB,
managing
all
the
different
clusters
opposite
cluster
around
could
be
made
I'm
thinking
about
the
multi-cloud
situation,
context
or
just
having
a
small
light
installation
for
every
cluster
operation.
Cluster
a
company
is
delivering
kept
in
sync
in
some
way.
I
don't
know
if
this
question
doesn't
make
any
sense.
Oh.
B
B
All
being
you
know,
protected
by
firewall
from
OSS
malware
and
look
I
know
you
guys
go
to
clients
where
not
all
their
applications
are
on
open
shift.
Eventually,
we
would
like
them
to
get
there,
but
we're
also
going
to
be
able
to
provide
security
and
support
for
those
applications
that
are
outside
of
you
know
the
open
shift,
software
Factory
and
pipeline.
B
So
you
know
you
can
get
into
the
architectural
describe
discussions
around
how
many
applications
you
know
more.
The
more
important
questions
are
how
many
applications,
how
many
scans
are
you
doing?
B
B
That's
not
a
hot,
that's,
not
a
lot
of
heavy
lifting
right.
So
when
we
we
get
those
hashes
we're
pushing
those
back
to
our
hosted
data
service
right
where
our
data
catalog
is,
and
that's
where
all
the
the
crunching
and
the
work
goes.
So
it's
a
highly
scalable
solution.
I
mean
we've
got
you
know,
clients
doing
thousands
of
applications
in
an
instance
of
life
cycle.
A
So
still
two
minutes
left
it's
probably
we
can
give
some
minutes
back
to
Paul
and
I,
don't
know
if
it
will
be
the
start
of
your
day.
You're
coming
back
to
your
to
relax,
some
means
more
some
hours
more
before.
B
Get
up
early,
this
is
no
problem
in
fact,
really
excited
I,
I
I,
believe
in
this
solution.
I
worked
with
a
gentleman
Bill
Benson.
He
has
since
left
the
red
hat,
but
you
guys
might
be
familiar
with.
D
Them
oh
yeah
I
used
to
work
with
BL
almost
every
every
week
on
those
topics
and
actually
I'm
gonna
be
picking
up
on
those
topics.
So
I
might
reach
out
to
you.
B
Later
on
would
would
love
to
discuss
any
time.
I
I
do
have
some
colleagues
across
the
pond
on
your
side
that
we
can
connect
you
with.
You
know
where,
where
maybe
I
don't
have
to
get
up
at
four
A.M,
but
but
sure
I
mean
look,
look
forward
to
the
the
partnership,
the
relationship
we
do
have
an
advanced
partner
ship
arrangement
with
you
guys
so
and
I
think
all
the
the
business
check
marks
are
there
and
aligned
and
again
I
I
believe
in
this
solution.
B
I
believe
in
the
modern
software,
Factory
and
I
believe
that
you
know
basing
it
on
you
know.
Containerization
and
and
openshift
is,
is
a
great
way
to
go
and
quickly
get
clients
there
to
Dev
suck
cops
cool.
A
Okay,
thanks
a
lot
really
and
thanks
Jafar
and
Jan
for
joining
as
a
co-host
and
Paul
I
think
we
can
recommend
soon
as
soon
as
we
do
have
some
advance
in
this
very
interesting
topic.
So
we
can
host
you
again
for
all
attendees,
let's
meet
in
two
weeks
again
coffee
break
on
Wednesday,
10
a.m
or
9
A.M.
If
you
stay
in
the
UK
so
having
a
great
day
and
let's
see
soon
great.