►
From YouTube: CNCF TOC Meeting 2023-06-20
Description
CNCF TOC Meeting 2023-06-20
B
D
B
All
right,
let's
go
ahead
and
get
started.
Thank
you,
everyone
for
joining
us
today.
As
a
reminder,
we
all
abide
by
the
antitrust
policy
notice
and
if
you
have
made
it
today,
you
know
where
the
meeting
is.
We
thank
you
for
joining
us
next
slide.
We
have
several
Toc
members
here
today,
but
we
won't
be
making
any
decisions
on
the
agenda.
B
We're
going
to
talk
a
little
bit
about
security
audits,
some
common
issues
and
findings
from
them,
how
the
TOC
uses
them,
how
the
maintainers
use
them
and
potential
improvements,
or
even
identifying
existing
challenges
between
maintainers
or
TSC
members
when
reviewing
the
audits
for
projects
and
then
an
effort
to
just
improve
the
overall
experience
for
all
parties
involved.
We
have
with
us
David
and
Adam
from
Ada
Logics,
who
are
going
to
first
run
through
kind
of
a
little
bit
about
their
audits.
B
If
you
were
present
at
the
last
kubecon,
they
had
a
presentation
on
this
which
is
kind
of
what
sparked
this
discussion
and
then
run
through
some
challenges
and
issues
that
they
they
come
across
and
then
we'll
open
it
up
to
a
little
bit
more
of
a
discussion
around
how
our
maintainers
feeling
about
the
audience.
What
are
some
of
the
challenges
in
that
process
that
they're
experiencing
and
some
of
the
recommendations
that
we
have
moving
forward?
All
right,
let's
go
ahead
and
get
started.
Adam
David
I'll
hand
it
over
to
you.
E
E
So
essentially
helped
that
process
not
do
your
work,
but
give
the
right
information
such
that
you
can
give
a
correct
assessment
and
I
think
this
is
a
it's
a
great
idea
and
I
think
a
key
point.
There
is
that
we
have
essentially
never
discussed
with
the
TRC
or
so
to
understand
what
are
the
things
you
try
to
extract
from
the
from
the
security
reports
to
to
enhance
your
decision
making.
B
E
So
that's
the
key
point
of
the
discussion
and
to
sort
of
lady
groundwork
we're
going
to
give
a
short
presentation
of
how
our
audits
usually
go
the
timeline
and
what
are
the
technical
aspects
we
look
for
and
what
are
the
the
outputs
of
it?
So
usually
the
engagements
are
five
weeks,
long
plus
minus
a
few,
and
sometimes
they
extend
a
little
bit
based
on
how
kind
of
how
how
well
we
synchronize
with
the
teams
during
the
orders.
So
sometimes
they
will
have
some.
E
They
will
not
have
the
the
a
lot
of
time
for
the
orders
in
certain
periods,
so
we
have
to
kind
of
like
it's
a
fairly
flexible
process.
In
that
sense,
it's
estimated
that
five
weeks
and
we
do
a
lot
of
navigation
during
that
time
to
ensure
enough
like
the
proper
work
is
done
and
also
we
meet
the
maintenance.
E
We
meet
the
maintain
a
schedule,
so
they
usually
start
with
having
an
introduction
meeting
either
the
first
day
or
a
few
days
before
the
the
audit
starts
where
we
discuss
sort
of
logistics,
communication
channels
outline
expectations.
They
can
give
us
input,
for
example,
if
they
have
Focus
areas
if
they
have
certain
concerns,
and
they
can
just
give
us
a
lot
of
information
that
they
feel
is
relevant
and
we'll
kind
of
incorporate
that
into
our
audit
process.
E
And
basically
the
audit
then
starts
there
can
be
a
lot
of
different
tasks
depending
on
each
audit,
depending
on
the
project
but
sort
of
an
invariant.
Is
we
often
have
meetings
either
weekly
or
bi-weekly,
and
this
is
depending
on
on
what
the
maintainers
want
and
sort
of
like
prefer,
and
we
try
to
engage
with
the
maintainers
on
their
times.
So
after
email
slack
or
are
the
means-
and
usually
it's
like
I-
don't
create
if
I'm
wrong
and
the
output
of
the
the
the
report.
E
Sorry,
the
output
of
the
engagement
is
a
mix
of
things.
Fundamentally,
it's
a
report,
that's
kind
of
like
the
deliverable
we
give
to
the
cncf,
but
then
there's
also
a
lot
of
Upstream
code
changes,
Upstream
document,
documentation,
changes,
security,
advisories,
fit
models,
security
policies
and
various
types
of
things,
so
those
are
also
outputs
of
the
artifacts.
As
output
of
the
of
the
audits,
we
have
a
list
of
all
the
orders
carried
out
and
to
say
here
that
there's
also
other
companies
that
do
this.
We
generally
follow
a
similar
structure.
E
D
E
E
So
that
context
is
super,
and-
and
we
do
write
the
reports
in
in
this
in
a
way
where
we
try
to
have
section
that
is
more
appropriate
for
various
stakeholders.
So
just
to
to
put
a
note
here
is
that
it
would
be
great
to
have
some
form
of
like
a
section
that
is
primarily
targeted,
the
TOC
almost,
and
it's
just
about
scoping
out
what.
E
F
F
Another
goal
is
to
look
at
the
the
test:
Suite,
both
yeah,
for
example.
First
first
test
Suite,
see
if
we
can
improve
it
and
make
an
assessment
of
how
it
is
how
well
it
covers
critical
areas
of
the
code,
and
we
also
will
consider
and
assess
the
static
analysis
tool
chain
of
the
project
and
also
add
more
tools
or
assess
findings
that
the
project
might
not
might
have
skipped
in
their
in
their
own
work.
F
F
We
will
look
at
the
the
typical
threats
and
attack
vectors
of
a
project
to
and
put
ourselves
in
the
in
a
position
of
an
attacker
to
see
how
we
would
assess
a
project
and
how
we
could
damage
the
project
and
the
threat
model
is
useful
for
pretty
much
all
the
other
goals
that
we
are
achieving
in
their
audits.
So
we
use
the
threat
model
when
we
ordered
the
code.
We
use
the
thread
model
when
we
assess
the
fuzzing
of
the
project
and
also
when
we
assess
the
static
tooling
of
of
the
project.
F
F
Advisories
we're
running
through
the
security
disclosure
policy
so
that
they
go
through
the
process
of
receiving
a
community
based
disclosure
and
taking
it
all
the
way
through
to
making
a
issuing
a
cve
and
creating
a
public
advisory
and
yeah,
so
so
that
we
do
that
with.
If,
if
we,
if
we
see
a
clearly
severe
issue-
and
sometimes
the
project
will
also
do
it,
it
itself,
they,
they
will
receive
a
list
of
findings
at
the
end
of
the
audit,
and
then
they
will
assess
each
and
all
of
them.
F
And
if,
if
they
consider
an
issue
to
be
severe,
they
will
create
the
CV
themselves
and
we
have
experienced
both
both
sides
of
that.
We
also
look
at
how
a
project
maintains
the
source
code,
so
how
many
reviewers
are
there
do
commits
need
to
be
signed
Etc.
We
will
also
assess
the
risk
release
process,
how
our
artifacts,
built
and
shared
do
they
conform
to
Industry
standards
in
that
part
of
the
project,
maintenance
and
finally,
deployment
and
usage.
F
So
when
a
pro,
when
a
user
deploys
or
consumes
the
the
the
sort
of
the
product,
the
software
product,
are
they
secure
or
are
there?
Is
it?
Is
the
project
insecure
by
default,
or
are
there
some
security
holes
that
they
can
very
easily
fall
into?
So
is
it
easy
to
open
up
certain
attack
vectors
and
are
these
documents
well
documented
in
the
in
the
Project's
documentation,
so
yeah
that
that's
it
for
for
the
goals
as
a
as
a
high
level.
E
And
just
to
clarify,
you
initially
said
that
the
goals
are
usually
different
on
purpose
and
the
main
point
is
here:
we
kind
of
debate
these
things
with
with
the
maintenance
and
like
the
project,
the
project
that
we
are
working
with
during
the
initial
meeting
we
set
up
an
initial
set
of
like
these
are
the
areas
where
we
think
should
improve
stuff,
and
we
invite
this
in
the
sort
of
like
RFP,
but
also
during
the
initial
meeting
with
the
retainers.
We
present
a
lot
of
these
things
in
detail.
F
Right,
if,
if
I
can
add,
there
is
also
an
experimental
element
at
times
so
to
we.
We
will
have
different
or
depend
on
different
security
disciplines
with
the
purpose
of
attempting
or
experimenting
to
see
which
benefit
the
product
projects
significantly,
and
we
had
have
had
security
audits
where
forsing
ended
up
being
very
important
or
where
the
thread
model
link
was
was
so
important
that
it
let
that
focusing
on
that
revealed
more
findings
than
if
we
had
let
out
the
thread
modeling
so
and
as
well
as
aesthetic
analysis.
E
So
this
is
an
example.
Table
of
contents
is
for
istio
work
and
is
the
engagement
we
did
I.
Think
I
can't
remember
now,
roughly
eight
months
ago
so
and
that's
sort
of
an
example
of
where
you
can
see
how
the
goals
are
manifested
in
the
report
itself.
There's
a
fasting
session,
there's
a
threat
model
section.
E
There
are
an
issues
found
section
with
which
just
lists
issues
there's
an
assessment
of
salsa,
which
is
kind
of
related
to
the
you
know,
says:
release
process
software
supply
chain
security,
and
then
there
is
the
second
last
section
is
reviewer
fixes
for
issues
from
previous
audit,
which
is
kind
of
a
different
section,
because
he
still
had
a
previous
work
done
with
a
lot
of
issues
found
and
they
needed
to
assess
where
they
were
correctly
fixed.
So
that's
sort
of
specific
Choice
during
that
sense,
and
it's.
E
E
A
few
links,
if
you
are,
if
you,
if
you
need
them
just
to
see
how
well
I
guess
this
is
also
important
to
say
so.
These
are
links
to
the
announcements
for
each
audit.
So
an
important
step
for
the
cncf
is
that
we
come
out
with
publishable
artifacts
that
can
be
used
to
show
and
distribute
the
work
and
sort
of
present
it
to
the
world.
E
In
that
sense-
and
these
are
links
to
the
announcements
not
to
the
reports
and
just
to
get
an
in
a
feeling
of
how
the
cncf
likes
to
take
the
work
further
next
slide,
please
so
it
the
conclusions
around
sort
of
all
of
the
security
orders
we
have
done
so
far
is
something
along
the
lines
of
what
we
presented.
These
slides
we've
done
a
lot
of
audits
continuously,
and
the
focus
of
the
of
the
audience
are
both
to
cover
the
technical
aspects
and,
in
a
sense
also
to
improve
the
Project's
workflow
processes.
B
Thanks
David
and
Adam,
so
I
wanted
to
kind
of
bring
everyone
together
to
talk
about
this,
because
in
the
course
of
Performing
due
diligence
on
several
projects
that
are
seeking
to
move
levels,
particularly
ones
that
have
undergone
an
audit
when
we're
reviewing
the
security
audit,
that's
been
conducted
on
these
projects.
It
has
a
lot
of
really
great
information
for
project
maintainers
and
at
cubecon,
when
I
was
talking
with
a
few
maintainers
that
had
recently
undergone
an
audit
whether
or
not
it
was
by
adologics
or
another
entity.
B
There
was
some
Express
challenges
that
they
had
associated
with
it.
One
understanding
that
prioritization
that
David
had
alluded
to
earlier
is
how
do
we
understand?
Which
findings
are
the
most
important
ones
that
we
are
taking
into
consideration
for
remediation,
which
ones
can
wait
in
the
context
of
their
project,
because
it's
not
going
to
be
the
same
for
every
single
project.
How
do
we
fundamentally
introduce
more
secure
processes
or
guides
or
recommendations
to
projects
so
that
they
could
potentially
eliminate
donate
whole
classes
of
findings?
Justin.
G
Can
we
do
an
end
user
survey
to
find
out
what
end
users
want,
because
end
users
are
the
other
customer
for
these
and
I?
Don't
know
that
we've
ever
asked
them
what
they
would
like
to
see
and
I'd
be
really
interested
in
what
they
say
as
well,
because
I
think
that
that
they're,
the
kind
of
the
other
they're
the
stakeholder-
that's
not
really
represented
at
any
point
in
this
process.
At
the
moment,.
A
I
agree
that
end
users
are
are
definitely
not
like
represented
in
the
in
the
view
of
this
I
think
other
stuff
that
would
be
useful
is
like
looking
at
one
of
the
reports
in
the
executive
summary
piece
of
this,
the
the
overall
assessment
having
some
function
around
like
licensing
review
supply,
chain,
Security
reviews,
security
incident
review
process.
You
did
mention
that
you
go
through
a
Security
review.
B
Yep,
that's
a
good
point,
definitely
making
sure
that
any
of
the
processes
that
are
described
as
far
as
the
security
of
the
project
are
fully
exercised
continuously
and
not
that
it's
just
a
one-hof
that
it
was
that
it
worked.
That's
a
good
call
out
as
well
other
TUC
members
when
you're
reviewing
security
audits.
Are
there
things
that
you'd
like
to
see
that
come
out
of
them?
Are
there
questions
that
you
have
regarding
the
content
and
even
those
Toc
members
or
maintainers
on
the
call?
How
has
your
experience
been
with
undergoing
an
audit?
H
One
of
the
rather
basic
things
is
with
my
Prometheus
head-on.
We
didn't
always
have
people
who
were
deeply
familiar
with
go
as
a
language
which
sometimes
led
to
interesting
results
in
the
first
round.
This
is
more
on
the
how
to
do
it
not
on
the
result
set,
but
this
is
something
which
has
come
up
once
or
twice.
E
H
H
D
Folks
so
I'm
the
sub
Project
Lead
for
the
kubernetes
security
external
audit,
and
we
just
released
an
audit,
not
just
as
in
April
of
2023..
What
we've
learned
was
also
helpful
was
the
since
projects
are
maturing.
This
is
this
was
the
second
external
audit
for
kubernetes.
What
helped
us
was
also
a
review
of
the
first
one
of
2019
and
to
publish
that
review
like
what,
if
any
issues
were
still
open,
issues
were
closed
from
from
that
audit
any
and,
if
they're
still
open.
D
Why,
as
well,
just
to
be
transparent
and
have
that
we
publish
that
in
a
blog
on
kubernetes.io,
so
it
was
helpful
and
it
was.
It
was
a
totally
different
crew
that
as
well
that
ran
the
2019
audit
versus
the
the
windows
published
this
year,
so
that
that
that
helped
the
the
case
projects
in
that
as
well.
D
A
scope
can
be
very
big.
I
mean
the
kubernetes
of
rock
projects
are
very
big,
so
the
scope,
there's
not.
We
couldn't
fit
everything
in
scope
for
the
Audits
and
there's
always
things
that
we
wanted.
You
know
we
want
to
play
next
as
well.
So
that's
also
something
for
us
to
help
keep
in
mind
of
that
the
scope
can't
be
too
big
and,
and
that
sets
a
that
awesome
kind
of
presets
or
roadmap
for
the
next
audits
or
next
audits,
which
ones
we
missed.
D
E
Kind
of,
if
I
understand
correctly
in
a
sense,
specifying
the
limitations
of
what
was
done,
such
that
a
next
team
can
pick
up
on
on
those
limitations
exactly
yeah.
It's
also
important
I.
Think
that's!
That's
super
key.
It's
also
it's
interesting
when
you
mentioned
with
all
the
issues,
because
we
did
because
we
did
that
with
istio
where-
and
this
is
mentioned
in
the
report,
where
we
reviewed
old
issues
from
old,
an
old
order,
and
it
was
also
a
new
team
in
istio
and
they
weren't.
E
It's
like
it
wasn't
very
explicit
where
this
issue
was
fixed
by
this
this
place
or,
and
sometimes
it
was
difficult
to
sort
of
assess
whether
where
the
fix
was
and
so
on
and
I
guess.
This
is
kind
of
related,
also
like
tracking
had
not
been
done
as
well
as
it
could
be,
and
I
think
it's
kind
of
related
to
what
Emily
said
in
the
sense
of
they
might
not
have
had.
E
B
Do
you
all
often
find
that
understanding
those
trade-offs
or
having
them
explained
as
a
contributor
to
a
project
are
beneficial
in
understanding?
What
are
the
next
steps?
How
do
we
do
this
as
a
path
forward
than
the
course
and
then
making
a
documentation
decision
around
that
explaining
why
we
chose
to
do
something
a
particular
way
instead
of
another?
We
see
this
a
lot
with
some
projects
and
some
other
feature
design
discussions,
but
not
necessarily
for
security
issues
as
they
come
up
for
security
design
decisions.
E
I
think
we
often
find
a
the
way
projects
make
decisions
is
based
on
what
the
interprets
as
the
state
of
the
art.
So,
for
example,
at
some
point,
salsa
was
heavily
promoted
and
didn't
they
made
decision
of.
We
should
integrate
various
prominent
speeches
such
that
we
could
achieve
this
thing.
So
I
think
it's
often
understood
by
reference,
rather
than
necessary,
from
a
first
principle,
type
of
approach,
which
is
which
is
still
great,
I.
Think
that's
one
of
my
thoughts.
There.
F
Right
again,
add
another
one:
a
performance
versus
security
is
also
a
very,
very
typical
one.
So
a
missing
security
check
for
adding
a
missing
Security
check
can
affect
performance
and
that's
where
it
typically
where
it
becomes
very
difficult
to
for
projects
in
the
in
the
order
to
to
come
up
with
a
quick
fix
for
an
issue.
F
B
Yep,
another
item
that
we
had
talked
about
was
around
the
security
boundary
associated
with
some
of
the
findings
we're
conducting
the
audit
on
the
project.
In
some
cases,
it's
very
clear
what
is
in
scope
of
the
project
and
what
is
considered
a
security
design
issue
or
just
a
finding
against
the
project
and
in
other
cases
it's
a
little
bit
ambiguous.
B
B
G
A
lot
of
the
time
in
my
experience
with
that
what's
come
out
with
that,
is
that
the
project
disputes
the
findings
of
the
Auditors.
And
it's
not
it's
not
actually
very
helpful
because
it
just
sits
there
being
disputed
and
there's
no,
not
not
necessarily
a
resolution,
which
is
definitely
a
problem
because
that
just
kind
of
leaves
it
there's
an
open
and
there's
no
kind
of
there's.
G
Never
a
resolved
decision
I,
often
on
those
they
just
get
left
and
all
closed
as
weren't
fixed
or
something
which
is
tends
to
be
unhelpful,
so
I
kind
of
rather
it
got
resolved
at
the
audit
time
and
declare
policy
was
written
and
it
was
then
clearly
documented
one
way
or
the
other.
What
the
decision
was
about
that,
rather
than
being
left
to
post
audience,
When,
there's
less
pressure
to
actually
say
come
down
to
say
one
thing
clearly.
A
What
do
you
think
yeah
I
mean
I,
do
think
these
things
do
struggle
a
bit
because
of
the
system
because
of
that,
but
I
think
there's
two
parts
to
it.
Also
one
is
that,
like
this
is
sort
of
a
question
about
secure
defaults
like
if
you're
going
to
have
a
configurable
element,
are
you
are
you
choosing
a
more
secure
default,
or
are
you
choosing
one
that's
easier
to
configure
at
the
time
and
when
doing
a
Security
review,
it
might
be
nice
to
identify
and
I
think
that
you
probably
do
this?
A
You
probably
identify
those
places
where
configuration
could
be
made
more
secure
by
the
way.
You
know
then
then,
with
whatever
the
default
might
be,
and
then
the
challenge
you
have
is:
do
you
open
an
issue
against
that?
Or
do
you
just
document
that,
because,
if
it
for
the
most
part,
people
who
are
consuming
a
security
audit
as
a
vendor
when
they
see
that
you're
not
opening
an
issue
against
a
particular
issue
that
falls
right
to
the
bottom
of
the
list
of
things
to
sell
or
to
resolve?
Because
they
don't
particularly
care?
F
So
so
there
are
also
some
positive
sides
from
a
project
saying
or
a
project
simply
disputing
or
refuting
a
security
issue,
in
the
sense
that
it's
very
clear
to
this
to
the
project
that
it
it
doesn't
fall
into
our
our
scope
of
of
the
our
security
model
and
that's
a
very
positive
sign
as
well
that
the
product
it's
clear
to
the
maintainers
and
the
security
team
where
the
the
boundaries
are.
It
can
be
that
we
disagree.
E
Yeah
and
that's
exactly
how
we
essentially
resolve
it
and
I
would
say
it's
it's
positive
when
they
refute
it,
because
that
shows
the
boundary
and
then
what
we
say
is
we
we
tell
them
it's
just
just
documented
and
that's
that
just
specify
in
your
threat
model.
You
do
not
care
about
this
and
you
do
not
take
any
responsibility
for
that
and
don't
expose
this
and
so
on
and
so
on
and
and
then
they're
good
and
in
in
general.
In
this
case,
we
really
refer
to
the
onboard
fit
model
who
have
an
excellent
documentation.
E
That
says
very
clearly:
we
do
not
care
about
all
of
this.
We
only
care
about
this
and
it's
a
some
simple
threat
model,
but
it's
a
really
good
one
to
show
how
how
opinionated
they
are
in
terms
of
where
this
boundary
is
so
that's
kind
of
how
we
often
trigger
like
we.
We
say
we,
we
sort
of
directed
the
conversation,
because
we
plenty
of
times
have
read
report
issues
and
they
say:
stop
really
an
issue.
E
Is
it
and
then
we
say
well
if
it's
not,
as
you
just
documented
that
this
is
not
an
issue
because
of
this
this
and
that-
and
we
don't
consider
this
in
our
scope
and,
for
example,
like
at
the
most
common
example,
is
probably
when
we
assess
security
vulnerabilities
that
require
a
little
bit
of
privileges
within
the
system.
So
you
can
either
have
a
completely
external
attacker
from
from
from
from
a
place.
E
You
are
clear
with
and
so
on,
or
you
can
have
someone
that
might
have
a
little
bit
of
permissions
and
usually
when
you
increase
the
the
permissions
a
little
bit,
it's
still
within
some
threat
model
a
security
issue,
but
a
lot
of
Maintenance
might
not
consider
that
a
relevant.
You
should
trust
from
all
that
have
crossed
this
level
of
permissions
within
the
system
and
that's
where
then
sometimes
clarify
these.
So
we
usually
to
summarize,
we
usually
make
it
explicit
either
you
should
document
it
or
we
should
fix
it
and
that's.
F
Kind
of
right,
if
I
can
add
so
then
the
next
thing
is,
of
course,
once
it
it's
completely
crystal
clear
for
the
project,
then
they
can
start.
The
project
can
independently
start
to
discuss
on
and
work
on,
whether
it's
the
correct
thread
model
and
the
correct
approach.
But
but
at
least
it's
it's
Crystal
Clear
what
it
is,
what
what
the
what
the
security
boundary
is.
E
Last
one
last
one:
okay,
because
the
last
thing
I
guess
the
key
thing
is
we
we
tell
them
to
be
opinionated,
they
should
have
an
opinion
on
where
the
boundary
is
and
that's
that
we
leave
them
that
to
them
they
can
make
their
own
decision
on
what
they
want,
but
they
should
have
a
clear
opinion.
Okay,.
B
B
If
the
project
were
to
take
on
that
remediation,
for
instance,
what
other
thoughts
and
experiences
do
folks
have
that
we
could
provide
with
adalogics
to
potentially
improve
those
reports
either
as
a
Toc
member
consuming
them?
I
mean
I've
shared
a
lot
of
my
observations
and
my
experience
with
reviewing
these
reports,
but
I'm
Keen,
to
hear
from
others,
because
I
know
that
my
opinions
are
just
one-sided.
E
E
Thank
you,
I
guess.
My
question
would
be
moving
forward,
we'd
like
to
take
some
initiatives
to
adjust
these
reports,
and
then
we
are
coming
up
with
reports
in
the
in
the
immediate
almost
and
it
makes
sense
to
do
that.
I
think
I,
don't
know
what
you
prefer,
but
what
we
could
do
is
we
could
include
what
we
think
is.
It
would
make
sense
we
can
sort
of
send
an
email
to
to
Emilia
and
the
rest
and
highlight
this
specific,
like
we
did
this
for
this
specific
purpose.
E
B
Yep
I
think
that
would
be
good
sending
a
summary
of
some
of
the
changes
that
you're
looking
to
make
in
an
upcoming
audit
to
the
TOC
public
mailing
list.
I
think
would
be
fantastic
for
us.
I
think
Amy.
If
we
could
look
at
getting
an
end
user
survey
pulled
together
regarding
the
usability
of
audits
by
end
users
and
what
features
they'd
like
to
see,
added
or
and
improving
the
clarity
on
them
for
their
consumption.
I
think
that
would
be
beneficial,
and
then
we
can
share
that
with
the
auditors.
C
G
I
think
I
think
there's
potentially
other
options
with
end
users
as
well.
I.
Think
I'm,
like
advising
them
to
be
to
be
part
of
the
audit
process
like
some
of
the
some
of
the
customers
of
the
project.
For
example,
I,
don't
know,
I
think
that's
potentially
other
things
we
could
do
to
involve
them
more.
E
One
minor
caveat
here
is
I
just
wanted
to
highlight
that,
usually
all
these
are
quite
condensed,
there's
a
lot
of
work
in
a
relatively
short
period
of
time.
So
is
that
as
if
there's
a
scope
for
in
a
sense
putting
in
introducing
a
lot
more,
as
you
know
so
like
all
the
time
is
already
allocated
in
a
sense,
so
it
would
be
kind
of.
We
should
also
think
about
that.
Yeah.
E
G
B
A
I
was
saying
part
of
the
review
of
a
project
is
like
we'll
interview,
people
who
are
using
the
project
and
get
their
thoughts
about
the
project,
and
it
may
be
useful
in
that
time
to
pull
for
security
concerns
with
that.
The
consumer
of
the
project
has
about
the
project
and
feed
that
back
into
the
loop
I'm,
not
sure
exactly
how
we
could,
like
you
know,
make
that
part
of
the
process,
but
it
seems
like
that
would
be
useful.
E
F
Yeah
I
think
especially
useful
as
well
to
to
have
information
about
how
the
project
is
being
deployed
and
used
in
which
of
our
environments
and
how?
How
open
is
it
to
the
world
Etc?
It's
it's
it's
not
often,
but
it
happens
that
we
ask
the
projects
of
what
are
some
typical
deployment
patterns,
for
example,
of
a
given
project,
and
it's
not
super
clear
to
to
the
to
the
maintainers,
and
so
that
that
would
be
useful
information
for
sure.
E
I
think
one
last
comment
on
this:
what
doctor
suggested
it
kind
of
also
ties
back
to
the
security
boundary
as
that
might
be
used
for
establishing?
Where
should
the
boundaries
be?
If
certainly
a
lot
of
customers
or
users
have
probably
come
out
and
say
we
use
it
this
way,
but
the
maintainers
actually
don't
consider
this
as
something
that
should
be
secure
of
using
it.
That
way
might
have
impact
right.
F
As
an
anecdote,
we
have
done
a
security
audit
where
an
issue
was
reported
by
another
team
a
year
before
we
did
our
Audits
and
we
reported
the
same
order
to
the
project
and
in
that
year
time
span
of
one
year.
The
the
same
issue
became
a
very
a
severe
security
issue,
because
the
use
case
had
changed
and
suddenly
reading
the
local
file
system
was
not
untrusted
anymore,
so
that
that's
something
that
that
will
will
help
several
parties.
B
So
that's
a
good
call
out
to
have
well
I
would
like
to
thank
adalogics
for
their
time
and
and
talking
through
how
they're
how
they
conduct
an
audit
and
everyone
sharing
their
experiences
with
it.
I
think,
overall,
the
discussion
and
some
of
the
recommendations
that
have
come
out
of
it
will
greatly
increase
the
usability
of
the
audit
for
a
variety
of
interested
parties.
Maintainers
UC
members
potentially
end
users
and
adopters
as
well.