SAST Custom Rules - Passthrough Scanner Configuration
Problem to solve
To complete Custom Rulesets for SAST Analyzers we should provide the ability to passthrough a configuration block to the underlying scanners.
Intended users
User experience goal
Proposal
- Update
analyzers/common
to detect and parse.gitlab/sast-rules.toml
- If configuration file is present, analyzer provides a compatible customization hook (similar to our
plugin.go
architecture), and[[ANALYZER.passthrough]]
is present, provide analyzer-specific configurationfile
to underlying tool (gosec-only initially) - Check for
GITLAB_PLAN
as defined in licensing issue usingos.GetEnv
[gosec]
description = 'gosec custom rules configuration'
[[passthrough]]
type = file
source/target/destination = gosec-config.json
value = gosec-config.json
Further details
The initial usecase is to reach feature parity with the previously introduced SAST_GOSEC_CONFIG
functionality of the gosec
analyzer. By instead providing a method of supplying the configuration through our SAST rules configuration file instead of directly via an ENV.
This reframes our customization functionality around a single customization entrypoint and provides the basic framework within common
and our analyzers to build on top of.
Permissions and Security
No change to permissions
Documentation
- Update Static Application Security Testing docs with new section on configuration file
- [optionally] Consider deprecating
SAST_GOSEC_CONFIG
Availability & Testing
- Add unit tests to
analyzers/common
covering new customization architecture - Add downstream test to
analyzers/gosec
where configuration file is specified to modify default behavior (similar togosec-config-FREEZE
branch)
What does success look like, and how can we measure that?
Customers have clear location for modifying analyzer behaviors
What is the type of buyer?
Is this a cross-stage feature?
No, only groupstatic analysis
Links / references
Edited by Lucas Charles