Documentation
¶
Overview ¶
Package cel wires the user-supplied CEL rules loader/evaluator (in internal/rules/cel) into the analyzer engine's module set. It implements the Module interface (Name + Analyze) so the engine can fan it out alongside the built-in analyzers.
The module's Name is "custom-rules" (operator-facing, used by --only-modules / --skip-modules); the package name is "cel" (developer-facing, reflects the underlying expression language).
When the operator does not pass --custom-rules, the module is registered with an empty rules directory and Analyze returns (nil, nil), keeping the scan output byte-identical to a build without the module.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Analyzer ¶
type Analyzer struct {
// contains filtered or unexported fields
}
Analyzer is the engine-facing wrapper around the CEL custom-rules pipeline. It loads rules once at construction and replays them against every snapshot the engine hands to Analyze, so a long-running scan loop (which is not yet a shipping feature but is on the roadmap, per STRATEGY.md §9) avoids re-reading and re-compiling the rules file on every iteration.
func New ¶
New constructs an Analyzer pointed at rulesDir. If rulesDir == "" the analyzer becomes a no-op: Analyze returns (nil, nil) and the engine treats it like any other module that found nothing.
A load error is recorded on the Analyzer rather than returned so the engine can construct the module without context. Analyze surfaces the error on the first invocation; the engine's runModulesInParallel reports the first error without dropping other modules' findings, so a broken rules pack does not hide an otherwise clean scan.
Source Files