►
From YouTube: CNCF SIG-Security Meeting - 2019-08-14
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
CNCF SIG-Security Meeting - 2019-08-14
A
C
A
D
A
So
ten
minutes
of
presentation,
I'm
gonna,
pad
your
estimate
on
discussion.
Given
you
know
especially
the
interest.
You
know
there
are
a
number
of
us
on
the
members
here
that
are
actually
in
fin,
serve
and
really
interested
in
and
that
so
we're
also
going
to
be
very
interested
in
so
that
context
sharing
for
non
sig
related
interests,
perfect.
A
A
Thank
You
Justin
all
right,
let's
go
ahead
and
get
started
because
I
do
think
that,
like
I
said
just
saying,
I
think
we're
gonna
get
into
some
interesting
discussions
and
then
we
have
some
ongoing
efforts
that
I'd
like
to
get
check-ins
to.
But
since
we've
been,
you
know
a
bit
sort
of
keeping
the
trains
running
and
you
know
working
on
our
work
focused
in
you
know
last
three
months
and
you
know
we're
beginning
just
to
restart
some
of
our
presentations.
I
went
on
they'll
make
sure
we
get
that
in
the
time
it
deserves
all
right.
A
A
F
G
This
is
Emily
Fox,
National,
Security
Agency
we
met,
or
we
talked
yesterday
about
the
six
security
day.
I've
updated
the
ticket
with
the
notes
from
that
meeting,
as
well
as
linked
in
the
Trello
board.
So
if
anybody's
interested
in
understanding
where
we're
at
and
what
things
are
going
on,
you
could
check
out
issue
I,
believe
it's
209
the
right
now
I'm
waiting
to
hear
back
from
Amy
and
Emily
ruff
concerning
website
content.
For
that
event,
that's
about
it
excellent.
F
H
Enough
hi
guys
this
is
Robin.
Now
this
is
my
first
meeting
so
yeah
I'm,
a
VPN
head
of
information
security
at
frame
IO,
a
New
York,
City
startup.
We
are
just
moved
into
kubernetes,
but
we
are.
We
have
been
using
Falco
for
quite
some
time
and
I
met
Michael
do
he.
Last
week
he
was
New
York's
week
he
totin
about
this
meeting
so
I.
That's
why
I
joined
X
welcome.
Thank
you.
B
Hey
Mark
here
the
report
I
wanted
to
mention
briefly
that
the
NIST
big
data
working
group,
which
is
wrapping
up
their
work.
It's
still
in
review
like
as
month,
three
of
reviews
for
at
NIST
before
the
official
final
report
comes
out.
The
leader
there
is
interested
in
working
on
a
framework
that
the
University
of
Indiana
and
I'll
put
this
in.
G
B
B
You
know
I'd
like
to
hook
them
up
with
other
people
with
that
interest.
So
if
anybody
on
this
group
is
interested,
I'll
put
them
in
touch
with
the
professor
at
the
University
of
Indiana
who's
who's
working
on
this
there's
a
github
project
around
this,
with
some
of
the
artifacts
in
there
that
you
can
poke
around
and
look
at.
But
it's
it's
pretty
much
TBD
to
see
where
it's
gonna
go
from
here.
It's
it
for
me,
Thank.
A
A
A
E
A
E
Cormac,
yes,
I
I've
been
mainly
reading
that
Cuban
IT
security
review,
which
is
long
and
interesting
and
trying
to
work
out
which
bits
of
it
actually
being
implemented,
and
so
on
this
some
of
the
I
was
actually
expecting
the
recommendations
to
be
kind
of
I
mean
I,
was
kind
of
expecting
the
recommendations
to
be
to
have
CVS
and
to
be
actioned
actually
there
they
have
internal
code
numbers
and
some
of
them
have
been
actions
and
some
of
them
haven't
it
was
kind
of,
but
some
of
them
are
quite
long-term
things
to
fix,
and
some
of
them
are
quite
short,
something
says
over.
E
A
E
A
I'll
make
a
note
that
we're
gonna,
you
know
slot
in
that
agenda
item
at
some
point
in
the
future,
and
you
know
we'll
just
check
back
in
when
on
the
right
time.
You
know,
especially
if
we
can
get.
You
know
a
couple,
different
perspectives
that
have
gone
through
and
digested
it
at
all.
That
would
be
really
nice.
J
Craig
hi
cranking
room
from
the
security
audit
working
group,
so
yeah
definitely
appreciate
the
feedback,
Justin
and
I've
been
enjoying
watching
the
community
response
to
a
lot
of
the
reports
has
come
out
and
a
lot
of
action
being
taken
on
issues
that
have
been
opened
already
to
and
things
being
closed
out
pretty
quickly.
So
it's
been
cool
to
see
cool.
J
It's
kind
of
rally
around
that
and
and
fixing
bugs
as
far
as
like
the
Seavey's
and
stuff
yeah
I
totally
get
that
and
that
definitely
makes
sense
we
that
was
kind
of
left
up
to
the
PSC
as
far
as
like
making
that
decision.
So
a
product
Security
Council
committee,
whatever
the
current
acronym
is
so
you
know
they
had
obviously
a
preview
beforehand
of
the
report
and
the
fine.
You
just
make
sure
how
you
doing
need
to
embargo
anything
and
ended
up
being
you
know,
no,
we
can
work
on
these
out
in
the
open.
J
E
B
D
L
Oh
hello,
everyone
so
I'm
from
re
Papa,
so
I
want
to
excuse
myself
myself,
but
we
use
communities
a
lot
in
our
company
and
we
care
a
lot
about
the
security.
So
this
is
the
first
meeting
I'm
joy,
I'm
joining
so
I'm,
trying
to
flow
falling
out
with
your
step
and
I'll
appreciate.
If
you
can
kill
me
some
guy
how
to
start
my
journey
on
the
energy
security
yeah.
A
You
know
at
a
high
level,
I
recommend
you
know
kind
of
watching
the
work
stream.
You
know
maybe
for
a
couple
meetings
and
then
we
have
a
few
major
work
streams,
around
security
assessments
policy
and
some
other
initiatives
that
we
are
always
looking
for
support
on.
So
you
know,
listen
for
the
you
know,
call-outs
for
for
needs
and
participation,
and
you
know
I
would
you
know
reach
out
and
you
know
volunteer
once
once.
You
feel
comfortable
that
there's
an
opportunity
to
lines
with
the
urges.
L
A
You
know
well
we'll
do
some
triage
there.
We
you
know
after
we
got
ratified
and
went
through.
You
know
cube
con
Europe,
we've
doubled
our
regular
attendance
and
you
know
haven't
gotten
a
lot
more
help.
So
great
the
fact
that
our
Help
Wanted,
you
is
getting
burnt
down
is
good
news.
Okay,
great
move
nice
to
have
you
on
board
last.
L
N
A
L
C
Do
I
am
new
to
this
group
and
I'm
working
for
on
special
and
yeah
Anthony.
We
just
want
to
improve
the
security
of
our
infrastructure
and
that's,
including
and
kinetise.
It
is
to
another
cloud
native
component,
so
I'm
just
telling
this
group
and
just
want
to
know
what
see
the
the
Nasdaq
of
the
cloud
native
of
security
and
want
to
keep
each
other
up.
Update.
A
Robert
great
to
see
you
I'm
gonna
transition
from
from
check-ins
to
kicking
off
our
presentation,
let's
for
the
sake
of
time,
so
welcome
anyone
who's
just
joining.
Please
do
sign
in
that
way.
We
can.
You
know,
record
your
your
attendance,
so
today
we
have
a
presentation
on
FinTech
kubernetes
and,
let's
you
you're
welcome
to
take
over.
Do
you?
Are
you
familiar
with
the
presenting
by
a
zoom.
D
D
You
should
yeah,
you
should
see
just
a
single
slide,
yeah,
okay,
hi
I
would
like
to
sorry.
D
That
specifically
means
we
are
at
German
FinTech
we've
been
we
actually
in
the
process
of
moving
the
last
customers
to
our
kubernetes
based
platform,
and
we
provide
a
API
for
banking
as
a
service.
That
automatically
means
we
are
have
regulated
heavily
regulated
industry.
So
there
are
some
of
the
things
we
can't
do.
D
We
cannot
use
public
cloud
providers
it
possibly
now,
but
it's
very
difficult
because
it's
always
a
question
of
who
gets
to
audit
whom
auditors
in
general,
are
our
biggest
pain,
because
they
asked
the
same
questions
over
and
over
again
slightly
differently
each
time
and
we
have
to
find
out
what
they
actually
are
asking.
Not
what
the
text
of
the
question
actually
means
we
are.
D
We
have
customers
that
are
banks
themselves,
as
well
as
other
fintechs
and
and
mid-sized
companies
that
simply
use
our
license
as
a
service,
because
we
are
licensed,
we
can
have
them
do
financial
transactions
across
our
platform.
We
also
serve
some
api's
to
mainly
mobile
tools
and
thus
interact
with
account
holders
and
users
directly.
We
are
in
Hamburg
and
Berlin
and
Berlin
and
we're
currently
merging
and
that's
what
I
said.
The
name
will
probably
change.
D
As
far
as
kubernetes
is
concerned,
we
are
pretty
small
compared
to
others.
We
just
have
50
mid-sized
nodes.
The
most
specific
thing
is
we
do
everything
on
bare
metal,
running
Korres
and
we
have
build
a
automatic
deployment
mechanism
that
takes
all
the
applications
directly
from
a
git
repository
and
from
configuration
from
a
git
repository
and
absolute
actual
applications
via
helm.
D
As
far
as
security
goals
and
design
principles
is
concerned,
we
do
zero
trust,
even
though
we
think
that
nobody
should
be
in
our
cluster.
We
still
don't
assume
so
that,
and
we
have
a
fairly
straightforward
sense
of
requirements,
because
the
thing
that
we
most
have
to
protect
is
the
user
credentials
of
the
online
customers.
D
D
Everything
should
be
via
get
controls
via
via
Gaddafi,
and
that
has
been
surprisingly
hard
to
do
mainly
because
we
don't
write
everything
ourselves
where
it
would
be
simple
to
do
so,
but
we
use
a
lot
of
third-party
components
and
I'll
get
into
that
in
a
bit
more
detail,
and
we
also
try
to
do
defense
of
the
in
depth
difference
in
depth
and
so
far
we
have
been.
We
think
we
have
been
successful
in
that,
because
there
were
CV
ease
that
everybody
got
really
up
in
arms.
D
D
They
are
all
automatically
by
this
deployment
mechanism
created
from
a
hasha
coke
vault
and
put
into
a
kubernetes,
and
we
are
in
the
process
of
getting
ready
to
do
better
workload
at
the
station,
so
that
we
can
eliminate
a
lot
of
these
secrets,
which
are
only
there
for
one
component
identifying
or
authenticating
to
another.
As
I
said,
we
do
bare
metal
and.
D
Then
we
do
everything
that
kubernetes
provides,
to
a
certain
extent
more
or
less.
We,
you
see
the
the
usual
acronyms
there
in
addition
to
that,
we
deployed
a
IDs
from
NOAA
vector,
which
basically
gives
us
an
insight
and
a
fairly
nice
UI
to
see
whom
is
trying
to
talking
to
whom,
and
we
can
intercept
that
if
we
want
to,
but
it's
at
the
co
at
the
moment,
we
use
it
more
as
a
detection
than
as
a
policy
enforcement
tool.
D
D
If
one
of
those
is
triggered
by
the
event,
then
the
it
pulls
the
help,
charts
and
ran,
that's
them
out
to
the
cluster.
We
do
not
use
tiller
and
it
will
also
automatically
populate
all
the
secrets
from
the
hajikko
vault.
As
I
said,
the
goal
here
is
to
have
no
human
intervention
in
the
cluster.
This
is
in
very
helpful
in
having
a
development
environment
that
looks
very
much
like
the
production
environment.
Where
you,
the
Deaf's,
can
have
all
the
secrets
they
want,
or
they
can
set
them
themselves.
D
They
can
put
them
in
the
development
vault
fairly
easy
to
work
with,
but
they
will
automatically
be
replaced
with
actual
production
values
by
deploy
D
and
therefore
there
is
nothing
that
can
be
accidentally
put
into
the
source
repo.
There
is
nothing
that
a
dev
can
leak
and
we
hope
at
one
point
to
read
a
point,
reach
a
point
where
even
an
admin
that
we
still
have
to
have
for
certain
corner
cases
is
not
able
to
leak
anything
because
they
can't
know.
D
But
now
the
next
from
from
here
on
in
this
is
basically
a
laundry
list
of
things
that
don't
really
work
that
are
hard
to
do
and
I'm
very
aware
of
the
fact
that
I'm
probably
barking
up
the
wrong
tree
and
I'm,
maybe
even
preaching
to
the
choir
here,
and
if
this
is
in
no
way
to
detract
from
the
good
work
and
and
very
helpful
work.
That
has
been
done
on
security
in
kubernetes,
but
some
of
these
things
are
really
hard
to
do
for
a
small
organization.
D
It
may
not
be
impossible,
but
it
makes
it
harder
and
also
we
are
working
with
banks,
and
most
of
the
banks
are
very
conservative,
and
the
most
conservative
of
the
representatives
of
these
banks
are
their
auditors
because
they
see
the
world
in
a
certain
way.
And
if
you
come
with
new
ideas,
then
they
often
understand
things,
as
you
can
see
from
these
quotes
that
their
actual
quotes.
That
happened
in
discussions
with
auditors.
D
D
D
The
biggest
obstacle
to
more
security
for
us
is
actually
managing
the
supply
chain.
The
software
supply
chain
security,
because
we
have
an
incredible
complexity
of
direct
and
more
indirect
dependencies
as
we
are
not
Google
or
other
large
organizations
that
can
write
or
or
at
least
review
everything,
every
single
line
of
code
that
we
put
into
our
system.
D
We
don't.
For
that
reason
we
don't
use
signed
images.
I
would
love
to
do
that.
But
what's
the
point,
it
would
be
just
signing
something
that
I
cannot
control
completely
because
of
the
complexity
of
dependencies
where
the
the
sheer
number
of
dependencies-
and
this
is
even
a
problem
with
with
the
ideas
we'll
have
had
a
number
of
cases
where
an
image
base
image
was
reported
as
containing
a
code
that
has
a
CVE
and
after
a
lot
of
manual
investigation,
we
found
out
that
yes
or
not
chorus
sent
OS
version.
D
X
Y
Z
has
CVE
that's
again
active
against
that,
but
only
in
a
component
or
in
a
package
that
is
not
installed
by
default
and
definitely
not
in
the
stripped-down
version.
That
was
the
base
image
for
some
tool
that
we
are
using.
So
any
tooling
that
were
any
concerted
effort
or
or
standard
procedure
that
would
allow
us
to
eye
easier,
identify
who
wrote
what
and
what's
the
quality
and
and
the
the
input
to
all
these
components.
All
these
dependencies
would
go
a
long
way
toward
improving
the
supply
chain
security.
D
The
next
thing
is,
as
I
said,
we
are
trying
to
eliminate
the
admin,
but
sometimes
that's
fairly
hard,
because
components
assume
that
there
is
an
admin.
They
will
even
ask
for
money
for
their
fantastic
UI,
which
is
nice
to
look
at,
and
it
often
gives
good
insights
into
what's
going
on,
but
also
they
require
you
to
configure
the
system
once
it's
running
down
to
even
closing
ports
or
setting
security
controls.
D
Now
the
network
side
isn't
that
bad
in
if
you
run
it
in
Cuba
Nettie's,
as
it
would
be
by
running
it
straight
into
the
in
the
internet
or
available
to
the
Internet.
But
there
are
a
number
of
things,
for
instance,
that
in
elasticsearch
are
very
hard
to
do
in
an
upfront
manner
or
in
a
declarative
configuration
way.
D
D
Cn
CF
landscape,
product
or
projects
that
have
this,
this
design
goal,
or
this
feature
that
they
are
completely
configurable
in
a
declarative
manner,
even
turning
off
or
or
dumbing
down.
The
UI
would
be
very
helpful
and
I
think
this
group
could
work
to
state
such
design
goals
that
are
conductive
to
security.
Hopefully,
some
projects
will
adopt
them.
D
It
is
for
me,
and
it
is
hard
to
define
or
show
what
the
benefits
of
something
like
spiffy
compared
to
kubernetes
on
board
secrets
are
especially
in
in
in
an
environment
where
I
have
to
find
a
good
reason
to
for
the
effort
that
it
would
take
to
an
implement
workload.
Attestation
I
seem
to
have
been
somewhat
successful
because
we're
we're
have
that
on
the
agenda
now.
The
next
real
effect
pain
point
with
all
the
MT
LS
is
the
certificate
management.
D
D
The
roots
a
root
certificate
rotation
is
painful.
There
is
no
easy
way
to
find
out
what
the
exact
certificate
is
and,
for
instance,
which
certificates
within
the
whole
cluster
should
be
rotated
near
next
or
should
be
replaced
next,
because
there
is
no
autorotation
all
that
gets
even
harder
if
certificate
management
is
one
of
the
regulated
areas,
because
we
have
to
do
in
a
certain
way
and
not
doing
that
is
not
an
option.
D
Manat
yet
found
a
tool
or
a
process
to
generate
the
documents
or
that
the
auditors
would
require
so
having
some
standardized
way
of
generating
standardized
documents
would
go
a
long
way,
even
if
semi-annually,
but
ideally
automatically,
because
we
are
a
small
company.
This
takes
up
a
lot
of
manpower
for
four
jobs,
so
that
are
basically
not
fun,
so
it
probably
would
help.
D
D
D
D
The
next
is
to
have
more
security
by
default,
that
is,
that
might
make
it
making
may
increase
the
learning
curve
to
start
with
kubernetes,
but
the
simple
things
as
the
non-secured
api
interface.
That's
the
default.
Why
I
know
it?
Some
of
these
points
have
been
covered
in
the
in
the
white
paper
and
the
security
analysis.
I
can
only
agree
fully,
half
that
full
heartedly
and.
D
More
steps
towards
the
Fantasyland
is
please:
let's
have
unmovable
key
support
everywhere,
where
I
can
keep
my
keys
in
an
HSM
or
maybe
even
a
chic
vault.
That
would
be
a
start
and
a
general
understanding
that
Keys
cannot
be
copied
where
you
need
them,
but
they
have
to
be
requested
or
their
use
has
to
be
requested
from
somewhere
else.
D
That
tells
me
well.
If
this
barrier
has
been
compromised
by
CVX,
then
you
have
still
n
more
layers
that
protect
your
vital
data,
which
are
the
customer
credentials
in
our
case.
So
we
at
least
we
have
the
advantage
of
being
able
to
identify
what
we
want
to
protect
and
if
there
is
any
research
on
doing
such
a
defense,
a
defense
of
depth,
so
meter
I'd
be
very
interested
in
that
and
with
that
I'm
done.
Thank
you
very
much.
A
A
A
D
It's
it's
an
interesting
for
me
that
to
understand
that
the
paintball
right-
no,
it's
actually
not
that
surprising,
but
I
have
to
continuously
make
myself
remember
that
that
it's
a
pain
point
on
both
sides
and
I.
Think-
and
this
has
been
the
the
I
think
common
theme
with
commercial
financial
services
user
group
as
well-
is
to
have
a
common,
a
common
framework,
if
only
of
documents
or
audit
questions
procedures.
Things
like
that
that
everybody
can
agree
to.
D
D
So
that
would
probably
be
helpful.
It's
the
question,
then,
is
who
who
accepts
that
as
it
as
a
base,
for
instance,
in
Germany,
we
have
had
a
federal
agency
generating
documents
like
these
for
a
long
time.
Of
course,
there
are
requirement
or
required
to
use
for
federal
agencies,
but
other
than
that.
It's
a
lot
of
that
is
yes,
the
normal
things
lock
the
door
kind
of
stuff,
but
it's
a
lot
of
paper
and
it's
I'm
not
sure
if
another
framework
like
these
will
help,
but
we
need
something.
D
H
Hi,
this
is
Abhinav,
so
one
question:
did
you
face
any
challenges
when
you
deploy
pod
security
policies
or
network
security
policies,
so,
for
example,
network
security
policy?
You
need
to
know
how
your
services
are
communicating
right,
I
mean
if
you
deploy
Blanton
policies,
they
cannot
disturb
the
services
or,
if
you
deploy
overly
broad
policies
that
don't
serve
the
purpose
that
they
intend
to
serve.
So
how
did
did
you
guys
face
any
challenges
around
that?
And
if,
yes,
how
do
we
solve
that.
D
For
understanding
who
talks
to
whom
the
nor
vector
IDs
was
very
helpful
because
you
can
run
it
in
a
learning
mode,
where
it'll
just
list
so
who
talks
to
whom
and
we
have
this
development
environment
that
reflects
the
the
actual
production
environment
to
a
sufficient
degree
other
than
that
especially
network
policies
and
and
parts
the
security
policies.
It's
just
grunt
work.
D
We
we
are.
We
are
moving
to
the
to
a
point
where
we
say
you
can't
communicate.
If
you
want
to
change
that,
come
to
me
but
and
and
state
exactly
what
you
have,
and
if
other
than
that
you
can't
it's,
it's
forbidden,
everything's
forbidden
and
it's
a
discussion.
It's
an
ongoing
discussion
and
I
think
there
is
no
real
there's
no
secure
way
around
having
this
ongoing
discussion.
D
It's
easier,
then
old-school,
firewall
rules,
because
there
is
not
this
ovation
of
this
context.
Switch
from
components,
talk
to
each
other,
to
network
numbers
and
port
numbers,
but
rather
I
can
describe
it
in
a
in
a
declarative
manner
of
of
the
length
or
of
the
names
of
the
components
that
are
talking
to
each
other.
D
B
It's
marked
underweight
here
so
so
I
also
work
in
financial
services.
So
we
got
several
of
us
here
that
are
mired
in
that
space.
I'm
wondering
if
the
Germany
federal
regulator
is
accept
any
of
your
automated
artifacts
at
all.
D
I'm,
not
sure
is
the
the
honest,
complete
answer,
but
in
the
end
it's
it's
often
generating
documentation.
That
makes
them
assume
that
you're
doing
it
thoroughly
more
than
anything
else
that
you
have
basically
have
a
plan
and
follow
that
there's
also
the
BSI
specifications
that
generally
follow
this
idea
that,
yes,
there
are
certain
simple
controls,
as
I
said,
that
lock
the
door
and
and
have
a
metal
cage
around
your
your
computers,
but
other
than
that.
D
It's
having
a
plan
and
having
a
plan
and
and
automatically
documenting
that
you
following
it
actually
does
help
a
lot
last
year.
They
wanted
us
to
do
some
screenshots
of
some
tool
that
control
controls
some
network
component.
In
order
to
document
that
we
were
following
where
we
were
doing
something
along
the
lines
of
a
plan
that,
for
us
that's
a
lot
or
too
much
manual
work
to
take
screenshots.
But
if
they
accept
screenshots,
then
the
the
assumption
is
they'll
except
automatically
reports
any
day.
B
So,
just
a
placeholder
for
a
future
discussion,
the
occ
who's,
the
main
regulator
in
the
u.s.
convened
a
meeting
with
our
DevOps
standard
in
I
Triple
E,
in
which
they
tried
to
talk
about
reverse
engineering
DevOps
from
the
regulator's
point
of
view,
ie
deconstruct
the
artifacts
that
were
coming
out
of
DevOps
so
that
they
could
consume
them
in
a
DevOps
methodology,
as
a
regulator
seems
to
me
that's
kind
of
where
we
need
to
get
with
the
whole
reg
tech
space.
B
B
I
seen
sure
I
it
was
an
abandoned
conversation.
We
had
five
or
six
meetings
with
them.
You
know
they
seemed
very
interested
and
then
they
concluded
it
with
no
artifacts.
So
I
don't
know
if
that
means
they
have
a
plan.
They're
gonna,
announce
to
us
or
if
somebody
inside
the
OSC
C
killed
the
project.
I
just
don't
know.
D
K
Well,
I
just
put
on
the
agenda
to
just
highlight
the
recent
CBE
cluster
for
envoy,
which,
coincidentally,
was
on
our
list.
They
get
things
we
wanted
to
maybe
reassess
the
underlying
point.
I
wanted
to
make.
Was
this
notion
that
you
know
security
on
it?
Is
you
know,
point
in
time,
artifact
and
that
you
know
this
notion
that
you
can
just
say
something
as
a
security.
G
E
The
Envoy
securities
use
the
same
ones
as
the
guy
runs
and
therefore
apply
to
everything.
Building
go
as
well.
Is
it
because
they
were
the
general
http/2
vulnerabilities,
so
they
approach
the
implementations
as
gets
hairy.
We
also
applies
to
Cuban
essays
and
anything
else
is
using
essentially
using
HTTP
to
saying.
E
A
E
Know
I
think
it
looks
to
me
like
no
one
had
looked
really
hard
at
the
kind
of
resource
allocation
issues,
http/2
that
we
went
through
the
whole
thing
with
HTTP
decades
ago,
with
slow
loris
was
one.
There
was
a
bunch
of
them
around
then
about
the
same
kind
of
attacks
and
the
HTTP
to
spec
didn't
wasn't
very
specific
about
how
to
deal
with
resource
allocation
issues,
and
so
netflix
spent
a
bit
of
time
on
it
recently
and
I.
Hopefully,
they
found
most
most
of
the
issues
and
I
think
they're
relatively.
E
Understandable
they
were
quite
a
few
of
them,
but
they
and
they
did
a
coordinated
disclosure
with
all
the
major
implementations
that
so
hopefully
this
is
most
of
them,
but
yeah.
If
people
that
I
mean
resource
allocation
issues,
it
kind
of
rice
through
everything,
it's
just
easy
to
make
things
with
each
resources
general,
because
it's
not
a
threat
model.
People
think
about
much
right.
A
E
It's
got
all
types
of
resource
because
he's
got
multiple
channels,
so
you
can
link
channels
or
you
can
send
things
down,
multiple
channels
in
small
amounts
and
all
the
other
kinds
of
types
of
thing,
because
it's
not
just
a
single
channel
anymore
and
there's
a
few
other
pieces
around
had
a
compression
and
things
like
that.
That
also
resource
allocation
issues
and.
A
A
K
Just
feedback
on
the
lifecycle
PR
that
I
put
up
there
and
noting
that
it's
still
work
in
progress,
but
I
thought
I'd
throw
up
what
I
had
just
you
know
to
keep
the
momentum
going
anyway,
I.
Think
again,
my
my
meta
point
is
that
I
think
the
security
assessment
shouldn't
be
thought
of
as
this
single
point
in
time.
It's
just
it's
a
commitment.