During the development of the report generating code for nessquik I came across some quirks in Nessus that just bug me.
The reports contain two fields for each report host called startTime and stopTime which, I'm assuming, are the timestamps for when Nessus started scanning and stopped scanning a particular host.
Now, the Nessus server emits messages via it's protocol that more or less give you most of the information you would need to build a report in the .nessus XML format. "More or less" are the key words here though. While this information is generated by the server, Tenable has decided that the Nessus client software should add some extra bits to the .nessus format; in particular severity counts, hostname resolution, netbios address, hardware address, and start and stop times for each host.
That data is not provided by the server via any messages that it emits back to the client, and this mixing of fat and thin client functionality pisses me off because my otherwise thin clients that I am writing now must maintain certain levels of state, and converse with my own web software to provide the same functionality as the stock Nessus clients.
It's my personal opinion that the Nessus server, seeing as how it _is_ the one doing the scanning, should be able to figure out all this stuff on its' own and emit that data as messages back to any interested clients. This would trim the fat on any client that needs to be made as they would become just parsers of NTP; adding bells, whistles, and magic as they see fit to enhance functionality.
Including those fields as known output in the .nessus files is lousy though. It would be ok if the server provided the values to fill in the blanks with; but it doesn't.