All Collections
Submission management
Duplicate, related or known vulnerability reports
Duplicate, related or known vulnerability reports
This article provides best practices around (seemingly) duplicate submissions or known issues
Travis Anderson avatar
Written by Travis Anderson
Updated over a week ago

This article will help you to:

  • Understand when submissions are considered duplicates and when they are not

  • Provide insight into how to deal with structural issues

  • Provide context around communicating with the researchers around duplicate submissions

Duplicate or not?

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.

What about previously known issues?

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.

Related issues

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.

Why should we be careful in handling seemingly duplicate issues?

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!

Did this answer your question?