►
From YouTube: Secure/Create Sync on VS Code Extension
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
D
C
C
A
Yeah
that
makes
a
lot
of
sense.
Okay.
Well,
we
have
one
engineer:
Fernando
who's,
a
front-end
engineer
and
it's
looking
probable
that
we'll
have
a
number
of
Milestones
available
here
soon
and
we
would
love
to
contribute
to
that
extension
to
start
to
build
in
some
secure
features,
because
right
now
there's
pretty
much
nothing
at
all
as
far
as
secure,
and
you
can't
see
any
of
your
vulnerabilities,
you
can't
you
know,
there's
just
nothing
right
like
the
most
you
can
do.
A
Is
you
can
see
the
status
of
your
pipeline
jobs
and
whether
or
not
they've
finished?
But
even
you
know,
monitoring
to
see
like,
oh,
you
know,
has
my
SAS
scan
completed.
It
doesn't
give
you
any
of
the
results
from
those
scans.
So
our
timeline
here
is
a
little
bit
short.
We
are
hoping
to
have
him
start,
probably
in
15
8..
We
don't
necessarily
have
to
have
100
of
all
of
the
mocks
and
everything
fully
done
and
designed
by
then
as
long
as
I
think
you
know.
A
A
C
Yeah,
well,
no,
it's
exciting
and
I
appreciate
any
contribution
to
it
from
from
other
groups.
I
hope
that
this
is
the
beginning
of
many
other
groups
trying
to
integrate
with
the
with
the
extension,
because
our
general
strategy
right
now
is
to
replace
the
web
ID
with
vs
code
and
that's
in
progress
and
then
once
we
do
that,
and
we
enable
extensions
we're
going
to
adapt
the
gitlab
workflow
extension
to
work
on
the
web.
C
We
hope
that
folks,
like
the
like
I've
talked
about
it
with
the
just
with
other
groups.
Pipeline
editor,
for
example,
could
make
a
an
extent,
an
extension
and
an
alternate
editing
experience
within
the
extension
make
that
available
on
the
desktop
and
web
just
an
example,
but
I'm
still
in
the
early
stages
of
ramping
up
so
I,
maybe
not
I,
don't
have
as
many
strongly
held
opinions
on
how
this
should
work
and
what
the
roadmap
looks
like
I.
A
Okay
yeah:
that's
super
helpful,
okay,
yeah
that
that
all
sounds
great
and
and
I
definitely
agree
with
that.
You
know
overall
vision
of
providing
a
consistent
experience
between
web
and
desktop
I.
Think
that's
a
really!
You
know
good
direction
to
head
with
everything
and
I
would
say
that
that's
generally,
in
line
and
consistent
with
what
my
vision
would
be
for
secure
features
in
in
the
vs
code
extension
as
well.
A
There
are
a
couple
of
challenges
that
we
deal
with.
You
know
and
I
apologize
I
didn't
put
all
of
this
in
the
notes
ahead
of
time.
This
sort
of
falls
under
my
second
Point
here
of
like
allowing
developers
to
see
vulnerabilities
from
all
the
different
types
of
scanners,
but
I
just
thought
I
might
take
a
minute
and
talk
through
some
of
the
challenges
that
we
face
with
the
secure
scanner,
specifically
just
to
give
you
and
really
everyone
in
the
call
a
little
bit
of
context.
So
we
have
a
lot
of
different
kinds
of
scanners.
A
That's
not
correct,
but
you
know:
linting
type
rules
are
only
one
piece
of
all
of
the
security
scanning.
That's
out
there
and
not
everything
can
be
done
as
simply
as
that
you
know,
otherwise
it
would
just
be
one
really
big
winter
and-
and
it
certainly
you
know,
security
scanning
is
actually
quite
a
lot
more
involved
and
so
some
of
our
on
the
other
end
of
the
spectrum.
A
A
Throwing
in
randomly
generated
content,
you
know,
they're,
you
know
actually
using
the
application
itself
in
order
to
discover
if
there's
a
vulnerability
there,
and
so
obviously
those
are
going
to
be
really
hard
to
run
locally,
if
not
impossible,
because
you
know
again
like
you
would
not
only
only
have
to
do
a
build,
but
you
also
have
to
deploy
it
somewhere.
So
you
know
we
run
our
cic
Pipeline
and
we
stand
up
a
review
app
typically
and
then
we
go
scan.
A
The
review
app
is
normally
the
way
that
works,
and
then
we
have
some
scans
that
are
in
between
between,
like
our
dependency
scanning,
which
performs
a
build
for
some
of
the
languages,
it
doesn't
have
to
be
deployed,
but
it
does
need
to
build
or
contain
your
scanning.
You
have
to
actually
build
the
container
image
in
order
to
scan
it.
A
We
may
not
be
able
to
get
the
full
scope
of
dependencies
that
are
introduced
without
doing
a
full
build,
so
what
we
end
up
having
is
this
trade-off
between
having
complete
results
and
having
fast
results,
and
you
know
that
solving
that
is
is
really
not
an
easy
problem
in
particular,
because
there
are
other
things
to
consider
too,
like
we
may
have
custom
rule
sets
first
fast
and
secret
detection.
You
know
so
it's
not
just
one
rule
set.
A
You
would
have
to
query
out
to
gitlab
to
get
the
latest
rule
set
and
bring
that
in
and
scan
it,
and
then
you
also
have
the
issue
of
limiting
eliminating
false
positives
or
vulnerabilities
that
have
already
been
dismissed,
because
some
of
the
scanners
can
generate
some
noise
and
if
you've
already
reviewed,
you
know
95
out
of
100
findings
and
found
those
to
not
be
applicable.
You
wouldn't
want
those
to
continue
to
show
up
in
the
IDE.
A
So,
there's
a
lot
of
complexity.
There
is
really
what
I'm
getting
at
when
it
comes
to
actually
running
the
scanners,
and
so
all
this
to
say
that
my
proposal
is
to
defer
our
attempt
to
address
that
complexity
and
actually
do
the
scanning
locally
and
instead
just
fetch
the
results
of
the
vulnerabilities
from
the
pipeline
up
in
gitlab,
and
that
way
we
can
show
everything
we
can
show
dasc
we
can
show
all
of
it.
It
just
is
going
to
take
some
time
to
fetch
those
results.
A
So
you
know
the
the
trade-off
is
the
time
to
get
a
response
and
I
think
we'll
have
to
be
careful
on
our
ux
design
to
communicate
that
you
know
this
really.
Is
you
know
whatever
vulnerability
view
we
create,
is
really
only
going
to
be
accurate
as
of
the
last
completed
pipeline,
not
as
you're
typing
live,
and
so
you
know
that
would
be
that
one
trade-off
with
with
that
approach.
But
on
the
other
hand,
you
know
we
won't
have
to
worry
about
communicating
hey.
A
This
is
only
results
for
your
secret
detection
and
everything
else
is
up
in
gitlab
right
anyway.
So
they're
really
pros
and
cons.
Both
ways-
but
that
was
my
initial
proposal
at
least
we
can
adjust
it
if
we
need
to
but
I,
don't
know
what
are
your
thoughts
on
starting
with
just
showing
the
results
from
the
scans
up
in
gitlab.
C
Fully
understand
the
challenges
here
and
I
I
made
some
notes
along
the
way
and
and
mentioned
that
down
the
road.
Our
remote
development
workspaces
may
help
in
this
regard,
with
making
the
Avail
I
know
you're
using
review
apps
now,
but
making
these
ephemeral
workspaces
that
can
actually
compile
code
on
the
web
or
remotely
you
know
via
SSH.
We
could
spin
up
one
of
those
for
a
scan
and
be
running
them.
B
C
Real
time
that
means
well,
that's
a
that's
a
much
longer
road
map,
though
we're
not
going
to
have
that
in
the
next
two
Milestones.
So
this
sounds
like
a
great
iteration
to
at
least
make
them
available
in
in
the
output,
with
the
trade-off
of.
Obviously,
that
you
mentioned
is
they're
only
accurate
up
to
the
last
time
the
pipelines
run,
and
if
you
make
any
changes
locally,
what
do
we
do?
How
do
we
show
that
there's
stale
things
like
that,
the
ux
around
there
could
be
a
challenge.
C
I
guess
I
would
turn
around
and
ask
like,
as
far
as
defining
the
MVC
is,
that
is
that
value
your
customers
want,
even
if
they're
stale
is
it
still
providing
the
value
or
that
are
they
going
to
be
happy
with
that
happy
enough
happier
than
today
with
that
iteration
or
are
they
gonna?
Just
only
need
it
if
it's
live.
A
No,
it
absolutely
will
be
an
improvement
on
a
number
of
fronts.
I
mean
just
for
one
thing:
they
don't
have
to
go
out
to
get
lab
just
to
see
their
vulnerability
results
right.
So
anytime
you
minimize
their
need
to
contact,
switch
or
go
back
and
forth.
They
were
going
to
have
to
wait
for
those
results
either
way,
and
so
they
may
as
well
continue
to
code
in
their
IDE
while
they
wait
for
those
to
show
up
rather
than
having
to
go
out
and
continually
check
the
web.
A
So
from
a
pure
user
perspective,
it's
valuable
and
then
you
know
from
like
a
sales
Market.
You
know
land
scape
perspective
having
anything
at
all
in
there
is
going
to
help
our
positioning
because,
right
now
we
don't
have
any
security.
Ide
story
to
speak
of
well,
almost
I
mean
like
the
most
we
can
do
is
say:
oh
look,
you
can
see
if
your
SAS
job
is
completed
yet
or
not
right.
A
C
But
also
to
Fernando's
first
question
in
here
about
the
availability
of
the
web
versus
desktop,
limiting
feature.
Parity
I
think
this
iteration
wouldn't
limit
that,
because
you
know
we're
reading
pipeline
jobs
and
if,
if
we
can
do
that
on
the
web,
we
can
do
that.
We
can
do
that
in
both
places,
but
we're
good
where
it
comes
down
to
being
a
bigger
challenge
with
feature
parity
is
when
we
start
running,
requiring,
builds
and.
D
C
B
C
Just
there's
nothing
to
connect
to
I
think
it
makes
sense
as
a
as
a
as
a
first
iteration
and
I
I.
Think
that,
given
there
already
is
insight
into
pipeline
jobs,
running
and
being
completed,
there's
some
areas
that
we
can
tap
into
to
to
kick
start
that
process
from
the
ux
standpoint
and
then
yeah
I
believe.
There's
there's
plenty
of
fairly
well
documented
apis
for
how
to
like
integrate
with
the
editing
environment
and
vs
code
and
show
you
know,
line
numbers
and-
and
things
like
that
that
relate
to
the
report.
A
Yeah,
absolutely
so,
that's
the
other.
That's
the
other
thing
to
consider
and
I'll
spare
you
reading
like
the
massive
thread
that
is
now
there
on
that
linked
epic.
But
you
know
one
of
the
big
design
decisions
and
Engineering
decisions
that
we
need
to
make
is
where
and
how
to
display
these
results.
So
not
all
vulnerability
results
will
have
an
Associated
file
and
line
number.
You
know,
for
example,
those
desk
scans
they're,
going
out
and
they're
scanning
and
a
URL
endpoint
right.
A
And
so
you
know
do
we
you
know:
do
we
rely
on
that
problem,
tab
in
in
the
visual
studio
code
IDE
to
show
everything,
but
that's
going
to
exclude.
You
know
dast
and
fuzzing
and
some
others,
or
do
we
create
our
own?
You
know
dashboard
of
sorts
that
can
list
listed
out.
You
know
there
are
a
few
different
different
security.
C
Okay,
let
me
share
my
screen:
real
quick,
I'm
I'm,
jumping
right
to
Solutions,
it's
terrible,
but
first
of
all,
I
want
to
highlight
Julia's
awesome
new
theme
that
I've
been
using
she's
working
on
a
new
dark
theme
for
our
web
IDE
and
I'm
using
it
locally.
But
so
in
the
you
know,
like
a
gitlab,
workflow
extension
right,
we
have
some,
maybe
the
most
obvious
if,
if
not
easiest
to
implement
would
be
to
have
another.
You
know
panel.
D
C
Section,
that's
just
like
scan
results,
I
see
what
you
mean
about
the
like
the
problems
panel
there
might,
it
might
be
that
certain
scans
show
up
in
both
or
either
or
depending
on
the
relevance,
but
it
does
seem
like
there's
space
for
it
right
like
it
makes
sense.
We
have
a
mental
model
right
now
for
like
essentially
playing
features
and
merge
requests,
and
that's
another
panel
I
think
is
the
adding
a
view
in
there
is
not
going
to
be
terribly
difficult.
A
D
I
have
very
similar
thoughts.
I
think
that
real
estate
that
you
talked
about
makes
a
lot
of
sense.
It
could
even
go
as
far
as,
like,
obviously,
vulnerabilities
relate
to
specific
branches,
so
it
could
be
a
sub
item
under
the
current
Branch
versus
having
a
separate
panel
for
it,
but
obviously
a
lot
to
talk
about
the
pros
and
cons
and
approach
there.
D
D
C
C
E
E
E
Do
some
development
work
right,
I'm
not
going
to
have
any
data
to
pull
from
until
pipeline
is
run,
so
it's
kind
of
like
as
I'm
developing
I'm
not
going
to
have
any
data
because
usually
putting
up
Mor
is
near
the
end
of
my
process,
or
at
least
when
I'm
doing
my
first
iteration
of
you
know
putting
something
up
so
like
that's
something
to
think
about
too.
So,
if
I'm
working
on
something,
then
I
I
think
I'm
ready
to
put
up
a
merge
request,
put
up
a
merge
request.
A
A
I
mean
I
suppose.
Maybe
there
is
some
way
to
kind
of
hack
it
on
the
back
end,
and
and
actually
do
that
you
know-
maybe
there
would
be
some
way
to
like
not
formally
open
a
merge
request,
but
still
push
the
code
up
to
gitlab
and
run
a
security
scan
only
pipeline
I
guess
you
still
would
have
to
do
all
the
build
and
deploy
steps.
A
C
Also
in
that,
in
that
workflow
that
you
were
mentioned
for
Fernandez,
like
you're
you're,
starting
on
your
main
branch
right-
and
maybe
you
you
create
a
branch
to
start
your
work,
you're,
not
necessarily
committing
yeah
at
all,
and
you
don't
necessarily
want
to
commit.
You
might
be
just
trying
something
out
you
don't
necessarily.
We
can't
presume
that
you
intend
this
to
be
a
merge
request
in
its
current
form,
until
you're
ready
to
actually
take
that
action.
Maybe
that's
that's
outside
of
my
realm
of
expertise,
I'm
just
spitballing
yeah.
A
Anyway,
so
that'll
be
something
to
think
about
too,
with
the
designs.
I
think
is
just
making
sure
that,
even
though
we're
not
developing
all
of
that
in
this
iteration
that
we
have
a
path
forward
and
we're
not
designing
ourselves
into
a
corner
so
that
we
can
have
that
more
immediate
feedback
in
the
future
for
a
subset
of
the
scans.
A
All
right:
well,
that's
all
I
have
thanks
for
syncing
out
Michael.
You
have
time
to
work
on
this.
I
think
right
from
a
ux
perspective,
so
I
went
ahead
and
created
that
design
issue
and
assigned
it
to
you,
yep,
absolutely,
okay,
but
yeah
we'll
definitely
keep
you
in
the
way
of
Eric
you're
the
dri
now
for
this
feature,
so.