SRL Authoring and Performance
Patterns for accurate findings, scalable collection analysis, testing, and maintainable system rules.
Authoring workflow
- Choose the narrowest correct execution scope and configuration section.
- Confirm the normalized path and whether the rule runs once or per edit.
- Write the smallest condition that distinguishes pass, fail, info, and skip.
- Test missing fields, scalar/list variants, multiple VDOMs, and built-in objects.
- Compare raw finding counts and subjects, not only the final overall result.
- Run against a representative large configuration before publishing.
Avoid quadratic collection scans
A nested scan over the same large collection grows approximately with the square of the object count. Use array_group_by() when objects can be grouped by fields in one pass.
$fields = split("protocol,tcp-portrange,udp-portrange", ",");
$groups = array_group_by(config.firewall.service.custom, $fields);
foreach ($group in $groups) {
if ($group.count > 1) {
addInfoFinding(
"Equivalent services: " + join($group.names, ", "),
"Review and consolidate duplicates where safe."
);
}
}
| Pattern | Typical cost | Use |
|---|---|---|
One foreach | O(n) | Independent checks per object. |
array_group_by() then loop groups | O(n) | Duplicates, categories, and signatures. |
array_sort() | O(n log n) | Ordered display or adjacent comparisons. |
| Nested full collection loops | O(n²) | Avoid for large sections unless the outer set is tightly bounded. |
Choosing generic and firewall-aware functions
- Use generic collection functions when the rule can describe grouping, sorting, slicing, or aggregation through ordinary fields.
- Use firewall expansion helpers when groups and references must be recursively resolved into effective addresses or ports.
- Use specialized helpers where their documented semantics and measured performance fit the rule.
- Do not reimplement interface classification heuristics in SRL; use
appliance.interfaces.<name>.network_type. - Collection functions are immutable. Keep original annotated members when a finding must link back to a configuration object.
Finding-quality checklist
- Details state the object, observed value, and why it matters.
- Remediation is specific enough for an engineer to act on.
- The finding subject is the original object or an explicit source path.
- Passes represent checks actually performed; unsupported configuration returns without a finding.
- Duplicate/group findings use stable configuration order so repeated audits remain comparable.
- Case-insensitive SRL equality is intentional for the values being compared.
Pre-publication test cases
| Fixture | Expected assertion |
|---|---|
| Compliant object | Correct pass count and subject. |
| Non-compliant object | Correct fail severity, details, and remediation. |
| Missing optional field | No execution error or false positive. |
| Missing required section | Intentional skip behavior. |
| Multiple VDOMs | No cross-VDOM leakage; correct scope labels. |
| Large real configuration | Stable counts, acceptable runtime, and memory below the production limit. |
| Repeated execution | Input configuration remains unchanged. |