No security concerns detected in this pull request.

All finding details can be found in the DryRun Security Dashboard.

I think it can be very helpful to document which fields are parsed and how. Could eventually become part of the "how to write a parser" guide?

One thing I am wondering about is the line numbers. These could potentially change slightly on small changes or non-functional changes like linting or refactorings. Does it bring a lot of value to put these line numbers in the docs? My initial thoughts that when people use "CTRL+F" on the parser file they'll quickly find the section for a specific field?

I too have questioned and am uncertain of the value of including line numbers vs trying to identify the function, and agree your thoughts are completely valid. The reason I decided to go ahead and try to include line numbers - even if a single function from lines X to Y have all the parsing logic or line numbers are changed from linting, etc - is for future analysis by an AI LLM. I am learning there is a wide range of approaches each individual parser can take to process similar finding fields into the same finding data field. My thinking is if the documentation contains enough detail about which data fields are being parsed, including line numbers in the parser.py code, it should be possible to perform AI analysis comparing all the parsers, the fields they parse, and how they are parsing them - which may help us come up with a more standardized approach to coach parser developers how to parse specific fields, best practices, etc. I could just be taking it "too far"! :) ¯_(ツ)_/¯

Carefully removed references to line numbers.