10 Things to Consider while Operationalizing OWASP DefectDojo

OWASP DefectDojo (DefectDojo | CI/CD and DevSecOps Automation ) is a security program and product/application security vulnerability management open source product. DefectDojo can be the source of truth for the AppSec/ProductSec program wherein it can be the registry for maintaining product development teams contact details, lifecycle details of vulnerability assessment findings and product libraries/SBOM details. DefectDojo official documentation has basic information to install and operate workflow. However, contextualizing the DefectDojo vulnerability management workflow in an enterprise context needs the following considerations. 

1. DefectDojo supports hierarchical data model i.e., products, engagements and test cycles that can be utilized both for managing security vulnerability assessment findings generated through security scan tools deployed during CI/CD pipeline or during interactive manual security reviews. This DefectDojo (DD) hierarchy needs to be mapped to organization structure and security program structure.  

• DD products can be mapped to digital products that have a dedicated product owner/manager. DD engagements can be mapped to different security testing i.e., source/secret code scan (including management of vulnerable dependencies),  mobile application scan,  API scan and DAST
• Since DD supports configuring Jira project keys at engagement level, this kind of mapping helps in having right mapping to product development team's Jira boards and also handling duplicate findings within engagements
• Maintain mapping of products & engagements; same can be achieved by using an Excel spreadsheet (sample given below) that can hold this information and can act as application registry maintained in a git repository. This spreadsheet should be consumed during the automated finding ingestion pipeline highlighted in #2

• DefectDojo hierarchical data model can be useful to track security posture of a multi-AWS account environment

2. Understand the asset configuration data model and API contracts of the existing SAST/DAST/SCA security tools. Most of the scan tool’s API output is mapped to vulnerability assessment findings data model in DefectDojo and is available in the DefectDojo github repository. However, following needs to be considered:

• Develop automated pipeline to ingest vulnerability assessment finding data from scanning tools to DefectDojo e.g., GitHub Action. GitHub Actions providing cron/schedule type of running the jobs and secure way to manage  storage of scanning tools API tokens/secrets. Daily GitHub Action run output should be reviewed to make sure asset/product configuration between scanning tools and DefectDojo is synchronized and there are no issues in gathering vulnerability assessment findings from scanning & uploading to DefectDojo
• Mapping asset configuration data in scan tools to DefectDojo product & engagement; logic should be built in the finding ingestion pipeline to make sure asset configuration data in scanning tools is in sync with DefectDojo products and engagement configuration
• Reopening of the findings in scanning tools should update corresponding status in DefectDojo; appropriate API should be used to update finding details in DefectDojo. Note: take care of updating corresponding Jira issue as well. Using DefectDojo API to get finding id to Jira issue mapping and use Jira SDK to update Jira issue status
• API supported by scanning tools could either be REST or GraphQL e.g., WhiteHat Sentinel provides REST APIs to get findings & details and GitHub Advance Security (GHAS) provides GraphQL

