Poor support for Qualys VM Findings

[paul-gould]

Not all fields in Qualys VM findings map well into OFF.

Sample list of findings & DTD attached.

qualys.zip

[thesp0nge]

Well, it will be a good idea to stay away from a a particular vendor findings output for the sake of being independent.

[paul-gould]

Agreed. We definitely need to stay vendor-independent. This is about making sure it's possible to map VM findings into OFF and I've used Qualys as an example. The issue is more of a placeholder at the moment.

[paul-gould]

See changes in https://github.com/OWASP/off/tree/Issue-10.

[kingthorin]

Hey Paul, thanks for tackling this. I know it's still a work in progress but noticed one thing that might be worth investigating:

off/owasp.off.schema.json

Lines 96 to 111 in 4c83169

	"references": {
	"type": "array",
	"maxItems": 100,
	"items": {
	"oneOf": [
	{
	"type": "string",
	"format": "uri"
	},
	{
	"type": "object",
	"additionalProperties": true
	}
	]
	}
	},

Do you want the references array limited to one type of reference on purpose? Or should oneOf be replaced with anyOf?

[paul-gould]

What I was trying to define was that references can be an array of up to 100 items and each item can be either a URI string (maintaining backwards compatibility) or an object containing any properties -- so really a set of KV pairs. That should allow maximum flexibility in the types of references used, at the expense of variation in the data, of course. We may want instead to define a set of fields for a reference object.

I think that's what using oneOf within items achieves, but I could well be wrong :) It definitely needs more discussion and more testing, but I wanted to push something to get that started.

[kingthorin]

I believe if you want people to be able to mix types then it has to be anyOf, however you can also use ajv o(as mentioned in the README here) or online tools (see below) to check and find out. This is actually quite timely because I was working on a schema for VWAD last night 👍

Please don't take my comment as critical in any way, I'm happy to see movement/progress on this. I just thought I should chime in because it was something I was just dealing with 😀

This online tool might be handy for you: https://extendsclass.com/json-schema-validator.html

[paul-gould]

Don't worry, I didn't take your comment as critical. I appreciate you taking the time to review & comment.

Thanks for the link to the online validator. That's showing that everything is OK as it stands -- tags and references can contain a mix of strings and objects. The only thing it doesn't like is the https in the URI referencing the schema specification. Not sure why, as both http://json-schema.org/draft-07/schema and https://json-schema.org/draft-07/schema appear to be valid.

Having said that, changing to anyOf would make adding new subschemas to those sections easier, so I'll make that change.

[kingthorin]

Another thought on this. Comparing the branch mentioned earlier in this issue vs the current trunk (master) schema it looks like the schema could use a version element to track support/differences.

[paul-gould]

Good point about versioning. I think the way that's intended to be done is via the $id field, but it's something that we should look into before making any changes to the trunk.

I've just pushed a couple of small changes to the Issue-10 branch to add a status field and an optional object for source that allows more detail to be recorded.