►
Description
Welcome to the Secure Cloud Cast!
Here you can find our monthly show focused on all things security, cloud native, and open source projects. Today we are discussing the following:
- OpenSSL vulnerability
- Red Hat Community Patterns (What you need to know)
- Advanced Cluster Security roadmap update
And today, we will have Bill Bensing on our show. Bill loves to build things that build things. This includes software, people, engineering teams, technology organization, or companies. He is the perfect guest to discuss building compliance and governance into your cloud and container adoption strategy.
A
A
B
B
Was
gonna
hand
it
off
to
you
thanks
again
for
joining
if
you
want
to
get
more
notifications,
hit
the
little
subscribe
button
and
the
bell
again,
like
I,
said
the
third
Tuesday
of
every
month
at
2
p.m.
Eastern,
today
we
have
a
couple
updates
for
you
and
we're
joined
by
the
wonderful
Bill
Benson,
so
without
further
Ado
I
think
we
should
get
any
updates
right.
Kim,
yeah.
B
So
there
was,
since
it's
been
a
month
and
a
half
since
we
talked
last,
there
was
a
big
vulnerability
that
came
out
the
open,
SSL
vulnerability.
It
was
handled
very
well
for
those
of
you,
the
security
world
that
are
paying
attention.
It
was
notified,
every
big
cloud
provider
put
out
their
statement
and
then
it
was
updated
with
a
fix
on
November
1st.
So
if
you
have
open
SSL,
3.0.5
or
6
update
2.7
in
order
to
get
those
patches,
it
does
not
affect
any
of
the
previous
versions.
B
So
you
have
open
SL1,
you're,
okay,
but
yeah.
It's
a
pretty
big
one.
It
was
a
high
AI
vulnerability
about
a
7.8
and
it
would
have
caused
within
on
with
a
malicious
certificate.
It
would
have
brought
down
servers
if
you
kept
getting
ping
so
stay
check
out
that
one
and
if
you
want
ACS,
does
have
a
policy
for
it
specifically,
so
you
can
use
that
to
identify
your
workloads,
two
more
things.
B
One
I
want
to
talk
about
on
a
shirt
bill
can
get
into
this
too
when
he
comes
on,
is
Red
Hat
Community
invalidated
patterns.
So
we
have
a
community
palette,
Community
pattern
for
the
secure
supply
chain,
they're
very
interesting,
I'll
post
the
link
in
the
chat
right
after
this,
but
really
Community
patterns
at
Red
Hat
have
a
list
of
requirements,
things
that
must
happen,
things
that
should
happen,
things
that
can
or
are
nice
to
have
requirements.
Things
like
they
should
be
available.
It
doesn't
matter
what
your
Hardware
is.
You
should
be
able
to
run
it.
B
So
it's
very
useful
if
you
want
to
check
out
patterns
that
we've
used
in
community
versions
and
production
which
are
called
validated
patterns.
If
you
want
to
get
into
things
like
secure
supply
chain
or
git
Ops,
it's
definitely
worth
checking
out
and
I'll
drop
that
in
the
chat
I'm
looking
forward.
This
cure
supply
chain,
I
believe,
is
only
a
community
pattern
right
now,
but
we're
looking
forward
to
it
being
a
validated
pattern
very
soon
and
then
the
last
thing
Advanced
cluster
security
is
going
to
be
updating
to
3.73.
B
B
B
C
A
C
C
A
So,
actually,
moving
from
energy.
So
my
background
here
at
Red
Hat
is
I
work
at
the
North
American
public
services,
I
focus
with
our
government
customers
moving
actually
over
to
our
Global
organization,
our
customer
success
office
of
technology
to
focus
on
application
delivery
globally.
So
a
lot
of
what
I
do
is
work
with
our
highly
regulated
organizations,
whether
it's
Banks,
Insurance
or
nation
states,
whether
it's,
the
U.S
and
or
our
Allied
nation
states
around.
How
do
we
better
build
and
deliver
software?
A
We
talk
about
security
and
compliance
like
a
lot
of
those
words
of
buzzwords.
But
how
do
we
do
it
in
a
way
that
we're
pulling,
for
example,
like
the
hands
of
people
on
the
middle?
How
do
we
make
it
effective
and
efficient
because
the
reality
in
most
Industries
a
lot
of
it's
theater
and
people
really
starting
to
talk
about
it?
But
then
there's
also
like
okay,
if
it's
theater,
how
do
we
actually
address
this
and
solve
that
problem?
A
B
Okay,
we
actually
recently
had
a
conversation
talking
about
how
security
and
compliance
can
be
an
enabler
for
bigger
companies
and
sort
of
a
hindrance
for
smaller
companies.
There's
a
point
at
which
at
scale
it
starts
to
become
extremely
useful.
I
know.
Kim.
You
had
a
bunch
of
questions.
You
want
to
ask
them
so
I
don't
want
to
take
over.
You
got
to
kick
it
off
this
time.
Okay,.
A
So,
security
compliance
in
government-
let's
get
like
it,
gets
a
pistonology
here
again,
they're
all
three
different.
Although
a
lot
of
organizations
try
to
use
those
words
interchangeably,
I'll,
some
put
governance
to
the
right
hand,
side
around
that
right
now
and
talk
about
security
versus
compliance.
Let's
just
face
it,
they're
different
they're,
not
the
same
thing
it's
and
and
to
explain
the
difference
and
like
this
they
a
lot
of
people.
Listen
to
like
oh
I,
know
the
difference,
but
have
you
asked
yourself?
A
Could
you
explain
this
to
a
10
year
old
child
and
I
picked
10
year
old
as
an
arbitrary
number
like?
How
could
you
do
this-
and
this
is
part
of
my
as
I-
was
writing
the
book?
Investments
unlimited,
you
know
part
of
it
was
like
how
do
I
write
this
and
explain
it
to
somebody.
That's
like
a
non-technical-
and
you
know
an
independent
third
party.
So
as
we
think
about
security
and
compliance,
we
need
to
acknowledge
the
difference
that
security
is
how
we
protect
from
an
adversary
and
compliance
is.
A
A
I
think
we
need
to
inside.
Most
organizations
take
a
step
back
because
everybody
does
psychops.
The
buzzwords
like
I
know
we'll
talk
about
some
of
the
stuff
here,
but
everybody's
like
jumping
to
the
latest
new
tool
and
greatest
thing
it's
like
hold
on.
Let's
take
a
step
back
and
think
about.
You
know
everybody's
the
people
in
process
thing
organizationally.
What
does
it
mean
to
focus?
Have
a
security
and
a
tactical
approach
to
security
and
a
tactical
approach
to
compliance,
yeah,
yeah
and.
B
So
when
I
think
about
compliance,
because
when
you
get
into
these
bigger
organizations,
you
have
different
compliance
standards
across
different
teams
now
and
so
as
you're,
if
you're
a
CSO
or
a
CTO,
or
something
like
that.
How
do
you
to
make
sure
that
each
group
is
following
it
that
you
have
maybe
some
reproducibility
across
these
organizations
right
or
do
they
tend
to
work
in
silos
and
then
they're
all
reporting
up
and
because
because
then
you
find
like
when
teams
move
now,
it
becomes
a
little
bit
more
hectic
right.
A
I,
like
you,
said,
I'm
trying
to
dig
data
up
this
but
Mike
when
I
put
it
I
bet,
you
say:
there's
mostly.
Standards
are
different
and
I'll
get
back
to
some
of
my
background.
It's
compositional
what
you
find
is
certain
controls
are
more
applicable
to
other
teams
than
than
you
know,
teammate
over
Team
B,
and
so
what
you
find
is
there's
really
a
base
set
of
compliance
and
security
expectations
that
apply
to
everybody.
A
But
then,
as
you
go
to
the
style,
silos
and
the
different
teams,
they
have
additional
ones
that
may
be
used
by
a
couple.
Other
teams,
and
not
by
some,
are
required
by
Summer
of
the
teams,
but
it
comes
to
a
compositional
phase,
so
I
like
where
you're
going
about
that
and
you're
talking
about
like
the
csos,
and
how
do
you
manage
it?
It's
a
compositional
approach.
What
you
want
to
think
about-
and
this
is
where
I
have
something
about
the
synthesis
versus
analytics
and
we'll
get
too
geeky
here
on
this
one.
A
But
as
you
start
looking
at
it,
how
do
you
bring
a
composable
aspect
to
compliance
in
your
organization?
How
do
you
chunk
and
logically
chunk
together
compliance
controls,
whether
it's
just
one
controller
set
of
controls
and
provide
context
for
how
that's
applied
and
I?
Think
that's
where
the
security
and
compliance
organization
come
in
is
understanding
how
to
provide
that
context
to
the
team
and
say:
okay,
contextually,
here's
what
we
need
to
achieve,
and
now
the
team
on
the
ground.
The
technical
team
will
Implement
that-
and
this
is
where
people
talk
about.
A
If
you
heard
on
three
lines
of
defense
and
stuff
like
that,
we'll
get
into
first
and
second
line,
but
that's
the
aspect
there
and
like
that's
how
you
can
then
manage
the
compliance
system
and
I'll
say
that,
broadly
speaking,
but
this
goes
to
governance,
your
governance
approach
is
that
so
what
do
we
say?
We're
going
to
do?
How
are
we
validating
we're,
saying
we're
going
to
do
it
and
then
how
do
we
make
an
objective
for
an
independent
third
party
to
come?
A
B
Yeah,
it
did
one
of
the
other
challenges.
I
find
is.
How
do
you
actually
Implement
changes
too,
because
there's
compliance
and
then
you
maybe
have
a
non-compliant
cluster
or
kubernetes
cluster,
or
something
like
that?
If
these
teams
are
separate,
how
would
you
go
about
bringing
it
into
compliance
like?
Is
this
because
the
teams
are
separate
and
let's
say
you
have
the
operational
team,
that's
managing
the
Clusters.
Do
they
interact?
Do
you
slowly
make
changes
over
releases?
Do
you
like
heart?
A
B
A
It's
all
this
all
comes
the
risk
mitigation,
so
I'll
go
red,
green
black
I'm
gonna
talk
about
red
green
black
here,
but
my
number
one
rules
never
break
the
build
unless
there's
there's
very
few
times
that
you
want
to
break
the
build
and
never
go
to
production
and
the
thing
about
compliance
is
you're.
Talking
about
like
how
do
we
manage
this?
It's
about
visibility
and
that's
where
I'm
gonna
go
into
red,
green
and
black,
because
when
people
say
Well
they're
not
compliant,
what
does
that
mean
a
lot
of
times?
A
It's
like
I'll
use
the
color
red
Red's,
okay,
I
have
a
control
and
I
have
a
way
of
measuring
it,
but
I'm
not
meeting
the
expectation
of
that
control
right.
So
green
is
like
okay,
I'm
meeting
the
expectation,
but
there's
black
like
a
big
black
hole
and
so
I
use
the
color
black.
It's
like
I
have
a
control,
do
I
even
know
if
it
applies,
let
alone
in
my
meeting
that
control
and
what
you
tend
to
find
in
that
is
funny
as
we're
doing.
A
A
A
It
puts
a
power
in
the
decision,
Maker's,
Head
Hands,
to
say,
okay
I'm,
going
to
make
a
risk
decision
whether
to
go
or
not
go
or
whatever
it
may
be,
and
that's
really
when
you
want
to
get
to
because,
like
we
think
about
governance
theater
a
lot
of
it
is
just
you
know:
hey
we're
fine
until
you
have
the
next
big
whatever
it
is
log
for
Shell
next
big
break,
and
then
people
are
just
like.
Oh
yeah,
we
weren't
as
really
good
as
we
thought
we
were
yeah.
A
C
Think
that's
really
interesting
about
treating
it
like
a
feature.
I
never
thought
about
that
before,
because,
if
you
think
about
it,
anyone
that
uses
your
software
right
or
your
applications,
anyone
that
does
it
is
a
common
expectation,
not
necessarily
that
you
are
compliant,
but
that
you
are
secure
right
and
I.
Think
people
have
become
more
aware
of
that
in
general.
As
you
know,
end
users
and
I
was
just
curious.
What
you
thought
about
that.
A
No
I
I
am
actively
dropping
companies
when
I
get
my
notice.
I
haven't
noticed
into
it.
That
tells
me
when
things
have
been
compromised
and
even
got
down
to
the
fact
that
I
have
unique
passwords,
that
contracts
back
to
things
and
I
have
certain
new
things
and
if
my
stuff
becomes
compromised
by
a
company
I
ditch
that
product
for
a
different
vendor.
A
Also
when
it
comes
down
to
that,
like
you
think
about
secure
the
stuff
when
I
put
my
financial
stuff
in
healthcare
like
that's,
yes,
I
need
to
be
able
to
use
it
to
my
trade
or
transfer
my
money,
but
like
at
the
end
of
the
day.
I,
you
know,
don't
want
my
information
getting
sold.
It's
like
that's
a
feature.
That's
an
expectation.
A
I
have
of
the
organization
is
to
protect
that,
because,
at
the
end
of
the
day,
if
they
get
a
hold
of
my
bank
account
numbers,
you
know
bam,
zero
dollars
and
so
like
that
is
you
know
that
that
right
there
and
you
think
about
future.
It's
trust
and
trust
is
a
feature
of
software
and
how
do
I
trust
it?
You
know.
Trust
can
be
a
very
wobbly
thing,
but
I
think
in
the
form
of
a
feature
when
I
think
like
putting
about
a
feature
is
a
feature
is
impaired.
A
It
is
empirical
the
feature
should
be
empirical.
It
should
be
very
black
and
white,
it
does
or
it
does
not
operate.
And
if
you
start
bringing
that
empirical
thinking
to
compliance
and
security,
then
you
get
very
declarative
and
explicit
around
what
is
isn't
compliant
and
insecure
and
that
actually
solves
a
big
problem.
In
the
organization
of
like
as
I
go
to
get
my
compliance
or
security.
You
know
outcome
evaluated,
it's
less
about
Canon,
Mike,
telling
me
it
is
or
isn't
secure,
and
it's
about
human
mic,
pointing
to
the
explicit
evidence
to
say
this.
B
Cool
makes
sense,
I
want
to
bring
it
back
a
little
bit
to
kubernetes,
and
this
is
kind
of
a
two-parter
question,
first,
one
being
just
in
general:
Maybe,
not
kubernetes.
Maybe
it's
just
containers
virtual
machines
in
general.
But
what
do
you
see
as
the
biggest
challenges
between
you
know?
Let's
say
getting
an
environment,
that's
out
of
compliance
into
compliance,
doing
it
across
a
larger
organization
and
then
the
second
part
is:
what
did
you
see
that
relates
to
kubernetes
the
dev
secops
movement
and
just
sort
of
the
adoption
over
the
last?
B
A
Yeah,
so
the
challenge
is
like
first
off
just
being
explicit
about
what
it
means
to
be
secure
and
compliant.
First
off:
let's
go
back
to
what
controls
apply
to
me
and
the
context
for
why
these
controls
matter
to
the
organization
and
whether
me
as
an
operations
individual
or
as
a
developer,
that
right
there
is
establish
that
context
and
those
people
do
it
they'll
do
it,
then.
A
The
second
part
is
like
okay
I
talk
about
the
compliance,
but
then
what's
the
process
to
automate
that
evaluation
or
the
the
rectification
of
the
compliance
aspect
that
becomes
very
there's
more
than
100
there's
more
than
one
way
to
do
it.
So
how
do
you
decide
on
the
one
way
and
then
sort
of
the
continuous
monitoring
of
that?
How
I
continually
evaluate
that
it's
there
and
I?
Think
as
you
start
about
the
challenges
getting
there,
that's
sort
of
like
the
basic
approach,
but
the
problem
is
people
have
kubernetes,
they
have
AKs
at
eks.
A
They
have
open
shift,
they
have
virtual
machines,
not
just
VM
and
VMware
and
different
type
of
maybe
it's
just
something
through
AWS
or
or
Google,
but
it's
also
different
versions,
and
so
this
is
the
variability
of
what
you
have
to
secure
and
ensure
as
compliance
to
your
control
goals.
That
is
the
biggest
issue
like
when
you
look
at
like
sort
of
traditional
operations
management.
This
is
where
the
idea
of
Six
Sigma
came
from
like
variability
is
what
drives
the
risk
and
negative
outcome.
It's
the
idea
of
six
sigmas.
How
do
you
like?
A
What's
the
trace,
cost
trade-off
to
reducing
variability
above
two
or
three
sigma,
and
so
a
lot
of
people
don't
focus
on
this
is
where
I
pull
the
technology.
Look
at
the
people
who
process
is
what
are
we
doing
to
reduce
the
variability
of
our
environments
and
because,
once
I
reduce
that
variability
now,
I
can
have
a
standard
way
for
ensuring
you
know
well,
an
open
shift
or
secure
and
compliant
and
I.
Don't
have
to
worry
about
all
these
other
xks
or
all
these
different
versions.
And
then
you
know
you
start
from
there.
A
So
yeah
that
becomes
I
mean
that's
that's
the
biggest
problem
and
a
lot
of
that
is
like
that's,
not
a
technical
problem.
Let's
be
honest,
that
I
mean
that's
really
at
the
end
of
the
organization
coalescing
around
saying
this
is
what
we're
going
to
stick
to
and
agreeing
to
it
and
marching
towards
that.
That's
I,
don't
say
it's
simple,
but
the
human
part
of
it
is
always
the
more
complex
part.
B
Yeah
no
kidding
I've
had
prior
to
Red
Hat
I
had
some
previous
experience
with,
let's
say
a
couple:
different
Industries
and
one
of
the
common
themes
was
containers
got
adopted
because
it
was
very
simple
to
package
and
manage
your
applications,
but
managing
managing
them
in
different
environments
was,
let's
say,
not
necessarily
standardized
at
the
time.
So
you
had
different
teams.
The
data
science
team
was
doing
something
different
working
with
different
data.
B
Then
you
had
the
payment
team
that
had
a
lot
more
restrictions
on
how
they
were
managing
and
doing
kubernetes
and
managing
kubernetes,
and
the
operations
team
was
looking
at
like
how
do
like.
We
can't
manage
you
know
eight
different
environments.
We
need
to
sort
of
bring
this
together,
but
then
each
team
had
their
had
their
requirements,
and
so
it's
like,
how
do
you
push
back
on
the
data
science
team
to
say:
hey,
you
guys
have
to
come
into
this
environment
in
order
for
us
to
scale
efficiently
right.
B
A
I
find
that
there
and
actually
so
this
is
I
love
the
SRE
book,
I
love
SRE,
but
like
I'm,
probably
the
biggest
advocate
for
things
like
kubernetes
and
SRE.
That
tells
people
not
to
use
kubernetes
and
SRE.
So
I'll
be
very
careful
about
that,
but,
like
it
sounds
really
counterintuitive
but
chapter
seven.
So
what
you're
talking
about
you
think
about
we're
sort
of
where
kubernetes
came
from
and
it's
history,
Borg
and
Google.
All
these
people
was
like
these
individual
stacks
of
technology
and
sort
of.
A
Like
you
hear
in
the
narrative,
you
read
chapter
seven:
it
talks
about
basically
Google
hit
a
plateau
of
automation.
They
couldn't
automate
anymore
to
be
any
more
effective,
efficient,
fundamentally
and
I'm
paraphrasing
here,
and
so
what
happens?
They
had
to
think
of
a
new
way
of
working
and
so
Mike
as
you're
talking
about
like
you
bring
people
together.
All
these
different
things,
that's
where
sort
of
board
came
from.
A
This
is
the
standard
this
Warehouse
size
data
center
to
where
you
get
away
from
individual
teams,
sort
of
operating
around
Tech
stacks
and
you
start
reducing
the
variability.
So
you
have
the
container
in
this
orchestrated.
So
it
didn't
matter
what
the
underlying,
for
example
operating
system
was.
Is
you
you
built
to
a
higher
level
abstraction,
which
was
that
container
and
to
your
point
right
that
right
there
that
that
change
in
Behavior
drives
the
change
in
technology
decisions
as
well,
and
so,
as
you
saw
that
in
the
in
a
lot
of
other
companies
are
seeing.
A
This
is
too
like
and
I
look
at
the
history.
That's
why
I
like
the
SRE
book,
because
it's
Google
telling
the
world
about
how
it
messed
up
and
how
it
made
better
on
its
vessels
and
so
like,
yes
like
seeing
that
all
over
the
place,
because
your
point
it's
like
well
I,
got
committed.
I
got
all
this
stuff.
Now
how
do
I
manage
it?
The
answer
is
you
can't
don't
ask?
How
do
I
meant?
How
do
I
manage
this?
This
highly
variable
environment.
A
Ask
the
question:
what
am
I
going
to
do
to
reduce
the
variability
of
my
environment?
A
lot
of
people?
Don't
ask
that
question
and
then
you
point
that
out
they
just
they'll
March,
all
the
way
through
and
they'll,
be
like
yes,
I'm
gonna
go
figure
out
how
to
do
101
plus
things,
and
that's
not
how
you
scale.
If
you
look
at
how
the
things
Facebook
app
with
Netflix,
was
it
Amazon
Google,
they
scale
they
scale
by
reducing
variability.
A
They
have
anybody,
not
just
the
things
the
the
non-faying
companies
that
have
figured
out
how
to
scale
they've
identified
the
area
where
they
reduce
variability,
but
they've
also
identified
where
they
allow
variability
to
happen,
and
it
tends
to
be
in
the
area
where
it's
around
the
customer
requirements
and
the
focus
on
the
software
to
build
for
the
customer,
not
sort
of
the
standardized
under
the
hood.
You
know
stuff
that
you
know
a
small
sense
of
the
organization
should
be
worried
about
yeah.
B
They're
more
in
a
reactionary
mode
to
the
customer
and
trying
to
get
things
to
Market
or
developing
new
features,
instead
of
actually
consolidating
which
will
help
them
accelerate
in
the
future.
It's
also
kind
of
aligns
with
I
I've,
seen
some
statistics
on
cost
moving
to
kubernetes
and
the
first
two
years
are
significantly
more
than
they've
they're
expected,
but
then,
after
as
we
start
to
see
them
mature,
the
costs
are
significantly
less
but
I.
Remember
when
I
first
started
pitching
kubernetes
there
was
oh.
This
is
going
to
reduce
costs.
B
A
You've
nailed
it
so
I
read
a
book
audiobook
recommendation
beyond
the
goal
by
Ilia
golden
rat,
so
he's
the
one
who
wrote
the
book,
The
Goal,
but
in
beyond
the
goal
he
has
four
questions
to
technology
adoption
so
Mike,
where
you're
going
to
I'll,
give
you
the
four
questions.
One
was
the
power
of
the
new
technology,
two:
what
are
the
limitations
of
diminishes?
But
three
and
four
what
the
old
rules
you
operate
by
and
what
are
the
new
rules
and
he
points
out.
A
Mike
is
your
point
in
there
and
he
talks
about
black
and
dead
or
Black
and
Decker
and
Manufacturing
resource
planning
of
our
P
systems
back
in
the
60s,
where
people
who
buy
kubernetes
like
they
may
not
see
that
they
have
to
change
the
way
they
operate
and
you
have
a
large
upfront
cost.
But
once
you
change
the
new
rules
of
operations,
then
over
time
your
total
cost
of
ownership
goes
down
significantly
and
to
your
point,
like
Mike,
as
you
pointed
out,
it's
like
yeah.
A
You
can't
just
adopt
technology
for
Technology's
sake
and
all
technology
is
an
implementation
of
a
human
system.
And
if
you
look
at
the
autonomy
that
kubernetes
brain
because
of
predecessor
Borg
and
that's
what
brought
autonomy
in
the
infrastructure,
that's
what
you
want
to
bring
to
organization
and
if
you're
not
willing
to
adopt
the
new
rules
of
autonomy
in
the
organization,
then
you
really
need
to
question
some
of
those
technical
decisions
and
so
yeah
so
like,
as
you
point
out
like
yeah,
it
can
increase
in
the
short
term,
because
remember,
there's,
there's
warning
hurdles.
A
There's
Investments!
There's
changes
like
you
know
as
much
as
we
are
very
steeped
in
kubernetes,
we
meet
a
lot
of
customers
that,
like
a
lot
of
them
that
barely
get
to
touch
a
container
and
so
yeah
there's
a
there's,
a
there's,
a
whole
world
of
growth.
That
happened
and
that
that
doesn't
happen
overnight
and
it
doesn't.
It
doesn't
happen
as
cheap
as
people
like
to
think
it
does.
A
B
C
A
A
So
I
want
to
preface
this.
My
formal
background
is
in
operations
and
Supply
Chain
management.
So
I
was
that
person
that,
like
was
Shadow
I.T
because
I
like
building
software
and
I
built
it
around
these.
These
concerns
not
software
supply
chain,
but
supply
chain
and
procurement.
I
got
myself
into
the
tech
world
and
that
sort
of
where
I
came
from
the
day
and
I
say
look
at
Salsa
and
you
look
at
Salsa
specific
within
his
website.
A
Basically
says:
hey
we're
here
to
you
know
it
is
a
response
to
something
like
solar
Woods
ensure
that
the
developer
enter
the
build
system
is
not
a
is,
is
has
a
low
probability
of
being
exploited.
That's
what
salsa
right
now
is
formulated
around
and
so
I
think
a
solid
software
Supply
Team
Management.
This
is
where
I
give
a
lot
of
the
unpopular
opinion
that
what
we're
doing
around
supply
chain
is
really
on
the
value
chain,
because
it's
not
focused
on
I
mean
the
difference
between
software
and
value
chain.
All
right
software
supply
chain.
A
The
supply
chain
is
everything
to
get
from
raw
materials
to
an
end
product
and
includes
all
the
actors
in
the
supply
chain.
Then
there's
the
value
chance,
what
happens
and
what
you
do
internally
and
what
I
see
happening.
What
I
fear
is
a
lot
of
people
using
the
word
software
supply
chain
to
talk
about
the
value
chain
of
the
things
that
happen
inside
the
four
walls
of
a
company,
and
this
is
where
I
get
them
to
be
careful.
A
It's
also
because
it
does
Focus
it's
as
you
start
seeing
what
they're
trying
to
do
with
it
is
it's
like
okay,
how
do
we
make
visible
the
stuff
that's
happening
in
another
supply
chain
partner
such
that
we
have
the
information
to
do
that,
but
yeah
as
I.
Look
at
software
supply
chain
like
if
you
go
to
the
council,
Supply
Chain
management.
They
specifically
don't
Define.
A
What
supply
chain
is,
but
they
Define
the
Act
of
managing
supply
chain
and
they
Define
the
iteration
interactions
between
supply
chain
actors
and
that's
very
key,
because
it's
supply
chain
changes.
But
it's
the
idea
of
how
do
you
manage
quality
at
a
risk
across
these
series
of
actors
and
I?
Think
it's
very
key,
as
we
think
about
software
supply
chain
and
like
Michael,
you
talked
about
like
we
have.
We
have
the
validated
patterns
media
patterns
for
software
supply
chain
and,
like
that's,
some
cool
stuff.
A
Looking
at
with,
what's
going
on
there
with
techcon
change,
you
know
things
like
in
total,
like
a
lot
of
these
things
are
coming
around,
but
what
I'd
like
to
get
to
do
across
the
leaders?
Organizationally
is
you
need
to
start
thinking
about
because,
let's
face
it,
open
source
is
everywhere
at
even
the
products
you
buy.
A
How
conformance
could
be
compliance
and
security,
but
that's
where
I
try
to
push
the
concept
of
software
supply
chain,
because
that
is
that
that's
addressing
the
holistic
problem
and
then
some
of
these
other
things
like
sauce
and
whatnot
like
they're,
great
and
then
they'll,
be
afraid,
like
all
the
stuff
is
going
to
grow
out
over
time,
I
believe
to
Encompass
this.
But
of
course,
I
get
a
bit
on
my
high
horse.
Coming
from
the
background,
I'm.
C
A
A
Because
there's
you
know
we
have,
you
know,
there's
one
percent
of
companies
that
do
really
well
and
there's
99
that
I'll
just
call
the
average,
which
99
being
average,
is
a
really
weird
statistic.
But
at
the
end
of
the
day
they
need
a
very
pragmatic
approach.
And
so
how
could
we
be
very
pragmatic
about
this?
And
you
know
the
things
like
response:
Vex
software
supply
chain,
salsa
secure
software
delivery
in
this
ssdf?
A
How
do
we
make
that,
such
that
it's
it's
you
know,
I
look
at
math
like
math
over
2000
years
has
become
standardized.
We
do
know
we
throughout
the
world.
We
do
math
the
same.
Why
can't
we
do
software
like
we
do
math
and
that's
sort
of
like
sort
of
a
you
know,
personal
thing
of
mine,
it's
like
how
do
you
do
that
and,
like
that's
a
big
problem
to
solve
doing
software
is
a
big
ambiguity,
is
a
big
problem,
but
how
do
we
do
software?
This
thing.
B
And
finding
the
tolerance
is
very
important.
Coming
from
an
engineering
background,
the
lower
the
tolerance
or
the
more
specific,
the
part
or
wherever
you're,
coming
from
the
more
you're
going
to
have
things
tossed
away
the
higher
the
cost
is
Upstream
to
get
that
part,
and
you
have
to
make
sure
that
one,
the
person
that's
designing.
Let's
say
this
package
or
operating
system
or
whatever
it
is,
has
the
right
people
there
that
know
how
to
do
it
right.
B
So
it's
not
one
piece
of
the
puzzle:
I
think
that
can
get
solved
if
you're
looking
at
supply
chain
and
you
have
a
tolerance
for
let's
say
it
has
to
be
quality
contributions.
It
has
to
be
signed.
It
has
to
be
committed
and
all
that
stuff
at
all
parts.
Well,
then,
if
your
tolerance
goes
off
in
one
area,
then
your
end
product
is
technically
tainted
right.
So
it's
you
know.
How
do
we
find
that
balance
between
or
maybe,
if
there's
some
realistic
ideas
that
you
have
on
how
to
implement
it?
A
Well,
you
talked
about
tolerance,
yeah
I
was
talking
earlier
about
the
difference
between
software
and
hard
Goods.
If
you
go
to
hard
Goods
Manufacturing
everything
has
a
blueprint.
Everything
has
a
specification.
Ask
yourself:
where
is
the
blueprint
for
software
low
software
is
not
built
to
a
specifications
where
you
could
have
more
than
one
implementation.
Most
software
is
built.
There
is
no
specification,
it's
just
built.
People
consume
it.
So
my
to
your
point
like
how
do
we
ID
and
like
this
gets
back
like
this?
A
Is
where
I
try
to
you
know:
people
talk
about
hard
goods
and
software
manufacturing
using
a
lot
of
lean
terms
and
over,
like
you
know,
how
do
you
build
a
spec
like
what
you
tend
to
see
is
like
specs,
like
RSC
specs
tend
to
be
derived
from
an
implementation,
but
Mike
as
I
put
into
the
answer
is
like
how
do
we
push
more
towards
a
standard
specification
for
common
for
the
solutions
to
common
problems
like
that's
what
software
is
used
for?
We
use
a
lot
of
software
to
solve
the
common
problems.
A
We
don't
want
to
rewrite
other
software
for
and
so
I
would
almost
turn
on
its
head.
I
don't
want
to
answer
a
question
with
a
question,
but
at
the
end
of
the
day,
I'd
say
the
goal
is:
how
do
you
drive
specifications
such
that
Mike's
you're?
Talking
about
it
defines
tolerance
because
it
defines
expectations,
and
now
you
have
an
objective,
metric
or
measuring
stick
to
measure
somebody's
implementation
against
and
you're.
Not
just
asking
broad
questions
like.
Is
this
secure
compliance
you're
asking
very
declarative
questions?
B
If
that
makes
sense,
my
biggest
worry
with
the
software
supply
chain
is
who
creates
the
blueprint
and
who
evaluates
the
blueprint?
Is
it
up
to
whoever
is
consuming
the
software
to
do
the
evaluation?
Is
it
the
developers
of
the
software
to
make
sure
it's
up
to
specification
and
then
who's
holding
who
accountable
for
the
the
data?
In
let's
say,
an
s-bomb.
A
Well,
until
you
see
it
so
we
talk
about
standards
like
look
at
night
I'll
get
back
to
you,
know,
Aerospace
manufacturing
every
I
go
that
you
have
like
ANSI
standards
and
you
have
standards
for
bullets
and
for
nuts,
so,
like
literally,
anybody
can
make
a
bolt
or
not
as
long
it
needs
the
spec.
So
to
your
point,
where
we're
going
I
think
we
have
a
bit
of
a
sort
of
a
synthesis
that
happens
where
these
specifications
for
common
stuff
are
taken
over
by
a
standard
governing
body
and
so
like.
A
If
you
look
at
ANSI,
M3
type
build
a
a
three
millimeter,
those
type
of
things
like
there's
specs
out
there,
and
so
how
do
you
then?
Is
there
an
organization
that
then
takes
on
that
responsibility?
That
says,
let's
say
about
email
addresses,
here's
a
specification.
I
mean
we
have
RFC
stuff
out
there,
but
here's
a
specification
for
email
address
and
I'm
trying
to
be
more
assistant
because,
like
a
lot
of
our
Software
System
or
systems
of
systems
but
sort
of
where
you're
going
is
like,
then
you
talk
about
s-bombs.
Then
it
changed.
A
You
know
it's
like.
Okay
is
you're
bringing
another
dimension.
What
is
that?
What
is
the
quality
expectation?
Where
is
this
coming
from
the
s-bomb
brings
the
thing
it's
not
just
what's
in
here:
it's
also
where
is
it
coming
from
and
I
think
that
that,
even
though
we're
trying
to
get
to
that
with
some
of
the
information
today,
that's
bombs
that
becomes
a
big
thing.
It's
like
I
can
have
log4j,
but
the
log
for
Jay
was
it
forked
where'd
it
come
from.
A
This
is
where
I
get
back
to
software
supply
chain
like
the
supply
chain,
is
mapping
it's
an
exchange
of
goods
for
information,
and
so,
if
you
apply
to
the
software
as
an
exchange
of
software
for
information,
but
we
don't
have,
is
we
don't
have
that
information
flow?
That's
where,
like
things
like
s,
bomb
and
backs,
are
trying
to
get
to,
but
I
think
to
your
point,
that's
important,
but
we
don't
have
standard
mechanisms
for
communicating
and
the
formal
supply
chain
practices
have
built
standard
protocols
for
communicating
and
standard
domain
practices
as
well
like
I.
A
Don't
need
to
learn
a
vendor
tool
in,
for
example,
in
traditional
supply
chain
to
do
Supply,
Chain
management,
I
learned
the
domain
practice
of
supply
chain
and
then
I
can
utilize
n
plus
one
vendor
tools
to
do
what
I
do
to
achieve
I'll
stop
right.
There
I
think
I
might
go
down
a
little
bit
of
hold.
Does
that
make
sense?
Did
that
answer
your
question
or
just
go
to.
C
Do,
however,
I
wanted
to
ask
a
question
specifically
around
what
you
were
just
speaking
about
so
I'm
curious
as
we
talk
about
supply
chain,
I
feel
like
over
the
past.
You
know,
10
years,
we've
seen
at
least
10
years,
we've
seen
things
like
security
and
compliance
become
more
of
a
business.
You
know
value
type
of
thing,
so
it
matters
to
a
lot
of
different
departments
and
even
become
a
boardroom
problem
and
discussion
right.
C
A
No,
like
security
compliance
needs
to
be
an
organizational
problem.
I
think
most
organizations
have
been
highly
regulated
for
years.
Understand
this,
but
to
your
point
like,
and
it's
like
I'll
just
talk
about
like
solarwinds.
A
lot
of
this
came
I'm.
Not
just
solar
was
like
big
data
breaches
before
that.
But
what
you
see
there
is
a
lot
of.
It
is
like
it's
thieving
up,
the
technical
folks
to
figure
out,
but
no
this
is
a
business
problem.
A
A
You
have
to
be
together
as
business
enabled
by
technology
and
Technology
helping
to
drive
the
business,
and
so
as
you
look
at
that,
yes,
like
it,
has
to
be
a
business,
it
has
to
be
affordable
practice
in
the
company
that
Technical
and
non-technical
people
can
coalesce
around,
and
you
know
again,
you
know
a
lot
of
times.
Let's
just
be
real
like
it
wasn't.
I
want
to
say
it
was
ignored,
I'll
be
very
careful
about
that,
because
I
don't
believe
in
a
lot
of
companies.
A
It
was
ignored,
but
the
emphasis
put
on
it
wasn't
such
until
people
started
losing
revenue
and
started
getting
you
know.
Large
large
lawsuits
started
happening
at
the
end
of
the
day,
and
so
I
think
that
you
know
now
like
in
the
past
five
years,
like
it's
become
a
very
it's
become
a
business
problem
simply
becoming
because
it's
become
a
liability.
At
the
end
of
the
day,
it's
always
been
a
liability.
A
It's
just
like
in
the
hyper
technology
world-
and
this
is
awesome,
like
you
think,
about
the
I
called
like
in
2007,
was
like
a
shift
in
technology
that
became
mainly
consumer
driven,
was
learning
that
two
seven
and
after
we're
like
now
we're
starting
to
see
this
because
we're
still
really
relatively
new
in
our
technology
experiment
in
the
consumer
industry.
A
lot
of
people
like
you
know,
think
about
2000
2007
was
not
that
long
ago,
yeah
and
so
we're
learning
the
lessons
and
like
yeah,
and
so
now
people
are
learning
like
Yep.
This
has
to
be.
C
Of
the
day,
yeah
for
sure
and
I
think
too
something
you
touched
on
earlier
was
around
managing
risk.
You
know
we
have.
You,
know
security
that
are
going
in
and
managing
risk
from
down
to
the
practitioner,
all
the
way
to
I
think
the
organization
trying
to
figure
out
how
to
do
that
and
I
think
that
comes
down
to
to
you
know
secure
supply
chain
as
well.
So
it's
interesting
that
you
mentioned
that
earlier
around
risk
management
specifically
around
automation,
which
is
what
I
think
Mike
Foster
was
alluding
to.
C
A
A
But
how
are
they
achieving
these
secure,
compliant
outcomes
right,
adopting
more
and
more
stuff
adds
variability,
which
makes
it
essentially
or
makes
it
difference
between
accidental
and
Central
complexity
makes
it
accidentally
more
complex,
so
I'd
argue
what
you're
starting
to
see
right
now
and
some
of
the
stuff.
We
talk
about
about
the
automated
governance,
autonomous
governance
and
we
talk
about
automating
security
is
really
that
admission
like
okay,
there's
a
lot
of
tools
out
there
there's
a
tool
for
me
to
do
almost
anything.
A
I
need
these
days,
but
how
am
I
going
to
smartly
stitch
these
tools
together
or
bring
an
autonomous
approach
and
when
I
say
autonomous,
it's
not
AI.
It's
not
ml
I
go
back
to
was
a
chapter
seven
in
the
Google
book,
where
they
talk
about
autonomous
and
automation,
where
manual
automation
is
actually
the
manual
intervention
is
preferred
in
some
instance
to
automation,
but
judicious
automation
is
the
fundamental
basis
of
autonomous,
because
automation
itself
is
not
a
PSC
people
think
like
automate
everything.
A
Well,
no,
because
you
automation,
that's
you
you
can
try
to
do
that,
but,
like
then
you'd
have
to
manage
it.
The
question
is:
this
goes
to
variability.
If
you
automate
everything,
you
have
a
high
view
variable.
You
have
a
lot
of
stuff,
you're
automating.
Why
not
just
reduce
what
you're
augmenting
and
be
very
judicious,
and
so
cameras
are
going
to
this?
This
is
the
concept
of
autonomous
and
it's
in
a
two-way.
It's
like
autonomously.
A
How
do
I-
and
this
is
for
kubernetes-
like
look
at
the
kubernetes-
it's
autonomous
infrastructure
at
the
end
of
the
day,
I
declaratively
tell
it
what
I
want
to
do
and
it
doesn't
I,
don't
know
how
it
does
it.
I
just
say:
hey
do
this,
so
how
can?
How
can
I
do
that?
For
my
governance
and
security
such
that
I?
A
A
It's
the
inability
to
be
judicious
about
the
automation
that
has
affected
the
outcome
and
that
that's
not
a
technology
again
back
to
people
in
process,
and
this
is
where
I
like
to
push
towards
non-technical
leadership,
to
help
understand
this
stuff,
because
at
the
end
of
the
day,
I
get
a
background
on
togaf.
We'll
talk
about
business
architecture.
A
What
we're
talking
about
is
this
fundamental
business
process
and
building
and
validating
software
and
delivering
software
is
no
different
than
any
other
business
process,
such
as
inventory
management
manufacturing
operations,
and
once
you
start
to
approach
it
from
that
Pro.
That
mindset,
then
I
think
some
of
the
stuff
comes
in
comes
into
play
a
little
better
and
I.
You
know
basically
talk
about
the
explosion
of
tools.
I
I
use
this
term.
A
The
Erp
system
of
software
development,
like
you
look
at
like
the
late
80s
early
90s
like
er
pieces,
is
an
enterprise
resource
planning,
there's
a
bunch
of
independent
modules
that
people
had
to
stitch
together
like
that's,
where
a
lot
of
your
big
floors
came
from
right,
stitching
it
together.
Then
companies
like
sap
and
Oracle
just
started
buying
that
stuff
together
and
plugging
it
as
default
capabilities,
and
so
what
you're.
A
The
tools
exist
to
manage
the
business
of
software
and
the
and
the
operations,
but
it's
now
putting
it
together
in
such
an
autonomous
and
cohesive
way
that
it
represents
a
a
a
effective
business
process.
I
say
effective
first
before
efficient,
because
it's
very
hard
to
be
it's
very
hard
to
be
if
you're
efficient
before
you're
affected.
You
have
some
very
bad
outcomes
very.
B
A
I'm
gonna
I'm
gonna
hit
this
from
two
areas:
not
answering
them
and
answer
it:
yeah,
okay,
so
the
thing
about
s-bomb.
Actually,
the
ntia
put
a
thing
together:
around
s-bomb,
tooling,
I
recommend
everybody
to
do
and
I
can
find
the
link
here,
but
it
talks
about
software
to
create
s-bombs
software
to
ingest
s-bombs
and
software
to
transform
s-bombs,
and
this
is
very
key
because
a
lot
of
people
are
thinking
about
creating
it.
A
But
if
you
look
at
the
most
recent
memo
releases,
September
14th,
it
talks
about
the
government
ingesting
things
like
s-bombs
and
evaluating
them,
and
so
that's
what,
as
you
look
at
it
understand
the
capabilities
and
need
thrust
bomb
and
more
around
how
if
I
give
you
an
s-bomb?
What
are
you
going
to
do
with
it,
and
this
gets
back
to
the
broader
around
software
composition,
analysis
s-bomb
is
just
another
tool
for
software
composition,
analysis,
and
so
how
do
you
have
a
broader
software
composition?
Analysis
approaching
your
organization
now
getting
more
specific
about
that.
A
A
But
if
you
have
stuff
like
the
red
hat
partner
sonotype
and
what
I
like
about
sort
of
sonotypes
or
Nexus
lifecycle
process
is
it
allows
you
in
sort
of
in
this
in
this
one
tool
which
it
runs
on
openshift
by
an
operator
which
I
love
about
it,
because
the
Opera
and
frame
rate
reduces
the
total
cost
of
ownership?
When
you
do
this
type
of
stuff,
but
the
idea
is,
you
have
policies
in
there,
so
you
can
ingest
s-spom,
you
can
create
an
s
bomb.
A
It's
also
looking
at
software
composition
and
so
say,
for
example,
stuff
like
ACS
and
then
ask
bombs,
and
so
you
look
at
like
sonotype
looks
at
sort
of
that
that
that's
that
software
binary.
But
you
need
to
be
looking
at
things
like
other
layers
like
container
layers
or
VM
layers,
and
that's
for
something
like
you
can
ingest
those
s-bombers
with
the
apis
of
sonotype
and
get
a
copper
into
Viewpoint,
and
so
as
I
talk
about
those
different
tools.
Understand
there's
like
the
ability
to
create.
But
then
how
do
you
manage?
A
And
how
do
you
operationalize
the
S
found
from
a
compositional
perspective?
And
so
that's
why
it's
so
it's
a
hawks!
That's
one
to
sort
of
change
a
bit
of
that
question,
and
this
is
where
I'm
focusing
right
now,
because
there's
not
a
lot
of
pragmatic
advice
around
how
to
operationalize
this,
at
least
that
I've
seen
and
that's
where
I
want
to
push
towards,
because
everybody's
being
told
to
do
s-bombs.
A
A
But
what
happens
is
how
do
you
address
this
and
that's
the
question
you
have
to
ask
yourself
in
the
organization
instead
of
saying
what
software?
What
are
we
going
to
do
to
operationalize
this,
or
should
we
operationalize
this
and
I'll
stop
right
there,
because
some
people,
like,
oh,
you,
have
to
operationalize
it,
but
this
gets
back
to
risk
management
like
Mike.
Can
you
talk.
A
This
really
something
we
need
to
care
about.
Now,
of
course,
there's
gonna
be
somebody
out
there
screaming
yes,
but
you
as
a
risk
owner
of
the
business,
need
to
understand
that
I
think
that's
the
big
thing
on
the
non-technical
leadership.
What
does
this
mean
for
managing
my
brand,
my
identity
and
my
my
market
of
my
product.
B
B
So
hopefully
we
can
have
him
on
to
to
show
some
of
the
tooling
last
question
for
you
before
we
head
out
you're
on
the
ground,
with
a
ton
of
customers
medium
to
Big,
typically
and
like
you've
dealt
with
all
that
any
new
challenges
that
you
see
popping
up:
automation,
governance.
What
do
you
see
in
just
out
on
the
field?
Yeah.
A
So
you
notice,
like
the
automated
governance
and
automating
governance,
is
part
of
the
sdlc
is
becoming
a
big
thing.
I
I,
but
also
we
talk
about
s-bombs
procurement
of
software,
and
so
what
I'm
starting
to
see
is
I've
talked
to
some
big
organizations.
Even
smaller
I'm
like
when
you
look
at
the
office
of
s
b,
some
of
their
heads
are
procurement
like
okay.
How
do
we
start
procuring
open
source
and
I
say
that
in
quotes,
because
everybody's
been
using
open
source
and
somebody's
like
well,
how
do
you
procure
something?
That's
free!
A
Well,
if
you
look
at
the
Active
procurement,
it's
the
act
of
identifying
when
you
talk
about.
What's
your
specification,
what
do
we
need
to
build
or
buy
to
do
we
build
or
buy
it?
Then?
Where
do
we
get
it
from
and
then
once
we
get
it
and
how
do
we
validate
the
quality
and
like
procurements
at
a
Nexus
of
a
lot
of
the
supply
chain
activities
and
they
talk
about
inbound
and
outbound
Logistics
and
so
like?
A
There
is
a
whole
domain
around
I'll,
just
say
software
procurement
in
general,
that's
being
realized
and
reevaluated
in
real
time.
With
that
much
people
talking
about
it,
because
the
traditional
procurement
to
software
is
like,
let's
go
to
Microsoft,
let's
go
to
Red
Hat,
let's
go
to
another
and
just
buy
what
they
have,
and
it
was
the
transitive
property
of
trust
because
you
we
trust
that
you
are
good
at
what
you're
doing
we're
just
going
to
buy
it
and
you're
going
to
ask
some
questions
but
we're
going
to
stop
our
validation
there.
A
Things
like
solar
winds,
like
a
lot
of
that
transit
property
of
trust,
has
now
gone
out
of
the
window,
and
so
it's
now
like
okay,
we
trust
you
because
you're
in
business
you're
doing
this,
but
we
need
additional
proof,
and
so
we've
had
I've.
Had
people
determine
ask
me
like
one:
what
does
that
spot
mean
to
me?
How
do
we
deal
with
it?
Two
first
off
like
we
know,
a
lot
of
people
are
using
open
source.
So
how
do
I
evaluate
like
a
community?
How,
if
I
know,
there's
two
different
open
source
projects?
B
A
Elastic
IPO
happened
all
of
a
sudden
if
your
company
made
more
than
25
million
in
Revenue.
You
know
you
gotta
Pony
up
and
there's
a
lot
of
companies
that
got
caught
off
guard
by
that,
and
so,
at
the
end
of
the
day,
what
you're
starting
to
see,
is
sort
of
like
the
business
implications
like
licenses,
for
example,
if
you're
using
a
licensed
piece
of
software,
that
requires
you
to
publish
what
you've
created
by
using
it.
Let's
say:
you've
built
a
proprietary
system
and
that
comes
to
error.
A
Like
that's,
you
know,
that's
now,
big
implication
that
could
be.
You
could
basically
be
enforced
to
publish
something
that
gives
you
a
comparative
advantage
of
the
market.
So
now
you
have
the
non-technical
people
who
understand
the
risk
implementation
implementations,
not
just
from
security
vulnerabilities
but
other
aspects
of
business
such
as
IP
asking.
How
do
we
do
this
and
how
do
we
manage
it?
And
so,
like
I'll,
give
you
my
next
three
year
prediction
here
is
there's
going
to
be
like
s-bomb
is
driving
it,
but
there's
going
to
be
a
lot
more
talk
around.
A
How
do
you
procure
technology
in
a
new
way?
A
modern
way
throw
your
Buster
in
behind
it.
You
know,
leave
it
up,
leave
it
up
to
us
vendors
to
find
a
way
to
architect
it,
but
at
the
end
of
the
day,
what
that
you're
going
to
start
to
people
are
asking
the
questions
a
lot
of
these
large
and
small
organizations
asking
the
same
questions.
A
What
do
I
need
to
do
to
do
this,
because
at
the
end
of
the
day,
the
board
and
the
market
and
regulator
is
going
to
hold
responsible
and
they
know
that
they
need
to
they
they
basically
let
them
say
the
industry,
not
one
company
has
been
caught
off
guard
the
industry
writ
large
and
now
it's
time
to
sort
of
show
up
what
is
our
domain.
This
is
right.
Talk
about
software
Supply,
Chain
management.
What
is
the
domain
of
software
Supply?
Chain
management
look
like,
and
that
is
going
to
be
the
next
three
to
five
years.
A
Getting
more
specific
and
I
see
a
lot
of
people
asking
those
questions
and,
and
it
actually
I'll
be
honest,
like
some
of
the
people
ask
a
question
about
the
open
source
Community
I
was
like
hold
on
a
second
like
I'm
talking
to
a
non-technical
leader
like
you
know,
firstly,
I
was
taken
back
by
that.
I'm
like
this
is
awesome
like
first
off,
like
I.
Didn't
expect
this
from
you,
but
like
the
fact
that
you
understand
the
implications
in
your
business
like
that
shows,
you
have
strategic
for
thought
in
your
mind
and
I
love.
A
Obviously
you
know
like
if
you
want
to
be
safe,
get
a
Volvo
and
like
now,
you're
starting
to
see
software
companies
and
other
types
of
consumer
companies
around
the
software.
Thinking
in
that
Volvo
mindset
like
yes,
we
have
to
meet
minimum
levels,
but
how
do
we
just
be
a
secure
and
complaint
as
we
need?
Basically
because
we
want
it,
and
we
know
our
customers
need.
C
A
You
deal
like
I
would
love
like
you
know:
I'm
I'm.
You
know
we're
all
geekishly
into
this
because
of
our
background,
but,
like
I
said,
look
at
some
of
this
stuff
I'm,
just
like
I'm,
actually
starting
I'm,
changing
the
way
I
consume
products
and
services
based
upon
how
secure
I
can
I
I
can
I
can
see
how
a
company
is
yeah
like
and
like
even
my
investments.
My
investments
are
now
going
towards,
like
actually
who's
who's
leadership,
at
least
for
the
you
know.
The
public-facing
Market
discussions
who's
leading
this
thought.
A
A
So
then
they
put
the
people
asking
those
questions,
especially
in
public
forums
and
trying
to
learn
like
that's
key
and
like
it's
changing
at
least
how
I
view
my
consumption
and
also
I
view
my
view,
my
investments,
because,
as
we
go
for
the
next
10
to
15
years,
it's
going
to
be
key.
It's
gonna
be
critical.
We're
in
this
technology
has
become
a
Mainstay
of
the
consumer
society,
which
means
8
billion
people
are
at
risk,
are
at
opportunity
for
what
can
be
delivered.