►
From YouTube: 12.3 Kickoff - Secure:SCA
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
So
it
looks
like
this
one
was
originally
in
for
11:11
and
kind
of
snuck
out.
So
it's
back
in
now
and
that's
it
looks
like
a
UX
change.
Mostly
it's
tagged
with
front
end
and
no
back
end.
So
I
don't
think.
There's
any
backend
work
for
it
for
a
license
management
for
dotnet
core.
This
one
doesn't
have
front-end
or
back-end
tags.
I,
don't
know
if
anyone's
really
done
an
evaluation
on
this
one.
Yet
back.
B
A
C
A
B
Pi
catches,
the
talk
is
the
registry
for
PHP
packages.
This
is
back,
and
only-
and
actually
this
might
be
delayed
to
next
myself,
depending
on
the
outcome
of
engineering
discovery
about
whether
or
not
we
want
to
kill
the
existing
client-server
architecture
for
gymnasium
I.
Just
a
little
comment,
just
before
the
de
million.
A
A
All
right,
so
that's
all
of
our
bugs.
The
next
big
item
is
docker
in
docker
removal
for
dependency
scanning.
This
one
has
been
customers
complaining
about
the
need
for
darker
and
darker.
Apparently
it
leads
to
overly
complex
items
so
across
all
of
our
different
scans
and
tools,
we're
looking
to
get
rid
of
it,
and
this
one
seems
to
have
like
a
proposal
with
a
plan
in
it.
But
has
this
one
actually
been
thought
through
thoroughly
enough
that
we
know
exactly
what
we
need
to
do.
B
B
There
are
all
day
verbose,
but
I
think
some
are
likely
to
be
closed
because
it
requires
a
lot
of
refactor
on
the
front
end
and
they've
not
tell
me
yet
everything
in
terms
at
1:00.
So
hopefully
this
will
be
done
interrupted
to
I
know.
That
is.
The
team
is
also
working
on
the
exact
same
issue
for
SAS,
because
Sasson
defense
is
tending
share,
the
same
orchestration
layer.
So
if
they
finish
in
12.2,
then
we
will
already
have
the
implementation
paths
and
just
have
to
replicate
it
for
dependency
scanning.
B
Otherwise,
if
they
are
pushing
it
to
chapter
3,
this
means
to
team.
We
work
on
the
same
exact
implementation
plan
in
the
same
release,
so
I'd
say
depending
on
the
outcome
of
SAS
issue.
We
should
ever
just
follow
what
they've
done
or
postpone
this
one
or
work
together
and
just
wait
for
one
implementation
to
be
done
and
replicate
it
to
the
other,
because
there
is
no
point
of
value
to
T's.
Working
at
the
same
time.
Understand
shoot
now.
A
C
C
A
B
Now
that
we've
moved
the
documentation
from
nozzles
custom
project
to
the
main
gate
lab
documentation,
it's
a
bit
tedious
to
go
there
and
add
a
need
each
time
we're
changing
the
project.
So
it
was
thought
to
find
a
way
to
automatically
extract
that
documentation
from
the
code
itself
leveraging
some
tools.
But
as
we're
going
to
remove
the
orchestration
layer,
we
probably
have
to
drop
some
of
the
work
we
will
be
doing
here
so
again
as
the
documentation
has
been
touched
or
is
being
pushed
right.
B
Now
it's
already
accurate
and
we
are
a
creamers
request
to
take
it
as
far
as
well,
especially
changes
to
the
code
itself.
So
I
don't
think
this
is
a
very
high
priority
and
this
is
a
Paxton
change
by
the
way,
so
it
doesn't
bring
value
to
the
customer.
It
will
just
make
our
life
easier
when
we
are
digging
things
right.
A
How
would
that
there
have
been
at
least
two
customers
complaining
that
it
takes?
There
is
a
delay
of
like
one
release
or
one
month
between
when
something
changes
and
the
docs
get
updated,
sometimes
slightly
longer,
and
that
it
might
be
due
to
capacity
on
our
Doc's
team
or
something
else
I'm,
not
sure.
So.
B
It
was
mainly
due
to
the
fact
that
it
wasn't
there
first,
so
it
was
not
part
of
the
usual
process
when
implementing
a
feature
to
put
the
documentation
there.
So
people
had
to
refer
to
the
me
and
the
project.
It
was
not
straightforward,
but
now
that
we
have
by
default
the
documentation
there
and
not
anymore,
in
the
rainy
part
of
the
issue
that
mentioned
to
get
the
documentation
as
developers
engineer,
to
check
the
documentation
on
the
negative
dog.
So
I
don't
expect
this
video
to
happen
again.
B
Unless
the
engineer
is
missing
like
where
we
are
missing,
the
users
being
I
think
that
that,
but
in
the
normal
process
the
documentation
should
be
kept
up
to
date
and
we
have
now
checkboxes.
So
if
you
go
through
the
issue
and
it
and
the
checkbox
is
not
ticked,
you
might
expect
you
as
the
the
engineer,
to
complete
the
work
before
closing
the
issue.
B
Maybe
we
can
keep
it
for
grooming
and
see
if
there
is
a
need
to
to
do
that
either.
I
haven't
read
out
the
the
proposal
there
and
there
is
already
a
tool
that
I
think
it's
probably
to
keep
a
good
package
them
that
automatically.
But
again
we
issued
that
we
are
going
to
change
drastically
the
architecture
by
removing
the
orchestrator.
So
the
main
goal
here
was
to
change
to
explore
the
the
option
generated
automatically
from
the
orchestrator
and
and
the
common
command
project
list.
A
A
C
A
I
guess
the
question
sort
of
are
I
know
we
have
some
api's
for
some
of
our
things
right
now.
I
know
we're
cleaning
up
some
of
our
back
end
logic,
so
that,
like
our
reports,
are
more
consolidated
but
I
guess
for
this
one.
What
work
is
actually
needed
like
I?
Don't
want
us
to
do
any
kind
of
integration
work
but
like
in
order
to
have
API
is
for
people
to
push
and
pull
data.
What
are
we
missing
like
what
back-end
clean
up?
B
B
B
So
last
comment
explain
a
bit
what's
the
current
state
and
what
can
we
provide
four-person
poll
today
and
what
are
the
limitation
of
those
so
to
quickly
recap?
This
we
need
first
class
winner
ability
to
provide
a
meaningful
API
to
person
to
push
data
to
the
dashboards.
We
currently
have
a
pull
API
that
she's
reliable
enough
I'd
say
it's
still
in
alpha
stage,
but
I
mean
at
least
they
can
get
the
data
right
now.
B
And
this
will
stop
the
push
of
data
for
the
dashboards,
but
if
you
want
to
push
data
to
the
report
metric
course,
widget
and
pipeline
view,
this
might
need
further
investigation,
because
there
we
have
more
constraint
how
you
can
identify
the
variability
that
we
can
do
them
and
do
some
operations
on
them.
So
it's
a
bit
harder.
You
can
do
it
right
now.
B
Actually,
if
you
just
have
a
job
that
outputs
a
reportage
isn't
report,
that
is
matching
our
format
that
will
work,
but
there
are
a
lot
of
deep
constraint
on
the
on
the
property
that
this
report
will
contain
and
it's
hard
to
explain
this.
They
are
not
well
documented
and
it's
there
is
no
way
to
clearly
validate
that.
So,
even
if
it
works,
it
might
generate
some
well
behavior
because
of
the
logic
that
we
are
the
manipulation
that
we
are
operating
on.
This
is
a
report
that
is
until
now
knowledge
right
now,
so.
A
A
So
it
doesn't
get
lost
and
then
the
next
three
ones
are
items
that
I
saw
for
gymnasium,
because
I
know
we're
trying
to
do
some
work
around
that
and
I'm
not
sure
if
any
more
issues
are
gonna
pop
up
as
a
result
of
the
work
on
the
architecture
but
I
figured,
we
need
to
kind
of
at
least
keep
a
couple
of
issues
related
to
that
in
each
one
of
our
releases,
so
that
we
aren't
that
we're
making
progress
on
that,
so
the
API
endpoint
to
patch
an
advisory.
Yes,.
B
This
one
is
also
on
server
side
so,
depending
on
the
outcome
of
the
discovery
of
whether
or
not
we
are
keeping
this
architecture.
So
it's
just
one
she's,
probably
late,
but
the
other
one
are
interesting
to
be
kept
because
those
are
for
the
word
before
putting
data
into
the
repository.
So
to
make
it
clear
to
everyone.
We
have
several
steps
in
the
process
of
feeding
the
database,
so
we're
taking
external
sources,
fetching
the
sorry-sorry
in
the
data
from
them
and
putting
them
into
the
gymnasium
repository
and
from
them.
B
We
are
creating
the
data
from
normalizing
it
and
pushing
it
to
the
PostgreSQL
database
to
be
to
the
base
to
be
consumed
by
the
API.
So
we
need
the
data
to
be
on
the
server
side
to
be
consumed
by
the
differences
caning.
But
all
this
work
is
currently
a
bit
posed
because
of
the
current
discussion
about
the
the
client-server
architecture,
but
all
the
work,
the
work
to
fight
that
external
sources.
Data
and
put
that
into
the
repository
is
worth
wise,
because
if
we
switch
from
the
trial
server
architecture,
we
will
rely
only
on
this
repository.
A
A
B
A
Cuz
there's
been,
customers
have
been
requesting
a
lot
of
different
flavors
of
like
I'm
set
up
this
way
and
I'm
set
up
that
way.
So
unless
everyone
tells
me
because
right
now,
I
think
we
support
like
a
certain
set
of
languages
and
it
looks
like
there's
a
lot
of
different
ways
to
enable
those
languages.
Unless
someone
tells
me
like
this
is
silly
anything
for
those
already
supported
languages.
It's
an
additional
setting,
I'm,
probably
gonna,
try
and
get
one
in
for
release
just
so
that
we
have
a
breadth
of
customer
setting
options
to
support.
A
B
B
We
had
less
knowledge
than
expected
on
license
management
and
I
had
to
dig
through
the
code
of
this,
and
the
outcome
is
that
we
could
figure
out
on
the
front-end
side,
but
now
that
we
are
refactoring,
I
mean
this
issue
is
a
bit
whole
now,
but
now
that
we
are
refactoring
the
logic
into
the
backend,
this
issue
is
probably
not
accurate
anymore
need
to
reevaluate.
This
I
mean
the
internet
itself
is
still
meaningful.
B
A
A
So,
like
it's
a
side,
I,
don't
know
if
you'd
call
it
a
popover
or
a
slide-out
or
a
drawer,
but
tada
information
shows
up
right
there,
instead
of
in
a
popover
that
hides
things
it's
just
kind
of
pushes
over
from
the
right.
So
the
main
idea
is.
We
would
like
to
introduce
that
drawer,
which
I
think
is
going
to
be
a
majority
front-end
work,
but
I
think
that
someone
will
have
to
double
check
and
see
if
there
is
any
work
needed
on
the
back
end.
B
Okay,
it's
double
check
with
Lukas
on
this
one,
because
there
are
a
lot
of
ongoing
refactor
again
moving
the
logic
from
the
front
end
to
the
back
end
involve
a
lot
of
changes
in
all
the
components
in
the
front.
End
code
and
I
know
that
yeah
a
lot
of
work
there
and-
and
this
is
a
transversal
change-
I
mean
it's
impacting
the
merge
request,
widgets
the
pipeline
view
with
the
dashboards.
So
they
definitely
prefer
to
do
that
after
the
refactor
is
done
and
they
have
kind
of
one
unique
component
to
display
yeah.
That's.
A
Gonna,
if
that's
gonna
roll
past
2.2
will
push
this
two
to
four.
So
you
definitely
need
to
check
on
this,
but
there
are
some
really
neat
UX
improvements
that
have
been
done
by
Kyle
and
Andy.
So
when
the
prerequisites
for
those
are
done,
I
would
like
to
jump
on
them
to
make
our
stuff
a
little
more
friendly.
B
A
This
one
seems
like
it's
a
a
bit
of
a
hack
as
best
I
can
tell,
but
it's
better
than
what
we
have
so
I
am
embracing
of
that.
So,
if
you
want
to
check
and
see
if
this
one
is
still
blocked
because
I
know,
the
thing
we
discussed
is
that
we
don't
really
have
a
great
way
to
check
all
states
of
all
pipelines
like
there's
not
a
great
way
to
do
that
right
now.
A
B
B
So,
as
you
might
see
in
the
merge
request
you
are,
you
can
see,
your
branch
is
bi
and
master
for
100
commits
and
we
don't
have
anything
like
women
to
say,
okay,
but
the
differential
is
you're
saying
there
is
not
matching
what
you
have
in
master
and
the
exact
same
issue
for
all
the
security
vulnerabilities.
So
here,
yes,
it.
A
A
A
B
C
A
B
A
A
Drop-Down,
so
I
will
get
that
finalized.
But
essentially
we
need
to
use
the
correct
words
instead
of
little
iconographies,
so
I'll
Boop
Kyle,
and
then,
when
you
guys
get
a
chance
to
look
at
this,
then
we
can
continue
to
Boop
him
more
to
get
this
cleaned
up,
but
it
should
just
be
changing
out
icons
for
words.
So
my
question
is:
do
we
right
now
have
in
the
backend
information
whether
the
license
is
approved
or
unknown
in
the
backend
being
passed
already?
A
C
B
A
A
A
B
B
We
currently
have
shipped
in
12.1
the
depends
list,
API
public
endpoint
API,
and
we
have
now.
We
are
now
interrupted
to
adding
dependency
scanning
information
so
venerable.
It
is
in
that
list
to
improve
it,
but
in
the
view
calling
so
we
have
to
do
that
in
the
API
also.
So
this
is
just
improving.
The
output
of
the
existing
is
the
endpoint.
A
Is
12.3
likely
or
yeah
okay,
not
there,
and
then
we
have
three
nope.
Two
engineering
discoveries
that
are
currently
in
here
one
is
the
client-server
architecture
which
I
think
work
has
already
sort
of
started
on
this,
but
it
wasn't
assigned
to
12.1
or
12.2,
so
I
just
assigned
it
to
12.3,
because
I'm
guessing
that
it
might
take
a
little
while
to
do
all
of
the
research
and
have
meetings
and
discuss
with
everyone.
B
Mm5
man
would
be
in
the
kitchen
next
weekend,
yeah
a
lot
of
to
do
with
this
one.
You
already
do
a
one
iteration
of
answer
out.
There
I
mean
I,
don't
think
it
was
that
interrupted,
but
obviously
unique
I
mean
we
should
have
decision
taken
in
to
have
those
three.
So
you
can
either
put
it
in
twelve.
The
and
have
people
keep
discussing
that
because
it
had
a
huge
impact,
but
I
think
that
from
engineering
perspective
there
won't
be
a
lot
of
work
done
in
20.
B
A
B
Okay,
I
think
mainly
the
issue
is
about
the
size
of
how
the
docker
images
that
we
have
to
tunnel,
for
example,
for
lysis
management,
the
other
more
than
one
gigabyte.
He
made
docker
image
to
download
at
each
frame.
So
this
is
a
really
obviously
where
we
can
improve
performance,
but
the
goal
was
to
at
least
define
one
I
think
at
start
tracking
and
ensure
that
we
are
not
getting
worse
all
the
time
so
that
we
integrate
those
metrics
check
within
our
QA
process.
A
I'm
going
to
temporarily
assign
this
to
me
to
start
but,
like
like
I,
said
I'm,
not
sure
what
items
we
have
in
the
underlying
structure,
so
I
might
just
start
with,
like
I'd
like
to
know
how
long
something
takes
you
know
and
I'd
like
to
know
so,
for
example,
what's
the
wait
time
and
what's
the
amount
of
resources
used
by
the
customer
might
be
like
my
first
vague
thing
that
I
want
to
know,
and
so
I
need
someone
to
help
me
figure
out.
What
does
that
look
like
for
each
item
like
how
do
I
know?
A
C
A
Right
and
then
I'll
just
reiterate
the
reason
why
I
only
put
20
and
we're
down
to
19,
though,
is
because
we
have
been
not
nailing
a
hundred
percent
and
I
have
a
feeling
that
twelve
two
items
are
going
to
roll
into
here
and
I
feel
if
I
put
any
more
than
20,
and
that
would
be
overly
ambitious
and
not
reasonable.
Does
anyone
feel
that
20
was
overly
ambitious
and
unreasonable
and
I
should
knock
any
of
these
down.
D
A
B
B
So
yeah
things
to
consider
displayed
the
fact
that
the
team
has
doubled
in
size
within
the
next
month
for
the
previous
month
story
and
keep
growing.
So
it's
it's
not
variable
talking
just
about
the
issues
and
obviously
there
is
no
way
there.
So
another
thing
to
consider
is
the
fact
that
nobody
in
not
everybody
in
the
team
is
able
to
tackle
all
the
issues.
B
We
are
issues
split
amongst
two
different
main
skills
go
along
and
we'll
be
on
race,
so
some
of
the
issues
are
definitely
not
able
to
be
taken
by
some
of
the
people
in
the
team.
We
are
aiming
at
at
putting
everybody
at
the
same
level
and
be
able
to
tackle
everything,
but
it's
not
the
case
right
now.
So
it's
hard
to
tell
you
right
now:
I
need
to
go
through
all
of
these
issues,
consider
assignments
and
make
sure
that
we
have
enough
capacity
as
a
team,
but
also
as
each
individual,
for
example.
B
A
A
So
this
way
I've
got
one
two
three
weeks
to
get
answers,
and
then
we
can
decide
that.
Oh
no,
this
needs
to
go
because
we
didn't
get
the
answers.
We
need
instead
of
scrambling
at
the
last
minute.
So
that's
why
I'm
attempting
to
get
ahead
of
the
curve?
Hopefully
we
will
be
having
these
meetings.
You
know
mid
month
going
forward
and
then
more
frequently
as
I
can
get
ahead
of
myself,
so
that
we're
asking
questions
earlier
in
earlier,
so
UX
research,
anything
else
we
need
we
have
before
we
start.