►
From YouTube: CI Component Catalog Q&A with Secure and Verify
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).
A
All
right
thanks
everybody
for
coming
so
so
we're
here
to
talk
about
the
CI
components
catalog,
so
we
I
mean
a
lot
of
folks.
Insecure,
started,
asking
questions
about
it
and
getting
interested
in
it,
and
so
we
want
to
thank
yeah
so
Dove
Fabio.
Thank
you
all
for
making
yourself
available
to
come.
Ask
come
come
answer
questions,
and
so
with
that
I
will
seed
the
floor
and
we've
got
agenda
document
going
and
so
popular
your
Fabio.
Your
first
sir.
B
I
just
wanted
to
there's
some
references
like
to
some
issues
that
might
be
related
to
what
we're
discussing
one
is
that
there's
an
issue
where
we
are
converting
existing
templates
to
components,
and
we
are
asking
to
team
members
to
to
dog
food
and
to
test
them,
and
another
one
is
kind
of
related
is
as
I'm
starting
to
document
some
of
the
steps
on
how
to
take
a
template
and
convert
into
a
component
and
what
kind
of
refactorings
we
can
do
there
like.
B
What
our
best
practices
in
in
in
the
way
of
writing
components,
and
this
ultimately,
will
be
converted
into
a
user
documentation
and
yeah
and
there's
also
Block
Boss
yeah.
C
A
D
Thank
you,
I
mean
that
is
very
interesting
to
me.
I
understand
a
few
of
the
benefits
that
are
mentioning
the
dogs
or
the
the
blueprints.
What
I've
missed
so
far
and
I
like
the
opportunity
to
dive
further
into
it,
but
is
from
the
customers
10
points
what
it
takes
to
move
from
a
catalog
from
a
template
to
a
component.
That's
our
at
least
in
competition.
It
is
for
me,
that's
the
main
concern
the
templates.
D
Is
our
integration
points
between
our
external
tools,
which
are
the
analyzers
with
the
mice,
and
this
is
enabled
by
default.
This
is
super
easy
for
the
customers.
They
just
have
to
drop
an
include
statement,
nothing
to
configure
by
default
and
that's
a
very
easy
process
by
default.
They
often
have
to
customize,
but
at
least
out
of
the
box.
This
is
a
very
simple
process.
D
Yeah.
My
first
sorry,
my
first
item
was:
we
are
excited
about
that
because,
as
I
said
we're
using
the
templates-
and
we
sometimes
have
some
difficulties
to
manage
them,
it's
it's
super
easy
to
to
break
existing
customers
configuration
because
they
are
so
flexible.
There
can
be
so
many
configuration
applied
on
top
of
our
our
default
content
that
is
difficult
to
match
them
over
time,
so
something
like
versioning
might
be
very
beneficial
for
us,
so
we're
super
excited
about
that.
D
But
what
you
should
expect
from
our
end
is
some
extra
cushion
because
moving
from
the
what
we
have
today
to
the
next
one,
the
the
components
might
be
super
descriptive
for
for
our
customers.
So
we
have
to
be
very,
very
well
prepared
for
making
that
transition.
B
D
Would
like
to
insert
today
the
templates
we
are
maintaining
them.
It's
a
very
important
part
of
our
integration.
Workflow.
We
don't
know
what
to
do
with
the
companies.
To
be
honest,
we
were
a
bit
surprised.
We
were
not
looking
enough
at
that
part,
so
focused
on
the
other
items.
So
when
we
we
learned
that
there
was
some
dark
footing
to
transition
the
security
templates
to
that
the
biggest
concern
for
me
is:
what
are
the
expectations
for
our
group?
Is
there
an
additional
maintenance
cost?
D
Should
we
take
a
support,
requests
for
customers
trying
those?
This
is
very
important
for
us
to
be
aware
about,
what's
being
done
there,
because
our
analyzers
are
made
to
be
integrated
within
the
template.
So
if
there
is
another
integration
point
that
we
don't
manage
ourselves,
we
can
miss
some
issues
and
we
can
break
customers
usages
because
we're
not
aware
about
what's
happening
there.
D
So
this
is
something
that
we
haven't
yet
settled
on,
but
this
is
part
of
this
conversation
is
so
far
while
understanding
that
season's
experimental
and
we're
trying
to
talk
with
that
internally,
there
is
no
expectation
from
the
security
teams
to
secure
analyzer
teams
to
maintain
those
templates
actively
and
and
be
responsible
for
dealing
with
customer
requests.
This
is
very
experimental
and
that's
fine,
because
we
have
very
high
pretty
features
to
work
on
right
now.
D
But
if
the
intent
product
wise
is
to
transition
all
the
templates
to
the
components,
then
we
definitely
need
to
be
much
more
involved
in
a
defined
timeline.
So
we
can
invest
time
into
that
process
because
I'm
expecting
that
to
be
a
a
complicated
transition.
Indeed,
we
haven't
had
the
opportunity
to
do
any
testing
on
our
end
so
far,
but
I'm
very
eager
to
see
how
that
works
and
again
what
the
customer
impact
for
transitioning
to
template,
to
components.
C
Yeah
I
would
say
that,
in
terms
of
like
the
product
roadmap,
I
do
see
us
eventually
like
as
a
company
and
migrate
from
templates
to
to
components.
Still
component
is
experimental.
We
might
have
like
additional
changes.
So
I
wouldn't
expect
the
team,
this
team,
to
maintain
the
components
for
the
customer
until
again
we'll
make
component
ga,
as
as
Fabio
mentioned.
C
The
intention
for
us
is
to
make
sure
first
of
all,
you
be
well
of
what
is
coming
and
what
is
the
expectation,
the
product
expectation
and
number
two
dog
food
try
it
out,
because
eventually
we
do
see
the
benefit
of
using
components
of
templates,
I'm
hoping
you
can
see
it
also,
and
if
not,
we
can
explain,
and
so
the
more
you
use
it
internally.
You
can
provide
us
the
feedback
and
then
we
can
quickly
take
it
back
and
implement
it
with
our
engineers.
D
Cool
yeah,
thank
you
for
adding
details
on
that.
Again,
we
don't
want
to
be
looking
at.
We
pushing
back
we're
interested
into
that.
It's
just
a
matter
of
making
sure
that
we
relying
on
the
on
the
responsibility
there
and
and
the
risk
that
comes
with
these
changes.
D
The
second
question
was
more
about
the
timeline.
I
was
looking
at
the
duration
plan
in
the
Epic,
and
it
looked
to
me
that
it
was
around
16.3
that
we
were
planning
to
to
move
to.
Ga
is
that
is
that
correct.
B
Is
too
soon
for
16-3,
everyone
still
moved
to
Beta.
First
and
and
ideally
you
know,
try
to
complete
dog
food
in
as
quick
as
possible.
So
we
can.
If
we
can
fix
anything
that
we
can
fix,
even
kind
of
introduce
breaking
changes
if
we
have
to
and
then
move
it
to
Beta
and
then
from
there,
and
we
start
the
move
to
ga.
C
C
Yeah
I
think
that
by
63,
maybe
we
can
move
it
to
better,
not
sure
we
still
have
some
discussions
about
the
architecture
of
the
component
and
also
based
on
the
feedback
policy.
We
can
change
things
so
to
remove
something
it
will
be
from
experimental
to
better
and
only
then
we'll
move
it
to
GA.
So
I
assume
that
once
once
we
move
component
from
experimental
to
better,
this
will
probably
signal
okay,
like
Our
intention
to
to
make
sure
it
is.
It
is
GA-
and
this
is
this-
will
probably
signal.
Okay.
C
Now
we
need
to
make
the
preparation,
for
you
know,
start
converting,
some
of
those
components
into
template
and
and
as
I
mentioned,
if
you
use
it,
I
will
show
you
to
see
the
benefit,
but
you
you
that
eventually
will
get
to
your
users
and
and
based
on
and
based
on
that.
C
I
would
expect
that,
like
anyone
that
has
templates
we'll
convert
those
into
into
components,
because,
basically
maybe
I
can
elaborate
a
bit
about
the
the
advantage
of
of
components
over
over
templates
and
I
guess
there
are,
there
are
a
few
and
number
one
goes.
We
have
like
full
version
control.
So
you
can,
you
can
mention
specific
version,
you
can
tag
a
specific
version,
and
so
there
is,
there
is
no
pool
of
breaking
or
introducing
breaking
change
there.
Is
there
isn't
the
concept?
Okay
change?
C
Basically,
because
everything
will
be
version,
and
this
is
number
one
number
two.
When
users
will
use
it,
they
have
a
a
way
to
opt
in
for
the
latest,
so
they
could
in
their
pattern.
When
they
are
using
it
they
could
it
will
always.
You
could
always
use
the
latest
verified
component
and
I'm
saying
verified,
because
who
can
introduce
tests
as
a
part
of
your
workflow
and
customers?
C
C
Basically,
it
will
be
the
single
source
of
Truth
to
see
what
are
the
available
components
in
your
organization,
so
it
actually
Amplified
the
the
the
value
of
component
with
with
that
catalog,
so
component
by
itself
makes
it
they
have
like
a
doing
break
break
a
great
value
over
templates.
But
if
you
combine
it
with
with
the
catalog,
it
will
even
be
provided
even
better
value
forecast
for
customers.
D
Yeah,
that's
a
very
interesting
point.
There
is
a
drawback,
though,
that
we
need
to
further
investigate
is
versioning
is
great
for
stability
for
the
users.
The
Contour
part
is
on
maintenance
cost
for
us,
because
it
means
we
have
to
maintain
a
compatibility
Matrix
between
all
the
versions
that
we
currently
support
on
one
end
on
the
component.
On
the
other
hand,
if
there
is
analyzers
there
is
a
platform
and,
on
the
other
hand,
with
the
analyzers.
D
This
is
something
that
we
encountered
in
the
past
and,
to
be
honest,
having
just
one
template
has
many
disadvantages,
because
well
it's
not
version,
but
the
main
advantage
is
there's
just
single
version
of
the
template
that
we
have
to
maintain
for
a
given
version
of
rails.
So
this
is
another
problem
that
we're
facing,
for
instance,
with
the
security
report
format.
So
we
have
a
schema.
A
Json
schema
for
the
security
report
that
we
send
to
the
race
platform,
and
we
have
this
compatibility,
Matrix
issue.
D
It
makes
things
much
more
complicated,
so
it's
good
in
one
way,
but
it
can
come
with
added
added
maintenance
costs.
So
that's
a
very
interesting
point
for
us
to
dig
further
into
and
and
figure
out
what
what
would
be
the
greatest
release
cycle
and
support
policy
for
versions.
So
that
way
we
don't
explore
the
maintenance
costs
on
our
end,
but
yeah,
definitely
that
that
makes
things
more
reliable
for
for
customers.
C
Yeah
I
would
assume
yes,
every
team
will
have
their
own
to
Define
their
own
policy,
for
you
know
for
for
making
sure
we
are
Backward
Compatible
and
like
what
are
the
versions
that
you
support.
This
is
something
that
I
would
say:
it's
not
something
for
us
to
decide.
I,
guess
everything
we
do
what
they
think
should
do.
We
will
just
provide
you
with
the
tools
with
the
means
you'll
decide
if
you
want
to
have
like
I,
don't
know,
support
like
two
versions
or
only
the
latest
I'm,
not
I'm,
not
really
sure.
D
Yeah,
but
at
that
moment
the
prime
is
I
mean
it's
not
a
big
problem
again,
and
this
comes
maybe
with
some
other
things.
We
need
to
train
the
customers
on,
but
if
your
customer
is
pinning
the
component
to
a
given
version,
for
instance,
at
the
time
we
drop
support
for
that
one,
they
have
to
manually
update
their
template
to
Brand
the
version
of
the
component
they're
using
so
again
that
that's
good
for
stability.
I
can
disagree
on
that,
but
this
is
a
first
customer
impact.
D
To
me
is
that
they
have
a
manual
action
to
do
anytime,
where
switching
versions
at
least
doing
some
breaking
changes,
and
they
don't
want
to
have
them
apply
to
them
by
following
the
latest
tag,
for
instance.
So
that's
that's.
Fine!
That's,
okay,
but
that's
a
part
of
thing
that
we
need
to
consider
now
when
to
to
make
the
customer
aware
of
that
that
new
approach.
B
Yeah
I
think
this
depends.
Then
every
component
will
have
its
own
strategy
for
support
so
and
recommended
strategy.
So
I
think
it's
up
maybe
or
the
one
thing
we're
doing
with
the
components
is
that
there
is
also
integrated
documentation
for
every
component.
There's
also
a
discussion
like.
Should
we
even
maintain
documentation
on
the
gitlab
docs
for
specific
analyzers
like
how
to
you
know,
use
and
customize
like
templates,
or
should
this
documentation
go
into
the
components?
Read
me
because,
like
GitHub
docs,
we
can
specify
this
is
the
capabilities
we
provide.
B
If
you
want
to
know
how
to
use
this
in
your
CI
yaml
and
how
to
customize
for
specific
how
to
tune
it,
particularly
you
can
refer
to
the
docs
in
the
component,
and
so
there
is
like.
Maybe
every
component
will
have
its
own
recommended
way
of
dealing
with
version
like
upgrades
and
things
like
that,
and
there's
definitely
maybe
for
a
lot
of
security
products
using
the
latest.
B
If
we
maintain
backward
compatibility,
the
user
latest,
maybe
the
the
the
one
kind
of
a
lot
of
the
time
kind
of
suggested,
but
some
for
some
customer
might
be
better
to
pin
it
or
to
pin
it.
If
we
are
introducing
a
breaking
change,
so
they
actually
know
they
have
to
pin
it.
So
they
don't
get
the
braking
change
immediately.
B
Stuff
like
that,
but
yeah
I
think
it's
interesting
to
see
like
if
there
is
anything
in
the
design
that
makes
life
more
difficult
and
at
the
same
time
we
are
kind
of
trying
to
understand
what
are
the
the
general
workflows
that
we
can
support
like
across
the
in
general,
the
software
development
life
cycle,
but
yeah.
If
we
encounter
anything
that
is
problematic,
you
know,
please
let
us
know
what
we
are
kind
of
definitely
eager
to
get
some
some
feedback
on
that.
E
Okay,
I
guess.
The
next
question
is
mine,
so
I
just
wanted
to
check
if
we
like
one
of
the
way
how
we
allow
users
to
kind
of
modify
certain
places,
just
like
basically
modified
template,
so
it's
very
important,
the
workflow,
so
our
components
support
the
same
feature
as
well.
E
B
B
Okay
yeah,
so
it
should
work
the
same
way.
So
if
so,
there
is
things
you
can
do
with
components
here,
you
can
actually
take
the
template,
as
is
move
into
like
a
directory
structure
that
is
supported
by
components
and
that
works.
As
is
look,
you
are
translating
like
a
template,
token
point
just
then
it
is
some
best
practices
that
I'm
documenting
on
the
one
of
the
first
links
in
the
top
of
the
page
that
we
actually
do
certain
things
better.
B
Nowadays
we
are,
we
introduce
inputs
for
for
templates,
so
certain
things
could
be
leveraged
through
inputs
like,
for
example,
one
of
typical
kind
of
anti-pattern.
Nowadays,
since
we
have
inputs,
would
be
use.
You
hard
code
like
a
stage
into
a
job
into
the
template,
but
then,
if
you
actually
don't
want
a
job
to
run
in
the
test
page,
you
want
to
run
a
different
stage.
Then
you
have
to
go
and
override
the
stage
for
every
job
that
are
included.
B
So
now
you
know
in
some
ways
you
have
to
know
the
implementation
details
of
the
template
to
be
able
to
override
it.
Instead,
there
is
some
kind
of
best
practice.
We
are
starting
to
recommend,
like
use
inputs
to
say,
I,
want
to
add
this
bunch
of
jobs
in
this
stage
and
then,
if
you
want
to,
can
still
override
them
afterwards,
but
like
at
least
you
can
inject
input
and
not
caring
too
much
about
how
the
jobs
are
structured
and
a
lot
of
the
override
can
be
done
that
way.
B
E
Okay,
great
and
the
second
question,
which
is
basically
I,
didn't
find
it
in
the
implementation
and
in
the
issue,
but
are
the
components
supposed
to
replace
template
in
the
future
as
it's
supposed
to
be
kind
of
new
version
of
the
same
feature?.
C
Yeah
I
I
think
like
internally.
We
discussed
this
with
the
team
and
we
kind
of
think
that
this
is
where
we
are
heading
but
I
think
templates
are
super
popular
with
our
users,
so
it
will
take
a
significant
amount
of
time
until
we
can
actually
say.
Okay,
we
are
getting
rid
of
templates
and
our
components
is
the
is
the
new
paper.
This
is
indeed
our
aspiration.
C
This
is
where
we
would
like
to
see
everyone's
going,
but
I
would
say:
I
I
will
be
very
cautious
of
like
giving
like
you
know
those
this
kind
of
statements
before
we
actually
test
it
properly
before
we
get
into
the
hands
of
the
customers.
So
to
answer
the
question:
yes,
but
you
know
it
depends
I
hate
to
give
it
depends,
but
it
really
depends.
B
The
the
results
are
also
in
our
architecture,
blueprint
that,
where
we
design
components
and
try
to
define
a
vision
there
and
again,
all
of
this
kind
of
future
proof
feature
statements
are,
are
not
gonna
be
to
happen,
but
it's
kind
of
part
of
the
vision,
and
one
of
this
aspect
is
that
we
wanted
to
make
components
also
available
across
gitlab
instances,
so
that
you
can
say
on
a
self-managed
instance.
B
So
this
will
be
like
and
also
could
be
a
way
for
us
to
eventually
move
away
from
templates,
because
we
can
move
away
from
templates
easily
or
relatively
easily
in
principle
on
on
SAS.
But
the
problem
is
more:
how
do
we
ship?
You
know
what
we
currently
you
know
ship
with
with
the
gitlab
instance,
the
templates?
How
can
user
have
the
same
capabilities,
and
so
having
the
ability
of
using
templates
from
other
instances
will
be
a
way
for
us
to
to
start
thinking
about
possibly
the
timing
templates,
but.
E
B
E
And
I
have
follow-up
questions
in
this
case.
What
about
applying
instances?
Because
it's
kind
of
very
big
question
for
security
analyzers?
We
need
to
support
offline
instances
so
how?
In
this
case,
it
will
work
with
like
for
some
self-managed
instance,
which
need
to
get
a
component
from
github.com.
But
it's
going
to
plan
and
doesn't
have
an
access
to
the
internet.
B
So
this
is
kind
of
yeah
what's
discussed
in
this,
and
we
still
don't
know
yet
in
the
details,
but
they
are.
The
idea
could
be
that
you
could
so
we
could
either
pre-populate
certain
projects
as
a
components
project
with
a
git
lab
instance.
So,
in
a
way,
instead
of
having
templates,
you
have
instance.
B
Or
have
ability
to
import
templates
and
console
components
from
using
git,
for
example?
So
so
you
will
have
a
way
of
porting
this
repositories
over
to
the
same
network
and
then
load
them
like
import
them
into
Google
app
and
then
once
important
project.
This
should
work
as
other
components,
project
and
yeah.
So
there's
kind
of
the
sum
of
ideas,
but
nothing
kind
of
actually
supported
today.
D
D
Yeah.
Indeed,
that's
that's
a
good
question,
and
this
is
to
me
something
that
will
be
part
of
the
the
ga
process.
Again,
we're
not
there
yet,
but
this
is
the
kind
of
feedback
that
you
might
expect
from
us
there.
There
are
very
Advanced
usage
on
the
template
from
our
end
and
ultimate
customer
are
very
very.
They
have
had
a
high
expectations,
so
it's
difficult
sometimes
so
I
just
move
on
to
the
next
one.
D
Then
what
are
your
expectations
for
the
dog
quitting
process
like
let's
say
the
prayer
of
time
from
now
to
around
16-3,
when
you'd
like
to
move
to
Beta,
do
you
expect
to
do
the
testing
on
yours
on
your
own,
or
do
you
expect
to
did
I
get
that
part
to
each
group,
which
is
supposedly
irresponsible
for
the
for
the
competent
and
the
reason
I'm
asking
is
particularly
is
a
entirely
planning
wise
just
to
make
sure
we
have
the
corresponding
capacity
allocated
for
that
work,
and
this
is
validated
with
our
respective
product
managers.
C
Yeah
I
think
I
think
that
our
team
could
only
support
migration
or
moving
from
template
to
component
but
validating
the
the
reliability
of
of
each
template
is
something
that
I
don't
think
we
could
actually
do
so,
while
I
would
very
much
like
for
other
team
to
start
converting
by
themselves.
C
Templates
to
component
I
know
that
this
is
something
that,
especially
at
the
beginning,
something
that
probably
will
be
in
some
parts
out
in
responsibility
like
we've
done
with
several
components,
and
maybe
we'll
do
some
hand
holder
holding
later
on
with
other
teams,
but
to
validate
the
the
reliability
of
each
component
is
something
that
we
simply
could
not
do.
So.
It's
something
that
we
really
rely
on
the
respective
team.
Each
team
for
the
specific
templates
components
that
they
are
responsible
for.
D
Then
my
question
may
be
entirely
administrative,
but
is
that
something
that
you
brought
into
the
product
organization
to
get
some
buying
from
your
Contour
product
so
that
they
get
that
prioritizing
their
respective
roadmap?
Because
currently
the
way
it's
coming
at
us
is
through
the
engineering
organization?
And
this
means
that
I-
don't
I,
don't
mind
about
that.
But
this
means
that
it's
up
to
us
to
each
engineering
team
to
bring
that
back
to
the
respective
product
manager
for
prioritization
I,
don't
know
about
other
groups,
but
definitely
in
our.
D
We
have
high
pressure
to
complete
some
other
items.
So
I
don't
know
what
would
be
the
response
for
my
APM
about
how
much
time
I
can
spend
on
that.
So
that's
why
I'm
I'm,
suggesting
that
maybe
on
your
side,
you're
also
trying
to
get
some
buying
from
your
Contour
part,
so
that
a
call
the
company
there
is
a
bit
of
time
allocated
for
each
crisping
group
to
to
work
on
that
I.
Think
that's!
D
A
great
Improvement
I
know
it's
difficult
right
now
to
prioritize,
because
there
are
just
so
many
things
that
are
high
priority,
but
it
would
be
great
yeah
if
that
also
gets
some
buying
for
their
product
teams.
B
Yeah
just
a
announce
on
the
dog
food,
so
we
we've
been
creating
some
converting
some
templates
to
components
just
for
the
sake
of
exercise
and
validate
first
ourselves.
What's
that
experience
look
like,
but
ideally
we
would
like
to
see
teams
to
convert
components
by
themselves
and
even
and
get
feedback
for
you
know.
Is
it
difficult?
Is
it
easy?
You
know,
what
did
you
find
difficult,
because
this
is
kind
of
validation
is
very
important
to
us
to
understand.
You
know
this.
B
Even
you
know
validating
how
easy
is
the
migration
you
know.
Is
there
something
we
we
should
have
made
better
in
the
design
or
things
like
that
or
we
should
fix
rather
than
like
giving
like
a
component.
That
is
almost
done.
B
It
just
needs
like
some
extensive
testing
and
maybe
some
fixes
it's
great
at
the
beginning,
but
like
ideally,
we
would
like
also
to
see
like
a
just
convert
that
a
component
from
scratch
that
you
know,
without
maybe
following
a
documentation
that
we
created
some
some
practice
there
and
give
us
feedback
on
on
this
process.
F
Maybe
piggybacking
off
that
question:
you've
converted
the
SAS
and
the
code
quality
templates
over
to
the
catalog.
So
thank
you
for
doing
that.
We're
right
now
testing
that,
similarly
to
Olivier's
question
like
if,
if
we're
planning
on
doing
the
migration
for
the
secret
detection,
template
as
well,
and
then
the
testing
for
that,
what
that
need
to
fall
within
that
same
timeline
before
we
hit
beta
or
I,
guess
what
are
the
timeline
expectations
of
doing
the
migration,
as
well
as
the
testing
of
the
validation?
C
B
The
sooner
the
sooner
the
more
feedback
we
get,
the
sooner
we
get
the
feedback
from
from
dog
fooding,
the
more
confident
we
will
fail
in
moving
from
experiment
to
better
but
I.
Think
with
that
x76
dog
fooding.
You
know
we
will
feel
like
less
comfortable
immediately
better
because
then,
if
we
realize
there's
something
that
we
might
want
to
introduce
breaking
changes
with
better
still
possible.
But
you
know
it's
it's
a
more
kind
of
it's
ideal
to
introduce
breaking
changes
in
in
the
experiment,
phase.
B
So
yeah
there's
no
strict
timeline
but
at
the
same
time
yeah
this
the
sooner
we
get
some
feedback,
and
it
might
be
that
you
know
we
don't
have
to
convert
a
certain
number
of
components
to
get
this
confidence.
B
It
could
be
that
once
we
do
with
a
few
components,
is
it's
enough
but
I
think
it's
more
about
okay
yeah
for
us
to
have
feedback,
so
we
feel
confident
to
move
from
from
experiment
to
better.
B
C
I
have
to
say
that,
because
you
start
using
components,
regardless
of
the
templates
that
we
have
today
and
so
we'll
get
feedback
from
them,
and
eventually
we'll
move
templates
to
components
and
and
if
indeed,
there
will
be
like
an
adoption,
as
we
expect
I
would
expect
customers
to
actually
ask
you.
Okay,
can
we
create
a
component,
a
form
template
because
of
the
benefit
that
they
have
because
of
the
work
that
we
are
doing
with
with
the
catalog,
because
of
basically
the
need
that
we
see
that
there
is.
C
D
D
We
do
have
some
templates
that
we
maintain
ourselves
in
another
location,
I'm,
seeing
I'm
thinking
about
them.
The
dev
template
that
we
use
across
all
the
analyzers
team,
for
instance.
D
That
is
a
great
example
for
us
to
maybe
try
to
use
component
instead
in
that,
in
that
case,
we
may
be
Focus
too
much
the
dark
feeling
about
the
founder
template
that
we
sent
to
customer,
but
maybe
more
of
the
value
that
the
components
bring
is
for
us
as
developer
as
builder
of
configuration,
CI
configuration
and
it's
related
to
the
latest
point
I
made
there
is
that
to
me
when
they
look
first
glance.
D
Has
this
feature
I
see
a
lot
of
value
coming
from
the
catalog
and
the
ability
to
easily
build
a
configuration
from
company
reusable
components,
just
the
technical
part,
just
the
component
itself.
D
I,
don't
use
that
bringing
a
ton
of
value
to
the
customer
right
now
and
that's
why
we
will
look
into
that,
but
I'm
not
so
sure
that
dog
footing,
just
that
part,
will
provide
you
a
lot
of
interesting
feedback
from
the
customer
perspective
on
our
security
templates,
but
definitely
I
think
it
could
be
interesting
to
harvest
testing
that
more
for
our
development
configurations.
C
Yeah
I
I
I
agree
with
that.
I
I
I'll
also
say
that
a
component
is
the
smallest
building
block
of
a
catalog,
and
if
we
want
to
build
a
product
right
bottom
up,
we
need
to
start
testing,
like
the
smallest
part
that
we
have,
because
if
you
won't
get
inside,
then
eventually
we'll
have
this
really
nice
catalog.
But
the
building
block
that
actually
construct
the
catalog
will
not
provide.
The
value
would
not
be
will
not
will
not
work
as
as
we
expect
them
to
work,
and
then,
basically
we
are
shaking
the
foundation
of
the
catalog.
C
Then,
if
we
need
to
change
or
switch
something,
we
eventually
could
like
disrupt
the
the
customer
workflow.
This
is
why,
when
we
introduce
the
component,
we
say:
okay,
let's
introduce
it.
Let's
release
it.
Let's
dog
food
it
there
is
a
value.
There
is
some
value
with
that.
But
yes,
I
agree
that
the
major
value
will
come
with
with
the
with
the
catalog.
B
Just
to
add
a
very
quickly
since
we
are
out
of
time
and
one
aspect
of
dog
fooding.
This,
which
is
perfectly
legit,
is
to
if
we
create
the
static
analyzer,
for
example,
some
of
the
security
products
in
components
we
convert
them
to
components
and
we
dog
food
them
in
get
a
lab
project.
You
know,
rather
than
using
the
templates
we
use
the
component.
That's
the
perfect
way
for
us
dog
food
and
start
to
get
feedback
on
this.
B
We
don't
have
to
get
the
customers
to
use
components,
that's
not
kind
of
necessarily
the
goal,
but
it
will
be
like,
let's
at
least
start
using
internally
the
components
and
and
see
see
what
it
feels
like.
A
A
With
that
I
think,
since
we
are
a
bit
over
time,
thank
you,
everybody
for
for
sticking
around
we'll
make
that
the
last
word
thank
you
for
taking
your
time,
but
we've
got
a
lot
of
links
and
a
lot
of
information
here.
So
if
anybody
has
additional
questions,
please,
let's,
let's
continue
the
conversation,
async
I'm,
going
to
let
this
video
process
and
intent
to
take
this
up
to
gitlab
and
filters
just
to
make
sure
everybody
knows
where
this
is
going.
A
So
thank
you
for
your
time
today
everybody
and
have
a
good
rest
of
your
day.
We'll
talk,
soon
see
ya.