-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Optionally Enforce SLA Remediation Days #10179
Conversation
Hi there 👋, @DryRunSecurity here, below is a summary of our analysis and findings.
Note 🟢 Risk threshold not exceeded. Change Summary (click to expand)The following is a summary of changes in this pull request made by me, your security buddy 🤖. Summary: The code changes in this pull request are primarily focused on improving the management and enforcement of Service Level Agreements (SLAs) for security findings in the Defect Dojo application. The changes introduce new fields and functionality to provide more granular control over which severity levels have their SLA days enforced, as well as handling the process of recalculating SLA expiration dates when the SLA configuration is updated. From an application security perspective, these changes are generally positive, as they help ensure that critical and high-severity findings are addressed in a timely manner, while still providing flexibility for lower-severity issues. The changes also include robust handling of the SLA recalculation process to prevent users from modifying the configuration during an ongoing update, which helps maintain the integrity of the SLA data. The code changes also include updates to the SLA configuration display, as well as new unit tests to verify the correct behavior of the SLA-related functionality. These improvements contribute to the overall security and reliability of the application. Files Changed:
Overall, the code changes in this pull request demonstrate a focus on improving the security management capabilities of the Defect Dojo application, with a specific emphasis on the handling and enforcement of SLAs for security findings. Powered by DryRun Security |
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.
Approved
@blakeaowens After updating from 2.34.5 to 2.35.4, I'm seeing this error...it looks like the migration never ran? Do you know how I can handle this error:
Nevermind, I manually did the migration in the uwsgi container and it works fine now. |
This PR adds functionality to optionally enforce SLA remediation days for all severities.
BooleanField
s to theSLA_Configuration
model that specify if a given severity will enforce the specified SLA days (default=True
, to match existing SLA Configuration functionality)set_sla_expiration_date
to set the findingsla_expiration_date
toNone
if its severity is not enforce on theSLA_Configuration
Not Enforced
for any non-enforced SLA days fieldsAddition of new "Enforce (Severity) Finding SLA Days" fields:
Viewing all SLAs with Critical Finding SLA Days not enforced:
After disabling Critical Finding SLA Days enforcement, critical findings no longer have an SLA expiration date or SLA days remaining:
When viewing a Product, severities that do not enforce a given SLA remediation period will show Not Enforced:
[sc-3361]