Retrieve DefectDojo finding ID from SecureCodeBox finding ID

➹ New Feature implementation request

Is your feature request related to a problem?

As a secureCodeBox user with DefectDojo integration I would like to know what DefectDojo finding was created for each secureCodeBox finding (and vice-versa).

This would be useful in a case where you create a custom hook which sends notifications for very specific finding cases with a link to the DefectDojo finding. DefectDojo's notification support is very limited.

Possible solutions

These are some possible solutions that I came up with. I'm very happy to hear any other solutions!

It would make sense if the unique_id_from_tool field in the Finding model refers to SecureCodeBox's finding ID. Currently, however, the finding filters don't include this field yet (i.e. no way to get finding from the unique_id_from_tool field). This field is already updated with DefectDojo's generic importer, but some other existing importers write their own unique id into it. We would need to patch the created findings after creation.
The DefectDojo persistence provider updates the Minio finding so that it includes the DefectDojo finding ID.
The DefectDojo persistence provider is a ReadAndWriteHook which writes a map of SecureCodeBox ID -> DefectDojo ID back to the scan spec.

@EndPositive

Hi @EndPositive,

thx for your proposal :)

If I'm not getting it wrong - the defectdojo hook is already implemented as ReadWriteHook and comes with the "two way sync" feature:

defectdojo:
  # -- Syncs back (two way sync) all imported findings from DefectDojo to SCB Findings Store, set to false to only import the findings to DefectDojo (one way sync).
  syncFindingsBack: true

Have you tried this already?

Was implemented here #330

Ah very cool. Just checked the source code and it seems like this is exactly the information that I requested! Maybe it's a good idea to add an example of the synced findings into the documentation.

I has turned this off by default because it was conflicting with the Cascading Hook. Does that sound familiar? I'll test some more on Monday and post logs if I can't get it to work!

Hi Robert, sorry for the delay. I've tested a bit and found the issue. Below you can find the findings for an nmap scan, one with syncFindingsBack and enabled and one with it disabled. The reason why syncFindingsBack is conflicting with Cascading Scans is because the DefectDojo persistence provider is overwriting fields that are being matched in the Cascading Rules.

This behavior results in no Cascading Rules being matched and thus no new scans starting. Would it be possible to update syncFindingsBack in such a way that it does not affect original finding fields (i.e. only add fields/attributes)?

Furthermore, you might notice that the nmap host finding disappears. I assume this is because DefectDojo only imports it as an endpoint. However, I might still like to match cascading rules to that host finding (i.e. syncFindingsBack should not discard findings).

With syncFindingsBack enabled:

{
    id: '183f7ed4-3e66-4020-8c89-836bbfe86213',
    name: 'Open Port: 443/TCP',
    location: 'tcp://------------:443',
    description: '### Host\n' +
      '\n' +
      '**IP Address:** ------------\n' +
      '**FQDN:** ------------\n' +
      '\n' +
      '\n' +
      '**Port/Protocol:** 443/tcp\n' +
      '\n' +
      '\n' +
      '**Product:** nginx\n' +
      '**Version:** 1.18.0\n' +
      '\n' +
      '\n',
    category: 'DefectDojo Imported Finding',
    severity: 'INFORMATIONAL',
    timestamp: null,
    attributes: {
      'defectdojo.org/finding-id': 2,
      'defectdojo.org/finding-url': 'http://defectdojo-django/finding/2',
      'defectdojo.org/test-id': 1,
      falsePositive: false,
      'defectdojo.org/test-url': 'http://defectdojo-django/test/1',
      duplicate: false
    },
    osi_layer: null
  },
  {
    id: '8aebd3e5-2003-41a0-a0e6-eb3178cd2cbf',
    name: 'Open Port: 80/TCP',
    location: 'tcp://------------:80',
    description: '### Host\n' +
      '\n' +
      '**IP Address:** ------------\n' +
      '**FQDN:** ------------\n' +
      '\n' +
      '\n' +
      '**Port/Protocol:** 80/tcp\n' +
      '\n' +
      '\n' +
      '**Product:** Apache httpd\n' +
      '\n' +
      '\n',
    category: 'DefectDojo Imported Finding',
    severity: 'INFORMATIONAL',
    timestamp: null,
    attributes: {
      'defectdojo.org/finding-id': 1,
      'defectdojo.org/finding-url': 'http://defectdojo-django/finding/1',
      'defectdojo.org/test-id': 1,
      falsePositive: false,
      'defectdojo.org/test-url': 'http://defectdojo-django/test/1',
      duplicate: false
    },
    osi_layer: null
  }

