why is he chosen?
What is ASPM?
ASPM (Application security posture management, application security posture management) is a holistic approach to application security (AppSec) that provides a single source of truth to identify, correlate, and prioritize vulnerabilities throughout the software lifecycle, from development to deployment.
ASPM solutions collate and analyze data from multiple sources to make it easier to interpret, triage, and resolve problems. They also administer and coordinate information security tools to implement security policies. Using this approach, experts can centrally manage application scan results, obtaining information about the level of security and risks for the entire software development environment.
Distinctive features of the ASPM practice and the DefectDojo tool
DefectDojo is an Open Source solution of the ASPM class, written in the Django Python framework, which allows you to correlate scan results from different tools and aggregate them on one resource. This product is widely known among developers and AppSec engineers as it helps solve many problems related to vulnerability management.
DefectDojo uses the following entities:
Product – a software product that includes scans, reports, vulnerabilities;
Engagements – scans. They can be grouped by the instrument that carried out the analysis;
Test – report on a separate scan;
Finding – found vulnerability.
DefectDojo has all the hallmarks of ASPM: integration with third-party tools, provision of centralized policies, prioritization and sorting of vulnerabilities, risk management. Let's take a closer look at each component.
Integration with third party tools
The ASPM solution must be able to obtain data from a variety of sources, including software product development, deployment, and operations, software assets, security data, and ticketing.
DefectDojo is capable of processing scan results from more than 150 tools, including BurpSuite, OWASP Zap, gitleaks, nmap, OWASP Dependency-Track (it even has built-in integration with DefectDojo). The platform parses the results of scanning these sources thanks to built-in parsers that analyze reports provided in a given format (JSON, XML and others). If the tool you need is not in the list of available ones, you can write a parser for it yourself using documentation. DefectDojo itself is built into the DevOps pipeline so that reports are sent automatically immediately after scanning.
Thus, DefectDojo has the ability to integrate with both manual and automated AppSec testing tools.
Centralized policy
ASPM solutions are designed to standardize security practices across teams, projects, and tools. They centrally define, enforce, and monitor security policies for prioritization testing. This allows AppSec workflows to scale.
The information uploaded to DefectDojo contains a criticality rating for each vulnerability found by the scanning tool. This allows you to prioritize the most dangerous information security problems in order to fix them first.
Security policies can be defined through the SLA (Service Level Agreement) system. In DefectDojo, SLA allows you to set the number of days during which the developer is obliged to eliminate the vulnerability:
This helps security and development teams easily integrate issue assessments, controls, patches, and audits into pipelines and maintain ongoing security compliance.
Prioritization and sorting
Having the tools to consolidate relevant data points and standardize workflows is the first hurdle in AppSec management, but security teams must also have access to ASPM capabilities to maintain developer productivity.
The ASPM solution should eliminate duplication of redundant results between tools and help identify priority issues that teams need to address first, based on defined policies for risk criteria. These may include the severity of the problem, the criticality of the software, and specific service level agreements to address security deficiencies.
DefectDojo has the ability to filter vulnerabilities by their criticality, CWE, date of occurrence, status in the system (Open, Verified, False Positive, Risk Accepted, Closed…) and other filters. The tool assigns vulnerability statuses, changes their criticality and description and other aspects; the functionality is provided within DefectDojo itself through the UI. This allows you to flexibly configure the criticality of vulnerabilities for each specific software product, supplement their description, and prioritize their fixes for the development team.
The tool also has a tagging function for software, vulnerabilities and scans. Depending on the team's policies, it is used to make it easier to navigate vulnerabilities and speed up their closure. You can enable inheritance of tags from a product, then scans (Engagements), reports (Tests), vulnerabilities (Findings) associated with these products will be marked with similar tags.
One example of using tags is adding them to reports depending on the scanning tools used and setting up their inheritance in vulnerabilities. This allows the AppSec engineer to filter all security issues found by the scanner he is working with. Essentially, the tag makes it easier to filter out vulnerabilities.
The built-in DefectDojo mechanism for processing duplicate vulnerabilities helps in solving the deduplication problem. When triggered, the tool marks them as duplicates or deletes them (depending on the settings).
The settings of the deduplication algorithm themselves can be viewed in documentation, and change it in the source code. For the SAST tool, the fields 'title', 'cwe', 'line', 'file_path', 'description' are compared; for DAST – 'title', 'cwe', 'line', 'file_path', 'description', 'endpoints'. However, in the same documentation there is a warning that the results may be unexpected due to the subtleties of the settings, therefore, if problems arise, you need to switch to debug mode.
As one of the prioritization tools, you can consider the Request peer review function, which allows you to direct a vulnerability to a specific team member for study.
With these capabilities, developers can focus on the most critical security activities.
Management of risks
The ASPM solution should provide an overview of the risk status of all software developed by the company. This includes detailed information about the location of vulnerable software components and applications, the resolution status of the issue, and any policy and compliance violations. Essentially, security leaders should be able to use ASPM to audit their products, understand organizational risk from a software perspective, and generate AppSec KPIs.
In DefectDojo, there are metrics for this, thanks to which you can evaluate the “health” of the product, the number of vulnerabilities found and closed in it, as well as assess the effectiveness of the work of each engineer individually. It is worth considering that the most basic metrics are presented here; it will be difficult to use them to evaluate the effectiveness of the process by analogy with DORA for DevOps.
Advantages of DefectDojo
The main advantage of the DefectDojo tool is that it is an Open Source project published on Github source code written in Python. It is easy to install, you can modify it yourself, implement the necessary functions and metrics in the source code, or request additional functionality from developers and the community.
We listed some of the advantages above when we mentioned the features that make it an ASPM tool. The result is an extensive list of possibilities:
And that is not all. To the listed advantages you can add:
An API that allows you to flexibly manage the tool through the pipeline. To integrate DefectDojo into a DevOps pipeline, they often use an API to query and send scan results for a specific software product. Documentation the API is also clearly written, the tool itself has Swagger;
Swagger at DefectDojo
An alert system that can be configured for a specific event, for example, if an SLA is violated, send automatic notifications to developers with information about how critical the vulnerability is and how many days they have to fix it. Notifications can be received by email, instant messengers, etc. (customizable according to requirements). Slack and MicrosoftTeams are present out of the box, as well as native notifications inside DefectDojo. If you use instant messengers (Telegram, Mattermost, Yandex Messenger, VK-Teams or your own internal product), then you will need to improve the notification system for them;
Integration with Jira, which allows you to configure the uploading of vulnerabilities directly to the tracking system. The combination of Jira with DefectDojo is bidirectional and synchronizes these software products without reference to which one appeared first and how long the developers interacted with it;
Availability of Questionnaires and benchmarks. This allows you to evaluate the security of programs not only using application scanners, but also by updating information about the system and the required level of its security, depending on its purpose, location (inside the company or outside) and vulnerabilities relevant to it.
Disadvantages of DefectDojo
The following problems may occur when using this tool:
Inefficient operation under high load. This tool is not designed for working with large amounts of data. VK team (3:00) also points out that she had performance issues when trying to connect DefectDojo to multiple pipelines, causing crashes;
In some cases the documentation is explicit encourages solving problems and including additional features by editing the source code hands, for example, Here. This forces one or two developers to be dedicated to maintaining the product in working order;
Extremely inconvenient filter organization system. Yes, filters are great for searching by titles, tags, and other fields, but it can be easy to get lost in their settings. As an example, filters for Findings (vulnerabilities). In DefectDojo, they can be assigned several statuses at the same time, for example, “Active, Verified” or “Inactive, Out of Scope”. But through the Status filter you can select only one status, and not all possible ones are listed there. For more precise filtering of vulnerabilities, you need to look for additional fields that are located in places that are not too obvious to the user;
There are some peculiarities of working with Jira: vulnerabilities are synchronized only individually (you cannot associate a group with one ticket in Jira), and the synchronization area includes status, label and comments. So it will not be possible to indicate an engineer in the application or link the case to the practice through a component. In this case, the comment will be sent to Jira only if the risk is accepted or not accepted (Accept or Unaccept); in other situations, it will not be sent at all. DefectDojo about this know.
Metrics are for developers and team managers only. Basically, they allow you to find out the “health” status of the product and the speed at which it closes vulnerabilities, as well as evaluate the results of the team’s work over the course of a week or month. However, there are few metrics that track business processes, re-emergence of previously handled or closed security issues, and technical debt across practices.
conclusions
How to use DefectDojo and for what purposes to modify it is up to you to decide. Developers prefer it for the convenience of the API and the ability to automate their own processes, without taking into account the work of an AppSec engineer. Information security specialists choose this tool to collect all vulnerability reports in one place and, based on them, write a report on the bugs found.
This product is suitable for those organizations that need a simple and free solution with good and extensive functionality that allows them to be more attentive not only to real, but also to paper security, as it helps fill out questionnaires and monitor compliance with OWASP requirements.
It is worth remembering that the main advantage of Open Source can also be a disadvantage. When deploying OpenSource, you need to be prepared for the fact that you will have to edit some details of its implementation. And for this we need developers or AppSec engineers who can modify the DefectDojo code. In our experience, Open Source tools are more often used in the initial stages of DevSecOps development and implementation. Of course, there are known cases of large companies using DefectDojo, but more often large organizations choose something more predictable, since they cannot cope with the volume of code that needs to be edited for themselves.
Like any Open Source tool, DefectDojo can be subject to a Supply Chain Attack, as anyone can make malicious changes or protestware to the source code.
And one more subtle point associated with Open Source tools is a potential conflict of interest if a developer of your organization wants to participate in the development of DefectDojo – he can publish in a public repository the code written for your DefectDojo instance for the organization’s money. Even if you legally protect yourself from such an outcome, a situation may arise where the developer introducing new features into DefectDojo leaves the company along with the expertise of the code he wrote. Then it will be very difficult for a new specialist in his place to understand this code, and the previously developed functionality will become impossible to maintain and develop.
