Skip to content
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

Merged
merged 7 commits into from
May 14, 2024

Conversation

blakeaowens
Copy link
Contributor

@blakeaowens blakeaowens commented May 10, 2024

This PR adds functionality to optionally enforce SLA remediation days for all severities.

  • Add BooleanFields to the SLA_Configuration model that specify if a given severity will enforce the specified SLA days (default=True, to match existing SLA Configuration functionality)
  • Add logic to the finding model's set_sla_expiration_date to set the finding sla_expiration_date to None if its severity is not enforce on the SLA_Configuration
  • Update templates displaying SLA configuration information to display Not Enforced for any non-enforced SLA days fields

Addition of new "Enforce (Severity) Finding SLA Days" fields:
Screenshot 2024-05-10 at 5 04 52 AM

Viewing all SLAs with Critical Finding SLA Days not enforced:
Screenshot 2024-05-10 at 5 05 41 AM

After disabling Critical Finding SLA Days enforcement, critical findings no longer have an SLA expiration date or SLA days remaining:
Screenshot 2024-05-10 at 5 06 31 AM

When viewing a Product, severities that do not enforce a given SLA remediation period will show Not Enforced:
Screenshot 2024-05-10 at 5 07 20 AM

[sc-3361]

@github-actions github-actions bot added New Migration Adding a new migration file. Take care when merging. apiv2 ui labels May 10, 2024
@blakeaowens blakeaowens changed the title Enforce sla days Optionally Enforce SLA Remediation Days May 10, 2024
Copy link

dryrunsecurity bot commented May 10, 2024

Hi there 👋, @DryRunSecurity here, below is a summary of our analysis and findings.

DryRun Security Status Findings
Configured Codepaths Analyzer 0 findings
Sensitive Files Analyzer 0 findings
AppSec Analyzer 0 findings
Authn/Authz Analyzer 0 findings
Secrets Analyzer 0 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 🤖.
Note that this summary is auto-generated and not meant to be a definitive list of security issues
but rather a helpful summary from a security perspective.

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:

  1. dojo/api_v2/serializers.py: The changes in this file ensure that the SLA configuration cannot be modified while the system is in the process of recalculating the finding SLA expiration dates. This is an important security consideration to maintain the integrity of the SLA data.

  2. dojo/models.py: The updates to the SLA_Configuration model introduce new fields to control the enforcement of SLA expiration dates for different severity levels. The changes also handle the process of updating the SLA expiration dates when the configuration is modified, while avoiding blocking the user interface during the update.

  3. dojo/db_migrations/0212_sla_configuration_enforce_critical_and_more.py: This database migration introduces the new fields to the SLA_Configuration model, allowing for more granular control over SLA enforcement.

  4. dojo/forms.py: The changes to the SLA_Configuration form disable certain fields when the SLA expiration dates are being recalculated, preventing users from modifying the configuration during this process.

  5. dojo/templates/dojo/view_product_details.html and dojo/templates/dojo/sla_config.html: These template changes improve the display of SLA information, providing more transparency to the user about which SLA rules are being enforced.

  6. unittests/test_finding_model.py: The new test cases verify the correct behavior of the Finding model's SLA-related functionality, including the calculation of SLA expiration dates and the handling of cases where SLA enforcement is disabled.

  7. dojo/templatetags/display_tags.py: The changes to the finding_sla function implement the display of SLA status for findings, including whether the remediation was completed within the SLA period.

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

Copy link
Contributor

@mtesauro mtesauro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved

dojo/api_v2/serializers.py Outdated Show resolved Hide resolved
@Maffooch Maffooch merged commit 1b86b66 into DefectDojo:dev May 14, 2024
123 checks passed
@kiblik kiblik mentioned this pull request May 14, 2024
3 tasks
@coheigea
Copy link
Contributor

coheigea commented Jul 19, 2024

@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:

[19/Jul/2024 12:44:25] ERROR [django.request:241] Internal Server Error: /product/4278
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/django/db/backends/utils.py", line 89, in _execute
    return self.cursor.execute(sql, params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.UndefinedColumn: column dojo_sla_configuration.enforce_critical does not exist

Nevermind, I manually did the migration in the uwsgi container and it works fine now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
apiv2 New Migration Adding a new migration file. Take care when merging. ui unittests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants