-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Security Solution] Move calculation of rule source outside of applyRuleUpdate #199720
Changes from 3 commits
5b67f44
da7f9c8
2966af2
9e52e57
e760dd4
dc3e349
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -19,6 +19,7 @@ import { validateMlAuth, toggleRuleEnabledOnUpdate } from '../utils'; | |
import { createRule } from './create_rule'; | ||
import { getRuleByRuleId } from './get_rule_by_rule_id'; | ||
import { createRuleImportErrorObject } from '../../import/errors'; | ||
import { calculateRuleSource } from '../mergers/rule_source/calculate_rule_source'; | ||
|
||
interface ImportRuleOptions { | ||
actionsClient: ActionsClient; | ||
|
@@ -57,12 +58,19 @@ export const importRule = async ({ | |
|
||
if (existingRule && overwriteRules) { | ||
let ruleWithUpdates = await applyRuleUpdate({ | ||
prebuiltRuleAssetClient, | ||
existingRule, | ||
ruleUpdate: rule, | ||
}); | ||
// applyRuleUpdate prefers the existing rule's values for `rule_source` and `immutable`, but we want to use the importing rule's calculated values | ||
ruleWithUpdates = { ...ruleWithUpdates, ...overrideFields }; | ||
|
||
// If no override fields are provided, we calculate the rule source | ||
if (overrideFields == null) { | ||
ruleWithUpdates.rule_source = await calculateRuleSource({ | ||
rule: ruleWithUpdates, | ||
prebuiltRuleAssetClient, | ||
}); | ||
} else { | ||
ruleWithUpdates = { ...ruleWithUpdates, ...overrideFields }; | ||
} | ||
Comment on lines
+65
to
+73
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This change raises some concerns about safety that I think we should discuss.
This change seems to trade off implementation correctness for performance improvements, which could introduce potential issues. The root cause appears to be the splitting of the rule import logic between two clients: While performance improvements are important, it might be worth waiting until the rule customization feature flag is enabled by default before considering optimizations. This would also allow us to remove the legacy import method support and combine the @banderror, would love to hear your thoughts on this. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
This is only true because we happen to call
I see this as an optimization rather than an inconsistency: in the special case of importing rules, If the general argument is that these extraneous calculations are acceptable/negligible: this code path is only hit when you're overwriting existing rules, which was about 45% slower than creating new rules in my recent testing. So: an edge case, but it's slower, but not to the point where it's timing out (even at 4000 rules). 🤷 |
||
|
||
const updatedRule = await rulesClient.update({ | ||
id: existingRule.id, | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that this call is removed,
applyRuleUpdate
doesn't have to beasync
anymore.