This article will help you to:

In general, submissions can be marked as duplicates if they have the same underlying root cause in the code. When in doubt, ask yourself whether the fix for the first report would have fixed the other report as well.

If two fixes have to be applied, for example on two different endpoints, then the submission would not be consider a duplicate as one fix would not prevent the second vulnerability from being found.

When a researcher submits an issue which you are already aware of, it is possible to mark it as a duplicate. As a best practice, we suggest to provide the Intigriti triage team with a list of known vulnerabilities, so that we can already mark those as duplicates in the triage step. Contact your success manager on how to do this.

In case there is an issue which you are aware of internally, you can still mark the submission as a duplicate. In this case, we ask you to be fair towards the researchers and provide context around this decision.

If an issue appears to be structural (present on many endpoints), it is possible to temporarily put the vulnerability class in the out of scope section to give your teams the time to fix the structural issue and take it back into the scope when the issue seems resolved.

In the meantime, the issues reported before the issue was taken out of scope, should be considered valid and unique as per the guidelines above.

The best resource on your program is to have a good set of loyal researchers, who come back time and time again and discover new, more complex issues.

Marking submissions as duplicate without the proper explanation or reasoning behind it, may cause researchers to move on to another program.

Being fair and communicating openly with the researchers will have a positive impact on your program in the long run.

When in doubt, contact your customer success manager!