Closed mpurzynski closed 8 years ago
If I understand correctly, your proposing this as new argument for the client? If so, it's a really good idea! For me, It's a fairly common activity when using fsf interactively to pipe out the returned scan report to a local file as a reference while working on it. This would save some steps then.
Have you considered scan.log? This captures the JSON output on the server side of FSF. I might be misunderstanding something but it seems like it would be more work to type out a param name and a file rather than just > fsf_out.json for example (when considering manual submission).
I have totally missed the scan.log. Looks like it captures everything I need, granted that only JSON will be there? I don't want log processor to be confused - something that's of course also possible to solve on the parser side.
Cool. I have experience setting this up for Splunk using their forwarding agent and ElasticSearch using FileBeats (Logstash). If you have any issues using those I can hopefully provide some help. Log rotation is also something to consider, which can be managed in LogRotate if desired. There is some guidance in the install docs on how to set that up under 'extra stuff'. Considering this closed pending any additional feedback.
I will write that myself, give me a day or two, so no worries here.
It would be very useful to have a JSON output of scan resuts, into a file, with no buffering, and with a proper separation between stdout and stderr.
How about adding a new parameter that takes a file name and dumps JSON with scan results there?