►
From YouTube: Securing Critical Projects WG (August 27, 2020)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
C
Cool
okay,
so
I
just
threw
a
couple
of
things
in
here
to
give
a
little
bit
of
background
to
people
on
the
call-
and
I
noticed
some
of
the
ryan
you're
here
I
was
hoping
john
gossman
was
gonna
come
today,
but
I
don't
see
him
on
the
call.
So
earlier
this
year,
we
we
use
in
google
and
several
other
companies
sort
of
got
together
and
try
to
figure
out
how
we're
going
to
improve
open
source
security
together.
The
outcome
of
that
is
the
new
open
source
security
communication.
C
We
had
we
had
a
bunch
of
working
sessions
together
and
and
were
you
know,
we
talked
about
this
idea
a
lot
and
what
it
could
look
like
sort
of
what's
been
done
before,
like
how
do
we?
How
do
we
learn
from
what's
been
done
before
and
apply
it
either
differently
or
you
know,
learn
from
it.
We
came
up
with
a
cool
name,
and
I
I
copied
it
here
called
like
the
fire
team.
C
The
free
incident
response
engineers
and
the
idea
is,
you
know
they
can
move
from
project
to
project
and
then
and
then
help
out
that
way,
and
so
you
know
one
of
the
things
that
we
discussed
with
companies
is
that
you
know
we're
all
sort
of
you
know,
there's
a
security
issue
or
something
we're
all
sort
of
fixing
the
same
thing.
So
there's
a
lot
of
duplicate
effort,
and
it
would
be
great
if
we
didn't
have
to
do
that,
and
we
had
like
one
concerted
effort
to
go
in
and
help
things.
C
C
This
is
where
you
know.
I
asked
david
and
he's
gonna
do
a
little
discussion
on
the
cii,
and-
and
this
is
where
some
of
the
work
that
the
linux
foundation
has
been
doing
with
harvard
in
the
census-
work
that
I
think
could
could
come
in
handy
but
really
curious.
You
know
to
have
to
talk
about
that
with
other
companies.
C
If
you
know
we
talked
to
a
few
companies
and
they're
like
yeah,
we
have
a
list
of
100
open
source
projects
that
are
critical
and
and
that
we,
you
know,
we
want
to
make
sure
our
secure
and
so
that
that
would
be
a
good
discussion
topic
for
us
and
then
and
then
the
next
thing
is
like
what
improvement?
What
improvements
would
we
actually
make
to
these
projects?
Is
there
something
we
could
sort
of
collectively
agree
on
and
go
and
start
tackling
alone?
C
And
then
so
we
you
know,
we
were
interested
in
funding,
an
effort
like
this
with
real
money.
Unfortunately,
kovitz
sort
of
came
upon
upon
us
and
then
you
know
budgets
were
shrinking
a
lot.
So
we
weren't
able
to
make
as
much
progress
on
this
as
we
wanted
to
yet,
but
that
that
was
the
spirit
like
there's
a
whole
bunch
of
critical
open
source
projects
that
you
know
that
don't
have
as
many
eyeballs
as
they
need
right
now
and
and
sometimes
even
at
google.
C
It's
hard
to
like
actually
get
that
stuff
prioritized
and
convince
like
an
engineer
to
sort
of
work
on.
You
know
some
random,
one-off
package,
but
even
though
we
all
sort
of
depend
on
it,
so
that
they're
kind
of
a
bit
of
the
background
how
this
came
about
and
then
you
know
we
spun
up
the
open
source
security
foundation
and
then
we
bootstrapped
it
with
this
working
group
and
that
was
sort
of
the
intention
of
the
working
group
and
and
what
we're
hoping
to
do
so.
So
that's
a
bit
of
background.
We
can.
C
D
Okay,
go
ahead,
dave,
I
I
I
did
actually
have
a
specific
sort
of
insight
from
cii
from
a
few
years
ago,
specifically
around
that
sort
of
selection
of
projects
thing,
which
I
think
is
a
precursor
to
any
other
discussion
when
when
we
were
doing
the
cii
five
six
years
ago,
one
of
the
things
that
was
specific,
sorry,
the
core
infrastructure
initiative.
Sorry
christina
the
core
infrastructure
initiative,
was
a
project
that
was
set
up
by
the
linux
foundation,
more
or
less
in
the
wake
of
heartbleed.
D
When
suddenly
everybody
in
industry
who
thought
that
they
wasn't,
they
weren't
using
open
source
software
and
their
code
base,
suddenly
realized
that
actually,
they
were
using
open
source
software
all
over
their
code
base.
One
of
the
things
that
came
up
in
the
early
discussions
was:
how
does
one
limit
the
scope
and
what
so?
What
constitutes
infrastructure,
because
the
goal
was
really
to
try
and
provide
a
way
to
better
secure
the
development
of
infrastructural
bits
of
software,
and
it
varies
enormously
depending
on
what
part
of
the
stack
you're
looking
at.
D
If
you
look
at
a
typical
piece
of
javascript,
the
transitive
closure
of
all
of
the
javascript
packages
that
get
sucked
in
is
enormous,
whereas
if
you
look
at
a
piece
of
go
or
rust,
it
tends
to
be.
You
know
the
the
span
at
any
given
node
is
much
smaller
and
then
the
so
the
total
transit
closure
is
much
smaller.
And
if
you
look
at
the
big
components
you
know
kubernetes
relies
on
a
bunch
of
other
bits,
but
actually
a
surprisingly
small
number
of
them
compared
to
your
typical
web
page.
D
So
I
think
that
if
one's
working,
the
the
critical
word
is
critical
in
in
this
discussion,
because
you
know
we
can't
necessarily
expect
to
you-
know
secure
every
javascript
project
on
npm
or
or
every
python
package
on
pi
pi,
and
so
you
know,
we've
got
to
sort
of
work
out.
Where
do
we
limit
our
scope?
D
A
D
A
Yeah,
so
if
I
can
jump
in
here
so
back
when
nico
was
leading
the
the
cii
I
actually
worked
for,
I
actually
supported
him.
We
did
an
early
study
which
was
called
cii
census,
one
where
we
analyzed
primarily
packages
within
linux,
distros
to
try
to
try
to
help
identify
what
was
critical
within
them,
since
that,
since
the
time
when,
after
and
nico
moved
on
much
more
recently,
just
a
few
months
ago,
harvard
released
what
we're
calling
cii
census
ii.
A
This
is
continuing
work
from
the
cii
where
they
analyzed
dependencies
at
the
language
package
level.
You
know
javascript
and
so
on
and
identified
what
they
believe
and
using
dependency
data
and
data
from
to
software
from
to
sca
organizations
that
software
compo
well
software
compo,
depending
on
your
device,
but
basically
the
software
components
of
folks
who
analyze
that
so
and
we
I'll
I'll
get
the
link
for
that.
A
We
can
put
that
in
in
this
little
document
for
notes
or
actually
somebody
else
can
just
google
and
look
it
up.
It's
it's.
It
shouldn't
be
hard
to
find
one
of
the
other
things
that
the
cii
did
two
other
things
and
what
the
one
the
important
things
to
do
is
after
you
identify
critical
projects.
What
do
you
do
about
them?
A
A
C
A
Sorry,
the
wii
in
this
case
was
the
cii.
The
the
cii
actually
funded
a
number
of
projects,
including
openssl,
to
basically
fix
up
some
serious
long-term
problems.
Openness
style
wasn't
getting
widespread
review
and
and
one
of
the
we
can
talk
about
the
changes
that
were
done.
But,
for
example,
if
you
ever
tried
to
look
at
the
open
ssl
code,
it
was
a
masterpiece
of
confusion.
A
They
had
you
know
it
had
built
up.
You
know
technical
debt
like
nobody's
business
and
I
think
and
made
some
decisions
that
really
should
never
have
been
made.
So
yes,
so
the
cia
actually
funded
work
to
evaluate
projects
to
fix
them
to
make
various
changes,
and
we
did
require
things
like
we'll
give
you
funding,
but
you've
got
to
use
a
version
control
system.
A
A
Okay,
okay
can
talk
about
this
as
well.
We
probably
have
slightly
different
opinions.
There
were
so
there
were
multiple
different
ways,
so
there
was
both
a
a
a
an
analysis
from
the
cii,
hey,
what's
important
to
fund
and
then
a
and
then
basically
its
governing
board
decided
what
to
fund.
There
was
also
a
grant
model
where
people
could
make
requests
now
nico
you
can
have.
A
You
may
not
have
the
same
opinion
as
I
do,
but
in
my
opinion-
and
this
is
just
my
opinion-
I
think
the
grant
model
in
the
short
term
was
a
mistake
and
the
reason
was
it
made
sense,
because
governments
do
this,
all
the
time
hey
make
proposals,
but
in
my
experience,
the
projects
that
needed
it
to
help
the
most
were
the
ones
who
tended
to
not
show
up
and
make
requests,
and
so
it's
spent.
It
took
a
lot
of
time
to
review,
grant
proposals.
D
I
I'm
imposed
yeah,
I'm
inclined
to
agree
with
you,
though
david.
I
think
that.
Well,
actually
I
I
mean
in
two
minds.
I
think
that
that
we
had
some
very
useful
grant
applications
that
we
granted
to
the
flow
we
actually,
I
think
the
biggest
problem
with
the
grant
process
was
that
we
that
a
lot
of
important
projects
didn't
know
that
they
could
come
to
us
for
grants
and
we
tried
doing
a
fair
amount
of
outreach.
D
D
You
know
there
was
a
fair
amount
of
back
and
forth
with
the
cii
board
about
what
the
right
way
to
do
with
this
was
because
there
were
several
people
who
felt
like
we
shouldn't
be.
We
shouldn't
be
giving
people
grant
money
unless
they'd
written
a
good
grant
application
and
so
marcus
streets
who
also
worked
for
the
cii
back
then
spent
a
fair
amount
of
time
talking.
People
through
the
process
of
writing,
grant
applications
so
that
they
could
apply.
D
D
D
Well,
we
yeah,
we
didn't
fund
its
development,
but
we
did
a
fun.
We
funded
its
security
audit,
which
demonstrated
that
it
was
a
significantly
bad
thing
and
I
think
one
of
the
things
that
we
did
do,
which
was
quite
valuable
in
a
number
of
cases,
was
going
to
projects
which
we
felt
were
important,
but
who
didn't
think
that
they
needed
a
lot
of
operational
help
and
funded
security
analyses
so
that
they
could
highlight
the
the
good
and
bad
in
the
project
and
and
work
out
what
what
to
do.
A
A
I
I'm
not
saying
that
grants
could
never
work.
It's
just.
I
I
think
it's
often
very
helpful
to
look
at
your
options.
You
know
evaluate,
see,
what's
going
on
and
look
at
your
options,
otherwise
it
take.
It
does
basically
takes
a
lot
of
time
to
run
a
grant
program.
So
let
me
I
I
had
promised
kim
just
a
few
minutes
and
I
I
think
we're
running
short.
So
let
me
just
talk
about
what
the
the
badge
is.
Just
one
thing
she
asked
me
to
talk
about.
A
A
How
folks
actually
developed
to
solve
for
matters?
That's
not
doesn't
mean
that
good
people
are
unimportant,
but
we
want
people
to
do
reasonable
things,
and
so
we
identified
a
bunch
of
best
practices
for
the
production
of
open
source
software
and
have
a
little
web
application
where
projects
can
self-certify.
A
There
is
some
automation
in
there
to
verify
to
fill
in
answers
and
verify
them,
and
we
also
present
the
answers
so
that
people
can
critique
the
various
claims.
It's
a
little
web
application
and
in
fact
it
earns
its
own
badge,
which
I
think
is
important.
Nothing
else.
If
you
ever,
if
you're
involved
in
an
open
source
project,
I'd,
encourage
everybody
to
go
and
go
to
their
website
best
practices,
infrastructure
or
get
a
badge.
A
I
think
my
video
okay,
this
is
slightly
old,
there's
something
there's
over
3
300
projects
participating
now
and
over
450
at
least
have
earned
a
at
least
the
passing
level
badge.
There's
actually
three
passing
three
badge
levels:
passing
silver
gold:
you
have
to
eat
the
lower
levels
to
get
the
higher
ones.
A
Silver
was
designed,
so
it's
possible
for
a
one-person
project,
but
it's
difficult
and
gold.
Really.
You
have
to
have
multiple
developers,
there's
just
a
lot
of
one-person
projects,
which
is
why
it
was
divided.
This
way
the
whole
thing's.
All
the
criteria
were
designed
to
be
reasonable.
Not
hypocritical
we're
focused
not
on
academics.
Somebody
thinks
it's
a
good
idea,
but
what
their,
what
projects
find
actually
works?
A
A
So
here's
a
couple
examples
of
what
those
look
like
hey.
Does
your
website
succinctly
describe
what
the
project,
what
the
software
does?
You
have
to
have
at
least
one
on
automated
tool
suite
you
have
to
use
at
least
one
static
code,
analysis
tool.
You
have
to
use
hd,
you
have
to
support
https
for
your
website
and
repo.
A
A
F
D
At
the
beginning,
there
was
a
perception
that
this
was
sort
of
commercial
companies
telling
them
what
to
do,
and
you
know
so
having
you
know,
google
and
microsoft
are
telling
us
that
we
need
to
do
x,
and
so
we
did
see
a
little
bit
of
a
pushback
of
that,
because
I
think
the
board
felt
I
think
quite
reasonably,
that
we
weren't
going
to
give
people
money
just
toss
it
over
the
wall
and
see
what
happens.
We
were
going
to
give
people
money
to
do
things
that
we
felt
were
necessary.
F
D
Quite
right
already
was,
with
the
reproducible
builds
project,
which
was
a
debian
project
to
ensure
that
when
you
build
a
debian
package
according
to
the
script,
you
end
up
with
a
binary,
identical
package.
If
you
build
from
the
same
source,
they
would
just
you
know
it
was
a
sensible
thing
to
do
and
they
were
doing
it
right,
and
so
we
didn't
put
many
constraints
on
them,
but
certainly
with
the
open
ssl
foundation.
D
Well,
the
open,
ssl
team
prior
to
them
having
a
foundation
they.
I
think
we
got
a
fair
amount
of
pushback,
saying
well
you're,
just
making
us
do
stuff
that
we
don't
didn't
want
to
do.
Eventually
we
got,
you
know,
got
over
those
humps,
but
I
think
that
was
sort
of
the
biggest
problem
that
we
had
with
the
board
deciding
whom
they
want
to
give
money.
A
A
Exactly
I
mean
I,
I
I
think
it's
in
many
ways,
it's
much
easier
to
view
this
as
a
negotiation
after
you
find
out,
you
got
a
problem,
you
need
to
do
something
about
it.
Just
sending
money
with
no
strings,
I
think
was,
is
actually
you
know
unless
you're
very,
very
confident,
they're
already
gonna
have
the
right
direction.
I
think
is
actually
important,
even
though
it
was
negatively
perceived
by
some.
I
think.
In
the
end
I
mean
they
did
take
the
money
with
the
strings
and
positive
things
occurred
from
it.
A
I
think
in
some
cases-
and
I
think
that's
going
to
be
the
experience
of
open
ssf
as
well
personalities
matter
have.
I
said
that
politically
nicely,
there
are
some
projects
which
are
very
important,
written
and
managed
by
people
who
are
a
little
prickly,
they're
used
to
doing
their
own
thing,
and
it's
not
necessarily
wrong,
because
they've
managed
to
succeed
in
doing
something.
The
way
they've
always
done
it,
and
so
I
I
think
it's
helpful
to
go
in
with
a
mindset
of
this
is
a
negotiation.
A
We
want
you
to
do
x
because
it's
important
we're
willing
to
pay
you
dollar
y,
and
I
I
think
it
did,
but
it
did
take
some
doing,
and
I
think
in
several
cases,
surprisingly
more
for
things
that
I
think
most
of
the
rest,
most
of
us
here
right
here
in
this
meeting
would
have
expected
would
be
well.
Of
course
you
would
do
that
and
for
them
the
idea
of
doing
version,
control
or
writing
a
test
was
beyond
the
pale
and
no
it's
not
beyond
the
pale.
It's
perfectly
reasonable.
G
So
david,
I
I
think
if
I
might
try
to
hear
it,
maybe
this
is
a
transition
to
where
kim
started
the
publication
is.
You
know
when,
when
you
talk
about
you
know
giving
funding
to
the
existing
maintainers
of
a
project
the
real
challenge
there
is
coaxing
them
into
changing
how
they're
running
their
project.
What
we
found
in
other
project
communities
is
that
hiring
somebody
you're
paying
somebody
to
go
and
work
on
what
needs
to
be
done.
G
You
know
sometimes
coming
somebody
else
actually
do
that
work
can
be
more
effective
because
usually
they're
existing
containers
yeah,
we
know
it'd
be
nice
to
do
that.
They
just
don't
have
the
time
to
do
it,
and
so
it's
growing
more
on
their
plate
and
saying
we'll
give
you
a
little
extra
money
for
it.
G
You
know
it's
just
like
okay,
well
I'll,
do
maybe
a
little
bit
extra
in
my
nighttime,
but
you
know
it's
a
constrained,
so
I
I
think
you
know
the
fire
team
concept
was
interesting
when
I
heard
about
it,
because
you
know
it's
something
that
that
really
puts
the
onus
on
certain
people
to
go
and
help
clean
up
and
fix
certain
things
without
necessarily
burdening
the
existing
maintainers
in
an
unnecessary
or
forceful
way.
So
you
know.
C
Yeah,
I
was
gonna
say
that
even
the
framing
that
they
might
not
want
to
do
it
or
it's
a
low
priority
is
like,
I
think
wrong,
because
writing
good
tests,
for
example,
is
extremely
difficult.
It's
something
that
people
specialize
in
in
their
careers
and
someone.
That's
writing.
You
know
like
low-level
kernel.
Drivers
is
not
specialized
in
writing.
A
comprehensive
test
suite
so
yeah,
just
plus
one
to
having
someone
kind
of
go
in
and
take
care
of
that
who
has
that
knowledge
and
knows
how
to
do
that?
C
G
So
yeah
we
do
it,
but
we
do
it.
I
guess
I
wouldn't
say
we
do
it
so
overtly
we
don't
say:
hey
we're
paying.
You
know
x
person
to
come
and
fix
your
code
base.
What
we
generally
do
is
show
up,
and
you
know
we
have
somebody
make
contributions,
and
you
know
we
make
contributions
to
various
projects.
All
the
time
you
know
through
you
know,
people
that
we,
you
know
deem
can
help
solve
the
problem.
G
For
example,
in
real
time
linux
we
hired
an
outside
firm
that
had
specialty
in
real-time
problems
to
go,
and
you
know
fix
up
a
lot
of
the
real-time
kernel
code
base
and
you
know,
make
those
contributions,
but
they
didn't
come
in
and
change
the
community.
Some
of
them
were
already
part
of
that
community,
but
you
know
it
was
we
had
new
people
coming
in
to
help
clean
up
some
of
that
in
automotive
technologies,
for
example,
the
automotive
makers
had
a
number
of
issues
when
they
started
deploying
linux
and
cars.
G
D
G
G
H
A
Yeah,
so
if
I,
if
I
could,
tie
this
up
in
a
bose
as
it
were,
I
think
identifying
this.
You
know
the
critical
projects
is
critically
important,
but
we
also
need
to
make
sure
that
there's
a
next
step,
because
if
we
just
say
oh
look,
there's
a
problem
and
I
would
go
further
and
say
that
the
exact
model
is
going
to
probably
vary
from
project
to
project.
A
A
B
Just
to
keep
going
on
that
thread
a
little
bit
like
what
other
types
of
I
guess,
what
we're
kind
of
getting
at
is
like
we
end
up
with
some
kind
of
menu
of
services.
You
know
we
could
offer
projects
whether
it's
funding,
you
know,
infrastructure
credits,
actual
full-time
employees
to
go.
Do
a
task,
expert
consultations
on
specific
security.
Things
like
what
other
kind
of
just
brainstorming
exercise
live.
What
other
things
can
we
think
of
that
projects
might
look
for,
and
obviously
we
have
to
run
this
by
actual
projects
too.
I
Yeah,
if
I
could
chime
in,
I
thought
some
really
good
points
were
made
about.
You
know
a
lot
of
these
projects.
You
know
they're
so
focused
on
the
the
core
project
itself.
They
don't
have
time
for
things
like
finding
finding
resources
and
things
like
that,
and
that's
certainly
been
the
case
with
what
we've
seen
at
ostif,
where
you
know
when
we
help
these
organizations
procure.
I
You
know:
high
quality
audit
resources,
there's
so
much
coordination
that
goes
into
that,
and
I
think
personally,
at
least
based
on
our
experience
and
based
on
the
research
from
things
like
zero
days,
thousands
of
nights
where
really
going
in
depth-
and
you
know-
having
a
well
scoped
correctly
scoped,
deep
dive
audits
performed
by
you-
know,
experts
who
have
published
research
in
this
field
or
have
expertise
in
that.
You
know
a
particular
field,
kind
of
going
back
to
christina's
point
as
well.
I
D
I
I
agree
very
much
with
you
emir,
but
I
think
that
there's
also
another
step
that
comes
before
that,
which
is
for
the
lower
hanging
fruit.
One
of
the
things
that
you
know
the
linux
foundation's
done.
A
ton
of
research
over
the
years
which
showed
about
how
the
strength
of
the
community
around
a
project
is
critical
in
the
success
of
an
open
source
project.
D
One
of
the
things
that
we
discovered
in
a
lot
of
discussions
through
the
cii
was
that
often
you
know
you
if
you,
if
you
go
through
the
best
practice
badge
list,
there's
nothing
on
that
list.
That
people
will
say:
oh
my
god!
Well
we
never
want
to
do
that.
I
mean
these
are
all
no-brainer
things,
but
if
you've
got
a
project
where
you
know,
there's
somebody
waving
the
flag
for
performance
and
there's
somebody
waving
the
flag
for
scalability
and
there's
somebody
waving
the
flag
for
new
features
and
there's
somebody
waving
flag
for
ux.
D
I
C
Cool
yeah,
I
know
they're,
I
mean
in
the
open
of
course,
open
ssf
just
got
off
the
ground,
but
there's
a
number
of
other
working
groups
too,
and
I
think
david's
put
together
some
training
stuff.
So
I
think
this
is
all
in
the
scope
of
what
we
want
to
do
as
a
foundation,
at
least.
So
we
only
have
nine
minutes
left.
We
didn't
get
to
all
the
discussion
stuff.
We
can.
C
We
can
table
that
for
next
time,
but
I
think
to
me
a
couple
of
things
that
I
feel
like
we
can
get
started
on
right
away
and
I,
and
one
is,
is
working
on
defining
those
critical
projects
so
as
soon
as
we
can
get
those
harvard
folks
in
here
david,
I
think
that
would
be
really
helpful.
I
know
I
think
last
time
I
heard
about
it.
They
actually
needed
more
data,
because
more
data
is
better.
A
C
Maybe
I
don't
mind
scheduling
another
one
of
these
depending
on
their
their
schedule,
and
then
the
other
thing
we
were
just
thinking
of
is,
if
you
know,
we
actually
just
started
getting
feedback
from
maintainers
about
like
what
would
be
on
their
wish
list,
like
the
top
10
to
20
things
and
from
a
security
standpoint.
So,
and
that
could
give
us
some
ideas
of
how
you
know
this.
This
service
might
work
once
we
have
the
funding
ready
ready
to
go.
H
I
I
have
a
question
about
that
identification
process
because
from
what
I've
heard
described,
it
sounds
like
it's
sort
of
a
dependency
analysis
tool
chain.
My
my
question
is
like:
how
do
you
identify
things
that
are
used
over
a
network,
because
that
also
seems
important,
so
like
an
example
which
probably
isn't
super
important
to
secure,
because
I
think
it's
already
secure
and
their
processes
around
it.
But
just
as
an
example
like,
let's
encrypt,
let's
encrypt
boulder
certificate
authority
is
run
by
one
organization
really
in
one
place,
but
we
all
depend
on
it.
J
Yeah,
I'm
actually
really
curious
what
that
algorithm
is
to
decide
what
exactly
is
critical
right
because,
like
you
just
said,
an
app
criticality
for
an
app
versus
a
network
service
is
very,
very
different
things
right
and
then,
if
we're
looking
at
popularity
and
components
that
are
used
in
apps,
that
doesn't
necessarily
define
critical
right,
but
something
could
be
used
by
every
single
project
on
the
planet
or
there's
no
app
on
the
planet.
But
you
know
it's
to
like
help.
You
format
a
string
and
it's
not
super
critical
right.
J
So
I
just
want
to
know
kind
of
what
that
what
that
calculation
looks
like,
because
in
the
past
I've
run
I've
written
scanners
for
apps
to
determine
like
little
sort.
You
know
middleware
components
and
things,
but
that's
just
popularity
right.
So
what?
What's
that
next
step
of
defining
security,
criticality.
A
B
G
Yeah,
I
I
think,
having
done
a
number
of
criticality
studies
like
with
the
one
with
harvard
we've
been
done
with
the
one
with
ci.
I
I
think
we'll
find
that
it's
really
up
to
this
group
to
define
what's
critical
to
you
in
terms
of
what
what
do
you
all
want
to
work
on
solving
for
and
back
into,
you
know.
G
And
so
I
think
it's
just
up
to
this
group
to
figure
out
you
know
what
do
you
want
to
define?
As
you
know,
what
is
critical
open
source
to
you
and
then
you
know
how
do
you
go
and
tackle
and
address
it
once
you
sort
of
have
scoped
that,
because
I
don't
think
you
can
scope
everything
you
know
just
looking
at
some
of
the
reports
on
the
javascript
dependency
trees.
It'll
just
make
your
head
explode,
but
you
know
that's
just
one
sort
of
use
case
to
focus
on
around
the
javascript
side.
J
Yeah
I
was
going
to
mention
kind
of
the
same
thing
is
that
I
think
there's
step.
One
is
identifying
criticality
or
a
couple
of
different
use
cases,
apps
versus
services
versus
whatever
right
and
then
triaging
those
and
then
the
next
step
is
also
kind
of
leading
into
these
fire
teams
right.
What
does
the
response
look
like?
I
Yeah,
that's
a
very
good
point
and
also
to
your
point
mike
about
you
know,
defining
what's
critical.
I
think
at
the
end
of
the
day,
it's
you
know,
what's
most
important
to
us,
what's
most
important
to
me
or
my
organization
or
our
technology
suite,
but
a
good
example
going
back
to
let's
encrypt
because
you
brought
it
up
and
it
could
be
kind
of
like
a
smaller
kind
of
case
study
of
this
bigger
problem
we're
talking
about.
I
We
actually
worked
with
let's
encrypt
last
year,
because
unbound
dns,
that
they
use
very
heavily,
was
kind
of
an
external
piece
that
was
kind
of
out
of
their
control,
and
you
know
it
was.
It
was
identified,
that's
very
important
to
their
operations,
and
so
we
were
able
to
coordinate
a
audit
of
that
and
find.
I
I
believe
it
was
one
critical
and
five
high
vulnerabilities,
which
I'm
happy
to
share
those
results
with
you
guys,
but
or
with
everybody.
But
it's
just
a
good
example.
Like
you
know,
those
all
those
classes
of
bugs
are
now
essentially
closed
as
a
result
of
that
review,
and
you
know
we
can
say-
obviously
you
can't
say
for
sure
for
certain
that
it's
secure,
but
we
could
say
with
pretty
decent
assurance
that
you
know
it
was
reviewed
and
we
found
these
issues
and
we
can
say
that
you
know
it's
much
more
secure
now.
C
Awesome
thanks
everyone
for
for
attending
the
first
inaugural
kickoff
meeting
here.
I
think
next
steps
are
to
start
working
on
defining
those
critical
projects,
so
david
may
yeah.
Let's
see
if
we
can
get
harvard
to
do
a
presentation
in
two
weeks
and
then
I
think
you
know
as
next
steps
for
folks
that
are
interested
in
this
like
we
could
do
some
smaller
working
group
sessions
to
hammer
this
out
and
then
and
then
go
from.