3. Ingestion of the vulnerability assessment findings from the scan tools into DefectDojo would require to use both DefectDojo REST APIs and the DefectDojo Python library (https://github.com/DefectDojo/defectdojo_api). Mostly the DefectDojo API Swagger documentation is up to date and provides capability to execute API through Swagger interface. But Python API implementation is evolving; so use REST API as needed e.g., to modify findings data in DefectDojo or reopening the finding, use HTTP PATCH method. Logs generated by DefectDojo can be really useful while developing this ingestion pipeline

4. DefectDojo can be deployed in AWS ECS and use AWS RDS for database. Even though there are some reference IaC templates available for this deployment, additional effort needs to be planned to customize the IaC template for an organization’s environment. Monthly charge for the AWS resources deployed would be around $120. Note: don’t forget to utilize DefectDojo logs available as AWS CloudWatch log groups for debugging issues. To enable SSO based access to DefectDojo, appropriate modifications in Iac code should be considered along with configuration updates in the organization’s SSO product

5. If Jira is used for issue tracking, then DefectDojo provides seamless bi-directional integration with Jira. Note: Jira next gen uses parent issue as Epic and hence it requires additional customization in DefectDojo code. PR has been submitted to DefectDojo public repository to enable this capability

• Follow steps in DefectDojo official documentation to configure Jira instance. Note: If the Jira project boards corresponding to the products are configured with issue workflow without uniform issues status and mandatory resolution, then different Jira instances have to be created per product; however if resolution is not mandatory to set an issue status to 'Done', then Jira status can't be properly updated in DefectDojo vulnerability assessment finding status
• Consider configuring Jira project key at engagement level and webhook (with secret) at the system level; 
• Update DD_SITE_URL env variable in DefectDojo configuration to make sure DefectDojo URL is included in Jira issue description
• Grouping findings in DefectDojo can be used in 3 ways

1. Group findings into a single Jira issue so that custom remediation date can be set (instead of SLA based remediation date) and also can be assigned to a single user. This is similar to 'remediation project' that some of the commercial vulnerability management platform vendors support. For using this capability, engagement to Epic mapping should be disabled in DefectDojo
2. Creating a separate AppSec Epic in each Jira project would help group findings. In order to send findings from DefectDojo as Jira issue under these Epics, Epic issue/parent issue  should be configured in each DefectDojo Engagement (Note: this is achieved via a PR submitted to DefectDojo github repo)
3. Use Jira Component. Components are subsections of a project; they are used to group issues within a project into smaller parts. So create a component for application security and configure the same in DefectDojo

6. Decide how the DefectDojo vulnerability assessment finding status move through different states i.e., from Active (verified) to Inactive, mitigated state and whether Jira status update can update DefectDojo finding status to mitigated or whether 'mitigated' state can only be set when a finding is closed in the scanning tool. Note: unless required, disable GitHub integration in DefectDojo system setting as it prevents closing a finding by an analyst

7. Vulnerability assessment findings management workflow in DefectDojo could take a few iterations before it is operationalized. Consider soft launching the finding management workflow to iron out issues in workflow and scanning tool integration.  Few considerations:

• Use Finding tab in DefectDojo to filter findings based on different criteria (e.g., severity) and generate reports in CSV/Excel format. One of the columns in this report is 'Age' and conformance with SLA configured. This helps in collaborating with product development teams to address the finding
• Make sure there is a Jira issue associated with finding in DefectDojo. Jira issue can either be automatically created at the time of ingesting vulnerability assessment finding from scanning tools or an already created Jira issue can be associated with a finding
• SLA configuration common for all products in DefectDojo. SLA configuration for critical/high severity finding helps track elapsed time for finding from the discovery to closure and is typically a key metric that most of the AppSec programs track

8. Training should be planned for the security analysts using the DefectDojo. Training should introduce typical configurations in DefectDojo that are relevant to a security analyst e.g., SLA configuration, product contact details, Jira parent issue configuration etc. 

9. Interactive, internal manual security reviews or external pen tests for various products & application components can be mapped to interactive engagements in DefectDojo and the vulnerability assessment findings can be tracked to closure. Information gathered as part of the security review can be used by the security team for fine-tuning security review benchmark and the threat model.

Following workflow could be used for interactive security reviews:

• Create a master list of review questions using Questionnaires capability in DefectDojo. These questions can be based on OWASP ASVS and also based on the security considerations depending on the organization environment. This master list can be created with different categories loosely mapping to the trust boundaries. Use 80:20 rule while creating questions either with multiple choice or with free flow text
• Using the master security review benchmark items list, create a questionnaire for an engagement. Naming convention for this questionnaire may need to be standardized for easy identification.
• Using the 'General Engagement Questionnaires' option in DefectDojo, create an instance of the questionnaire with an expiration date for the review. DefectDojo creates a link for this questionnaire link and the same can be shared with reviewers/developers for them to review/respond to the questionnaire. 
• On the Engagement tab in DefectDojo, use 'Additional Features' section to associate questionnaire to an Engagement
• Reviewer responds to the questionnaire and the responses are stored in DefectDojo. Response to question could result in a finding and a corresponding Jira ticket
• For each test cycle in engagement - different questionnaires can be used with different questions associated.
• Survey/questions (choice/text) can be deleted only from DefectDojo django admin panel

10. Keep stakeholders informed of the DefectDojo implementation progress and plan for regular demonstration of the vulnerability assessment findings management workflow. 3~4 person month effort needs to be planned to setup DefectDojo infrastructure, findings ingestion automated workflow setup, training security analyst and a soft launch to verify vulnerability assessment findings management workflow.