Identifiers inclusion

[kingthorin]

Per https://mobile.twitter.com/kingthorin_rm/status/910134747455741957

You might also want an array element for arbitrary identifiers. WASC_ID, Testing Guide Refs, Top 10 IDs...etc

[mkonda]

What's the best way to do it such that they are open ended and support a bunch of identifiers but still meaningful and possible to interpret back out?

[kingthorin]

_{I'm throwing this response together before I've had coffee and I'm definitely not a JSON/JavaScript guru. So take this with an appropriately sized grain of salt.}

How about something like:

vuln = {
    "name":"Whatever Info Leak",
    "someotherattrib":30,
    "identifiers": [
        {"name": "WASC", "id": "13"},
        {"name": "CWE", "id": "200"},
        {"name": "OWASP-TestingGuideV4", "id": "OTG-ERR-001"}
    ]
}

Then accessed:

var x=""; 
for (i in vuln.identifiers) {
    x += "<h1>" + vuln.identifiers[i].name + " " + vuln.identifiers[i].id + "</h1>\n";
    // Could be a second loop here if there's a need for the "id" attribute     
    // to also be an array, like: {"name": "CWE", "ids": [ "200", "209" ] }
} 
console.log(x);

Producing:

<h1>WASC 13</h1>
<h1>CWE 200</h1>
<h1>OWASP-TestingGuideV4 OTG-ERR-001</h1>

The "name" element of the identifiers might be problematic if people aren't consistent, but it shouldn't be a big deal to check if vuln.identifiers[i].name.containsIgnoreCase("wasc") or whatever (that's more java'ish than JavaScript, but hopefully you get the idea).
I'm not a JSON master but isn't there a way to declare standard values? Then some standards format/value for WASC, CWE, etc could be established in the off schema while also allowing "other" .... then it would be up to the consumer to decide if they care about only the standard entries or all entries...

_{Ref: Nested Arrays in JSON Objects}

[kingthorin]

@mkonda are you still trying to move this ahead? I see that the repo was updated April 6th. I'm just after confirmation that this effort is still alive.

[paul-gould]

This gets my support as well. Would be useful to link to e.g. ATT&CK, CAPEC, etc.

[mkonda]

Acknowledging and agree to put this stuff in here in Q3.

[mkonda]

I looked at this again @kingthorin @paul-gould and I'm wondering if the array of references is largely overlapping. It seems open ended enough to work, but maybe it doesn't fit what you would actually use it for?

Do we often know the detail of the identifiers but not the reference link?

[kingthorin]

Identifiers should not change with time, links may.

[paul-gould]

Maybe add extra fields under references for type and identifier. That would effectively duplicate CWE, but you may want to retain that for backwards compatibility.

So something like:

"references": {
    "type": "array",
    "maxItems": 15,
    "items": {
        "type": "object",
        "properties": {
            "name": { "type": "string" },
            "id": { "type": "string" },
            "url": { "type" : "string", "format": "uri" }
        }
    }
}

That would make it straightforward to look at only findings with an ATT&CK ref or a CWE, or CAPEC, or whatever, as well as aggregate by ID directly rather than having to derive from the URL.