Prevent project-level SAST/SD/IaC config files from interfering with policy-driven scans
Background
In #393452 (comment 1364762017) we discussed how to handle conflicts between shared configurations (which are referenced by using an environment variable) and project-level configurations (which are committed into the specific project.
We decided to be permissive at first because of the variety of places one can specify a shared config (not just Scan Execution Policies). For example, you can set it as a group-level CI/CD variable too, which is less obviously a policy-related goal. But, if you're writing a Scan Execution Policy, it's likely you'd want to have some control over at least the minimum amount of coverage you want to see, and you're less likely to want individual project developers to be able to change which rules are disabled.
Goal
Allow SEP- or compliance-pipeline-based SAST, Secret Detection, and IaC Scanning jobs to disallow project-level overrides. That is, those jobs would be able to enforce that the job uses either the default configuration or a configuration provided by the SAST_RULESET_GIT_REFERENCE
or equivalent SD options.
Proposal
- Add a variable:
- Add a single new variable that causes SAST, IaC Scanning, or Secret Detection to not read any project-local configuration.
- This should disable project-local configuration whether or not a shared ruleset is used. Customers may wish to enforce that the default settings are used (to ensure, for example, that no default rules are disabled) even without building their own config and setting that via SAST_RULESET_GIT_REFERENCE or similar. See #414732 (comment 1746308390).
- Why a single variable? Primarily this is a judgment call that it is more convenient for customers to say "don't look at customizations" only once; note that even with a single variable the variable could be applied in scoped ways to affect only one scan type or another. See #414732 (comment 1927989193).
- Name:
SECURE_ENABLE_LOCAL_CONFIGURATION
- This would have the value
true
orfalse
. Use the same comparison semantics asSAST_DISABLED
and similar variables. - The default value, if the variable is not provided, is
true
. - This single variable will control both SAST and Secret Detection. (IaC Scanning is implemented as part of SAST.)
- This variable only needs to control whether the local file is used or not.
- This would have the value
- Naming considerations:
- In docs, we call this a "configuration file" for SAST and SD. For IaC docs call it a custom ruleset file.
- Configuration seems more discoverable/obvious than "LOCAL_RULESET" or "LOCAL_CUSTOMIZATION".
- Opinions welcome; see thread below.
-
Update from initial proposal: We changed from
DISABLE
toENABLE
for clarity, with the default value flipped fromdisable: false
toenable: true
. See thread.
- Add a single new variable that causes SAST, IaC Scanning, or Secret Detection to not read any project-local configuration.
- Release the change:
- Update all relevant analyzers to respect the new variable.
- Update documentation for relevant feature categories to note the new variable, likely in the sections describing how customizations and shared GIT_REFERENCE configs are used.
- In %18.0 or the next available chance, change Scan Execution Policies to set this variable by default.
Alternatives
- Disable project-level configuration when specifically running via a Scan Execution Policy. (#393452 (comment 1386009482))
- There’s a common module that all SAST analyzers use; it knows how to fetch a remote ruleset if one is provided. I believe this package is where the precedence logic is defined.
- When the SEP creates the job, we could inject another CI/CD variable into the job, or otherwise use job context to know that we’re in an SEP-based job. With that signal, we could tell the analyzer that it should not consult any project-based config file.
- We should document that this is the behavior, and should log when it occurs, to reduce confusion.
- Downside: this does not apply to compliance pipelines (though something analogous could be done there, presumably). And, it would potentially be a breaking change.
- Use other features to disable this editing.
-
@theoretick: "I would imagine there are more native control mechanisms we could leverage too like pre-empting a
CODEOWNERS
config to prevent the addition of asast-ruleset.toml
file or something." (#393452 (comment 1387289371))
-
@theoretick: "I would imagine there are more native control mechanisms we could leverage too like pre-empting a