Skip to main content

Engagement

In DefectDojo, an "engagement" refers to a specific project or activity that involves the identification and mitigation of vulnerabilities in an application or system. Engagements are a fundamental part of security management in DefectDojo, as they allow you to keep track of security tests, audits and evaluations performed on your products or applications.

Each engagement can represent a variety of activities, such as:

  1. Penetration Testing: When a security team or an external auditor attempts to identify vulnerabilities in an application through controlled attacks.
  2. Application Assessments: Systematic evaluations of an application to identify potential security risks.
  3. Code Audits: Source code reviews for vulnerabilities and security issues.
  4. Vulnerability Scanning Analysis: Automatic vulnerability scans that identify risks in an application or system.
  5. Continuous Security Testing: Regular and automated tests that run throughout the development life cycle.
  6. Compliance Testing: Evaluations that ensure that an application complies with specific security standards and regulations.
  7. Third Party Assessments: Audits performed by external parties, such as independent security companies.

Types of Engagement

At DefectDojo, we have two types of engagement: "Interactive Engagements" and "CI/CD Engagements" are specific types of engagements used to organize and manage security-related activities in an application or project. However, they have key differences in nature and purpose:

Interactive Engagement:

  • Interactive nature: These engagements involve active interaction of a security team, auditor or security professional with the application or system. In other words, these are security tests that require manual intervention and decision making by security experts.
  • Penetration Testing: Interactive Engagements are often related to penetration testing or manual security assessments. They involve the active search for vulnerabilities, exploitation of possible weaknesses and an in-depth analysis of the application's security.
  • Realistic Scenario: These engagements typically replicate realistic attack scenarios to assess the application's ability to resist exploitation attempts and to identify potential security risks.

CI/CD Engagement:

  • Automation and Continuity: CI/CD Engagements are more related to automated and continuous security testing that is integrated into the development workflow (CI/CD). They are part of an agile development process and are executed on a regular basis, even after changes have been implemented.
  • Focus on Continuous Integration and Delivery (CI/CD): These engagements focus on assessing security throughout the development lifecycle, especially in CI/CD environments. They are used to ensure that new updates and features do not introduce vulnerabilities into the application.
  • Security Test Automation: CI/CD Engagements typically include automated security scans, static and dynamic code analysis, container vulnerability scans and other automated tests.

In summary, the main difference lies in the nature of the security activities they address. Interactive Engagements focus on manual testing and penetration activities that require active human interaction, while CI/CD Engagements focus on automated, continuous testing that is integrated into the development process to ensure security at all times. Both types of commitments are essential to a comprehensive security strategy in an organization.

Creation

For those of us who integrate it with GitLab's CI, we will create an engagement of type CI/CD each time our pipeline is executed. This will allow us to separate commit tests into their own test group. If the development team is large and many pipelines are generated, this could mean more work for SecDevOps teams. However, it will provide us with greater clarity on which commit and which user has committed poor practices, allowing us to address and avoid them more effectively in the future. To do this we will create a previous stage in the IC that we can see in the Monitoring Integrations section