With syncFindinsBack disabled:

{
    name: 'http',
    description: 'Port 80 is open using tcp protocol.',
    category: 'Open Port',
    location: 'tcp://------------:80',
    osi_layer: 'NETWORK',
    severity: 'INFORMATIONAL',
    attributes: {
      port: 80,
      state: 'open',
      ip_address: '------------',
      mac_address: null,
      protocol: 'tcp',
      hostname: '------------.nl',
      method: 'probed',
      operating_system: null,
      service: 'http',
      serviceProduct: 'Apache httpd',
      serviceVersion: null,
      scripts: [Object],
      tunnel: null
    },
    id: 'fa8d2dde-3145-4b27-84b4-97a81599b954',
    parsed_at: '2021-07-07T09:14:43.198Z'
  },
  {
    name: 'http',
    description: 'Port 443 is open using tcp protocol.',
    category: 'Open Port',
    location: 'tcp://------------:443',
    osi_layer: 'NETWORK',
    severity: 'INFORMATIONAL',
    attributes: {
      port: 443,
      state: 'open',
      ip_address: '------------',
      mac_address: null,
      protocol: 'tcp',
      hostname: '------------.nl',
      method: 'probed',
      operating_system: null,
      service: 'http',
      serviceProduct: 'nginx',
      serviceVersion: '1.18.0',
      scripts: [Object],
      tunnel: 'ssl'
    },
    id: '18890888-3014-41c4-85a6-8d47c251c2b3',
    parsed_at: '2021-07-07T09:14:43.198Z'
  },
  {
    name: 'Host: ------------.nl',
    category: 'Host',
    description: 'Found a host',
    location: '------------.nl',
    severity: 'INFORMATIONAL',
    osi_layer: 'NETWORK',
    attributes: {
      ip_address: '------------',
      hostname: '------------.nl',
      operating_system: null
    },
    id: 'f352d223-8c48-4cbf-ab52-5e21f3cecbe2',
    parsed_at: '2021-07-07T09:14:43.198Z'
  }

Hi again 👋

Thanks for the detailed report and examples, much appreciated 🙏

Really merging the secureCodeBox findings and DefectDojo findings is unfortunately so hard that its as good as impossible. At least I haven't come up with a good way to do it. The parsers are just (or can be depending on the scanner) to different to reliably correlate between the two. This is especially hard when the secureCodeBox and DefectDojo will even produce a different number of findings per report, like for the host findings in DefectDojo.

One thing which might be possible to do is to configure the DefectDojo exporter to always use the Generic Finding upload (added with #487) for all findings. Then we could easily map between DefectDojo and secureCodeBox findings as they are guaranteed to be "mappable".

This might impact DefectDojo ability to properly detect duplicates & false positives thought, as DefectDojo would not know anymore which scanner specific fields are best to use to detect duplicate findings

I understand. Using the generic parser would really be less than ideal since DefectDojo's built-in parsers make a huge difference for their user-experience.

What about importing secureCodeBox findings one-by-one into DefectDojo? This way you are guaranteed a mapping (unless DefectDojo does not create a finding). I'm curious how much, if any, influence this method would have on the import duration.

I don't think that will be possible, as this would require that our DefectDojo exporter code would have to split up the raw results (e.g. the XML Output from nmap) into multiple raw results which all only contain one finding. This would be extremely complicated and would have to be tied to every scanner.

Closing this as I don't see how we can do this without a huge amount of effort on our side for each scanner, or severly decreasing the quality of findings in DefectDojo.

Navigation Menu

Repository navigation

Retrieve DefectDojo finding ID from SecureCodeBox finding ID #536

➹ New Feature implementation request

Is your feature request related to a problem?

Possible solutions

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Retrieve DefectDojo finding ID from SecureCodeBox finding ID #536

Description

➹ New Feature implementation request

Is your feature request related to a problem?

Possible solutions

Activity

rfelber commented on Jul 2, 2021

EndPositive commented on Jul 3, 2021

EndPositive commented on Jul 7, 2021

J12934 commented on Jul 9, 2021

EndPositive commented on Jul 12, 2021

J12934 commented on Jul 13, 2021

J12934 commented on Jul 20, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions