►
Description
Staff Engineer Lucas Charles does a quick demo of the new GitLab 16.1 feature to specify a shared SAST custom ruleset configuration
- Documentation https://docs.gitlab.com/ee/user/application_security/sast/customize_rulesets.html#specify-a-remote-configuration-file
- Feature Issue https://gitlab.com/gitlab-org/gitlab/-/issues/393452/
A
A
So,
with
gitlab
16.1
we'll
be
introducing
a
new
capability
for
specifying
a
remote
custom
rules
set
configuration
for
those
unfamiliar
custom
rule
sets
is
a
capability
within
the
static
analysis
and
secret
detection
categories
to
provide
a
override
to
the
default
rule.
Sets
that
our
analyzers
use
now
this
can
be
very
powerful
for
doing
things
like
disabling
predefined
rules
or
overriding
specific
rules
say
increase
in
the
severity
of
SQL
injections
or
something
of
that
nature.
A
Now
this
new
capability
that
we're
added
adding
is
called
a
specifying
a
remote
configuration
file.
Now,
once
a
file
is
specified,
as
described
in
the
docs
here
under
the
gitlab
directory
with
the
corresponding
file
name
generally,
this
must
be
on
inside
the
project
that
is
being
scanned
with
this
new
capability.
Here,
the
file
can
actually
live
in
a
separate
project
and
be
shared
across
a
number
of
projects
or
groups.
A
Now
the
basic
format
for
this
feature
is
to
specify
a
cicd
variable,
called
SAS
rule
set
git
reference
or
in
the
case
of
secret
detection.
It
would
be
secret
detection.
We
will
set
get
reference
also
described
in
the
docs
here,
and
it
would
match
this
precise
format
now.
The
basic
format
here
is
a
optional
Authentication
project
path
and
then
an
optional
git
shop.
Now
this
project
path,
it
will
be
expecting
a
file
matching
the
default
path
as
described
above,
and
then
that
file
will
be
loaded
remotely
from
whatever
project
it's
specified
in
the
project.
A
A
A
We
have
a
fairly
simple
configuration
which
just
loads
the
SAS
job.
We
have
a
readme
and
here
is
our
main
go
file
which
includes
this
dangerous
eval
function.
Now
this
dangerous
eval
function
is
a
custom
function,
so
it
will
not
be
detected
by
default
by
our
stack
analysis
scanner,
but
our
organization
particularly
is
concerned
about
this,
and
so
we
want
to
write
a
customer
rule
set
that
detects
this.
A
So
we
have
a
separate
project
here:
called
security
policies,
demo
private,
as
indicated
by
the
lock.
This
is
a
private
project
and
it
includes
a
readme,
a
custom
rule
set
configuration
here
and
a
security
policy
configuration
which
is
optional.
Just
an
example
of
how
you
could
include
both
your
policies
and
your
customer
rule
sets
in
one
project.
A
Now
this
configuration
is
pretty
simple
for
semrep
scanner.
It
includes
a
override,
so
it
overrides
the
existing
configuration
with
a
file
and
specifies
the
file
here.
This
file
is
in
our
root
here,
and
the
file
contains
a
single
rule
called
in
your
C
Val,
and
the
pattern
detects
a
function
called
Dangerous
eval
returning
the
message
function,
dangerous
default
detected
and
a
error
level
severity.
A
A
Okay,
now
this
time
we
are
expecting
our
pipeline
to
run
our
pipeline
will
fail
and
it
will
return
a
validation
error
as
expected,
and
then
we
will
follow
us
up
with
Addie
and
the
appropriate
Authentication.
Thank
you.
While
that's
running
I'm,
going
to
just
go
ahead
and
hop
over
here
to
our
private
project.
The
way
that
we're
going
to
specify
this
here
is
by
creating
a
project
access
token,
we'll
call
it
custom
rule
set
demo.
A
Now
for
the
authentication
description
here
we
need
a
user
and
a
password
so
when
generating
a
project
access
token,
a
bot
user
is
generated
as
well,
so
we'll
go
ahead
and
go
over
to
the
members,
and
you
can
see
the
spot
user
right
here
so
we'll
first
paste
in
this
will
be
our
user
and
then
we're
going
to
use
the
policies
access.
Token
variable.