Closed winzj closed 3 months ago
We could start with a reduced and slightly updated version, that might be sufficient:
{
"apiVersion" : "1.0",
"type" : "falsePositiveDataList",
"projectData" : [ { /* use the rest service that is already available for jobData. */
"webScan" : {
"cweId" : 323, /* mandatory - can be omitted when the corresponding finding ahs no cwe id */
"ports" : [ "8443", "8441", "*" ], /* optional - defaults: 80, 443 */
"protocols" : [ "ws", "wss" ], /* optional - defaults https, http */
"urlPathPatterns" : [ "/api/projects/*", "/api/users/*", "/api/admin/profiles/*" ], /* mandatory - at least one, wildcards allowed!*/
"hostPatterns" : [ "dev.myapp.com", "prod.myapp.com" ], /* mandatory - at least one, wildcards allowed!**/
"methods" : [ "GET", "POST" ] /* optional - does a default make sense? */
},
"comment" : "This is a false positive because ... ", /* optional */
"id" : "unique-identifier" /* mandatory */
} ]
}
Situation
The current approach to mark false positives for web scans is not sufficient because a lot of the web scan findings contain dynamic parts e.g. random inputs inside URL query parameters. If these inputs differ on the next web scan, the previously marked false-positive could show up as finding again, because the URL containing these inputs is used to mark false positives.
Wanted
We want a generic approach to mark false positives. We want to introduce
projectData
, where a project can define the false positive information for their project. As discussed, the generic approach to mark false positives for web scans, could look like this:Solution