feat(SLA config): allow to use it on all levels

[kiblik]

Finish of #11300

[dryrunsecurity]

This pull request reveals multiple security concerns including potential race conditions during SLA configuration updates, information disclosure risks through verbose error messages, configuration-based security vulnerabilities that could bypass access controls, and a potential authentication weakness involving hardcoded admin tokens in test environments.

💭 Unconfirmed Findings (4)

Vulnerability	Potential Race Conditions
Description	Multiple files show synchronization risks during SLA configuration updates, with async updating mechanisms that could potentially be exploited or cause service disruption. Specific risks are present in models.py, engagement/views.py, and unittests/test_finding_model.py.

Vulnerability	Information Disclosure Risks
Description	Detailed messages and popovers expose internal system processes and configuration details. Verbose error handling and configuration change messages could leak system internals, identified in files like engagement/views.py, forms.py, templates/dojo/view_eng.html, and test/views.py.

Vulnerability	Configuration-based Security Risks
Description	New setting SLA_CONFIG_ON_NON_PRODUCT_LEVELS could bypass existing access controls. Dynamic configuration loading without strict validation presents potential for unintended configuration behaviors, found in settings/settings.dist.py and models.py.

Vulnerability	Potential Authentication Weakness
Description	Hardcoded admin token used in test environment, which could indicate risky authentication practices if similar patterns exist in production. This was discovered in unittests/test_finding_model.py.

---

All finding details can be found in the DryRun Security Dashboard.

[Maffooch]

Hi @kiblik I think the line of thinking from the previous comment is still valid here

[kiblik]

Hi @kiblik I think the line of thinking from the previous comment is still valid here

Hi @Maffooch,

• regarding documentation/explanation (how does it work), the fields have a description which is accessible as a hint:

• If it is necessary to add a couple of words to the documentation, I can write them down. Do you have a recommendation for which documentation page? Or should I create a new one?
• Regarding performance, I changed the implementation to opt-in mode, so users can decide to enable it. Or can I which it to opt-out?

Are there any other doubts that I should fix or explain?

[kiblik]

@Maffooch / @mtesauro, can I know your opinion, please?

[Maffooch]

The fear here is that we complicate the model, API, documentation, etc. Even if this feature were to be opt in thing from the UI, the code base cannot opt out

[kiblik]

The fear here is that we complicate the model, API, documentation, etc. Even if this feature were to be opt in thing from the UI, the code base cannot opt out

I suppose the adjustment of the model was expected from the beginning (assignment of specific SLA Config needs to be stored somewhere), but this kind of concern has not been raised at the beginning when we were talking about implementation: #10025

I'm willing to scale it down only to Engagement if it would help (even though I still believe there is reason to have it on Test level as well).

Complexity of API? I'm not sure, as there are only two more fields (sla_configuration for Eng and Test) that users can assign. I see that there are new fields (e.g. pro in CommonImportScanSerializer for import and reimport - #12525) that are not usable by non-opensource-users, and they have been added without any complaints.

Documentation? Well, a good product should have good documentation. I'm willing to add it. I just asked where to place it - to keep it as clean as possible - I'm happy to keep it polished and organised.

I agree that adding more and more code to a project makes it harder to maintain. It is the reason regular cleanup of not well-written or not used parts (like Google Sheets or async-eval) should be performed. But I suppose it should not be the reason to stop the development of features that people are happy to use and willing to maintain.