-
Notifications
You must be signed in to change notification settings - Fork 91
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
Provide an API to apply policy to a results list #2094
Comments
Hi @lgolding and @michaelcfanning , I have some questions:
Some information:
With that in mind, I though in something like this: public bool ApplyPolicies()
{
// TODO: add logic to apply all policies modifying the current `Results` list
return true;
} |
My opinions: We have various options:
My 2 cents. |
Based on your comments:
Since we don't have an output saying which policy ran. I would expect that when that happens, it ran all policies that you have in place. |
The SARIF standard does not say "if there is a policy present, you must apply it". It's more like "here are some policies you might find useful, depending on your situation". For instance: "here's the government policy. If we are selling to the government, this policy is applicable. Otherwise it is not applicable." But at this point I defer to @michaelcfanning. Those are my opinions. |
Hello! I think the cleanest thing to do here is to create a computed policy cache. This cache would be initialized by an order-sensitive list of policy objects. We may need an optional behavioral flag that specifies things like 'only tighten, never loosen failure levels' (meaning that the maximal severity associated with each rule id would be honored) or 'last policy wins' in which every policy, when processed, actively updates any already computed policy for a rule id. To build the computed policy cache, you will need to cycle through the policies in order. Compute a key for each tool + unique rule by its id (the only required rule property). Use this key to persist an object that contains relevant policy information. In our first utilization, it will simply be a potentially overridden failure level (after we do this first work, we can discuss adding the rule enabled vs, disabled designation). The cache object can provide a simple helper that accepts a rule id and returns the overridden level. Please do not use an interface to make this testable, declare the policy cache in such a way that it can be overridden/mocked without taking on the costs of defining new interface types. This is the core code that I suggest you write and test. Perhaps you can also write a simple visitor that overwrites every result failure level (if necessary) based on the policy cache. Remember: there's some complexity to retrieving a result rule id, since that can be expressed on the result directly, indirectly via the I hope this is enough for you to get started. Contact me and @cfaucon with any questions. I'll send you an invite to a teleconference where we can discuss this work, if you have time to drop in (entirely optional). |
The helper is in the |
The API would both filter the list for rules that are disabled, and adjust level.
@michaelcfanning FYI
The text was updated successfully, but these errors were encountered: