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, but not all instances or 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, as long as they would not be identified as part of the initial fix. If the same issue affects all endpoints or instances, it can be considered as a single issue.

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!

Most of the time companies include vulnerabilities as 'Known Issues' in the program details when the vulnerability is internally known (e.g. after completing a penetration test and the issue is not yet fixed), or when they receive multiple reports about the same vulnerability type, and no longer wish to receive reports of this or a similar nature. In these cases, it is useful to mention the known issues in the program details so that researchers are informed that the program no longer wishes to receive new reports because your security team is already looking into the problem.

Once the issue is fixed to your best knowledge, you should remove it from the out of scope section. If the researcher reports one or multiple structural issue(s) (an asset-wide vulnerability that impact most endpoints / functionalities of a site, but caused by a single point of failure within the source code), we recommend accepting the first submission with 100% bonus (so twice the value of the bounty) to reward the researcher for discovering a widespread issue. The other submissions can be rejected as duplicate. You can discuss this with the Triage team via internal messaging if you are unsure.

You can also ask the researcher to validate the fix once it is rolled out, and we highly recommend that you reward a small bonus for doing so. Retesting the submission is done entirely at the researcher's discretion. Intigriti Triage does not verify fixes on your or the researcher's behalf.